From nobody Fri Aug 1 11:13:04 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8C91B2887 for ; Fri, 1 Aug 2014 11:13: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xys3VTKxdDp for ; Fri, 1 Aug 2014 11:12:55 -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 3B6991A031A for ; Fri, 1 Aug 2014 11:12:55 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-8f-53db853574ff Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 13.E4.05330.5358BD35; Fri, 1 Aug 2014 14:16:53 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Fri, 1 Aug 2014 14:12:53 -0400 From: Dave Hood To: Leeyoung , "Varma, Eve L (Eve)" , "Shew, Stephen" , "actn@ietf.org" Thread-Topic: related standards work Thread-Index: Ac+s07DwrSd601O8RyCE0rBXyO3RzwAB92+QAADM7uAAAP+EQAA0Ojxg Date: Fri, 1 Aug 2014 18:12:52 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F47913F@eusaamb105.ericsson.se> References: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> <7AEB3D6833318045B4AE71C2C87E8E1729C079A9@dfweml706-chm.china.huawei.com> <6D32668528F93D449A073F45707153D82C49F304@US70UWXCHMBA03.zam.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E1729C07A03@dfweml706-chm.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C07A03@dfweml706-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.12] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F47913Feusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonSte09XawwbdH1hZbei6wWSxtesJo MW2eq8WOdzUOLB6tz/ayepy9+Y/Fo+XIW1aPJUt+MgWwRHHZpKTmZJalFunbJXBltD/7zVqw q5Op4vfnbYwNjPefMXYxcnJICJhIHNh6mgnCFpO4cG89WxcjF4eQwFFGiYMf/jFCOMsYJd7t vs4OUsUmoCHx5NJkJpCEiMB8Romd+6+xdDFycAgLKEtsveIPUiMioCLR/GAtE4TtJtF69h3Y Nhag+MZP+5lBbF4BX4kvR5tZIRbsYpL427YdrIFTIEyie/cnsGWMQCd9P7UGLM4sIC5x68l8 qFMFJJbsOc8MYYtKvHz8jxXCVpKY8/oaM8g9zAL5Ep/mekPsEpQ4OfMJywRGkVlIJs1CqJqF pAqiREdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchRWpxalptuZLCJERhlxyTYdHcw7nlp eYhRgINRiYd3gfCtYCHWxLLiytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYJRTUYx31eiecV9g8qKF25gnvXypF9S9OZ7B9dh5p5YnL+u7Dc9uN+MIu9OSrnSdL0PK 91KC67perfVWO6cZN7Za5dvsXZWubannaflgduTqn1vXH/mzy8pRhVckrcY2MHx6yb9n93gZ c252PS3dJ31s/Y3Yqc8nydVN4PgzI2KFveaW3tprt5VYijMSDbWYi4oTARq3jSuTAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/actn/5R16ayn7AUNrme4Y84RU036UegU Subject: Re: [Actn] related standards work X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:13:02 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F47913Feusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One correction to the comment on the ONF SDN architecture: it is explicitly= *not* based on OpenFlow concepts. It recognizes the existence of the ONF p= rotocols as candidates to perform some of the necessary functions, but with= the caveat that they may require extension. This has been true throughout the development of the architecture that has = now been released. Dave From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 10:34 AM To: Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Eve, Good to hear from you in ACTN list. Thanks for your comment. I think you cl= arified some misunderstanding and confusion. Here's my comment for you in-l= ine. Regards, Young From: Varma, Eve L (Eve) [mailto:eve.varma@alcatel-lucent.com] Sent: Thursday, July 31, 2014 12:06 PM To: Leeyoung; Shew, Stephen; actn@ietf.org Subject: RE: related standards work Hi Young, Please see below for my two cents ;-) With best regards, Eve From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 12:44 PM To: Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Stephen, Thanks for posting this list of reference. My overall comment is: in light of many works in the past and even presentl= y in other SDOs, it is ironic that operators came to IETF to address their = problems and see IETF as viable and practical place for their problem to be= solved. I am not surprised that operators are seeking to find solutions acros= s a range of standards and industry forums. This is not exclusive to IETF = - e.g., consider related ETSI NVF work items. YOUNG>> Yes, that is a reality. >From a transport network perspective, there have been many tools IETF champ= ioned in regard to GMPLS control plane, PCE and other configuration/managem= ent tools. Some of your pointer for ONF seems irrelevant to many operators = as OF is a green-field for them. As you were in the BoF, the operators bro= ught their current problems on their brown field. Are you aware of any real= deployment of ONF-based transport networks? ACTN can certainly treat OF-ba= sed transport as a domain among others once it is deployed. The reference was to a protocol-neutral SDN Architecture document (i.= e., independent of the protocol used over interfaces), which has some very = useful material that has also been shared with other SDOs, and IMHO is quit= e relevant to the ACTN problem domain. I would certainly understand your c= omment if the document were focused/optimized for the OF protocol. However= , it is not. It is my view that protocol-independent architectural work sh= ould be examined regardless of what group produces it, as we have so many c= olleagues contributing across multiple standards and industry forums, which= allows for leverage of applicable work. YOUNG>> The assumption for SDN arch. Document (as far as I understand from = the initial version) is, however, tied with OF based philosophy, meaning th= at the SDN controller is a "God"-box as to what to control as to how much i= t wants to know. The ACTN is on a different assumption. ACTN control hierar= chy would not touch existing domain control of many kinds (e.g., GMPLS/ASON= , PCE-based, NMS/EMS-based, etc.) and let them continue control/operate the= ir networks (which is one of the requirements from many operators). What th= ey need is a overarching "overseer" that allows quick service provisioning = based on an end-to-end global abstraction view of all encompassing domains.= For instance, cross-connect and other low level control of NE will need no= t be abstracted in ACTN scope as these controls will continue to be done at= existing domain level control. I think this assumption makes a huge differ= ence. I believe what ACTN is trying to do based on operators' use-cases has= a different starting point from what you are referring to, namely, the ONF= SDN Control architecture models has been trying to do. ACTN does not repla= ce any existing network control and operation. It builds on top of that. Your Virtual network reference from ITU-T is quite theoretical and VPNs hav= e been implemented in L2VPN/L3VPN WGs focusing on practical issues. I also = see some gap of many ITU-T references and the reality. Perhaps the language used in the ITU-T Rec. could be a barrier for so= me, but there is useful information. You'll find some good material, lever= aging this, in the SDN Architecture document discussion of this area. YOUNG>> language is always a tremendous stumbling block. :) I will try to u= pdate myself with the mentioned references. Your pointer for TMF is all appreciated. We will look at if data model is n= ecessary to enable abstraction. For TE model of IETF, we did not have eithe= r IM or DM in GMPLS/PCE implementation. At this point, I am not sure if we = need IM or DM. One of the homeworks from the BoF is to investigate if we ne= ed IM/DM. If we do need IM/DM, there have been some efforts in IETF around = Yang and JSON. I have proposed JSON based abstraction models in the past in= IETF (In a BoF called I2AEX under ALTO) , which seems working very well fo= r transport network resource abstraction. There are also BGP-LS based mode= ls that have progressed in IETF quite a bit. I tend to think these lists ar= e a starting point. TMF is a bit foreign to IETF and to me. If one is looking from a broader transport networking perspective, a= n underlying information model from which various data models/interfaces ca= n be derived enables interoperability (not to mention leverage of significa= nt industry experience in networking & forwarding domain). However, this i= s a much larger discussion topic area (beyond ACTN). YOUNG>> Agree. My point is that models are only tools that should help the = functions. As pointed previously, for simple functions to fulfill, the vali= dity of models needs to be carefully evaluated. Thanks, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen Sent: Thursday, July 31, 2014 11:00 AM To: actn@ietf.org Subject: [Actn] related standards work As discussed in the actn bof last week, I list some related standards that = I think should be considered by actn so that things don't get re-invented. 1. Virtual Network. There are various semantics to the word "virtual"= so adopting or stating a definition is important. RFC4847 describes virtua= l networks in terms of ITU-T Y.1312 and Y.1313. Those Recommendations addr= ess both the data plane aspect of VPNs as well as the control plane aspect.= Concepts of private and shared VPNs are described. I find them quite use= ful and suggest that uses cases adopt these terms so that the commonality o= f the use cases can more readily be determined. 2. Abstraction and arrangement of control. The recently published ONF= SDN Architecture (https://www.opennetworking.org/images/stories/downloads/= sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes var= ious arrangements of SDN controllers which I think should be adopted by act= n. They define "abstraction" in way that makes "virtual" a subset of abstr= action. Having a clear definition of the 2 terms is important. The Multip= le Vendor Domain Transport Networks use case could be covered by a limited = hierarchy of SDN controllers. One of the suggestions in the SDN Architectu= re document is that there may be a need for inter-domain control and this m= ay be a gap that actn addresses. 3. Interfaces. Implementations of interfaces imply some design, and i= t is helpful to expose that design upfront so that limitations, extensibili= ty, and commonality are understood. To that end, use of a common informati= on model has been beneficial. I point in particular to TM Forum's TR215 an= d is draft successor TR225. From an information model, a more specific inf= ormation model can be derived (like an instantiation of an aspect of the ge= neral one). Then, data models can be developed from that specific informat= ion model. If a common information model is used, then the particular enco= ding of the data model is less critical. I don't suggest that actn start w= ith just a data model because the architecture behind it is not exposed. Stephen Shew | Director, Standards sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA = K2H 8E9 Direct +1.613.670.3211 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F47913Feusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One correction to th= e comment on the ONF SDN architecture: it is explicitly *not* based = on OpenFlow concepts. It recognizes the existence of the ONF protocols as candidates to perform some of the necessary functions, bu= t with the caveat that they may require extension.

 

This has been true t= hroughout the development of the architecture that has now been released.

 

Dave

 

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 10:34 AM
To: Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Eve,

 

Good to hear from you = in ACTN list. Thanks for your comment. I think you clarified some misunders= tanding and confusion. Here’s my comment for you in-line.

 

Regards,

Young

 

From: Varma, E= ve L (Eve) [mailto:eve.varm= a@alcatel-lucent.com]
Sent: Thursday, July 31, 2014 12:06 PM
To: Leeyoung; Shew, Stephen; actn@i= etf.org
Subject: RE: related standards work

 

Hi Young,

 

Please see below for my two ce= nts ;-)

 

With best regards,<= /span>

Eve

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 12:44 PM
To: Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Stephen,=

 

Thanks for posting thi= s list of reference.

 

My overall comment is:= in light of many works in the past and even presently in other SDOs, it is= ironic that operators came to IETF to address their problems and see IETF = as viable and practical place for their problem to be solved.

 

<ELV> I am no= t surprised that operators are seeking to find solutions across a range of = standards and industry forums.  This is not exclusive to IETF – = e.g.,  consider related ETSI NVF work items. 

 

YOUNG>> Yes, = that is a reality.

 

From a transport netwo= rk perspective, there have been many tools IETF championed in regard to GMP= LS control plane, PCE and other configuration/management tools. Some of you= r pointer for ONF seems irrelevant to many operators as OF is a green-field for them.  As you were in the B= oF, the operators brought their current problems on their brown field. Are = you aware of any real deployment of ONF-based transport networks? ACTN can = certainly treat OF-based transport as a domain among others once it is deployed.

 

<ELV> The ref= erence was to a protocol-neutral SDN Architecture document (i.e., independe= nt of the protocol used over interfaces), which has some very useful materi= al that has also been shared with other SDOs, and IMHO is quite relevant to the ACTN problem domain.  I would certa= inly understand your comment if the document were focused/optimized for the= OF protocol.  However, it is not.  It is my view that protocol-i= ndependent architectural work should be examined regardless of what group produces it, as we have so many colleagues contri= buting across multiple standards and industry forums, which allows for leve= rage of applicable work.    

 

YOUNG>> The a= ssumption for SDN arch. Document (as far as I understand from the initial v= ersion) is, however, tied with OF based philosophy, meaning that the SDN co= ntroller is a “God”-box as to what to control as to how much it wants to know. The ACTN is on a different assumption. AC= TN control hierarchy would not touch existing domain control of many kinds = (e.g., GMPLS/ASON, PCE-based, NMS/EMS-based, etc.) and let them continue co= ntrol/operate their networks (which is one of the requirements from many operators). What they need is a overa= rching “overseer” that allows quick service provisioning based = on an end-to-end global abstraction view of all encompassing domains. For i= nstance, cross-connect and other low level control of NE will need not be abstracted in ACTN scope as these controls will con= tinue to be done at existing domain level control. I think this assumption = makes a huge difference. I believe what ACTN is trying to do based on opera= tors’ use-cases has a different starting point from what you are referring to, namely, the ONF SDN Control= architecture models has been trying to do. ACTN does not replace any exist= ing network control and operation. It builds on top of that.

 

 

 

Your Virtual network r= eference from ITU-T is quite theoretical and VPNs have been implemented in = L2VPN/L3VPN WGs focusing on practical issues. I also see some gap of many I= TU-T references and the reality.

 

<ELV> Perhaps= the language used in the ITU-T Rec. could be a barrier for some, but there= is useful information.  You’ll find some good material, leverag= ing this, in the SDN Architecture document discussion of this area.

 

YOUNG>> langu= age is always a tremendous stumbling block. J<= span style=3D"color:#1F497D"> I will try to update myself with the mentione= d references.

 

Your pointer for TMF i= s all appreciated. We will look at if data model is necessary to enable abs= traction. For TE model of IETF, we did not have either IM or DM in GMPLS/PC= E implementation. At this point, I am not sure if we need IM or DM. One of the homeworks from the BoF is to inve= stigate if we need IM/DM. If we do need IM/DM, there have been some efforts= in IETF around Yang and JSON. I have proposed JSON based abstraction model= s in the past in IETF (In a BoF called I2AEX under ALTO) , which seems working very well for transport net= work resource abstraction.  There are also BGP-LS based models that ha= ve progressed in IETF quite a bit. I tend to think these lists are a starti= ng point. TMF is a bit foreign to IETF and to me.

 

<ELV>  I= f one is looking from a broader transport networking perspective, an underl= ying information model from which various data models/interfaces can be der= ived enables interoperability (not to mention leverage of significant industry experience in networking & forwarding domain).=   However, this is a much larger discussion topic area (beyond ACTN).<= o:p>

 

YOUNG>> Agree= . My point is that models are only tools that should help the functions. As= pointed previously, for simple functions to fulfill, the validity of model= s needs to be carefully evaluated.

 

Thanks,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: actn@ietf.org
Subject: [Actn] related standards work

 

As discussed in the actn bof last week,= I list some related standards that I think should be considered by actn so= that things don’t get re-invented.

 

1= .   &= nbsp;  Virtual Network.  There ar= e various semantics to the word “virtual” so adopting or statin= g a definition is important. RFC4847 describes virtual networks in terms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both the d= ata plane aspect of VPNs as well as the control plane aspect.  Concept= s of private and shared VPNs are described.  I find them quite useful = and suggest that uses cases adopt these terms so that the commonality of the use cases can more readily be determined.=

2= .   &= nbsp;  Abstraction and arrangement of = control.  The recently published ONF SDN Architecture (https://www.open= networking.org/images/stories/downloads/sdn-resources/technical-reports/TR_= SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SDN controllers which= I think should be adopted by actn.  They define “abstraction= 221; in way that makes “virtual” a subset of abstraction. = Having a clear definition of the 2 terms is important.  The Multiple Vendor Domain T= ransport Networks use case could be covered by a limited hierarchy of SDN c= ontrollers.  One of the suggestions in the SDN Architecture document i= s that there may be a need for inter-domain control and this may be a gap that actn addresses.

3= .   &= nbsp;  Interfaces.  Implementatio= ns of interfaces imply some design, and it is helpful to expose that design= upfront so that limitations, extensibility, and commonality are understood.  To that end, use of a common information model has b= een beneficial.  I point in particular to TM Forum’s TR215 and i= s draft successor TR225.  From an information model, a more specific i= nformation model can be derived (like an instantiation of an aspect of the general one).  Then, data models can be developed= from that specific information model.  If a common information model = is used, then the particular encoding of the data model is less critical.&n= bsp; I don’t suggest that actn start with just a data model because the architecture behind it is not exposed.=

 

Stephen Shew | Director, Standards
sshew@cien= a.com | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

 

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F47913Feusaamb105erics_-- From nobody Mon Aug 4 10:28:15 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238871A0061 for ; Mon, 4 Aug 2014 10:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hYlDJ1k57tr for ; Mon, 4 Aug 2014 10:28: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 95D981A0019 for ; Mon, 4 Aug 2014 10:28:07 -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 BKW51659; Mon, 04 Aug 2014 17:28:05 +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; Mon, 4 Aug 2014 18:28:04 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Mon, 4 Aug 2014 10:27:58 -0700 From: Leeyoung To: "actn@ietf.org" Thread-Topic: ACTN BoF summary and meeting minutes Thread-Index: Ac+wCW34/v7VU+JRSPe74zyR/DaJUA== Date: Mon, 4 Aug 2014 17:27:57 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C085F1@dfweml706-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.102] Content-Type: multipart/mixed; boundary="_004_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/HElPSxuHWjnONwyydjAt7310Wk8 Cc: Daniel King Subject: [Actn] ACTN BoF summary and meeting minutes X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:28:13 -0000 --_004_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_ Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_" --_000_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, Attached please find a draft ACTN BoF meeting minutes. We thank Andy Malis = for taking the minutes. Please feel free to comment on that. Below is an ex= ecutive summary for those who do not have time to read the minutes. This in= formation will also be upload to ACTN wiki: https://sites.google.com/site/a= ctnbof/. Thanks for your interest in ACTN work and we look forward to see more discu= ssion on the mailing list. Best regards, Dan & Young ---------------------------------------------------------------------------= --------------------------------- Abstraction and Control of Transport Networks (ACTN) Summary THURSDAY, July 24, 2014 1. Introduction - Good attendance (over 110 signed) http://goo.gl/NKmRfw and suppo= rt for network operators both who presented (KDDI, Microsoft, KT, Telefonic= a, China Mobile & SKT) and those who participated at the mic (British Telec= om and Deutsch Telecom). - Session intended as a non-WG forming BoF - Opportunity to hear operators' pain points in operating dynamic = connectivity in current multi-domain transport networks - Discuss if there is enough interest and agreement to pursue furt= her. 2. Use Cases from Operators - Multi-Tenant Virtual Network Operation http://tools.ietf.org/html/draft-kumaki-actn-multitenant-vno - Data Center Operator: Multi-domain Data Center Interconnect https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dci/ - Transport Network Operators: On-demand E2E Connectivity Services= in Multiple Vendor Domain Transport Networks/Virtual Network Operation for= Multiple Domain in a Single Operator Network https://datatracker.ietf.org/doc/draft-klee-actn-connectivity-multi-vendor-= domains/ https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multidomains/ - Mobile Network Operators: Mobile Backhaul Packet Transport Netwo= rks/Mobile Virtual Network Operation for Multiple Domains in a Single Opera= tor Network https://datatracker.ietf.org/doc/draft-cheng-actn-ptn-requirements/ https://datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/ - ACTN is multi-dimensional problem: administrative domain, switch= ing technology and time (to-deploy or resize or reconfigure topologies of e= xisting services). - Operator use case objectives include requirements for more effic= ient use of transport network resources, fast deployment of new services, a= nd control of the core transport network by the service network operator (n= etwork programmability), virtualization of network resources for centralize= d control and packet-optical integration for multi-layer integration. - Observation that the control plane should be simpler, and if we = expend more time on the control plane, we create more complexity. Data Plan= e interoperability is out of scope. 3. Research Use Case - Towards Ultimate Convergence of All Networks (TOUCAN) - TOUCAN - UK EPSRC Project 4. Open Discussion - Open discussion reiterated the operator requirements for greater= control of network interconnectivity (between administrative and technolog= y domains), abstraction of underlay resources and ability to slice and pres= ent resources. - Suggestion that other SDOs have also researched aspects of the p= roblem space, including ITU-T (Y.1311, Y.1312, and Y.1313), ONF (Architectu= re group), and TMF (network modeling). - Requirement to clarify differences between inter-technology, int= er-region, and inter-domain, suggestion to do this on the list. - Vendor suggestion that protocol work exists, and would need to b= e clearly identified. PCE also suggested a technology solution, as part of = larger platform towards solving ACTN use cases. - Proposed that a common abstraction model would help with simplif= ying network operations and providing network abstraction. - Highlighted that abstraction (data plane) is hard to model due t= o the breadth and complexity of transport technologies. - Investigation of existing work (including YANG) would be require= d. 5. Summary and Next Steps - AD highlighted the common threads, and agreement that solving AC= TN will require interoperable technologies, however it would be extremely p= remature to be talking about solutions. - Agreement that the next steps should include further polishing o= f the use cases and drawing out common requirements, development of a probl= em statement and a clear scope and architecture document would also facilit= ate discussion. - AD polled the room to see who would be willing to write text to = scope the problem and frame solutions, approximately 20 people put their ha= nds up. - Request by the AD and Chairs for people to participate on the li= st, and contribute both the use cases and additional documents. 6. Links to session slides - Administrivia, Agenda Bashing, Introduction - Multi-Tenant VNO Use Case - Multi-domain Data Center Interconnect Use Case - On-demand E2E Connectivity/Virtual Network Operation in Multiple= Vendor Domains Use Case - Mobile Operator Packet Transport Network/Mobile Virtual Network = Operation Use Case - TOUCAN - UK EPSRC Project --_000_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Attached please find a draft ACTN BoF meeting minute= s. We thank Andy Malis for taking the minutes. Please feel free to comment = on that. Below is an executive summary for those who do not have time to re= ad the minutes. This information will also be upload to ACTN wiki: https://sites.google.com/site/actnbof/.

 

Thanks for your interest in ACTN work and we look fo= rward to see more discussion on the mailing list.

 

Best regards,

Dan & Young

 

----------------------------------------------------= --------------------------------------------------------

 

Abstraction and Control of Tran= sport Networks (ACTN) Summary

THURSDAY, July 24, 2014

 

1. Introduction

 

-     &n= bsp;    Good attendance (over 110 signed) http://goo.gl/NKmRfw and suppor= t for network operators both who presented (KDDI, Microsoft, KT, Telefonica= , China Mobile & SKT) and those who participated at the mic (British Te= lecom and Deutsch Telecom).

-     &n= bsp;    Session intended as a non-WG forming BoF

-     &n= bsp;    Opportunity to hear operators’ pain points in operating dynami= c connectivity in current multi-domain transport networks

-     &n= bsp;    Discuss if there is enough interest and agreement to pursue further.=

 

2. Use Cases from Operators

 

-     &n= bsp;    Multi-Tenant Virtual Network Operation
http://tools.ietf.org/html/draft-kumaki-actn= -multitenant-vno

 

-     &n= bsp;    Data Center Operator: Multi-domain Data Center = Interconnect

https://datatracker.ietf.org/doc/draft-fang-actn-multidomain-dc= i/

 

-     &n= bsp;    Transport Network Operators: On-demand E2E Conn= ectivity Services in Multiple Vendor Domain Transport Networks/Virtual Netw= ork Operation for Multiple Domain in a Single Operator Network

https://datatracker.ietf.org/doc/draft-klee-a= ctn-connectivity-multi-vendor-domains/

https://datatracker.ietf.org/doc/draft-lopez-actn-vno-multido= mains/

 

-     &n= bsp;    Mobile Network Operators: Mobile Backhaul Packe= t Transport Networks/Mobile Virtual Network Operation for Multiple Domains = in a Single Operator Network

https:/= /datatracker.ietf.org/doc/draft-cheng-actn-ptn-requirements/

https:/= /datatracker.ietf.org/doc/draft-shin-actn-mvno-multi-domain/

 

-     &n= bsp;    ACTN is multi-dimensional problem: administrati= ve domain, switching technology and time (to-deploy or resize or reconfigur= e topologies of existing services).

-=           Operator use case objectives include requiremen= ts for more efficient use of transport network resources, fast deployment o= f new services, and control of the core transport network by the service ne= twork operator (network programmability), virtualization of network resources for centralized control and pack= et-optical integration for multi-layer integration.

-     &n= bsp;    Observation that the control plane should be si= mpler, and if we expend more time on the control plane, we create more comp= lexity. Data Plane interoperability is out of scope.

 

3. Research Use Case=

 

-     &n= bsp;    Towards Ultimate Convergence of All Networks (T= OUCAN)

-     &n= bsp;    TOUCAN - UK EP= SRC Project

 

4. Open Discussion <= /span>

 

-     &n= bsp;    Open discussion reiterated the operator require= ments for greater control of network interconnectivity (between administrat= ive and technology domains), abstraction of underlay resources and ability = to slice and present resources.

-     &n= bsp;    Suggestion that other SDOs have also researched= aspects of the problem space, including ITU-T (Y.1311, Y.1312, and Y.1313)= , ONF (Architecture group), and TMF (network modeling).

-     &n= bsp;    Requirement to clarify differences between inte= r-technology, inter-region, and inter-domain, suggestion to do this on the = list.

-     &n= bsp;    Vendor suggestion that protocol work exists, an= d would need to be clearly identified. PCE also suggested a technology solu= tion, as part of larger platform towards solving ACTN use cases.

-     &n= bsp;    Proposed that a common abstraction model would = help with simplifying network operations and providing network abstraction.

-     &n= bsp;    Highlighted that abstraction (data plane) is ha= rd to model due to the breadth and complexity of transport technologies. &n= bsp;

-     &n= bsp;    Investigation of existing work (including YANG)= would be required.

 

5. Summary and Next Steps<= /o:p>

 

-     &n= bsp;    AD highlighted the common threads, and agreemen= t that solving ACTN will require interoperable technologies, however it wou= ld be extremely premature to be talking about solutions.<= /p>

-     &n= bsp;    Agreement that the next steps should include fu= rther polishing of the use cases and drawing out common requirements, devel= opment of a problem statement and a clear scope and architecture document w= ould also facilitate discussion.

-     &n= bsp;    AD polled the room to see who would be willing = to write text to scope the problem and frame solutions, approximately 20 pe= ople put their hands up.

-     &n= bsp;    Request by the AD and Chairs for people to part= icipate on the list, and contribute both the use cases and additional docum= ents.  

 

6. Links to session slides=

 

-     &n= bsp;    Administrivia= , Agenda Bashing, Introduction

-     &n= bsp;    Multi-Tenant = VNO Use Case

-     &n= bsp;    Multi-domain = Data Center Interconnect Use Case

-     &n= bsp;    On-demand E2E= Connectivity/Virtual Network Operation in Multiple Vendor Domains Use Case=

-     &n= bsp;    Mobile Operat= or Packet Transport Network/Mobile Virtual Network Operation Use Case

-     &n= bsp;    TOUCAN - UK EP= SRC Project

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_-- --_004_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="ACTN BoF Minutes_IETF90.docx" Content-Description: ACTN BoF Minutes_IETF90.docx Content-Disposition: attachment; filename="ACTN BoF Minutes_IETF90.docx"; size=29153; creation-date="Mon, 04 Aug 2014 17:21:49 GMT"; modification-date="Mon, 04 Aug 2014 17:21:50 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDgvd/FogEAAJAGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VctOwzAQvCPxD5GvKHHhgBBqyoHHEZAo4uw6m9Yifsi7Bfr3bBIaHm1ToHCJlNg7Mzs7doZnL7ZK niCi8S4Xh9lAJOC0L4yb5uJ+fJWeiARJuUJV3kEuFoDibLS/NxwvAmDC1Q5zMSMKp1KinoFVmPkA jldKH60ifo1TGZR+VFOQR4PBsdTeEThKqcYQo+EFlGpeUXL5wp9bJREqFMl5u7HmyoUKoTJaESuV T674wpK+MWRc2ezBmQl4wDKEXMtQr2wmeKu7YWuiKSC5VZGulWUZ8tnHQhZezy33kPXDrNHpy9Jo 6OprtBC9BkT23FZZt2KVcUv9G3W4uZ1A5Mq/F9JBbxWBtKgA/15Bi9tHz2bdRh9Qcjh25oc6fgUU Kc8jQCQDXX42+t9KfDA0uyxL0Jz27YGwmNZTz1Zq+zptUodAxLP+DsnnM5huS90SuU9CZ7aeI3n7 jU77RbQwP3Gb+H4B2TwPd6ZvYPr6bSwv+Qoaq0kFO/OtnPQOequIZ5jc/dvoP4D3CXmfvo+/MGN5 PWuuXjNy2fxPRq8AAAD//wMAUEsDBBQABgAIAAAAIQCZVX4FBAEAAOECAAALAAgCX3JlbHMvLnJl bHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAArJLPSsNAEMbvgu+wzL2ZtIqINOlFhN5E4gMMu9MkmP3D7lTbt3ctiAZq0oPHnfnm m9987HpzsIN655h67ypYFiUodtqb3rUVvDZPi3tQScgZGrzjCo6cYFNfX61feCDJQ6nrQ1LZxaUK OpHwgJh0x5ZS4QO73Nn5aEnyM7YYSL9Ry7gqyzuMvz2gHnmqrakgbs0NqOYY8uZ5b7/b9Zofvd5b dnJmBfJB2Bk2ixAzW5Q+X6Maii1LBcbr51xOSCEUGRvwPNHqcqK/r0XLQoaEUPvI0zxfiimg5eVA 8xGNFT/pfPhoMEd0ynaK5vY/afQ+ibcz8Zw030g4+pj1JwAAAP//AwBQSwMEFAAGAAgAAAAhAHQE hqkVAgAA+wkAABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAzFZNj9MwEL0j8R8q31O3C2xZtGkvLNIeuEARZ9eeNFbscbAn ZcuvZ9psv7S7gVYR4hLJtjLz5uu9uZ09eDdYQUw2YC7Gw5EYAOpgLC5z8W3+KXsvBokUGuUCQi7W kMRs+vrV7RdwivinVNo6DdgKplyURPUHKZMuwas0DDUgvxQhekV8jEtZK12pJcir0ehaxmMbYnpi c3BvchHvDfufr2v2/GfboSisho9BNx6QnnEhS7YUncWKjaq4BGrNJsZsFCmKjA7i0AIVW7QmaGmi KiirHECmNGGmAyJositL68w3jmy2AjQhZiZ4ZTHJnfHPwTDuuweCiMoJ+XyA4zd9RkicedgByMX2 KLff8ZBL8RKIXjEkIOL+SQcYu5suCJM+03B5oQuFy7bQ29q2Nc2MtueW9arPeIqANFcLd1Ta/VVX UnsFkWjtePz3o9Oeu9yP+8wBNn4BkRvrgGB/1QXiuk8QlzdW1XhV2aPWIkCFlK0wnNtavab18oiY +vExHg7ikQvbgTkzonf/qEQUgksHemchYmGTNyPJDN6AnMUQfE7NhswncqM8W5H4Sx5n6fwflIq1 d8dgNctVhB+NjSwKSOcq09s+A/oJi69PdOHosmuCb/oEcnm/O95nfrUNv+/3CzX/pdR6q2NIoaCh Dl62C81mkZmc7kqypd7vlsq7ouBt5AkrHz3tMitPVrbpbwAAAP//AwBQSwMEFAAGAAgAAAAhAKjk g9/8MAAAaqQBABEAAAB3b3JkL2RvY3VtZW50LnhtbOx9627byLLu/wOcd2gYOBsZwI51l+21okDW ZeIzEycr9qzB/KQkSiJMkRqSsqL8mtc4wN7APMs8ynqS81V1N0XSFMPMaGJS0QL2zlgXis2urstX X1X98/XHhS0eTc+3XOfVSfVl5USYztidWM7s1clP98OzixPhB4YzMWzXMV+dbEz/5HXnf/+vf66v Ju54tTCdQOASjn/1iHfnQbC8Oj/3x3NzYfgv3aXp4M2p6y2MAH96s/OF4T2slmdjd7E0Amtk2Vaw Oa9VKq0TdRn31cnKc67UJc4W1thzfXca0Feu3OnUGpvqH/0NL8/vym/21S3zL557po17cB1/bi19 fbXFn70aljjXF3nMWsTjwtafWy/z/NrEM9bYj4Utb3vtepOl545N38erfflmeMVqJeu31QOkS4Tf yHML8d/Ud7IwLCe8DElHYv/DzXuJzTuXv31Ol9ouBM+iA1kauZMN/bsU6yvI4uTDq5NKpdtrVdsQ DPXSe2z0kxf75tRY2cHTd97TSxfddrXf5V9YvvfoB/ylMcZTwzWNaWDiitUWRH59ZVt0/7V6U//x YWXjBSP40TT84OScvuvJS3hD1wl8uoI/tqxXJz3DtkaeRV+cdx0//srYf3Vyby1MX9yaa/HBXRiO vNjYtV0PX3k0bLpT+p98w/+kX63V9Cs9+jn+pHztXN0M/lXrokvxg4s9pb3f9YgfxKjn8797WcP6 ijUI7wye+NIzfdN7NE863ZEfeMaYTqiAAhI9PHbPtYU7Ffee4fhL1wvwVAMI1IMvXnR797ffiX/i kQQd+v+83fL/7XPf/p4n0HlrOavA9JO3X+JdHXmQEb0PI9d9INV/FxjYtPWVNYHQ04lxjAU2/f7N Tx/u+t1fpLyXWpY7ei2JrdRPYABJ1uuXWqXEexx0TsX/XdkbUWucilql2kgsusw7yfJLyqRar1TO qs1K5Y/fu2QzHNd1/vj9jswvNNPNIS75R3fMntHVH78nljffLE0PxvJBeHyIvZsJm8zAde3Agjvz wXUXYmEs6XDPLT9wvQ2MLJvg55eGy2Zj2A6tKu4wYlPhG3xK2tn11Up/iHwt2yQFRTpNWpSgc7+a wIq3zy9ijwmfCJ8Tf3559G1Y132Dvk2nNzcsz396kr7SadiXj9b5xV3Bb/7RNGOijrOg7Re5sbWL Wrdek6d9n17X3lZxuuvuy+g3d56o53Az/t7l7G07+oZjmbb4Aco1tjHQoJ/VmcfQT50wfQD/3j2X gc/edr4a2++EGum22u1LIE94mcAAubBWv12pXu9ft+x5YS9zLGzvcfm+toVAuKeR+JOoOr4xCqfZ +6LkxuwbbOjcEIwwWTGwsGuv/t6jtK/dgv5/Ua2IheV8F1tIqvZst9uD4RZNi2jPdq/Zb7f1afvG gDMgqe504JHhDBDbvDqZecaCYQry9aGA9i7We9v9957rwCkbmxPxn9/+u8sC/Z/f/iepgFJXCBiC 1pdHUmJnQZ/8o/go41tY8UhX5dKLZ5DVCSA4Mb2RsML9Vq3fHuzf4O7rAKSvMJibT1ZV2E3qUIqM 8hG+bU1MP3l0Q3eeYqt2v3F9IZMZxctE7ETxxT32I+7cJ8RseN0YXA+LK2Yd17CF5YvAFb5pCmsq pisPUuaJieWPVxIGxPtrw0NaAocqvoupKjbh4Ea0afydZzHGlPHq+pbxNHMF7f+MKa58p3hfd//3 eJ/pOqv28onK0oaWTn5WIvQQHkrnLVK4lrg3HZyfP37/9+273cBGEZ/HvgxaZ+WbYmz4mRBbcYRh X8tOPxPixb3xsNoY4q21MXzjwTgVP/T7N9+JF9VmzpAn/VHFsYWI6q2069dtzkoS6nBUvWS5pJcb ZjO2WR+OJHclePZzSP+sqdl7lodoLT54TRMjMIiS8GB6Ly0zmDKjCTSo84kHNsnZw2phPFhnoCw4 ZwvSaAErtLNHxz2P+dl4sOETzReDRaS03q1c9wffaLRe4GhcaattaIXDkcetv27VW/2L4rq/O7Rz TKATHn232hj0+sVdUueNKdZZC4jwxkoUarkreyJs68EUC9czhUlkSYsImuRWgDUF1aVYU45kTQlw rdyVBybhqZjC6RcTc2m7GyZ14vMOGGvExQLlEh8gCtZ4S8GiMHtMP/P0qllPdthrNvu9AovGaCNo aWrdeAbMLxOI0z0DZAbxQr8CWI2gwoUhSazf5Yj6EhDs54C1frVVvawfNf1VgRiXRAi6dcW//stY LP/RzbHn6T5onNkate79+nWTGTWhD1qXL1Gg91VIrPsKoPcSHmx90Jymf193/zXD//o3Hv734VeL HiwVMLV3StFmGZGsM/UceMheJJ00y5VgJORsAp645Yjoc0HW0vRgfx1zHHzxs4mokM/7M/s9QXt7 NmWBhPa24Bc/rjYrwxFDw5mdAgVRhTB/AQCJ2JkCYB1/Nrz/68USYfC9hTM4/X2EM2bnWzhjCrmL gBlSJ51NxtYewQwVKSqw+1kgt+cTw5wezde+wZ2pPKWPIggH7LVKXGbmLxr1dqt2WdygLx3iuEMY uF2rgcgaETLCYs/8dWV5JkXJvkBtY56l62yODPmK/jw6suLTm/hnI2QjJsKIlGKtrWAuDMT+iwXK HyxHVneiFILhUUAPE9POclAKv/gcQV2/Xe22hjoy/xCxq5f9eqN+qd85KrQiVEnuVGgDzxpnnt7q RXVQLzDlAlCEN6G6uswD12i0u+3ial9EPV3giBt3lVxFvliuMPZRGL6/AhlzBgTRCBhGdFFab9i2 Bk5tGMy54YtHy1e178QqMfGhDcyL8/A6Lo2p1JHr61Y7ncdZrbf7tZDhedQ9BdE9Hek3JYVbuwSU K71oVS+aBUbF0x2kq7i0JpJAyhKW7Azfuqd8cMfw7nByowd34qKK33EDnOBHUxhjasBAx5fO98QM DMv24Q7xn4m9TmXgRjnGUVko+nPrqASInyylSl2l4hkfhGywYATuMioUroPqZ9ACkepdIRfkWZ8i 7rKfwHVT9fluXzKu6Y/6vCD6PF0Zki95iAqxa/tQiQYlehEPG84GVFh/BXnnOJBesyLINFXEL128 4osRMqem6egMqp/Ht6lctPsXIQMrGlcdfZvPA/fP4Ajn8G0Kb8+uiKIO+SYZZ9rW0jbFz9+zMSf5 vhncDwU1mSHPHvIdELHHs2bzAN7AOgdaEJfdqFQf0YJCSnW6hn/nj41ssK89rNa24M+HGL8jnx+8 r9zb3pJQ37vOJ8M2PyU82rJB11fiZwtuOh1n7dkbE4TqgHQlrWdEdozf99GRSETe5PZTcPTxVX81 Cp1fQd271DWhOPD9UHfAEX5ENY/nM2dqtELrEAoVYu3m8ljDuHaI6o24Rjl6hgXxDA/DGnZxUIgt CIE3RgCwcli43TFM87pVa1aPeHjROGyy8QbU4nwjJq5Ym/DTEbmybwOv5jXeAISp3f5Qhy3cwHqU TTNfJ01CFMS4GDYbFwXuA5Nu4cXd0jRA7kcwP2cybWDYD3QIVuhZpyHdyCPg5zP10PDKEOEjAn/J X4KkY+HkZAJkw2ql2S0d6JcmMFPb/Kjw7IRdS+A+5RSLG2n9l54FgGeDDCefAdh/hvktIP0QGoIC XYEmuUD/XTH2TCOgMxVlUD9NFadCZruAwaI/vA60RUInpK4vHRIs+up2aAyyki7+n6fFAu4i/D7A I6ZtZ6rIXqPRb5eOFBHXaKmA5hey3I++bCFj4By+bDkl+ErcuQsz4J7MGqO0DW9mCirv4/CQPACO 94Dma1c4iXICA5JpW/4qFcfk0X27dHvRH2XH/IhGFT58mr+Q9Sn6Ineo+NA3dslT9kl45gQFSr+Q fQCl73NESlnUde1AR+hEirit3uFAP8LlPpaDfLbH5L4Ata9ZDtLIjhuyROjroox/z0Pp3Id1ireq +k4Xhezsj76fgvP9CsveMNirhGUB8JhvSMLXlYZ9rXeHGi7HQ5BHYl+PovPOOZtglAq8i0FtQBMQ qPzHesTQFHGnKnO/+LlcXLbb13lJjQU9EmUpBtqzOCBFwQVilKH8t+lQ7/G+LBV7ojP9839bXrAC hSmuRCmdQaT18DryAllSNKhUeoNmTgJpQQXmm7QcOzQpkdTEHVxYSJG2rFpKsuRABfZHq4KhROV8 CJ0XbzBMy5n98Tv6uKOfEvo3GGi7ZZuo5jgVnODO1qxNtCS43hJ0DjnDfdhOVueU933qOtbYQElp LW8b4azoQz+ySAB7rDOND0vhpubHOtNonemDbZqyzlSVt7N/KztonT2yl6MK4v0vrjxNSOtRMHf2 c+OataNgRgXTRtOfT1Iy0cJNCqSsgv5yQbxoVHr9muZBRLk88XeOXJ6icHmkpxSpACbaZ442za1W q3n5N4yp2BemsCMoeBMtdqbkB3K3I9tc+AL/zQUOTPgerzyPWooZS7xvYM6rJLnNQYc9s1HIZj8t j7YW+OijrJfOgZAn0ocRlX1db/S+2TkFIegnfW71LPKFIc9BDP+wMifWzPSSAWVh73jHuUjev/Zx S7INP6ycT0lWRihKhJoPrhvIwOeMZ59BkNK3hTn7yYxrbF3tXquLqdKFFbcOnF0aZ7tLvsq7N2Jp Gw5shqTQgRidtcTCb5MP84Wy7aw1lPMIvRQ/o6ZrS3DMWmG910RpVoEPE++ShX6nzE3NWko5N4tY KNvSA8oHYQwFiAlMy5jIfq9EaZH1SdSZVc7K5qN4Sp9UjETuDAu0DzL9EVmkHP6YemDa7kX8sfg7 x8ilKJFLd+JZhpN1CIp+ntONPjrhIfh4YjELa+LTV3ElboQx8wh/H4FXzoz7haomDKiOiIIvWV54 eFsIOG8FWvw9lqhVVNYir3u1bk0Nj/4s1ecZnNMOs7/QuQYTrzcYAITAGORv82PWmsp59kwPvc+4 QA69xLOWV/gt02Y0axFF3yNkb0BFJLnTMge9oQ4U8g3UgEjV5avV0pshdeSUahctsDknUtnoJ5JO W0/leKsHpJ0CFQxf1ge9sHd1FOOMf7zonsKfm1L+pNYBVUC2nUb4jT2tvVuvL7l76jn8JusgXPRa w34y33st9/nZ75xT2Ym7T9+FpyUnxdqDKz6wIzRzA/U8h08eP0+q0Fxtiz6TEUc9/vHDPH4h+FOs neUWg7pLn2x0B93MY76WcnKERaVjXGxpg40x2cB9oEaj6zl6p1B4vqWao46cKDsqBfUa1C82AdyO qvseVWrE6zJE7GPwRybGJl6IdNTo6yv/Uw81WlePhv3qpFY7kaNwuRCHno7yNfVRKpRIpUcVMlt1 Jah/mYm8DIpTmB5I3QY/pyKTE48LuWy42qblCXft/MkKlBJsIveLwDo3//nt/3moHkWvOSojTG5g qOoII1b+djH3jAqhgcqZk4QIhiso1KZ04pY3WbtcYFcoXScQwMtV/X4AxNDwJoKsRHyR+7AFcSfx 6F6MLevVSc+wrZFnneBgfgEw8aXOe8y9EC/idh6G7HPD7QupNtKl+btMNRh3ceMe8bMHKskCntRt eRqjkHov8rrS90kMqSEGsAkYa57lg4oDVCFQpsLDNLoxcE/upQHHdkJpDdk/XuMZ7MySH0sIhvR0 iYIzRYM2fJUNpO2Ocb2la1vjzWtuHU2flXk6hjY4vUGpIGrFiR+ZWDQJDwM5uTODsQxWnhk/KXm0 YGnjqb0QhyJe8d6P015u8PNQRrvSvC7wnM1OGpzhFfZhpx9+NBQyZX/ksBuaClc5Ccmn20F7FMUi 257sXK1yE8rweCJVnFoyIdG9p24CxDngD2Ya9maj1h9WCkw9YEFPxjeF3ZHO2QQ0AWD/bJThiBDH 88tDgsjRu5B6VXmSRff+92JrSmEMf8CMIrQ5SUqm9vgjzmVhhTXdxqBsbUGpFeNK/AuNqANd0Upe oE1TjIM5Vk5eo88jJWFa7udPOJBlWzSvTK2JSU6ZWlNZypItkuBubp9PDfdoO3uDMHEp+6rRiypd Kec0yA1foy+Lbt2XJfD9ixaK3wtsTPyl+/BEVA/gyMpeOXqoNo6lFVDeo9R7RfUQlpO1hHKeQj55 8Ay4h/FLobw00GBdDzgiB9ES1wXjhfJWa1PC1TP0/UdXpCnm1ILaZI4NGjtPBxZ9s21VJ6LnpFBj UQrLKawPcrgfu4tC4jHB0f0oCAkx3XT/4q6cGXH3De36z1z3See0MDtAPkrjul1r1QussnncRVIL lMzwZjecUvh+ydYE3wEFe5RDG6/8AF3bPGFOZop1iaateBPDldUYJ95EHmmC5hha92n88cUNJ+Kp PbIrfrgPZ0CMTACVUsUtyNV2Zt8lHmQqrhgvY4vSpOLvsC6rXTYx1I3F/6t0e/uCXMW3E0rJyQ86 oJiInJWgg2F10MvbaOlrP/idQzEznbKIOBaza2mIKSEfYKGtpyAnZIwhtkkNHXWqy6ng5ASmH+4J RMtaXdH3LN1VwMwppG7gPoL0MXMNzNYjnzFrne1e4wLHTW+spBYUffEdrsshCAOpMAODQblnF0+R Mx385To0Z5qGCrprcq9lSs2lBrUuPo3+4uRhR+czq9ENKwdcQnuTHaAU/emki8ZMjlo5iwxpcRFy HJ5sMLSsWqCcqkUH5njuuLY722gg5AAPf8KNSjBxlNSW66Cni/I9Dm+YJWeNp1j852j6aMy4aYLq QA07FubUQsZ+lszXmvVh7j6Pz+B+pMwLiEV+FYwQafeLG/ml72imGiql5HZAIUW1qQqZNL04aqmU OObAcZRLrI9uJI103ap3m2GlwRHHKQiO07mZuTuL3xV7U+5cBjzQRT2qTY5Znuag4YfH/qsT+QfY 2eurWLhZazUazWuibROVG1eWRO6KfiVC7tavzSf6Y2PbNDy6Hb7kqxNjFbj05xTj3F6dDPl/UUb4 l4dKeR/MnyMJxp5Ehf+n162XKCntWTR34stcexsfNKykEcnYyWe+4SvUPHC5BFCXsEm4YonNMJyA 6yFoRi1q3TByj6b1WI4kmMHFZnKYqpuT065cMbVmYIORcqMx3pR3Iuaab9rTHAyxuM6KITlHbVbI el1Gcq4EcGiAAkD//AcumtHDvTbMXWI5gRgIWZbNpCVEW5AciIkWj1P6g64xc8UIE4BQibnJw60+ WsD0WpvCKp10N4/MIshuPCUOgjBCDA5JQC4DRbUGxeYsNYacKbNwJ2iMhoouaBqSq4CKOihuT2pe qG8PZbkfKPHRG8DENYrr/nZsKwjsJ7hayfZRzFYbVX93gxPuAEwLxIPjrsUc/4d9lNEZ79spOhvB gwmpJaEuoMJpDcEg4zAx8yiCo/EomSLoKONB2UvQUlY2HEpMBZdtPOhYa0MBZTAGWDld4ZC7nIGy XZUK1/lvLviknhFSTThim17HfxnjgPLulKLStHZqFcIlofghmW73Vo7DCXeYKdsmBJHHEvmnrGLk /fHvRi699YV0oyB1QzlCt1a9PWhwl1hWUdLF3d1fN/7xYzxXkHgu3Zr9IvPyOnnioFpjDBtFyHOp TdSvih/4j+Qqymal0MBL9dOzXfcBQQ0US8ifQS2M78v5q0SqoryJYYOF44An+JjLFiWO8WfPdr/S 7zYoZCZVwGe7JV+i5/pV8tR5kIRIsEpYwj2P/LtFyuQDZqY4MmTeSyz9xXzgfd39iAGQUc/nf/ey lvUVUSo/oHoc3urkPTDoa7QleOAfCNK1RzMbrs8SrnznsNCPK+i8dUcW+jLcHoeVAVNK1jp60Zim OKKwp7Oy40RkWs3iPASpPvb1KPQ5uDbGD3MDzu97/IcZiPsQqVMnxD9XJ+aLJlQhCfEn5xYV54Hv 61Gn62Hx4mfT+tUynFnS3Ymewc9PcfpxNbYmhvge+zYxycrn0b9PvkQmN/7iPo1UuQ/evuSg00OX oNmp6IGIbgh5qk7h3kzEGzSGwxt3P+jxTscZP3+PxzffoK49PuOnymnMzFkql+3mMBlLN/vNOvI2 UZfoLtjAsVDZrTf6l6Tn6g3R45d6GBn+V2w4MQ+CpX91fk6zspGCgYL3XlpmMH3petHRKRgM4czk 6JRl4Jx55q8rlKMRlSlzdEqC6HHZbNQvC1z7uUMNZ1r/equF8ZuxXd7LRu5LpfyZNX3RRNFnYJrs WFPMSqZStROeQ4SucJxrltB5VXIUMnVer1XF4ER8KoIfFv00dHLqOx8GWKq7RTgqSg0tO0+KWWgx WNPr58Epn3ZlMCw54yn1HO0u37q8bl9f17VUfGswsd58CbgV/jDo8CKsrc5dCpHKzS76eneYjTcg n0QLlbkaRA7jZuw1JGdGvZ6YEki4OY1qpdXs6zOgeleV9OFQ6yZJW1a0HACJZ4F7hn90g+pTgcp8 kGzGSJO5aHmL0IVq+LMJ3Jf1Zrs2LJvbpEiSIVP7/D+//Y8SDxolB44SXsheeCmFo0M5CLBnPNmp YEodwXTPn9u3d2YmZb1VaV+Ct1wu3bhDVyBNY2QdfbXWaMy3OxrIA8N8tZzHblLkf377b3+FoFif d0xPgpTLaiVqzQaZAF6O4TPqJdULavD27vzd3R3ltkxvauBs5EhK73YsusNWtzfUUvStORb5BOoZ QrGOaktzJd4Yiq+JigcaRYBsE4r1iNHw9v2PJAZ+gHbYVPxAf5/dv5cVYfIjvmks0FPAl5/V/QJV Ma/SsDkInHEhiRE4MXmke/2tik+5dG9H+6VZmlZtdXEPhuzdrWQdvCAfpEK0gCeKER2KRxNkZuoG TcRTKvkERyMgSM1Gx3jD3xDVSNYMoVJMlqWDnHpR+T+qfEjy0riIEnkUIh8uTMwflGyBMbGl0Txp A62tyi6Fs1qM8CfOHzPa+Ju+iw95VEQvx4+hwS1uDdeTRxYUJVCRcCfwj3FbnklHO/BWY9nNR53L sKUI2hKj+xj/4HYFUP+G5fwl1V+vNNvVwbd6dgsr4ekukqIeUSEclfkyHbvbu78l8htEmsq3eSAC CRqhyEuuh8066SDO1iulQ1jp2IWRY3J5hd1Tqg1brDBuAP9KFpJt5ji71LR+a12PdlcPnCjuPlNO 8YsbYJTzJGamb6r92mW9wKz8dCUrgFltdw/GH00VGt+z5W1+r9WOwJB2j1oKgEJM2igBXmzrlOWg mYVkPemGBPoqiagtAXX1r5vD6/Ih3LBOerwfP7vIQ4ONUqUe0YpYwxvPrSCpxrVbTVh/rdLut3rF BbQ65pj6pKsYHYlbDwMNPiFGUwXqLCJgqoPhc+YuA7Rbtzl0DzGfEAiUbiWF9eq9HAZi2K40LsJq YAWJ7s7G1SuN5kWYTz8G+3+RFLCvXHLn1hX/+i9jsfxHN8ee795eRS5Wx+fINz4svvEOKlfrG2cV f0D7YjIjWUYkcWRivP18vuS+MOU9U0nRI9Jd08Sin2yMNcckD9FzHbgnM54CAkyiC5zhVhKuM5MJ xXlC+1KqOzy8F+iqL35AlHwqfnJQ9gGSBRB2PKkfDQf9z4CpgwHYRFLG+S4mUan5+laz0u2GCEo0 PruotYeNeOlHY9Cq9aRL/FVKP742ah3RttqBkwctsvBiNsMjkdi6/cjL3L/7qde91YfLz3W6kLuJ G++ES6+eQrkezY5DJGsuDfHTD2foxO34wFEp7HXhuC4yw8JGs1m5LDDm1EGYMjEfTdtdZickD2k3 Y3ouKbWF37Csu0/o53Koo/QzF7azOzNmjotpDmPhb2Cuyn7eqEh86qL1MCoyUZsdocFQtLywPh3c /nYk2QMuB3rueHA5KPEDCEFWpKre/9nOWq3dbBe51/epylCDxoCeHuRgzeGkwlFFFutPAeEX6G/e v9Cpqqij1R7Ua1uInGPeiL9x6I5WvuDla3uC1DMLUCB2mzozoKW4MBaonA/IzSbw1DaWSNoGa8rb SleLUTJKZ0lIFQ4Zp26XHoIabk4FvxwjbOh6NsyzZ8woz8X5rxeEwaKxEHKwen4rqj2QDf4uTdYo VwZXD1OfA+GZFmIlzNjApfB96hth2nEfLtXrT5BppFWpDCrN6paNFaXAx945gm5H0M17dVJtMWqL 4gATg9XrTVJt9MeHlY0XjOBHAhxUAdNnO4TtC5zYS+gdCQPzaad93b2EVvZc5L8DdGt/46DbuyVU d9/y4bfRiLwsH+3wkKXOH7+/qOWFiBLGImIXLlrtZj20GM9iF/Z19MqtOPZy9+TzMEcHDgr346c8 sIPmM/qMxB2LRJitAtWvqzD3te70gJUm3JLDTzUg5GHJ0Way5iFLX/QuWtVq3gqGQgkwiYCs5njS R0mjfpTRPsS9Ng1wm1QlC1EyLVRcu2snTIKHQS7PmIRUUF9ZJq6N0LGJIoTDFQnd8fAzdvIQxQLx XqzICcEXN+qzpki56KH3EvdQw6SesGmo/AfqI1N7dvvtYa+akyNSNJWxQ3vGmEiG8FcLjoTxOCYY hTCVIwUpatXEIhALESIjnCXz406Mzctw7KskItGHZ567WqIfK6FurJzxWuLkYSPc6cDzoLICdFJ4 dUKg/l1geDocieqyUj/5DsNTDvg6NGTzNM9zGDgTFZQdzFPYIX+EqnC7Z0AuCwtePplw4t7SoDgC cbSYxctHEn4Nmq53u2U15jueTJecGka3ooWreAlnSr0SIlHMBPNde0WVm378UaViS+qBaemKhAvo clythNWvx3Dh2XCGfbnNnbvAXKL/i7ibm2vUeZlczMLOECkmaHLOiJDati0e1w0Bwx9ToJSwmZBC ZIFA7zCWS9hIKhHRzhW/R06VLB/GZaY7JJKPNJIQC1O26PUVR/2Xl9V6tXoq+N+aBGX5v+v6N6AW MGzMlc286ctU3kL3+u52yNitpHYqdiTbHe7Vu4Z3aMjqmBALpgnB4q5/+1LQBHIsTF/cQIkOWoIz QItKNvqJ+7dDedTwGSSN0Dw40zVAE5nqIC8PuSSuQV+139b4NT92Bq9PBbc9hZxIQJz3hRUTOeVz SIrpQG+DcoqnJ//kZ0slUQ9wJVaw+rSVvAl4Gha6FsXMYqrOUs84RWfF3znqrLLrrC9ueYpEDrFo kj4mOZfc3Ybi4WGt1b6I9/MqT213J3S/Y+cEyzskLOdJ64XPBgnlXH3nZprYxtSFbqOAci5zh2OL vvhwFci1lVaArPCjgemwcC3gAki3F3WGW4eDsqlotL+dHouSGHwLgz7CLwpuakGOAVKtEwzkfC1u pmSxcDm6ZOJ5H5BmCN3+5BIPSmjCjT5FuLihLZWzQbDD+MtGT+zJBsl+cjPgrk1yhEBxpyHK9Yi/ c3Qnyu5O7EiuqlJn5A8m5tRyLIwB2oQzZ9CvFVXybkjeYOc3ecIOx71gt/5JOuGgNMjWFnBAiQAk mK/n1Ck+cF1EuiquvBncq8gPQx5ooBjUyUuhYmgoHx40A2NEM6YOVx7IFidXd1jSgDpR017SfDAw s5AncFznTO69psCGwzvEDEQyzP+1N76VB1yL24+jZfE/ReZ/1gjYhkXhEo3SWxYNrhGuBjgKMBnU AiEe3ABmiSlRfrCago4oQSsG2AjepnfIWV263F8L/rB8wcvTrmG3fNW67ctK+0TZpaPnUn75eouE 2NORsFHHozWstXt5a11KAj0mTU/KevVLkhZb6ofQ+bc1Q3Rrrj4m111Ok9u5El2E3NLh0mOx0NIq JGOzzjsLtKHdIJqnLoPoSz/jzqOkIeUrkuuRI5qLa76ozY2/c9SJ5deJQHst076ikYwTE6mGSXaT k163dVHpHhZt42flbSjen2wxF3EycqRTdjNGL+uVar129CIOx0vVJ2arlmkqe5hT0LEvKDkL2WGG WxYi8kUEjIq51+IFWoeA9kNFuGaOgvW4BEW1MdzT2jAcO3DUxuXXxpKNjNHtyPiiDSWj+wTpi0cw nrhcG1jCQvhoTgR4f+Kia6bwTWSBR4+WuyI6mRu4IDtwMkDi/0vTxWhn7l6p8sacLlb6DV+IXpGc BRoOrQZy4ur4wAzCmidUj4vjUVAPOVSXoRTcBha/pNhBiiA6emb0zIWzunHx4sj9qEpmDc9z1xBs vIhp0iiigvdhLoEZc0CP7qqWTwgys9k4to/KKfJVpzLptcbH6Ke4N6tP7gsBkLJtIyqRcVVgAjMx XTljYnOhj1eU4pJwdUh9UJCw1OEQZbqrtUq3GQ7xiAp1/J2j9i2/9tWW/QYsd+BJCr02hWfN5oFY 2lC6lMaA2qW3SY1KlhU0te9SLg0J0hzhVVxwjiL1LejJd9BwYPSR3MRMua80KCdMYOnZsoOsu7Kh LUl94Xt4731vELaWNgRArI1YAszSl4xZ8Xi4AnA4qs6a1WoTRfnlxEJ2cCDumZiAhxfhQYA6Rw3F 488iVcFfVFvNQcjRjZ7G+DtHBV96BZ8uP11n4mFw+t3Ktq1H4r4lgcPY+anXLgd5W5sWDSDu3CCt stD5k5vuNXtbVNZFZm3tIWuPUMMzl0jnyk/hUF2/G0L14IsYaTFH1z58lljzcLr4i7I2aEz9Qsh1 M6C70D/EAYUoJCiPkI7BxzlTDIWGSwXyu/jR8RyzXAnehJvmE08Zl8aPzthtw/ucAcJvEt2Y0jrG BDOVUNWAC6xVU38qWEJCccYjOKVBlq366Vr4/hh8Fu4XwfeGWOij7sIjF0J8bKbSypsgu+7nMeOY aEqioKUjQvuPv3NUHAeqOBTn5R0XxUFoZMCDaBlyt6SYGWkIOkZjtH4iSy0hIgblQcKHK7DJVDUX vdawn3dCbOFUDXF+kor0oLwOKCfC9LCNaDiuB4CFUxxOBWk93mNWk0YYgxKTHxUS6BlCshHOf3jz M+lgzBYB+oKvLeivlLpLlFv8LEmYgbdReI5ufkdlKKzDcAGpRilE4TkkXK2hbzIcxQAnKTngQN43 tLVCgFhpc4EC7gf3hWVQ36uIMzpz0T7/1xU6/bBk07LBJeUZLzTPiIavWAuuduF6Kmrwk9Mzi6vR qGcWf+eoYA9UwQ48a4z0J8oXid9Mc9OUW2Li4GmRg3hBokjgE+oGQVF2UWw51VHHSvaZS13owfLd oZpWcqbTmBxWzzJec4Zc4dykqxjyg5oNnVGH+IkjtDObCBruLivUhDH2XGgnrnYniFyR3dmPlbly JGvuqdqPKIraPf5GpEz3ZRNsTPIs+kAlDuGQrNGXoCDsMzW1U1EOCI8u2k4bgeu9FD8zasO2F2GH ktLXAm4izQsFgmi70FtkpUN/YQtMI4CSthdg4o+9Pik1dQUQOuRQNCrj5qtTY8YcyEbcSh7t5yHj jDcz17sSH8wZRIPUH+STIl2WKnLbeP4YZApeXDTWZfeP3UzTO+U+AZysVt9+ybJLvO0JOX/4+mgD p1cG4OoERDqlSMUZ6tejhMq2E3upPd96eKnWPtrro6RuzWs5NvUbtjTkZZD7AjgO3iyNgMA8oqmC 1X7p3n4v/RYU45EpwkcQLYY4XM7cU7dXqaNTVwpoFX/nGFNtT1xJy4Jla7sr8Qv65Eh5WRhU1geB oogcLjGVZUXTSAQXxLV2InsEhke30T6s7NG1xGkA1aEOUqWQDFAJxmjloWgL3NCCbSdaV4CVgBHg DJFz1LklftH3fUOhMtzMKabMSKBIN8foBbt9tON5rO0qb9HaS9LVr+uNXjuvUD5HW+0PK3NizUwv Jg2Jk4Xu8M1h3kUUDexNz6s9TaSV1DMBBICTDe8XPXAQggHJnyOGI2XJE323CgDONVpsrcASibrf lBaDB24gMQDyExvuqGlnw84Jq5FJiDJUDPdyiSviVOWxmxl60ay02887NLBQQhox5nHloTodl1Iy Mzq77BwbX8qF7qg5vxLb1BtNY0f5Kc9sXy3R/pCjYO5j4dp4nQJfpIzxH3ICi0rW4VWQbYlqm1DO hxploclrnpUeLJZn+GCBgvHMURUlZs/M6RS+HqbKvRQ9sBAM8VYO/5XF6baFHls0s+KM/2tsLI2R JZtPcr5uMhFTwln4Ra5TJbRFZdgUoLdF7xwTlVs+TceYEjyN8E19ElLIHudLMcQb5kfMFaX+LZy2 G2EQ7dxY2acMQ8cIFOCFm7jYZOMYCwwX0hcbmWODcpMUUPrImShiw2qJjKNcOTJ0Ds3kUPwLMC/u VEY6smw6HFifT4Cl/gntGeO9rIXiPWRF9SgQAp8ST5fzipQk5Kvj5OI/kQ7tvqfYFplPQJyJ6t2E wzSsN+rDy8MKReBooHae6Dj8HPS4Fei2wHNtG3MPdSc/FcnpesBAIgOyZ+z2RXwRg3yQlpXfA/IH KiH6gq7Ym2FPBBsF34YiFwdPHRHhhBg+/PMkonIft/Qa+De/riyPqTZ52NMXg0b7OpUjE3/nCDds PZRDNT1ogWiA1RonSCMcTkvTHqb9uUI2EWEERxKSBUxamqrCTvXBxnt57PMB4L0UP+VZ6mGKAqAl SqNofjf0rBjb7moiBqSRYcjJEVgt2E1hHQ3WZCQAlckX6oJNiJ6cykXX0PJElWCmbiwuVTyVxswp AUl/srhx5y+Vz7mNgM0ckW61/1HlI2y/Bd30gwtDeMzpQHNh/BVjc+ur3TlVmqzxwQK/F/7EN6Hz 0alB8qs56jTGxsRcWIYkJKuGisjZcJMawpAeLXNNuDz5X+Tzsd8LCAhzA4gvBzoKPsAFHp7hoFgY lGzl38ObewMWAtx3fP/Jm+zMMf6EBtM0WAA5WxAUVh71g4QSoHQuBwY8nQDNznEPuC/+BieMqVsE PH99Gwx+JzcwVlNyXav2UeJ+SNDCtqd1jIm+AlUdJA6EKjwI1PUwvh3utYzaUJeT3IxTGd6MTJRC WiFDGE8X+wwnGi35J6cC9GE0OfLxAiauWAhFYRdUeAWHnIbGUo6Gf5NUvBICuZm0dWwZ6B3XoYpJ 5HhYqKTBQKHQHAAl3XDYltsK8mCLMtWj0bIIu10lgdQ7R89967mXNFGYDt+DtuTMMHZEaieSSFTl ujMnqTG2tHYSaUSY3P1PzRVSoSv4mbAEXATCkSbUDdV9QNLBmpLhp8QKLEgwvjMmFwhZcFD2AmE6 k7PAPcM/eAFHxOBSXgXgcGQsRnChJ4QfyF74kU/htl0APKBcr+zAOlO3FbZ5jQD4OMcoD96WsySm BaYC8ErzpRySxqDabYaB7/GQHOgh6U7AP/1MyVi/Ueu1DgupuoGZkS1dYaHgmMDFgCVymHi7TYdR CIEygjUZNGCP5Hzo0Xpk4hREyP0nFEOBbRZDmh7hf8lQOOZ1DCr1VmVQUq+jw30TEuFvbHkHKDXk Y1JpYDCnDtPYcpIIBoJ9gphlc0d2RmcuQi7obVLpNJYu8aBSIaMoJKIVMjVwKPWD7GAg318YclXq tae7JSw0qE9imBzWnb0FeAEIdUhayA+OixmgDvgAukZPeeRwh5nPKmUuIV6xc3hZq/QvyjqnroMM S9biBheNWq2si9shH3L3s1Zd7i2VoJ+O5BFIcnNHFvCUPtNRTVjq3e7IZKosBVMJTdIBWRt9iOoP Kg97nrXqy4vKsLwtCpSH+O1tLALgRxgxgnBotBogOk9XpG2rbWl6m/kxoAQsPrikgJuQPYrOIRXx sc1hkBtHexJ59EOk9GadjhYy0vV+ScOGHSbvligDssukA64TYjLk/RFiwR+Ktjtj12lbcSYBwUSQ lQpzJHiGknarmHPawEQAQqV21TtH7KP02EfnX6q8n+EycrGpuSmNJHbj3U512yqisyoYW5bNBlBa zOsZExhNV0AMx40njazDWqnVm72yToLsILrlLjhIAuhhsuLFXXK95UybdChid1aLEaBVBFMAfyaZ kUa/1+5fHliksca0EwBbyQ3VGpHAh0O0NhKVz1p1qX2KTq2SXFtJj+h3L4XEp5EWmc2QXYSXwPCa apUgsVu4jsQaIZ0sRxYzpoJMJDq50MtgJJH2Tj6TQ5dy+E4+GavTaCczirqjdJjkQymVoPx/AQAA AP//7FbdatswFH6Vgy9GB6VNnF+yJpAmbRlsJSS9H7ItxyK2ZCS5afs0e5Y+2c6R7S7uMthFmq0w Xxjp/EjnT+d8I73Qk4vtyE5OwSiwCbOw5RAyCYZzEDGSuMaFASEjziOIC00k2Cq9KeUlkg1YBQGH SEkUlqQFn6/urs8uzulw+uM9+M/pthxwa0S0HHut1nTWbw/6Xk2a85gVqSVOr9/qdIY1Z7FDcoeU lpuchUKuUZ3Fluux1+63SCUVko89v9OrN8siRQKzXzgz1junIyrn9bWS1tAJJhRi7M1YKgItSJFk p0awsXcnMm7glm9hqTImiZlMpWmKh+ZXQXdTqFKlUeWepeQGfaUJ5qmm+n5NmZEtTrKkUfDIWQpf 6bTL2fGsD5wPwcwczhesCnjI0hGlD9OSa264vufepH8GjZpB3zEav6uWBSb8pYSOm9K3CcpkVWQZ 04/wgWX5J6y3Bwsry3PzPoJykDqnjvH8/aTdgkzIjw3H93aQZp9Y/u8gT/9cBzlYXZw0yuFVc5j7 g/Zl1ztuHziYa7fKJjjJXjv4Pr3Z39yBwMQpaIQXqrCgEF7gWP2DJz5odWe9OQ1dNwnKtl+luybu vPumuEMOO7VRDdG3RQ5/DxwESm1whGxWlmlEcyMRISii0EmW4aj9dqMuWbgpwUYteyWjF0kc8nWb NTy0i8b8bUZ2uS8RK1SiqdwfdKbdjnuN+XpFOGeLhvh+1+GzBNe9Ia4dpsjXXxndY1WO9G4posU6 wZPaQwRLyAuUtSr7yU55vMNNOIsI/g18Jxwr5dBgtV0X1m2r6/DNEsaqwAfJOCsiFd5oQZEg9LgQ NkQrO4gny5CU0XDRCVT06BaoUmRc2skPAAAA//8DAFBLAwQUAAYACAAAACEAIVqihCEHAADbHQAA FQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezYDbRpo9gt6nG8 O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH1jv7e2/e+70/ 82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvOFbyuYpIQBPKp XMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpbwyENCeprlcFG obzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcsbFxZwOu5EFNz ZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPRXa23Cp0VkP05 q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1ccvAFZ/MoMvnt5 baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgCQAMZVjRFapKR IQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f//H4wYPj+z9Y RY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+/uUnv3370APf FHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+uRVwG7whoHz7g tfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1IlvZ5xB36Q+le2Y OGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+AyHeDjc7d1CL M5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05EpPTJ3BLgbyXo 16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9DHHA6dxw36HE Cffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFVPv/qkcfuN7Vl bwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkXhgatt0x2o222 3cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJejDPYtNcDrWQk c9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSCs062dDlXCr69 zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzbGBVhMVH4e0KU e20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YTS6u1xVJ02AzW lheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZkGoLy9jG0LzK Q8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE9OLoEA3YWOxh CD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbzVDEPfPPabpw7 vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6Fl4D+XC/bP4X 5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SAsL7ugSu6Bwco hlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf36epn5Y14sUZW HdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPrHxUhsx8r9ILa 53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtbdpZ4n5PschPl TufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydTB9muMNk14NEk /8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1LIUXTxcuJczM 0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl6ujVlOVMAXmz iQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAOR/j+4qBgAAxhQAABEAAAB3 b3JkL3NldHRpbmdzLnhtbJxY25LjthF9T1X+QaXnzAp3kCrPukCQTOLajbcs+wMgCTPDLG9FUqOd fH2akmjt2icuV55E9UGfBrobDaC/+/5LU69e4zBWXfu45u/YehXbQ3es2ufH9S8/lw/JejVOoT2G umvj4/otjuvv3//1L9+dt2OcJho2roiiHbfd4/o0tNvx8BKbMD401WHoxu5pejh0zbZ7eqoO8faz vmkMj+uXaeq3m81N6V3Xx5bYnrqhCdP4rhueN1fNvDucmthOG8GY2QyxDhNNeHyp+nFha/5fNjL1 spC8/tEiXpt6GXfm7I9G3pZ77objrxp/ZnqzQj90hziO5Nmmvi63CVW70Iz1n+G5+vNDtR/C8PYV yXsK23+6rlmdt30cDuRQirlm680MkOHuaTeFKRI89rGuL0lwqGMg8+ft8xCaJlDQrpKLzjSEw+ef 4ms15894ER3jUzjV089hv5u6nvReA83ZipuVw0sgnSkOuz4cyIDv2mno6mXcsftXN/mu6QfywXVe lD99mOYZnsZYFh/CW3eayNTmvL1DlMDHcR4zf/zUddNCyJjzhltz5ZrRO8IIdCVEhNReQUSrxOYQ MaL0GUSszOxt/b+ZAXElGHGiNClkK5jmDiFcMKclRKTNBfQBT3ghMVsuUgl9IJjNjUd2hJZlBtmE 1bq0UCcRTgqIpJqmDRFnU4bZCpVJuFJRSpNqxCaZ0gn0tWTa8gLqSM4s9I5UUjsYU2mMtTBDJHlH wMhJx7Icz8BrlkAfyJwphu3kMtPQB4ozo2FeK2mNgN5RSlkHZ6CU5gyzac1SODeVWWGgD1TBnYb5 pgoj8D7VnOs8QZHT3PAMxkdLkRbQjlYiL7GOYVJiO0aXGiMpF0vV/bYe6MwIzdGsDbMp3llGytTB +BhpC4URTZUPZpUxRuP4GCudgvGhrOYF3AsmUU7DaBvHXCLgSnOWO8yWW8YxW6GshPlmSmFxVbZM eZzxVnAlYbStMT6FfrPWFiWsO9arxMOaaMm+hfvHevIPZstVlmC2QgoHvWNLLiTMg4SpDO+ShGq8 xzrc6AL6OhG2VDByiWIeV/JEM2uxHcMTvOsTYzU+sxLLdAb3XJJS6YV+Sxz3+FxInOU51vGmzGGG JJSJGawhSUlXB5jxdJTRYY/2AiFOwQxJuSpzaCcVLE84ZJOM45M2lZqmAHW0kilcaWqNd3g9CStx HU0zm2WwhqQ5nZswD1K6awgYU8dV4WEmOrpuWGjHUbFKMVtqdQln4DyTHHrnf98tXW5LD6PgSuM8 ZMsEz3F8Mqk8rhSZkQbvYEIcPmWyVBYe3gKyzFiciZkXTsD1zAiuO16pHO9tb6hUQB94y4oSxtQn huMoeGcSBvepL6iQw5pIiNKwVvlSphrW+JxuDinMqlxYnkG2XAmP7/G5EbnFdix3BnonTwzVMbRP 80yXGfRb7m2ewsgVjPkC5kHBRI59UDBpGJx1oeguBndWkSiBc6fIFJdwPUXJC3xqlpxpBytfKYzF Fbak4oL3Nj0KON4LJV0Q8NuszFSRwfiUXutrVabX6Xy1ozdps507DJ+G5aukF++quT6LfWj2QxVW H+ceBL1pm+1++JxV7YLvI/VC4tfI7rRfwIeHKzA2oa5LelUvALUfrsixGvs8Pl2I649heL4zX0p6 sx2glN7wP/zKNrcJ4vD3oTv1V9bzEPp/tkcSLwa5Uje+qp0+VM0iH0/73aLVUiviK+jUHn98HWbC zd1B5+1E3aM4e+hDaJ+Xl3psH37ZzS2IGMbJjVV4XP87PPzwadamJkA97OamU/wY+p46CjRu/8wf 13X1/DLxWW2if8cwfL782T+LGyYuGP2bscufcJgXS6NvH/OA6yeNun3cZXKRybtMLTJ1l+lFpu8y s8jMLHt5o3YMtVs+U3Nn+ZzlT11dd+d4/McifFz/TnR1wqVv4k5Tt/ROPlWH6URNlIuLxpfQR0qE uTFDGdltL4Jbp2ZcvW7jF+oExWM1Ubevr45N+EKNIXbtGNxG15e+yzdjZ6Z5cP+NdHUME0XoUnE2 3yhfeja/mct5e4yHijJ499bs732gd9dl1dU47WJPLaOpG8ghl17S3y5Zc29Avv8vAAAA//8DAFBL AwQUAAYACAAAACEAEuMV1VICAACuGAAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1s7Fldb9sgFH2f tP8Q8b7agPmKmlTrqu5lqqal+wHEJoklbCxD43W/fsTO2sx1t3nKojzwFAIXfOH43HO5vrz6VujJ VtU2N+UMwIsYTFSZmiwv1zPw9f72HQcT62SZSW1KNQOPyoKr+ds3l820UcuFcs5b2olfpbTTegY2 zlXTKLLpRhXSXphKlX5sZepCOv+3XkdmtcpTdWPSh0KVLkJxTKNaaem8B3aTVxbsV2v+ZrXG1FlV m1RZ6x0pdLdeIfMSzL2PWb61+99JM80zv0UsOMcI43Z8abLHm3zrx7ZS+0EQ7awLWX9SK/ezN37q /ZKvNwPd96Z6aXttnDNFr9/7c53Vu2e45zmlP1ngDe33GfDn7xuVTP1Zt+3UaOPPVT4407mhDzwb N3P5i0fj5taHOx8zNWpBaDfdNXtw8AQlnEIa4BjzEhwDjo4dHza5znqYCEJiLjDrONJjA2bJCD5A yp+sAyNaCg8wouuyeyyGeII8GgxyAQNPTs2TITiwgCRBQiQBjnOAI+GYQs64CHCcAxwUC0QZEizA cWo4XhV1gpDnh2CdgPQ0nSTsSaX/nONC/JwBBE3/d00XCBNMaBI0fdQF6Bi575Cm+6xXYMEICVHr 1FFrCA6IBKSUMxhyrJPT41UV4UlMCYtFl2j1VCTcDDsRPWaA6pjx25thTDlPMKMoxK1ziFsIxjRm kJFQYTyfuMUYiQXHrONIiFu7KvOLyvL/j1v7aLYrN0qtTfP57mNbcM/MnXELuVXv7cKX8bW6zbXy I97+4CvD/AcAAAD//wMAUEsDBBQABgAIAAAAIQCSyLqOTggAAAdBAAAPAAAAd29yZC9zdHlsZXMu eG1szFvbcptIEH3fqv0HinevdYnltStKyte1q3JxIrv2eQQjizJitIBiO1+/PT0wQiCg25CtzUvC MNOnr6exM/3+48sqdH7IOAlUNHWHfwxcR0ae8oPoceo+3F8f/Ok6SSoiX4QqklP3VSbuxw+///b+ +TRJX0OZOCAgSk7jqbtM0/Xp4WHiLeVKJH+otYzg3ULFK5HCY/x4qBaLwJOXytusZJQejgaDyWEs Q5ECeLIM1ombSXumSHtWsb+OlSeTBLRdhUbeSgSR+wHU85V3KRdiE6aJfozv4uwxe8K/rlWUJs7z qUi8ILgHxcHEVRCp+OYsSgIX3kiRpGdJIIovr7I1/X6pNxZf2pNekhYEngd+4B5q0OQnHPshwqk7 epevXGgldtZCET3mazI6eJgVlZm6dmkOcqeuiA9mZ1rYIVqa/12weG3tN7tK7oEgQEhmJqTgPLn4 pLwn6c9SeDF1IS1w8eH2Lg5UHKSvU/fkJFucyVVwE/i+1BmUb4yWgS//XsroIZH+dv3bNeZDJtFT mygFP0yOMWRh4l+9eHKt8wHwIqHD8UUfCLXYpICDCm2CrTZmoYSKi//kkEPj7b0oSyl0zjuofyMQ Wr3pDDTSFhUNQLksXcfdRbzrLuKou4hJdxHH3UUA03WNiMmNQlbSg5oqzyRfMSfGJw0pq09Usqj1 RCVpWk9UcqT1RCUlWk9UMqD1RCXgrScq8W09UQln4wlPIHGVs2iM3iAV9n2QhlKfbySgYUeqy5qC cydi8RiL9dLRXbCsdhNZzjbzlKYq0unbyXKWxip6bPXIyJTBmzn5arVeiiSAz48W1486uv5ezEPp /BUHfivUkUm+ik34CbG3hd2FwpNLFfoydu7li4ko4/wX5czWwoMu2Kpcx7B+Ch6XqTNbYsttBZvU OL3eE0b+pyBBHzQW06TGlDbhpBhOavKyXvhn6QebVe4awtfIxPA5I8wlCFSx2UXvdIiqRdxqhQ4A xQTTLvgmoHyC/qa58OXrGFP0N63ojfIJ+pvG9Ub5mB/N8WUzzaWInxxSeR2za/dChSpebMK8Blrp 4ZhdwRaCZgK7iK18Ekkcsyt4hz6dM8+Dn9woecqOxZZHGSjscBgULDa6LeyglGhvyLCIHaAS1oiB 1Y1rGUBs0v0ufwT6t0TcZoAsbb81W8t5XOMBaEGkb+hvG5W2f0OPajiPinIbwa9LEunQ0MY1lUdF y/LJ9DtGjLs1PgZQtw7IAOrWChlANflR/81jeyIdpHtzZGCxadl2MUw7MjMfs5nZAvFaQE99k/D9 VVO99blQ7ZsEFHaAqn2TgMKOTqmX2b5JwOqtbxKwarpGfYyKnMoxit03i0D2S4BgUT/kTQDqh7wJ QP2QNwGoO3m3g/RH3gQsNjdYTi2SNwEIt3B+1LdARfImALG5wbBd9jujvO+hlOYfbnsgbwIKO0BV 8iagsKNTR94ELNzCyYQSlqU6AlY/5E0A6oe8CUD9kDcBqB/yJgD1Q94EoO7k3Q7SH3kTsNjcYDm1 SN4EIDY9WKAieROAcAuHG/aSN1b9LydvAgo7QFXyJqCwo1MiVPuRSsBiB6iEZcmbgIVbOMmQYWFy c4zqh7wJFvVD3gSgfsibANQPeROAupN3O0h/5E3AYnOD5dQieROA2PRggYrkTQBic8Ne8sZi/OXk TUBhB6hK3gQUdnRKhGp5joDFDlAJy5I3AQvzpTN5E4Bwy1uBOBb1Q94Ei/ohbwJQP+RNAOpO3u0g /ZE3AYvNDZZTi+RNAGLTgwUqkjcBiM0Ne8kba+SXkzcBhR2gKnkTUNjRKRGqJW8CFjtAJSxLdQSs fsibAISJ2Zm8CUC45Q1AWEWcMPVD3gSL+iFvAlB38m4H6Y+8CVhsbrCcWiRvAhCbHixQkbwJQGxu 0Pds4b4o+XrqsCYJqPcM8lsNZMBRTZCogJmB3+VCxjB2JNtvh3QEzC1kINakB9XEc6WeHNrF7nFN gpChgnkYKLzS/Yq3dAqDCOPjhkmC+68Xzo0ZgKmcw5TavXkDM0bFcSGcadKDQ6Bn+rqGkZ11frNc S4NRIj2ElY0A4dDYLQwEZWM9+rCe84GNOP6ULeP/22ao+G8YUPPzPYPB1WB0eXSVzTuhyKoS3hK0 8FIZNyiRXYW3t5PwInxZpZr78qjWdlgjVy67N7/9ujL7dm5vwhL4sEbvVN8Rb9AZ75A3es/BLSbe VQVhbAtVatPQ3rfC3ek8vIu1Z+Aft5EOBczo4f+tmZD7L8KIhfcXMgw/C7Nbreu3hnKRmrfDAfbJ kqi5SlO1qj8f4zVy1GSfAHBxURnzqI2o9320Wc1lnN2Ar01c3V9wXm03cc2NWBNuW3mgPeY11ev1 uu3ks7dJwDU4rlcuLLFeh/LAUxFMdabSP0jgTr+sqLt/Fyo/FzCx91UP4KHme2sEN+7W5NnFZHg8 YdRkgw3AYauqzmb1P9XR0tUNEFscBtFTxZPbNzzN6itz9wO40dXZtOfzqaevTechG8Cf6+uMAPJF PSQLxALiIMdgGrapDnYI3PpA572lyoof8Ktr+3qfM4rkXjUfbn7ioXra36bY8ynMsyLnm4kVMHIu YdQYms9wgLRkHs82qdIFALZndSIW0BLsLnwqbTIeyuSjo8BfO4PCU/c+WMEgNKDi+G/+jOoXxnsH xqDkZ2G8F9faI0Ct9mQNZFstlWx5XxD6rOf9eXIuwlCpCGeQys00e2cGlPapV8wRXW95+haEXkBn z5L7zTwLId35ojg/GV9dHBmpdTEXS7USxaDbBS+BFDBPpRwYIiNCsy/kgFnrLwfKrmnyubN1Hpnn a8LADMH/z995r00+/AsAAP//AwBQSwMEFAAGAAgAAAAhABEr3gL1AgAAPAUAABMACAFkb2NQcm9w cy9jdXN0b20ueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtJTLr5paFIfn Tfo/GEb3hli2vDnR06g8RAQRRcSJQd7IY8tTae7/fj1pa3MGZ9Kmw5218631W1+yxl9vWTpo/bKK i3yCjL4AZODnbuHFeThBzJ04ZJFBVTu556RF7k+Qu18hX18/fxrrZQH9so79avBA5NUEieoavmBY 5UZ+5lRfHuX8UQmKMnPqx7MMsSIIYtfnC7fJ/LzGcABozG2qusiG8IlDvvNe2vp3kV7hvk1X7Xd3 +Bj3dfwDfh8EWR17E+QbT815ngLUEBe4+XAERrMhR3DMELAA4DN8LnJT4T9kAN8+48ggd7JH9FPu d6esOkGZPzE4RRIPclu/pLCr6vL1H+LfEs3mhSmt7COT0enUlOa+uMQ0FhX71cL2zk0I06UFdVXP C98mmyC8CUlhoEHf0/zmsme3XC8GN/10AwB4p8+fdnuXEU1HjB0LS1EB05tjeVzascntL4GfsaSi HGeRqt5U2jUZeZ5Z82sJiXzJ6k5yIXjvfmwEDbZPILYeRZ1vQLXVQlc87muF1w4bstE1FljBMo/Q KXtIhJVnxC6tRQmqk8pNMWMLNFqg96zdbW268BdP4Nq221bDFVuMD1i3anbOGPu1kzH2c/N/6ID4 0MHonYRtUTqt7LDeuiCx+1Wa1YECumoRWK3RE5Tb1le1uYN9S0KI2yzjZRSQg2eapQaO9dbYUMV5 EbXyGuOD3uq1cFoxPtTW53gx9TjgTtdX+X650bNVskzlcNfsoXsuztimJRmu3PnwCRQ8hzvo/WU9 TU3d7AhUlzAplKRo4R18d7bdQpiUnCxFuhvsW89WcO5YMcR0t1KTzlONo87tLGe0fgKzhOyvLO+d Q2gwyUgyaEu63KGVYXkpUZcrq1bRXzFAfmgAf2fgHmYybNeNVrfoBSUFmyG5+MCF4iLqXE6hldAy nmns/sotO8nKLHyzzbp5JJh0GBq1WBGpEE4mfyUJ9TNJFaRO+G74EQmYEYPTDPtRZ+ztsHw/e6// AwAA//8DAFBLAwQUAAYACAAAACEAXyyju/0BAAD/AwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU0Fu2zAQvBfoHwSdG1Fy4rg1aAaFg8KH tDFgJTmz1EoiSpEESbtxX9+lFDtM21N92p1dDMezI3rzPKjsAM5Lo1d5VZR5BlqYRupulT/UXy4+ 5pkPXDdcGQ2r/Ag+v2Hv39GtMxZckOAzpNB+lfch2CUhXvQwcF/gWOOkNW7gAVvXEdO2UsCtEfsB dCCzsrwm8BxAN9Bc2DNhPjEuD+F/SRsjoj7/WB8tCma0hsEqHoB9i3JU0ZgwUHJGaW0CV7UcgFUI nxu65R14NqdkKuiTcY1ns3J+TclU03XPHRcBLWRVtZhdUZIg9LO1Sgoe0F72VQpnvGlDdj8akUUG StIViubsQOydDEdWUpK29E5qFPNpQclUoTrHO8dtj5IQTVq6E1zBGj1gLVceKHkF6AZ4vO+WS9RM D2F5ABGMy7z8hRee5dl37iE6t8oP3EmuAzoY16ZmrJX1wbFaBoXcOJv6sUzX0lpeRXNxF4u3ixGc NODgrbrxBX/f4n8L/xBbpWJHDZPURE5Snt/4g3VtBsv1kW32/CfIrAbRa6NMF8O9NsWHu9AUeNaX rXiHH/7B1uY2JurF37dgkoonGfqd5QJPV10u5pdpPpIZ3WGOoMGDnxhfAbrBYzgVn8Vs6Q6a087f g5i4x+l7ZtWsKPE3RuyEYUzOHxr7DQAA//8DAFBLAwQUAAYACAAAACEAyg+7dk8BAAB/AgAAEQAI AWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJJd b8IgGIXvl+w/NNy30GrUNC1mH/FKkyVzcdkdgVclK5QAs/rvR1vtNNvVLuEcHs55oZgfVRUdwDpZ 6xKlCUERaF4LqXclelsv4hmKnGdasKrWUKITODSn93cFNzmvLbzY2oD1ElwUSNrl3JRo773JMXZ8 D4q5JDh0ELe1VcyHpd1hw/gn2wHOCJlgBZ4J5hlugbEZiOiMFHxAmi9bdQDBMVSgQHuH0yTFP14P Vrk/D3TKlVNJfzKh0znuNVvwXhzcRycHY9M0STPqYoT8KX5fLV+7qrHU7aw4IFoInnMLzNeWPmhh oYlWrJKuwFdCO8SKOb8K895KEI8nupyOJrOswL+V1mzhINuXor1jWIbbunL9lSCiEDfvy12Uzejp eb1ANCPpOCazmIzX6TTP0pyQjzbUzfk2fr+hztH+TbwAaNfp9svQbwAAAP//AwBQSwMEFAAGAAgA AAAhADjBysFvAgAA+wkAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzcls9u2kAQxu+V+g7W3huvjSEJ CkRAcC9VDhV9gMUseCV71/Ia3FzJvece2keoemilXvI2SLnmFTK7i/kT4gQjcikICWbX4/VvvvmG i8uvcWTNaCqZ4C3knGBkUR6IEeOTFvoy8D+cIUtmhI9IJDhtoRsq0WX7/buLvDkWPJMWXM9lM22h MMuSpm3LIKQxkScioRzWxiKNSQY/04ktxmMW0CsRTGPKM9vFuGGnNCIZ3FuGLJFomS3fJ1su0lGS ioBKCYeNI5MvJoyj9vJ0Vt7kJIZTD1gM51bhhHAhqQMrMxK1EHbh3cA1XMcefFz45iFbbQxCkkqa rTZiEx6TmEU3RZRMM2HiCcuCsAjPSMrIMKJmSbIJLEzlEMP9zKuGTMRZRYC73uPuRGrbkWAzj6Ou gshmHji9bYrzPAbrmubWZxETw+m4QFKdVwPck0gfiLgd318T6UHk9MzTzwbU1kTOl3vKiTgmz/5E OlCoqEQYXRCGpwWiROJWEobMmZSVlFHKodDKm3LokXgIKEpIqNYwLaJapRqJwxSB3U1FeKprvFVk TaLomhcUca6Vtb8iHu5+Pdz9se6/f7v/8VPzeOIEXv8oTqDqvf2UjU7v1L/yu0+dwHFf0T0YadWn HJAQOrWk3Eb4puCqAao44gHCd4BDf1VcsDJlAA1c3wHhvmYADq5sAD0SMVB+CQlfzwTd/JWFfwCJ HUko4Xd6KzZr4RfmeEThf5oGbESsjykMe6p5kCi7hvEJI0bPSj1EN6bH24/Jor1BE3VFYlndraFQ 7HmBRPcwC1jM/y7m/xa3t4v57//HCJb/DWT7EQAA//8DAFBLAwQUAAYACAAAACEA4OvntEYGAADH SAAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbOxc3Y6jNhi9r9R3GCH1ciYGzE+izawIAWmrturF9AEY Qiao/ERAMjt3fZY+Wp+kn+2QkA3xxPzssi03m4XPn+EcG3M4tufDx89xdLcPsjxMk7kkPyDpLkj8 dBUmL3Ppjyf33pTu8sJLVl6UJsFcegty6ePjjz98eJ0lu/g5yKDgHdSR5LM9hDdFsZ1NJrm/CWIv f0i3QQLBdZrFXgGH2csk9rI/d9t7P423XhE+h1FYvE0UhHTpUE06l3ZZMjtUcR+Hfpbm6bogKbN0 vQ794PBTZmS3XJdlLlN/FwdJQa84yYII7iFN8k24zcva4qa1AcRNWcmeB2IfR2W51+0tV1tl3ivw HEfstl/TbLXNUj/Iczi7ZMFjjTLiXftAIKnimHHLLZxfs7yT2AuTYzWke3zR/sfGe4DGm7BrT0hV JyDAxSN0Ju85LzLPL37bxXdnR59WcwnRIkkeriC296K5pCLX1FzLlCYkOd5FRfhLsA+ip7dtUJah ZyNylpUq4m1Uxlx7iV2s6CwS7UkghJ/yWtDls6IsrLJS0N/d+HhyFfhh7B2qhsyn4PMx9pP8cKz4 Z7+sJgrWBTu9/T0jt10A6MNvWQauIcH/t2k+lwwFkeKTU8EwIQSQelgUDjZe8kKfVVUvS9PaIQtu itReBSeTygvo/9DtyeMqU2LPwMrCYJUuwMoYl/df0lJFS8PCcJU+4KpdwFXkY3PVwaVhYbhqH3Bx J3BNk9e6CgkLw8V9wNW6gAvPIg8uDQvD1fqAq3cBF6vckYqGheGCHuh+qDK6gKsh7lBFw8JwjT7g mp3ANbhDlUbCwnBBVXbfutMu4OqYO1TR8A1w4f1bkTTkPVw5hPzKEVE47EV8pnA0R0UL1WCvY3GF Y2NLty1TYflVEcDU1NlL/6CDvrbCwRpvmCTRG5j+bhSObPDQyiQsDHe4Ckc2p1y4JCwMd8AKR5d5 cBUSFoY7YIWjqjy4KgkLwx2wwkH8kYqEheEOV+FggztU0bAw3AErHMwdqjQSFoY7YIWjcIcqnYRv gCuocJQLDwdr2EC6veApnM3bcxaufiX+zhUnx5zaiqaZdp3OARTFNvLnkoZcjOypeaPd8byLouDg 1Xxh7fzz19/HK30ja+d1ljH/KHPTpMgBpJf7YTiXnsIY3FnSdBYoyepxmIBjtArWHhBJbh/ajtbB c4kocbppI9m0aIdo4Bv1TmRL26h3Kpk+o1S6MrKROlwqW1pSvVPJtB/rlYqiL1zHJn19iL2S+lnX rdv37K7eqWS6klKpOrYla3iwVLa00nqnkmlW1isty3asxWCpbGnT9U4l08OUSstysW0smyrk3l87 LS3A3qlkWptS6RhTU7Vw00/J/qlsZy/2TiXT8ZRK051alqE19Vx6p7KlddkDlYLfCOrFN4ImmwsZ 4cYuqKZOkYJt56jZQTFcnec9eKVf2wUd53lPs9rjPG9pq3Fm8ZkS7ngWf5znnUuiKzRaitP6r+8B u6DjPG9lAc44z3vDUDVgF/SbzPPiS4WzMCxVtimX11ayve+CTrGjyK5Sq3OIScK+qhausjQ0+7/t glpZCMvyTi7o6bixC2rYtmMawzVJ+nJBT9QxQ/l0LEZlxQV14F5NbAz2y74vF/REXTsqmfajjzMM GshSBmwot1v0d/VztCsqKy6ooRpItmE58EAN5ZZCs3cqKy4oNh0HL5EzVCr7ckG76pUVF1RfOhbW 7eFad+0WQvbeKysuKF46iqooTeVo79YdXUV5fcbovUWWvVNZcUGnyhIt1cX/zgVt/oALuqDaxTeC gTRbk/WDuhdfC2qYBkIYWze5oJiVGl3QI1tnW3vG3S7iPllLUV3vk40uKCwqP1vFLb51a9ztIt6Z WwrI+s7c9MuDuwtx3O0i3rothVh96zaVndzW/Y53u+iXCsfFFtKXLnvniiscE+sOWsi1q0DJ5puz cVIbFQ5v8/KocMSHjVHhVHdrv7fAsX6UbOpzcEfJUeGId+ZR4VQ78zjPO87z0h0TlS27RFKAQQKz BfDvaf9upcQnsqaJ/akSojZgxIOSF2lsU0xtWkl6XRpbJ1ebRrXNlauxyefaNLoB+Eoa86Nq0+gX 55U0JvJq06jFdCXNoNqwNo2uzyvT2C/7A0SP/wIAAP//AwBQSwMEFAAGAAgAAAAhAPyvjZXPBgAA AUIAABoAAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbL2bW0/jOhDH3490vkOUd7ZpboVqy4qF ZUHaC7sFnWc3calFYufYLoXz6Y+dW0uvcc3OE43t+c947PwcpPHHTy955jxjLgijI7f/wXMdTBOW Evo4ch/ur09OXUdIRFOUMYpH7isW7qfzv//6uBgK+Zph4SgBKoaLIhm5MymLYa8nkhnOkfiQk4Qz wabyQ8LyHptOSYJ7C8bTnu/1vfJXwVmChVDeLhF9RsKt5XLWTS1HSfPT97xT9Uxoq7EZESswVZ1T xnMk1SN/VBb8aV6cKM0CSTIhGZGvWituZZ5H7pzTYa1x0sahbYYqgOFznjWD2b6xVaD1n8aCdwmy MrliyTzHVJbh9TjOVMCMihkplnk7Vk11zhqRvRNemeyi6Id2i37F0UL9WQp2CT+tjPKsiny/Yt/r sCJaorXoEsJbn00kq5tvcVxqVpP7aJfbr5zNi6UasVO7pU+tluaAgVa9RqtTE3bBjGeoUC9Qngxv HynjaJKpiFTGHb0j3XPFppQlV3iK5pkU+pHf8fqxfir/XDMqhbMYIpEQcq/iUCo5UYI3F1QQV/Vg JOSFIGi180vdpvtneuBWy0TIlebPJCVuTzsV/6nOZ5SNXD9sWi7FeluG6GPThunJw3g1mJWmidId uYifjC+0Ya+eW299xkX7VI1aS48CiQLBuOK56sXTbyx5wulYqo6R67lV48PtHSeMK0CO3LOzunGM c3JD0hTr46MZSGckxf/MMH0QOF22/7ou36FaMWFzqn77g7hcskykX14SXGimqV6KdPZ+aINMjxYr fkrzOVlGUzWseS0b/21c9uvMbvMyw0gfeE7/oKOz93Hkb9U1kgjsJUJ7icheIraXGNhLnNpLnB0v IVlSbb5V8+DsgIVvbBEYW4TGFpGxRWxsMTC2ODW2ODOySFD5vGETdd4D90Rm+CCA+paoq7Hv3CGO HjkqZo4+BTe87FEYzyeyW6h9u1DHkjP9JXfAje/bufmSFzMkiDjsyDL19/o7xfnKSXrQVbTjnNkt fpehBM9YlmLu3OMXaWr/gznjAiWkQ8Itl/UbeZxJR33CpV2cxZ7pTCr9b0TIw+L948Q7rWHsm4p/ xymZ501qOnyNxIGlC/+wi/BIF3oBukwhstHvEH98pL5e4y7xD2z0O8R/aqMfHNY3Js0V4k/dXq+B 8bt7yTLGp/OsMx4G/aNddJuCf7R+J0gMguMI1LzAF0mi/nPrsk8tOGrgxQKoBl6syWrgyxqxBr7s WGvgyBi6v/EzEc33rdHyipVvzYOBBaHdt8WvOZOHP0x9y//ib6nEVGCnm7fA8rPxzXlnsMZ2B5+B I7sT0MCR3VFo4Oj4M7G7E/vD0cCX3Slp4MjuuDRw9D7npg9ybvog56YPeG76gOemD3Vu+n/6nxUD R+8Dbx8K3j4UvH0IePuA8Pah4O1DwduHgncAAu8ABN4BILwDQHgHUPAOoOAdQME7gIJ3AAXvAALe ASC8Ayh4B1DwDqDgHYLAOwSBdwgI7xAQ3iEUvEMoeIdQ8A6h4B1CwTuEgHcICO8QCt4hFLxDKHhH IPCOQOAdAcI7AoR3BAXvCAreERS8Iyh4R1DwjiDgHQHCO4KCdwQF7wgK3jEIvGMQeMeA8I4B4R1D wTuGgncMBe8YCt4xFLxjCHjHgPCOoeAdQ8E7/gPw1nW2GXY6l6f236mqoXs9rG19bzXB33iKOaZJ h0qK/vvM0MCjZW3xZ8aenG6F3UFg6YpMMsLKMpvXDe3BvrLkn5fODW7L7dYq3jfc995eFzpvLoKq gfK1UHrFarVPWpWb10XD5cDbtL3Wo411EM1Vp7q5jLX2WnksDTddJTPlK5GY73FVF7y3NUhlufu6 4x1V8WUgy4Q0o+tleLtWewOVuvR7T5BlafjepDjlkF0RndVXE5Y7bHuEKp5JVt1+Uz9uaaoEFvUu qyJNX5DbDLzEWfYdVaNZsXtohqey6u17p1v6J0xKlu+25+V33U6B3ttgeu0kduebzvMJ5vWO3rkH ywrQzXRXlaGWme64aZO5UKkpX6X1+FBRZPgkYfQZc4nTE1EgRaz1cLePqtKOVCg/6doef/siVPkX JG1Ged7FZdwfxO67zEE5yjdjrlpBY2wjulF9PCP0aSOqZY9ZZLv3yJbXb9c02kupif68WI7wvOvr Wqxp1BdgKxKsXPfckYM3LG5zoPf3siZzPQ9rJZvbkrHK6c3pB+E6wffNu6jmLarLJ/pOK54yrneS V7KieryYS1YPqfcYmqqlbUeVT2uDqgzV+lvv/OpLVzkW7U3e5nn9pq635aau120Fur4polB823xV 6ub3fleaX+L8f1BLAQItABQABgAIAAAAIQDgvd/FogEAAJAGAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsAAAAAAAAAAAAA AAAA2wMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAHQEhqkVAgAA+wkAABwAAAAAAAAAAAAA AAAAEAcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAqOSD3/ww AABqpAEAEQAAAAAAAAAAAAAAAABnCgAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEA IVqihCEHAADbHQAAFQAAAAAAAAAAAAAAAACSOwAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0A FAAGAAgAAAAhAOR/j+4qBgAAxhQAABEAAAAAAAAAAAAAAAAA5kIAAHdvcmQvc2V0dGluZ3MueG1s UEsBAi0AFAAGAAgAAAAhABLjFdVSAgAArhgAABQAAAAAAAAAAAAAAAAAP0kAAHdvcmQvd2ViU2V0 dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAJLIuo5OCAAAB0EAAA8AAAAAAAAAAAAAAAAAw0sAAHdv cmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQARK94C9QIAADwFAAATAAAAAAAAAAAAAAAAAD5U AABkb2NQcm9wcy9jdXN0b20ueG1sUEsBAi0AFAAGAAgAAAAhAF8so7v9AQAA/wMAABAAAAAAAAAA AAAAAAAAbFgAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEAyg+7dk8BAAB/AgAAEQAA AAAAAAAAAAAAAACfWwAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAOMHKwW8CAAD7 CQAAEgAAAAAAAAAAAAAAAAAlXgAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAODr 57RGBgAAx0gAABIAAAAAAAAAAAAAAAAAxGAAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAI AAAAIQD8r42VzwYAAAFCAAAaAAAAAAAAAAAAAAAAADpnAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3Rz LnhtbFBLBQYAAAAADgAOAIoDAABBbgAAAAA= --_004_7AEB3D6833318045B4AE71C2C87E8E1729C085F1dfweml706chmchi_-- From nobody Wed Aug 6 13:04:16 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310671B2868 for ; Wed, 6 Aug 2014 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 AvucRRTimI2v for ; Wed, 6 Aug 2014 13:04: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 306CF1B285B for ; Wed, 6 Aug 2014 13:04:05 -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 BKY75972; Wed, 06 Aug 2014 20:04:03 +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; Wed, 6 Aug 2014 21:04:02 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Wed, 6 Aug 2014 13:03:52 -0700 From: Leeyoung To: Dave Hood , "Varma, Eve L (Eve)" , "Shew, Stephen" , "actn@ietf.org" Thread-Topic: related standards work Thread-Index: Ac+s07DwrSd601O8RyCE0rBXyO3RzwAB92+QAADM7uAAAP+EQAA0OjxgAP3+SKA= Date: Wed, 6 Aug 2014 20:03:50 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C08D80@dfweml706-chm.china.huawei.com> References: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> <7AEB3D6833318045B4AE71C2C87E8E1729C079A9@dfweml706-chm.china.huawei.com> <6D32668528F93D449A073F45707153D82C49F304@US70UWXCHMBA03.zam.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E1729C07A03@dfweml706-chm.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F47913F@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F47913F@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.33] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C08D80dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/OYgvIIfeMsUr0GOKN7Js85E8YgQ Subject: Re: [Actn] related standards work X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 20:04:14 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C08D80dfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I guess the SDN RG discussion right now is interesting and some heated disc= ussion around ONF and IETF has some relevance to ACTN work. First of all, I thank for the pointer on the ONF SDN architecture. I think = you and the contributors did a good job on managing to publish a good quali= ty document. I came across Section 6.7 in which to state very interesting statements in = regards to some IETF protocols such as GMPLS, BGP and PCEP: 6.7 Inter-domain control communication Taken to its extreme, the principle of logically centralized control sugges= ts that a single SDN controller have worldwide scope. However, a real-world= SDN controller probably doesn't encompass all endpoints of interest to its= clients. Client services often extend into other technical or administrati= ve domains. These domains may include non-SDN networks. Particularly when interfacing with non-SDN-controlled networks that are alr= eady in place and working, it may be appropriate that an SDN controller run= a variety of existing protocols, for example BGP or GMPLS. When talking di= rectly to another SDN controller, the appropriate interface is a matter for= further study, but may well be extensions of these, or other, existing pro= tocols, for example the path computation element communication protocol, PC= EP [9]. Following the principle of parsimony, new protocols should be developed onl= y upon convincing evidence that no existing protocol can be suitably used o= r adapted. As you said in the earlier email, "it is explicitly *not* based on OpenFlow= concepts and it recognizes the existence of the ONF protocols as candidate= s to perform some of the necessary functions, but with the caveat that they= may require extension." I have a couple of questions: 1. Are there any plans to extend ONF-based protocol extensions to sup= port non-SDN networks (I assumed that non-SDN is meant non-OF based)? 2. Where do you think the best place to work on extensions of GMPLS, = BGP and PCEP to support necessary functions discussed in your ONF SDN Archi= tecture document? The ACTN has a very different starting point (as I discussed with Eve and S= tephen) than the ONF SDN architecture and its controller functionality. Wha= t do I mean by that? 1. We avoid reinventing the wheel. Domain control as deployed in the = form of control mechanisms (e.g., GMPLS/ASON, PCE, EMS/NMS, etc.) will not = be affected. 2. If and when an OF-based Transport network domain comes to be with = your SDN controller, ACTN can take SDN transport control domain as a domain= which consists of multi-domain of an operator network. 3. As indicated by many ACTN use-cases by operators, the main focus o= f ACTN is operator's multi-domain coordination to enable faster service pro= visioning and/or allow network resource partitioning for various services o= perators should support on their deployed network environments (no green fi= eld here). Regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Friday, August 01, 2014 1:13 PM To: Leeyoung; Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work One correction to the comment on the ONF SDN architecture: it is explicitly= *not* based on OpenFlow concepts. It recognizes the existence of the ONF p= rotocols as candidates to perform some of the necessary functions, but with= the caveat that they may require extension. This has been true throughout the development of the architecture that has = now been released. Dave From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 10:34 AM To: Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Eve, Good to hear from you in ACTN list. Thanks for your comment. I think you cl= arified some misunderstanding and confusion. Here's my comment for you in-l= ine. Regards, Young From: Varma, Eve L (Eve) [mailto:eve.varma@alcatel-lucent.com] Sent: Thursday, July 31, 2014 12:06 PM To: Leeyoung; Shew, Stephen; actn@ietf.org Subject: RE: related standards work Hi Young, Please see below for my two cents ;-) With best regards, Eve From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 12:44 PM To: Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Stephen, Thanks for posting this list of reference. My overall comment is: in light of many works in the past and even presentl= y in other SDOs, it is ironic that operators came to IETF to address their = problems and see IETF as viable and practical place for their problem to be= solved. I am not surprised that operators are seeking to find solutions acros= s a range of standards and industry forums. This is not exclusive to IETF = - e.g., consider related ETSI NVF work items. YOUNG>> Yes, that is a reality. >From a transport network perspective, there have been many tools IETF champ= ioned in regard to GMPLS control plane, PCE and other configuration/managem= ent tools. Some of your pointer for ONF seems irrelevant to many operators = as OF is a green-field for them. As you were in the BoF, the operators bro= ught their current problems on their brown field. Are you aware of any real= deployment of ONF-based transport networks? ACTN can certainly treat OF-ba= sed transport as a domain among others once it is deployed. The reference was to a protocol-neutral SDN Architecture document (i.= e., independent of the protocol used over interfaces), which has some very = useful material that has also been shared with other SDOs, and IMHO is quit= e relevant to the ACTN problem domain. I would certainly understand your c= omment if the document were focused/optimized for the OF protocol. However= , it is not. It is my view that protocol-independent architectural work sh= ould be examined regardless of what group produces it, as we have so many c= olleagues contributing across multiple standards and industry forums, which= allows for leverage of applicable work. YOUNG>> The assumption for SDN arch. Document (as far as I understand from = the initial version) is, however, tied with OF based philosophy, meaning th= at the SDN controller is a "God"-box as to what to control as to how much i= t wants to know. The ACTN is on a different assumption. ACTN control hierar= chy would not touch existing domain control of many kinds (e.g., GMPLS/ASON= , PCE-based, NMS/EMS-based, etc.) and let them continue control/operate the= ir networks (which is one of the requirements from many operators). What th= ey need is a overarching "overseer" that allows quick service provisioning = based on an end-to-end global abstraction view of all encompassing domains.= For instance, cross-connect and other low level control of NE will need no= t be abstracted in ACTN scope as these controls will continue to be done at= existing domain level control. I think this assumption makes a huge differ= ence. I believe what ACTN is trying to do based on operators' use-cases has= a different starting point from what you are referring to, namely, the ONF= SDN Control architecture models has been trying to do. ACTN does not repla= ce any existing network control and operation. It builds on top of that. Your Virtual network reference from ITU-T is quite theoretical and VPNs hav= e been implemented in L2VPN/L3VPN WGs focusing on practical issues. I also = see some gap of many ITU-T references and the reality. Perhaps the language used in the ITU-T Rec. could be a barrier for so= me, but there is useful information. You'll find some good material, lever= aging this, in the SDN Architecture document discussion of this area. YOUNG>> language is always a tremendous stumbling block. :) I will try to u= pdate myself with the mentioned references. Your pointer for TMF is all appreciated. We will look at if data model is n= ecessary to enable abstraction. For TE model of IETF, we did not have eithe= r IM or DM in GMPLS/PCE implementation. At this point, I am not sure if we = need IM or DM. One of the homeworks from the BoF is to investigate if we ne= ed IM/DM. If we do need IM/DM, there have been some efforts in IETF around = Yang and JSON. I have proposed JSON based abstraction models in the past in= IETF (In a BoF called I2AEX under ALTO) , which seems working very well fo= r transport network resource abstraction. There are also BGP-LS based mode= ls that have progressed in IETF quite a bit. I tend to think these lists ar= e a starting point. TMF is a bit foreign to IETF and to me. If one is looking from a broader transport networking perspective, a= n underlying information model from which various data models/interfaces ca= n be derived enables interoperability (not to mention leverage of significa= nt industry experience in networking & forwarding domain). However, this i= s a much larger discussion topic area (beyond ACTN). YOUNG>> Agree. My point is that models are only tools that should help the = functions. As pointed previously, for simple functions to fulfill, the vali= dity of models needs to be carefully evaluated. Thanks, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen Sent: Thursday, July 31, 2014 11:00 AM To: actn@ietf.org Subject: [Actn] related standards work As discussed in the actn bof last week, I list some related standards that = I think should be considered by actn so that things don't get re-invented. 1. Virtual Network. There are various semantics to the word "virtual"= so adopting or stating a definition is important. RFC4847 describes virtua= l networks in terms of ITU-T Y.1312 and Y.1313. Those Recommendations addr= ess both the data plane aspect of VPNs as well as the control plane aspect.= Concepts of private and shared VPNs are described. I find them quite use= ful and suggest that uses cases adopt these terms so that the commonality o= f the use cases can more readily be determined. 2. Abstraction and arrangement of control. The recently published ONF= SDN Architecture (https://www.opennetworking.org/images/stories/downloads/= sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes var= ious arrangements of SDN controllers which I think should be adopted by act= n. They define "abstraction" in way that makes "virtual" a subset of abstr= action. Having a clear definition of the 2 terms is important. The Multip= le Vendor Domain Transport Networks use case could be covered by a limited = hierarchy of SDN controllers. One of the suggestions in the SDN Architectu= re document is that there may be a need for inter-domain control and this m= ay be a gap that actn addresses. 3. Interfaces. Implementations of interfaces imply some design, and i= t is helpful to expose that design upfront so that limitations, extensibili= ty, and commonality are understood. To that end, use of a common informati= on model has been beneficial. I point in particular to TM Forum's TR215 an= d is draft successor TR225. From an information model, a more specific inf= ormation model can be derived (like an instantiation of an aspect of the ge= neral one). Then, data models can be developed from that specific informat= ion model. If a common information model is used, then the particular enco= ding of the data model is less critical. I don't suggest that actn start w= ith just a data model because the architecture behind it is not exposed. Stephen Shew | Director, Standards sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA = K2H 8E9 Direct +1.613.670.3211 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C08D80dfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

I guess the SDN RG dis= cussion right now is interesting and some heated discussion around ONF and = IETF has some relevance to ACTN work.

 

First of all, I thank = for the pointer on the ONF SDN architecture. I think you and the contributo= rs did a good job on managing to publish a good quality document.

I came across Section = 6.7 in which to state very interesting statements in regards to some IETF p= rotocols such as GMPLS, BGP and PCEP:

 

6.7 Inter-domain c= ontrol communication

Taken to its extreme, the principle of= logically centralized control suggests that a single SDN controller have w= orldwide scope. However, a real-world SDN controller probably doesn’t encompass all endpoints of interest to its clients. Client s= ervices often extend into other technical or administrative domains. These = domains may include non-SDN networks.

Particularly when interfacing with non= -SDN-controlled networks that are already in place and working, it may be a= ppropriate that an SDN controller run a variety of existing protocols, for example BGP or GMPLS. When talking directly to another SDN = controller, the appropriate interface is a matter for further study, but ma= y well be extensions of these, or other, existing protocols, for example th= e path computation element communication protocol, PCEP [9].

Following the principle of parsimony= , new protocols should be developed only upon convincing evidence that no e= xisting protocol can be suitably used or adapted.

 

As you said in the ear= lier email, “it is explicitly *not* based on OpenFlow concepts= and it recognizes the existence of the ONF protocols as candidates to perf= orm some of the necessary functions, but with the caveat that they may require extension.”  I have a couple o= f questions:

 

1.&n= bsp;      Are there any = plans to extend ONF-based protocol extensions to support non-SDN networks (= I assumed that non-SDN is meant non-OF based)?  

2.&n= bsp;      Where do you t= hink the best place to work on extensions of GMPLS, BGP and PCEP to support= necessary functions discussed in your ONF SDN Architecture document?

 

The ACTN has a very di= fferent starting point (as I discussed with Eve and Stephen) than the ONF S= DN architecture and its controller functionality. What do I mean by that?

1.&n= bsp;      We avoid reinv= enting the wheel. Domain control as deployed in the form of control mechani= sms (e.g., GMPLS/ASON, PCE, EMS/NMS, etc.) will not be affected.

2.&n= bsp;      If and when an= OF-based Transport network domain comes to be with your SDN controller, AC= TN can take SDN transport control domain as a domain which consists of mult= i-domain of an operator network.

3.&n= bsp;      As indicated b= y many ACTN use-cases by operators, the main focus of ACTN is operator̵= 7;s multi-domain coordination to enable faster service provisioning and/or = allow network resource partitioning for various services operators should support on their deployed network enviro= nments (no green field here).

 

Regards,

Young

 

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Friday, August 01, 2014 1:13 PM
To: Leeyoung; Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

One correction to th= e comment on the ONF SDN architecture: it is explicitly *not* based = on OpenFlow concepts. It recognizes the existence of the ONF protocols as candidates to perform some of the necessary functions, bu= t with the caveat that they may require extension.

 

This has been true t= hroughout the development of the architecture that has now been released.

 

Dave

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 10:34 AM
To: Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Eve,

 

Good to hear from you = in ACTN list. Thanks for your comment. I think you clarified some misunders= tanding and confusion. Here’s my comment for you in-line.

 

Regards,

Young

 

From: Varma, E= ve L (Eve) [mailto:eve.varm= a@alcatel-lucent.com]
Sent: Thursday, July 31, 2014 12:06 PM
To: Leeyoung; Shew, Stephen; actn@i= etf.org
Subject: RE: related standards work

 

Hi Young,

 

Please see below for my two ce= nts ;-)

 

With best regards,<= /span>

Eve

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 12:44 PM
To: Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Stephen,=

 

Thanks for posting thi= s list of reference.

 

My overall comment is:= in light of many works in the past and even presently in other SDOs, it is= ironic that operators came to IETF to address their problems and see IETF = as viable and practical place for their problem to be solved.

 

<ELV> I am no= t surprised that operators are seeking to find solutions across a range of = standards and industry forums.  This is not exclusive to IETF – = e.g.,  consider related ETSI NVF work items. 

 

YOUNG>> Yes, = that is a reality.

 

From a transport netwo= rk perspective, there have been many tools IETF championed in regard to GMP= LS control plane, PCE and other configuration/management tools. Some of you= r pointer for ONF seems irrelevant to many operators as OF is a green-field for them.  As you were in the B= oF, the operators brought their current problems on their brown field. Are = you aware of any real deployment of ONF-based transport networks? ACTN can = certainly treat OF-based transport as a domain among others once it is deployed.

 

<ELV> The ref= erence was to a protocol-neutral SDN Architecture document (i.e., independe= nt of the protocol used over interfaces), which has some very useful materi= al that has also been shared with other SDOs, and IMHO is quite relevant to the ACTN problem domain.  I would certa= inly understand your comment if the document were focused/optimized for the= OF protocol.  However, it is not.  It is my view that protocol-i= ndependent architectural work should be examined regardless of what group produces it, as we have so many colleagues contri= buting across multiple standards and industry forums, which allows for leve= rage of applicable work.    

 

YOUNG>> The a= ssumption for SDN arch. Document (as far as I understand from the initial v= ersion) is, however, tied with OF based philosophy, meaning that the SDN co= ntroller is a “God”-box as to what to control as to how much it wants to know. The ACTN is on a different assumption. AC= TN control hierarchy would not touch existing domain control of many kinds = (e.g., GMPLS/ASON, PCE-based, NMS/EMS-based, etc.) and let them continue co= ntrol/operate their networks (which is one of the requirements from many operators). What they need is a overa= rching “overseer” that allows quick service provisioning based = on an end-to-end global abstraction view of all encompassing domains. For i= nstance, cross-connect and other low level control of NE will need not be abstracted in ACTN scope as these controls will con= tinue to be done at existing domain level control. I think this assumption = makes a huge difference. I believe what ACTN is trying to do based on opera= tors’ use-cases has a different starting point from what you are referring to, namely, the ONF SDN Control= architecture models has been trying to do. ACTN does not replace any exist= ing network control and operation. It builds on top of that.

 

 

 

Your Virtual network r= eference from ITU-T is quite theoretical and VPNs have been implemented in = L2VPN/L3VPN WGs focusing on practical issues. I also see some gap of many I= TU-T references and the reality.

 

<ELV> Perhaps= the language used in the ITU-T Rec. could be a barrier for some, but there= is useful information.  You’ll find some good material, leverag= ing this, in the SDN Architecture document discussion of this area.

 

YOUNG>> langu= age is always a tremendous stumbling block. J<= span style=3D"color:#1F497D"> I will try to update myself with the mentione= d references.

 

Your pointer for TMF i= s all appreciated. We will look at if data model is necessary to enable abs= traction. For TE model of IETF, we did not have either IM or DM in GMPLS/PC= E implementation. At this point, I am not sure if we need IM or DM. One of the homeworks from the BoF is to inve= stigate if we need IM/DM. If we do need IM/DM, there have been some efforts= in IETF around Yang and JSON. I have proposed JSON based abstraction model= s in the past in IETF (In a BoF called I2AEX under ALTO) , which seems working very well for transport net= work resource abstraction.  There are also BGP-LS based models that ha= ve progressed in IETF quite a bit. I tend to think these lists are a starti= ng point. TMF is a bit foreign to IETF and to me.

 

<ELV>  I= f one is looking from a broader transport networking perspective, an underl= ying information model from which various data models/interfaces can be der= ived enables interoperability (not to mention leverage of significant industry experience in networking & forwarding domain).=   However, this is a much larger discussion topic area (beyond ACTN).<= o:p>

 

YOUNG>> Agree= . My point is that models are only tools that should help the functions. As= pointed previously, for simple functions to fulfill, the validity of model= s needs to be carefully evaluated.

 

Thanks,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: actn@ietf.org
Subject: [Actn] related standards work

 

As discussed in the actn bof last week,= I list some related standards that I think should be considered by actn so= that things don’t get re-invented.

 

1= .   &= nbsp;  Virtual Network.  There ar= e various semantics to the word “virtual” so adopting or statin= g a definition is important. RFC4847 describes virtual networks in terms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both the d= ata plane aspect of VPNs as well as the control plane aspect.  Concept= s of private and shared VPNs are described.  I find them quite useful = and suggest that uses cases adopt these terms so that the commonality of the use cases can more readily be determined.=

2= .   &= nbsp;  Abstraction and arrangement of = control.  The recently published ONF SDN Architecture (https://www.open= networking.org/images/stories/downloads/sdn-resources/technical-reports/TR_= SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SDN controllers which= I think should be adopted by actn.  They define “abstraction= 221; in way that makes “virtual” a subset of abstraction. = Having a clear definition of the 2 terms is important.  The Multiple Vendor Domain T= ransport Networks use case could be covered by a limited hierarchy of SDN c= ontrollers.  One of the suggestions in the SDN Architecture document i= s that there may be a need for inter-domain control and this may be a gap that actn addresses.

3= .   &= nbsp;  Interfaces.  Implementatio= ns of interfaces imply some design, and it is helpful to expose that design= upfront so that limitations, extensibility, and commonality are understood.  To that end, use of a common information model has b= een beneficial.  I point in particular to TM Forum’s TR215 and i= s draft successor TR225.  From an information model, a more specific i= nformation model can be derived (like an instantiation of an aspect of the general one).  Then, data models can be developed= from that specific information model.  If a common information model = is used, then the particular encoding of the data model is less critical.&n= bsp; I don’t suggest that actn start with just a data model because the architecture behind it is not exposed.=

 

Stephen Shew | Director, Standards
sshew@cien= a.com | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C08D80dfweml706chmchi_-- From nobody Wed Aug 6 13:54:11 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BAC1A0294 for ; Wed, 6 Aug 2014 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGlP-aQBcgtT for ; Wed, 6 Aug 2014 13:53:59 -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 96E4D1A028E for ; Wed, 6 Aug 2014 13:53:47 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-07-53e2421f8ef9 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FF.DC.05330.F1242E35; Wed, 6 Aug 2014 16:56:32 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Wed, 6 Aug 2014 16:53:38 -0400 From: Dave Hood To: Leeyoung , "Varma, Eve L (Eve)" , "Shew, Stephen" , "actn@ietf.org" Thread-Topic: related standards work Thread-Index: Ac+s07DwrSd601O8RyCE0rBXyO3RzwAB92+QAADM7uAAAP+EQAA0OjxgAP3+SKAAAofPoA== Date: Wed, 6 Aug 2014 20:53:38 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F47C431@eusaamb105.ericsson.se> References: <510C3D5C5DFBCB46AE189D936C1DD605A73BBB3721@ONWVEXCHMB02.ciena.com> <7AEB3D6833318045B4AE71C2C87E8E1729C079A9@dfweml706-chm.china.huawei.com> <6D32668528F93D449A073F45707153D82C49F304@US70UWXCHMBA03.zam.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E1729C07A03@dfweml706-chm.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F47913F@eusaamb105.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C08D80@dfweml706-chm.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C08D80@dfweml706-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.12] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F47C431eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonRFfB6VGwwc12IYstPRfYLJY2PWG0 mDbP1WLHuxoHFo/WZ3tZPc7e/Mfi0XLkLavHkiU/mQJYorhsUlJzMstSi/TtErgypnx7yl5w Yy5zxdMj6Q2Mrc+Zuhg5OSQETCQ2zO1lgbDFJC7cW8/WxcjFISRwlFFi+fkFrBDOMkaJPT1N jCBVbAIaEk8uTWYCSYgIzGeU2Ln/GlA7B4ewgLLE1iv+IDUiAioSzQ/WMkHYYRJTX5wF62UB is9o3MAOYvMK+Ep8OX+KGWLBKWaJy1MWgSU4gRqmzbgM1swIdNL3U2vAbGYBcYlbT+ZDnS0g sWTPeWYIW1Ti5eN/rBC2ksSc19eYIerzJX4f/M8MsUxQ4uTMJywTGEVmIRk1C0nZLCRlEHEd iQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHBJkZgnB2TYNPdwbjnpeUhRgEO RiUe3gcmj4KFWBPLiitzDzFKc7AoifPOqp0XLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx i9D6O1PKF105xK+zQbJYYnNUoYeNrI7t9nIeR04fNWXH5dqiUbkX/x1UTT0/IVG4zTh2SRD7 0Sdvbyl9jdhz0SI97hlPRf7b+i/7tGLsGY7zr96v+s/7xIzP/dtrbiVksL9/Ual3988ShU2K q/xcDk5lz2+p/a3s6y8n4CJoJXM4KnTR2wAlluKMREMt5qLiRAAFW7sZlAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/actn/SB0QcF1c-ugO-G12YROb60bK7mQ Subject: Re: [Actn] related standards work X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 20:54:08 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F47C431eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Lee First, let's Havecorrect "I assumed that non-SDN is meant non-OF based" - n= o, SDN means software defined networking, one (small) aspect of which is ad= dressed by OF. The non-SDN networks would be those controlled directly by E= MS/NMS or by signaling, but not by recognizable SDN components. (Recognizab= le: one could argue that all of this EMS/NMS etc is also software control, = but it takes the discussion off into the weeds, where we don't want to go.)= So to answer your question, it is probably not meaningful to extend one of= the candidate SDN protocols to support legacy networks, because in the pro= cess they would become SDN networks. I cannot speak for ONF, but my own view on BGP/GMPLS/... extensions is that= anyone (maybe ONF but not necessarily) might define use cases to explain a= nd justify the need for such extensions, but once the requirements were cle= ar, protocol development is the responsibility of IETF. Liaison or joint me= mbership might be the vehicle for interaction, but the extensions themselve= s would appear as RFCs. As to your description of ACTN, I fully approve and support the approach. I= would only point out that an SDN controller can sit at the top of such a m= ulti-domain network, coordinating and delegating functionality to lower-lay= er entities. I expect fitting in SDN principles at various levels of federa= tion and hierarchy to be the *only* way in which legacy networks can and wi= ll migrate to SDN. Dave From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, August 06, 2014 1:04 PM To: Dave Hood; Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org Subject: RE: related standards work Hi Dave, I guess the SDN RG discussion right now is interesting and some heated disc= ussion around ONF and IETF has some relevance to ACTN work. First of all, I thank for the pointer on the ONF SDN architecture. I think = you and the contributors did a good job on managing to publish a good quali= ty document. I came across Section 6.7 in which to state very interesting statements in = regards to some IETF protocols such as GMPLS, BGP and PCEP: 6.7 Inter-domain control communication Taken to its extreme, the principle of logically centralized control sugges= ts that a single SDN controller have worldwide scope. However, a real-world= SDN controller probably doesn't encompass all endpoints of interest to its= clients. Client services often extend into other technical or administrati= ve domains. These domains may include non-SDN networks. Particularly when interfacing with non-SDN-controlled networks that are alr= eady in place and working, it may be appropriate that an SDN controller run= a variety of existing protocols, for example BGP or GMPLS. When talking di= rectly to another SDN controller, the appropriate interface is a matter for= further study, but may well be extensions of these, or other, existing pro= tocols, for example the path computation element communication protocol, PC= EP [9]. Following the principle of parsimony, new protocols should be developed onl= y upon convincing evidence that no existing protocol can be suitably used o= r adapted. As you said in the earlier email, "it is explicitly *not* based on OpenFlow= concepts and it recognizes the existence of the ONF protocols as candidate= s to perform some of the necessary functions, but with the caveat that they= may require extension." I have a couple of questions: 1. Are there any plans to extend ONF-based protocol extensions to sup= port non-SDN networks (I assumed that non-SDN is meant non-OF based)? 2. Where do you think the best place to work on extensions of GMPLS, = BGP and PCEP to support necessary functions discussed in your ONF SDN Archi= tecture document? The ACTN has a very different starting point (as I discussed with Eve and S= tephen) than the ONF SDN architecture and its controller functionality. Wha= t do I mean by that? 1. We avoid reinventing the wheel. Domain control as deployed in the = form of control mechanisms (e.g., GMPLS/ASON, PCE, EMS/NMS, etc.) will not = be affected. 2. If and when an OF-based Transport network domain comes to be with = your SDN controller, ACTN can take SDN transport control domain as a domain= which consists of multi-domain of an operator network. 3. As indicated by many ACTN use-cases by operators, the main focus o= f ACTN is operator's multi-domain coordination to enable faster service pro= visioning and/or allow network resource partitioning for various services o= perators should support on their deployed network environments (no green fi= eld here). Regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood Sent: Friday, August 01, 2014 1:13 PM To: Leeyoung; Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work One correction to the comment on the ONF SDN architecture: it is explicitly= *not* based on OpenFlow concepts. It recognizes the existence of the ONF p= rotocols as candidates to perform some of the necessary functions, but with= the caveat that they may require extension. This has been true throughout the development of the architecture that has = now been released. Dave From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 10:34 AM To: Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Eve, Good to hear from you in ACTN list. Thanks for your comment. I think you cl= arified some misunderstanding and confusion. Here's my comment for you in-l= ine. Regards, Young From: Varma, Eve L (Eve) [mailto:eve.varma@alcatel-lucent.com] Sent: Thursday, July 31, 2014 12:06 PM To: Leeyoung; Shew, Stephen; actn@ietf.org Subject: RE: related standards work Hi Young, Please see below for my two cents ;-) With best regards, Eve From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, July 31, 2014 12:44 PM To: Shew, Stephen; actn@ietf.org Subject: Re: [Actn] related standards work Hi Stephen, Thanks for posting this list of reference. My overall comment is: in light of many works in the past and even presentl= y in other SDOs, it is ironic that operators came to IETF to address their = problems and see IETF as viable and practical place for their problem to be= solved. I am not surprised that operators are seeking to find solutions acros= s a range of standards and industry forums. This is not exclusive to IETF = - e.g., consider related ETSI NVF work items. YOUNG>> Yes, that is a reality. >From a transport network perspective, there have been many tools IETF champ= ioned in regard to GMPLS control plane, PCE and other configuration/managem= ent tools. Some of your pointer for ONF seems irrelevant to many operators = as OF is a green-field for them. As you were in the BoF, the operators bro= ught their current problems on their brown field. Are you aware of any real= deployment of ONF-based transport networks? ACTN can certainly treat OF-ba= sed transport as a domain among others once it is deployed. The reference was to a protocol-neutral SDN Architecture document (i.= e., independent of the protocol used over interfaces), which has some very = useful material that has also been shared with other SDOs, and IMHO is quit= e relevant to the ACTN problem domain. I would certainly understand your c= omment if the document were focused/optimized for the OF protocol. However= , it is not. It is my view that protocol-independent architectural work sh= ould be examined regardless of what group produces it, as we have so many c= olleagues contributing across multiple standards and industry forums, which= allows for leverage of applicable work. YOUNG>> The assumption for SDN arch. Document (as far as I understand from = the initial version) is, however, tied with OF based philosophy, meaning th= at the SDN controller is a "God"-box as to what to control as to how much i= t wants to know. The ACTN is on a different assumption. ACTN control hierar= chy would not touch existing domain control of many kinds (e.g., GMPLS/ASON= , PCE-based, NMS/EMS-based, etc.) and let them continue control/operate the= ir networks (which is one of the requirements from many operators). What th= ey need is a overarching "overseer" that allows quick service provisioning = based on an end-to-end global abstraction view of all encompassing domains.= For instance, cross-connect and other low level control of NE will need no= t be abstracted in ACTN scope as these controls will continue to be done at= existing domain level control. I think this assumption makes a huge differ= ence. I believe what ACTN is trying to do based on operators' use-cases has= a different starting point from what you are referring to, namely, the ONF= SDN Control architecture models has been trying to do. ACTN does not repla= ce any existing network control and operation. It builds on top of that. Your Virtual network reference from ITU-T is quite theoretical and VPNs hav= e been implemented in L2VPN/L3VPN WGs focusing on practical issues. I also = see some gap of many ITU-T references and the reality. Perhaps the language used in the ITU-T Rec. could be a barrier for so= me, but there is useful information. You'll find some good material, lever= aging this, in the SDN Architecture document discussion of this area. YOUNG>> language is always a tremendous stumbling block. :) I will try to u= pdate myself with the mentioned references. Your pointer for TMF is all appreciated. We will look at if data model is n= ecessary to enable abstraction. For TE model of IETF, we did not have eithe= r IM or DM in GMPLS/PCE implementation. At this point, I am not sure if we = need IM or DM. One of the homeworks from the BoF is to investigate if we ne= ed IM/DM. If we do need IM/DM, there have been some efforts in IETF around = Yang and JSON. I have proposed JSON based abstraction models in the past in= IETF (In a BoF called I2AEX under ALTO) , which seems working very well fo= r transport network resource abstraction. There are also BGP-LS based mode= ls that have progressed in IETF quite a bit. I tend to think these lists ar= e a starting point. TMF is a bit foreign to IETF and to me. If one is looking from a broader transport networking perspective, a= n underlying information model from which various data models/interfaces ca= n be derived enables interoperability (not to mention leverage of significa= nt industry experience in networking & forwarding domain). However, this i= s a much larger discussion topic area (beyond ACTN). YOUNG>> Agree. My point is that models are only tools that should help the = functions. As pointed previously, for simple functions to fulfill, the vali= dity of models needs to be carefully evaluated. Thanks, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen Sent: Thursday, July 31, 2014 11:00 AM To: actn@ietf.org Subject: [Actn] related standards work As discussed in the actn bof last week, I list some related standards that = I think should be considered by actn so that things don't get re-invented. 1. Virtual Network. There are various semantics to the word "virtual"= so adopting or stating a definition is important. RFC4847 describes virtua= l networks in terms of ITU-T Y.1312 and Y.1313. Those Recommendations addr= ess both the data plane aspect of VPNs as well as the control plane aspect.= Concepts of private and shared VPNs are described. I find them quite use= ful and suggest that uses cases adopt these terms so that the commonality o= f the use cases can more readily be determined. 2. Abstraction and arrangement of control. The recently published ONF= SDN Architecture (https://www.opennetworking.org/images/stories/downloads/= sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes var= ious arrangements of SDN controllers which I think should be adopted by act= n. They define "abstraction" in way that makes "virtual" a subset of abstr= action. Having a clear definition of the 2 terms is important. The Multip= le Vendor Domain Transport Networks use case could be covered by a limited = hierarchy of SDN controllers. One of the suggestions in the SDN Architectu= re document is that there may be a need for inter-domain control and this m= ay be a gap that actn addresses. 3. Interfaces. Implementations of interfaces imply some design, and i= t is helpful to expose that design upfront so that limitations, extensibili= ty, and commonality are understood. To that end, use of a common informati= on model has been beneficial. I point in particular to TM Forum's TR215 an= d is draft successor TR225. From an information model, a more specific inf= ormation model can be derived (like an instantiation of an aspect of the ge= neral one). Then, data models can be developed from that specific informat= ion model. If a common information model is used, then the particular enco= ding of the data model is less critical. I don't suggest that actn start w= ith just a data model because the architecture behind it is not exposed. Stephen Shew | Director, Standards sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA = K2H 8E9 Direct +1.613.670.3211 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F47C431eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Lee

 

First, let’s H= avecorrect “I assumed that non-SDN is meant non-OF based” ̵= 1; no, SDN means software defined networking, one (small) aspect of which i= s addressed by OF. The non-SDN networks would be those controlled directly by EMS/NMS = or by signaling, but not by recognizable SDN components. (Recognizable: one= could argue that all of this EMS/NMS etc is also software control, but it = takes the discussion off into the weeds, where we don’t want to go.) So to answer your question, it is= probably not meaningful to extend one of the candidate SDN protocols to su= pport legacy networks, because in the process they would become SDN network= s.

 

I cannot speak for O= NF, but my own view on BGP/GMPLS/… extensions is that anyone (maybe O= NF but not necessarily) might define use cases to explain and justify the need for such extensions, but once the requirements were clear= , protocol development is the responsibility of IETF. Liaison or joint memb= ership might be the vehicle for interaction, but the extensions themselves = would appear as RFCs.

 

As to your descripti= on of ACTN, I fully approve and support the approach. I would only point ou= t that an SDN controller can sit at the top of such a multi-domain network, coordinating and delegating functionality to lower-layer entities= . I expect fitting in SDN principles at various levels of federation and hi= erarchy to be the *only* way in which legacy networks can and will m= igrate to SDN.

 

Dave

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, August 06, 2014 1:04 PM
To: Dave Hood; Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org
Subject: RE: related standards work

 

Hi Dave,

 

I guess the SDN RG dis= cussion right now is interesting and some heated discussion around ONF and = IETF has some relevance to ACTN work.

 

First of all, I thank = for the pointer on the ONF SDN architecture. I think you and the contributo= rs did a good job on managing to publish a good quality document.

I came across Section = 6.7 in which to state very interesting statements in regards to some IETF p= rotocols such as GMPLS, BGP and PCEP:

 

6.7 Inter-domain c= ontrol communication

Taken to its extreme, the principle of= logically centralized control suggests that a single SDN controller have w= orldwide scope. However, a real-world SDN controller probably doesn’t encompass all endpoints of interest to its clients. Client s= ervices often extend into other technical or administrative domains. These = domains may include non-SDN networks.

Particularly when interfacing with non= -SDN-controlled networks that are already in place and working, it may be a= ppropriate that an SDN controller run a variety of existing protocols, for example BGP or GMPLS. When talking directly to another SDN = controller, the appropriate interface is a matter for further study, but ma= y well be extensions of these, or other, existing protocols, for example th= e path computation element communication protocol, PCEP [9].

Following the principle of parsimony= , new protocols should be developed only upon convincing evidence that no e= xisting protocol can be suitably used or adapted.

 

As you said in the ear= lier email, “it is explicitly *not* based on OpenFlow concepts= and it recognizes the existence of the ONF protocols as candidates to perf= orm some of the necessary functions, but with the caveat that they may require extension.”  I have a couple o= f questions:

 

1.&n= bsp;      Are there any = plans to extend ONF-based protocol extensions to support non-SDN networks (= I assumed that non-SDN is meant non-OF based)?  

2.&n= bsp;      Where do you t= hink the best place to work on extensions of GMPLS, BGP and PCEP to support= necessary functions discussed in your ONF SDN Architecture document?

 

The ACTN has a very di= fferent starting point (as I discussed with Eve and Stephen) than the ONF S= DN architecture and its controller functionality. What do I mean by that?

1.&n= bsp;      We avoid reinv= enting the wheel. Domain control as deployed in the form of control mechani= sms (e.g., GMPLS/ASON, PCE, EMS/NMS, etc.) will not be affected.

2.&n= bsp;      If and when an= OF-based Transport network domain comes to be with your SDN controller, AC= TN can take SDN transport control domain as a domain which consists of mult= i-domain of an operator network.

3.&n= bsp;      As indicated b= y many ACTN use-cases by operators, the main focus of ACTN is operator̵= 7;s multi-domain coordination to enable faster service provisioning and/or = allow network resource partitioning for various services operators should support on their deployed network enviro= nments (no green field here).

 

Regards,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Dave Hood
Sent: Friday, August 01, 2014 1:13 PM
To: Leeyoung; Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

One correction to th= e comment on the ONF SDN architecture: it is explicitly *not* based = on OpenFlow concepts. It recognizes the existence of the ONF protocols as candidates to perform some of the necessary functions, bu= t with the caveat that they may require extension.

 

This has been true t= hroughout the development of the architecture that has now been released.

 

Dave

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 10:34 AM
To: Varma, Eve L (Eve); Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Eve,

 

Good to hear from you = in ACTN list. Thanks for your comment. I think you clarified some misunders= tanding and confusion. Here’s my comment for you in-line.

 

Regards,

Young

 

From: Varma, E= ve L (Eve) [mailto:eve.varm= a@alcatel-lucent.com]
Sent: Thursday, July 31, 2014 12:06 PM
To: Leeyoung; Shew, Stephen; actn@i= etf.org
Subject: RE: related standards work

 

Hi Young,

 

Please see below for my two ce= nts ;-)

 

With best regards,<= /span>

Eve

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 12:44 PM
To: Shew, Stephen; actn@ietf.org
Subject: Re: [Actn] related standards work

 

Hi Stephen,=

 

Thanks for posting thi= s list of reference.

 

My overall comment is:= in light of many works in the past and even presently in other SDOs, it is= ironic that operators came to IETF to address their problems and see IETF = as viable and practical place for their problem to be solved.

 

<ELV> I am no= t surprised that operators are seeking to find solutions across a range of = standards and industry forums.  This is not exclusive to IETF – = e.g.,  consider related ETSI NVF work items. 

 

YOUNG>> Yes, = that is a reality.

 

From a transport netwo= rk perspective, there have been many tools IETF championed in regard to GMP= LS control plane, PCE and other configuration/management tools. Some of you= r pointer for ONF seems irrelevant to many operators as OF is a green-field for them.  As you were in the B= oF, the operators brought their current problems on their brown field. Are = you aware of any real deployment of ONF-based transport networks? ACTN can = certainly treat OF-based transport as a domain among others once it is deployed.

 

<ELV> The ref= erence was to a protocol-neutral SDN Architecture document (i.e., independe= nt of the protocol used over interfaces), which has some very useful materi= al that has also been shared with other SDOs, and IMHO is quite relevant to the ACTN problem domain.  I would certa= inly understand your comment if the document were focused/optimized for the= OF protocol.  However, it is not.  It is my view that protocol-i= ndependent architectural work should be examined regardless of what group produces it, as we have so many colleagues contri= buting across multiple standards and industry forums, which allows for leve= rage of applicable work.    

 

YOUNG>> The a= ssumption for SDN arch. Document (as far as I understand from the initial v= ersion) is, however, tied with OF based philosophy, meaning that the SDN co= ntroller is a “God”-box as to what to control as to how much it wants to know. The ACTN is on a different assumption. AC= TN control hierarchy would not touch existing domain control of many kinds = (e.g., GMPLS/ASON, PCE-based, NMS/EMS-based, etc.) and let them continue co= ntrol/operate their networks (which is one of the requirements from many operators). What they need is a overa= rching “overseer” that allows quick service provisioning based = on an end-to-end global abstraction view of all encompassing domains. For i= nstance, cross-connect and other low level control of NE will need not be abstracted in ACTN scope as these controls will con= tinue to be done at existing domain level control. I think this assumption = makes a huge difference. I believe what ACTN is trying to do based on opera= tors’ use-cases has a different starting point from what you are referring to, namely, the ONF SDN Control= architecture models has been trying to do. ACTN does not replace any exist= ing network control and operation. It builds on top of that.

 

 

 

Your Virtual network r= eference from ITU-T is quite theoretical and VPNs have been implemented in = L2VPN/L3VPN WGs focusing on practical issues. I also see some gap of many I= TU-T references and the reality.

 

<ELV> Perhaps= the language used in the ITU-T Rec. could be a barrier for some, but there= is useful information.  You’ll find some good material, leverag= ing this, in the SDN Architecture document discussion of this area.

 

YOUNG>> langu= age is always a tremendous stumbling block. J<= span style=3D"color:#1F497D"> I will try to update myself with the mentione= d references.

 

Your pointer for TMF i= s all appreciated. We will look at if data model is necessary to enable abs= traction. For TE model of IETF, we did not have either IM or DM in GMPLS/PC= E implementation. At this point, I am not sure if we need IM or DM. One of the homeworks from the BoF is to inve= stigate if we need IM/DM. If we do need IM/DM, there have been some efforts= in IETF around Yang and JSON. I have proposed JSON based abstraction model= s in the past in IETF (In a BoF called I2AEX under ALTO) , which seems working very well for transport net= work resource abstraction.  There are also BGP-LS based models that ha= ve progressed in IETF quite a bit. I tend to think these lists are a starti= ng point. TMF is a bit foreign to IETF and to me.

 

<ELV>  I= f one is looking from a broader transport networking perspective, an underl= ying information model from which various data models/interfaces can be der= ived enables interoperability (not to mention leverage of significant industry experience in networking & forwarding domain).=   However, this is a much larger discussion topic area (beyond ACTN).<= o:p>

 

YOUNG>> Agree= . My point is that models are only tools that should help the functions. As= pointed previously, for simple functions to fulfill, the validity of model= s needs to be carefully evaluated.

 

Thanks,

Young

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: actn@ietf.org
Subject: [Actn] related standards work

 

As discussed in the actn bof last week,= I list some related standards that I think should be considered by actn so= that things don’t get re-invented.

 

1= .   &= nbsp;  Virtual Network.  There ar= e various semantics to the word “virtual” so adopting or statin= g a definition is important. RFC4847 describes virtual networks in terms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both the d= ata plane aspect of VPNs as well as the control plane aspect.  Concept= s of private and shared VPNs are described.  I find them quite useful = and suggest that uses cases adopt these terms so that the commonality of the use cases can more readily be determined.=

2= .   &= nbsp;  Abstraction and arrangement of = control.  The recently published ONF SDN Architecture (https://www.open= networking.org/images/stories/downloads/sdn-resources/technical-reports/TR_= SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SDN controllers which= I think should be adopted by actn.  They define “abstraction= 221; in way that makes “virtual” a subset of abstraction. = Having a clear definition of the 2 terms is important.  The Multiple Vendor Domain T= ransport Networks use case could be covered by a limited hierarchy of SDN c= ontrollers.  One of the suggestions in the SDN Architecture document i= s that there may be a need for inter-domain control and this may be a gap that actn addresses.

3= .   &= nbsp;  Interfaces.  Implementatio= ns of interfaces imply some design, and it is helpful to expose that design= upfront so that limitations, extensibility, and commonality are understood.  To that end, use of a common information model has b= een beneficial.  I point in particular to TM Forum’s TR215 and i= s draft successor TR225.  From an information model, a more specific i= nformation model can be derived (like an instantiation of an aspect of the general one).  Then, data models can be developed= from that specific information model.  If a common information model = is used, then the particular encoding of the data model is less critical.&n= bsp; I don’t suggest that actn start with just a data model because the architecture behind it is not exposed.=

 

Stephen Shew | Director, Standards
sshew@cien= a.com | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

 

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F47C431eusaamb105erics_-- From nobody Thu Aug 7 05:33:09 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9281ABB23 for ; Thu, 7 Aug 2014 05:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 QGoqGgMQwr-0 for ; Thu, 7 Aug 2014 05:32:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7761A02ED for ; Thu, 7 Aug 2014 05:32:54 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s77CWjiI018641; Thu, 7 Aug 2014 13:32:45 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s77CWivv018611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 13:32:44 +0100 From: "Adrian Farrel" To: Date: Thu, 7 Aug 2014 13:32:48 +0100 Message-ID: <011f01cfb23b$b2f0e4e0$18d2aea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+yO6r6l0W9p7S7Ql2GUuO5IvwSbQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20864.006 X-TM-AS-Result: No--14.598-10.0-31-10 X-imss-scan-details: No--14.598-10.0-31-10 X-TMASE-MatchedRID: VVcOg/l/oH7hXsvDt/BQz37siEtWY367NNuh+5zmS68Dry5/qhdmxK+X B+i+fhrvzX5RaqRCsDJ+eSLaFktj6NtkAjIIK7ccVtZNMIeE5PEXZ6k61HUJz/0TP/kikeqnRie oXCkgihoEfA4J9jLLt9kVAVb359lcrjUR+Vfy4sycZTZ+HXkn2FAI6wCVrE3vbYFzfEj43Bizi0 AQ4R+iwbiJrfmQzGWrrMQ97QdLnjTDZWKfQinYBfOHbIp2eXtYGSqdEmeD/nVTuk1nx2Un4WpHK tkQBynKB4nXQQumWv1K/HdDS/GCI9ooGYFlLRsJ3akpBNcZ4UoZYA38gj3BxJXP+fN7LWAfZilV Rkf5Si73pb5hxMuPbkjqRIvXEdZ7BVwP6b8+JkgqptFPEIjUdI/8SyGg0rIR+yNYYwngrxYm3Wx JbYAWsZtFQKdM8wCFRRu4BtPjgPwYB2fOueQzjzl/1fD/Gopd2K+lN2ZUJHbEQdG7H66TyH4gKq 42LRYkI3vYQ+TRzUjeo4H+Y/2tGul8XB2/7ryylYcFEB7Ee71+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/actn/dXnizfVKfKNN6y9gYM4tz9MpfxE Cc: leeyoung@huawei.com, daniel@olddog.co.uk Subject: [Actn] AD's summary of ACTN BoF X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 12:32:59 -0000 Hi, Apologies for the delay after IETF-90 caused by an excess of travel. First, let me thank the chairs and all of you who spoke either to present or to ask questions / make comments from the floor. >From many perspectives, the ACTN BoF was successful. It was intended to provide a venue for network operators to talk about the type of problem they are trying to solve and the "pain points" they are encountering. From that perspective it was very valuable, and it is nice to see a forum where operators can share their thoughts and ideas without the vendors telling them what to think. The BoF was billed as a "non-WG forming BoF" and we can say that the BoF was very successful in that regard: no WG was formed ;-) In re-reading my notes from the BoF and looking at the minutes posted to this list (chairs: please be sure to post the minutes to the meetings materials page) I think there were some common threads visible in the presentations/use-cases from the different operators: - Desire to request end-to-end services over multi-domain/layer networks - Desire to express services to a network and to build abstract/virtual networks to support those services - A need to provision/control inter-domain links There may be some more common threads, but perhaps we should be looking for just a few ideas with wide support. However, I didn't come away with any clarity about what actually needs work. This should not be a huge surprise because that was not the top objective of the BoF, but it should be the next focus for people wanting to work in this area. We need to identify the topics that could be brought to the IETF for standardisation activities. To advance this, i suggest that the next step is for the proponents to convert the use-cases into an architecture (developing the documents that already exist) with the objective of seeing whether this architecture can be solved with existing tools or if new tools (protocols) need to be built. The result could be anything in a wide range including: - nothing to be done in the IETF - an applicability statement to show how to solve the problems with existing tools - some small protocol extensions (for example, a YANG model to represent/request a virtual network) - a requirements statement for new protocols or substantial protocol extensions. That is all a bit in the future. The first step, as i say, is to refine the use-cases and hone the architecture. I'll leave the mailing list open for discussion of the topic, but please remember it is not a working group! Thanks, Adrian From nobody Thu Aug 7 07:46:12 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E028B1B2B8D for ; Thu, 7 Aug 2014 07:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 M_82HPW541-A for ; Thu, 7 Aug 2014 07:46:05 -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 A6D601B2B85 for ; Thu, 7 Aug 2014 07:46:04 -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 BIA07808; Thu, 07 Aug 2014 14:46:02 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Aug 2014 15:46:00 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 07:45:53 -0700 From: Leeyoung To: "adrian@olddog.co.uk" , "actn@ietf.org" Thread-Topic: AD's summary of ACTN BoF Thread-Index: Ac+yO6r6l0W9p7S7Ql2GUuO5IvwSbQAEmeEA Date: Thu, 7 Aug 2014 14:45:52 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C090CE@dfweml706-chm.china.huawei.com> References: <011f01cfb23b$b2f0e4e0$18d2aea0$@olddog.co.uk> In-Reply-To: <011f01cfb23b$b2f0e4e0$18d2aea0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.102] 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/actn/IteLnCLqyQoRnxj2LTWNFPQ_GoA Cc: "daniel@olddog.co.uk" Subject: Re: [Actn] AD's summary of ACTN BoF X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:46:09 -0000 Hi Adrian, Thanks for providing AD's summary of ACTN BoF.=20 Meeting minutes have been uploaded per your reminder: https://datatracker.ietf.org/meeting/90/materials.html#rtg Best regards, Young -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Thursday, August 07, 2014 7:33 AM To: actn@ietf.org Cc: daniel@olddog.co.uk; Leeyoung Subject: AD's summary of ACTN BoF Hi, Apologies for the delay after IETF-90 caused by an excess of travel. First, let me thank the chairs and all of you who spoke either to present o= r to ask questions / make comments from the floor. >From many perspectives, the ACTN BoF was successful. It was intended to pro= vide a venue for network operators to talk about the type of problem they a= re trying to solve and the "pain points" they are encountering. From that p= erspective it was very valuable, and it is nice to see a forum where operat= ors can share their thoughts and ideas without the vendors telling them wha= t to think. The BoF was billed as a "non-WG forming BoF" and we can say that the BoF wa= s very successful in that regard: no WG was formed ;-) In re-reading my notes from the BoF and looking at the minutes posted to th= is list (chairs: please be sure to post the minutes to the meetings materia= ls page) I think there were some common threads visible in the presentation= s/use-cases from the different operators: - Desire to request end-to-end services over multi-domain/layer networks - Desire to express services to a network and to build abstract/virtual net= works to support those services - A need to provision/control inter-domain links There may be some more common threads, but perhaps we should be looking for= just a few ideas with wide support. However, I didn't come away with any clarity about what actually needs work= . This should not be a huge surprise because that was not the top objective o= f the BoF, but it should be the next focus for people wanting to work in th= is area. We need to identify the topics that could be brought to the IETF f= or standardisation activities. To advance this, i suggest that the next step is for the proponents to conv= ert the use-cases into an architecture (developing the documents that alrea= dy exist) with the objective of seeing whether this architecture can be sol= ved with existing tools or if new tools (protocols) need to be built. The result could be anything in a wide range including: - nothing to be done in the IETF - an applicability statement to show how to solve the problems with=20 existing tools - some small protocol extensions (for example, a YANG model to represent/request a virtual network) - a requirements statement for new protocols or substantial protocol extensions. That is all a bit in the future. The first step, as i say, is to refine the= use-cases and hone the architecture. I'll leave the mailing list open for discussion of the topic, but please re= member it is not a working group! Thanks, Adrian From nobody Wed Aug 13 09:57:19 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5901A094B for ; Wed, 13 Aug 2014 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_ROLLER_IS_T=1.357, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEuJ-WE7phbP for ; Wed, 13 Aug 2014 09:57: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 09D671A0947 for ; Wed, 13 Aug 2014 09:57:12 -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 BIF26654; Wed, 13 Aug 2014 16:57:11 +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, 13 Aug 2014 17:57:10 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 09:57:05 -0700 From: Leeyoung To: "actn@ietf.org" Thread-Topic: ACTN architecture/framework Thread-Index: Ac+3F2UdejCVGB9TRvSkym1DkSoAkQ== Date: Wed, 13 Aug 2014 16:57:03 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C12292@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.132] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C12292dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/qwwOgGkdHlfnZuYn1P3Bx-0LVbs Subject: [Actn] ACTN architecture/framework X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 16:57:18 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C12292dfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the action items from the BoF was to define an architecture framewor= k for ACTN. I think we can start based on the current framework document. h= ttp://tools.ietf.org/html/draft-ceccarelli-actn-framework-02 >From the framework, the term VNC (Virtual Network Controller) was defined t= o denote a control function for multi-domain virtual network coordination a= nd operation to give a global view and control of operator's multi-domain t= ransport networks. PNC (Physical Network Controller) was defined to denote= a domain control of different kinds (e.g., EMS/NMS, Control Plane like GMP= LS/ASON, or PCE based, etc.). Each PNC is responsible for its domain's cont= rol and operation such as provisioning, path computation, etc. Here's how the VNC and PNC functionality is captured from the framework dra= ft. The virtual network controller is composed by the following functional comp= onents: +------------------------------------------------------------------+ | | | Virtual +-------------+ +------------------------+ | | Network | VNS Proxy | | Abstract Topology DB | | | Controller +-------------+ +------------------------+ | | | | +-------------------+ +-------------------+ +---------------+ | | | Resource Manager | | vConnection Agent | |VNC OAM handler| | | +-------------------+ +-------------------+ +---------------+ | +----------------------------------------------------------------= --+ * VNS proxy: The VNS proxy is the functional module in charge of pe= rforming policy management and AAA (Authentication, authorization, and acco= unting) functions. It is the one that receives that VN instantiation and re= source allocation requests from the Customer controllers. * Abstract Topology DB: This is the database where the abstract top= ology, generated by the VNC or received from the PNC, is stored. A differen= t VN instance is kept for every different customer. * Resource Manager: The resource manager is in charge of receiving = VNS instantiation requests from the customer controller and, as a consequen= ce, triggering a concurrent path computation request to the PCE in the PNC = based on the traffic matrix. The Resource manager is also in charge of gene= rating the abstract topology for the customer. * vConnection Agent: This module is in charge of mapping VN setup c= ommands into network provisioning requests to the PNC. * VNC OAM handler: The VNC OAM handler is the module that is in cha= rge of understanding how the network is operating, detecting faults and rea= cting to problems related to the abstract topology. The physical network controller is the one in charge of configuring the net= work elements, monitoring the physical topology of the network and passing = it, either raw or abstracted, to the VNC. It is composed by the following functional components: +------------------------------------------------------------------+ | | | Physical +-----------+ +-----+ +------------------------+ | | Network | VNC Proxy | | PCE | | Abstract Topology Gen. | | | Controller +-----------+ +-----+ +------------------------+ | | | | +---------------+ +--------------------+ +--------------------+ | | |PNC OAM Handler| |Provisioning Manager| |Physical Topology DB| | | +---------------+ +--------------------+ +--------------------+ | +------------------------------------------------------------------+ * VNC proxy: The VNC proxy is the functional module in charge of pe= rforming policy management and AAA (Authentication, authorization, and acco= unting) functions on requests coming from the VNC. * PCE: This is the stateful PCE performing the path computation ove= r the physical topology and that provides the vConnection agent with the ne= twork topology. * Abstract topology generator: the network topology can be passed t= o the VNC as raw or abstract. In case the topology is passed as abstract to= pology, this module is in charge of generating it from the physical topolog= y DB. The module is optional. * ONC OAM handler: it verifies that connections exists, implements = monitoring functions to see if failures occurs. It is the proxy to an OSS/N= MS system but does not duplicate any of OSS/NMS functionalities. * Physical topology database: The physical topology database is mai= nly composed by two databases: the Traffic Engineering Database (TED) and t= he LSP Database (LSP-DB). * Provisioning manager: The Provisioning Manager is responsible for= making or channeling requests for the establishment of LSPs. This may be = instructions to the control plane running in the networks, or may involve t= he programming of individual network devices. In the latter case, the Prov= isioning Manager may act as an OpenFlow Controller [ONF]. >From this context, we can begin to discuss architectural discussion such as= interfaces functionality and work flows and information models between the= VNC and PNCs. Thanks, Young --_000_7AEB3D6833318045B4AE71C2C87E8E1729C12292dfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the action items from the BoF was to define a= n architecture framework for ACTN. I think we can start based on the curren= t framework document. h= ttp://tools.ietf.org/html/draft-ceccarelli-actn-framework-02=

 

From the framework, the term VNC (Virtual Network Co= ntroller) was defined to denote a control function for multi-domain virtual= network coordination and operation to give a global view and control of op= erator’s multi-domain transport networks.  PNC (Physical Network Controller) was defined to denote a domain control o= f different kinds (e.g., EMS/NMS, Control Plane like GMPLS/ASON, or PCE bas= ed, etc.). Each PNC is responsible for its domain’s control and opera= tion such as provisioning, path computation, etc.  

 

Here’s how the VNC and PNC functionality is ca= ptured from the framework draft.

 

The virtual network controller is composed by the fo= llowing functional components:

+-----------------------------------------------= -------------------+

|        &nb= sp;            =             &nb= sp;            =             &nb= sp;       |

| Virtual     +-------------= +        +----------------------= --+    |

| Network     | VNS Proxy &= nbsp; |        | Abstract Topology DB&nb= sp;  |    |

| Controller  +-------------+ &nbs= p;      +------------------------+ &n= bsp;  |

|        &nb= sp;            =             &nb= sp;            =             &nb= sp;       |

| +-------------------+  +---------= ----------+   +---------------+ |

| | Resource Manager  |  | vConnection Age= nt |   |VNC OAM handler| |

| +-------------------+  +---------= ----------+   +---------------+ |

        &nbs= p; +------------------------------------------------------------------+= ;                = ;    

·         VNS proxy: The VNS proxy is the functional m= odule in charge of performing policy management and AAA (Authentication, au= thorization, and accounting) functions. It is the one that receives that VN= instantiation and resource allocation requests from the Customer controllers.

·         Abstract Topology DB: This is the database w= here the abstract topology, generated by the VNC or received from the PNC, = is stored. A different VN instance is kept for every different customer.

·         Resource Manager: The resource manager is in= charge of receiving VNS instantiation requests from the customer controlle= r and, as a consequence, triggering a concurrent path computation request t= o the PCE in the PNC based on the traffic matrix. The Resource manager is also in charge of generating the a= bstract topology for the customer.

·         vConnection Agent: This module is in charge = of mapping VN setup commands into network provisioning requests to the PNC.=

·         VNC OAM handler: The VNC OAM handler is the = module that is in charge of understanding how the network is operating, det= ecting faults and reacting to problems related to the abstract topology.

 

The physical network controller is the one in charge= of configuring the network elements, monitoring the physical topology of t= he network and passing it, either raw or abstracted, to the VNC.=

It is composed by the following functional component= s:

+-----------------------------------------------= -------------------+

|        &nb= sp;            =             &nb= sp;            =             &nb= sp;       |

| Physical    +-----------+ &= #43;-----+   +------------------------+   |=

| Network     | VNC Proxy | | PC= E |   | Abstract Topology Gen. |   |

| Controller  +-----------+ +-----&= #43;   +------------------------+   |

|        &nb= sp;            =             &nb= sp;            =             &nb= sp;       |

| +---------------+ +-------------------= -+ +--------------------+  |

| |PNC OAM Handler| |Provisioning Manager| |Physical= Topology DB|  |

| +---------------+ +-------------------= -+ +--------------------+  |

   +----------------------------------------= --------------------------+       &n= bsp;        &nbs= p;   

·         VNC proxy: The VNC proxy is the functional m= odule in charge of performing policy management and AAA (Authentication, au= thorization, and accounting) functions on requests coming from the VNC.

·         PCE: This is the stateful PCE performing the= path computation over the physical topology and that provides the vConnect= ion agent with the network topology.

·         Abstract topology generator: the network top= ology can be passed to the VNC as raw or abstract. In case the topology is = passed as abstract topology, this module is in charge of generating it from= the physical topology DB. The module is optional.

·         ONC OAM handler: it verifies that connection= s exists, implements monitoring functions to see if failures occurs. It is = the proxy to an OSS/NMS system but does not duplicate any of OSS/NMS functi= onalities.

·         Physical topology database: The physical top= ology database is mainly composed by two databases: the Traffic Engineering= Database (TED) and the LSP Database (LSP-DB).

·         Provisioning manager: The Provisioning Manag= er is responsible for making or channeling requests for the establishment o= f LSPs.  This may be instructions to the control plane running in the = networks, or may involve the programming of individual network devices.  In the latter case, the Provisioning = Manager may act as an OpenFlow Controller [ONF].

>From this context, we can begin to discuss architectural discussion such as= interfaces functionality and work flows and information models between the= VNC and PNCs.

Thanks,

Young

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C12292dfweml706chm_-- From nobody Wed Aug 13 12:44:40 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507351A064D for ; Wed, 13 Aug 2014 12:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap_ZzHu5EqHx for ; Wed, 13 Aug 2014 12:44: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 6412F1A047B for ; Wed, 13 Aug 2014 12:44:24 -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 BLF12596; Wed, 13 Aug 2014 19:44:22 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 20:44:21 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 12:44:11 -0700 From: Leeyoung To: "actn@ietf.org" Thread-Topic: ACTN Requirements Thread-Index: Ac+3LvMW7oqwu1PSSrGIaHx6nEjHpg== Date: Wed, 13 Aug 2014 19:44:10 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C122EC@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.227] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C122ECdfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/_8bUWPkRAE5CjnNo7eW1cSEcpYU Subject: [Actn] ACTN Requirements X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 19:44:30 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C122ECdfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like to trigger a new thread of discussions on ACTN requirements. Ther= e are some service requirements identified by KDDI and China Mobile use-cas= e presentations on the need for network slicing by different internal servi= ces. If we were to work on this service interface between "customer" and VN= C, this might constitute a separate work on this interface. However, as a s= tarting point, we can begin with a VNC-PNC interface as this is a common th= read in all use-cases. Here's a list of areas for VNC-PNC interface requirements collected from us= e-cases. 1. VN Information Query /Response a. Abstraction level negotiation b. Constraints Filtering (B/W, latency, etc.) c. Abstracted Topology (VNs/VLs) i. Type= : TED like ii. Inclu= ding border VNs/VLs d. End-point information 2. VN Path Computation Request / Reply a. Path level abstraction - LSP DB like b. Diversity calculation c. Border/gateway nodes/links 3. VN Path Request Signaling (Setup) / Reply a. Per domain path request i. Sing= le request ii. Multi= ple requests - diversity path request, etc. b. Domain sequence kept at VNC c. Coordination of signaling (multi-domain) 4. VN Path Modification/Rerouting/re-grooming 5. VN Performance Monitoring a. VN Connection Failure and other degradation report b. Pull/Push Models Thanks, Young --_000_7AEB3D6833318045B4AE71C2C87E8E1729C122ECdfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’d like to trigger a new thread of discussion= s on ACTN requirements.  There are some service requirements identifie= d by KDDI and China Mobile use-case presentations on the need for network s= licing by different internal services. If we were to work on this service interface between “customer” and = VNC, this might constitute a separate work on this interface. However, as a= starting point, we can begin with a VNC-PNC interface as this is a common = thread in all use-cases.

 

Here’s a list of areas for VNC-PNC interface r= equirements collected from use-cases.

 

1.       VN Information Query /Response

a.       Abstraction level negotiation

b.      Constraints Filtering (B/W, latency, etc.)

c.       Abstracted Topology (VNs/VLs)

       =             &nb= sp;            =             &nb= sp;            =       i.  = ;    Type:  TED like

       =             &nb= sp;            =             &nb= sp;            =     ii. &nbs= p;    Including border VNs/VLs<= /o:p>

d.      End-point information

2.       VN Path Computation Request / Reply

a.       Path level abstraction – LSP DB like

b.      Diversity calculation

c.       Border/gateway nodes/links

3.       VN Path Request Signaling (Setup) / Reply

a.       Per domain path request

       =             &nb= sp;            =             &nb= sp;            =       i.  = ;    Single request

       =             &nb= sp;            =             &nb= sp;            =     ii. &nbs= p;    Multiple requests – dive= rsity path request, etc.

b.      Domain sequence kept at VNC

c.       Coordination of signaling (multi-domain)

4.       VN Path Modification/Rerouting/re-grooming  

5.       VN Performance Monitoring

a.       VN Connection Failure and other degradation report =

b.      Pull/Push Models

Thanks,

Young

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C122ECdfweml706chm_-- From nobody Mon Aug 18 03:08:08 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2281A03A5 for ; Mon, 18 Aug 2014 03:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 QhQRgBir2J_1 for ; Mon, 18 Aug 2014 03:08:04 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1021A0340 for ; Mon, 18 Aug 2014 03:08:03 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so4013071lbd.28 for ; Mon, 18 Aug 2014 03:07:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=dz/C/+bKqYvio25knuVkhrEmIyZPlGDdn5t2Romoa3Q=; b=iIDEUl5dfx4xeOHL/8+uWq0UF1++wtqCtdT9plGgGOgUnvByRGzVH0YSDL8DCIek/b ker8+TaOgEjgILzpjjbi9inAF+kP8cNxpjplKcfqeieAlKvOMgTNZGf5z3LVGco7Fin5 G2v70yVduRbUxwHvpq4Bc/L/4Cv1EtlRe8C0zrOHpKUoRtJ5h0X8hECL4LmxwYkGNsVX 4pC/6dLD9WWez0IFIEAi3wYG2FkYvY8FbLCQt/xXxI/XquorRZoBveaL9ftIf/hRxytO j3SSWyikLAJOWuAeZzQPqw/lQNk1bCwFMqlPE6CP0AJgKaGIDEMfJ+o9wZNdnJh3WY5r 5MdQ== X-Gm-Message-State: ALoCoQnf/0Mzu614oDfa4PqblniafHcZVdrChn0ZcojxOl3AzGjoJlrcftLu6X7va/Cf4QudCKj2 X-Received: by 10.112.155.226 with SMTP id vz2mr26914409lbb.23.1408356478541; Mon, 18 Aug 2014 03:07:58 -0700 (PDT) From: Nico Wauters References: <7AEB3D6833318045B4AE71C2C87E8E1729C122EC@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C122EC@dfweml706-chm> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGUqCW2YcnRVi3XhFmnBGIP4iEjn5xMRoMw Date: Mon, 18 Aug 2014 12:08:01 +0200 Message-ID: To: Leeyoung , actn@ietf.org Content-Type: multipart/alternative; boundary=089e0118281c9ef5600500e48be9 Archived-At: http://mailarchive.ietf.org/arch/msg/actn/2MNBbI2-sI7kuvOiUzNVxuCFe08 Subject: Re: [Actn] ACTN Requirements X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 10:08:06 -0000 --089e0118281c9ef5600500e48be9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lee, On your proposal, I assume that some use cases require a good understanding of diversity or risk sharing. Can we include in Abstracted topology (section 1.c) also publishing of shared risk information (e.g. by listing SRGID=E2=80=99s)? In case links (of the abstracted topology) have common SPOF=E2=80=99s, the = VNC should be informed about this. Regards Nico *From:* Leeyoung [mailto:leeyoung@huawei.com] *Sent:* woensdag 13 augustus 2014 21:44 *To:* actn@ietf.org *Subject:* [Actn] ACTN Requirements I=E2=80=99d like to trigger a new thread of discussions on ACTN requirement= s. There are some service requirements identified by KDDI and China Mobile use-case presentations on the need for network slicing by different internal services. If we were to work on this service interface between =E2=80=9Ccustomer=E2=80=9D and VNC, this might constitute a separate work o= n this interface. However, as a starting point, we can begin with a VNC-PNC interface as this is a common thread in all use-cases. Here=E2=80=99s a list of areas for VNC-PNC interface requirements collected= from use-cases. 1. VN Information Query /Response a. Abstraction level negotiation b. Constraints Filtering (B/W, latency, etc.) c. Abstracted Topology (VNs/VLs) i. Type= : TED like ii. Inclu= ding border VNs/VLs d. End-point information 2. VN Path Computation Request / Reply a. Path level abstraction =E2=80=93 LSP DB like b. Diversity calculation c. Border/gateway nodes/links 3. VN Path Request Signaling (Setup) / Reply a. Per domain path request i. Sing= le request ii. Multi= ple requests =E2=80=93 diversity path request, etc. b. Domain sequence kept at VNC c. Coordination of signaling (multi-domain) 4. VN Path Modification/Rerouting/re-grooming 5. VN Performance Monitoring a. VN Connection Failure and other degradation report b. Pull/Push Models Thanks, Young --089e0118281c9ef5600500e48be9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Lee,

=C2=A0

On your= proposal,

=C2=A0

I assume that some use cases require a good unders= tanding of diversity or risk sharing.

=C2=A0<= /span>

Can we include in Abstracted topology (section 1.c) also publishing of s= hared risk information (e.g. by listing SRGID=E2=80=99s)?

=C2=A0<= /span>

In case links (of the abstracted topology) have common SPOF=E2=80=99s, t= he VNC should be informed about this.

=C2=A0<= /span>

Regards

Nico

=C2=A0<= /span>

=C2=A0

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: woensdag 13 augustus 2014 21:44
To: actn@ietf.org
Subject: [Actn] ACTN Requireme= nts

=C2=A0

=C2=A0

I=E2=80=99d like to trigger a new thread of = discussions on ACTN requirements.=C2=A0 There are some service requirements= identified by KDDI and China Mobile use-case presentations on the need for= network slicing by different internal services. If we were to work on this= service interface between =E2=80=9Ccustomer=E2=80=9D and VNC, this might c= onstitute a separate work on this interface. However, as a starting point, = we can begin with a VNC-PNC interface as this is a common thread in all use= -cases.

=C2=A0

Here=E2=80=99s a list of areas for VNC-PNC in= terface requirements collected from use-cases.

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 VN Information Query= /Response

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Abstraction level negotiation

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Constraints Filtering (B/W, latency, etc.)

c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Abstracted Topology (VNs/VLs)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 i.= Type:=C2=A0 TED like

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Including border VNs/VLs

d.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 En= d-point information

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 VN Path Computation Request / Reply

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Path level abstraction =E2=80=93 LSP DB like

<= p class=3D"MsoListParagraph" style=3D"margin-left:72.0pt"> b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Diversity calculation

c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Border/gateway nodes/links=

3.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 VN Path Request Sign= aling (Setup) / Reply

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Per domain path request

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 i.= Single request

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Multiple requests =E2=80= =93 diversity path request, etc.

b.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do= main sequence kept at VNC

c.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Coordination of signaling (multi-domain)

4.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 VN Path Modification= /Rerouting/re-grooming =C2=A0

5.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 VN Performance Monit= oring

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 VN Connection Failure and other degradation report

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pull/Push Models

Thanks,

Young

--089e0118281c9ef5600500e48be9-- From nobody Mon Aug 18 08:35:25 2014 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5B41A063E for ; Mon, 18 Aug 2014 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgVC_hMDS5_V for ; Mon, 18 Aug 2014 08:35: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 1C59E1A0564 for ; Mon, 18 Aug 2014 08:35:21 -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 BIJ33279; Mon, 18 Aug 2014 15:35:20 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Aug 2014 16:35:19 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Mon, 18 Aug 2014 08:35:12 -0700 From: Leeyoung To: Nico Wauters , "actn@ietf.org" Thread-Topic: [Actn] ACTN Requirements Thread-Index: Ac+3LvMW7oqwu1PSSrGIaHx6nEjHpgD2AQyAAATI/LA= Date: Mon, 18 Aug 2014 15:35:11 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C13D7F@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C122EC@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.105] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C13D7Fdfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/actn/6o_CAQcoBXfHgJOemStJfdWnRzQ Subject: Re: [Actn] ACTN Requirements X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:35:24 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C13D7Fdfweml706chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljbywNCg0KWWVzLCB0aGlzIGlzIGFkZHJlc3NlZCBieSBzb21lIHVzZS1jYXNlcy4gSW4g dGhlIGluaXRpYWwgVk4gYWJzdHJhY3RlZCB0b3BvbG9neSBzaG91bGQgaW5kaWNhdGUgc2luZ2xl IHBvaW50IG9mIGZhaWx1cmUgKFNQT0YpLiBPbmUgd2F5IHRvIGRvIGl0IGZvciBsaW5rcyBpcyBh cyB5b3Ugc2FpZCBTUkxHIElELiAgRm9yIHNvbWUgYXBwbGljYXRpb24sIEkgY2FuIHRoaW5rIHRo YXQgVk4gTm9kZSBsZXZlbCBTUE9GIGluZGljYXRvciBtYXkgYmUgbmVlZGVkLg0KDQpJbiBhbGwg Y2FzZSwgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IFZOQyBuZWVkcyB0byBiZSBpbmZvcm1lZCBvZiB0 aGF0Lg0KDQpUaGFua3MsDQpZb3VuZw0KDQoNCkZyb206IE5pY28gV2F1dGVycyBbbWFpbHRvOm5p Y28ud2F1dGVyc0BuZXR3b3JrbWluaW5nLmNvbV0NClNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAy MDE0IDU6MDggQU0NClRvOiBMZWV5b3VuZzsgYWN0bkBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtB Y3RuXSBBQ1ROIFJlcXVpcmVtZW50cw0KDQpMZWUsDQoNCk9uIHlvdXIgcHJvcG9zYWwsDQoNCkkg YXNzdW1lIHRoYXQgc29tZSB1c2UgY2FzZXMgcmVxdWlyZSBhIGdvb2QgdW5kZXJzdGFuZGluZyBv ZiBkaXZlcnNpdHkgb3IgcmlzayBzaGFyaW5nLg0KDQpDYW4gd2UgaW5jbHVkZSBpbiBBYnN0cmFj dGVkIHRvcG9sb2d5IChzZWN0aW9uIDEuYykgYWxzbyBwdWJsaXNoaW5nIG9mIHNoYXJlZCByaXNr IGluZm9ybWF0aW9uIChlLmcuIGJ5IGxpc3RpbmcgU1JHSUTigJlzKT8NCg0KSW4gY2FzZSBsaW5r cyAob2YgdGhlIGFic3RyYWN0ZWQgdG9wb2xvZ3kpIGhhdmUgY29tbW9uIFNQT0bigJlzLCB0aGUg Vk5DIHNob3VsZCBiZSBpbmZvcm1lZCBhYm91dCB0aGlzLg0KDQpSZWdhcmRzDQpOaWNvDQoNCg0K RnJvbTogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tPG1haWx0bzpsZWV5b3Vu Z0BodWF3ZWkuY29tPl0NClNlbnQ6IHdvZW5zZGFnIDEzIGF1Z3VzdHVzIDIwMTQgMjE6NDQNClRv OiBhY3RuQGlldGYub3JnPG1haWx0bzphY3RuQGlldGYub3JnPg0KU3ViamVjdDogW0FjdG5dIEFD VE4gUmVxdWlyZW1lbnRzDQoNCg0KSeKAmWQgbGlrZSB0byB0cmlnZ2VyIGEgbmV3IHRocmVhZCBv ZiBkaXNjdXNzaW9ucyBvbiBBQ1ROIHJlcXVpcmVtZW50cy4gIFRoZXJlIGFyZSBzb21lIHNlcnZp Y2UgcmVxdWlyZW1lbnRzIGlkZW50aWZpZWQgYnkgS0RESSBhbmQgQ2hpbmEgTW9iaWxlIHVzZS1j YXNlIHByZXNlbnRhdGlvbnMgb24gdGhlIG5lZWQgZm9yIG5ldHdvcmsgc2xpY2luZyBieSBkaWZm ZXJlbnQgaW50ZXJuYWwgc2VydmljZXMuIElmIHdlIHdlcmUgdG8gd29yayBvbiB0aGlzIHNlcnZp Y2UgaW50ZXJmYWNlIGJldHdlZW4g4oCcY3VzdG9tZXLigJ0gYW5kIFZOQywgdGhpcyBtaWdodCBj b25zdGl0dXRlIGEgc2VwYXJhdGUgd29yayBvbiB0aGlzIGludGVyZmFjZS4gSG93ZXZlciwgYXMg YSBzdGFydGluZyBwb2ludCwgd2UgY2FuIGJlZ2luIHdpdGggYSBWTkMtUE5DIGludGVyZmFjZSBh cyB0aGlzIGlzIGEgY29tbW9uIHRocmVhZCBpbiBhbGwgdXNlLWNhc2VzLg0KDQpIZXJl4oCZcyBh IGxpc3Qgb2YgYXJlYXMgZm9yIFZOQy1QTkMgaW50ZXJmYWNlIHJlcXVpcmVtZW50cyBjb2xsZWN0 ZWQgZnJvbSB1c2UtY2FzZXMuDQoNCg0KMS4gICAgICAgVk4gSW5mb3JtYXRpb24gUXVlcnkgL1Jl c3BvbnNlDQoNCmEuICAgICAgIEFic3RyYWN0aW9uIGxldmVsIG5lZ290aWF0aW9uDQoNCmIuICAg ICAgQ29uc3RyYWludHMgRmlsdGVyaW5nIChCL1csIGxhdGVuY3ksIGV0Yy4pDQoNCmMuICAgICAg IEFic3RyYWN0ZWQgVG9wb2xvZ3kgKFZOcy9WTHMpDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGkuICAgICAgVHlwZTogIFRF RCBsaWtlDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBpaS4gICAgICBJbmNsdWRpbmcgYm9yZGVyIFZOcy9WTHMNCg0KZC4gICAg ICBFbmQtcG9pbnQgaW5mb3JtYXRpb24NCg0KMi4gICAgICAgVk4gUGF0aCBDb21wdXRhdGlvbiBS ZXF1ZXN0IC8gUmVwbHkNCg0KYS4gICAgICAgUGF0aCBsZXZlbCBhYnN0cmFjdGlvbiDigJMgTFNQ IERCIGxpa2UNCg0KYi4gICAgICBEaXZlcnNpdHkgY2FsY3VsYXRpb24NCg0KYy4gICAgICAgQm9y ZGVyL2dhdGV3YXkgbm9kZXMvbGlua3MNCg0KMy4gICAgICAgVk4gUGF0aCBSZXF1ZXN0IFNpZ25h bGluZyAoU2V0dXApIC8gUmVwbHkNCg0KYS4gICAgICAgUGVyIGRvbWFpbiBwYXRoIHJlcXVlc3QN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgaS4gICAgICBTaW5nbGUgcmVxdWVzdA0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWkuICAgICAgTXVsdGlwbGUg cmVxdWVzdHMg4oCTIGRpdmVyc2l0eSBwYXRoIHJlcXVlc3QsIGV0Yy4NCg0KYi4gICAgICBEb21h aW4gc2VxdWVuY2Uga2VwdCBhdCBWTkMNCg0KYy4gICAgICAgQ29vcmRpbmF0aW9uIG9mIHNpZ25h bGluZyAobXVsdGktZG9tYWluKQ0KDQo0LiAgICAgICBWTiBQYXRoIE1vZGlmaWNhdGlvbi9SZXJv dXRpbmcvcmUtZ3Jvb21pbmcNCg0KNS4gICAgICAgVk4gUGVyZm9ybWFuY2UgTW9uaXRvcmluZw0K DQphLiAgICAgICBWTiBDb25uZWN0aW9uIEZhaWx1cmUgYW5kIG90aGVyIGRlZ3JhZGF0aW9uIHJl cG9ydA0KDQpiLiAgICAgIFB1bGwvUHVzaCBNb2RlbHMNClRoYW5rcywNCllvdW5nDQo= --_000_7AEB3D6833318045B4AE71C2C87E8E1729C13D7Fdfweml706chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbToxMC4wcHQ7DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglsaW5lLWhl aWdodDoxMTUlOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIE5pY28sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5ZZXMsIHRoaXMgaXMgYWRkcmVzc2VkIGJ5IHNvbWUgdXNlLWNhc2Vz LiBJbiB0aGUgaW5pdGlhbCBWTiBhYnN0cmFjdGVkIHRvcG9sb2d5IHNob3VsZCBpbmRpY2F0ZSBz aW5nbGUgcG9pbnQgb2YgZmFpbHVyZSAoU1BPRikuIE9uZSB3YXkgdG8gZG8gaXQgZm9yIGxpbmtz IGlzIGFzIHlvdSBzYWlkIFNSTEcgSUQuICZuYnNwO0ZvciBzb21lIGFwcGxpY2F0aW9uLCBJIGNh bg0KIHRoaW5rIHRoYXQgVk4gTm9kZSBsZXZlbCBTUE9GIGluZGljYXRvciBtYXkgYmUgbmVlZGVk LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIGFsbCBjYXNlLCBJIGFn cmVlIHdpdGggeW91IHRoYXQgVk5DIG5lZWRzIHRvIGJlIGluZm9ybWVkIG9mIHRoYXQuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ WW91bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTmljbyBXYXV0ZXJzIFttYWlsdG86bmlj by53YXV0ZXJzQG5ldHdvcmttaW5pbmcuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg QXVndXN0IDE4LCAyMDE0IDU6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IExlZXlvdW5nOyBhY3RuQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQWN0bl0gQUNUTiBSZXF1aXJlbWVudHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+TGVlLDwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9u IHlvdXIgcHJvcG9zYWwsIDwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYXNzdW1l IHRoYXQgc29tZSB1c2UgY2FzZXMgcmVxdWlyZSBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiBkaXZl cnNpdHkgb3IgcmlzayBzaGFyaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNh biB3ZSBpbmNsdWRlIGluIEFic3RyYWN0ZWQgdG9wb2xvZ3kgKHNlY3Rpb24gMS5jKSBhbHNvIHB1 Ymxpc2hpbmcgb2Ygc2hhcmVkIHJpc2sgaW5mb3JtYXRpb24gKGUuZy4gYnkgbGlzdGluZyBTUkdJ ROKAmXMpPzwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIGNhc2UgbGlua3MgKG9m IHRoZSBhYnN0cmFjdGVkIHRvcG9sb2d5KSBoYXZlIGNvbW1vbiBTUE9G4oCZcywgdGhlIFZOQyBz aG91bGQgYmUgaW5mb3JtZWQgYWJvdXQgdGhpcy48L3NwYW4+PHNwYW4gbGFuZz0iTkwtQkUiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iTkwtQkUiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5SZWdhcmRzPC9zcGFuPjxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Tmlj bzwvc3Bhbj48c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMZWV5b3Vu ZyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tIj5sZWV5b3VuZ0Bo dWF3ZWkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiB3b2Vuc2RhZyAxMyBhdWd1c3R1cyAy MDE0IDIxOjQ0PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86YWN0bkBpZXRmLm9yZyI+ YWN0bkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0FjdG5dIEFDVE4gUmVxdWly ZW1lbnRzPC9zcGFuPjxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwtQkUiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iTkwtQkUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlkIGxpa2UgdG8gdHJp Z2dlciBhIG5ldyB0aHJlYWQgb2YgZGlzY3Vzc2lvbnMgb24gQUNUTiByZXF1aXJlbWVudHMuJm5i c3A7IFRoZXJlIGFyZSBzb21lIHNlcnZpY2UgcmVxdWlyZW1lbnRzIGlkZW50aWZpZWQgYnkgS0RE SSBhbmQgQ2hpbmEgTW9iaWxlIHVzZS1jYXNlIHByZXNlbnRhdGlvbnMgb24gdGhlIG5lZWQgZm9y IG5ldHdvcmsgc2xpY2luZyBieSBkaWZmZXJlbnQgaW50ZXJuYWwgc2VydmljZXMuIElmIHdlDQog d2VyZSB0byB3b3JrIG9uIHRoaXMgc2VydmljZSBpbnRlcmZhY2UgYmV0d2VlbiDigJxjdXN0b21l cuKAnSBhbmQgVk5DLCB0aGlzIG1pZ2h0IGNvbnN0aXR1dGUgYSBzZXBhcmF0ZSB3b3JrIG9uIHRo aXMgaW50ZXJmYWNlLiBIb3dldmVyLCBhcyBhIHN0YXJ0aW5nIHBvaW50LCB3ZSBjYW4gYmVnaW4g d2l0aCBhIFZOQy1QTkMgaW50ZXJmYWNlIGFzIHRoaXMgaXMgYSBjb21tb24gdGhyZWFkIGluIGFs bCB1c2UtY2FzZXMuDQo8c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gbGFuZz0iTkwtQkUiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmXigJlzIGEgbGlzdCBvZiBhcmVh cyBmb3IgVk5DLVBOQyBpbnRlcmZhY2UgcmVxdWlyZW1lbnRzIGNvbGxlY3RlZCBmcm9tIHVzZS1j YXNlcy4NCjxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+Vk4gSW5mb3JtYXRpb24gUXVlcnkgL1Jlc3BvbnNlPHNwYW4gbGFuZz0i TkwtQkUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPmEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+QWJzdHJhY3Rpb24gbGV2ZWwgbmVnb3RpYXRpb248c3BhbiBsYW5nPSJOTC1CRSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+Yi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2xpbmUt aGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5Db25z dHJhaW50cyBGaWx0ZXJpbmcgKEIvVywgbGF0ZW5jeSwgZXRjLik8c3BhbiBsYW5nPSJOTC1CRSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+Yy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2xpbmUt aGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj5BYnN0cmFjdGVkIFRvcG9sb2d5IChWTnMvVkxzKTxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2xpbmUtaGVpZ2h0OjEx NSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5pLjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPlR5cGU6Jm5ic3A7IFRFRCBsaWtlIDxzcGFuIGxhbmc9Ik5MLUJF Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2xpbmUt aGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5paS48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj5JbmNsdWRpbmcgYm9yZGVyIFZOcy9WTHM8c3BhbiBsYW5nPSJOTC1C RSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ZC48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2xp bmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5F bmQtcG9pbnQgaW5mb3JtYXRpb24gPHNwYW4gbGFuZz0iTkwtQkUiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj4yLjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPlZOIFBhdGggQ29tcHV0YXRpb24gUmVxdWVzdCAvIFJlcGx5IDxzcGFu IGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5hLjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPlBhdGggbGV2ZWwgYWJzdHJhY3Rpb24g4oCTIExTUCBEQiBsaWtlPHNw YW4gbGFuZz0iTkwtQkUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPmIuPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+RGl2ZXJzaXR5IGNhbGN1bGF0aW9uIDxzcGFuIGxhbmc9Ik5MLUJFIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj5jLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWln aHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPkJv cmRlci9nYXRld2F5IG5vZGVzL2xpbmtzIDxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+My48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj5WTiBQYXRoIFJlcXVlc3QgU2lnbmFsaW5nIChTZXR1cCkgLyBS ZXBseTxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5hLjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlBlciBkb21haW4gcGF0aCByZXF1ZXN0IDxzcGFuIGxh bmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj5pLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlNpbmdsZSByZXF1ZXN0PHNwYW4g bGFuZz0iTkwtQkUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmlpLjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPk11bHRpcGxlIHJlcXVlc3RzIOKAkyBkaXZlcnNp dHkgcGF0aCByZXF1ZXN0LCBldGMuIDxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj5iLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPkRvbWFpbiBzZXF1ZW5jZSBrZXB0 IGF0IFZOQzxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5jLjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPkNvb3JkaW5hdGlvbiBvZiBzaWduYWxpbmcgKG11 bHRpLWRvbWFpbikgPHNwYW4gbGFuZz0iTkwtQkUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj40LjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPlZOIFBhdGggTW9kaWZpY2F0aW9uL1Jlcm91dGluZy9yZS1ncm9vbWluZyAmbmJzcDs8 c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiPjUuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtsaW5lLWhlaWdodDox MTUlO2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+Vk4gUGVy Zm9ybWFuY2UgTW9uaXRvcmluZzxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij5hLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlZOIENvbm5lY3Rpb24gRmFp bHVyZSBhbmQgb3RoZXIgZGVncmFkYXRpb24gcmVwb3J0IDxzcGFuIGxhbmc9Ik5MLUJFIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj5iLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bGluZS1oZWln aHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlB1bGwvUHVz aCBNb2RlbHM8c3BhbiBsYW5nPSJOTC1CRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxzcGFuIGxhbmc9Ik5MLUJFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3VuZzxzcGFuIGxhbmc9Ik5MLUJFIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729C13D7Fdfweml706chm_--