From csikor@tmit.bme.hu Thu Aug 1 00:52:03 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8236D21F8D6D for ; Thu, 1 Aug 2013 00:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.598 X-Spam-Level: ** X-Spam-Status: No, score=2.598 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO5+ZoaBHqkz for ; Thu, 1 Aug 2013 00:51:57 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9177521F8CB0 for ; Thu, 1 Aug 2013 00:51:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id CBBBA87350; Thu, 1 Aug 2013 09:51:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk7E587WMxiF; Thu, 1 Aug 2013 09:51:35 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 7D20D87346; Thu, 1 Aug 2013 09:51:35 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r717pflX029444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 09:51:41 +0200 Message-ID: <51FA138A.3090807@tmit.bme.hu> Date: Thu, 01 Aug 2013 09:51:38 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtgwg@ietf.org, cbowers@juniper.net Subject: Re: issue with cost-based formulation of extended P-space in draft-ietf-rtgwg-remote-lfa-02 References: <145B98DA3B8D164BA479E1AC5316E6AF1472EDF8@BN1PRD0512MB667.namprd05.prod.outlook.com> In-Reply-To: <145B98DA3B8D164BA479E1AC5316E6AF1472EDF8@BN1PRD0512MB667.namprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------020407050804060005010104" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:52:03 -0000 This is a multi-part message in MIME format. --------------020407050804060005010104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear Chris, you have right that the draft's conditionof ext-P-space in cost terms is incorrect and not well-specified. I foundthat (2)is exactly the same that we found and described in our related papers (check previous mails in the rlfa-rtgwg thread). However, (1)is actually the condition of the simple P-space in costterms. If you are interested, how these conditions regarding to costterms change if node-protection is also taken into account, just read our last paper (http://csikor.tmit.bme.hu/remoteLFA/remote_lfa_telsys.pdf). Regards, Levente On 07/30/2013 02:08 PM, Chris Bowers wrote: > It appears that the cost-based formulation for determining the > extended P-space in draft-ietf-rtgwg-remote-lfa-02 is incorrect. In > particular, section 4.2.2 says: > “In cost terms a router is in extended P-space if the shortest path > cost S-N->P is strictly less than the shortest path cost S-E->P.” > Instead, the requirement should be that the shortest path cost N->P is > strictly less than cost N-S-E->P. > I propose the following text for section 4.2.2. > “In terms of cost, a router Y is in the extended P-space of S with > respect to the failure of link S-E, if either of the two following > conditions is true: > (1) D_opt(S,Y) < D_opt(S,E) + D_opt(E,Y) > OR > (2) S has a neighbor N satisfying the inequality: > D_opt(N,Y) < D_opt(N,S) + D_opt(S,E) + D_opt(E,Y)” > This text corrects the error noted above, and it puts both of the > criteria for determining extended P-space in terms of cost in one > place in the text. > Chris > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --------------020407050804060005010104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear Chris,

you have right that the draft's condition of ext-P-space in cost terms is incorrect and not well-specified.

I found that (2) is exactly the same that we found and described in our related papers (check previous mails in the rlfa-rtgwg thread). However, (1) is actually the condition of the simple P-space in cost terms.

If you are interested, how these conditions regarding to cost terms change if node-protection is also taken into account, just read our last paper  (http://csikor.tmit.bme.hu/remoteLFA/remote_lfa_telsys.pdf).

Regards,
Levente
On 07/30/2013 02:08 PM, Chris Bowers wrote:
It appears that the cost-based formulation for determining the extended P-space in draft-ietf-rtgwg-remote-lfa-02 is incorrect.  In particular, section 4.2.2 says:
 
“In cost terms a router is in extended P-space if the shortest path cost S-N->P is strictly less than the shortest path cost S-E->P.”
 
Instead, the requirement should be that the shortest path cost N->P is strictly less than cost N-S-E->P. 
 
I propose the following text for section 4.2.2.
 
“In terms of cost, a router Y is in the extended P-space of S with respect to the failure of link S-E, if either of the two following conditions is true:
(1) D_opt(S,Y) < D_opt(S,E) + D_opt(E,Y)
OR
(2) S has a neighbor N satisfying the inequality:
D_opt(N,Y) < D_opt(N,S) + D_opt(S,E) + D_opt(E,Y)”
 
This text corrects the error noted above, and it puts both of the criteria for determining extended P-space in terms of cost in one place in the text.
 
Chris
 
 

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

--------------020407050804060005010104-- From wwwrun@rfc-editor.org Thu Aug 1 01:55:59 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF721F9E8B; Thu, 1 Aug 2013 01:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2s5IUnhxE2g; Thu, 1 Aug 2013 01:55:58 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 562F321F9ED1; Thu, 1 Aug 2013 01:55:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 186B36212E; Thu, 1 Aug 2013 01:52:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6981 on A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses From: rfc-editor@rfc-editor.org Message-Id: <20130801085222.186B36212E@rfc-editor.org> Date: Thu, 1 Aug 2013 01:52:22 -0700 (PDT) Cc: drafts-update-ref@iana.org, rtgwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:55:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6981 Title: A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses Author: S. Bryant, S. Previdi, M. Shand Status: Informational Stream: IETF Date: August 2013 Mailbox: stbryant@cisco.com, sprevidi@cisco.com, imc.shand@googlemail.com Pages: 34 Characters: 79311 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rtgwg-ipfrr-notvia-addresses-11.txt URL: http://www.rfc-editor.org/rfc/rfc6981.txt This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics. The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. This document is a product of the Routing Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From csikor@tmit.bme.hu Thu Aug 1 07:11:17 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEBE21E8200 for ; Thu, 1 Aug 2013 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.527 X-Spam-Level: ** X-Spam-Status: No, score=2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1mLUM7t0A+s for ; Thu, 1 Aug 2013 07:11:12 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id BCDEE21E81FE for ; Thu, 1 Aug 2013 07:11:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 8A86A87350; Thu, 1 Aug 2013 16:11:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqchqGoN6EtI; Thu, 1 Aug 2013 16:10:46 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 0AFED87346; Thu, 1 Aug 2013 16:10:44 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r71EAsID013365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 16:10:54 +0200 Message-ID: <51FA6C6A.4090200@tmit.bme.hu> Date: Thu, 01 Aug 2013 16:10:50 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> In-Reply-To: <51D308D0.5090707@cisco.com> Content-Type: multipart/alternative; boundary="------------010003000902060000060800" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:11:17 -0000 This is a multi-part message in MIME format. --------------010003000902060000060800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear All, since our previous works in remote LFA analysis (papers already sent to these mailing lists) assumed unit cost networks, therefore as I promised, I calculated the corresponding LFA and rLFA coverages in those networks with their original link costs. These networks were inferred from Rocketfuel dataset (/Mahajan, R., Spring, N., Wetherall, D., Anderson, T.:// //Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 231–236 (2002)/), SNDLib (http://sndlib.zib.de), and TopologyZoo(http://www.topology-zoo.org). The found coverages and some details are found in the table below, where /n/ and /m/ denote the number of nodes and the number of links, respectively. The other columns mark the different coverages obrtained by simple LFA and remote LFA, where LP indicates the link-protecting case, while NP notes the case of node protection. Topologies marked with an asterisk(*) did not have inferred real link costs from the datasets, so their costs were initially set to 1 (unit costs). I believe that these results computed on real-world networks could significantly improve the rlfa draft, especially Sec. 9.3., and the advantages of remote LFA over simple LFA would be more emphasized. +==============+====+====+==========+===========+============+============+ | Topology | n | m | LFA_LP | LFA_NP | rLFA_LP | rLFA_NP | +==============+====+====+==========+===========+============+============+ | AS1221 | 7 | 9 | 0.809 | 0.25 | 0.809 | 0.25 | +--------------+----+----+----------+-----------+------------+------------+ | AS1239 | 30 | 69 | 0.8735 | 0.7554 | 1 | 0.9795 | +--------------+----+----+----------+-----------+------------+------------+ | AS1755 | 18 | 33 | 0.8725 | 0.7741 | 0.9967 | 0.9959 | +--------------+----+----+----------+-----------+------------+------------+ | AS3257 | 27 | 64 | 0.923 | 0.7186 | 0.99 | 0.8472 | +--------------+----+----+----------+-----------+------------+------------+ | AS3967 | 21 | 36 | 0.7857 | 0.6460 | 1 | 0.9325 | +--------------+----+----+----------+-----------+------------+------------+ | AS6461 | 17 | 37 | 0.9338 | 0.6933 | 0.9963 | 0.7075 | +--------------+----+----+----------+-----------+------------+------------+ | Abilene* | 12 | 15 | 0.5606 | 0.6078 | 0.9090 | 0.8725 | +--------------+----+----+----------+-----------+------------+------------+ | Arnes* | 41 | 57 | 0.6225 | 0.3518 | 0.7487 | 0.4562 | +--------------+----+----+----------+-----------+------------+------------+ | AT&T | 22 | 38 | 0.8225 | 0.5647 | 1 | 0.8497 | +--------------+----+----+----------+-----------+------------+------------+ | Deltacom | 113| 161| 0.5771 | 0.4910 | 0.8539 | 0.8148 | +--------------+----+----+----------+-----------+------------+------------+ | Gambia | 28 | 28 | 0.037 | 0.04 | 0.1851 | 0.12 | +--------------+----+----+----------+-----------+------------+------------+ | Geant | 37 | 55 | 0.6906 | 0.3977 | 0.8303 | 0.6582 | +--------------+----+----+----------+-----------+------------+------------+ | Germ_50 | 50 | 88 | 0.9004 | 0.8381 | 1 | 0.9995 | +--------------+----+----+----------+-----------+------------+------------+ | Germany* | 27 | 32 | 0.6948 | 0.599 | 1 | 0.9549 | +--------------+----+----+----------+-----------+------------+------------+ | InternetMCI | 19 | 33 | 0.9035 | 0.6798 | 0.9415 | 0.9136 | +--------------+----+----+----------+-----------+------------+------------+ | Italy* | 33 | 56 | 0.784 | 0.5741 | 1 | 0.9269 | +--------------+----+----+----------+-----------+------------+------------+ | NSF* | 26 | 43 | 0.86 | 0.6347 | 1 | 1 | +--------------+----+----+----------+-----------+------------+------------+ Furthermore, after reading the draft again-and-again, I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found. This is important, since normally people obviously think and observe that the failure coverage of remote LFA should be greater than or equal to the coverage obtained by simple LFA. Moreover, people also think that LFAs produce a subset of remote LFAs. However, if after a failure only P-spaces and Q-spaces are taken into account in order to seek a (remote) loop-free alternate, then it is possible that a simple LFA would not be found resulting unprotected node-pairs. But, this case could only happen when link costs are not unit costs. For an easier understanding, consider the network depicted below: 1 1 F--------S-----------X--------E \ / \ 10 \ / 4 \ 1 \ / 1 \ N ---------------------------C | | 1 | | 1 | | | 1 1 | A--------------B-------------D Assume that S wishes to send a packet to D, and the shortest path goes through E, therefore it is S-E-C-D. Suppose that the link (s,e) fails, or even the node e itself fails. In this case, since LFA (and its calculation) only consider all other neighbors of s, then node N would be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D). However, if we only seek possible remote LFAs, than according to the (r)SPF calculations, or taking into account our distance-function conditions will result that D's Q-space will contain node N (besides some other nodes), but S's P-space won't (it will only contain node F and what is more, if node F does not exist, then S's P-space would be empty), therefore no intersection of the two spaces will exist, leaving this network vulnerable to the failure of link (s,e). This results that a neighbor should be always reached by the neighboring link, even if there exists a shorter, but definitely bigger in hop-count path to it. According to this case (when seeking simple LFA is missed), the condition of extended P-space described by our distance functions, should be modified a bit: For source /s/, destination /d/, and next-hop /e/, some node /n != s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if and only if /∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)//*&& dist(s,v) < dist(s,e) + dist(e**,v)*/** /dist(n, d) < dist(n, s) + dist(s, d) . / One can easily observe that emphasizing more that remote LFA seeking process is only "executed" after no simple LFA is found could much more ease the understanding and won't result a headache to the reader who accidentally wants to calculate rLFA coverage in such network. Please let me know, if my interpretation is not correct. Thanks. Best, Levente On 07/02/2013 07:07 PM, Stewart Bryant wrote: > On 26/06/2013 14:13, Levente Csikor wrote: > > Levente > > In each case below the conditions are surely fulfilled if n=e > thus I think that in each case the condition needs to be > changed to : > > some node n!={s or e} >> In order to not to read our full papers and searching the answers, I >> copied here the relevant parts: >> *Link-protecting rLFA condition:* >> For source /s/, destination /d/, and next-hop /e/, some node /n/ /!= >> s,d/ is a link-protecting remote LFA for the /s-d/ pair if and only if >> /dist(s, n) < dist(s, e) + dist(e, n)/ (1) >> /dist(n, d) < dist(n, s) + dist(s, d)/ (2) >> In these equations, one can easily see, that (1) defines the P-space, >> while (2) is the condition of Q-space. Furthermore, with these >> formalized conditions, one can easily observe, that (2) is actually >> the basic loop-free criterion of pure LFA. >> >> *Link-protecting rLFA condition with extended P-space:* >> For source /s/, destination /d/, and next-hop /e/, some node /n != >> s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if >> and only if >> /∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)/// >> /dist(n, d) < dist(n, s) + dist(s, d) . / >> >> *Node-protecting rLFA condition:* >> For source /s/, destination /d/, and next-hop /e/, some /n != s,d/ is >> a node-protecting remote LFA for the /s-d/ pair if and only if >> /dist(s,n) < dist(s,e) + dist(e,n)/// (3) >> /dist(n,d) < dist(n,e) + dist(e,d) / (4) >> As it was in the case of link protection, here, (3) defines the >> P-space, while (4) characterize the Q-space. >> Here, two important observations can be made, which are the followings: >> - P-space does not depend on the protection scheme (i.e., link or >> node protection) > SB> That falls directly out of the definition of P-space > SB> since in link you cannot traverse the link to e and in > SB> node only get to e if you traverse the link to e > SB> thus the exclusion of the link to e applies in both cases >> - (4) again is the basic node-protecting loop-free criterion of pure >> LFA. >> >> *Node-protecting rLFA condition with extended P-space:* >> For source /s/, destination /d/, and next-hop /e/, some node /n != >> s,d/ is an extended node-protecting remote LFA for the /s-d/ pair if >> and only if >> /∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)/ >> /dist(n, d) < dist(n, e) + dist(e, d) ./ >> >> Despite the fact that we only considered unit cost networks, the >> formal definitions above are *true for any arbitrary weighted network.* > SB> I do not see where the unit costs come into the text above. It looks > SB> like it is already expressed in terms of arbitrary cost. > > SB> Additionally in order to limit the number of SPFs to a practical > SB> level, we normally suggest that the repair target in not d, but > SB> instead is e (in the link case) or next hop of e (node case). > > SB> Anyway I will work on some text. > > - Stewart --------------010003000902060000060800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear All,
since our previous works in remote LFA analysis (papers already sent to these mailing lists) assumed unit cost networks, therefore as I promised, I calculated the corresponding LFA and rLFA coverages in those networks with their original link costs.
These networks were inferred from Rocketfuel dataset (Mahajan, R., Spring, N., Wetherall, D., Anderson, T.:
Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 231–236 (2002)), SNDLib (http://sndlib.zib.de), and TopologyZoo(http://www.topology-zoo.org). The found coverages and some details are found in the table below, where n and m denote the number of nodes and the number of links, respectively. The other columns mark the different coverages obrtained by simple LFA and remote LFA, where LP indicates the link-protecting case, while NP notes the case of node protection.
Topologies marked with an asterisk(*) did not have inferred real link costs from the datasets, so their costs were initially set to 1 (unit costs).

I believe that these results computed on real-world networks could significantly improve the rlfa draft, especially Sec. 9.3., and the advantages of remote LFA over simple LFA would be more emphasized.


+==============+====+====+==========+===========+============+============+
| Topology     | n  | m  | LFA_LP   | LFA_NP    |  rLFA_LP   |  rLFA_NP   |
+==============+====+====+==========+===========+============+============+
| AS1221       | 7  | 9  | 0.809    |   0.25    |   0.809    |    0.25    |
+--------------+----+----+----------+-----------+------------+------------+
| AS1239       | 30 | 69 | 0.8735   |  0.7554   |     1      |   0.9795   |
+--------------+----+----+----------+-----------+------------+------------+
| AS1755       | 18 | 33 | 0.8725   |  0.7741   |   0.9967   |   0.9959   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3257       | 27 | 64 | 0.923    |  0.7186   |   0.99     |   0.8472   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3967       | 21 | 36 | 0.7857   |  0.6460   |     1      |   0.9325   |
+--------------+----+----+----------+-----------+------------+------------+
| AS6461       | 17 | 37 | 0.9338   |  0.6933   |   0.9963   |   0.7075   |
+--------------+----+----+----------+-----------+------------+------------+
| Abilene*     | 12 | 15 | 0.5606   |  0.6078   |   0.9090   |   0.8725   |
+--------------+----+----+----------+-----------+------------+------------+
| Arnes*       | 41 | 57 | 0.6225   |  0.3518   |   0.7487   |   0.4562   |
+--------------+----+----+----------+-----------+------------+------------+
| AT&T         | 22 | 38 | 0.8225   |  0.5647   |     1      |   0.8497   |
+--------------+----+----+----------+-----------+------------+------------+
| Deltacom     | 113| 161| 0.5771   |  0.4910   |   0.8539   |   0.8148   |
+--------------+----+----+----------+-----------+------------+------------+
| Gambia       | 28 | 28 | 0.037    |   0.04    |   0.1851   |     0.12   |
+--------------+----+----+----------+-----------+------------+------------+
| Geant        | 37 | 55 | 0.6906   |  0.3977   |   0.8303   |   0.6582   |
+--------------+----+----+----------+-----------+------------+------------+
| Germ_50      | 50 | 88 | 0.9004   |  0.8381   |     1      |   0.9995   |
+--------------+----+----+----------+-----------+------------+------------+
| Germany*     | 27 | 32 | 0.6948   |  0.599    |     1      |   0.9549   |
+--------------+----+----+----------+-----------+------------+------------+
| InternetMCI  | 19 | 33 | 0.9035   |  0.6798   |   0.9415   |   0.9136   |
+--------------+----+----+----------+-----------+------------+------------+
| Italy*       | 33 | 56 | 0.784    |  0.5741   |     1      |   0.9269   |
+--------------+----+----+----------+-----------+------------+------------+
| NSF*         | 26 | 43 | 0.86     |  0.6347   |     1      |     1      |
+--------------+----+----+----------+-----------+------------+------------+


Furthermore, after reading the draft again-and-again, I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found. This is important, since normally people obviously think and observe that the failure coverage of remote LFA should be greater than or equal to the coverage obtained by simple LFA. Moreover, people also think that LFAs produce a subset of remote LFAs. However, if after a failure only P-spaces and Q-spaces are taken into account in order to seek a (remote) loop-free alternate, then it is possible that a simple LFA would not be found resulting unprotected node-pairs. But, this case could only happen when link costs are not unit costs. For an easier understanding, consider the network depicted below:
            1              1
          F--------S-----------X--------E
           \      /                      \
         10 \    / 4                      \  1
             \  /        1                 \
              N ---------------------------C
              |                            |
           1  |                            |  1
              |                            |
              |      1             1       |
              A--------------B-------------D

Assume that S wishes to send a packet to D, and the shortest path goes through E, therefore it is S-E-C-D. Suppose that the link (s,e)
fails, or even the node e itself fails. In this case, since LFA (and its calculation) only consider all other neighbors of s, then node N would be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D).
However, if we only seek possible remote LFAs, than according to the (r)SPF calculations, or taking into account our distance-function conditions will result that D's Q-space will contain node N (besides some other nodes), but S's P-space won't (it will only contain node F and what is more, if node F does not exist, then S's P-space would be empty), therefore no intersection of the two spaces will exist, leaving this network vulnerable to the failure of link (s,e).

This results that a neighbor should be always reached by the neighboring link, even if there exists a shorter, but definitely bigger in hop-count path to it.
According to this case (when seeking simple LFA is missed), the condition of extended P-space described by our distance functions, should be modified a bit:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)  && dist(s,v) < dist(s,e) + dist(e,v)
dist(n, d) < dist(n, s) + dist(s, d) .

One can easily observe that emphasizing more that remote LFA seeking process is only "executed" after no simple LFA is found could much more ease the understanding and won't result a headache to the reader who accidentally wants to calculate rLFA coverage in such network.

Please let me know, if my interpretation is not correct.
Thanks.

Best,
Levente

On 07/02/2013 07:07 PM, Stewart Bryant wrote:
On 26/06/2013 14:13, Levente Csikor wrote:

Levente

In each case below the conditions are surely fulfilled if n=e
thus I think that in each case the condition needs to be
changed to :

some node n!={s or e}
In order to not to read our full papers and searching the answers, I copied here the relevant parts:
Link-protecting rLFA condition:
For source s, destination d, and next-hop e, some node n != s,d is a link-protecting remote LFA for the s-d pair  if and only if
  dist(s, n) < dist(s, e) + dist(e, n)  (1)
  dist(n, d) < dist(n, s) + dist(s, d)  (2)
In these equations, one can easily see, that (1) defines the P-space, while (2) is the condition of Q-space. Furthermore, with these formalized conditions, one can easily observe, that (2) is actually the basic loop-free criterion of pure LFA.

Link-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)    
dist(n, d) < dist(n, s) + dist(s, d) .                                             

Node-protecting rLFA condition:
For source s, destination d, and next-hop e, some n != s,d is a node-protecting remote LFA for the s-d pair if and only if
dist(s,n) < dist(s,e) + dist(e,n)      (3)
dist(n,d) < dist(n,e) + dist(e,d)     (4)
As it was in the case of link protection, here, (3) defines the P-space, while (4) characterize the Q-space.
Here, two important observations can be made, which are the followings:
 - P-space does not depend on the protection scheme (i.e., link or node protection)
SB> That falls directly out of the definition of P-space
SB> since in link you cannot traverse the link to e and in
SB> node only get to e if you traverse the link to e
SB> thus the exclusion of the link to e applies in both cases
 - (4) again is the basic node-protecting loop-free criterion of pure LFA.

Node-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended node-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)
dist(n, d) < dist(n, e) + dist(e, d) .

Despite the fact that we only considered unit cost networks, the formal definitions above are true for any arbitrary weighted network.
SB> I do not see where the unit costs come into the text above. It looks
SB> like it is already expressed in terms of arbitrary cost.

SB> Additionally in order to limit the number of SPFs to a practical
SB> level, we normally suggest that the repair target in not d, but
SB> instead is e (in the link case) or next hop of e (node case).

SB> Anyway I will work on some text.

- Stewart

--------------010003000902060000060800-- From aretana@cisco.com Thu Aug 1 09:24:57 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1221F9DBB for ; Thu, 1 Aug 2013 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqo17q9BQNnm for ; Thu, 1 Aug 2013 09:24:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 15CF421F9D04 for ; Thu, 1 Aug 2013 09:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2962; q=dns/txt; s=iport; t=1375374289; x=1376583889; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=f+UsIB4B5Cg+Q0wQtSAjCC7AW7Zp5R9j8aTBHU9tgTU=; b=m/B0acQzsCNgfBLtX/WbhkusMfAp96LsucPADkorargdBCgRR16pYHfk nVoi2jIpmLnDKPpa9jBxnrnYcT89pzMCODMg2iRMiwTWj/1+Yc7vR1J40 MP4wmo87YLNbybsWaI1y5HJs8VxyvvgI8U+gS8X40WVqzxtLv9er2V1hr Q=; X-Files: ATT00002.txt : 130 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FADGL+lGtJV2Z/2dsb2JhbABbgkJENVCCSbt+gR0WdIIkAQEBBAEBAWsdAQgEAR0dCR8GCxQHAQYDAgQTCAaHcAMPDJlDl1MNiFoEjRaCQDiDGXMDkBKBLYQ3jhCFJ4MUgio X-IronPort-AV: E=Sophos;i="4.89,795,1367971200"; d="txt'?scan'208,217";a="239341604" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2013 16:24:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r71GOlWI009827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 16:24:47 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.218]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 11:24:47 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: FW: scribe and jabber scribe needed Thread-Topic: scribe and jabber scribe needed Thread-Index: AQHOi5Kt7r1wnzzhlE20oYv1Yc0ib5mBBXYA Date: Thu, 1 Aug 2013 16:24:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.149] Content-Type: multipart/mixed; boundary="_004_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:24:58 -0000 --_004_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_ Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_" --_000_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We still need someone to take notes and to be the Jabber scribe for our mee= ting tomorrow. Thanks! Alvaro. On 7/28/13 3:01 PM, "Alia Atlas" > wrote: It's not too soon to volunteer to be a scribe or jabber scribe for RTGWG... We could really use volunteers, particularly, for scribe. I'd rather have = this dealt with before Friday. Thanks, Alia --_000_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <6AC64DC62DD419459254E06918747CEC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

We still need someone to take notes and to be the Jabber scribe for ou= r meeting tomorrow.

Thanks!

Alvaro.

On 7/28/13 3:01 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

It's not too soon to volunteer to be a scribe or jabber sc= ribe for RTGWG...

We could really use volunteers, particularly, for scribe.  I'd ra= ther have this dealt with before Friday.

Thanks,
Alia
 --_000_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_-- --_004_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_ Content-Type: text/plain; name="ATT00002.txt" Content-Description: ATT00002.txt Content-Disposition: attachment; filename="ATT00002.txt"; size=130; creation-date="Thu, 01 Aug 2013 16:24:46 GMT"; modification-date="Thu, 01 Aug 2013 16:24:46 GMT" Content-ID: <2CC8E7D092804F49B7C11CD1C6189B8D@emea.cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Z3dnIG1h aWxpbmcgbGlzdA0KcnRnd2dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRnd2cNCg== --_004_BBD66FD99311804F80324E8139B3C94E27CE7A68xmbalnx15ciscoc_-- From csikor@tmit.bme.hu Thu Aug 1 23:25:39 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB011E8248 for ; Thu, 1 Aug 2013 23:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3F8s0C9+fKO for ; Thu, 1 Aug 2013 23:25:34 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9645711E8191 for ; Thu, 1 Aug 2013 23:25:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id BC83F87350; Fri, 2 Aug 2013 08:25:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5irJvfIe0nd8; Fri, 2 Aug 2013 08:25:02 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id D1E3D87346; Fri, 2 Aug 2013 08:25:01 +0200 (CEST) Received: from [192.168.89.148] (catv-178-48-68-91.catv.broadband.hu [178.48.68.91]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r726P6rl006967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 08:25:06 +0200 Message-ID: <51FB50BB.90303@tmit.bme.hu> Date: Fri, 02 Aug 2013 08:24:59 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> In-Reply-To: <51FA6C6A.4090200@tmit.bme.hu> Content-Type: multipart/alternative; boundary="------------040507000700030903070804" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:25:39 -0000 This is a multi-part message in MIME format. --------------040507000700030903070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear All, I'm sending my previous mail again since the font for the ASCII art network was not fixed and may not appear in a right format at everyone. If it still messy, let me know. Sorry, Levente Dear All, since our previous works in remote LFA analysis (papers already sent to these mailing lists) assumed unit cost networks, therefore as I promised, I calculated the corresponding LFA and rLFA coverages in those networks with their original link costs. These networks were inferred from Rocketfuel dataset (/Mahajan, R., Spring, N., Wetherall, D., Anderson, T.:// //Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 231--236 (2002)/), SNDLib (http://sndlib.zib.de), and TopologyZoo(http://www.topology-zoo.org). The found coverages and some details are found in the table below, where /n/ and /m/ denote the number of nodes and the number of links, respectively. The other columns mark the different coverages obrtained by simple LFA and remote LFA, where LP indicates the link-protecting case, while NP notes the case of node protection. Topologies marked with an asterisk(*) did not have inferred real link costs from the datasets, so their costs were initially set to 1 (unit costs). I believe that these results computed on real-world networks could significantly improve the rlfa draft, especially Sec. 9.3., and the advantages of remote LFA over simple LFA would be more emphasized. +==============+====+====+==========+===========+============+============+ | Topology | n | m | LFA_LP | LFA_NP | rLFA_LP | rLFA_NP | +==============+====+====+==========+===========+============+============+ | AS1221 | 7 | 9 | 0.809 | 0.25 | 0.809 | 0.25 | +--------------+----+----+----------+-----------+------------+------------+ | AS1239 | 30 | 69 | 0.8735 | 0.7554 | 1 | 0.9795 | +--------------+----+----+----------+-----------+------------+------------+ | AS1755 | 18 | 33 | 0.8725 | 0.7741 | 0.9967 | 0.9959 | +--------------+----+----+----------+-----------+------------+------------+ | AS3257 | 27 | 64 | 0.923 | 0.7186 | 0.99 | 0.8472 | +--------------+----+----+----------+-----------+------------+------------+ | AS3967 | 21 | 36 | 0.7857 | 0.6460 | 1 | 0.9325 | +--------------+----+----+----------+-----------+------------+------------+ | AS6461 | 17 | 37 | 0.9338 | 0.6933 | 0.9963 | 0.7075 | +--------------+----+----+----------+-----------+------------+------------+ | Abilene* | 12 | 15 | 0.5606 | 0.6078 | 0.9090 | 0.8725 | +--------------+----+----+----------+-----------+------------+------------+ | Arnes* | 41 | 57 | 0.6225 | 0.3518 | 0.7487 | 0.4562 | +--------------+----+----+----------+-----------+------------+------------+ | AT&T | 22 | 38 | 0.8225 | 0.5647 | 1 | 0.8497 | +--------------+----+----+----------+-----------+------------+------------+ | Deltacom | 113| 161| 0.5771 | 0.4910 | 0.8539 | 0.8148 | +--------------+----+----+----------+-----------+------------+------------+ | Gambia | 28 | 28 | 0.037 | 0.04 | 0.1851 | 0.12 | +--------------+----+----+----------+-----------+------------+------------+ | Geant | 37 | 55 | 0.6906 | 0.3977 | 0.8303 | 0.6582 | +--------------+----+----+----------+-----------+------------+------------+ | Germ_50 | 50 | 88 | 0.9004 | 0.8381 | 1 | 0.9995 | +--------------+----+----+----------+-----------+------------+------------+ | Germany* | 27 | 32 | 0.6948 | 0.599 | 1 | 0.9549 | +--------------+----+----+----------+-----------+------------+------------+ | InternetMCI | 19 | 33 | 0.9035 | 0.6798 | 0.9415 | 0.9136 | +--------------+----+----+----------+-----------+------------+------------+ | Italy* | 33 | 56 | 0.784 | 0.5741 | 1 | 0.9269 | +--------------+----+----+----------+-----------+------------+------------+ | NSF* | 26 | 43 | 0.86 | 0.6347 | 1 | 1 | +--------------+----+----+----------+-----------+------------+------------+ Furthermore, after reading the draft again-and-again, I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found. This is important, since normally people obviously think and observe that the failure coverage of remote LFA should be greater than or equal to the coverage obtained by simple LFA. Moreover, people also think that LFAs produce a subset of remote LFAs. However, if after a failure only P-spaces and Q-spaces are taken into account in order to seek a (remote) loop-free alternate, then it is possible that a simple LFA would not be found resulting unprotected node-pairs. But, this case could only happen when link costs are not unit costs. For an easier understanding, consider the network depicted below: 1 1 F--------S-----------X--------E \ / \ 10 \ / 4 \ 1 \ / 1 \ N ---------------------------C | | 1 | | 1 | | | 1 1 | A--------------B-------------D Assume that S wishes to send a packet to D, and the shortest path goes through E, therefore it is S-E-C-D. Suppose that the link (s,e) fails, or even the node e itself fails. In this case, since LFA (and its calculation) only consider all other neighbors of s, then node N would be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D). However, if we only seek possible remote LFAs, than according to the (r)SPF calculations, or taking into account our distance-function conditions will result that D's Q-space will contain node N (besides some other nodes), but S's P-space won't (it will only contain node F and what is more, if node F does not exist, then S's P-space would be empty), therefore no intersection of the two spaces will exist, leaving this network vulnerable to the failure of link (s,e). This results that a neighbor should be always reached by the neighboring link, even if there exists a shorter, but definitely bigger in hop-count path to it. According to this case (when seeking simple LFA is missed), the condition of extended P-space described by our distance functions, should be modified a bit: For source /s/, destination /d/, and next-hop /e/, some node /n != s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if and only if /?v ? neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)//*&& dist(s,v) < dist(s,e) + dist(e**,v)*/ /dist(n, d) < dist(n, s) + dist(s, d) . / One can easily observe that emphasizing more that remote LFA seeking process is only "executed" after no simple LFA is found could much more ease the understanding and won't result a headache to the reader who accidentally wants to calculate rLFA coverage in such network. Please let me know, if my interpretation is not correct. Thanks. Best, Levente --------------040507000700030903070804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear All,
I'm sending my previous mail again since the font for the ASCII art network was not fixed and may not appear in a right format at everyone.

If it still messy, let me know.

Sorry,
Levente


Dear All,
since our previous works in remote LFA analysis (papers already sent to these mailing lists) assumed unit cost networks, therefore as I promised, I calculated the corresponding LFA and rLFA coverages in those networks with their original link costs.
These networks were inferred from Rocketfuel dataset (Mahajan, R., Spring, N., Wetherall, D., Anderson, T.:
Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 231–236 (2002)), SNDLib (http://sndlib.zib.de), and TopologyZoo(http://www.topology-zoo.org). The found coverages and some details are found in the table below, where n and m denote the number of nodes and the number of links, respectively. The other columns mark the different coverages obrtained by simple LFA and remote LFA, where LP indicates the link-protecting case, while NP notes the case of node protection.
Topologies marked with an asterisk(*) did not have inferred real link costs from the datasets, so their costs were initially set to 1 (unit costs).

I believe that these results computed on real-world networks could significantly improve the rlfa draft, especially Sec. 9.3., and the advantages of remote LFA over simple LFA would be more emphasized.
+==============+====+====+==========+===========+============+============+
| Topology     | n  | m  | LFA_LP   | LFA_NP    |  rLFA_LP   |  rLFA_NP   |
+==============+====+====+==========+===========+============+============+
| AS1221       | 7  | 9  | 0.809    |   0.25    |   0.809    |    0.25    |
+--------------+----+----+----------+-----------+------------+------------+
 | AS1239       | 30 | 69 | 0.8735   |  0.7554   |     1      |   0.9795   |
 +--------------+----+----+----------+-----------+------------+------------+
 | AS1755       | 18 | 33 | 0.8725   |  0.7741   |   0.9967   |   0.9959   |
 +--------------+----+----+----------+-----------+------------+------------+
 | AS3257       | 27 | 64 | 0.923    |  0.7186   |   0.99     |   0.8472   |
 +--------------+----+----+----------+-----------+------------+------------+
 | AS3967       | 21 | 36 | 0.7857   |  0.6460   |     1      |   0.9325   |
 +--------------+----+----+----------+-----------+------------+------------+
 | AS6461       | 17 | 37 | 0.9338   |  0.6933   |   0.9963   |   0.7075   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Abilene*     | 12 | 15 | 0.5606   |  0.6078   |   0.9090   |   0.8725   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Arnes*       | 41 | 57 | 0.6225   |  0.3518   |   0.7487   |   0.4562   |
 +--------------+----+----+----------+-----------+------------+------------+
 | AT&T         | 22 | 38 | 0.8225   |  0.5647   |     1      |   0.8497   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Deltacom     | 113| 161| 0.5771   |  0.4910   |   0.8539   |   0.8148   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Gambia       | 28 | 28 | 0.037    |   0.04    |   0.1851   |     0.12   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Geant        | 37 | 55 | 0.6906   |  0.3977   |   0.8303   |   0.6582   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Germ_50      | 50 | 88 | 0.9004   |  0.8381   |     1      |   0.9995   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Germany*     | 27 | 32 | 0.6948   |  0.599    |     1      |   0.9549   |
 +--------------+----+----+----------+-----------+------------+------------+
 | InternetMCI  | 19 | 33 | 0.9035   |  0.6798   |   0.9415   |   0.9136   |
 +--------------+----+----+----------+-----------+------------+------------+
 | Italy*       | 33 | 56 | 0.784    |  0.5741   |     1      |   0.9269   |
 +--------------+----+----+----------+-----------+------------+------------+
 | NSF*         | 26 | 43 | 0.86     |  0.6347   |     1      |     1      |
 +--------------+----+----+----------+-----------+------------+------------+


Furthermore, after reading the draft again-and-again, I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found. This is important, since normally people obviously think and observe that the failure coverage of remote LFA should be greater than or equal to the coverage obtained by simple LFA. Moreover, people also think that LFAs produce a subset of remote LFAs. However, if after a failure only P-spaces and Q-spaces are taken into account in order to seek a (remote) loop-free alternate, then it is possible that a simple LFA would not be found resulting unprotected node-pairs. But, this case could only happen when link costs are not unit costs. For an easier understanding, consider the network depicted below:
            1              1
          F--------S-----------X--------E
           \      /                      \
         10 \    / 4                      \  1
             \  /        1                 \
              N ---------------------------C
              |                            |
           1  |                            |  1
              |                            |
              |      1             1       |
              A--------------B-------------D

Assume that S wishes to send a packet to D, and the shortest path goes through E, therefore it is S-E-C-D. Suppose that the link (s,e)
fails, or even the node e itself fails. In this case, since LFA (and its calculation) only consider all other neighbors of s, then node N would be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D).
However, if we only seek possible remote LFAs, than according to the (r)SPF calculations, or taking into account our distance-function conditions will result that D's Q-space will contain node N (besides some other nodes), but S's P-space won't (it will only contain node F and what is more, if node F does not exist, then S's P-space would be empty), therefore no intersection of the two spaces will exist, leaving this network vulnerable to the failure of link (s,e).

This results that a neighbor should be always reached by the neighboring link, even if there exists a shorter, but definitely bigger in hop-count path to it.
According to this case (when seeking simple LFA is missed), the condition of extended P-space described by our distance functions, should be modified a bit:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)  && dist(s,v) < dist(s,e) + dist(e,v)
dist(n, d) < dist(n, s) + dist(s, d) .

One can easily observe that emphasizing more that remote LFA seeking process is only "executed" after no simple LFA is found could much more ease the understanding and won't result a headache to the reader who accidentally wants to calculate rLFA coverage in such network.

Please let me know, if my interpretation is not correct.
Thanks.

Best,
Levente


--------------040507000700030903070804-- From gabor.sandor.enyedi@ericsson.com Fri Aug 2 00:59:42 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5272011E823B for ; Fri, 2 Aug 2013 00:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb0BmoI-w6pT for ; Fri, 2 Aug 2013 00:59:37 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DD7E311E82A8 for ; Fri, 2 Aug 2013 00:59:05 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-6d-51fb66c8086c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E9.97.11907.8C66BF15; Fri, 2 Aug 2013 09:59:04 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.48]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 09:59:04 +0200 From: =?utf-8?B?R8OhYm9yIFPDoW5kb3IgRW55ZWRp?= To: Levente Csikor , "stbryant@cisco.com" Subject: RE: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Topic: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Index: AQHOcm8kBHtQfVkVUE+P5S2zzPGgu5lRht0AgC70lwCAARAtgIAAOxDg Date: Fri, 2 Aug 2013 07:59:03 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> <51FB50BB.90303@tmit.bme.hu> In-Reply-To: <51FB50BB.90303@tmit.bme.hu> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5A5ESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VvdE2u9Ag7cnDC3+7P7MaLF8wQ1G i5sHZzJZXHjzm9ni3NM5jA6sHlN+b2T1WLLkJ5PHsmfzWD2+XP7MFsASxWWTkpqTWZZapG+X wJWxuPEkY8GP34wVP/feY2lgXPGVsYuRk0NCwERi5snNzBC2mMSFe+vZuhi5OIQEjjJKPL98 khnCWcQo8ePZZiaQKjaBYIn7n26zg9giAiESX/bfYQcpYhY4yCjx9e9TsISwQJTEocUT2SCK oiUa9t1hhbDdJB7+nQw2iEVAReLbtndg9bwCvhKrH/yH2nacUeLpzzVgCU4BTYmjC7uAbA4O RgFZiYdrLUDCzALiEreezGeCOFtAYsme81AviEq8fPyPFcJWkvix4RILRH2+RP+PDhaIXYIS J2c+YZnAKDoLyahZSMpmISmbBbSZGeiK9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvoqRozi1 OCk33chgEyMwGg9u+W2xg/HyX5tDjNIcLErivFv0zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYKy51FYdKrjMUHbeupcsrUdm3jVq6Lao7DSXuq4/yTirgDtg7rmE77+MjypL2fy+tebo DZOufUb5EWcDWh4eVdAziI3eftwiOjj518rasuOrSv7PUGISOV525iHztWpNVr8+/rPMIQpt zuunndVdZ9V8Meb3VAuZ69mH+blZAy7dffj1Ze91QyWW4oxEQy3mouJEAO1qxiGUAgAA Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:59:42 -0000 --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5A5ESESSMB307erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJlIHRoZXNlIHRoZSBzaW5nbGUgb3IgdGhlIGJpZGlyZWN0aW9uYWwgY292ZXJhZ2UgcmVzdWx0 cz8NCg0KR2Fib3INCg0KRnJvbTogcnRnd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZXZlbnRlIENzaWtvcg0KU2VudDogRnJp ZGF5LCBBdWd1c3QgMDIsIDIwMTMgODoyNSBBTQ0KVG86IHN0YnJ5YW50QGNpc2NvLmNvbQ0KQ2M6 IGRyYWZ0LWlldGYtcnRnd2ctcmVtb3RlLWxmYUB0b29scy5pZXRmLm9yZzsgcnRnd2ctY2hhaXJz QHRvb2xzLmlldGYub3JnOyBydGd3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IGRyYWZ0LWlldGYt cnRnd2ctcmVtb3RlLWxmYSAtIHJlYWR5IGZvciBXR0xDPyAtIHNvbWUgY29tbWVudHMgYW5kIHF1 ZXN0aW9ucw0KDQpEZWFyIEFsbCwNCkknbSBzZW5kaW5nIG15IHByZXZpb3VzIG1haWwgYWdhaW4g c2luY2UgdGhlIGZvbnQgZm9yIHRoZSBBU0NJSSBhcnQgbmV0d29yayB3YXMgbm90IGZpeGVkIGFu ZCBtYXkgbm90IGFwcGVhciBpbiBhIHJpZ2h0IGZvcm1hdCBhdCBldmVyeW9uZS4NCg0KSWYgaXQg c3RpbGwgbWVzc3ksIGxldCBtZSBrbm93Lg0KDQpTb3JyeSwNCkxldmVudGUNCg0KDQpEZWFyIEFs bCwNCnNpbmNlIG91ciBwcmV2aW91cyB3b3JrcyBpbiByZW1vdGUgTEZBIGFuYWx5c2lzIChwYXBl cnMgYWxyZWFkeSBzZW50IHRvIHRoZXNlIG1haWxpbmcgbGlzdHMpIGFzc3VtZWQgdW5pdCBjb3N0 IG5ldHdvcmtzLCB0aGVyZWZvcmUgYXMgSSBwcm9taXNlZCwgSSBjYWxjdWxhdGVkIHRoZSBjb3Jy ZXNwb25kaW5nIExGQSBhbmQgckxGQSBjb3ZlcmFnZXMgaW4gdGhvc2UgbmV0d29ya3Mgd2l0aCB0 aGVpciBvcmlnaW5hbCBsaW5rIGNvc3RzLg0KVGhlc2UgbmV0d29ya3Mgd2VyZSBpbmZlcnJlZCBm cm9tIFJvY2tldGZ1ZWwgZGF0YXNldCAoTWFoYWphbiwgUi4sIFNwcmluZywgTi4sIFdldGhlcmFs bCwgRC4sIEFuZGVyc29uLCBULjoNCkluZmVycmluZyBsaW5rIHdlaWdodHMgdXNpbmcgZW5kLXRv LWVuZCBtZWFzdXJlbWVudHMuIEluOiBBQ00gSU1DLCBwcC4gMjMx4oCTMjM2ICgyMDAyKSksIFNO RExpYiAoaHR0cDovL3NuZGxpYi56aWIuZGUpLCBhbmQgVG9wb2xvZ3lab28oaHR0cDovL3d3dy50 b3BvbG9neS16b28ub3JnKS4gVGhlIGZvdW5kIGNvdmVyYWdlcyBhbmQgc29tZSBkZXRhaWxzIGFy ZSBmb3VuZCBpbiB0aGUgdGFibGUgYmVsb3csIHdoZXJlIG4gYW5kIG0gZGVub3RlIHRoZSBudW1i ZXIgb2Ygbm9kZXMgYW5kIHRoZSBudW1iZXIgb2YgbGlua3MsIHJlc3BlY3RpdmVseS4gVGhlIG90 aGVyIGNvbHVtbnMgbWFyayB0aGUgZGlmZmVyZW50IGNvdmVyYWdlcyBvYnJ0YWluZWQgYnkgc2lt cGxlIExGQSBhbmQgcmVtb3RlIExGQSwgd2hlcmUgTFAgaW5kaWNhdGVzIHRoZSBsaW5rLXByb3Rl Y3RpbmcgY2FzZSwgd2hpbGUgTlAgbm90ZXMgdGhlIGNhc2Ugb2Ygbm9kZSBwcm90ZWN0aW9uLg0K VG9wb2xvZ2llcyBtYXJrZWQgd2l0aCBhbiBhc3RlcmlzaygqKSBkaWQgbm90IGhhdmUgaW5mZXJy ZWQgcmVhbCBsaW5rIGNvc3RzIGZyb20gdGhlIGRhdGFzZXRzLCBzbyB0aGVpciBjb3N0cyB3ZXJl IGluaXRpYWxseSBzZXQgdG8gMSAodW5pdCBjb3N0cykuDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZXNl IHJlc3VsdHMgY29tcHV0ZWQgb24gcmVhbC13b3JsZCBuZXR3b3JrcyBjb3VsZCBzaWduaWZpY2Fu dGx5IGltcHJvdmUgdGhlIHJsZmEgZHJhZnQsIGVzcGVjaWFsbHkgU2VjLiA5LjMuLCBhbmQgdGhl IGFkdmFudGFnZXMgb2YgcmVtb3RlIExGQSBvdmVyIHNpbXBsZSBMRkEgd291bGQgYmUgbW9yZSBl bXBoYXNpemVkLg0KDQoNCis9PT09PT09PT09PT09PSs9PT09Kz09PT0rPT09PT09PT09PSs9PT09 PT09PT09PSs9PT09PT09PT09PT0rPT09PT09PT09PT09Kw0KfCBUb3BvbG9neSAgICAgfCBuICB8 IG0gIHwgTEZBX0xQICAgfCBMRkFfTlAgICAgfCAgckxGQV9MUCAgIHwgIHJMRkFfTlAgICB8DQor PT09PT09PT09PT09PT0rPT09PSs9PT09Kz09PT09PT09PT0rPT09PT09PT09PT0rPT09PT09PT09 PT09Kz09PT09PT09PT09PSsNCnwgQVMxMjIxICAgICAgIHwgNyAgfCA5ICB8IDAuODA5ICAgIHwg ICAwLjI1ICAgIHwgICAwLjgwOSAgICB8ICAgIDAuMjUgICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0t LS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r DQp8IEFTMTIzOSAgICAgICB8IDMwIHwgNjkgfCAwLjg3MzUgICB8ICAwLjc1NTQgICB8ICAgICAx ICAgICAgfCAgIDAuOTc5NSAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0t LSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBBUzE3NTUgICAgICAg fCAxOCB8IDMzIHwgMC44NzI1ICAgfCAgMC43NzQxICAgfCAgIDAuOTk2NyAgIHwgICAwLjk5NTkg ICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgQVMzMjU3ICAgICAgIHwgMjcgfCA2NCB8IDAuOTIz ICAgIHwgIDAuNzE4NiAgIHwgICAwLjk5ICAgICB8ICAgMC44NDcyICAgfA0KKy0tLS0tLS0tLS0t LS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0rDQp8IEFTMzk2NyAgICAgICB8IDIxIHwgMzYgfCAwLjc4NTcgICB8ICAwLjY0NjAgICB8 ICAgICAxICAgICAgfCAgIDAuOTMyNSAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBBUzY0NjEg ICAgICAgfCAxNyB8IDM3IHwgMC45MzM4ICAgfCAgMC42OTMzICAgfCAgIDAuOTk2MyAgIHwgICAw LjcwNzUgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgQWJpbGVuZSogICAgIHwgMTIgfCAxNSB8 IDAuNTYwNiAgIHwgIDAuNjA3OCAgIHwgICAwLjkwOTAgICB8ICAgMC44NzI1ICAgfA0KKy0tLS0t LS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rDQp8IEFybmVzKiAgICAgICB8IDQxIHwgNTcgfCAwLjYyMjUgICB8ICAwLjM1 MTggICB8ICAgMC43NDg3ICAgfCAgIDAuNDU2MiAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0t LS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBB VCZUICAgICAgICAgfCAyMiB8IDM4IHwgMC44MjI1ICAgfCAgMC41NjQ3ICAgfCAgICAgMSAgICAg IHwgICAwLjg0OTcgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgRGVsdGFjb20gICAgIHwgMTEz fCAxNjF8IDAuNTc3MSAgIHwgIDAuNDkxMCAgIHwgICAwLjg1MzkgICB8ICAgMC44MTQ4ICAgfA0K Ky0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0rDQp8IEdhbWJpYSAgICAgICB8IDI4IHwgMjggfCAwLjAzNyAgICB8 ICAgMC4wNCAgICB8ICAgMC4xODUxICAgfCAgICAgMC4xMiAgIHwNCistLS0tLS0tLS0tLS0tLSst LS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t Kw0KfCBHZWFudCAgICAgICAgfCAzNyB8IDU1IHwgMC42OTA2ICAgfCAgMC4zOTc3ICAgfCAgIDAu ODMwMyAgIHwgICAwLjY1ODIgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0t LS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgR2VybV81MCAgICAg IHwgNTAgfCA4OCB8IDAuOTAwNCAgIHwgIDAuODM4MSAgIHwgICAgIDEgICAgICB8ICAgMC45OTk1 ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IEdlcm1hbnkqICAgICB8IDI3IHwgMzIgfCAwLjY5 NDggICB8ICAwLjU5OSAgICB8ICAgICAxICAgICAgfCAgIDAuOTU0OSAgIHwNCistLS0tLS0tLS0t LS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tKw0KfCBJbnRlcm5ldE1DSSAgfCAxOSB8IDMzIHwgMC45MDM1ICAgfCAgMC42Nzk4ICAg fCAgIDAuOTQxNSAgIHwgICAwLjkxMzYgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgSXRhbHkq ICAgICAgIHwgMzMgfCA1NiB8IDAuNzg0ICAgIHwgIDAuNTc0MSAgIHwgICAgIDEgICAgICB8ICAg MC45MjY5ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IE5TRiogICAgICAgICB8IDI2IHwgNDMg fCAwLjg2ICAgICB8ICAwLjYzNDcgICB8ICAgICAxICAgICAgfCAgICAgMSAgICAgIHwNCistLS0t LS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tKw0KDQoNCkZ1cnRoZXJtb3JlLCBhZnRlciByZWFkaW5nIHRoZSBkcmFmdCBh Z2Fpbi1hbmQtYWdhaW4sIEkgaGF2ZSBmb3VuZCB0aGF0IGl0IHNob3VsZCBiZSBtb3JlIGVtcGhh c2l6ZWQgaW4gdGhlIGRyYWZ0IHRoYXQgY2FsY3VsYXRpbmcgb3Igc2Vla2luZyBmb3IgYSByZW1v dGUgTEZBIHN0YWdpbmcgcG9pbnQgc2hvdWxkIGJlIGRvbmUgSUYgQU5EIE9OTFkgSUYgbm8gc2lt cGxlIExGQSB3ZXJlIGZvdW5kLiBUaGlzIGlzIGltcG9ydGFudCwgc2luY2Ugbm9ybWFsbHkgcGVv cGxlIG9idmlvdXNseSB0aGluayBhbmQgb2JzZXJ2ZSB0aGF0IHRoZSBmYWlsdXJlIGNvdmVyYWdl IG9mIHJlbW90ZSBMRkEgc2hvdWxkIGJlIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byB0aGUgY292 ZXJhZ2Ugb2J0YWluZWQgYnkgc2ltcGxlIExGQS4gTW9yZW92ZXIsIHBlb3BsZSBhbHNvIHRoaW5r IHRoYXQgTEZBcyBwcm9kdWNlIGEgc3Vic2V0IG9mIHJlbW90ZSBMRkFzLiBIb3dldmVyLCBpZiBh ZnRlciBhIGZhaWx1cmUgb25seSBQLXNwYWNlcyBhbmQgUS1zcGFjZXMgYXJlIHRha2VuIGludG8g YWNjb3VudCBpbiBvcmRlciB0byBzZWVrIGEgKHJlbW90ZSkgbG9vcC1mcmVlIGFsdGVybmF0ZSwg dGhlbiBpdCBpcyBwb3NzaWJsZSB0aGF0IGEgc2ltcGxlIExGQSB3b3VsZCBub3QgYmUgZm91bmQg cmVzdWx0aW5nIHVucHJvdGVjdGVkIG5vZGUtcGFpcnMuIEJ1dCwgdGhpcyBjYXNlIGNvdWxkIG9u bHkgaGFwcGVuIHdoZW4gbGluayBjb3N0cyBhcmUgbm90IHVuaXQgY29zdHMuIEZvciBhbiBlYXNp ZXIgdW5kZXJzdGFuZGluZywgY29uc2lkZXIgdGhlIG5ldHdvcmsgZGVwaWN0ZWQgYmVsb3c6DQog ICAgICAgICAgICAxICAgICAgICAgICAgICAxDQogICAgICAgICAgRi0tLS0tLS0tUy0tLS0tLS0t LS0tWC0tLS0tLS0tRQ0KICAgICAgICAgICBcICAgICAgLyAgICAgICAgICAgICAgICAgICAgICBc DQogICAgICAgICAxMCBcICAgIC8gNCAgICAgICAgICAgICAgICAgICAgICBcICAxDQogICAgICAg ICAgICAgXCAgLyAgICAgICAgMSAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICBOIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUMNCiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgICAgIDEgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgMQ0KICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgfCAgICAgIDEgICAgICAgICAgICAgMSAgICAgICB8DQogICAgICAgICAgICAg IEEtLS0tLS0tLS0tLS0tLUItLS0tLS0tLS0tLS0tRA0KDQpBc3N1bWUgdGhhdCBTIHdpc2hlcyB0 byBzZW5kIGEgcGFja2V0IHRvIEQsIGFuZCB0aGUgc2hvcnRlc3QgcGF0aCBnb2VzIHRocm91Z2gg RSwgdGhlcmVmb3JlIGl0IGlzIFMtRS1DLUQuIFN1cHBvc2UgdGhhdCB0aGUgbGluayAocyxlKQ0K ZmFpbHMsIG9yIGV2ZW4gdGhlIG5vZGUgZSBpdHNlbGYgZmFpbHMuIEluIHRoaXMgY2FzZSwgc2lu Y2UgTEZBIChhbmQgaXRzIGNhbGN1bGF0aW9uKSBvbmx5IGNvbnNpZGVyIGFsbCBvdGhlciBuZWln aGJvcnMgb2YgcywgdGhlbiBub2RlIE4gd291bGQgYmUgYW4gZWFzeSBMRkEgZm9yIHRoaXMgZmFp bHVyZSwgc2luY2UgZGlzdChOLEQpIDwgZGlzdChOLFMpK2Rpc3QoUyxEKS4NCkhvd2V2ZXIsIGlm IHdlIG9ubHkgc2VlayBwb3NzaWJsZSByZW1vdGUgTEZBcywgdGhhbiBhY2NvcmRpbmcgdG8gdGhl IChyKVNQRiBjYWxjdWxhdGlvbnMsIG9yIHRha2luZyBpbnRvIGFjY291bnQgb3VyIGRpc3RhbmNl LWZ1bmN0aW9uIGNvbmRpdGlvbnMgd2lsbCByZXN1bHQgdGhhdCBEJ3MgUS1zcGFjZSB3aWxsIGNv bnRhaW4gbm9kZSBOIChiZXNpZGVzIHNvbWUgb3RoZXIgbm9kZXMpLCBidXQgUydzIFAtc3BhY2Ug d29uJ3QgKGl0IHdpbGwgb25seSBjb250YWluIG5vZGUgRiBhbmQgd2hhdCBpcyBtb3JlLCBpZiBu b2RlIEYgZG9lcyBub3QgZXhpc3QsIHRoZW4gUydzIFAtc3BhY2Ugd291bGQgYmUgZW1wdHkpLCB0 aGVyZWZvcmUgbm8gaW50ZXJzZWN0aW9uIG9mIHRoZSB0d28gc3BhY2VzIHdpbGwgZXhpc3QsIGxl YXZpbmcgdGhpcyBuZXR3b3JrIHZ1bG5lcmFibGUgdG8gdGhlIGZhaWx1cmUgb2YgbGluayAocyxl KS4NCg0KVGhpcyByZXN1bHRzIHRoYXQgYSBuZWlnaGJvciBzaG91bGQgYmUgYWx3YXlzIHJlYWNo ZWQgYnkgdGhlIG5laWdoYm9yaW5nIGxpbmssIGV2ZW4gaWYgdGhlcmUgZXhpc3RzIGEgc2hvcnRl ciwgYnV0IGRlZmluaXRlbHkgYmlnZ2VyIGluIGhvcC1jb3VudCBwYXRoIHRvIGl0Lg0KQWNjb3Jk aW5nIHRvIHRoaXMgY2FzZSAod2hlbiBzZWVraW5nIHNpbXBsZSBMRkEgaXMgbWlzc2VkKSwgdGhl IGNvbmRpdGlvbiBvZiBleHRlbmRlZCBQLXNwYWNlIGRlc2NyaWJlZCBieSBvdXIgZGlzdGFuY2Ug ZnVuY3Rpb25zLCBzaG91bGQgYmUgbW9kaWZpZWQgYSBiaXQ6DQpGb3Igc291cmNlIHMsIGRlc3Rp bmF0aW9uIGQsIGFuZCBuZXh0LWhvcCBlLCBzb21lIG5vZGUgbiAhPSBzLGQgaXMgYW4gZXh0ZW5k ZWQgbGluay1wcm90ZWN0aW5nIHJlbW90ZSBMRkEgZm9yIHRoZSBzLWQgcGFpciBpZiBhbmQgb25s eSBpZg0K4oiDdiDiiIggbmVpZ2gocykgOiBkaXN0KHYsIG4pIDwgZGlzdCh2LCBzKSArIGRpc3Qo cywgZSkgKyBkaXN0KGUsIG4pICAmJiBkaXN0KHMsdikgPCBkaXN0KHMsZSkgKyBkaXN0KGUsdikN CmRpc3QobiwgZCkgPCBkaXN0KG4sIHMpICsgZGlzdChzLCBkKSAuDQoNCk9uZSBjYW4gZWFzaWx5 IG9ic2VydmUgdGhhdCBlbXBoYXNpemluZyBtb3JlIHRoYXQgcmVtb3RlIExGQSBzZWVraW5nIHBy b2Nlc3MgaXMgb25seSAiZXhlY3V0ZWQiIGFmdGVyIG5vIHNpbXBsZSBMRkEgaXMgZm91bmQgY291 bGQgbXVjaCBtb3JlIGVhc2UgdGhlIHVuZGVyc3RhbmRpbmcgYW5kIHdvbid0IHJlc3VsdCBhIGhl YWRhY2hlIHRvIHRoZSByZWFkZXIgd2hvIGFjY2lkZW50YWxseSB3YW50cyB0byBjYWxjdWxhdGUg ckxGQSBjb3ZlcmFnZSBpbiBzdWNoIG5ldHdvcmsuDQoNClBsZWFzZSBsZXQgbWUga25vdywgaWYg bXkgaW50ZXJwcmV0YXRpb24gaXMgbm90IGNvcnJlY3QuDQpUaGFua3MuDQoNCkJlc3QsDQpMZXZl bnRlDQoNCg== --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5A5ESESSMB307erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BcmUgdGhlc2UgdGhlIHNpbmdsZSBvciB0aGUgYmlkaXJlY3Rp b25hbCBjb3ZlcmFnZSByZXN1bHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2Fib3I8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gcnRnd2ctYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxl dmVudGUgQ3Npa29yPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDAyLCAyMDEzIDg6 MjUgQU08YnI+DQo8Yj5Ubzo8L2I+IHN0YnJ5YW50QGNpc2NvLmNvbTxicj4NCjxiPkNjOjwvYj4g ZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhQHRvb2xzLmlldGYub3JnOyBydGd3Zy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc7IHJ0Z3dnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBk cmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmEgLSByZWFkeSBmb3IgV0dMQz8gLSBzb21lIGNvbW1l bnRzIGFuZCBxdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkRlYXIgQWxsLDxicj4NCkknbSBz ZW5kaW5nIG15IHByZXZpb3VzIG1haWwgYWdhaW4gc2luY2UgdGhlIGZvbnQgZm9yIHRoZSBBU0NJ SSBhcnQgbmV0d29yayB3YXMgbm90IGZpeGVkIGFuZCBtYXkgbm90IGFwcGVhciBpbiBhIHJpZ2h0 IGZvcm1hdCBhdCBldmVyeW9uZS48YnI+DQo8YnI+DQpJZiBpdCBzdGlsbCBtZXNzeSwgbGV0IG1l IGtub3cuPGJyPg0KPGJyPg0KU29ycnksPGJyPg0KTGV2ZW50ZTxicj4NCjxicj4NCjxicj4NCkRl YXIgQWxsLDxicj4NCnNpbmNlIG91ciBwcmV2aW91cyB3b3JrcyBpbiByZW1vdGUgTEZBIGFuYWx5 c2lzIChwYXBlcnMgYWxyZWFkeSBzZW50IHRvIHRoZXNlIG1haWxpbmcgbGlzdHMpIGFzc3VtZWQg dW5pdCBjb3N0IG5ldHdvcmtzLCB0aGVyZWZvcmUgYXMgSSBwcm9taXNlZCwgSSBjYWxjdWxhdGVk IHRoZSBjb3JyZXNwb25kaW5nIExGQSBhbmQgckxGQSBjb3ZlcmFnZXMgaW4gdGhvc2UgbmV0d29y a3Mgd2l0aCB0aGVpciBvcmlnaW5hbCBsaW5rIGNvc3RzLjxicj4NClRoZXNlIG5ldHdvcmtzIHdl cmUgaW5mZXJyZWQgZnJvbSBSb2NrZXRmdWVsIGRhdGFzZXQgKDxpPk1haGFqYW4sIFIuLCBTcHJp bmcsIE4uLCBXZXRoZXJhbGwsIEQuLCBBbmRlcnNvbiwgVC46PGJyPg0KSW5mZXJyaW5nIGxpbmsg d2VpZ2h0cyB1c2luZyBlbmQtdG8tZW5kIG1lYXN1cmVtZW50cy4gSW46IEFDTSBJTUMsIHBwLiAy MzHigJMyMzYgKDIwMDIpPC9pPiksIFNORExpYiAoPGEgaHJlZj0iaHR0cDovL3NuZGxpYi56aWIu ZGUiPmh0dHA6Ly9zbmRsaWIuemliLmRlPC9hPiksIGFuZCBUb3BvbG9neVpvbyg8YSBocmVmPSJo dHRwOi8vd3d3LnRvcG9sb2d5LXpvby5vcmciPmh0dHA6Ly93d3cudG9wb2xvZ3ktem9vLm9yZzwv YT4pLiBUaGUgZm91bmQgY292ZXJhZ2VzDQogYW5kIHNvbWUgZGV0YWlscyBhcmUgZm91bmQgaW4g dGhlIHRhYmxlIGJlbG93LCB3aGVyZSA8aT5uPC9pPiBhbmQgPGk+bTwvaT4gZGVub3RlIHRoZSBu dW1iZXIgb2Ygbm9kZXMgYW5kIHRoZSBudW1iZXIgb2YgbGlua3MsIHJlc3BlY3RpdmVseS4gVGhl IG90aGVyIGNvbHVtbnMgbWFyayB0aGUgZGlmZmVyZW50IGNvdmVyYWdlcyBvYnJ0YWluZWQgYnkg c2ltcGxlIExGQSBhbmQgcmVtb3RlIExGQSwgd2hlcmUgTFAgaW5kaWNhdGVzIHRoZSBsaW5rLXBy b3RlY3RpbmcNCiBjYXNlLCB3aGlsZSBOUCBub3RlcyB0aGUgY2FzZSBvZiBub2RlIHByb3RlY3Rp b24uPGJyPg0KVG9wb2xvZ2llcyBtYXJrZWQgd2l0aCBhbiBhc3RlcmlzaygqKSBkaWQgbm90IGhh dmUgaW5mZXJyZWQgcmVhbCBsaW5rIGNvc3RzIGZyb20gdGhlIGRhdGFzZXRzLCBzbyB0aGVpciBj b3N0cyB3ZXJlIGluaXRpYWxseSBzZXQgdG8gMSAodW5pdCBjb3N0cykuPGJyPg0KPGJyPg0KSSBi ZWxpZXZlIHRoYXQgdGhlc2UgcmVzdWx0cyBjb21wdXRlZCBvbiByZWFsLXdvcmxkIG5ldHdvcmtz IGNvdWxkIHNpZ25pZmljYW50bHkgaW1wcm92ZSB0aGUgcmxmYSBkcmFmdCwgZXNwZWNpYWxseSBT ZWMuIDkuMy4sIGFuZCB0aGUgYWR2YW50YWdlcyBvZiByZW1vdGUgTEZBIG92ZXIgc2ltcGxlIExG QSB3b3VsZCBiZSBtb3JlIGVtcGhhc2l6ZWQuPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjxicj4NCjx0 dD4mIzQzOz09PT09PT09PT09PT09JiM0Mzs9PT09JiM0Mzs9PT09JiM0Mzs9PT09PT09PT09JiM0 Mzs9PT09PT09PT09PSYjNDM7PT09PT09PT09PT09JiM0Mzs9PT09PT09PT09PT0mIzQzOzwvdHQ+ PGJyPg0KPHR0PnwgVG9wb2xvZ3kmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBuJm5ic3A7IHwg bSZuYnNwOyB8IExGQV9MUCZuYnNwOyZuYnNwOyB8IExGQV9OUCZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7IHJMRkFfTFAmbmJzcDsmbmJzcDsgfCZuYnNwOyByTEZBX05QJm5ic3A7Jm5ic3A7IHw8 L3R0Pjxicj4NCjx0dD4mIzQzOz09PT09PT09PT09PT09JiM0Mzs9PT09JiM0Mzs9PT09JiM0Mzs9 PT09PT09PT09JiM0Mzs9PT09PT09PT09PSYjNDM7PT09PT09PT09PT09JiM0Mzs9PT09PT09PT09 PT0mIzQzOzwvdHQ+PGJyPg0KPHR0PnwgQVMxMjIxJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyB8IDcmbmJzcDsgfCA5Jm5ic3A7IHwgMC44MDkmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyAwLjI1Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC44MDkmbmJzcDsg Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgMC4yNSZuYnNwOyZuYnNwOyZuYnNwOyB8PC90dD48 YnI+DQo8dHQ+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0t LS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0 Mzs8L3R0Pjxicj4NCjx0dD58IEFTMTIzOSAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgMzAg fCA2OSB8IDAuODczNSZuYnNwOyZuYnNwOyB8Jm5ic3A7IDAuNzU1NCZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7 IDAuOTc5NSZuYnNwOyZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0MzstLS0tLS0tLS0tLS0tLSYj NDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxicj4NCjx0dD58IEFTMTc1NSAmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgMTggfCAzMyB8IDAuODcyNSAmbmJzcDsgfCZuYnNwOyAw Ljc3NDEmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk5NjcgJm5ic3A7IHwmbmJzcDsmbmJz cDsgMC45OTU5ICZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7 LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0t LS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxicj4NCjx0dD58IEFTMzI1NyAmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7IHwgMjcgfCA2NCB8IDAuOTIzJm5ic3A7ICZuYnNwOyB8Jm5ic3A7 IDAuNzE4NiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTkgJm5ic3A7ICZuYnNwOyB8Jm5i c3A7Jm5ic3A7IDAuODQ3MiAmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0t LS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBBUzM5Njcg Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDIxIHwgMzYgfCAwLjc4NTcgJm5ic3A7IHwmbmJz cDsgMC42NDYwICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTMyNSZuYnNwOyZuYnNwOyB8PC90dD48YnI+DQo8dHQ+ JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxi cj4NCjx0dD58IEFTNjQ2MSAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgMTcgfCAzNyB8IDAu OTMzOCZuYnNwOyZuYnNwOyB8Jm5ic3A7IDAuNjkzMyAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk5 NjMgJm5ic3A7IHwmbmJzcDsmbmJzcDsgMC43MDc1ICZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0 MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxicj4N Cjx0dD58IEFiaWxlbmUqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMTIgfCAxNSB8IDAuNTYw NiZuYnNwOyZuYnNwOyB8Jm5ic3A7IDAuNjA3OCAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjkwOTAg Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC44NzI1ICZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0Mzst LS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0t LS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxicj4NCjx0 dD58IEFybmVzKiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgNDEgfCA1NyB8IDAuNjIyNSAm bmJzcDsgfCZuYnNwOyAwLjM1MTggJm5ic3A7IHwmbmJzcDsmbmJzcDsgMC43NDg3ICZuYnNwOyB8 Jm5ic3A7Jm5ic3A7IDAuNDU2MiAmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0t LS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBBVCZh bXA7VCAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDIyIHwgMzggfCAwLjgyMjUg Jm5ic3A7IHwmbmJzcDsgMC41NjQ3ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEg Jm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODQ5NyAmbmJzcDsgfDwvdHQ+PGJy Pg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7 PC90dD48YnI+DQo8dHQ+fCBEZWx0YWNvbSZuYnNwOyAmbmJzcDsmbmJzcDsgfCAxMTN8IDE2MXwg MC41NzcxICZuYnNwOyB8Jm5ic3A7IDAuNDkxMCAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjg1Mzkg Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC44MTQ4ICZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0Mzst LS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0t LS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxicj4NCjx0 dD58IEdhbWJpYSAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgMjggfCAyOCB8IDAuMDM3ICZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuMDQgJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsg MC4xODUxICZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICZuYnNwOyAwLjEyICZuYnNwOyB8PC90dD48YnI+ DQo8dHQ+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8 L3R0Pjxicj4NCjx0dD58IEdlYW50Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCAz NyB8IDU1IHwgMC42OTA2Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgMC4zOTc3ICZuYnNwOyB8Jm5ic3A7 Jm5ic3A7IDAuODMwMyAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjY1ODIgJm5ic3A7IHw8L3R0Pjxi cj4NCjx0dD4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0tLS0t LS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQz OzwvdHQ+PGJyPg0KPHR0PnwgR2VybV81MCZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCA1MCB8 IDg4IHwgMC45MDA0Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgMC44MzgxICZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTk5 NSAmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQz Oy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBHZXJtYW55KiZuYnNwOyAmbmJzcDsm bmJzcDsgfCAyNyB8IDMyIHwgMC42OTQ4ICZuYnNwOyB8Jm5ic3A7IDAuNTk5Jm5ic3A7ICZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7IDAuOTU0OSAmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0m IzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBJbnRlcm5ldE1D SSZuYnNwOyB8IDE5IHwgMzMgfCAwLjkwMzUgJm5ic3A7IHwmbmJzcDsgMC42Nzk4ICZuYnNwOyB8 Jm5ic3A7Jm5ic3A7IDAuOTQxNSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTEzNiAmbmJz cDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0m IzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBJdGFseSogJm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyB8IDMzIHwgNTYgfCAwLjc4NCZuYnNwOyAmbmJzcDsgfCZuYnNwOyAwLjU3NDEgJm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSAmbmJzcDsgJm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsgMC45MjY5ICZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0MzstLS0tLS0tLS0tLS0tLSYj NDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxicj4NCjx0dD58IE5TRiogJm5ic3A7 ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCAyNiB8IDQzIHwgMC44NiAmbmJzcDsgJm5ic3A7 IHwmbmJzcDsgMC42MzQ3ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7 ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICZuYnNwOyAxICZuYnNwOyAmbmJzcDsmbmJzcDsg fDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQz Oy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0t LS0tLSYjNDM7PC90dD48L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KRnVydGhlcm1vcmUsIGFmdGVy IHJlYWRpbmcgdGhlIGRyYWZ0IGFnYWluLWFuZC1hZ2FpbiwgSSBoYXZlIGZvdW5kIHRoYXQgaXQg c2hvdWxkIGJlIG1vcmUgZW1waGFzaXplZCBpbiB0aGUgZHJhZnQgdGhhdCBjYWxjdWxhdGluZyBv ciBzZWVraW5nIGZvciBhIHJlbW90ZSBMRkEgc3RhZ2luZyBwb2ludCBzaG91bGQgYmUgZG9uZSBJ RiBBTkQgT05MWSBJRiBubyBzaW1wbGUgTEZBIHdlcmUgZm91bmQuIFRoaXMgaXMgaW1wb3J0YW50 LCBzaW5jZSBub3JtYWxseQ0KIHBlb3BsZSBvYnZpb3VzbHkgdGhpbmsgYW5kIG9ic2VydmUgdGhh dCB0aGUgZmFpbHVyZSBjb3ZlcmFnZSBvZiByZW1vdGUgTEZBIHNob3VsZCBiZSBncmVhdGVyIHRo YW4gb3IgZXF1YWwgdG8gdGhlIGNvdmVyYWdlIG9idGFpbmVkIGJ5IHNpbXBsZSBMRkEuIE1vcmVv dmVyLCBwZW9wbGUgYWxzbyB0aGluayB0aGF0IExGQXMgcHJvZHVjZSBhIHN1YnNldCBvZiByZW1v dGUgTEZBcy4gSG93ZXZlciwgaWYgYWZ0ZXIgYSBmYWlsdXJlIG9ubHkgUC1zcGFjZXMNCiBhbmQg US1zcGFjZXMgYXJlIHRha2VuIGludG8gYWNjb3VudCBpbiBvcmRlciB0byBzZWVrIGEgKHJlbW90 ZSkgbG9vcC1mcmVlIGFsdGVybmF0ZSwgdGhlbiBpdCBpcyBwb3NzaWJsZSB0aGF0IGEgc2ltcGxl IExGQSB3b3VsZCBub3QgYmUgZm91bmQgcmVzdWx0aW5nIHVucHJvdGVjdGVkIG5vZGUtcGFpcnMu IEJ1dCwgdGhpcyBjYXNlIGNvdWxkIG9ubHkgaGFwcGVuIHdoZW4gbGluayBjb3N0cyBhcmUgbm90 IHVuaXQgY29zdHMuIEZvciBhbiBlYXNpZXINCiB1bmRlcnN0YW5kaW5nLCBjb25zaWRlciB0aGUg bmV0d29yayBkZXBpY3RlZCBiZWxvdzo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDEmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgMTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGLS0tLS0tLS1TLS0tLS0t LS0tLS1YLS0tLS0tLS1FPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IFw8 L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDEwIFwmbmJzcDsmbmJzcDsmbmJzcDsgLyA0Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgXCZuYnNwOyAxPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgXCZuYnNwOyAvJm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAxICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBcPC90dD48YnI+DQo8dHQ+ Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tQzwvdHQ+PGJyPg0KPHR0PiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCA8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyB8Jm5ic3A7IDE8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsgfDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAxJm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMSAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBLS0tLS0tLS0tLS0tLS1CLS0tLS0tLS0tLS0tLUQ8L3R0Pjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj48YnI+DQpB c3N1bWUgdGhhdCBTIHdpc2hlcyB0byBzZW5kIGEgcGFja2V0IHRvIEQsIGFuZCB0aGUgc2hvcnRl c3QgcGF0aCBnb2VzIHRocm91Z2ggRSwgdGhlcmVmb3JlIGl0IGlzIFMtRS1DLUQuIFN1cHBvc2Ug dGhhdCB0aGUgbGluayAocyxlKTxicj4NCmZhaWxzLCBvciBldmVuIHRoZSBub2RlIGUgaXRzZWxm IGZhaWxzLiBJbiB0aGlzIGNhc2UsIHNpbmNlIExGQSAoYW5kIGl0cyBjYWxjdWxhdGlvbikgb25s eSBjb25zaWRlciBhbGwgb3RoZXIgbmVpZ2hib3JzIG9mIHMsIHRoZW4gbm9kZSBOIHdvdWxkIGJl IGFuIGVhc3kgTEZBIGZvciB0aGlzIGZhaWx1cmUsIHNpbmNlIGRpc3QoTixEKSAmbHQ7IGRpc3Qo TixTKSYjNDM7ZGlzdChTLEQpLjxicj4NCkhvd2V2ZXIsIGlmIHdlIG9ubHkgc2VlayBwb3NzaWJs ZSByZW1vdGUgTEZBcywgdGhhbiBhY2NvcmRpbmcgdG8gdGhlIChyKVNQRiBjYWxjdWxhdGlvbnMs IG9yIHRha2luZyBpbnRvIGFjY291bnQgb3VyIGRpc3RhbmNlLWZ1bmN0aW9uIGNvbmRpdGlvbnMg d2lsbCByZXN1bHQgdGhhdCBEJ3MgUS1zcGFjZSB3aWxsIGNvbnRhaW4gbm9kZSBOIChiZXNpZGVz IHNvbWUgb3RoZXIgbm9kZXMpLCBidXQgUydzIFAtc3BhY2Ugd29uJ3QgKGl0IHdpbGwgb25seQ0K IGNvbnRhaW4gbm9kZSBGIGFuZCB3aGF0IGlzIG1vcmUsIGlmIG5vZGUgRiBkb2VzIG5vdCBleGlz dCwgdGhlbiBTJ3MgUC1zcGFjZSB3b3VsZCBiZSBlbXB0eSksIHRoZXJlZm9yZSBubyBpbnRlcnNl Y3Rpb24gb2YgdGhlIHR3byBzcGFjZXMgd2lsbCBleGlzdCwgbGVhdmluZyB0aGlzIG5ldHdvcmsg dnVsbmVyYWJsZSB0byB0aGUgZmFpbHVyZSBvZiBsaW5rIChzLGUpLjxicj4NCjxicj4NClRoaXMg cmVzdWx0cyB0aGF0IGEgbmVpZ2hib3Igc2hvdWxkIGJlIGFsd2F5cyByZWFjaGVkIGJ5IHRoZSBu ZWlnaGJvcmluZyBsaW5rLCBldmVuIGlmIHRoZXJlIGV4aXN0cyBhIHNob3J0ZXIsIGJ1dCBkZWZp bml0ZWx5IGJpZ2dlciBpbiBob3AtY291bnQgcGF0aCB0byBpdC48YnI+DQpBY2NvcmRpbmcgdG8g dGhpcyBjYXNlICh3aGVuIHNlZWtpbmcgc2ltcGxlIExGQSBpcyBtaXNzZWQpLCB0aGUgY29uZGl0 aW9uIG9mIGV4dGVuZGVkIFAtc3BhY2UgZGVzY3JpYmVkIGJ5IG91ciBkaXN0YW5jZSBmdW5jdGlv bnMsIHNob3VsZCBiZSBtb2RpZmllZCBhIGJpdDo8YnI+DQpGb3Igc291cmNlIDxpPnM8L2k+LCBk ZXN0aW5hdGlvbiA8aT5kPC9pPiwgYW5kIG5leHQtaG9wIDxpPmU8L2k+LCBzb21lIG5vZGUgPGk+ biAhPSBzLGQ8L2k+IGlzIGFuIGV4dGVuZGVkIGxpbmstcHJvdGVjdGluZyByZW1vdGUgTEZBIGZv ciB0aGUNCjxpPnMtZDwvaT4gcGFpciBpZiBhbmQgb25seSBpZjxicj4NCjxpPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PuKIgzwvc3Bhbj48L2k+PGk+diA8L2k+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oiIPC9zcGFuPjwvaT48aT4g bmVpZ2gocykgOiBkaXN0KHYsIG4pICZsdDsgZGlzdCh2LCBzKSAmIzQzOyBkaXN0KHMsIGUpICYj NDM7IGRpc3QoZSwgbikmbmJzcDsNCjxiPiZhbXA7JmFtcDsgZGlzdChzLHYpICZsdDsgZGlzdChz LGUpICYjNDM7IGRpc3QoZSx2KTwvYj48L2k+PGJyPg0KPGk+ZGlzdChuLCBkKSAmbHQ7IGRpc3Qo biwgcykgJiM0MzsgZGlzdChzLCBkKSAuIDwvaT48YnI+DQo8YnI+DQpPbmUgY2FuIGVhc2lseSBv YnNlcnZlIHRoYXQgZW1waGFzaXppbmcgbW9yZSB0aGF0IHJlbW90ZSBMRkEgc2Vla2luZyBwcm9j ZXNzIGlzIG9ubHkgJnF1b3Q7ZXhlY3V0ZWQmcXVvdDsgYWZ0ZXIgbm8gc2ltcGxlIExGQSBpcyBm b3VuZCBjb3VsZCBtdWNoIG1vcmUgZWFzZSB0aGUgdW5kZXJzdGFuZGluZyBhbmQgd29uJ3QgcmVz dWx0IGEgaGVhZGFjaGUgdG8gdGhlIHJlYWRlciB3aG8gYWNjaWRlbnRhbGx5IHdhbnRzIHRvIGNh bGN1bGF0ZSByTEZBIGNvdmVyYWdlIGluDQogc3VjaCBuZXR3b3JrLjxicj4NCjxicj4NClBsZWFz ZSBsZXQgbWUga25vdywgaWYgbXkgaW50ZXJwcmV0YXRpb24gaXMgbm90IGNvcnJlY3QuPGJyPg0K VGhhbmtzLjxicj4NCjxicj4NCkJlc3QsPGJyPg0KTGV2ZW50ZTxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5A5ESESSMB307erics_-- From csikor@tmit.bme.hu Fri Aug 2 01:01:25 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD8311E8258 for ; Fri, 2 Aug 2013 01:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.712 X-Spam-Level: * X-Spam-Status: No, score=1.712 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEs9GQQh1c0J for ; Fri, 2 Aug 2013 01:01:20 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE8E11E8269 for ; Fri, 2 Aug 2013 01:01:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 4788687350; Fri, 2 Aug 2013 10:01:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6HBcZXApT3C; Fri, 2 Aug 2013 10:00:59 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 620F887346; Fri, 2 Aug 2013 10:00:59 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r72814fM010902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 10:01:05 +0200 Message-ID: <51FB673E.9020905@tmit.bme.hu> Date: Fri, 02 Aug 2013 10:01:02 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?R8OhYm9yIFPDoW5kb3IgRW55ZWRp?= Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> <51FB50BB.90303@tmit.bme.hu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030409070709060906030401" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:01:25 -0000 This is a multi-part message in MIME format. --------------030409070709060906030401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit These are bidirectionalresults. Levente On 08/02/2013 09:59 AM, Gábor Sándor Enyedi wrote: > > Are these the single or the bidirectional coverage results? > > Gabor > > *From:*rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] *On > Behalf Of *Levente Csikor > *Sent:* Friday, August 02, 2013 8:25 AM > *To:* stbryant@cisco.com > *Cc:* draft-ietf-rtgwg-remote-lfa@tools.ietf.org; > rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org > *Subject:* Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some > comments and questions > > Dear All, > I'm sending my previous mail again since the font for the ASCII art > network was not fixed and may not appear in a right format at everyone. > > If it still messy, let me know. > > Sorry, > Levente > > > Dear All, > since our previous works in remote LFA analysis (papers already sent > to these mailing lists) assumed unit cost networks, therefore as I > promised, I calculated the corresponding LFA and rLFA coverages in > those networks with their original link costs. > These networks were inferred from Rocketfuel dataset (/Mahajan, R., > Spring, N., Wetherall, D., Anderson, T.: > Inferring link weights using end-to-end measurements. In: ACM IMC, pp. > 231–236 (2002)/), SNDLib (http://sndlib.zib.de), and > TopologyZoo(http://www.topology-zoo.org). The found coverages and some > details are found in the table below, where /n/ and /m/ denote the > number of nodes and the number of links, respectively. The other > columns mark the different coverages obrtained by simple LFA and > remote LFA, where LP indicates the link-protecting case, while NP > notes the case of node protection. > Topologies marked with an asterisk(*) did not have inferred real link > costs from the datasets, so their costs were initially set to 1 (unit > costs). > > I believe that these results computed on real-world networks could > significantly improve the rlfa draft, especially Sec. 9.3., and the > advantages of remote LFA over simple LFA would be more emphasized. > > > +==============+====+====+==========+===========+============+============+ > | Topology | n | m | LFA_LP | LFA_NP | rLFA_LP | rLFA_NP | > +==============+====+====+==========+===========+============+============+ > | AS1221 | 7 | 9 | 0.809 | 0.25 | 0.809 | 0.25 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1239 | 30 | 69 | 0.8735 | 0.7554 | 1 | > 0.9795 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1755 | 18 | 33 | 0.8725 | 0.7741 | 0.9967 | 0.9959 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3257 | 27 | 64 | 0.923 | 0.7186 | 0.99 | > 0.8472 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3967 | 21 | 36 | 0.7857 | 0.6460 | 1 | > 0.9325 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS6461 | 17 | 37 | 0.9338 | 0.6933 | 0.9963 | 0.7075 | > +--------------+----+----+----------+-----------+------------+------------+ > | Abilene* | 12 | 15 | 0.5606 | 0.6078 | 0.9090 | 0.8725 | > +--------------+----+----+----------+-----------+------------+------------+ > | Arnes* | 41 | 57 | 0.6225 | 0.3518 | 0.7487 | 0.4562 | > +--------------+----+----+----------+-----------+------------+------------+ > | AT&T | 22 | 38 | 0.8225 | 0.5647 | 1 | 0.8497 | > +--------------+----+----+----------+-----------+------------+------------+ > | Deltacom | 113| 161| 0.5771 | 0.4910 | 0.8539 | 0.8148 | > +--------------+----+----+----------+-----------+------------+------------+ > | Gambia | 28 | 28 | 0.037 | 0.04 | 0.1851 | 0.12 | > +--------------+----+----+----------+-----------+------------+------------+ > | Geant | 37 | 55 | 0.6906 | 0.3977 | 0.8303 | 0.6582 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germ_50 | 50 | 88 | 0.9004 | 0.8381 | 1 | > 0.9995 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germany* | 27 | 32 | 0.6948 | 0.599 | 1 | > 0.9549 | > +--------------+----+----+----------+-----------+------------+------------+ > | InternetMCI | 19 | 33 | 0.9035 | 0.6798 | 0.9415 | 0.9136 | > +--------------+----+----+----------+-----------+------------+------------+ > | Italy* | 33 | 56 | 0.784 | 0.5741 | 1 | > 0.9269 | > +--------------+----+----+----------+-----------+------------+------------+ > | NSF* | 26 | 43 | 0.86 | 0.6347 | 1 | 1 > | > +--------------+----+----+----------+-----------+------------+------------+ > > > Furthermore, after reading the draft again-and-again, I have found > that it should be more emphasized in the draft that calculating or > seeking for a remote LFA staging point should be done IF AND ONLY IF > no simple LFA were found. This is important, since normally people > obviously think and observe that the failure coverage of remote LFA > should be greater than or equal to the coverage obtained by simple > LFA. Moreover, people also think that LFAs produce a subset of remote > LFAs. However, if after a failure only P-spaces and Q-spaces are taken > into account in order to seek a (remote) loop-free alternate, then it > is possible that a simple LFA would not be found resulting unprotected > node-pairs. But, this case could only happen when link costs are not > unit costs. For an easier understanding, consider the network depicted > below: > 1 1 > F--------S-----------X--------E > \ / \ > 10 \ / 4 \ 1 > \ / 1 \ > N ---------------------------C > | | > 1 | | 1 > | | > | 1 1 | > A--------------B-------------D > > Assume that S wishes to send a packet to D, and the shortest path goes > through E, therefore it is S-E-C-D. Suppose that the link (s,e) > fails, or even the node e itself fails. In this case, since LFA (and > its calculation) only consider all other neighbors of s, then node N > would be an easy LFA for this failure, since dist(N,D) < > dist(N,S)+dist(S,D). > However, if we only seek possible remote LFAs, than according to the > (r)SPF calculations, or taking into account our distance-function > conditions will result that D's Q-space will contain node N (besides > some other nodes), but S's P-space won't (it will only contain node F > and what is more, if node F does not exist, then S's P-space would be > empty), therefore no intersection of the two spaces will exist, > leaving this network vulnerable to the failure of link (s,e). > > This results that a neighbor should be always reached by the > neighboring link, even if there exists a shorter, but definitely > bigger in hop-count path to it. > According to this case (when seeking simple LFA is missed), the > condition of extended P-space described by our distance functions, > should be modified a bit: > For source /s/, destination /d/, and next-hop /e/, some node /n != > s,d/ is an extended link-protecting remote LFA for the /s-d/ pair if > and only if > /∃//v //∈//neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, > n) *&& dist(s,v) < dist(s,e) + dist(e,v)*/ > /dist(n, d) < dist(n, s) + dist(s, d) . / > > One can easily observe that emphasizing more that remote LFA seeking > process is only "executed" after no simple LFA is found could much > more ease the understanding and won't result a headache to the reader > who accidentally wants to calculate rLFA coverage in such network. > > Please let me know, if my interpretation is not correct. > Thanks. > > Best, > Levente > --------------030409070709060906030401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit These are bidirectional results.

Levente
On 08/02/2013 09:59 AM, Gábor Sándor Enyedi wrote:

Are these the single or the bidirectional coverage results?

 

Gabor

 

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Levente Csikor
Sent: Friday, August 02, 2013 8:25 AM
To: stbryant@cisco.com
Cc: draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org
Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions

 

Dear All,
I'm sending my previous mail again since the font for the ASCII art network was not fixed and may not appear in a right format at everyone.

If it still messy, let me know.

Sorry,
Levente


Dear All,
since our previous works in remote LFA analysis (papers already sent to these mailing lists) assumed unit cost networks, therefore as I promised, I calculated the corresponding LFA and rLFA coverages in those networks with their original link costs.
These networks were inferred from Rocketfuel dataset (Mahajan, R., Spring, N., Wetherall, D., Anderson, T.:
Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 231–236 (2002)), SNDLib (http://sndlib.zib.de), and TopologyZoo(http://www.topology-zoo.org). The found coverages and some details are found in the table below, where n and m denote the number of nodes and the number of links, respectively. The other columns mark the different coverages obrtained by simple LFA and remote LFA, where LP indicates the link-protecting case, while NP notes the case of node protection.
Topologies marked with an asterisk(*) did not have inferred real link costs from the datasets, so their costs were initially set to 1 (unit costs).

I believe that these results computed on real-world networks could significantly improve the rlfa draft, especially Sec. 9.3., and the advantages of remote LFA over simple LFA would be more emphasized.


+==============+====+====+==========+===========+============+============+
| Topology     | n  | m  | LFA_LP   | LFA_NP    |  rLFA_LP   |  rLFA_NP   |
+==============+====+====+==========+===========+============+============+
| AS1221       | 7  | 9  | 0.809    |   0.25    |   0.809    |    0.25    |
+--------------+----+----+----------+-----------+------------+------------+
| AS1239       | 30 | 69 | 0.8735   |  0.7554   |     1      |   0.9795   |
+--------------+----+----+----------+-----------+------------+------------+
| AS1755       | 18 | 33 | 0.8725   |  0.7741   |   0.9967   |   0.9959   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3257       | 27 | 64 | 0.923    |  0.7186   |   0.99     |   0.8472   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3967       | 21 | 36 | 0.7857   |  0.6460   |     1      |   0.9325   |
+--------------+----+----+----------+-----------+------------+------------+
| AS6461       | 17 | 37 | 0.9338   |  0.6933   |   0.9963   |   0.7075   |
+--------------+----+----+----------+-----------+------------+------------+
| Abilene*     | 12 | 15 | 0.5606   |  0.6078   |   0.9090   |   0.8725   |
+--------------+----+----+----------+-----------+------------+------------+
| Arnes*       | 41 | 57 | 0.6225   |  0.3518   |   0.7487   |   0.4562   |
+--------------+----+----+----------+-----------+------------+------------+
| AT&T         | 22 | 38 | 0.8225   |  0.5647   |     1      |   0.8497   |
+--------------+----+----+----------+-----------+------------+------------+
| Deltacom     | 113| 161| 0.5771   |  0.4910   |   0.8539   |   0.8148   |
+--------------+----+----+----------+-----------+------------+------------+
| Gambia       | 28 | 28 | 0.037    |   0.04    |   0.1851   |     0.12   |
+--------------+----+----+----------+-----------+------------+------------+
| Geant        | 37 | 55 | 0.6906   |  0.3977   |   0.8303   |   0.6582   |
+--------------+----+----+----------+-----------+------------+------------+
| Germ_50      | 50 | 88 | 0.9004   |  0.8381   |     1      |   0.9995   |
+--------------+----+----+----------+-----------+------------+------------+
| Germany*     | 27 | 32 | 0.6948   |  0.599    |     1      |   0.9549   |
+--------------+----+----+----------+-----------+------------+------------+
| InternetMCI  | 19 | 33 | 0.9035   |  0.6798   |   0.9415   |   0.9136   |
+--------------+----+----+----------+-----------+------------+------------+
| Italy*       | 33 | 56 | 0.784    |  0.5741   |     1      |   0.9269   |
+--------------+----+----+----------+-----------+------------+------------+
| NSF*         | 26 | 43 | 0.86     |  0.6347   |     1      |     1      |
+--------------+----+----+----------+-----------+------------+------------+


Furthermore, after reading the draft again-and-again, I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found. This is important, since normally people obviously think and observe that the failure coverage of remote LFA should be greater than or equal to the coverage obtained by simple LFA. Moreover, people also think that LFAs produce a subset of remote LFAs. However, if after a failure only P-spaces and Q-spaces are taken into account in order to seek a (remote) loop-free alternate, then it is possible that a simple LFA would not be found resulting unprotected node-pairs. But, this case could only happen when link costs are not unit costs. For an easier understanding, consider the network depicted below:
            1              1
          F--------S-----------X--------E
           \      /                      \
         10 \    / 4                      \  1
             \  /        1                 \
              N ---------------------------C
              |                            |
           1  |                            |  1
              |                            |
              |      1             1       |
              A--------------B-------------D

Assume that S wishes to send a packet to D, and the shortest path goes through E, therefore it is S-E-C-D. Suppose that the link (s,e)
fails, or even the node e itself fails. In this case, since LFA (and its calculation) only consider all other neighbors of s, then node N would be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D).
However, if we only seek possible remote LFAs, than according to the (r)SPF calculations, or taking into account our distance-function conditions will result that D's Q-space will contain node N (besides some other nodes), but S's P-space won't (it will only contain node F and what is more, if node F does not exist, then S's P-space would be empty), therefore no intersection of the two spaces will exist, leaving this network vulnerable to the failure of link (s,e).

This results that a neighbor should be always reached by the neighboring link, even if there exists a shorter, but definitely bigger in hop-count path to it.
According to this case (when seeking simple LFA is missed), the condition of extended P-space described by our distance functions, should be modified a bit:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)  && dist(s,v) < dist(s,e) + dist(e,v)
dist(n, d) < dist(n, s) + dist(s, d) .

One can easily observe that emphasizing more that remote LFA seeking process is only "executed" after no simple LFA is found could much more ease the understanding and won't result a headache to the reader who accidentally wants to calculate rLFA coverage in such network.

Please let me know, if my interpretation is not correct.
Thanks.

Best,
Levente


--------------030409070709060906030401-- From gabor.sandor.enyedi@ericsson.com Fri Aug 2 01:10:57 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2B411E8269 for ; Fri, 2 Aug 2013 01:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmT50sGabrbD for ; Fri, 2 Aug 2013 01:10:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7A42711E82A4 for ; Fri, 2 Aug 2013 01:10:38 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-5b-51fb69763b29 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 30.F9.05990.6796BF15; Fri, 2 Aug 2013 10:10:30 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.48]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 10:10:30 +0200 From: =?utf-8?B?R8OhYm9yIFPDoW5kb3IgRW55ZWRp?= To: Levente Csikor Subject: RE: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Topic: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Index: AQHOj1Z5wa1kp5HEfkKSt2gXwoRsH5mBjn6Q Date: Fri, 2 Aug 2013 08:10:29 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> <51FB50BB.90303@tmit.bme.hu> <51FB673E.9020905@tmit.bme.hu> In-Reply-To: <51FB673E.9020905@tmit.bme.hu> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5E5ESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+JvrW5Z5u9Ag9mHBC3+7P7MaLF8wQ1G i5sHZzJZXHjzm9ni3NM5jA6sHlN+b2T1WLLkJ5PHsmfzWD2+XP7MFsASxWWTkpqTWZZapG+X wJWx+LdMwY01TBV/r15naWB8sYSpi5GDQ0LARGJaH1cXIyeQKSZx4d56ti5GLg4hgcOMEk2f nzFBOIsYJXZe2scOUsUmECxx/9NtMFtEQF2i881nNhCbWeAdo8SXMyIgtrBAlETL/pOsEDXR Ep1LLzKDLBMRMJJ4eD0LJMwioCIxa8FisFZeAV+JH0/fQu1awyRx5Px6JpAEp4C2xM9p/awg vYwCshIP11pArBKXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSfzYcIkFoj5fYuKiaewQuwQl Ts58wjKBUXQWklGzkJTNQlI2C2gzs4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FyJ6b mJmTXm60iREYgwe3/FbdwXjnnMghRmkOFiVx3s16ZwKFBNITS1KzU1MLUovii0pzUosPMTJx cEo1MO78fmmX1I1q+RJF3W0JKsKV8YXbnA1f2n5c1hAtvSm3zf4tg1pAh1/Whg/FW6f2LL1e 8+/s9RWFb/0ntkw4GNZXkv2zwzM+d+eOHtZSbaHlByzClfL2ieX5vWbxeC9VNj922XbD62af HXWCAvf41kVKyJ940BNzccaLj917tCZ4Rgf3TX/lp8RSnJFoqMVcVJwIAIIygKKPAgAA Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:10:57 -0000 --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5E5ESESSMB307erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmljZS4gSG93ZXZlciwgSeKAmW0gYSBiaXQgY29uZnVzZWQsIGJlY2F1c2UgdG9wb2xvZ2llcyB3 aXRoIHVuaWZvcm0gbGluayBjb3N0cyBzaG91bGQgaGF2ZSAxMDAlIGxpbmsgZmFpbHVyZSBjb3Zl cmFnZSAoaWYgdGhleSBhcmUgMi1jb25uZWN0ZWQpLCBzaG91bGRu4oCZdCB0aGV5PyBJc27igJl0 IEFiaWxlbmUgYW5kIEFybmVzIDItY29ubmVjdGVkPw0KDQpPdGhlcjogZGlkIHlvdSBub3RpY2Vk IHRoYXQgd2l0aCBzb21lIG1pbmltYWwgZXh0cmEgY29tcHV0YXRpb24sIGl0IGlzIHBvc3NpYmxl IHRvIHJlYWNoIDEwMCUgbm9kZSBwcm90ZWN0aW9uIHdpdGggckxGQSwgaWYgd2Ugc3VwcG9zZSB0 aGF0IGFsbCB0aGUgbm9kZXMgZG8gckxGQSBpbiB0aGUgbmV0d29yay4gTWF5YmUgd2UgY291bGQg YXNzaWduIGEgc2luZ2xlIGV4dHJhIGxhYmVsL0lQIGFkZHJlc3MgdG8gc2F5IHRoYXQg4oCcdXNl IHVuaWZvcm0gbGluayBjb3N0cyBmb3IgdGhpcyBwYWNrZXTigJ0sIGFuZCBnZXQgc29tZXRoaW5n IHF1aXRlIHNpbWlsYXIgdG8gTVJUPyA6KQ0KDQpHYWJvcg0KDQpGcm9tOiBMZXZlbnRlIENzaWtv ciBbbWFpbHRvOmNzaWtvckB0bWl0LmJtZS5odV0NClNlbnQ6IEZyaWRheSwgQXVndXN0IDAyLCAy MDEzIDEwOjAxIEFNDQpUbzogR8OhYm9yIFPDoW5kb3IgRW55ZWRpDQpDYzogc3RicnlhbnRAY2lz Y28uY29tOyBkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmFAdG9vbHMuaWV0Zi5vcmc7IHJ0Z3dn LWNoYWlyc0B0b29scy5pZXRmLm9yZzsgcnRnd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBkcmFm dC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmEgLSByZWFkeSBmb3IgV0dMQz8gLSBzb21lIGNvbW1lbnRz IGFuZCBxdWVzdGlvbnMNCg0KVGhlc2UgYXJlIGJpZGlyZWN0aW9uYWwgcmVzdWx0cy4NCg0KTGV2 ZW50ZQ0KT24gMDgvMDIvMjAxMyAwOTo1OSBBTSwgR8OhYm9yIFPDoW5kb3IgRW55ZWRpIHdyb3Rl Og0KQXJlIHRoZXNlIHRoZSBzaW5nbGUgb3IgdGhlIGJpZGlyZWN0aW9uYWwgY292ZXJhZ2UgcmVz dWx0cz8NCg0KR2Fib3INCg0KRnJvbTogcnRnd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRn d2ctYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTGV2ZW50ZSBDc2lrb3INClNlbnQ6IEZyaWRheSwgQXVndXN0IDAyLCAyMDEzIDg6 MjUgQU0NClRvOiBzdGJyeWFudEBjaXNjby5jb208bWFpbHRvOnN0YnJ5YW50QGNpc2NvLmNvbT4N CkNjOiBkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmFAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtcnRnd2ctcmVtb3RlLWxmYUB0b29scy5pZXRmLm9yZz47IHJ0Z3dnLWNoYWlyc0B0 b29scy5pZXRmLm9yZzxtYWlsdG86cnRnd2ctY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgcnRnd2dA aWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IGRyYWZ0LWlldGYt cnRnd2ctcmVtb3RlLWxmYSAtIHJlYWR5IGZvciBXR0xDPyAtIHNvbWUgY29tbWVudHMgYW5kIHF1 ZXN0aW9ucw0KDQpEZWFyIEFsbCwNCkknbSBzZW5kaW5nIG15IHByZXZpb3VzIG1haWwgYWdhaW4g c2luY2UgdGhlIGZvbnQgZm9yIHRoZSBBU0NJSSBhcnQgbmV0d29yayB3YXMgbm90IGZpeGVkIGFu ZCBtYXkgbm90IGFwcGVhciBpbiBhIHJpZ2h0IGZvcm1hdCBhdCBldmVyeW9uZS4NCg0KSWYgaXQg c3RpbGwgbWVzc3ksIGxldCBtZSBrbm93Lg0KDQpTb3JyeSwNCkxldmVudGUNCg0KDQpEZWFyIEFs bCwNCnNpbmNlIG91ciBwcmV2aW91cyB3b3JrcyBpbiByZW1vdGUgTEZBIGFuYWx5c2lzIChwYXBl cnMgYWxyZWFkeSBzZW50IHRvIHRoZXNlIG1haWxpbmcgbGlzdHMpIGFzc3VtZWQgdW5pdCBjb3N0 IG5ldHdvcmtzLCB0aGVyZWZvcmUgYXMgSSBwcm9taXNlZCwgSSBjYWxjdWxhdGVkIHRoZSBjb3Jy ZXNwb25kaW5nIExGQSBhbmQgckxGQSBjb3ZlcmFnZXMgaW4gdGhvc2UgbmV0d29ya3Mgd2l0aCB0 aGVpciBvcmlnaW5hbCBsaW5rIGNvc3RzLg0KVGhlc2UgbmV0d29ya3Mgd2VyZSBpbmZlcnJlZCBm cm9tIFJvY2tldGZ1ZWwgZGF0YXNldCAoTWFoYWphbiwgUi4sIFNwcmluZywgTi4sIFdldGhlcmFs bCwgRC4sIEFuZGVyc29uLCBULjoNCkluZmVycmluZyBsaW5rIHdlaWdodHMgdXNpbmcgZW5kLXRv LWVuZCBtZWFzdXJlbWVudHMuIEluOiBBQ00gSU1DLCBwcC4gMjMx4oCTMjM2ICgyMDAyKSksIFNO RExpYiAoaHR0cDovL3NuZGxpYi56aWIuZGUpLCBhbmQgVG9wb2xvZ3lab28oaHR0cDovL3d3dy50 b3BvbG9neS16b28ub3JnKS4gVGhlIGZvdW5kIGNvdmVyYWdlcyBhbmQgc29tZSBkZXRhaWxzIGFy ZSBmb3VuZCBpbiB0aGUgdGFibGUgYmVsb3csIHdoZXJlIG4gYW5kIG0gZGVub3RlIHRoZSBudW1i ZXIgb2Ygbm9kZXMgYW5kIHRoZSBudW1iZXIgb2YgbGlua3MsIHJlc3BlY3RpdmVseS4gVGhlIG90 aGVyIGNvbHVtbnMgbWFyayB0aGUgZGlmZmVyZW50IGNvdmVyYWdlcyBvYnJ0YWluZWQgYnkgc2lt cGxlIExGQSBhbmQgcmVtb3RlIExGQSwgd2hlcmUgTFAgaW5kaWNhdGVzIHRoZSBsaW5rLXByb3Rl Y3RpbmcgY2FzZSwgd2hpbGUgTlAgbm90ZXMgdGhlIGNhc2Ugb2Ygbm9kZSBwcm90ZWN0aW9uLg0K VG9wb2xvZ2llcyBtYXJrZWQgd2l0aCBhbiBhc3RlcmlzaygqKSBkaWQgbm90IGhhdmUgaW5mZXJy ZWQgcmVhbCBsaW5rIGNvc3RzIGZyb20gdGhlIGRhdGFzZXRzLCBzbyB0aGVpciBjb3N0cyB3ZXJl IGluaXRpYWxseSBzZXQgdG8gMSAodW5pdCBjb3N0cykuDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZXNl IHJlc3VsdHMgY29tcHV0ZWQgb24gcmVhbC13b3JsZCBuZXR3b3JrcyBjb3VsZCBzaWduaWZpY2Fu dGx5IGltcHJvdmUgdGhlIHJsZmEgZHJhZnQsIGVzcGVjaWFsbHkgU2VjLiA5LjMuLCBhbmQgdGhl IGFkdmFudGFnZXMgb2YgcmVtb3RlIExGQSBvdmVyIHNpbXBsZSBMRkEgd291bGQgYmUgbW9yZSBl bXBoYXNpemVkLg0KDQoNCis9PT09PT09PT09PT09PSs9PT09Kz09PT0rPT09PT09PT09PSs9PT09 PT09PT09PSs9PT09PT09PT09PT0rPT09PT09PT09PT09Kw0KfCBUb3BvbG9neSAgICAgfCBuICB8 IG0gIHwgTEZBX0xQICAgfCBMRkFfTlAgICAgfCAgckxGQV9MUCAgIHwgIHJMRkFfTlAgICB8DQor PT09PT09PT09PT09PT0rPT09PSs9PT09Kz09PT09PT09PT0rPT09PT09PT09PT0rPT09PT09PT09 PT09Kz09PT09PT09PT09PSsNCnwgQVMxMjIxICAgICAgIHwgNyAgfCA5ICB8IDAuODA5ICAgIHwg ICAwLjI1ICAgIHwgICAwLjgwOSAgICB8ICAgIDAuMjUgICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0t LS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r DQp8IEFTMTIzOSAgICAgICB8IDMwIHwgNjkgfCAwLjg3MzUgICB8ICAwLjc1NTQgICB8ICAgICAx ICAgICAgfCAgIDAuOTc5NSAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0t LSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBBUzE3NTUgICAgICAg fCAxOCB8IDMzIHwgMC44NzI1ICAgfCAgMC43NzQxICAgfCAgIDAuOTk2NyAgIHwgICAwLjk5NTkg ICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgQVMzMjU3ICAgICAgIHwgMjcgfCA2NCB8IDAuOTIz ICAgIHwgIDAuNzE4NiAgIHwgICAwLjk5ICAgICB8ICAgMC44NDcyICAgfA0KKy0tLS0tLS0tLS0t LS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0rDQp8IEFTMzk2NyAgICAgICB8IDIxIHwgMzYgfCAwLjc4NTcgICB8ICAwLjY0NjAgICB8 ICAgICAxICAgICAgfCAgIDAuOTMyNSAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBBUzY0NjEg ICAgICAgfCAxNyB8IDM3IHwgMC45MzM4ICAgfCAgMC42OTMzICAgfCAgIDAuOTk2MyAgIHwgICAw LjcwNzUgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgQWJpbGVuZSogICAgIHwgMTIgfCAxNSB8 IDAuNTYwNiAgIHwgIDAuNjA3OCAgIHwgICAwLjkwOTAgICB8ICAgMC44NzI1ICAgfA0KKy0tLS0t LS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rDQp8IEFybmVzKiAgICAgICB8IDQxIHwgNTcgfCAwLjYyMjUgICB8ICAwLjM1 MTggICB8ICAgMC43NDg3ICAgfCAgIDAuNDU2MiAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0t LS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBB VCZUICAgICAgICAgfCAyMiB8IDM4IHwgMC44MjI1ICAgfCAgMC41NjQ3ICAgfCAgICAgMSAgICAg IHwgICAwLjg0OTcgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgRGVsdGFjb20gICAgIHwgMTEz fCAxNjF8IDAuNTc3MSAgIHwgIDAuNDkxMCAgIHwgICAwLjg1MzkgICB8ICAgMC44MTQ4ICAgfA0K Ky0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0rDQp8IEdhbWJpYSAgICAgICB8IDI4IHwgMjggfCAwLjAzNyAgICB8 ICAgMC4wNCAgICB8ICAgMC4xODUxICAgfCAgICAgMC4xMiAgIHwNCistLS0tLS0tLS0tLS0tLSst LS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t Kw0KfCBHZWFudCAgICAgICAgfCAzNyB8IDU1IHwgMC42OTA2ICAgfCAgMC4zOTc3ICAgfCAgIDAu ODMwMyAgIHwgICAwLjY1ODIgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0t LS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgR2VybV81MCAgICAg IHwgNTAgfCA4OCB8IDAuOTAwNCAgIHwgIDAuODM4MSAgIHwgICAgIDEgICAgICB8ICAgMC45OTk1 ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IEdlcm1hbnkqICAgICB8IDI3IHwgMzIgfCAwLjY5 NDggICB8ICAwLjU5OSAgICB8ICAgICAxICAgICAgfCAgIDAuOTU0OSAgIHwNCistLS0tLS0tLS0t LS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tKw0KfCBJbnRlcm5ldE1DSSAgfCAxOSB8IDMzIHwgMC45MDM1ICAgfCAgMC42Nzk4ICAg fCAgIDAuOTQxNSAgIHwgICAwLjkxMzYgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgSXRhbHkq ICAgICAgIHwgMzMgfCA1NiB8IDAuNzg0ICAgIHwgIDAuNTc0MSAgIHwgICAgIDEgICAgICB8ICAg MC45MjY5ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IE5TRiogICAgICAgICB8IDI2IHwgNDMg fCAwLjg2ICAgICB8ICAwLjYzNDcgICB8ICAgICAxICAgICAgfCAgICAgMSAgICAgIHwNCistLS0t LS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tKw0KDQoNCkZ1cnRoZXJtb3JlLCBhZnRlciByZWFkaW5nIHRoZSBkcmFmdCBh Z2Fpbi1hbmQtYWdhaW4sIEkgaGF2ZSBmb3VuZCB0aGF0IGl0IHNob3VsZCBiZSBtb3JlIGVtcGhh c2l6ZWQgaW4gdGhlIGRyYWZ0IHRoYXQgY2FsY3VsYXRpbmcgb3Igc2Vla2luZyBmb3IgYSByZW1v dGUgTEZBIHN0YWdpbmcgcG9pbnQgc2hvdWxkIGJlIGRvbmUgSUYgQU5EIE9OTFkgSUYgbm8gc2lt cGxlIExGQSB3ZXJlIGZvdW5kLiBUaGlzIGlzIGltcG9ydGFudCwgc2luY2Ugbm9ybWFsbHkgcGVv cGxlIG9idmlvdXNseSB0aGluayBhbmQgb2JzZXJ2ZSB0aGF0IHRoZSBmYWlsdXJlIGNvdmVyYWdl IG9mIHJlbW90ZSBMRkEgc2hvdWxkIGJlIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byB0aGUgY292 ZXJhZ2Ugb2J0YWluZWQgYnkgc2ltcGxlIExGQS4gTW9yZW92ZXIsIHBlb3BsZSBhbHNvIHRoaW5r IHRoYXQgTEZBcyBwcm9kdWNlIGEgc3Vic2V0IG9mIHJlbW90ZSBMRkFzLiBIb3dldmVyLCBpZiBh ZnRlciBhIGZhaWx1cmUgb25seSBQLXNwYWNlcyBhbmQgUS1zcGFjZXMgYXJlIHRha2VuIGludG8g YWNjb3VudCBpbiBvcmRlciB0byBzZWVrIGEgKHJlbW90ZSkgbG9vcC1mcmVlIGFsdGVybmF0ZSwg dGhlbiBpdCBpcyBwb3NzaWJsZSB0aGF0IGEgc2ltcGxlIExGQSB3b3VsZCBub3QgYmUgZm91bmQg cmVzdWx0aW5nIHVucHJvdGVjdGVkIG5vZGUtcGFpcnMuIEJ1dCwgdGhpcyBjYXNlIGNvdWxkIG9u bHkgaGFwcGVuIHdoZW4gbGluayBjb3N0cyBhcmUgbm90IHVuaXQgY29zdHMuIEZvciBhbiBlYXNp ZXIgdW5kZXJzdGFuZGluZywgY29uc2lkZXIgdGhlIG5ldHdvcmsgZGVwaWN0ZWQgYmVsb3c6DQog ICAgICAgICAgICAxICAgICAgICAgICAgICAxDQogICAgICAgICAgRi0tLS0tLS0tUy0tLS0tLS0t LS0tWC0tLS0tLS0tRQ0KICAgICAgICAgICBcICAgICAgLyAgICAgICAgICAgICAgICAgICAgICBc DQogICAgICAgICAxMCBcICAgIC8gNCAgICAgICAgICAgICAgICAgICAgICBcICAxDQogICAgICAg ICAgICAgXCAgLyAgICAgICAgMSAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICBOIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUMNCiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgICAgIDEgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgMQ0KICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgfCAgICAgIDEgICAgICAgICAgICAgMSAgICAgICB8DQogICAgICAgICAgICAg IEEtLS0tLS0tLS0tLS0tLUItLS0tLS0tLS0tLS0tRA0KDQpBc3N1bWUgdGhhdCBTIHdpc2hlcyB0 byBzZW5kIGEgcGFja2V0IHRvIEQsIGFuZCB0aGUgc2hvcnRlc3QgcGF0aCBnb2VzIHRocm91Z2gg RSwgdGhlcmVmb3JlIGl0IGlzIFMtRS1DLUQuIFN1cHBvc2UgdGhhdCB0aGUgbGluayAocyxlKQ0K ZmFpbHMsIG9yIGV2ZW4gdGhlIG5vZGUgZSBpdHNlbGYgZmFpbHMuIEluIHRoaXMgY2FzZSwgc2lu Y2UgTEZBIChhbmQgaXRzIGNhbGN1bGF0aW9uKSBvbmx5IGNvbnNpZGVyIGFsbCBvdGhlciBuZWln aGJvcnMgb2YgcywgdGhlbiBub2RlIE4gd291bGQgYmUgYW4gZWFzeSBMRkEgZm9yIHRoaXMgZmFp bHVyZSwgc2luY2UgZGlzdChOLEQpIDwgZGlzdChOLFMpK2Rpc3QoUyxEKS4NCkhvd2V2ZXIsIGlm IHdlIG9ubHkgc2VlayBwb3NzaWJsZSByZW1vdGUgTEZBcywgdGhhbiBhY2NvcmRpbmcgdG8gdGhl IChyKVNQRiBjYWxjdWxhdGlvbnMsIG9yIHRha2luZyBpbnRvIGFjY291bnQgb3VyIGRpc3RhbmNl LWZ1bmN0aW9uIGNvbmRpdGlvbnMgd2lsbCByZXN1bHQgdGhhdCBEJ3MgUS1zcGFjZSB3aWxsIGNv bnRhaW4gbm9kZSBOIChiZXNpZGVzIHNvbWUgb3RoZXIgbm9kZXMpLCBidXQgUydzIFAtc3BhY2Ug d29uJ3QgKGl0IHdpbGwgb25seSBjb250YWluIG5vZGUgRiBhbmQgd2hhdCBpcyBtb3JlLCBpZiBu b2RlIEYgZG9lcyBub3QgZXhpc3QsIHRoZW4gUydzIFAtc3BhY2Ugd291bGQgYmUgZW1wdHkpLCB0 aGVyZWZvcmUgbm8gaW50ZXJzZWN0aW9uIG9mIHRoZSB0d28gc3BhY2VzIHdpbGwgZXhpc3QsIGxl YXZpbmcgdGhpcyBuZXR3b3JrIHZ1bG5lcmFibGUgdG8gdGhlIGZhaWx1cmUgb2YgbGluayAocyxl KS4NCg0KVGhpcyByZXN1bHRzIHRoYXQgYSBuZWlnaGJvciBzaG91bGQgYmUgYWx3YXlzIHJlYWNo ZWQgYnkgdGhlIG5laWdoYm9yaW5nIGxpbmssIGV2ZW4gaWYgdGhlcmUgZXhpc3RzIGEgc2hvcnRl ciwgYnV0IGRlZmluaXRlbHkgYmlnZ2VyIGluIGhvcC1jb3VudCBwYXRoIHRvIGl0Lg0KQWNjb3Jk aW5nIHRvIHRoaXMgY2FzZSAod2hlbiBzZWVraW5nIHNpbXBsZSBMRkEgaXMgbWlzc2VkKSwgdGhl IGNvbmRpdGlvbiBvZiBleHRlbmRlZCBQLXNwYWNlIGRlc2NyaWJlZCBieSBvdXIgZGlzdGFuY2Ug ZnVuY3Rpb25zLCBzaG91bGQgYmUgbW9kaWZpZWQgYSBiaXQ6DQpGb3Igc291cmNlIHMsIGRlc3Rp bmF0aW9uIGQsIGFuZCBuZXh0LWhvcCBlLCBzb21lIG5vZGUgbiAhPSBzLGQgaXMgYW4gZXh0ZW5k ZWQgbGluay1wcm90ZWN0aW5nIHJlbW90ZSBMRkEgZm9yIHRoZSBzLWQgcGFpciBpZiBhbmQgb25s eSBpZg0K4oiDdiDiiIggbmVpZ2gocykgOiBkaXN0KHYsIG4pIDwgZGlzdCh2LCBzKSArIGRpc3Qo cywgZSkgKyBkaXN0KGUsIG4pICAmJiBkaXN0KHMsdikgPCBkaXN0KHMsZSkgKyBkaXN0KGUsdikN CmRpc3QobiwgZCkgPCBkaXN0KG4sIHMpICsgZGlzdChzLCBkKSAuDQoNCk9uZSBjYW4gZWFzaWx5 IG9ic2VydmUgdGhhdCBlbXBoYXNpemluZyBtb3JlIHRoYXQgcmVtb3RlIExGQSBzZWVraW5nIHBy b2Nlc3MgaXMgb25seSAiZXhlY3V0ZWQiIGFmdGVyIG5vIHNpbXBsZSBMRkEgaXMgZm91bmQgY291 bGQgbXVjaCBtb3JlIGVhc2UgdGhlIHVuZGVyc3RhbmRpbmcgYW5kIHdvbid0IHJlc3VsdCBhIGhl YWRhY2hlIHRvIHRoZSByZWFkZXIgd2hvIGFjY2lkZW50YWxseSB3YW50cyB0byBjYWxjdWxhdGUg ckxGQSBjb3ZlcmFnZSBpbiBzdWNoIG5ldHdvcmsuDQoNClBsZWFzZSBsZXQgbWUga25vdywgaWYg bXkgaW50ZXJwcmV0YXRpb24gaXMgbm90IGNvcnJlY3QuDQpUaGFua3MuDQoNCkJlc3QsDQpMZXZl bnRlDQoNCg0KDQo= --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5E5ESESSMB307erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk5pY2UuIEhvd2V2ZXIsIEnigJltIGEgYml0IGNvbmZ1c2VkLCBiZWNhdXNlIHRv cG9sb2dpZXMgd2l0aCB1bmlmb3JtIGxpbmsgY29zdHMgc2hvdWxkIGhhdmUgMTAwJSBsaW5rIGZh aWx1cmUgY292ZXJhZ2UgKGlmIHRoZXkgYXJlIDItY29ubmVjdGVkKSwgc2hvdWxkbuKAmXQgdGhl eT8NCiBJc27igJl0IEFiaWxlbmUgYW5kIEFybmVzIDItY29ubmVjdGVkPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3Ro ZXI6IGRpZCB5b3Ugbm90aWNlZCB0aGF0IHdpdGggc29tZSBtaW5pbWFsIGV4dHJhIGNvbXB1dGF0 aW9uLCBpdCBpcyBwb3NzaWJsZSB0byByZWFjaCAxMDAlIG5vZGUgcHJvdGVjdGlvbiB3aXRoIHJM RkEsIGlmIHdlIHN1cHBvc2UgdGhhdCBhbGwgdGhlIG5vZGVzIGRvDQogckxGQSBpbiB0aGUgbmV0 d29yay4gTWF5YmUgd2UgY291bGQgYXNzaWduIGEgc2luZ2xlIGV4dHJhIGxhYmVsL0lQIGFkZHJl c3MgdG8gc2F5IHRoYXQg4oCcdXNlIHVuaWZvcm0gbGluayBjb3N0cyBmb3IgdGhpcyBwYWNrZXTi gJ0sIGFuZCBnZXQgc29tZXRoaW5nIHF1aXRlIHNpbWlsYXIgdG8gTVJUPyA6KTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ R2Fib3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij4gTGV2ZW50ZSBDc2lrb3IgW21haWx0bzpjc2lrb3JAdG1pdC5ibWUuaHVdDQo8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMDIsIDIwMTMgMTA6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+ IEfDoWJvciBTw6FuZG9yIEVueWVkaTxicj4NCjxiPkNjOjwvYj4gc3RicnlhbnRAY2lzY28uY29t OyBkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmFAdG9vbHMuaWV0Zi5vcmc7IHJ0Z3dnLWNoYWly c0B0b29scy5pZXRmLm9yZzsgcnRnd2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IGRyYWZ0LWlldGYtcnRnd2ctcmVtb3RlLWxmYSAtIHJlYWR5IGZvciBXR0xDPyAtIHNvbWUgY29t bWVudHMgYW5kIHF1ZXN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPlRoZXNlIGFyZSBiaWRpcmVjdGlvbmFsIHJlc3VsdHMuPGJyPg0KPGJyPg0K TGV2ZW50ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiAwOC8wMi8yMDEzIDA5OjU5IEFNLCBHw6Fib3IgU8OhbmRvciBFbnllZGkgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFyZSB0aGVzZSB0aGUgc2luZ2xlIG9yIHRo ZSBiaWRpcmVjdGlvbmFsIGNvdmVyYWdlIHJlc3VsdHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HYWJvcjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KPGEgaHJlZj0i bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmciPnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFs8YSBocmVmPSJtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Z3dnLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5MZXZlbnRlIENzaWtvcjxi cj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEF1Z3VzdCAwMiwgMjAxMyA4OjI1IEFNPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86c3RicnlhbnRAY2lzY28uY29tIj5zdGJyeWFudEBjaXNj by5jb208L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3 Zy1yZW1vdGUtbGZhQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmFA dG9vbHMuaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWNoYWlyc0B0b29scy5p ZXRmLm9yZyI+cnRnd2ctY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRv OnJ0Z3dnQGlldGYub3JnIj4NCnJ0Z3dnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhIC0gcmVhZHkgZm9yIFdHTEM/IC0gc29t ZSBjb21tZW50cyBhbmQgcXVlc3Rpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5EZWFyIEFsbCw8YnI+ DQpJJ20gc2VuZGluZyBteSBwcmV2aW91cyBtYWlsIGFnYWluIHNpbmNlIHRoZSBmb250IGZvciB0 aGUgQVNDSUkgYXJ0IG5ldHdvcmsgd2FzIG5vdCBmaXhlZCBhbmQgbWF5IG5vdCBhcHBlYXIgaW4g YSByaWdodCBmb3JtYXQgYXQgZXZlcnlvbmUuPGJyPg0KPGJyPg0KSWYgaXQgc3RpbGwgbWVzc3ks IGxldCBtZSBrbm93Ljxicj4NCjxicj4NClNvcnJ5LDxicj4NCkxldmVudGU8YnI+DQo8YnI+DQo8 YnI+DQpEZWFyIEFsbCw8YnI+DQpzaW5jZSBvdXIgcHJldmlvdXMgd29ya3MgaW4gcmVtb3RlIExG QSBhbmFseXNpcyAocGFwZXJzIGFscmVhZHkgc2VudCB0byB0aGVzZSBtYWlsaW5nIGxpc3RzKSBh c3N1bWVkIHVuaXQgY29zdCBuZXR3b3JrcywgdGhlcmVmb3JlIGFzIEkgcHJvbWlzZWQsIEkgY2Fs Y3VsYXRlZCB0aGUgY29ycmVzcG9uZGluZyBMRkEgYW5kIHJMRkEgY292ZXJhZ2VzIGluIHRob3Nl IG5ldHdvcmtzIHdpdGggdGhlaXIgb3JpZ2luYWwgbGluayBjb3N0cy48YnI+DQpUaGVzZSBuZXR3 b3JrcyB3ZXJlIGluZmVycmVkIGZyb20gUm9ja2V0ZnVlbCBkYXRhc2V0ICg8aT5NYWhhamFuLCBS LiwgU3ByaW5nLCBOLiwgV2V0aGVyYWxsLCBELiwgQW5kZXJzb24sIFQuOjxicj4NCkluZmVycmlu ZyBsaW5rIHdlaWdodHMgdXNpbmcgZW5kLXRvLWVuZCBtZWFzdXJlbWVudHMuIEluOiBBQ00gSU1D LCBwcC4gMjMx4oCTMjM2ICgyMDAyKTwvaT4pLCBTTkRMaWIgKDxhIGhyZWY9Imh0dHA6Ly9zbmRs aWIuemliLmRlIj5odHRwOi8vc25kbGliLnppYi5kZTwvYT4pLCBhbmQgVG9wb2xvZ3lab28oPGEg aHJlZj0iaHR0cDovL3d3dy50b3BvbG9neS16b28ub3JnIj5odHRwOi8vd3d3LnRvcG9sb2d5LXpv by5vcmc8L2E+KS4gVGhlIGZvdW5kIGNvdmVyYWdlcw0KIGFuZCBzb21lIGRldGFpbHMgYXJlIGZv dW5kIGluIHRoZSB0YWJsZSBiZWxvdywgd2hlcmUgPGk+bjwvaT4gYW5kIDxpPm08L2k+IGRlbm90 ZSB0aGUgbnVtYmVyIG9mIG5vZGVzIGFuZCB0aGUgbnVtYmVyIG9mIGxpbmtzLCByZXNwZWN0aXZl bHkuIFRoZSBvdGhlciBjb2x1bW5zIG1hcmsgdGhlIGRpZmZlcmVudCBjb3ZlcmFnZXMgb2JydGFp bmVkIGJ5IHNpbXBsZSBMRkEgYW5kIHJlbW90ZSBMRkEsIHdoZXJlIExQIGluZGljYXRlcyB0aGUg bGluay1wcm90ZWN0aW5nDQogY2FzZSwgd2hpbGUgTlAgbm90ZXMgdGhlIGNhc2Ugb2Ygbm9kZSBw cm90ZWN0aW9uLjxicj4NClRvcG9sb2dpZXMgbWFya2VkIHdpdGggYW4gYXN0ZXJpc2soKikgZGlk IG5vdCBoYXZlIGluZmVycmVkIHJlYWwgbGluayBjb3N0cyBmcm9tIHRoZSBkYXRhc2V0cywgc28g dGhlaXIgY29zdHMgd2VyZSBpbml0aWFsbHkgc2V0IHRvIDEgKHVuaXQgY29zdHMpLjxicj4NCjxi cj4NCkkgYmVsaWV2ZSB0aGF0IHRoZXNlIHJlc3VsdHMgY29tcHV0ZWQgb24gcmVhbC13b3JsZCBu ZXR3b3JrcyBjb3VsZCBzaWduaWZpY2FudGx5IGltcHJvdmUgdGhlIHJsZmEgZHJhZnQsIGVzcGVj aWFsbHkgU2VjLiA5LjMuLCBhbmQgdGhlIGFkdmFudGFnZXMgb2YgcmVtb3RlIExGQSBvdmVyIHNp bXBsZSBMRkEgd291bGQgYmUgbW9yZSBlbXBoYXNpemVkLjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+JiM0Mzs9PT09PT09PT09PT09PSYjNDM7PT09PSYj NDM7PT09PSYjNDM7PT09PT09PT09PSYjNDM7PT09PT09PT09PT0mIzQzOz09PT09PT09PT09PSYj NDM7PT09PT09PT09PT09JiM0Mzs8L3R0Pjxicj4NCjx0dD58IFRvcG9sb2d5Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgbiZuYnNwOyB8IG0mbmJzcDsgfCBMRkFfTFAmbmJzcDsmbmJzcDsgfCBM RkFfTlAmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyByTEZBX0xQJm5ic3A7Jm5ic3A7IHwmbmJz cDsgckxGQV9OUCZuYnNwOyZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0Mzs9PT09PT09PT09PT09 PSYjNDM7PT09PSYjNDM7PT09PSYjNDM7PT09PT09PT09PSYjNDM7PT09PT09PT09PT0mIzQzOz09 PT09PT09PT09PSYjNDM7PT09PT09PT09PT09JiM0Mzs8L3R0Pjxicj4NCjx0dD58IEFTMTIyMSZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCA3Jm5ic3A7IHwgOSZuYnNwOyB8IDAuODA5 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC4yNSZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7IDAuODA5Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMjUm bmJzcDsmbmJzcDsmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQz Oy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0t LS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBBUzEyMzkgJm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDMwIHwgNjkgfCAwLjg3MzUmbmJzcDsmbmJzcDsgfCZuYnNw OyAwLjc1NTQmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxICZuYnNwOyZu YnNwOyAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk3OTUmbmJzcDsmbmJzcDsgfDwvdHQ+PGJyPg0K PHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0m IzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90 dD48YnI+DQo8dHQ+fCBBUzE3NTUgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDE4IHwgMzMg fCAwLjg3MjUgJm5ic3A7IHwmbmJzcDsgMC43NzQxJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsg MC45OTY3ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTk1OSAmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0 PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90dD48 YnI+DQo8dHQ+fCBBUzMyNTcgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDI3IHwgNjQgfCAw LjkyMyZuYnNwOyAmbmJzcDsgfCZuYnNwOyAwLjcxODYmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyAwLjk5ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjg0NzIgJm5ic3A7IHw8L3R0Pjxi cj4NCjx0dD4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0tLS0t LS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQz OzwvdHQ+PGJyPg0KPHR0PnwgQVMzOTY3ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCAyMSB8 IDM2IHwgMC43ODU3ICZuYnNwOyB8Jm5ic3A7IDAuNjQ2MCAmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAxICZuYnNwOyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjkzMjUmbmJz cDsmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQz Oy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBBUzY0NjEgJm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyB8IDE3IHwgMzcgfCAwLjkzMzgmbmJzcDsmbmJzcDsgfCZuYnNwOyAwLjY5MzMg Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC45OTYzICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuNzA3NSAm bmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0t LS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0t LS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBBYmlsZW5lKiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IDEyIHwgMTUgfCAwLjU2MDYmbmJzcDsmbmJzcDsgfCZuYnNwOyAwLjYwNzggJm5i c3A7IHwmbmJzcDsmbmJzcDsgMC45MDkwICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODcyNSAmbmJz cDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0m IzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBBcm5lcyombmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwOyB8IDQxIHwgNTcgfCAwLjYyMjUgJm5ic3A7IHwmbmJzcDsgMC4zNTE4ICZuYnNwOyB8Jm5i c3A7Jm5ic3A7IDAuNzQ4NyAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjQ1NjIgJm5ic3A7IHw8L3R0 Pjxicj4NCjx0dD4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0t LS0tLS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0m IzQzOzwvdHQ+PGJyPg0KPHR0PnwgQVQmYW1wO1QgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsgfCAyMiB8IDM4IHwgMC44MjI1ICZuYnNwOyB8Jm5ic3A7IDAuNTY0NyAmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxICZuYnNwOyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyAwLjg0OTcgJm5ic3A7IHw8L3R0Pjxicj4NCjx0dD4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0Mzst LS0tJiM0MzstLS0tJiM0MzstLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0t LS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvdHQ+PGJyPg0KPHR0PnwgRGVsdGFjb20mbmJzcDsg Jm5ic3A7Jm5ic3A7IHwgMTEzfCAxNjF8IDAuNTc3MSAmbmJzcDsgfCZuYnNwOyAwLjQ5MTAgJm5i c3A7IHwmbmJzcDsmbmJzcDsgMC44NTM5ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODE0OCAmbmJz cDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0m IzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBHYW1iaWEgJm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyB8IDI4IHwgMjggfCAwLjAzNyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjA0ICZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuMTg1MSAmbmJzcDsgfCZuYnNwOyZuYnNwOyAmbmJz cDsgMC4xMiAmbmJzcDsgfDwvdHQ+PGJyPg0KPHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0t LS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90dD48YnI+DQo8dHQ+fCBHZWFudCZuYnNwOyAmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgMzcgfCA1NSB8IDAuNjkwNiZuYnNwOyZuYnNwOyB8Jm5i c3A7IDAuMzk3NyAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjgzMDMgJm5ic3A7IHwmbmJzcDsmbmJz cDsgMC42NTgyICZuYnNwOyB8PC90dD48YnI+DQo8dHQ+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7 LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0t LS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3R0Pjxicj4NCjx0dD58IEdlcm1fNTAmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7IHwgNTAgfCA4OCB8IDAuOTAwNCZuYnNwOyZuYnNwOyB8Jm5ic3A7 IDAuODM4MSAmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxICZuYnNwOyAmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk5OTUgJm5ic3A7IHw8L3R0Pjxicj4NCjx0dD4mIzQzOy0t LS0tLS0tLS0tLS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0tLS0tLS0tJiM0MzstLS0tLS0t LS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvdHQ+PGJyPg0KPHR0 PnwgR2VybWFueSombmJzcDsgJm5ic3A7Jm5ic3A7IHwgMjcgfCAzMiB8IDAuNjk0OCAmbmJzcDsg fCZuYnNwOyAwLjU5OSZuYnNwOyAmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxICZu YnNwOyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk1NDkgJm5ic3A7IHw8L3R0Pjxicj4N Cjx0dD4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0tLS0tLS0t JiM0MzstLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwv dHQ+PGJyPg0KPHR0PnwgSW50ZXJuZXRNQ0kmbmJzcDsgfCAxOSB8IDMzIHwgMC45MDM1ICZuYnNw OyB8Jm5ic3A7IDAuNjc5OCAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk0MTUmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyAwLjkxMzYgJm5ic3A7IHw8L3R0Pjxicj4NCjx0dD4mIzQzOy0tLS0tLS0t LS0tLS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYj NDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvdHQ+PGJyPg0KPHR0PnwgSXRh bHkqICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgfCAzMyB8IDU2IHwgMC43ODQmbmJzcDsgJm5i c3A7IHwmbmJzcDsgMC41NzQxICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5i c3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTI2OSAmbmJzcDsgfDwvdHQ+PGJyPg0K PHR0PiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0m IzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC90 dD48YnI+DQo8dHQ+fCBOU0YqICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgMjYg fCA0MyB8IDAuODYgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7IDAuNjM0NyAmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAxICZuYnNwOyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmbmJz cDsgMSAmbmJzcDsgJm5ic3A7Jm5ic3A7IHw8L3R0Pjxicj4NCjx0dD4mIzQzOy0tLS0tLS0tLS0t LS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvdHQ+PC9zcGFuPjxicj4NCjxicj4N Cjxicj4NCkZ1cnRoZXJtb3JlLCBhZnRlciByZWFkaW5nIHRoZSBkcmFmdCBhZ2Fpbi1hbmQtYWdh aW4sIEkgaGF2ZSBmb3VuZCB0aGF0IGl0IHNob3VsZCBiZSBtb3JlIGVtcGhhc2l6ZWQgaW4gdGhl IGRyYWZ0IHRoYXQgY2FsY3VsYXRpbmcgb3Igc2Vla2luZyBmb3IgYSByZW1vdGUgTEZBIHN0YWdp bmcgcG9pbnQgc2hvdWxkIGJlIGRvbmUgSUYgQU5EIE9OTFkgSUYgbm8gc2ltcGxlIExGQSB3ZXJl IGZvdW5kLiBUaGlzIGlzIGltcG9ydGFudCwgc2luY2Ugbm9ybWFsbHkNCiBwZW9wbGUgb2J2aW91 c2x5IHRoaW5rIGFuZCBvYnNlcnZlIHRoYXQgdGhlIGZhaWx1cmUgY292ZXJhZ2Ugb2YgcmVtb3Rl IExGQSBzaG91bGQgYmUgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIHRoZSBjb3ZlcmFnZSBvYnRh aW5lZCBieSBzaW1wbGUgTEZBLiBNb3Jlb3ZlciwgcGVvcGxlIGFsc28gdGhpbmsgdGhhdCBMRkFz IHByb2R1Y2UgYSBzdWJzZXQgb2YgcmVtb3RlIExGQXMuIEhvd2V2ZXIsIGlmIGFmdGVyIGEgZmFp bHVyZSBvbmx5IFAtc3BhY2VzDQogYW5kIFEtc3BhY2VzIGFyZSB0YWtlbiBpbnRvIGFjY291bnQg aW4gb3JkZXIgdG8gc2VlayBhIChyZW1vdGUpIGxvb3AtZnJlZSBhbHRlcm5hdGUsIHRoZW4gaXQg aXMgcG9zc2libGUgdGhhdCBhIHNpbXBsZSBMRkEgd291bGQgbm90IGJlIGZvdW5kIHJlc3VsdGlu ZyB1bnByb3RlY3RlZCBub2RlLXBhaXJzLiBCdXQsIHRoaXMgY2FzZSBjb3VsZCBvbmx5IGhhcHBl biB3aGVuIGxpbmsgY29zdHMgYXJlIG5vdCB1bml0IGNvc3RzLiBGb3IgYW4gZWFzaWVyDQogdW5k ZXJzdGFuZGluZywgY29uc2lkZXIgdGhlIG5ldHdvcmsgZGVwaWN0ZWQgYmVsb3c6PGJyPg0KPHR0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IDE8L3NwYW4+PC90dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRi0tLS0tLS0tUy0tLS0tLS0tLS0tWC0tLS0tLS0t RTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBcPC90dD48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMCBcJm5ic3A7Jm5i c3A7Jm5ic3A7IC8gNCZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 IFwmbmJzcDsgMTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbmJzcDsgJm5ic3A7IFwmbmJzcDsgLyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgMSAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgXDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyAmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLUM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IHwgPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsg fCZuYnNwOyAxPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHw8L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgMSZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyB8PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQS0tLS0tLS0tLS0t LS0tQi0tLS0tLS0tLS0tLS1EPC90dD48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGJy Pg0KQXNzdW1lIHRoYXQgUyB3aXNoZXMgdG8gc2VuZCBhIHBhY2tldCB0byBELCBhbmQgdGhlIHNo b3J0ZXN0IHBhdGggZ29lcyB0aHJvdWdoIEUsIHRoZXJlZm9yZSBpdCBpcyBTLUUtQy1ELiBTdXBw b3NlIHRoYXQgdGhlIGxpbmsgKHMsZSk8YnI+DQpmYWlscywgb3IgZXZlbiB0aGUgbm9kZSBlIGl0 c2VsZiBmYWlscy4gSW4gdGhpcyBjYXNlLCBzaW5jZSBMRkEgKGFuZCBpdHMgY2FsY3VsYXRpb24p IG9ubHkgY29uc2lkZXIgYWxsIG90aGVyIG5laWdoYm9ycyBvZiBzLCB0aGVuIG5vZGUgTiB3b3Vs ZCBiZSBhbiBlYXN5IExGQSBmb3IgdGhpcyBmYWlsdXJlLCBzaW5jZSBkaXN0KE4sRCkgJmx0OyBk aXN0KE4sUykmIzQzO2Rpc3QoUyxEKS48YnI+DQpIb3dldmVyLCBpZiB3ZSBvbmx5IHNlZWsgcG9z c2libGUgcmVtb3RlIExGQXMsIHRoYW4gYWNjb3JkaW5nIHRvIHRoZSAocilTUEYgY2FsY3VsYXRp b25zLCBvciB0YWtpbmcgaW50byBhY2NvdW50IG91ciBkaXN0YW5jZS1mdW5jdGlvbiBjb25kaXRp b25zIHdpbGwgcmVzdWx0IHRoYXQgRCdzIFEtc3BhY2Ugd2lsbCBjb250YWluIG5vZGUgTiAoYmVz aWRlcyBzb21lIG90aGVyIG5vZGVzKSwgYnV0IFMncyBQLXNwYWNlIHdvbid0IChpdCB3aWxsIG9u bHkNCiBjb250YWluIG5vZGUgRiBhbmQgd2hhdCBpcyBtb3JlLCBpZiBub2RlIEYgZG9lcyBub3Qg ZXhpc3QsIHRoZW4gUydzIFAtc3BhY2Ugd291bGQgYmUgZW1wdHkpLCB0aGVyZWZvcmUgbm8gaW50 ZXJzZWN0aW9uIG9mIHRoZSB0d28gc3BhY2VzIHdpbGwgZXhpc3QsIGxlYXZpbmcgdGhpcyBuZXR3 b3JrIHZ1bG5lcmFibGUgdG8gdGhlIGZhaWx1cmUgb2YgbGluayAocyxlKS48YnI+DQo8YnI+DQpU aGlzIHJlc3VsdHMgdGhhdCBhIG5laWdoYm9yIHNob3VsZCBiZSBhbHdheXMgcmVhY2hlZCBieSB0 aGUgbmVpZ2hib3JpbmcgbGluaywgZXZlbiBpZiB0aGVyZSBleGlzdHMgYSBzaG9ydGVyLCBidXQg ZGVmaW5pdGVseSBiaWdnZXIgaW4gaG9wLWNvdW50IHBhdGggdG8gaXQuPGJyPg0KQWNjb3JkaW5n IHRvIHRoaXMgY2FzZSAod2hlbiBzZWVraW5nIHNpbXBsZSBMRkEgaXMgbWlzc2VkKSwgdGhlIGNv bmRpdGlvbiBvZiBleHRlbmRlZCBQLXNwYWNlIGRlc2NyaWJlZCBieSBvdXIgZGlzdGFuY2UgZnVu Y3Rpb25zLCBzaG91bGQgYmUgbW9kaWZpZWQgYSBiaXQ6PGJyPg0KRm9yIHNvdXJjZSA8aT5zPC9p PiwgZGVzdGluYXRpb24gPGk+ZDwvaT4sIGFuZCBuZXh0LWhvcCA8aT5lPC9pPiwgc29tZSBub2Rl IDxpPm4gIT0gcyxkPC9pPiBpcyBhbiBleHRlbmRlZCBsaW5rLXByb3RlY3RpbmcgcmVtb3RlIExG QSBmb3IgdGhlDQo8aT5zLWQ8L2k+IHBhaXIgaWYgYW5kIG9ubHkgaWY8YnI+DQo8aT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSBNYXRoJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij7iiIM8L3NwYW4+diA8L2k+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oiIPC9zcGFuPiBuZWlnaChzKSA6 IGRpc3QodiwgbikgJmx0OyBkaXN0KHYsIHMpICYjNDM7IGRpc3QocywgZSkgJiM0MzsgZGlzdChl LCBuKSZuYnNwOw0KPGI+JmFtcDsmYW1wOyBkaXN0KHMsdikgJmx0OyBkaXN0KHMsZSkgJiM0Mzsg ZGlzdChlLHYpPC9iPjwvaT48YnI+DQo8aT5kaXN0KG4sIGQpICZsdDsgZGlzdChuLCBzKSAmIzQz OyBkaXN0KHMsIGQpIC4gPC9pPjxicj4NCjxicj4NCk9uZSBjYW4gZWFzaWx5IG9ic2VydmUgdGhh dCBlbXBoYXNpemluZyBtb3JlIHRoYXQgcmVtb3RlIExGQSBzZWVraW5nIHByb2Nlc3MgaXMgb25s eSAmcXVvdDtleGVjdXRlZCZxdW90OyBhZnRlciBubyBzaW1wbGUgTEZBIGlzIGZvdW5kIGNvdWxk IG11Y2ggbW9yZSBlYXNlIHRoZSB1bmRlcnN0YW5kaW5nIGFuZCB3b24ndCByZXN1bHQgYSBoZWFk YWNoZSB0byB0aGUgcmVhZGVyIHdobyBhY2NpZGVudGFsbHkgd2FudHMgdG8gY2FsY3VsYXRlIHJM RkEgY292ZXJhZ2UgaW4NCiBzdWNoIG5ldHdvcmsuPGJyPg0KPGJyPg0KUGxlYXNlIGxldCBtZSBr bm93LCBpZiBteSBpbnRlcnByZXRhdGlvbiBpcyBub3QgY29ycmVjdC48YnI+DQpUaGFua3MuPGJy Pg0KPGJyPg0KQmVzdCw8YnI+DQpMZXZlbnRlPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C5E5ESESSMB307erics_-- From stephane.litkowski@orange.com Fri Aug 2 01:14:41 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9881B11E81E4 for ; Fri, 2 Aug 2013 01:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.945 X-Spam-Level: * X-Spam-Status: No, score=1.945 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wK2kRZQeaIRT for ; Fri, 2 Aug 2013 01:14:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 18BAB21E82A7 for ; Fri, 2 Aug 2013 01:13:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 94D2D18CE10; Fri, 2 Aug 2013 10:13:40 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 64EBA238128; Fri, 2 Aug 2013 10:13:40 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 2 Aug 2013 10:13:40 +0200 From: To: Levente Csikor , "stbryant@cisco.com" Date: Fri, 2 Aug 2013 10:13:38 +0200 Subject: RE: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Topic: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Index: Ac6PCxttHwUdWryeQ5yNnhoPR4+G3AASxoSg Message-ID: <23321_1375431220_51FB6A34_23321_1107_9_EEE55384044474429A926C625D0FCC81095908C18E@PUEXCB2F.nanterre.francetelecom.fr> References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> In-Reply-To: <51FA6C6A.4090200@tmit.bme.hu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC81095908C18EPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 X-Mailman-Approved-At: Fri, 02 Aug 2013 01:16:00 -0700 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:14:41 -0000 --_000_EEE55384044474429A926C625D0FCC81095908C18EPUEXCB2Fnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KQ29ycmVjdCBtZSBpZiBJIGRvbid0IHVuZGVyc3RhbmQgY29ycmVjdGx5IHdoYXQg eW91IG1lYW50Lg0KDQogIkkgaGF2ZSBmb3VuZCB0aGF0IGl0IHNob3VsZCBiZSBtb3JlIGVtcGhh c2l6ZWQgaW4gdGhlIGRyYWZ0IHRoYXQgY2FsY3VsYXRpbmcgb3Igc2Vla2luZyBmb3IgYSByZW1v dGUgTEZBIHN0YWdpbmcgcG9pbnQgc2hvdWxkIGJlIGRvbmUgSUYgQU5EIE9OTFkgSUYgbm8gc2lt cGxlIExGQSB3ZXJlIGZvdW5kLiINCg0KVGhpcyBpcyBob3cgdGhlIGRyYWZ0IGlzIHdyaXR0ZW4g dG9kYXkgOg0KDQrCpzMuMSA6DQoiSWYgdGhlcmUNCiAgIGlzIG5vIHN1Y2ggTEZBIG5laWdoYm9y LCB0aGVuIFMgbWF5IGJlIGFibGUgdG8gY3JlYXRlIGEgdmlydHVhbCBMRkENCiAgIGJ5IHVzaW5n IGEgdHVubmVsIHRvIGNhcnJ5IHRoZSBwYWNrZXQgdG8gYSBwb2ludCBpbiB0aGUgbmV0d29yayB3 aGljaA0KICAgaXMgbm90IGEgZGlyZWN0IG5laWdoYm9yIG9mIFMgZnJvbSB3aGljaCB0aGUgcGFj a2V0IHdpbGwgYmUgZGVsaXZlcmVkDQogICB0byB0aGUgZGVzdGluYXRpb24gd2l0aG91dCBsb29w aW5nIGJhY2sgdG8gUy4iDQoNCsKnNC4xIDoNCiJOb3QgYWxsIGxpbmtzIHdpbGwgcmVxdWlyZSBw cm90ZWN0aW9uIHVzaW5nIGEgdHVubmVsZWQgcmVwYWlyIHBhdGguDQogICBSZWZlcnJpbmcgdG8g RmlndXJlIDEsIGlmIEUgY2FuIGFscmVhZHkgYmUgcHJvdGVjdGVkIHZpYSBhbiBMRkEsIFMtRQ0K ICAgZG9lcyBub3QgbmVlZCB0byBiZSBwcm90ZWN0ZWQgdXNpbmcgYSByZXBhaXIgdHVubmVsLCBz aW5jZSBhbGwNCiAgIGRlc3RpbmF0aW9ucyBub3JtYWxseSByZWFjaGFibGUgdGhyb3VnaCBFIG11 c3QgdGhlcmVmb3JlIGFsc28gYmUNCiAgIHByb3RlY3RhYmxlIGJ5IGFuIExGQS4gIg0KDQpUaGUg ZHJhZnQgYWxzbyBwcmVjaXNlIHRoYXQgZXh0ZW5kZWQgUC1TcGFjZSBtdXN0IGJlIHVzZWQgOg0K IjkuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1s ZmEtMDIjc2VjdGlvbi05LjE+LiAgU2ltcGxpY2l0eQ0KDQogICBUaGUgcmVtb3RlIExGQSBhbGdv cml0aG0gaXMgc2ltcGxlIHRvIGNvbXB1dGUuDQoNCiAgIG8gIFRoZSBleHRlbmRlZCBQIHNwYWNl IGRvZXMgbm90IHJlcXVpcmUgYW55IG5ldyBjb21wdXRhdGlvbiAoaXQgaXMNCiAgICAgIGtub3du IG9uY2UgcGVyLXByZWZpeCBMRkEgY29tcHV0YXRpb24gaXMgY29tcGxldGVkKS4NCiINCg0KSW4g eW91ciBleGFtcGxlLCBOIGlzIHBhcnQgb2YgZXh0ZW5kZWQgUC1TcGFjZS4gU28gTiB3b3VsZCBi ZSBhIFBRIChpdCdzIGEgbm9ybWFsIExGQSBhbHNvIGFzIHlvdSBzdGF0ZWQpLg0KDQoNCg0KDQpN eSBjb21tZW50IDoNCi0gWWVzLCBleHRlbmRlZCBQLVNwYWNlIHVzYWdlIGlzIG1hbmRhdG9yeSBp biBvcmRlciB0byBtYXhpbWl6ZSBjb3ZlcmFnZSAoZm9yIG1lIGl0J3MgY2xlYXJseSBleHBsYWlu ZWQgaW4gdGhlIGRyYWZ0KQ0KDQotIGRyYWZ0IGN1cnJlbnRseSBzdGF0ZXMgdGhhdCByZW1vdGUg TEZBIHdvdWxkIGJlIGNvbXB1dGVkIG9ubHkgd2hlbiBub3JtYWwgTEZBIGlzIG5vdCBhdmFpbGFi bGUgQlVUIHRoaXMgaXMgbm90IGEgZ29vZCBpZGVhLiBCYXNlZCBvbiB0aGUgdXNlIGNhc2Ugd2Ug YXJlIHByZXNlbnRpbmcgaWYgZHJhZnQtaWV0Zi1ydGd3Zy1sZmEtbWFuYWdlYWJpbGl0eSwgdGhl cmUgaXMgYSBzdHJvbmcgaW50ZXJyZXN0IGluIGFsd2F5cyBjb21wdXRpbmcgckxGQSBwcm90ZWN0 aW9uIHRoZW4gYmUgYWJsZSB0byBjb21wYXJlIGF0dHJpYnV0ZXMgb2YgUFFzIGFuZCBub3JtYWwg TEZBcyB0byBkZXRlcm1pbmUgd2hpY2ggb25lIGlzIHRoZSBtb3JlIGVmZmljaWVudCBiYXNlZCBv biBzZXJ2aWNlIHByb3ZpZGVyIHJlcXVpcmVtZW50cy4gVGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQg d2UgZG9uJ3QgdXNlIGV4dGVuZGVkIFAgU3BhY2UsIGV4dGVuZGVkIFAtU3BhY2UgbmVlZCBhbHdh eXMgdG8gYmUgdXNlZC4NCg0KLSBZb3UgYXJlIHByb3ZpZGluZyBOUCBjb3ZlcmFnZSBmb3IgckxG QSAsIHRoYW5rcyBmb3IgdGhlIGluZm8sIGJ1dCBJIGp1c3Qgd2FudCB0byBoaWdobGlnaHQgdGhh dCB0aGlzIGlzIGp1c3QgImluZm9ybWF0aW9uYWwiIGFzIGEgcm91dGVyIGlzIG5vdCBhYmxlIHRv IGRldGVybWluZSB0aGF0IHRoZSBQUSBpcyBwcm92aWRpbmcgTlAgb3Igbm90IGZvciB0aGUgc3Bl Y2lmaWMgZGVzdGluYXRpb24uIERldGVybWluaW5nIHN1Y2ggUFEgYXR0cmlidXRlIHdvdWxkIHJl cXVpcmUgZXh0cmEgU1BGLCBhcyBzdGF0ZWQgaW4gZHJhZnQtcHNhcmthci1ydGd3Zy1ybGZhLW5v ZGUtcHJvdGVjdGlvbi0wMDxodHRwOi8vd3d3Lmdvb2dsZS5mci91cmw/cT1odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9kZS1wcm90ZWN0 aW9uLyZzYT1VJmVpPXpXbjdVY3lHR01UY09vM2FnY2dNJnZlZD0wQ0I0UUZqQUEmdXNnPUFGUWpD TkUxMHZRSi01R29tU0ZzRGtQVlc2bVh6MHd6UlE+Lg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KU3Rl cGhhbmUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGUgOiBydGd3Zy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy dCBkZSBMZXZlbnRlIENzaWtvcg0KRW52b3nDqSA6IGpldWRpIDEgYW/Du3QgMjAxMyAxNjoxMQ0K w4AgOiBzdGJyeWFudEBjaXNjby5jb20NCkNjIDogZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZh QHRvb2xzLmlldGYub3JnOyBydGd3Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IHJ0Z3dnQGlldGYu b3JnDQpPYmpldCA6IFJlOiBkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmEgLSByZWFkeSBmb3Ig V0dMQz8gLSBzb21lIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMNCg0KRGVhciBBbGwsDQpzaW5jZSBv dXIgcHJldmlvdXMgd29ya3MgaW4gcmVtb3RlIExGQSBhbmFseXNpcyAocGFwZXJzIGFscmVhZHkg c2VudCB0byB0aGVzZSBtYWlsaW5nIGxpc3RzKSBhc3N1bWVkIHVuaXQgY29zdCBuZXR3b3Jrcywg dGhlcmVmb3JlIGFzIEkgcHJvbWlzZWQsIEkgY2FsY3VsYXRlZCB0aGUgY29ycmVzcG9uZGluZyBM RkEgYW5kIHJMRkEgY292ZXJhZ2VzIGluIHRob3NlIG5ldHdvcmtzIHdpdGggdGhlaXIgb3JpZ2lu YWwgbGluayBjb3N0cy4NClRoZXNlIG5ldHdvcmtzIHdlcmUgaW5mZXJyZWQgZnJvbSBSb2NrZXRm dWVsIGRhdGFzZXQgKE1haGFqYW4sIFIuLCBTcHJpbmcsIE4uLCBXZXRoZXJhbGwsIEQuLCBBbmRl cnNvbiwgVC46DQpJbmZlcnJpbmcgbGluayB3ZWlnaHRzIHVzaW5nIGVuZC10by1lbmQgbWVhc3Vy ZW1lbnRzLiBJbjogQUNNIElNQywgcHAuIDIzMeKAkzIzNiAoMjAwMikpLCBTTkRMaWIgKGh0dHA6 Ly9zbmRsaWIuemliLmRlKSwgYW5kIFRvcG9sb2d5Wm9vKGh0dHA6Ly93d3cudG9wb2xvZ3ktem9v Lm9yZykuIFRoZSBmb3VuZCBjb3ZlcmFnZXMgYW5kIHNvbWUgZGV0YWlscyBhcmUgZm91bmQgaW4g dGhlIHRhYmxlIGJlbG93LCB3aGVyZSBuIGFuZCBtIGRlbm90ZSB0aGUgbnVtYmVyIG9mIG5vZGVz IGFuZCB0aGUgbnVtYmVyIG9mIGxpbmtzLCByZXNwZWN0aXZlbHkuIFRoZSBvdGhlciBjb2x1bW5z IG1hcmsgdGhlIGRpZmZlcmVudCBjb3ZlcmFnZXMgb2JydGFpbmVkIGJ5IHNpbXBsZSBMRkEgYW5k IHJlbW90ZSBMRkEsIHdoZXJlIExQIGluZGljYXRlcyB0aGUgbGluay1wcm90ZWN0aW5nIGNhc2Us IHdoaWxlIE5QIG5vdGVzIHRoZSBjYXNlIG9mIG5vZGUgcHJvdGVjdGlvbi4NClRvcG9sb2dpZXMg bWFya2VkIHdpdGggYW4gYXN0ZXJpc2soKikgZGlkIG5vdCBoYXZlIGluZmVycmVkIHJlYWwgbGlu ayBjb3N0cyBmcm9tIHRoZSBkYXRhc2V0cywgc28gdGhlaXIgY29zdHMgd2VyZSBpbml0aWFsbHkg c2V0IHRvIDEgKHVuaXQgY29zdHMpLg0KDQpJIGJlbGlldmUgdGhhdCB0aGVzZSByZXN1bHRzIGNv bXB1dGVkIG9uIHJlYWwtd29ybGQgbmV0d29ya3MgY291bGQgc2lnbmlmaWNhbnRseSBpbXByb3Zl IHRoZSBybGZhIGRyYWZ0LCBlc3BlY2lhbGx5IFNlYy4gOS4zLiwgYW5kIHRoZSBhZHZhbnRhZ2Vz IG9mIHJlbW90ZSBMRkEgb3ZlciBzaW1wbGUgTEZBIHdvdWxkIGJlIG1vcmUgZW1waGFzaXplZC4N Cg0KDQorPT09PT09PT09PT09PT0rPT09PSs9PT09Kz09PT09PT09PT0rPT09PT09PT09PT0rPT09 PT09PT09PT09Kz09PT09PT09PT09PSsNCnwgVG9wb2xvZ3kgICAgIHwgbiAgfCBtICB8IExGQV9M UCAgIHwgTEZBX05QICAgIHwgIHJMRkFfTFAgICB8ICByTEZBX05QICAgfA0KKz09PT09PT09PT09 PT09Kz09PT0rPT09PSs9PT09PT09PT09Kz09PT09PT09PT09Kz09PT09PT09PT09PSs9PT09PT09 PT09PT0rDQp8IEFTMTIyMSAgICAgICB8IDcgIHwgOSAgfCAwLjgwOSAgICB8ICAgMC4yNSAgICB8 ICAgMC44MDkgICAgfCAgICAwLjI1ICAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBBUzEyMzkg ICAgICAgfCAzMCB8IDY5IHwgMC44NzM1ICAgfCAgMC43NTU0ICAgfCAgICAgMSAgICAgIHwgICAw Ljk3OTUgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgQVMxNzU1ICAgICAgIHwgMTggfCAzMyB8 IDAuODcyNSAgIHwgIDAuNzc0MSAgIHwgICAwLjk5NjcgICB8ICAgMC45OTU5ICAgfA0KKy0tLS0t LS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rDQp8IEFTMzI1NyAgICAgICB8IDI3IHwgNjQgfCAwLjkyMyAgICB8ICAwLjcx ODYgICB8ICAgMC45OSAgICAgfCAgIDAuODQ3MiAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0t LS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBB UzM5NjcgICAgICAgfCAyMSB8IDM2IHwgMC43ODU3ICAgfCAgMC42NDYwICAgfCAgICAgMSAgICAg IHwgICAwLjkzMjUgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgQVM2NDYxICAgICAgIHwgMTcg fCAzNyB8IDAuOTMzOCAgIHwgIDAuNjkzMyAgIHwgICAwLjk5NjMgICB8ICAgMC43MDc1ICAgfA0K Ky0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0rDQp8IEFiaWxlbmUqICAgICB8IDEyIHwgMTUgfCAwLjU2MDYgICB8 ICAwLjYwNzggICB8ICAgMC45MDkwICAgfCAgIDAuODcyNSAgIHwNCistLS0tLS0tLS0tLS0tLSst LS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t Kw0KfCBBcm5lcyogICAgICAgfCA0MSB8IDU3IHwgMC42MjI1ICAgfCAgMC4zNTE4ICAgfCAgIDAu NzQ4NyAgIHwgICAwLjQ1NjIgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0t LS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgQVQmVCAgICAgICAg IHwgMjIgfCAzOCB8IDAuODIyNSAgIHwgIDAuNTY0NyAgIHwgICAgIDEgICAgICB8ICAgMC44NDk3 ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IERlbHRhY29tICAgICB8IDExM3wgMTYxfCAwLjU3 NzEgICB8ICAwLjQ5MTAgICB8ICAgMC44NTM5ICAgfCAgIDAuODE0OCAgIHwNCistLS0tLS0tLS0t LS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tKw0KfCBHYW1iaWEgICAgICAgfCAyOCB8IDI4IHwgMC4wMzcgICAgfCAgIDAuMDQgICAg fCAgIDAuMTg1MSAgIHwgICAgIDAuMTIgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgR2VhbnQg ICAgICAgIHwgMzcgfCA1NSB8IDAuNjkwNiAgIHwgIDAuMzk3NyAgIHwgICAwLjgzMDMgICB8ICAg MC42NTgyICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IEdlcm1fNTAgICAgICB8IDUwIHwgODgg fCAwLjkwMDQgICB8ICAwLjgzODEgICB8ICAgICAxICAgICAgfCAgIDAuOTk5NSAgIHwNCistLS0t LS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tKw0KfCBHZXJtYW55KiAgICAgfCAyNyB8IDMyIHwgMC42OTQ4ICAgfCAgMC41 OTkgICAgfCAgICAgMSAgICAgIHwgICAwLjk1NDkgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSst LS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwg SW50ZXJuZXRNQ0kgIHwgMTkgfCAzMyB8IDAuOTAzNSAgIHwgIDAuNjc5OCAgIHwgICAwLjk0MTUg ICB8ICAgMC45MTM2ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IEl0YWx5KiAgICAgICB8IDMz IHwgNTYgfCAwLjc4NCAgICB8ICAwLjU3NDEgICB8ICAgICAxICAgICAgfCAgIDAuOTI2OSAgIHwN CistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBOU0YqICAgICAgICAgfCAyNiB8IDQzIHwgMC44NiAgICAg fCAgMC42MzQ3ICAgfCAgICAgMSAgICAgIHwgICAgIDEgICAgICB8DQorLS0tLS0tLS0tLS0tLS0r LS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LSsNCg0KDQpGdXJ0aGVybW9yZSwgYWZ0ZXIgcmVhZGluZyB0aGUgZHJhZnQgYWdhaW4tYW5kLWFn YWluLCBJIGhhdmUgZm91bmQgdGhhdCBpdCBzaG91bGQgYmUgbW9yZSBlbXBoYXNpemVkIGluIHRo ZSBkcmFmdCB0aGF0IGNhbGN1bGF0aW5nIG9yIHNlZWtpbmcgZm9yIGEgcmVtb3RlIExGQSBzdGFn aW5nIHBvaW50IHNob3VsZCBiZSBkb25lIElGIEFORCBPTkxZIElGIG5vIHNpbXBsZSBMRkEgd2Vy ZSBmb3VuZC4gVGhpcyBpcyBpbXBvcnRhbnQsIHNpbmNlIG5vcm1hbGx5IHBlb3BsZSBvYnZpb3Vz bHkgdGhpbmsgYW5kIG9ic2VydmUgdGhhdCB0aGUgZmFpbHVyZSBjb3ZlcmFnZSBvZiByZW1vdGUg TEZBIHNob3VsZCBiZSBncmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8gdGhlIGNvdmVyYWdlIG9idGFp bmVkIGJ5IHNpbXBsZSBMRkEuIE1vcmVvdmVyLCBwZW9wbGUgYWxzbyB0aGluayB0aGF0IExGQXMg cHJvZHVjZSBhIHN1YnNldCBvZiByZW1vdGUgTEZBcy4gSG93ZXZlciwgaWYgYWZ0ZXIgYSBmYWls dXJlIG9ubHkgUC1zcGFjZXMgYW5kIFEtc3BhY2VzIGFyZSB0YWtlbiBpbnRvIGFjY291bnQgaW4g b3JkZXIgdG8gc2VlayBhIChyZW1vdGUpIGxvb3AtZnJlZSBhbHRlcm5hdGUsIHRoZW4gaXQgaXMg cG9zc2libGUgdGhhdCBhIHNpbXBsZSBMRkEgd291bGQgbm90IGJlIGZvdW5kIHJlc3VsdGluZyB1 bnByb3RlY3RlZCBub2RlLXBhaXJzLiBCdXQsIHRoaXMgY2FzZSBjb3VsZCBvbmx5IGhhcHBlbiB3 aGVuIGxpbmsgY29zdHMgYXJlIG5vdCB1bml0IGNvc3RzLiBGb3IgYW4gZWFzaWVyIHVuZGVyc3Rh bmRpbmcsIGNvbnNpZGVyIHRoZSBuZXR3b3JrIGRlcGljdGVkIGJlbG93Og0KICAgICAgICAgICAg MSAgICAgICAgICAgICAgMQ0KICAgICAgICAgIEYtLS0tLS0tLVMtLS0tLS0tLS0tLVgtLS0tLS0t LUUNCiAgICAgICAgICAgXCAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAg MTAgXCAgICAvIDQgICAgICAgICAgICAgICAgICAgICAgXCAgMQ0KICAgICAgICAgICAgIFwgIC8g ICAgICAgIDEgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgTiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1DDQogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAxICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDENCiAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg IHwgICAgICAxICAgICAgICAgICAgIDEgICAgICAgfA0KICAgICAgICAgICAgICBBLS0tLS0tLS0t LS0tLS1CLS0tLS0tLS0tLS0tLUQNCg0KQXNzdW1lIHRoYXQgUyB3aXNoZXMgdG8gc2VuZCBhIHBh Y2tldCB0byBELCBhbmQgdGhlIHNob3J0ZXN0IHBhdGggZ29lcyB0aHJvdWdoIEUsIHRoZXJlZm9y ZSBpdCBpcyBTLUUtQy1ELiBTdXBwb3NlIHRoYXQgdGhlIGxpbmsgKHMsZSkNCmZhaWxzLCBvciBl dmVuIHRoZSBub2RlIGUgaXRzZWxmIGZhaWxzLiBJbiB0aGlzIGNhc2UsIHNpbmNlIExGQSAoYW5k IGl0cyBjYWxjdWxhdGlvbikgb25seSBjb25zaWRlciBhbGwgb3RoZXIgbmVpZ2hib3JzIG9mIHMs IHRoZW4gbm9kZSBOIHdvdWxkIGJlIGFuIGVhc3kgTEZBIGZvciB0aGlzIGZhaWx1cmUsIHNpbmNl IGRpc3QoTixEKSA8IGRpc3QoTixTKStkaXN0KFMsRCkuDQpIb3dldmVyLCBpZiB3ZSBvbmx5IHNl ZWsgcG9zc2libGUgcmVtb3RlIExGQXMsIHRoYW4gYWNjb3JkaW5nIHRvIHRoZSAocilTUEYgY2Fs Y3VsYXRpb25zLCBvciB0YWtpbmcgaW50byBhY2NvdW50IG91ciBkaXN0YW5jZS1mdW5jdGlvbiBj b25kaXRpb25zIHdpbGwgcmVzdWx0IHRoYXQgRCdzIFEtc3BhY2Ugd2lsbCBjb250YWluIG5vZGUg TiAoYmVzaWRlcyBzb21lIG90aGVyIG5vZGVzKSwgYnV0IFMncyBQLXNwYWNlIHdvbid0IChpdCB3 aWxsIG9ubHkgY29udGFpbiBub2RlIEYgYW5kIHdoYXQgaXMgbW9yZSwgaWYgbm9kZSBGIGRvZXMg bm90IGV4aXN0LCB0aGVuIFMncyBQLXNwYWNlIHdvdWxkIGJlIGVtcHR5KSwgdGhlcmVmb3JlIG5v IGludGVyc2VjdGlvbiBvZiB0aGUgdHdvIHNwYWNlcyB3aWxsIGV4aXN0LCBsZWF2aW5nIHRoaXMg bmV0d29yayB2dWxuZXJhYmxlIHRvIHRoZSBmYWlsdXJlIG9mIGxpbmsgKHMsZSkuDQoNClRoaXMg cmVzdWx0cyB0aGF0IGEgbmVpZ2hib3Igc2hvdWxkIGJlIGFsd2F5cyByZWFjaGVkIGJ5IHRoZSBu ZWlnaGJvcmluZyBsaW5rLCBldmVuIGlmIHRoZXJlIGV4aXN0cyBhIHNob3J0ZXIsIGJ1dCBkZWZp bml0ZWx5IGJpZ2dlciBpbiBob3AtY291bnQgcGF0aCB0byBpdC4NCkFjY29yZGluZyB0byB0aGlz IGNhc2UgKHdoZW4gc2Vla2luZyBzaW1wbGUgTEZBIGlzIG1pc3NlZCksIHRoZSBjb25kaXRpb24g b2YgZXh0ZW5kZWQgUC1zcGFjZSBkZXNjcmliZWQgYnkgb3VyIGRpc3RhbmNlIGZ1bmN0aW9ucywg c2hvdWxkIGJlIG1vZGlmaWVkIGEgYml0Og0KRm9yIHNvdXJjZSBzLCBkZXN0aW5hdGlvbiBkLCBh bmQgbmV4dC1ob3AgZSwgc29tZSBub2RlIG4gIT0gcyxkIGlzIGFuIGV4dGVuZGVkIGxpbmstcHJv dGVjdGluZyByZW1vdGUgTEZBIGZvciB0aGUgcy1kIHBhaXIgaWYgYW5kIG9ubHkgaWYNCuKIg3Yg 4oiIIG5laWdoKHMpIDogZGlzdCh2LCBuKSA8IGRpc3QodiwgcykgKyBkaXN0KHMsIGUpICsgZGlz dChlLCBuKSAgJiYgZGlzdChzLHYpIDwgZGlzdChzLGUpICsgZGlzdChlLHYpDQpkaXN0KG4sIGQp IDwgZGlzdChuLCBzKSArIGRpc3QocywgZCkgLg0KDQpPbmUgY2FuIGVhc2lseSBvYnNlcnZlIHRo YXQgZW1waGFzaXppbmcgbW9yZSB0aGF0IHJlbW90ZSBMRkEgc2Vla2luZyBwcm9jZXNzIGlzIG9u bHkgImV4ZWN1dGVkIiBhZnRlciBubyBzaW1wbGUgTEZBIGlzIGZvdW5kIGNvdWxkIG11Y2ggbW9y ZSBlYXNlIHRoZSB1bmRlcnN0YW5kaW5nIGFuZCB3b24ndCByZXN1bHQgYSBoZWFkYWNoZSB0byB0 aGUgcmVhZGVyIHdobyBhY2NpZGVudGFsbHkgd2FudHMgdG8gY2FsY3VsYXRlIHJMRkEgY292ZXJh Z2UgaW4gc3VjaCBuZXR3b3JrLg0KDQpQbGVhc2UgbGV0IG1lIGtub3csIGlmIG15IGludGVycHJl dGF0aW9uIGlzIG5vdCBjb3JyZWN0Lg0KVGhhbmtzLg0KDQpCZXN0LA0KTGV2ZW50ZQ0KDQpPbiAw Ny8wMi8yMDEzIDA3OjA3IFBNLCBTdGV3YXJ0IEJyeWFudCB3cm90ZToNCk9uIDI2LzA2LzIwMTMg MTQ6MTMsIExldmVudGUgQ3Npa29yIHdyb3RlOg0KDQpMZXZlbnRlDQoNCkluIGVhY2ggY2FzZSBi ZWxvdyB0aGUgY29uZGl0aW9ucyBhcmUgc3VyZWx5IGZ1bGZpbGxlZCBpZiBuPWUNCnRodXMgSSB0 aGluayB0aGF0IGluIGVhY2ggY2FzZSB0aGUgY29uZGl0aW9uIG5lZWRzIHRvIGJlDQpjaGFuZ2Vk IHRvIDoNCg0Kc29tZSBub2RlIG4hPXtzIG9yIGV9DQpJbiBvcmRlciB0byBub3QgdG8gcmVhZCBv dXIgZnVsbCBwYXBlcnMgYW5kIHNlYXJjaGluZyB0aGUgYW5zd2VycywgSSBjb3BpZWQgaGVyZSB0 aGUgcmVsZXZhbnQgcGFydHM6DQpMaW5rLXByb3RlY3RpbmcgckxGQSBjb25kaXRpb246DQpGb3Ig c291cmNlIHMsIGRlc3RpbmF0aW9uIGQsIGFuZCBuZXh0LWhvcCBlLCBzb21lIG5vZGUgbiAhPSBz LGQgaXMgYSBsaW5rLXByb3RlY3RpbmcgcmVtb3RlIExGQSBmb3IgdGhlIHMtZCBwYWlyICBpZiBh bmQgb25seSBpZg0KICBkaXN0KHMsIG4pIDwgZGlzdChzLCBlKSArIGRpc3QoZSwgbikgICgxKQ0K ICBkaXN0KG4sIGQpIDwgZGlzdChuLCBzKSArIGRpc3QocywgZCkgICgyKQ0KSW4gdGhlc2UgZXF1 YXRpb25zLCBvbmUgY2FuIGVhc2lseSBzZWUsIHRoYXQgKDEpIGRlZmluZXMgdGhlIFAtc3BhY2Us IHdoaWxlICgyKSBpcyB0aGUgY29uZGl0aW9uIG9mIFEtc3BhY2UuIEZ1cnRoZXJtb3JlLCB3aXRo IHRoZXNlIGZvcm1hbGl6ZWQgY29uZGl0aW9ucywgb25lIGNhbiBlYXNpbHkgb2JzZXJ2ZSwgdGhh dCAoMikgaXMgYWN0dWFsbHkgdGhlIGJhc2ljIGxvb3AtZnJlZSBjcml0ZXJpb24gb2YgcHVyZSBM RkEuDQoNCkxpbmstcHJvdGVjdGluZyByTEZBIGNvbmRpdGlvbiB3aXRoIGV4dGVuZGVkIFAtc3Bh Y2U6DQpGb3Igc291cmNlIHMsIGRlc3RpbmF0aW9uIGQsIGFuZCBuZXh0LWhvcCBlLCBzb21lIG5v ZGUgbiAhPSBzLGQgaXMgYW4gZXh0ZW5kZWQgbGluay1wcm90ZWN0aW5nIHJlbW90ZSBMRkEgZm9y IHRoZSBzLWQgcGFpciBpZiBhbmQgb25seSBpZg0K4oiDdiDiiIggbmVpZ2gocykgOiBkaXN0KHYs IG4pIDwgZGlzdCh2LCBzKSArIGRpc3QocywgZSkgKyBkaXN0KGUsIG4pDQpkaXN0KG4sIGQpIDwg ZGlzdChuLCBzKSArIGRpc3QocywgZCkgLg0KDQpOb2RlLXByb3RlY3RpbmcgckxGQSBjb25kaXRp b246DQpGb3Igc291cmNlIHMsIGRlc3RpbmF0aW9uIGQsIGFuZCBuZXh0LWhvcCBlLCBzb21lIG4g IT0gcyxkIGlzIGEgbm9kZS1wcm90ZWN0aW5nIHJlbW90ZSBMRkEgZm9yIHRoZSBzLWQgcGFpciBp ZiBhbmQgb25seSBpZg0KZGlzdChzLG4pIDwgZGlzdChzLGUpICsgZGlzdChlLG4pICAgICAgKDMp DQpkaXN0KG4sZCkgPCBkaXN0KG4sZSkgKyBkaXN0KGUsZCkgICAgICg0KQ0KQXMgaXQgd2FzIGlu IHRoZSBjYXNlIG9mIGxpbmsgcHJvdGVjdGlvbiwgaGVyZSwgKDMpIGRlZmluZXMgdGhlIFAtc3Bh Y2UsIHdoaWxlICg0KSBjaGFyYWN0ZXJpemUgdGhlIFEtc3BhY2UuDQpIZXJlLCB0d28gaW1wb3J0 YW50IG9ic2VydmF0aW9ucyBjYW4gYmUgbWFkZSwgd2hpY2ggYXJlIHRoZSBmb2xsb3dpbmdzOg0K IC0gUC1zcGFjZSBkb2VzIG5vdCBkZXBlbmQgb24gdGhlIHByb3RlY3Rpb24gc2NoZW1lIChpLmUu LCBsaW5rIG9yIG5vZGUgcHJvdGVjdGlvbikNClNCPiBUaGF0IGZhbGxzIGRpcmVjdGx5IG91dCBv ZiB0aGUgZGVmaW5pdGlvbiBvZiBQLXNwYWNlDQpTQj4gc2luY2UgaW4gbGluayB5b3UgY2Fubm90 IHRyYXZlcnNlIHRoZSBsaW5rIHRvIGUgYW5kIGluDQpTQj4gbm9kZSBvbmx5IGdldCB0byBlIGlm IHlvdSB0cmF2ZXJzZSB0aGUgbGluayB0byBlDQpTQj4gdGh1cyB0aGUgZXhjbHVzaW9uIG9mIHRo ZSBsaW5rIHRvIGUgYXBwbGllcyBpbiBib3RoIGNhc2VzDQogLSAoNCkgYWdhaW4gaXMgdGhlIGJh c2ljIG5vZGUtcHJvdGVjdGluZyBsb29wLWZyZWUgY3JpdGVyaW9uIG9mIHB1cmUgTEZBLg0KDQpO b2RlLXByb3RlY3RpbmcgckxGQSBjb25kaXRpb24gd2l0aCBleHRlbmRlZCBQLXNwYWNlOg0KRm9y IHNvdXJjZSBzLCBkZXN0aW5hdGlvbiBkLCBhbmQgbmV4dC1ob3AgZSwgc29tZSBub2RlIG4gIT0g cyxkIGlzIGFuIGV4dGVuZGVkIG5vZGUtcHJvdGVjdGluZyByZW1vdGUgTEZBIGZvciB0aGUgcy1k IHBhaXIgaWYgYW5kIG9ubHkgaWYNCuKIg3Yg4oiIIG5laWdoKHMpIDogZGlzdCh2LCBuKSA8IGRp c3QodiwgZSkgKyBkaXN0KGUsIG4pDQpkaXN0KG4sIGQpIDwgZGlzdChuLCBlKSArIGRpc3QoZSwg ZCkgLg0KDQpEZXNwaXRlIHRoZSBmYWN0IHRoYXQgd2Ugb25seSBjb25zaWRlcmVkIHVuaXQgY29z dCBuZXR3b3JrcywgdGhlIGZvcm1hbCBkZWZpbml0aW9ucyBhYm92ZSBhcmUgdHJ1ZSBmb3IgYW55 IGFyYml0cmFyeSB3ZWlnaHRlZCBuZXR3b3JrLg0KU0I+IEkgZG8gbm90IHNlZSB3aGVyZSB0aGUg dW5pdCBjb3N0cyBjb21lIGludG8gdGhlIHRleHQgYWJvdmUuIEl0IGxvb2tzDQpTQj4gbGlrZSBp dCBpcyBhbHJlYWR5IGV4cHJlc3NlZCBpbiB0ZXJtcyBvZiBhcmJpdHJhcnkgY29zdC4NCg0KU0I+ IEFkZGl0aW9uYWxseSBpbiBvcmRlciB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIFNQRnMgdG8gYSBw cmFjdGljYWwNClNCPiBsZXZlbCwgd2Ugbm9ybWFsbHkgc3VnZ2VzdCB0aGF0IHRoZSByZXBhaXIg dGFyZ2V0IGluIG5vdCBkLCBidXQNClNCPiBpbnN0ZWFkIGlzIGUgKGluIHRoZSBsaW5rIGNhc2Up IG9yIG5leHQgaG9wIG9mIGUgKG5vZGUgY2FzZSkuDQoNClNCPiBBbnl3YXkgSSB3aWxsIHdvcmsg b24gc29tZSB0ZXh0Lg0KDQotIFN0ZXdhcnQNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_EEE55384044474429A926C625D0FCC81095908C18EPUEXCB2Fnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjYwMDAuMjEyNjQiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIHRleHQ9IzAwMDAw MCBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkw Ny0wMjA4MjAxMz48L1NQQU4+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCnNpemU9Mj5IaSw8L0ZP TlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkwNy0wMjA4MjAxMz48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj5Db3JyZWN0IG1lIGlmIEkgDQpkb24ndCB1bmRlcnN0YW5kIGNvcnJlY3Rs eSB3aGF0IHlvdSBtZWFudC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04 MDUyNjU5MDctMDIwODIwMTM+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+Jm5ic3A7 IkkgaGF2ZSBmb3VuZCB0aGF0IGl0IHNob3VsZCBiZSBtb3JlIA0KZW1waGFzaXplZCBpbiB0aGUg ZHJhZnQgdGhhdCBjYWxjdWxhdGluZyBvciBzZWVraW5nIGZvciBhIHJlbW90ZSBMRkEgc3RhZ2lu ZyANCnBvaW50IHNob3VsZCBiZSBkb25lIElGIEFORCBPTkxZIElGIG5vIHNpbXBsZSBMRkEgd2Vy ZSBmb3VuZC4iPC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIw MTM+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIw MTM+VGhpcyBpcyBob3cgdGhlIGRyYWZ0IGlzIHdyaXR0ZW4gdG9kYXkgDQo6PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+PEZPTlQgZmFjZT1BcmlhbCAN CnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUy NjU5MDctMDIwODIwMTM+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+wqczLjEgDQo6PC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9ODA1MjY1OTA3LTAyMDgyMDEzPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPiJJZiANCnRoZXJlPEJSPiZuYnNwOyZuYnNwOyBpcyBubyBzdWNoIExG QSBuZWlnaGJvciwgdGhlbiBTIG1heSBiZSBhYmxlIHRvIGNyZWF0ZSBhIA0KdmlydHVhbCBMRkE8 QlI+Jm5ic3A7Jm5ic3A7IGJ5IHVzaW5nIGEgdHVubmVsIHRvIGNhcnJ5IHRoZSBwYWNrZXQgdG8g YSBwb2ludCBpbiANCnRoZSBuZXR3b3JrIHdoaWNoPEJSPiZuYnNwOyZuYnNwOyBpcyBub3QgYSBk aXJlY3QgbmVpZ2hib3Igb2YgUyBmcm9tIHdoaWNoIHRoZSANCnBhY2tldCB3aWxsIGJlIGRlbGl2 ZXJlZDxCUj4mbmJzcDsmbmJzcDsgdG8gdGhlIGRlc3RpbmF0aW9uIHdpdGhvdXQgbG9vcGluZyBi YWNrIA0KdG8gUy4iPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9ODA1MjY1 OTA3LTAyMDgyMDEzPjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJz cDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9ODA1MjY1OTA3LTAyMDgyMDEzPsKnNC4xIDo8L1NQ QU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkwNy0wMjA4MjAxMz4iTm90IGFsbCBs aW5rcyB3aWxsIHJlcXVpcmUgcHJvdGVjdGlvbiB1c2luZyANCmEgdHVubmVsZWQgcmVwYWlyIHBh dGguPEJSPiZuYnNwOyZuYnNwOyBSZWZlcnJpbmcgdG8gRmlndXJlIDEsIGlmIEUgY2FuIGFscmVh ZHkgDQpiZSBwcm90ZWN0ZWQgdmlhIGFuIExGQSwgUy1FPEJSPiZuYnNwOyZuYnNwOyBkb2VzIG5v dCBuZWVkIHRvIGJlIHByb3RlY3RlZCB1c2luZyANCmEgcmVwYWlyIHR1bm5lbCwgc2luY2UgYWxs PEJSPiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbnMgbm9ybWFsbHkgcmVhY2hhYmxlIA0KdGhyb3Vn aCBFIG11c3QgdGhlcmVmb3JlIGFsc28gYmU8QlI+Jm5ic3A7Jm5ic3A7IHByb3RlY3RhYmxlIGJ5 IGFuIA0KTEZBLiZuYnNwOyI8L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkw Ny0wMjA4MjAxMz4mbmJzcDs8L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkw Ny0wMjA4MjAxMz48L1NQQU4+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+VDxTUEFOIA0K Y2xhc3M9ODA1MjY1OTA3LTAyMDgyMDEzPmhlIGRyYWZ0IGFsc28gcHJlY2lzZSB0aGF0IGV4dGVu ZGVkIFAtU3BhY2UgbXVzdCBiZSANCnVzZWQgOjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVD48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+ PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PFNQQU4gDQpjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+PC9T UEFOPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiI8U1BBTiBjbGFzcz1oMz48QSANCmNsYXNzPXNl bGZsaW5rIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGd3 Zy1yZW1vdGUtbGZhLTAyI3NlY3Rpb24tOS4xIiANCm5hbWU9c2VjdGlvbi05LjE+PFNUUk9ORz48 Rk9OVCANCmNvbG9yPSMwMDAwMDA+OS4xPC9GT05UPjwvU1RST05HPjwvQT48U1RST05HPi4mbmJz cDsgDQpTaW1wbGljaXR5PC9TVFJPTkc+PC9TUEFOPjxCUj48QlI+Jm5ic3A7Jm5ic3A7IFRoZSBy ZW1vdGUgTEZBIGFsZ29yaXRobSBpcyANCnNpbXBsZSB0byBjb21wdXRlLjxCUj48QlI+Jm5ic3A7 Jm5ic3A7IG8mbmJzcDsgVGhlIGV4dGVuZGVkIFAgc3BhY2UgZG9lcyBub3QgDQpyZXF1aXJlIGFu eSBuZXcgY29tcHV0YXRpb24gKGl0IGlzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBrbm93biBvbmNlIA0KcGVyLXByZWZpeCBMRkEgY29tcHV0YXRpb24gaXMgY29tcGxldGVkKS48 QlI+PFNQQU4gDQpjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+PC9TUEFOPiI8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkwNy0wMjA4 MjAxMz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JbiB5b3VyIGV4YW1wbGUsIE4gDQppcyBwYXJ0 IG9mIGV4dGVuZGVkIFAtU3BhY2UuIFNvIE4gd291bGQgYmUgYSBQUSAoaXQncyBhIG5vcm1hbCBM RkEgYWxzbyBhcyB5b3UgDQpzdGF0ZWQpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTgwNTI2NTkwNy0wMjA4MjAxMz48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkwNy0wMjA4MjAx Mz48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkwNy0wMjA4MjAxMz48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkw Ny0wMjA4MjAxMz48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTgwNTI2NTkwNy0wMjA4MjAxMz48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5NeSBjb21tZW50IA0KOjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTgwNTI2NTkwNy0wMjA4MjAxMz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4tIFllcywg ZXh0ZW5kZWQgDQpQLVNwYWNlIHVzYWdlIGlzIG1hbmRhdG9yeSBpbiBvcmRlciB0byBtYXhpbWl6 ZSBjb3ZlcmFnZSAoZm9yIG1lIGl0J3MgY2xlYXJseSANCmV4cGxhaW5lZCBpbiB0aGUgZHJhZnQp PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9ODA1MjY1OTA3LTAyMDgyMDEz PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxE SVY+PFNQQU4gY2xhc3M9ODA1MjY1OTA3LTAyMDgyMDEzPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y Pi0gZHJhZnQgY3VycmVudGx5IA0Kc3RhdGVzIHRoYXQgcmVtb3RlIExGQSZuYnNwO3dvdWxkIGJl IGNvbXB1dGVkIG9ubHkgd2hlbiBub3JtYWwgTEZBIGlzIG5vdCANCmF2YWlsYWJsZSBCVVQgdGhp cyBpcyBub3QgYSBnb29kIGlkZWEuIEJhc2VkIG9uIHRoZSB1c2UgY2FzZSB3ZSBhcmUgcHJlc2Vu dGluZyANCmlmIGRyYWZ0LWlldGYtcnRnd2ctbGZhLW1hbmFnZWFiaWxpdHksIHRoZXJlIGlzIGEg c3Ryb25nIGludGVycmVzdCBpbiBhbHdheXMgDQpjb21wdXRpbmcgckxGQSBwcm90ZWN0aW9uIHRo ZW4gYmUgYWJsZSB0byBjb21wYXJlIGF0dHJpYnV0ZXMgb2YgUFFzIGFuZCBub3JtYWwgDQpMRkFz IHRvIGRldGVybWluZSB3aGljaCBvbmUgaXMgdGhlIG1vcmUgZWZmaWNpZW50IGJhc2VkIG9uIHNl cnZpY2UgcHJvdmlkZXIgDQpyZXF1aXJlbWVudHMuIFRoaXMgZG9lcyBub3QgbWVhbiB0aGF0IHdl IGRvbid0IHVzZSBleHRlbmRlZCBQIFNwYWNlLCBleHRlbmRlZCANClAtU3BhY2UgbmVlZCBhbHdh eXMgdG8gYmUgdXNlZC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUy NjU5MDctMDIwODIwMTM+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+LSBZb3UgYXJlIHByb3ZpZGluZyANCk5QIGNvdmVyYWdlIGZvciByTEZB ICwgdGhhbmtzIGZvciB0aGUgaW5mbywgYnV0IEkganVzdCB3YW50IHRvIGhpZ2hsaWdodCB0aGF0 IA0KdGhpcyBpcyBqdXN0ICJpbmZvcm1hdGlvbmFsIiBhcyBhIHJvdXRlciBpcyBub3QgYWJsZSB0 byBkZXRlcm1pbmUgdGhhdCB0aGUgUFEgaXMgDQpwcm92aWRpbmcgTlAgb3Igbm90IGZvciB0aGUg c3BlY2lmaWMgZGVzdGluYXRpb24uIERldGVybWluaW5nIHN1Y2ggUFEgYXR0cmlidXRlIA0Kd291 bGQgcmVxdWlyZSBleHRyYSBTUEYsIGFzIHN0YXRlZCBpbiA8QSANCmhyZWY9Imh0dHA6Ly93d3cu Z29vZ2xlLmZyL3VybD9xPWh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBz YXJrYXItcnRnd2ctcmxmYS1ub2RlLXByb3RlY3Rpb24vJmFtcDtzYT1VJmFtcDtlaT16V243VWN5 R0dNVGNPbzNhZ2NnTSZhbXA7dmVkPTBDQjRRRmpBQSZhbXA7dXNnPUFGUWpDTkUxMHZRSi01R29t U0ZzRGtQVlc2bVh6MHd6UlEiPjxGT05UIA0Kc2l6ZT0zPjxGT05UIA0KY29sb3I9IzExMjJjYz48 Qj5kcmFmdDwvQj4tcHNhcmthci1ydGd3Zy08Qj5ybGZhPC9CPi08Qj5ub2RlPC9CPi08Qj5wcm90 ZWN0aW9uPC9CPi0wMDwvRk9OVD48L0ZPTlQ+PC9BPi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDct MDIwODIwMTM+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv RElWPg0KPERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+QmVzdCANClJlZ2FyZHMsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9ODA1MjY1OTA3LTAyMDgyMDEzPjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05U PjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9ODA1MjY1OTA3LTAyMDgyMDEz PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+U3RlcGhhbmU8L0ZPTlQ+PC9TUEFOPjwvRElWPg0K PERJVj48U1BBTiBjbGFzcz04MDUyNjU5MDctMDIwODIwMTM+PEZPTlQgZmFjZT1BcmlhbCANCnNp emU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxGT05UIA0KZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD48Rk9OVCBm YWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+ PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PEJSPjwvRElWPg0KPEJMT0NLUVVPVEUg c3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhl YWRlciBsYW5nPWZyIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4PS0xPg0KICA8 Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RGUmbmJzcDs6PC9CPiBydGd3Zy1ib3VuY2VzQGll dGYub3JnIA0KICBbbWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmddIDxCPkRlIGxhIHBhcnQg ZGU8L0I+IExldmVudGUgDQogIENzaWtvcjxCUj48Qj5FbnZvecOpJm5ic3A7OjwvQj4gamV1ZGkg MSBhb8O7dCAyMDEzIDE2OjExPEJSPjxCPsOAJm5ic3A7OjwvQj4gDQogIHN0YnJ5YW50QGNpc2Nv LmNvbTxCUj48Qj5DYyZuYnNwOzo8L0I+IA0KICBkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmFA dG9vbHMuaWV0Zi5vcmc7IHJ0Z3dnLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgDQogIHJ0Z3dnQGll dGYub3JnPEJSPjxCPk9iamV0Jm5ic3A7OjwvQj4gUmU6IGRyYWZ0LWlldGYtcnRnd2ctcmVtb3Rl LWxmYSAtIHJlYWR5IA0KICBmb3IgV0dMQz8gLSBzb21lIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM8 QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj5EZWFyIEFsbCw8QlI+c2luY2Ugb3Vy IHByZXZpb3VzIHdvcmtzIGluIHJlbW90ZSBMRkEgYW5hbHlzaXMgDQogIChwYXBlcnMgYWxyZWFk eSBzZW50IHRvIHRoZXNlIG1haWxpbmcgbGlzdHMpIGFzc3VtZWQgdW5pdCBjb3N0IG5ldHdvcmtz LCANCiAgdGhlcmVmb3JlIGFzIEkgcHJvbWlzZWQsIEkgY2FsY3VsYXRlZCB0aGUgY29ycmVzcG9u ZGluZyBMRkEgYW5kIHJMRkEgY292ZXJhZ2VzIA0KICBpbiB0aG9zZSBuZXR3b3JrcyB3aXRoIHRo ZWlyIG9yaWdpbmFsIGxpbmsgY29zdHMuPEJSPlRoZXNlIG5ldHdvcmtzIHdlcmUgDQogIGluZmVy cmVkIGZyb20gUm9ja2V0ZnVlbCBkYXRhc2V0ICg8ST5NYWhhamFuLCBSLiwgU3ByaW5nLCBOLiwg V2V0aGVyYWxsLCBELiwgDQogIEFuZGVyc29uLCBULjo8L0k+PEk+PEJSPjwvST48ST5JbmZlcnJp bmcgbGluayB3ZWlnaHRzIHVzaW5nIGVuZC10by1lbmQgDQogIG1lYXN1cmVtZW50cy4gSW46IEFD TSBJTUMsIHBwLiAyMzHigJMyMzYgKDIwMDIpPC9JPiksIFNORExpYiAoPEEgDQogIGNsYXNzPW1v ei10eHQtbGluay1mcmVldGV4dCANCiAgaHJlZj0iaHR0cDovL3NuZGxpYi56aWIuZGUiPmh0dHA6 Ly9zbmRsaWIuemliLmRlPC9BPiksIGFuZCBUb3BvbG9neVpvbyg8QSANCiAgY2xhc3M9bW96LXR4 dC1saW5rLWZyZWV0ZXh0IA0KICBocmVmPSJodHRwOi8vd3d3LnRvcG9sb2d5LXpvby5vcmciPmh0 dHA6Ly93d3cudG9wb2xvZ3ktem9vLm9yZzwvQT4pLiBUaGUgZm91bmQgDQogIGNvdmVyYWdlcyBh bmQgc29tZSBkZXRhaWxzIGFyZSBmb3VuZCBpbiB0aGUgdGFibGUgYmVsb3csIHdoZXJlIDxJPm48 L0k+IGFuZCANCiAgPEk+bTwvST4gZGVub3RlIHRoZSBudW1iZXIgb2Ygbm9kZXMgYW5kIHRoZSBu dW1iZXIgb2YgbGlua3MsIHJlc3BlY3RpdmVseS4gVGhlIA0KICBvdGhlciBjb2x1bW5zIG1hcmsg dGhlIGRpZmZlcmVudCBjb3ZlcmFnZXMgb2JydGFpbmVkIGJ5IHNpbXBsZSBMRkEgYW5kIHJlbW90 ZSANCiAgTEZBLCB3aGVyZSBMUCBpbmRpY2F0ZXMgdGhlIGxpbmstcHJvdGVjdGluZyBjYXNlLCB3 aGlsZSBOUCBub3RlcyB0aGUgY2FzZSBvZiANCiAgbm9kZSBwcm90ZWN0aW9uLjxCUj5Ub3BvbG9n aWVzIG1hcmtlZCB3aXRoIGFuIGFzdGVyaXNrKCopIGRpZCBub3QgaGF2ZSANCiAgaW5mZXJyZWQg cmVhbCBsaW5rIGNvc3RzIGZyb20gdGhlIGRhdGFzZXRzLCBzbyB0aGVpciBjb3N0cyB3ZXJlIGlu aXRpYWxseSBzZXQgDQogIHRvIDEgKHVuaXQgY29zdHMpLjxCUj48QlI+SSBiZWxpZXZlIHRoYXQg dGhlc2UgcmVzdWx0cyBjb21wdXRlZCBvbiByZWFsLXdvcmxkIA0KICBuZXR3b3JrcyBjb3VsZCBz aWduaWZpY2FudGx5IGltcHJvdmUgdGhlIHJsZmEgZHJhZnQsIGVzcGVjaWFsbHkgU2VjLiA5LjMu LCBhbmQgDQogIHRoZSBhZHZhbnRhZ2VzIG9mIHJlbW90ZSBMRkEgb3ZlciBzaW1wbGUgTEZBIHdv dWxkIGJlIG1vcmUgDQogIGVtcGhhc2l6ZWQuPEJSPjxCUj48QlI+PEZPTlQgDQogIGZhY2U9IkNv dXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPis9PT09PT09PT09PT09PSs9PT09Kz09PT0r PT09PT09PT09PSs9PT09PT09PT09PSs9PT09PT09PT09PT0rPT09PT09PT09PT09KzxCUj58IA0K ICBUb3BvbG9neSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG4mbmJzcDsgfCBtJm5ic3A7IHwg TEZBX0xQJm5ic3A7Jm5ic3A7IHwgDQogIExGQV9OUCZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 IHJMRkFfTFAmbmJzcDsmbmJzcDsgfCZuYnNwOyANCiAgckxGQV9OUCZuYnNwOyZuYnNwOyANCiAg fDxCUj4rPT09PT09PT09PT09PT0rPT09PSs9PT09Kz09PT09PT09PT0rPT09PT09PT09PT0rPT09 PT09PT09PT09Kz09PT09PT09PT09PSs8QlI+fCANCiAgQVMxMjIxJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyB8IDcmbmJzcDsgfCA5Jm5ic3A7IHwgDQogIDAuODA5Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsgPC9GT05UPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldywg Q291cmllciwgbW9ub3NwYWNlIj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcsJiMxMzsmIzEw OyAgICAgICAgQ291cmllciwgbW9ub3NwYWNlIj4wLjI1PC9GT05UPiZuYnNwOyZuYnNwOyZuYnNw OyANCiAgfCZuYnNwOyZuYnNwOyAwLjgwOSZuYnNwOyAmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyAwLjI1Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB8PEJSPistLS0tLS0tLS0tLS0tLSstLS0tKy0t LS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKzwvRk9O VD48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPnwg QVMxMjM5ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCAzMCANCiAgfCA2OSB8IDAuODczNSZu YnNwOyZuYnNwOyB8Jm5ic3A7IDwvRk9OVD48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcsIENv dXJpZXIsJiMxMzsmIzEwOyAgICAgIG1vbm9zcGFjZSI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIg TmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjAuNzU1NDwvRk9OVD4mbmJzcDsmbmJzcDsgDQogIHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSAmbmJzcDsmbmJzcDsgJm5ic3A7IHwmbmJzcDsmbmJz cDsgDQogIDAuOTc5NSZuYnNwOyZuYnNwOyB8PC9GT05UPjxCUj48Rk9OVCANCiAgZmFjZT0iQ291 cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSst LS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rPC9GT05UPjxC Uj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+fCBBUzE3 NTUgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDE4IA0KICB8IDMzIHwgMC44NzI1ICZuYnNw OyB8Jm5ic3A7IDAuNzc0MSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTk2NyAmbmJzcDsg DQogIHwmbmJzcDsmbmJzcDsgMC45OTU5ICZuYnNwOyB8PC9GT05UPjxCUj48Rk9OVCANCiAgZmFj ZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tKy0tLS0r LS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rPC9G T05UPjxCUj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+ fCBBUzMyNTcgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDI3IA0KICB8IDY0IHwgMC45MjMm bmJzcDsgJm5ic3A7IHwmbmJzcDsgMC43MTg2Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC45 OSAmbmJzcDsgDQogICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODQ3MiAmbmJzcDsgfDwvRk9OVD48 QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPistLS0t LS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tKzwvRk9OVD48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3Vy aWVyLCBtb25vc3BhY2UiPnwgQVMzOTY3ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCAyMSAN CiAgfCAzNiB8IDAuNzg1NyAmbmJzcDsgfCZuYnNwOyAwLjY0NjAgJm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMSAmbmJzcDsgDQogICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAu OTMyNSZuYnNwOyZuYnNwOyB8PC9GT05UPjxCUj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcs IENvdXJpZXIsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0t Ky0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rPC9GT05UPjxCUj48Rk9OVCAN CiAgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+fCBBUzY0NjEgJm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDE3IA0KICB8IDM3IHwgMC45MzM4Jm5ic3A7Jm5ic3A7IHwm bmJzcDsgMC42OTMzICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTk2MyAmbmJzcDsgDQogIHwmbmJz cDsmbmJzcDsgMC43MDc1ICZuYnNwOyB8PC9GT05UPjxCUj48Rk9OVCANCiAgZmFjZT0iQ291cmll ciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0t LS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rPC9GT05UPjxCUj48 Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+fCBBYmlsZW5l KiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IDEyIA0KICB8IDE1IHwgMC41NjA2Jm5ic3A7Jm5i c3A7IHwmbmJzcDsgMC42MDc4ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTA5MCAmbmJzcDsgDQog IHwmbmJzcDsmbmJzcDsgMC44NzI1ICZuYnNwOyB8PC9GT05UPjxCUj48Rk9OVCANCiAgZmFjZT0i Q291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tKy0tLS0rLS0t LSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rPC9GT05U PjxCUj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+fCBB cm5lcyombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyB8IDQxIA0KICB8IDU3IHwgMC42MjI1ICZu YnNwOyB8Jm5ic3A7IDAuMzUxOCAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjc0ODcgJm5ic3A7IA0K ICB8Jm5ic3A7Jm5ic3A7IDAuNDU2MiAmbmJzcDsgfDwvRk9OVD48QlI+PEZPTlQgDQogIGZhY2U9 IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPistLS0tLS0tLS0tLS0tLSstLS0tKy0t LS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKzwvRk9O VD48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPnwg QVQmYW1wO1QgJm5ic3A7ICZuYnNwOyZuYnNwOyANCiAgJm5ic3A7Jm5ic3A7IHwgMjIgfCAzOCB8 IDAuODIyNSAmbmJzcDsgfCZuYnNwOyAwLjU2NDcgJm5ic3A7IA0KICB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODQ5NyAmbmJz cDsgDQogIHw8L0ZPTlQ+PEJSPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldywgQ291cmllciwg bW9ub3NwYWNlIj4rLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSs8L0ZPTlQ+PEJSPjxGT05UIA0KICBmYWNlPSJD b3VyaWVyIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj58IERlbHRhY29tJm5ic3A7ICZuYnNwOyZu YnNwOyB8IDExM3wgDQogIDE2MXwgMC41NzcxICZuYnNwOyB8Jm5ic3A7IDAuNDkxMCAmbmJzcDsg fCZuYnNwOyZuYnNwOyAwLjg1MzkgJm5ic3A7IA0KICB8Jm5ic3A7Jm5ic3A7IDAuODE0OCAmbmJz cDsgfDwvRk9OVD48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25v c3BhY2UiPistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKzwvRk9OVD48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJp ZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPnwgR2FtYmlhICZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsgfCAyOCANCiAgfCAyOCB8IDAuMDM3ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAu MDQgJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC4xODUxIA0KICAmbmJzcDsgfCZuYnNwOyZu YnNwOyAmbmJzcDsgMC4xMiAmbmJzcDsgfDwvRk9OVD48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJp ZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKzwvRk9OVD48QlI+ PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPnwgR2VhbnQm bmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyANCiAgfCAzNyB8IDU1IHwgMC42OTA2Jm5i c3A7Jm5ic3A7IHwmbmJzcDsgMC4zOTc3ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODMwMyANCiAg Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC42NTgyICZuYnNwOyB8PC9GT05UPjxCUj48Rk9OVCANCiAg ZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tKy0t LS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r PC9GT05UPjxCUj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFj ZSI+fCBHZXJtXzUwJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDUwIA0KICB8IDg4IHwgMC45 MDA0Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgMC44MzgxICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDEgDQogICZuYnNwOyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk5OTUgJm5i c3A7IHw8L0ZPTlQ+PEJSPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldywgQ291cmllciwgbW9u b3NwYWNlIj4rLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSs8L0ZPTlQ+PEJSPjxGT05UIA0KICBmYWNlPSJDb3Vy aWVyIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj58IEdlcm1hbnkqJm5ic3A7ICZuYnNwOyZuYnNw OyB8IDI3IHwgMzIgDQogIHwgMC42OTQ4ICZuYnNwOyB8Jm5ic3A7IDAuNTk5Jm5ic3A7ICZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7IA0KICAmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyAwLjk1NDkgJm5ic3A7IHw8L0ZPTlQ+PEJSPjxGT05UIA0KICBmYWNlPSJDb3Vy aWVyIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj4rLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSs8L0ZPTlQ+PEJS PjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj58IEludGVy bmV0TUNJJm5ic3A7IHwgMTkgfCAzMyB8IDAuOTAzNSANCiAgJm5ic3A7IHwmbmJzcDsgMC42Nzk4 ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTQxNSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IA0K ICAwLjkxMzYgJm5ic3A7IHw8L0ZPTlQ+PEJSPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldywg Q291cmllciwgbW9ub3NwYWNlIj4rLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0r LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSs8L0ZPTlQ+PEJSPjxGT05UIA0K ICBmYWNlPSJDb3VyaWVyIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj58IEl0YWx5KiAmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMzMgDQogIHwgNTYgfCAwLjc4NCZuYnNwOyAmbmJzcDsgfCZu YnNwOyAwLjU3NDEgJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSANCiAgJm5ic3A7 ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTI2OSAmbmJzcDsgfDwvRk9OVD48QlI+PEZP TlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPistLS0tLS0tLS0t LS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tKzwvRk9OVD48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBt b25vc3BhY2UiPnwgTlNGKiAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyANCiAgfCAy NiB8IDQzIHwgMC44NiAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgMC42MzQ3ICZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAxICZuYnNwOyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyAmbmJzcDsgMSAmbmJzcDsgJm5ic3A7Jm5ic3A7IA0KICB8PC9GT05UPjxCUj48Rk9OVCANCiAg ZmFjZT0iQ291cmllciBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tKy0t LS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r PC9GT05UPjxCUj48QlI+PEJSPkZ1cnRoZXJtb3JlLCANCiAgYWZ0ZXIgcmVhZGluZyB0aGUgZHJh ZnQgYWdhaW4tYW5kLWFnYWluLCBJIGhhdmUgZm91bmQgdGhhdCBpdCBzaG91bGQgYmUgbW9yZSAN CiAgZW1waGFzaXplZCBpbiB0aGUgZHJhZnQgdGhhdCBjYWxjdWxhdGluZyBvciBzZWVraW5nIGZv ciBhIHJlbW90ZSBMRkEgc3RhZ2luZyANCiAgcG9pbnQgc2hvdWxkIGJlIGRvbmUgSUYgQU5EIE9O TFkgSUYgbm8gc2ltcGxlIExGQSB3ZXJlIGZvdW5kLiBUaGlzIGlzIA0KICBpbXBvcnRhbnQsIHNp bmNlIG5vcm1hbGx5IHBlb3BsZSBvYnZpb3VzbHkgdGhpbmsgYW5kIG9ic2VydmUgdGhhdCB0aGUg ZmFpbHVyZSANCiAgY292ZXJhZ2Ugb2YgcmVtb3RlIExGQSBzaG91bGQgYmUgZ3JlYXRlciB0aGFu IG9yIGVxdWFsIHRvIHRoZSBjb3ZlcmFnZSANCiAgb2J0YWluZWQgYnkgc2ltcGxlIExGQS4gTW9y ZW92ZXIsIHBlb3BsZSBhbHNvIHRoaW5rIHRoYXQgTEZBcyBwcm9kdWNlIGEgc3Vic2V0IA0KICBv ZiByZW1vdGUgTEZBcy4gSG93ZXZlciwgaWYgYWZ0ZXIgYSBmYWlsdXJlIG9ubHkgUC1zcGFjZXMg YW5kIFEtc3BhY2VzIGFyZSANCiAgdGFrZW4gaW50byBhY2NvdW50IGluIG9yZGVyIHRvIHNlZWsg YSAocmVtb3RlKSBsb29wLWZyZWUgYWx0ZXJuYXRlLCB0aGVuIGl0IGlzIA0KICBwb3NzaWJsZSB0 aGF0IGEgc2ltcGxlIExGQSB3b3VsZCBub3QgYmUgZm91bmQgcmVzdWx0aW5nIHVucHJvdGVjdGVk IA0KICBub2RlLXBhaXJzLiBCdXQsIHRoaXMgY2FzZSBjb3VsZCBvbmx5IGhhcHBlbiB3aGVuIGxp bmsgY29zdHMgYXJlIG5vdCB1bml0IA0KICBjb3N0cy4gRm9yIGFuIGVhc2llciB1bmRlcnN0YW5k aW5nLCBjb25zaWRlciB0aGUgbmV0d29yayBkZXBpY3RlZCANCiAgYmVsb3c6PEJSPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiIHNpemU9LTE+PEZPTlQgDQogIHNp emU9LTE+PEZPTlQgc2l6ZT0tMT48Rk9OVCBzaXplPS0xPjxGT05UIHNpemU9LTE+PEZPTlQgc2l6 ZT0tMT48Rk9OVCANCiAgc2l6ZT0tMT48Rk9OVCBzaXplPS0xPjxGT05UIHNpemU9LTE+PEZPTlQg c2l6ZT0tMT48Rk9OVCBzaXplPS0xPjxGT05UIA0KICBzaXplPS0xPjxGT05UIHNpemU9LTE+PEZP TlQgc2l6ZT0tMT48Rk9OVCBzaXplPS0xPjxGT05UIHNpemU9LTE+PEZPTlQgDQogIHNpemU9LTE+ PEZPTlQgc2l6ZT0tMT48Rk9OVCBzaXplPS0xPjxGT05UIHNpemU9LTE+PEZPTlQgc2l6ZT0tMT48 Rk9OVCANCiAgc2l6ZT0tMT48Rk9OVCBzaXplPS0xPjxGT05UIHNpemU9LTE+PEZPTlQgc2l6ZT0t MT48Rk9OVCBzaXplPS0xPjxGT05UIA0KICBzaXplPS0xPjxGT05UIHNpemU9LTE+PEZPTlQgc2l6 ZT0tMT4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMSZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICAmbmJzcDsmbmJzcDsmbmJzcDsgMTxCUj48Rk9OVCBzaXplPS0xPiZuYnNwOyZuYnNwOyZuYnNw OyANCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIHNpemU9LTE+PEZPTlQg DQogIHNpemU9LTE+Ri0tLS0tLS0tPC9GT05UPlMtLS0tLS0tLS0tLTxGT05UIHNpemU9LTE+WDwv Rk9OVD4tLS0tLS0tLTxGT05UIA0KICBzaXplPS0xPkU8L0ZPTlQ+PC9GT05UPjxCUj48Rk9OVCAN CiAgc2l6ZT0tMT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogIFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQg c2l6ZT0tMT4vJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICBcPEJSPjxGT05UIHNpemU9LTE+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAxMCANCiAgXCZuYnNwOyZuYnNwOyZuYnNwOyAvIDQmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgXCZuYnNwOyAxPEJSPjxGT05UIA0KICBz aXplPS0xPiZuYnNwOyAmbmJzcDsgPEZPTlQgc2l6ZT0tMT4mbmJzcDsgJm5ic3A7PC9GT05UPiAm bmJzcDsmbmJzcDsgJm5ic3A7IA0KICBcJm5ic3A7IC8mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBcPC9GT05UPjxCUj48Rk9OVCAN CiAgc2l6ZT0tMT4mbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgDQogIHNpemU9LTE+TiA8Rk9OVCBzaXplPS0xPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD5DPEJSPjxGT05UIA0KICBzaXplPS0xPiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICA8Rk9OVCBzaXplPS0xPnwmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgDQogIHNpemU9LTE+Jm5i c3A7Jm5ic3A7IHwgPC9GT05UPjxCUj48Rk9OVCBzaXplPS0xPiZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyANCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7IDxGT05UIHNpemU9LTE+fCZuYnNwOyAxPC9GT05UPjxCUj48Rk9O VCANCiAgc2l6ZT0tMT4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IA0KICB8Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyA8Rk9OVCANCiAgc2l6 ZT0tMT58PC9GT05UPjxCUj48Rk9OVCBzaXplPS0xPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsgDQogICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsgPEZPTlQgDQogIHNpemU9LTE+MTwvRk9OVD4mbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgMSAmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7IDxGT05UIHNpemU9LTE+fDwvRk9OVD48QlI+PEZPTlQgDQogIHNp emU9LTE+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQogIEEtLS0tLS0tLS0tLS0tLUItLS0tLS0tLS0tLS0tRDwvRk9O VD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05U PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+ PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48 L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwv Rk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PEZP TlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjxCUj48L0ZPTlQ+ PEJSPkFzc3VtZSB0aGF0IFMgd2lzaGVzIHRvIA0KICBzZW5kIGEgcGFja2V0IHRvIEQsIGFuZCB0 aGUgc2hvcnRlc3QgcGF0aCBnb2VzIHRocm91Z2ggRSwgdGhlcmVmb3JlIGl0IGlzIA0KICBTLUUt Qy1ELiBTdXBwb3NlIHRoYXQgdGhlIGxpbmsgKHMsZSk8QlI+ZmFpbHMsIG9yIGV2ZW4gdGhlIG5v ZGUgZSBpdHNlbGYgDQogIGZhaWxzLiBJbiB0aGlzIGNhc2UsIHNpbmNlIExGQSAoYW5kIGl0cyBj YWxjdWxhdGlvbikgb25seSBjb25zaWRlciBhbGwgb3RoZXIgDQogIG5laWdoYm9ycyBvZiBzLCB0 aGVuIG5vZGUgTiB3b3VsZCBiZSBhbiBlYXN5IExGQSBmb3IgdGhpcyBmYWlsdXJlLCBzaW5jZSAN CiAgZGlzdChOLEQpICZsdDsgZGlzdChOLFMpK2Rpc3QoUyxEKS48QlI+SG93ZXZlciwgaWYgd2Ug b25seSBzZWVrIHBvc3NpYmxlIA0KICByZW1vdGUgTEZBcywgdGhhbiBhY2NvcmRpbmcgdG8gdGhl IChyKVNQRiBjYWxjdWxhdGlvbnMsIG9yIHRha2luZyBpbnRvIGFjY291bnQgDQogIG91ciBkaXN0 YW5jZS1mdW5jdGlvbiBjb25kaXRpb25zIHdpbGwgcmVzdWx0IHRoYXQgRCdzIFEtc3BhY2Ugd2ls bCBjb250YWluIA0KICBub2RlIE4gKGJlc2lkZXMgc29tZSBvdGhlciBub2RlcyksIGJ1dCBTJ3Mg UC1zcGFjZSB3b24ndCAoaXQgd2lsbCBvbmx5IGNvbnRhaW4gDQogIG5vZGUgRiBhbmQgd2hhdCBp cyBtb3JlLCBpZiBub2RlIEYgZG9lcyBub3QgZXhpc3QsIHRoZW4gUydzIFAtc3BhY2Ugd291bGQg YmUgDQogIGVtcHR5KSwgdGhlcmVmb3JlIG5vIGludGVyc2VjdGlvbiBvZiB0aGUgdHdvIHNwYWNl cyB3aWxsIGV4aXN0LCBsZWF2aW5nIHRoaXMgDQogIG5ldHdvcmsgdnVsbmVyYWJsZSB0byB0aGUg ZmFpbHVyZSBvZiBsaW5rIChzLGUpLjxCUj48QlI+VGhpcyByZXN1bHRzIHRoYXQgYSANCiAgbmVp Z2hib3Igc2hvdWxkIGJlIGFsd2F5cyByZWFjaGVkIGJ5IHRoZSBuZWlnaGJvcmluZyBsaW5rLCBl dmVuIGlmIHRoZXJlIA0KICBleGlzdHMgYSBzaG9ydGVyLCBidXQgZGVmaW5pdGVseSBiaWdnZXIg aW4gaG9wLWNvdW50IHBhdGggdG8gaXQuPEJSPkFjY29yZGluZyANCiAgdG8gdGhpcyBjYXNlICh3 aGVuIHNlZWtpbmcgc2ltcGxlIExGQSBpcyBtaXNzZWQpLCB0aGUgY29uZGl0aW9uIG9mIGV4dGVu ZGVkIA0KICBQLXNwYWNlIGRlc2NyaWJlZCBieSBvdXIgZGlzdGFuY2UgZnVuY3Rpb25zLCBzaG91 bGQgYmUgbW9kaWZpZWQgYSBiaXQ6PEJSPkZvciANCiAgc291cmNlIDxJPnM8L0k+LCBkZXN0aW5h dGlvbiA8ST5kPC9JPiwgYW5kIG5leHQtaG9wIDxJPmU8L0k+LCBzb21lIG5vZGUgPEk+biANCiAg IT0gcyxkPC9JPiBpcyBhbiBleHRlbmRlZCBsaW5rLXByb3RlY3RpbmcgcmVtb3RlIExGQSBmb3Ig dGhlIDxJPnMtZDwvST4gcGFpciANCiAgaWYgYW5kIG9ubHkgaWY8QlI+PEk+4oiDdiDiiIggbmVp Z2gocykgOiBkaXN0KHYsIG4pICZsdDsgZGlzdCh2LCBzKSArIGRpc3QocywgZSkgKyANCiAgZGlz dChlLCBuKTwvST48ST4mbmJzcDsgPEI+JmFtcDsmYW1wOyBkaXN0KHMsdikgJmx0OyBkaXN0KHMs ZSkgKyANCiAgZGlzdChlPC9CPjxCPix2KTwvQj48L0k+PEI+PC9CPjxCUj48ST5kaXN0KG4sIGQp ICZsdDsgZGlzdChuLCBzKSArIGRpc3QocywgZCkgDQogIC4gPC9JPjxCUj48QlI+T25lIGNhbiBl YXNpbHkgb2JzZXJ2ZSB0aGF0IGVtcGhhc2l6aW5nIG1vcmUgdGhhdCByZW1vdGUgTEZBIA0KICBz ZWVraW5nIHByb2Nlc3MgaXMgb25seSAiZXhlY3V0ZWQiIGFmdGVyIG5vIHNpbXBsZSBMRkEgaXMg Zm91bmQgY291bGQgbXVjaCANCiAgbW9yZSBlYXNlIHRoZSB1bmRlcnN0YW5kaW5nIGFuZCB3b24n dCByZXN1bHQgYSBoZWFkYWNoZSB0byB0aGUgcmVhZGVyIHdobyANCiAgYWNjaWRlbnRhbGx5IHdh bnRzIHRvIGNhbGN1bGF0ZSByTEZBIGNvdmVyYWdlIGluIHN1Y2ggbmV0d29yay48QlI+PEJSPlBs ZWFzZSANCiAgbGV0IG1lIGtub3csIGlmIG15IGludGVycHJldGF0aW9uIGlzIG5vdCANCiAgY29y cmVjdC48QlI+VGhhbmtzLjxCUj48QlI+QmVzdCw8QlI+TGV2ZW50ZTxCUj48QlI+DQogIDxESVYg Y2xhc3M9bW96LWNpdGUtcHJlZml4Pk9uIDA3LzAyLzIwMTMgMDc6MDcgUE0sIFN0ZXdhcnQgQnJ5 YW50IA0KICB3cm90ZTo8QlI+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkOjUxRDMwOEQw LjUwOTA3MDdAY2lzY28uY29tIHR5cGU9ImNpdGUiPg0KICAgIDxESVYgY2xhc3M9bW96LWNpdGUt cHJlZml4Pk9uIDI2LzA2LzIwMTMgMTQ6MTMsIExldmVudGUgQ3Npa29yIA0KICAgIHdyb3RlOjxC Uj48L0RJVj48QlI+TGV2ZW50ZTxCUj48QlI+SW4gZWFjaCBjYXNlIGJlbG93IHRoZSBjb25kaXRp b25zIGFyZSANCiAgICBzdXJlbHkgZnVsZmlsbGVkIGlmIG49ZTxCUj50aHVzIEkgdGhpbmsgdGhh dCBpbiBlYWNoIGNhc2UgdGhlIGNvbmRpdGlvbiANCiAgICBuZWVkcyB0byBiZSA8QlI+Y2hhbmdl ZCB0byA6PEJSPjxCUj5zb21lIG5vZGUgbiE9e3Mgb3IgZX08QlI+DQogICAgPEJMT0NLUVVPVEUg Y2l0ZT1taWQ6NTFDQUU5MTUuNDAyMDMwNEB0bWl0LmJtZS5odSB0eXBlPSJjaXRlIj5JbiBvcmRl ciB0byANCiAgICAgIG5vdCB0byByZWFkIG91ciBmdWxsIHBhcGVycyBhbmQgc2VhcmNoaW5nIHRo ZSBhbnN3ZXJzLCBJIGNvcGllZCBoZXJlIHRoZSANCiAgICAgIHJlbGV2YW50IHBhcnRzOjxCUj48 Qj5MaW5rLXByb3RlY3RpbmcgckxGQSBjb25kaXRpb246PC9CPjxCUj5Gb3Igc291cmNlIA0KICAg ICAgPEk+czwvST4sIGRlc3RpbmF0aW9uIDxJPmQ8L0k+LCBhbmQgbmV4dC1ob3AgPEk+ZTwvST4s IHNvbWUgbm9kZSA8ST5uPC9JPiANCiAgICAgIDxJPiE9IHMsZDwvST4gaXMgYSBsaW5rLXByb3Rl Y3RpbmcgcmVtb3RlIExGQSBmb3IgdGhlIDxJPnMtZDwvST4gDQogICAgICBwYWlyJm5ic3A7IGlm IGFuZCBvbmx5IGlmPEJSPiZuYnNwOyA8ST5kaXN0KHMsIG4pICZsdDsgZGlzdChzLCBlKSArIA0K ICAgICAgZGlzdChlLCBuKTwvST4mbmJzcDsgKDEpPEJSPiZuYnNwOyA8ST5kaXN0KG4sIGQpICZs dDsgZGlzdChuLCBzKSArIGRpc3QocywgDQogICAgICBkKTwvST4mbmJzcDsgKDIpPEJSPkluIHRo ZXNlIGVxdWF0aW9ucywgb25lIGNhbiBlYXNpbHkgc2VlLCB0aGF0ICgxKSANCiAgICAgIGRlZmlu ZXMgdGhlIFAtc3BhY2UsIHdoaWxlICgyKSBpcyB0aGUgY29uZGl0aW9uIG9mIFEtc3BhY2UuIEZ1 cnRoZXJtb3JlLCANCiAgICAgIHdpdGggdGhlc2UgZm9ybWFsaXplZCBjb25kaXRpb25zLCBvbmUg Y2FuIGVhc2lseSBvYnNlcnZlLCB0aGF0ICgyKSBpcyANCiAgICAgIGFjdHVhbGx5IHRoZSBiYXNp YyBsb29wLWZyZWUgY3JpdGVyaW9uIG9mIHB1cmUgDQogICAgICBMRkEuPEJSPjxCUj48Qj5MaW5r LXByb3RlY3RpbmcgckxGQSBjb25kaXRpb24gd2l0aCBleHRlbmRlZCANCiAgICAgIFAtc3BhY2U6 PC9CPjxCUj5Gb3Igc291cmNlIDxJPnM8L0k+LCBkZXN0aW5hdGlvbiA8ST5kPC9JPiwgYW5kIG5l eHQtaG9wIA0KICAgICAgPEk+ZTwvST4sIHNvbWUgbm9kZSA8ST5uICE9IHMsZDwvST4gaXMgYW4g ZXh0ZW5kZWQgbGluay1wcm90ZWN0aW5nIHJlbW90ZSANCiAgICAgIExGQSBmb3IgdGhlIDxJPnMt ZDwvST4gcGFpciBpZiBhbmQgb25seSBpZjxCUj48ST7iiIN2IOKIiCBuZWlnaChzKSA6IGRpc3Qo diwgDQogICAgICBuKSAmbHQ7IGRpc3QodiwgcykgKyBkaXN0KHMsIGUpICsgZGlzdChlLCBuKTwv ST48ST4gPC9JPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgIDxCUj48ST5kaXN0KG4sIGQpICZs dDsgZGlzdChuLCBzKSArIGRpc3QocywgZCkgLiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICZu YnNwOzwvST4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyANCiAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7IDxCUj48 QlI+PEI+Tm9kZS1wcm90ZWN0aW5nIHJMRkEgDQogICAgICBjb25kaXRpb246PC9CPjxCUj5Gb3Ig c291cmNlIDxJPnM8L0k+LCBkZXN0aW5hdGlvbiA8ST5kPC9JPiwgYW5kIG5leHQtaG9wIA0KICAg ICAgPEk+ZTwvST4sIHNvbWUgPEk+biAhPSBzLGQ8L0k+IGlzIGEgbm9kZS1wcm90ZWN0aW5nIHJl bW90ZSBMRkEgZm9yIHRoZSANCiAgICAgIDxJPnMtZDwvST4gcGFpciBpZiBhbmQgb25seSBpZjxC Uj48ST5kaXN0KHMsbikgJmx0OyBkaXN0KHMsZSkgKyANCiAgICAgIGRpc3QoZSxuKTwvST48ST4m bmJzcDs8L0k+ICZuYnNwOyZuYnNwOyZuYnNwOyAoMyk8QlI+PEk+ZGlzdChuLGQpICZsdDsgDQog ICAgICBkaXN0KG4sZSkgKyBkaXN0KGUsZCkgPC9JPiZuYnNwOyZuYnNwOyZuYnNwOyAoNCk8QlI+ QXMgaXQgd2FzIGluIHRoZSBjYXNlIA0KICAgICAgb2YgbGluayBwcm90ZWN0aW9uLCBoZXJlLCAo MykgZGVmaW5lcyB0aGUgUC1zcGFjZSwgd2hpbGUgKDQpIGNoYXJhY3Rlcml6ZSANCiAgICAgIHRo ZSBRLXNwYWNlLjxCUj5IZXJlLCB0d28gaW1wb3J0YW50IG9ic2VydmF0aW9ucyBjYW4gYmUgbWFk ZSwgd2hpY2ggYXJlIA0KICAgICAgdGhlIGZvbGxvd2luZ3M6IDxCUj4mbmJzcDstIFAtc3BhY2Ug ZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBwcm90ZWN0aW9uIA0KICAgICAgc2NoZW1lIChpLmUuLCBs aW5rIG9yIG5vZGUgcHJvdGVjdGlvbik8QlI+PC9CTE9DS1FVT1RFPlNCJmd0OyBUaGF0IGZhbGxz IA0KICAgIGRpcmVjdGx5IG91dCBvZiB0aGUgZGVmaW5pdGlvbiBvZiBQLXNwYWNlPEJSPlNCJmd0 OyBzaW5jZSBpbiBsaW5rIHlvdSBjYW5ub3QgDQogICAgdHJhdmVyc2UgdGhlIGxpbmsgdG8gZSBh bmQgaW48QlI+U0ImZ3Q7IG5vZGUgb25seSBnZXQgdG8gZSBpZiB5b3UgdHJhdmVyc2UgDQogICAg dGhlIGxpbmsgdG8gZTxCUj5TQiZndDsgdGh1cyB0aGUgZXhjbHVzaW9uIG9mIHRoZSBsaW5rIHRv IGUgYXBwbGllcyBpbiBib3RoIA0KICAgIGNhc2VzPEJSPg0KICAgIDxCTE9DS1FVT1RFIGNpdGU9 bWlkOjUxQ0FFOTE1LjQwMjAzMDRAdG1pdC5ibWUuaHUgdHlwZT0iY2l0ZSI+Jm5ic3A7LSAoNCkg DQogICAgICBhZ2FpbiBpcyB0aGUgYmFzaWMgbm9kZS1wcm90ZWN0aW5nIGxvb3AtZnJlZSBjcml0 ZXJpb24gb2YgcHVyZSANCiAgICAgIExGQS48QlI+PEJSPjxCPk5vZGUtcHJvdGVjdGluZyByTEZB IGNvbmRpdGlvbiB3aXRoIGV4dGVuZGVkIA0KICAgICAgUC1zcGFjZTo8L0I+PEJSPkZvciBzb3Vy Y2UgPEk+czwvST4sIGRlc3RpbmF0aW9uIDxJPmQ8L0k+LCBhbmQgbmV4dC1ob3AgDQogICAgICA8 ST5lPC9JPiwgc29tZSBub2RlIDxJPm4gIT0gcyxkPC9JPiBpcyBhbiBleHRlbmRlZCBub2RlLXBy b3RlY3RpbmcgcmVtb3RlIA0KICAgICAgTEZBIGZvciB0aGUgPEk+cy1kPC9JPiBwYWlyIGlmIGFu ZCBvbmx5IGlmPEJSPjxJPuKIg3Yg4oiIIG5laWdoKHMpIDogZGlzdCh2LCANCiAgICAgIG4pICZs dDsgZGlzdCh2LCBlKSArIGRpc3QoZSwgbik8L0k+PEJSPjxJPmRpc3QobiwgZCkgJmx0OyBkaXN0 KG4sIGUpICsgDQogICAgICBkaXN0KGUsIGQpIC48L0k+PEJSPjxCUj48L0JMT0NLUVVPVEU+DQog ICAgPEJMT0NLUVVPVEUgY2l0ZT1taWQ6NTFDQUU5MTUuNDAyMDMwNEB0bWl0LmJtZS5odSB0eXBl PSJjaXRlIj5EZXNwaXRlIHRoZSANCiAgICAgIGZhY3QgdGhhdCB3ZSBvbmx5IGNvbnNpZGVyZWQg dW5pdCBjb3N0IG5ldHdvcmtzLCB0aGUgZm9ybWFsIGRlZmluaXRpb25zIA0KICAgICAgYWJvdmUg YXJlIDxCSUc+PEI+dHJ1ZSBmb3IgYW55IGFyYml0cmFyeSB3ZWlnaHRlZCANCiAgICBuZXR3b3Jr LjwvQj48L0JJRz48QlI+PC9CTE9DS1FVT1RFPlNCJmd0OyBJIGRvIG5vdCBzZWUgd2hlcmUgdGhl IHVuaXQgY29zdHMgDQogICAgY29tZSBpbnRvIHRoZSB0ZXh0IGFib3ZlLiBJdCBsb29rcyA8QlI+ U0ImZ3Q7IGxpa2UgaXQgaXMgYWxyZWFkeSBleHByZXNzZWQgDQogICAgaW4gdGVybXMgb2YgYXJi aXRyYXJ5IGNvc3QuPEJSPjxCUj5TQiZndDsgQWRkaXRpb25hbGx5IGluIG9yZGVyIHRvIGxpbWl0 IHRoZSANCiAgICBudW1iZXIgb2YgU1BGcyB0byBhIHByYWN0aWNhbDxCUj5TQiZndDsgbGV2ZWws IHdlIG5vcm1hbGx5IHN1Z2dlc3QgdGhhdCB0aGUgDQogICAgcmVwYWlyIHRhcmdldCBpbiBub3Qg ZCwgYnV0PEJSPlNCJmd0OyBpbnN0ZWFkIGlzIGUgKGluIHRoZSBsaW5rIGNhc2UpIG9yIA0KICAg IG5leHQgaG9wIG9mIGUgKG5vZGUgY2FzZSkuPEJSPjxCUj5TQiZndDsgQW55d2F5IEkgd2lsbCB3 b3JrIG9uIHNvbWUgDQogICAgdGV4dC48QlI+PEJSPi0gU3Rld2FydDxCUj48L0JMT0NLUVVPVEU+ PEJSPjwvQkxPQ0tRVU9URT48UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L0JPRFk+PC9I VE1MPg0K --_000_EEE55384044474429A926C625D0FCC81095908C18EPUEXCB2Fnante_-- From csikor@tmit.bme.hu Fri Aug 2 01:31:11 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CDC11E82B9 for ; Fri, 2 Aug 2013 01:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.44 X-Spam-Level: * X-Spam-Status: No, score=1.44 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF6FzKlduDC8 for ; Fri, 2 Aug 2013 01:30:03 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id 5831321F99D2 for ; Fri, 2 Aug 2013 01:28:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id EC15187350; Fri, 2 Aug 2013 10:26:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lDrPAdgPQ-9; Fri, 2 Aug 2013 10:26:39 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id A9DC487346; Fri, 2 Aug 2013 10:26:39 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r728QjAb011930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 10:26:45 +0200 Message-ID: <51FB6D43.4060106@tmit.bme.hu> Date: Fri, 02 Aug 2013 10:26:43 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?R8OhYm9yIFPDoW5kb3IgRW55ZWRp?= Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> <51FB50BB.90303@tmit.bme.hu> <51FB673E.9020905@tmit.bme.hu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060903000409090208090406" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:31:11 -0000 This is a multi-part message in MIME format. --------------060903000409090208090406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit See comments inline. On 08/02/2013 10:10 AM, Gábor Sándor Enyedi wrote: > > Nice. However, I’m a bit confused, because topologies with uniform > link costs should have 100% link failure coverage (if they are > 2-connected), shouldn’t they? Isn’t Abilene and Arnes 2-connected? > Yepp, they are not 2-connected Abilene: http://www.ots.utsystem.edu/pubs/internet2/graphics/abilenebackbone.gif Arnes: http://www.xipi.eu/InfinityImages/images/2263/arnes.png > Other: did you noticed that with some minimal extra computation, > > it is possible to reach 100% node protection with rLFA, if we suppose > that all the nodes do rLFA in the network. > I'm a bit confused: why do we suppose that not all nodes do rLFA? > Maybe we could assign a single extra label/IP address to say that “use > uniform link costs for this packet”, and get something quite similar > to MRT? :) > > Gabor > > *From:*Levente Csikor [mailto:csikor@tmit.bme.hu] > *Sent:* Friday, August 02, 2013 10:01 AM > *To:* Gábor Sándor Enyedi > *Cc:* stbryant@cisco.com; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; > rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org > *Subject:* Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some > comments and questions > > These are bidirectional results. > > Levente > > On 08/02/2013 09:59 AM, Gábor Sándor Enyedi wrote: > > Are these the single or the bidirectional coverage results? > > Gabor > > *From:*rtgwg-bounces@ietf.org > [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Levente Csikor > *Sent:* Friday, August 02, 2013 8:25 AM > *To:* stbryant@cisco.com > *Cc:* draft-ietf-rtgwg-remote-lfa@tools.ietf.org > ; > rtgwg-chairs@tools.ietf.org ; > rtgwg@ietf.org > *Subject:* Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - > some comments and questions > > Dear All, > I'm sending my previous mail again since the font for the ASCII > art network was not fixed and may not appear in a right format at > everyone. > > If it still messy, let me know. > > Sorry, > Levente > > > Dear All, > since our previous works in remote LFA analysis (papers already > sent to these mailing lists) assumed unit cost networks, therefore > as I promised, I calculated the corresponding LFA and rLFA > coverages in those networks with their original link costs. > These networks were inferred from Rocketfuel dataset (/Mahajan, > R., Spring, N., Wetherall, D., Anderson, T.: > Inferring link weights using end-to-end measurements. In: ACM IMC, > pp. 231–236 (2002)/), SNDLib (http://sndlib.zib.de), and > TopologyZoo(http://www.topology-zoo.org). The found coverages and > some details are found in the table below, where /n/ and /m/ > denote the number of nodes and the number of links, respectively. > The other columns mark the different coverages obrtained by simple > LFA and remote LFA, where LP indicates the link-protecting case, > while NP notes the case of node protection. > Topologies marked with an asterisk(*) did not have inferred real > link costs from the datasets, so their costs were initially set to > 1 (unit costs). > > I believe that these results computed on real-world networks could > significantly improve the rlfa draft, especially Sec. 9.3., and > the advantages of remote LFA over simple LFA would be more emphasized. > > > +==============+====+====+==========+===========+============+============+ > | Topology | n | m | LFA_LP | LFA_NP | rLFA_LP | > rLFA_NP | > +==============+====+====+==========+===========+============+============+ > | AS1221 | 7 | 9 | 0.809 | 0.25 | 0.809 | > 0.25 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1239 | 30 | 69 | 0.8735 | 0.7554 | 1 | > 0.9795 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1755 | 18 | 33 | 0.8725 | 0.7741 | 0.9967 | > 0.9959 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3257 | 27 | 64 | 0.923 | 0.7186 | 0.99 | > 0.8472 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3967 | 21 | 36 | 0.7857 | 0.6460 | 1 | > 0.9325 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS6461 | 17 | 37 | 0.9338 | 0.6933 | 0.9963 | > 0.7075 | > +--------------+----+----+----------+-----------+------------+------------+ > | Abilene* | 12 | 15 | 0.5606 | 0.6078 | 0.9090 | > 0.8725 | > +--------------+----+----+----------+-----------+------------+------------+ > | Arnes* | 41 | 57 | 0.6225 | 0.3518 | 0.7487 | > 0.4562 | > +--------------+----+----+----------+-----------+------------+------------+ > | AT&T | 22 | 38 | 0.8225 | 0.5647 | 1 | > 0.8497 | > +--------------+----+----+----------+-----------+------------+------------+ > | Deltacom | 113| 161| 0.5771 | 0.4910 | 0.8539 | > 0.8148 | > +--------------+----+----+----------+-----------+------------+------------+ > | Gambia | 28 | 28 | 0.037 | 0.04 | 0.1851 | > 0.12 | > +--------------+----+----+----------+-----------+------------+------------+ > | Geant | 37 | 55 | 0.6906 | 0.3977 | 0.8303 | > 0.6582 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germ_50 | 50 | 88 | 0.9004 | 0.8381 | 1 | > 0.9995 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germany* | 27 | 32 | 0.6948 | 0.599 | 1 | > 0.9549 | > +--------------+----+----+----------+-----------+------------+------------+ > | InternetMCI | 19 | 33 | 0.9035 | 0.6798 | 0.9415 | > 0.9136 | > +--------------+----+----+----------+-----------+------------+------------+ > | Italy* | 33 | 56 | 0.784 | 0.5741 | 1 | > 0.9269 | > +--------------+----+----+----------+-----------+------------+------------+ > | NSF* | 26 | 43 | 0.86 | 0.6347 | 1 | 1 > | > +--------------+----+----+----------+-----------+------------+------------+ > > > Furthermore, after reading the draft again-and-again, I have found > that it should be more emphasized in the draft that calculating or > seeking for a remote LFA staging point should be done IF AND ONLY > IF no simple LFA were found. This is important, since normally > people obviously think and observe that the failure coverage of > remote LFA should be greater than or equal to the coverage > obtained by simple LFA. Moreover, people also think that LFAs > produce a subset of remote LFAs. However, if after a failure only > P-spaces and Q-spaces are taken into account in order to seek a > (remote) loop-free alternate, then it is possible that a simple > LFA would not be found resulting unprotected node-pairs. But, this > case could only happen when link costs are not unit costs. For an > easier understanding, consider the network depicted below: > 1 1 > F--------S-----------X--------E > \ / \ > 10 \ / 4 \ 1 > \ / 1 \ > N ---------------------------C > | | > 1 | | 1 > | | > | 1 1 | > A--------------B-------------D > > Assume that S wishes to send a packet to D, and the shortest path > goes through E, therefore it is S-E-C-D. Suppose that the link (s,e) > fails, or even the node e itself fails. In this case, since LFA > (and its calculation) only consider all other neighbors of s, then > node N would be an easy LFA for this failure, since dist(N,D) < > dist(N,S)+dist(S,D). > However, if we only seek possible remote LFAs, than according to > the (r)SPF calculations, or taking into account our > distance-function conditions will result that D's Q-space will > contain node N (besides some other nodes), but S's P-space won't > (it will only contain node F and what is more, if node F does not > exist, then S's P-space would be empty), therefore no intersection > of the two spaces will exist, leaving this network vulnerable to > the failure of link (s,e). > > This results that a neighbor should be always reached by the > neighboring link, even if there exists a shorter, but definitely > bigger in hop-count path to it. > According to this case (when seeking simple LFA is missed), the > condition of extended P-space described by our distance functions, > should be modified a bit: > For source /s/, destination /d/, and next-hop /e/, some node /n != > s,d/ is an extended link-protecting remote LFA for the /s-d/ pair > if and only if > /∃v //∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, > n) *&& dist(s,v) < dist(s,e) + dist(e,v)*/ > /dist(n, d) < dist(n, s) + dist(s, d) . / > > One can easily observe that emphasizing more that remote LFA > seeking process is only "executed" after no simple LFA is found > could much more ease the understanding and won't result a headache > to the reader who accidentally wants to calculate rLFA coverage in > such network. > > Please let me know, if my interpretation is not correct. > Thanks. > > Best, > Levente > > --------------060903000409090208090406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit See comments inline.
On 08/02/2013 10:10 AM, Gábor Sándor Enyedi wrote:

Nice. However, I’m a bit confused, because topologies with uniform link costs should have 100% link failure coverage (if they are 2-connected), shouldn’t they? Isn’t Abilene and Arnes 2-connected?

Yepp, they are not 2-connected
Abilene: http://www.ots.utsystem.edu/pubs/internet2/graphics/abilenebackbone.gif
Arnes: http://www.xipi.eu/InfinityImages/images/2263/arnes.png

 

Other: did you noticed that with some minimal extra computation,

it is possible to reach 100% node protection with rLFA, if we suppose that all the nodes do rLFA in the network.

I'm a  bit confused:  why do we suppose that not all nodes do rLFA?

Maybe we could assign a single extra label/IP address to say that “use uniform link costs for this packet”, and get something quite similar to MRT? :)

 

Gabor

 

From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Friday, August 02, 2013 10:01 AM
To: Gábor Sándor Enyedi
Cc: stbryant@cisco.com; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org
Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions

 

These are bidirectional results.

Levente

On 08/02/2013 09:59 AM, Gábor Sándor Enyedi wrote:

Are these the single or the bidirectional coverage results?

 

Gabor

 

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Levente Csikor
Sent: Friday, August 02, 2013 8:25 AM
To: stbryant@cisco.com
Cc: draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org
Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions

 

Dear All,
I'm sending my previous mail again since the font for the ASCII art network was not fixed and may not appear in a right format at everyone.

If it still messy, let me know.

Sorry,
Levente


Dear All,
since our previous works in remote LFA analysis (papers already sent to these mailing lists) assumed unit cost networks, therefore as I promised, I calculated the corresponding LFA and rLFA coverages in those networks with their original link costs.
These networks were inferred from Rocketfuel dataset (Mahajan, R., Spring, N., Wetherall, D., Anderson, T.:
Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 231–236 (2002)), SNDLib (http://sndlib.zib.de), and TopologyZoo(http://www.topology-zoo.org). The found coverages and some details are found in the table below, where n and m denote the number of nodes and the number of links, respectively. The other columns mark the different coverages obrtained by simple LFA and remote LFA, where LP indicates the link-protecting case, while NP notes the case of node protection.
Topologies marked with an asterisk(*) did not have inferred real link costs from the datasets, so their costs were initially set to 1 (unit costs).

I believe that these results computed on real-world networks could significantly improve the rlfa draft, especially Sec. 9.3., and the advantages of remote LFA over simple LFA would be more emphasized.


+==============+====+====+==========+===========+============+============+
| Topology     | n  | m  | LFA_LP   | LFA_NP    |  rLFA_LP   |  rLFA_NP   |
+==============+====+====+==========+===========+============+============+
| AS1221       | 7  | 9  | 0.809    |   0.25    |   0.809    |    0.25    |
+--------------+----+----+----------+-----------+------------+------------+
| AS1239       | 30 | 69 | 0.8735   |  0.7554   |     1      |   0.9795   |
+--------------+----+----+----------+-----------+------------+------------+
| AS1755       | 18 | 33 | 0.8725   |  0.7741   |   0.9967   |   0.9959   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3257       | 27 | 64 | 0.923    |  0.7186   |   0.99     |   0.8472   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3967       | 21 | 36 | 0.7857   |  0.6460   |     1      |   0.9325   |
+--------------+----+----+----------+-----------+------------+------------+
| AS6461       | 17 | 37 | 0.9338   |  0.6933   |   0.9963   |   0.7075   |
+--------------+----+----+----------+-----------+------------+------------+
| Abilene*     | 12 | 15 | 0.5606   |  0.6078   |   0.9090   |   0.8725   |
+--------------+----+----+----------+-----------+------------+------------+
| Arnes*       | 41 | 57 | 0.6225   |  0.3518   |   0.7487   |   0.4562   |
+--------------+----+----+----------+-----------+------------+------------+
| AT&T         | 22 | 38 | 0.8225   |  0.5647   |     1      |   0.8497   |
+--------------+----+----+----------+-----------+------------+------------+
| Deltacom     | 113| 161| 0.5771   |  0.4910   |   0.8539   |   0.8148   |
+--------------+----+----+----------+-----------+------------+------------+
| Gambia       | 28 | 28 | 0.037    |   0.04    |   0.1851   |     0.12   |
+--------------+----+----+----------+-----------+------------+------------+
| Geant        | 37 | 55 | 0.6906   |  0.3977   |   0.8303   |   0.6582   |
+--------------+----+----+----------+-----------+------------+------------+
| Germ_50      | 50 | 88 | 0.9004   |  0.8381   |     1      |   0.9995   |
+--------------+----+----+----------+-----------+------------+------------+
| Germany*     | 27 | 32 | 0.6948   |  0.599    |     1      |   0.9549   |
+--------------+----+----+----------+-----------+------------+------------+
| InternetMCI  | 19 | 33 | 0.9035   |  0.6798   |   0.9415   |   0.9136   |
+--------------+----+----+----------+-----------+------------+------------+
| Italy*       | 33 | 56 | 0.784    |  0.5741   |     1      |   0.9269   |
+--------------+----+----+----------+-----------+------------+------------+
| NSF*         | 26 | 43 | 0.86     |  0.6347   |     1      |     1      |
+--------------+----+----+----------+-----------+------------+------------+


Furthermore, after reading the draft again-and-again, I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found. This is important, since normally people obviously think and observe that the failure coverage of remote LFA should be greater than or equal to the coverage obtained by simple LFA. Moreover, people also think that LFAs produce a subset of remote LFAs. However, if after a failure only P-spaces and Q-spaces are taken into account in order to seek a (remote) loop-free alternate, then it is possible that a simple LFA would not be found resulting unprotected node-pairs. But, this case could only happen when link costs are not unit costs. For an easier understanding, consider the network depicted below:
            1              1
          F--------S-----------X--------E
           \      /                      \
         10 \    / 4                      \  1
             \  /        1                 \
              N ---------------------------C
              |                            |
           1  |                            |  1
              |                            |
              |      1             1       |
              A--------------B-------------D

Assume that S wishes to send a packet to D, and the shortest path goes through E, therefore it is S-E-C-D. Suppose that the link (s,e)
fails, or even the node e itself fails. In this case, since LFA (and its calculation) only consider all other neighbors of s, then node N would be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D).
However, if we only seek possible remote LFAs, than according to the (r)SPF calculations, or taking into account our distance-function conditions will result that D's Q-space will contain node N (besides some other nodes), but S's P-space won't (it will only contain node F and what is more, if node F does not exist, then S's P-space would be empty), therefore no intersection of the two spaces will exist, leaving this network vulnerable to the failure of link (s,e).

This results that a neighbor should be always reached by the neighboring link, even if there exists a shorter, but definitely bigger in hop-count path to it.
According to this case (when seeking simple LFA is missed), the condition of extended P-space described by our distance functions, should be modified a bit:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)  && dist(s,v) < dist(s,e) + dist(e,v)
dist(n, d) < dist(n, s) + dist(s, d) .

One can easily observe that emphasizing more that remote LFA seeking process is only "executed" after no simple LFA is found could much more ease the understanding and won't result a headache to the reader who accidentally wants to calculate rLFA coverage in such network.

Please let me know, if my interpretation is not correct.
Thanks.

Best,
Levente


 


--------------060903000409090208090406-- From gabor.sandor.enyedi@ericsson.com Fri Aug 2 01:42:41 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D01511E82B9 for ; Fri, 2 Aug 2013 01:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.436 X-Spam-Level: X-Spam-Status: No, score=-4.436 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYEN2Ase5OeT for ; Fri, 2 Aug 2013 01:42:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2B21E830A for ; Fri, 2 Aug 2013 01:36:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-da-51fb6f9246b5 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 34.77.00725.29F6BF15; Fri, 2 Aug 2013 10:36:34 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.48]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 10:36:34 +0200 From: =?utf-8?B?R8OhYm9yIFPDoW5kb3IgRW55ZWRp?= To: Levente Csikor Subject: RE: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Topic: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Index: AQHOj1Z5wa1kp5HEfkKSt2gXwoRsH5mBjn6Q///lV4CAACHFYA== Date: Fri, 2 Aug 2013 08:36:33 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> <51FB50BB.90303@tmit.bme.hu> <51FB673E.9020905@tmit.bme.hu> <51FB6D43.4060106@tmit.bme.hu> In-Reply-To: <51FB6D43.4060106@tmit.bme.hu> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C6B5ESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvre6k/N+BBqtPmFv82f2Z0WL5ghuM FjcPzmSyuPDmN7PFuadzGB1YPab83sjqsWTJTyaPZc/msXp8ufyZLYAlissmJTUnsyy1SN8u gSvjcustloIL85krVu9YwNLA+GIKcxcjJ4eEgInEx9b3jBC2mMSFe+vZuhi5OIQEDjNKLJ/w lhXCWcQo8ffHVrAqNoFgifufbrOD2CIC6hKdbz6zgdjMAu8YJb6cEQGxhQWiJFr2n2SFqImW 6Fx6kRnCdpLY33wVbA6LgApQ+UGwObwCvhLzJvSxQyybyCyx5vhkFpAEp4C2xLofi4FsDg5G AVmJh2stIHaJS9x6Mp8J4moBiSV7zkN9Iyrx8vE/VghbSeLHhkssEPX5Ej87rzFB7BKUODnz CcsERtFZSEbNQlI2C0nZLKDNzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0VI3tuYmZO ernhJkZgJB7c8lt3B+OpcyKHGKU5WJTEeTfpnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wKgeLHvunA7jbQ37y8cPtP1KZWM4vHaidI6aQk1f8YXw/xc18mbodndKCt2yfyGmekl4wv/P V/l/bv8fM2HHip07lszadv/7ib6yS9knr4lkll08eOFxrVKnoZ/yhKfnXhzZ5zJJf8LTk4c7 eYJ1l51Mn6jR/5jj+A37rIOcImkXNfcdYKjSVPytxFKckWioxVxUnAgAqUhahJICAAA= X-Mailman-Approved-At: Fri, 02 Aug 2013 02:33:45 -0700 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:42:41 -0000 --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C6B5ESESSMB307erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcWWVwcCwgdGhleSBhcmUgbm90IDItY29ubmVjdGVk4oCdDQoNCklmIHRoZXkgYXJlIG5vdCAy LWNvbm5lY3RlZCwgaXNu4oCZdCBpdCB1bmZhaXIgdG8gd3JpdGUgb25seSB0aGUgY292ZXJhZ2Ug dGhlcmU/IEkgbWVhbiBpdCB3b3VsZCBiZSBuaWNlIHRvIHB1dCB0aGVyZSB0aGUgbWF4aW11bSBw b3NzaWJsZSBjb3ZlcmFnZSB0b28sIHRoYXQgd2hhdCBlLmcuIE1SVCBjYW4gcmVhY2guDQoNCuKA nEknbSBhICBiaXQgY29uZnVzZWQ6ICB3aHkgZG8gd2Ugc3VwcG9zZSB0aGF0IG5vdCBhbGwgbm9k ZXMgZG8gckxGQT/igJ0NCg0KWW91IG1heSBoYXZlIHNvbWUgbGVnYWN5IG5vZGVzIGluIHJlYWwg bmV0d29ya3MuDQoNCkdhYm9yDQoNCkZyb206IExldmVudGUgQ3Npa29yIFttYWlsdG86Y3Npa29y QHRtaXQuYm1lLmh1XQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMDIsIDIwMTMgMTA6MjcgQU0NClRv OiBHw6Fib3IgU8OhbmRvciBFbnllZGkNCkNjOiBzdGJyeWFudEBjaXNjby5jb207IGRyYWZ0LWll dGYtcnRnd2ctcmVtb3RlLWxmYUB0b29scy5pZXRmLm9yZzsgcnRnd2ctY2hhaXJzQHRvb2xzLmll dGYub3JnOyBydGd3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtcnRnd2ctcmVt b3RlLWxmYSAtIHJlYWR5IGZvciBXR0xDPyAtIHNvbWUgY29tbWVudHMgYW5kIHF1ZXN0aW9ucw0K DQpTZWUgY29tbWVudHMgaW5saW5lLg0KT24gMDgvMDIvMjAxMyAxMDoxMCBBTSwgR8OhYm9yIFPD oW5kb3IgRW55ZWRpIHdyb3RlOg0KTmljZS4gSG93ZXZlciwgSeKAmW0gYSBiaXQgY29uZnVzZWQs IGJlY2F1c2UgdG9wb2xvZ2llcyB3aXRoIHVuaWZvcm0gbGluayBjb3N0cyBzaG91bGQgaGF2ZSAx MDAlIGxpbmsgZmFpbHVyZSBjb3ZlcmFnZSAoaWYgdGhleSBhcmUgMi1jb25uZWN0ZWQpLCBzaG91 bGRu4oCZdCB0aGV5PyBJc27igJl0IEFiaWxlbmUgYW5kIEFybmVzIDItY29ubmVjdGVkPw0KWWVw cCwgdGhleSBhcmUgbm90IDItY29ubmVjdGVkDQpBYmlsZW5lOiBodHRwOi8vd3d3Lm90cy51dHN5 c3RlbS5lZHUvcHVicy9pbnRlcm5ldDIvZ3JhcGhpY3MvYWJpbGVuZWJhY2tib25lLmdpZg0KQXJu ZXM6IGh0dHA6Ly93d3cueGlwaS5ldS9JbmZpbml0eUltYWdlcy9pbWFnZXMvMjI2My9hcm5lcy5w bmcNCg0KDQoNCk90aGVyOiBkaWQgeW91IG5vdGljZWQgdGhhdCB3aXRoIHNvbWUgbWluaW1hbCBl eHRyYSBjb21wdXRhdGlvbiwNCml0IGlzIHBvc3NpYmxlIHRvIHJlYWNoIDEwMCUgbm9kZSBwcm90 ZWN0aW9uIHdpdGggckxGQSwgaWYgd2Ugc3VwcG9zZSB0aGF0IGFsbCB0aGUgbm9kZXMgZG8gckxG QSBpbiB0aGUgbmV0d29yay4NCkknbSBhICBiaXQgY29uZnVzZWQ6ICB3aHkgZG8gd2Ugc3VwcG9z ZSB0aGF0IG5vdCBhbGwgbm9kZXMgZG8gckxGQT8NCg0KDQpNYXliZSB3ZSBjb3VsZCBhc3NpZ24g YSBzaW5nbGUgZXh0cmEgbGFiZWwvSVAgYWRkcmVzcyB0byBzYXkgdGhhdCDigJx1c2UgdW5pZm9y bSBsaW5rIGNvc3RzIGZvciB0aGlzIHBhY2tldOKAnSwgYW5kIGdldCBzb21ldGhpbmcgcXVpdGUg c2ltaWxhciB0byBNUlQ/IDopDQoNCkdhYm9yDQoNCkZyb206IExldmVudGUgQ3Npa29yIFttYWls dG86Y3Npa29yQHRtaXQuYm1lLmh1XQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMDIsIDIwMTMgMTA6 MDEgQU0NClRvOiBHw6Fib3IgU8OhbmRvciBFbnllZGkNCkNjOiBzdGJyeWFudEBjaXNjby5jb208 bWFpbHRvOnN0YnJ5YW50QGNpc2NvLmNvbT47IGRyYWZ0LWlldGYtcnRnd2ctcmVtb3RlLWxmYUB0 b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhQHRvb2xzLmll dGYub3JnPjsgcnRnd2ctY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpydGd3Zy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+OyBydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhIC0gcmVhZHkgZm9yIFdHTEM/ IC0gc29tZSBjb21tZW50cyBhbmQgcXVlc3Rpb25zDQoNClRoZXNlIGFyZSBiaWRpcmVjdGlvbmFs IHJlc3VsdHMuDQoNCkxldmVudGUNCk9uIDA4LzAyLzIwMTMgMDk6NTkgQU0sIEfDoWJvciBTw6Fu ZG9yIEVueWVkaSB3cm90ZToNCkFyZSB0aGVzZSB0aGUgc2luZ2xlIG9yIHRoZSBiaWRpcmVjdGlv bmFsIGNvdmVyYWdlIHJlc3VsdHM/DQoNCkdhYm9yDQoNCkZyb206IHJ0Z3dnLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cnRnd2ctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExldmVudGUgQ3Npa29yDQpTZW50OiBGcmlkYXksIEF1 Z3VzdCAwMiwgMjAxMyA4OjI1IEFNDQpUbzogc3RicnlhbnRAY2lzY28uY29tPG1haWx0bzpzdGJy eWFudEBjaXNjby5jb20+DQpDYzogZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhQHRvb2xzLmll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmFAdG9vbHMuaWV0Zi5vcmc+ OyBydGd3Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWNoYWlyc0B0b29scy5p ZXRmLm9yZz47IHJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmEgLSByZWFkeSBmb3IgV0dMQz8gLSBzb21l IGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMNCg0KRGVhciBBbGwsDQpJJ20gc2VuZGluZyBteSBwcmV2 aW91cyBtYWlsIGFnYWluIHNpbmNlIHRoZSBmb250IGZvciB0aGUgQVNDSUkgYXJ0IG5ldHdvcmsg d2FzIG5vdCBmaXhlZCBhbmQgbWF5IG5vdCBhcHBlYXIgaW4gYSByaWdodCBmb3JtYXQgYXQgZXZl cnlvbmUuDQoNCklmIGl0IHN0aWxsIG1lc3N5LCBsZXQgbWUga25vdy4NCg0KU29ycnksDQpMZXZl bnRlDQoNCg0KRGVhciBBbGwsDQpzaW5jZSBvdXIgcHJldmlvdXMgd29ya3MgaW4gcmVtb3RlIExG QSBhbmFseXNpcyAocGFwZXJzIGFscmVhZHkgc2VudCB0byB0aGVzZSBtYWlsaW5nIGxpc3RzKSBh c3N1bWVkIHVuaXQgY29zdCBuZXR3b3JrcywgdGhlcmVmb3JlIGFzIEkgcHJvbWlzZWQsIEkgY2Fs Y3VsYXRlZCB0aGUgY29ycmVzcG9uZGluZyBMRkEgYW5kIHJMRkEgY292ZXJhZ2VzIGluIHRob3Nl IG5ldHdvcmtzIHdpdGggdGhlaXIgb3JpZ2luYWwgbGluayBjb3N0cy4NClRoZXNlIG5ldHdvcmtz IHdlcmUgaW5mZXJyZWQgZnJvbSBSb2NrZXRmdWVsIGRhdGFzZXQgKE1haGFqYW4sIFIuLCBTcHJp bmcsIE4uLCBXZXRoZXJhbGwsIEQuLCBBbmRlcnNvbiwgVC46DQpJbmZlcnJpbmcgbGluayB3ZWln aHRzIHVzaW5nIGVuZC10by1lbmQgbWVhc3VyZW1lbnRzLiBJbjogQUNNIElNQywgcHAuIDIzMeKA kzIzNiAoMjAwMikpLCBTTkRMaWIgKGh0dHA6Ly9zbmRsaWIuemliLmRlKSwgYW5kIFRvcG9sb2d5 Wm9vKGh0dHA6Ly93d3cudG9wb2xvZ3ktem9vLm9yZykuIFRoZSBmb3VuZCBjb3ZlcmFnZXMgYW5k IHNvbWUgZGV0YWlscyBhcmUgZm91bmQgaW4gdGhlIHRhYmxlIGJlbG93LCB3aGVyZSBuIGFuZCBt IGRlbm90ZSB0aGUgbnVtYmVyIG9mIG5vZGVzIGFuZCB0aGUgbnVtYmVyIG9mIGxpbmtzLCByZXNw ZWN0aXZlbHkuIFRoZSBvdGhlciBjb2x1bW5zIG1hcmsgdGhlIGRpZmZlcmVudCBjb3ZlcmFnZXMg b2JydGFpbmVkIGJ5IHNpbXBsZSBMRkEgYW5kIHJlbW90ZSBMRkEsIHdoZXJlIExQIGluZGljYXRl cyB0aGUgbGluay1wcm90ZWN0aW5nIGNhc2UsIHdoaWxlIE5QIG5vdGVzIHRoZSBjYXNlIG9mIG5v ZGUgcHJvdGVjdGlvbi4NClRvcG9sb2dpZXMgbWFya2VkIHdpdGggYW4gYXN0ZXJpc2soKikgZGlk IG5vdCBoYXZlIGluZmVycmVkIHJlYWwgbGluayBjb3N0cyBmcm9tIHRoZSBkYXRhc2V0cywgc28g dGhlaXIgY29zdHMgd2VyZSBpbml0aWFsbHkgc2V0IHRvIDEgKHVuaXQgY29zdHMpLg0KDQpJIGJl bGlldmUgdGhhdCB0aGVzZSByZXN1bHRzIGNvbXB1dGVkIG9uIHJlYWwtd29ybGQgbmV0d29ya3Mg Y291bGQgc2lnbmlmaWNhbnRseSBpbXByb3ZlIHRoZSBybGZhIGRyYWZ0LCBlc3BlY2lhbGx5IFNl Yy4gOS4zLiwgYW5kIHRoZSBhZHZhbnRhZ2VzIG9mIHJlbW90ZSBMRkEgb3ZlciBzaW1wbGUgTEZB IHdvdWxkIGJlIG1vcmUgZW1waGFzaXplZC4NCg0KDQorPT09PT09PT09PT09PT0rPT09PSs9PT09 Kz09PT09PT09PT0rPT09PT09PT09PT0rPT09PT09PT09PT09Kz09PT09PT09PT09PSsNCnwgVG9w b2xvZ3kgICAgIHwgbiAgfCBtICB8IExGQV9MUCAgIHwgTEZBX05QICAgIHwgIHJMRkFfTFAgICB8 ICByTEZBX05QICAgfA0KKz09PT09PT09PT09PT09Kz09PT0rPT09PSs9PT09PT09PT09Kz09PT09 PT09PT09Kz09PT09PT09PT09PSs9PT09PT09PT09PT0rDQp8IEFTMTIyMSAgICAgICB8IDcgIHwg OSAgfCAwLjgwOSAgICB8ICAgMC4yNSAgICB8ICAgMC44MDkgICAgfCAgICAwLjI1ICAgIHwNCist LS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tKw0KfCBBUzEyMzkgICAgICAgfCAzMCB8IDY5IHwgMC44NzM1ICAgfCAg MC43NTU0ICAgfCAgICAgMSAgICAgIHwgICAwLjk3OTUgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0t LSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsN CnwgQVMxNzU1ICAgICAgIHwgMTggfCAzMyB8IDAuODcyNSAgIHwgIDAuNzc0MSAgIHwgICAwLjk5 NjcgICB8ICAgMC45OTU5ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0tLS0tLS0t Ky0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IEFTMzI1NyAgICAgICB8 IDI3IHwgNjQgfCAwLjkyMyAgICB8ICAwLjcxODYgICB8ICAgMC45OSAgICAgfCAgIDAuODQ3MiAg IHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBBUzM5NjcgICAgICAgfCAyMSB8IDM2IHwgMC43ODU3 ICAgfCAgMC42NDYwICAgfCAgICAgMSAgICAgIHwgICAwLjkzMjUgICB8DQorLS0tLS0tLS0tLS0t LS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLSsNCnwgQVM2NDYxICAgICAgIHwgMTcgfCAzNyB8IDAuOTMzOCAgIHwgIDAuNjkzMyAgIHwg ICAwLjk5NjMgICB8ICAgMC43MDc1ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0tLSstLS0t LS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IEFiaWxlbmUq ICAgICB8IDEyIHwgMTUgfCAwLjU2MDYgICB8ICAwLjYwNzggICB8ICAgMC45MDkwICAgfCAgIDAu ODcyNSAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBBcm5lcyogICAgICAgfCA0MSB8IDU3IHwg MC42MjI1ICAgfCAgMC4zNTE4ICAgfCAgIDAuNzQ4NyAgIHwgICAwLjQ1NjIgICB8DQorLS0tLS0t LS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSsNCnwgQVQmVCAgICAgICAgIHwgMjIgfCAzOCB8IDAuODIyNSAgIHwgIDAuNTY0 NyAgIHwgICAgIDEgICAgICB8ICAgMC44NDk3ICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0rLS0t LSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQp8IERl bHRhY29tICAgICB8IDExM3wgMTYxfCAwLjU3NzEgICB8ICAwLjQ5MTAgICB8ICAgMC44NTM5ICAg fCAgIDAuODE0OCAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0tLSstLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBHYW1iaWEgICAgICAgfCAyOCB8 IDI4IHwgMC4wMzcgICAgfCAgIDAuMDQgICAgfCAgIDAuMTg1MSAgIHwgICAgIDAuMTIgICB8DQor LS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLSsNCnwgR2VhbnQgICAgICAgIHwgMzcgfCA1NSB8IDAuNjkwNiAgIHwg IDAuMzk3NyAgIHwgICAwLjgzMDMgICB8ICAgMC42NTgyICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0t LS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0r DQp8IEdlcm1fNTAgICAgICB8IDUwIHwgODggfCAwLjkwMDQgICB8ICAwLjgzODEgICB8ICAgICAx ICAgICAgfCAgIDAuOTk5NSAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0tLS0tLS0t LSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBHZXJtYW55KiAgICAg fCAyNyB8IDMyIHwgMC42OTQ4ICAgfCAgMC41OTkgICAgfCAgICAgMSAgICAgIHwgICAwLjk1NDkg ICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCnwgSW50ZXJuZXRNQ0kgIHwgMTkgfCAzMyB8IDAuOTAz NSAgIHwgIDAuNjc5OCAgIHwgICAwLjk0MTUgICB8ICAgMC45MTM2ICAgfA0KKy0tLS0tLS0tLS0t LS0tKy0tLS0rLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0rDQp8IEl0YWx5KiAgICAgICB8IDMzIHwgNTYgfCAwLjc4NCAgICB8ICAwLjU3NDEgICB8 ICAgICAxICAgICAgfCAgIDAuOTI2OSAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tKy0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KfCBOU0YqICAg ICAgICAgfCAyNiB8IDQzIHwgMC44NiAgICAgfCAgMC42MzQ3ICAgfCAgICAgMSAgICAgIHwgICAg IDEgICAgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLSstLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KDQpGdXJ0aGVybW9yZSwgYWZ0ZXIgcmVh ZGluZyB0aGUgZHJhZnQgYWdhaW4tYW5kLWFnYWluLCBJIGhhdmUgZm91bmQgdGhhdCBpdCBzaG91 bGQgYmUgbW9yZSBlbXBoYXNpemVkIGluIHRoZSBkcmFmdCB0aGF0IGNhbGN1bGF0aW5nIG9yIHNl ZWtpbmcgZm9yIGEgcmVtb3RlIExGQSBzdGFnaW5nIHBvaW50IHNob3VsZCBiZSBkb25lIElGIEFO RCBPTkxZIElGIG5vIHNpbXBsZSBMRkEgd2VyZSBmb3VuZC4gVGhpcyBpcyBpbXBvcnRhbnQsIHNp bmNlIG5vcm1hbGx5IHBlb3BsZSBvYnZpb3VzbHkgdGhpbmsgYW5kIG9ic2VydmUgdGhhdCB0aGUg ZmFpbHVyZSBjb3ZlcmFnZSBvZiByZW1vdGUgTEZBIHNob3VsZCBiZSBncmVhdGVyIHRoYW4gb3Ig ZXF1YWwgdG8gdGhlIGNvdmVyYWdlIG9idGFpbmVkIGJ5IHNpbXBsZSBMRkEuIE1vcmVvdmVyLCBw ZW9wbGUgYWxzbyB0aGluayB0aGF0IExGQXMgcHJvZHVjZSBhIHN1YnNldCBvZiByZW1vdGUgTEZB cy4gSG93ZXZlciwgaWYgYWZ0ZXIgYSBmYWlsdXJlIG9ubHkgUC1zcGFjZXMgYW5kIFEtc3BhY2Vz IGFyZSB0YWtlbiBpbnRvIGFjY291bnQgaW4gb3JkZXIgdG8gc2VlayBhIChyZW1vdGUpIGxvb3At ZnJlZSBhbHRlcm5hdGUsIHRoZW4gaXQgaXMgcG9zc2libGUgdGhhdCBhIHNpbXBsZSBMRkEgd291 bGQgbm90IGJlIGZvdW5kIHJlc3VsdGluZyB1bnByb3RlY3RlZCBub2RlLXBhaXJzLiBCdXQsIHRo aXMgY2FzZSBjb3VsZCBvbmx5IGhhcHBlbiB3aGVuIGxpbmsgY29zdHMgYXJlIG5vdCB1bml0IGNv c3RzLiBGb3IgYW4gZWFzaWVyIHVuZGVyc3RhbmRpbmcsIGNvbnNpZGVyIHRoZSBuZXR3b3JrIGRl cGljdGVkIGJlbG93Og0KICAgICAgICAgICAgMSAgICAgICAgICAgICAgMQ0KICAgICAgICAgIEYt LS0tLS0tLVMtLS0tLS0tLS0tLVgtLS0tLS0tLUUNCiAgICAgICAgICAgXCAgICAgIC8gICAgICAg ICAgICAgICAgICAgICAgXA0KICAgICAgICAgMTAgXCAgICAvIDQgICAgICAgICAgICAgICAgICAg ICAgXCAgMQ0KICAgICAgICAgICAgIFwgIC8gICAgICAgIDEgICAgICAgICAgICAgICAgIFwNCiAg ICAgICAgICAgICAgTiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1DDQogICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAxICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgIDENCiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgIHwgICAgICAxICAgICAgICAgICAgIDEgICAgICAg fA0KICAgICAgICAgICAgICBBLS0tLS0tLS0tLS0tLS1CLS0tLS0tLS0tLS0tLUQNCg0KQXNzdW1l IHRoYXQgUyB3aXNoZXMgdG8gc2VuZCBhIHBhY2tldCB0byBELCBhbmQgdGhlIHNob3J0ZXN0IHBh dGggZ29lcyB0aHJvdWdoIEUsIHRoZXJlZm9yZSBpdCBpcyBTLUUtQy1ELiBTdXBwb3NlIHRoYXQg dGhlIGxpbmsgKHMsZSkNCmZhaWxzLCBvciBldmVuIHRoZSBub2RlIGUgaXRzZWxmIGZhaWxzLiBJ biB0aGlzIGNhc2UsIHNpbmNlIExGQSAoYW5kIGl0cyBjYWxjdWxhdGlvbikgb25seSBjb25zaWRl ciBhbGwgb3RoZXIgbmVpZ2hib3JzIG9mIHMsIHRoZW4gbm9kZSBOIHdvdWxkIGJlIGFuIGVhc3kg TEZBIGZvciB0aGlzIGZhaWx1cmUsIHNpbmNlIGRpc3QoTixEKSA8IGRpc3QoTixTKStkaXN0KFMs RCkuDQpIb3dldmVyLCBpZiB3ZSBvbmx5IHNlZWsgcG9zc2libGUgcmVtb3RlIExGQXMsIHRoYW4g YWNjb3JkaW5nIHRvIHRoZSAocilTUEYgY2FsY3VsYXRpb25zLCBvciB0YWtpbmcgaW50byBhY2Nv dW50IG91ciBkaXN0YW5jZS1mdW5jdGlvbiBjb25kaXRpb25zIHdpbGwgcmVzdWx0IHRoYXQgRCdz IFEtc3BhY2Ugd2lsbCBjb250YWluIG5vZGUgTiAoYmVzaWRlcyBzb21lIG90aGVyIG5vZGVzKSwg YnV0IFMncyBQLXNwYWNlIHdvbid0IChpdCB3aWxsIG9ubHkgY29udGFpbiBub2RlIEYgYW5kIHdo YXQgaXMgbW9yZSwgaWYgbm9kZSBGIGRvZXMgbm90IGV4aXN0LCB0aGVuIFMncyBQLXNwYWNlIHdv dWxkIGJlIGVtcHR5KSwgdGhlcmVmb3JlIG5vIGludGVyc2VjdGlvbiBvZiB0aGUgdHdvIHNwYWNl cyB3aWxsIGV4aXN0LCBsZWF2aW5nIHRoaXMgbmV0d29yayB2dWxuZXJhYmxlIHRvIHRoZSBmYWls dXJlIG9mIGxpbmsgKHMsZSkuDQoNClRoaXMgcmVzdWx0cyB0aGF0IGEgbmVpZ2hib3Igc2hvdWxk IGJlIGFsd2F5cyByZWFjaGVkIGJ5IHRoZSBuZWlnaGJvcmluZyBsaW5rLCBldmVuIGlmIHRoZXJl IGV4aXN0cyBhIHNob3J0ZXIsIGJ1dCBkZWZpbml0ZWx5IGJpZ2dlciBpbiBob3AtY291bnQgcGF0 aCB0byBpdC4NCkFjY29yZGluZyB0byB0aGlzIGNhc2UgKHdoZW4gc2Vla2luZyBzaW1wbGUgTEZB IGlzIG1pc3NlZCksIHRoZSBjb25kaXRpb24gb2YgZXh0ZW5kZWQgUC1zcGFjZSBkZXNjcmliZWQg Ynkgb3VyIGRpc3RhbmNlIGZ1bmN0aW9ucywgc2hvdWxkIGJlIG1vZGlmaWVkIGEgYml0Og0KRm9y IHNvdXJjZSBzLCBkZXN0aW5hdGlvbiBkLCBhbmQgbmV4dC1ob3AgZSwgc29tZSBub2RlIG4gIT0g cyxkIGlzIGFuIGV4dGVuZGVkIGxpbmstcHJvdGVjdGluZyByZW1vdGUgTEZBIGZvciB0aGUgcy1k IHBhaXIgaWYgYW5kIG9ubHkgaWYNCuKIg3Yg4oiIIG5laWdoKHMpIDogZGlzdCh2LCBuKSA8IGRp c3QodiwgcykgKyBkaXN0KHMsIGUpICsgZGlzdChlLCBuKSAgJiYgZGlzdChzLHYpIDwgZGlzdChz LGUpICsgZGlzdChlLHYpDQpkaXN0KG4sIGQpIDwgZGlzdChuLCBzKSArIGRpc3QocywgZCkgLg0K DQpPbmUgY2FuIGVhc2lseSBvYnNlcnZlIHRoYXQgZW1waGFzaXppbmcgbW9yZSB0aGF0IHJlbW90 ZSBMRkEgc2Vla2luZyBwcm9jZXNzIGlzIG9ubHkgImV4ZWN1dGVkIiBhZnRlciBubyBzaW1wbGUg TEZBIGlzIGZvdW5kIGNvdWxkIG11Y2ggbW9yZSBlYXNlIHRoZSB1bmRlcnN0YW5kaW5nIGFuZCB3 b24ndCByZXN1bHQgYSBoZWFkYWNoZSB0byB0aGUgcmVhZGVyIHdobyBhY2NpZGVudGFsbHkgd2Fu dHMgdG8gY2FsY3VsYXRlIHJMRkEgY292ZXJhZ2UgaW4gc3VjaCBuZXR3b3JrLg0KDQpQbGVhc2Ug bGV0IG1lIGtub3csIGlmIG15IGludGVycHJldGF0aW9uIGlzIG5vdCBjb3JyZWN0Lg0KVGhhbmtz Lg0KDQpCZXN0LA0KTGV2ZW50ZQ0KDQoNCg0KDQoNCg== --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C6B5ESESSMB307erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXcg XCwgc2VyaWYiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnR0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxZZXBwLCB0aGV5IGFyZSBub3QgMi1j b25uZWN0ZWTigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhleSBhcmUgbm90IDItY29u bmVjdGVkLCBpc27igJl0IGl0IHVuZmFpciB0byB3cml0ZSBvbmx5IHRoZSBjb3ZlcmFnZSB0aGVy ZT8gSSBtZWFuIGl0IHdvdWxkIGJlIG5pY2UgdG8gcHV0IHRoZXJlIHRoZSBtYXhpbXVtIHBvc3Np YmxlIGNvdmVyYWdlIHRvbywgdGhhdCB3aGF0IGUuZy4gTVJUIGNhbiByZWFjaC48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnEknbSBhJm5ic3A7IGJp dCBjb25mdXNlZDombmJzcDsgd2h5IGRvIHdlIHN1cHBvc2UgdGhhdCBub3QgYWxsIG5vZGVzIGRv IHJMRkE/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBtYXkgaGF2ZSBzb21lIGxlZ2Fj eSBub2RlcyBpbiByZWFsIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HYWJvciA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBMZXZlbnRlIENz aWtvciBbbWFpbHRvOmNzaWtvckB0bWl0LmJtZS5odV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEF1Z3VzdCAwMiwgMjAxMyAxMDoyNyBBTTxicj4NCjxiPlRvOjwvYj4gR8OhYm9yIFPDoW5k b3IgRW55ZWRpPGJyPg0KPGI+Q2M6PC9iPiBzdGJyeWFudEBjaXNjby5jb207IGRyYWZ0LWlldGYt cnRnd2ctcmVtb3RlLWxmYUB0b29scy5pZXRmLm9yZzsgcnRnd2ctY2hhaXJzQHRvb2xzLmlldGYu b3JnOyBydGd3Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogZHJhZnQtaWV0Zi1y dGd3Zy1yZW1vdGUtbGZhIC0gcmVhZHkgZm9yIFdHTEM/IC0gc29tZSBjb21tZW50cyBhbmQgcXVl c3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ U2VlIGNvbW1lbnRzIGlubGluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gMDgvMDIvMjAxMyAxMDoxMCBBTSwgR8OhYm9yIFPDoW5kb3IgRW55 ZWRpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaWNlLiBIb3dldmVy LCBJ4oCZbSBhIGJpdCBjb25mdXNlZCwgYmVjYXVzZSB0b3BvbG9naWVzIHdpdGggdW5pZm9ybSBs aW5rIGNvc3RzIHNob3VsZCBoYXZlIDEwMCUgbGluayBmYWlsdXJlIGNvdmVyYWdlIChpZiB0aGV5 IGFyZSAyLWNvbm5lY3RlZCksIHNob3VsZG7igJl0IHRoZXk/DQogSXNu4oCZdCBBYmlsZW5lIGFu ZCBBcm5lcyAyLWNvbm5lY3RlZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXBwLCB0aGV5IGFyZSBub3QgMi1jb25uZWN0ZWQ8YnI+ DQpBYmlsZW5lOiA8YSBocmVmPSJodHRwOi8vd3d3Lm90cy51dHN5c3RlbS5lZHUvcHVicy9pbnRl cm5ldDIvZ3JhcGhpY3MvYWJpbGVuZWJhY2tib25lLmdpZiI+DQpodHRwOi8vd3d3Lm90cy51dHN5 c3RlbS5lZHUvcHVicy9pbnRlcm5ldDIvZ3JhcGhpY3MvYWJpbGVuZWJhY2tib25lLmdpZjwvYT48 YnI+DQpBcm5lczogPGEgaHJlZj0iaHR0cDovL3d3dy54aXBpLmV1L0luZmluaXR5SW1hZ2VzL2lt YWdlcy8yMjYzL2FybmVzLnBuZyI+aHR0cDovL3d3dy54aXBpLmV1L0luZmluaXR5SW1hZ2VzL2lt YWdlcy8yMjYzL2FybmVzLnBuZzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3RoZXI6IGRpZCB5 b3Ugbm90aWNlZCB0aGF0IHdpdGggc29tZSBtaW5pbWFsIGV4dHJhIGNvbXB1dGF0aW9uLA0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aXQgaXMgcG9zc2libGUgdG8gcmVhY2ggMTAw JSBub2RlIHByb3RlY3Rpb24gd2l0aCByTEZBLCBpZiB3ZSBzdXBwb3NlIHRoYXQgYWxsIHRoZSBu b2RlcyBkbyByTEZBIGluIHRoZSBuZXR3b3JrLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGEmbmJzcDsgYml0IGNvbmZ1c2Vk OiZuYnNwOyB3aHkgZG8gd2Ugc3VwcG9zZSB0aGF0IG5vdCBhbGwgbm9kZXMgZG8gckxGQT88YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSB3ZSBjb3VsZCBhc3Np Z24gYSBzaW5nbGUgZXh0cmEgbGFiZWwvSVAgYWRkcmVzcyB0byBzYXkgdGhhdCDigJx1c2UgdW5p Zm9ybSBsaW5rIGNvc3RzIGZvciB0aGlzIHBhY2tldOKAnSwgYW5kIGdldCBzb21ldGhpbmcgcXVp dGUgc2ltaWxhciB0byBNUlQ/IDopPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HYWJvcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBMZXZlbnRlIENzaWtvciBbPGEgaHJl Zj0ibWFpbHRvOmNzaWtvckB0bWl0LmJtZS5odSI+bWFpbHRvOmNzaWtvckB0bWl0LmJtZS5odTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMDIsIDIwMTMgMTA6MDEgQU08 YnI+DQo8Yj5Ubzo8L2I+IEfDoWJvciBTw6FuZG9yIEVueWVkaTxicj4NCjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOnN0YnJ5YW50QGNpc2NvLmNvbSI+c3RicnlhbnRAY2lzY28uY29tPC9hPjsg PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2ctcmVtb3RlLWxmYUB0b29scy5pZXRmLm9y ZyI+DQpkcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmFAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86cnRnd2ctY2hhaXJzQHRvb2xzLmlldGYub3JnIj4NCnJ0Z3dnLWNoYWlyc0B0 b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBkcmFmdC1pZXRmLXJ0Z3dnLXJl bW90ZS1sZmEgLSByZWFkeSBmb3IgV0dMQz8gLSBzb21lIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGVzZSBh cmUgYmlkaXJlY3Rpb25hbCByZXN1bHRzLjxicj4NCjxicj4NCkxldmVudGU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDgvMDIvMjAxMyAwOTo1 OSBBTSwgR8OhYm9yIFPDoW5kb3IgRW55ZWRpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BcmUgdGhlc2UgdGhlIHNpbmdsZSBvciB0aGUgYmlkaXJlY3Rpb25hbCBjb3Zl cmFnZSByZXN1bHRzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2Fib3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4NCjxhIGhyZWY9Im1haWx0bzpydGd3Zy1ib3VuY2Vz QGlldGYub3JnIj5ydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnJ0 Z3dnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+TGV2ZW50ZSBDc2lrb3I8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBBdWd1c3QgMDIsIDIwMTMgODoyNSBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnN0YnJ5YW50QGNpc2NvLmNvbSI+c3RicnlhbnRAY2lzY28uY29tPC9hPjxicj4NCjxiPkNj OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2ctcmVtb3RlLWxmYUB0b29scy5p ZXRmLm9yZyI+ZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhQHRvb2xzLmlldGYub3JnPC9hPjsN CjxhIGhyZWY9Im1haWx0bzpydGd3Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPnJ0Z3dnLWNoYWly c0B0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+DQpy dGd3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGRyYWZ0LWlldGYtcnRn d2ctcmVtb3RlLWxmYSAtIHJlYWR5IGZvciBXR0xDPyAtIHNvbWUgY29tbWVudHMgYW5kIHF1ZXN0 aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RGVhciBBbGwsPGJyPg0KSSdtIHNlbmRpbmcgbXkgcHJl dmlvdXMgbWFpbCBhZ2FpbiBzaW5jZSB0aGUgZm9udCBmb3IgdGhlIEFTQ0lJIGFydCBuZXR3b3Jr IHdhcyBub3QgZml4ZWQgYW5kIG1heSBub3QgYXBwZWFyIGluIGEgcmlnaHQgZm9ybWF0IGF0IGV2 ZXJ5b25lLjxicj4NCjxicj4NCklmIGl0IHN0aWxsIG1lc3N5LCBsZXQgbWUga25vdy48YnI+DQo8 YnI+DQpTb3JyeSw8YnI+DQpMZXZlbnRlPGJyPg0KPGJyPg0KPGJyPg0KRGVhciBBbGwsPGJyPg0K c2luY2Ugb3VyIHByZXZpb3VzIHdvcmtzIGluIHJlbW90ZSBMRkEgYW5hbHlzaXMgKHBhcGVycyBh bHJlYWR5IHNlbnQgdG8gdGhlc2UgbWFpbGluZyBsaXN0cykgYXNzdW1lZCB1bml0IGNvc3QgbmV0 d29ya3MsIHRoZXJlZm9yZSBhcyBJIHByb21pc2VkLCBJIGNhbGN1bGF0ZWQgdGhlIGNvcnJlc3Bv bmRpbmcgTEZBIGFuZCByTEZBIGNvdmVyYWdlcyBpbiB0aG9zZSBuZXR3b3JrcyB3aXRoIHRoZWly IG9yaWdpbmFsIGxpbmsgY29zdHMuPGJyPg0KVGhlc2UgbmV0d29ya3Mgd2VyZSBpbmZlcnJlZCBm cm9tIFJvY2tldGZ1ZWwgZGF0YXNldCAoPGk+TWFoYWphbiwgUi4sIFNwcmluZywgTi4sIFdldGhl cmFsbCwgRC4sIEFuZGVyc29uLCBULjo8YnI+DQpJbmZlcnJpbmcgbGluayB3ZWlnaHRzIHVzaW5n IGVuZC10by1lbmQgbWVhc3VyZW1lbnRzLiBJbjogQUNNIElNQywgcHAuIDIzMeKAkzIzNiAoMjAw Mik8L2k+KSwgU05ETGliICg8YSBocmVmPSJodHRwOi8vc25kbGliLnppYi5kZSI+aHR0cDovL3Nu ZGxpYi56aWIuZGU8L2E+KSwgYW5kIFRvcG9sb2d5Wm9vKDxhIGhyZWY9Imh0dHA6Ly93d3cudG9w b2xvZ3ktem9vLm9yZyI+aHR0cDovL3d3dy50b3BvbG9neS16b28ub3JnPC9hPikuIFRoZSBmb3Vu ZCBjb3ZlcmFnZXMNCiBhbmQgc29tZSBkZXRhaWxzIGFyZSBmb3VuZCBpbiB0aGUgdGFibGUgYmVs b3csIHdoZXJlIDxpPm48L2k+IGFuZCA8aT5tPC9pPiBkZW5vdGUgdGhlIG51bWJlciBvZiBub2Rl cyBhbmQgdGhlIG51bWJlciBvZiBsaW5rcywgcmVzcGVjdGl2ZWx5LiBUaGUgb3RoZXIgY29sdW1u cyBtYXJrIHRoZSBkaWZmZXJlbnQgY292ZXJhZ2VzIG9icnRhaW5lZCBieSBzaW1wbGUgTEZBIGFu ZCByZW1vdGUgTEZBLCB3aGVyZSBMUCBpbmRpY2F0ZXMgdGhlIGxpbmstcHJvdGVjdGluZw0KIGNh c2UsIHdoaWxlIE5QIG5vdGVzIHRoZSBjYXNlIG9mIG5vZGUgcHJvdGVjdGlvbi48YnI+DQpUb3Bv bG9naWVzIG1hcmtlZCB3aXRoIGFuIGFzdGVyaXNrKCopIGRpZCBub3QgaGF2ZSBpbmZlcnJlZCBy ZWFsIGxpbmsgY29zdHMgZnJvbSB0aGUgZGF0YXNldHMsIHNvIHRoZWlyIGNvc3RzIHdlcmUgaW5p dGlhbGx5IHNldCB0byAxICh1bml0IGNvc3RzKS48YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhhdCB0 aGVzZSByZXN1bHRzIGNvbXB1dGVkIG9uIHJlYWwtd29ybGQgbmV0d29ya3MgY291bGQgc2lnbmlm aWNhbnRseSBpbXByb3ZlIHRoZSBybGZhIGRyYWZ0LCBlc3BlY2lhbGx5IFNlYy4gOS4zLiwgYW5k IHRoZSBhZHZhbnRhZ2VzIG9mIHJlbW90ZSBMRkEgb3ZlciBzaW1wbGUgTEZBIHdvdWxkIGJlIG1v cmUgZW1waGFzaXplZC48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 YnI+DQo8YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mIzQz Oz09PT09PT09PT09PT09JiM0Mzs9PT09JiM0Mzs9PT09JiM0Mzs9PT09PT09PT09JiM0Mzs9PT09 PT09PT09PSYjNDM7PT09PT09PT09PT09JiM0Mzs9PT09PT09PT09PT0mIzQzOzwvc3Bhbj48L3R0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnwgVG9wb2xvZ3kmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCBuJm5ic3A7IHwgbSZuYnNwOyB8IExGQV9MUCZuYnNwOyZuYnNwOyB8IExGQV9OUCZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHJMRkFfTFAmbmJzcDsmbmJzcDsgfCZuYnNwOyByTEZB X05QJm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m IzQzOz09PT09PT09PT09PT09JiM0Mzs9PT09JiM0Mzs9PT09JiM0Mzs9PT09PT09PT09JiM0Mzs9 PT09PT09PT09PSYjNDM7PT09PT09PT09PT09JiM0Mzs9PT09PT09PT09PT0mIzQzOzwvc3Bhbj48 L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnwgQVMxMjIxJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyB8IDcmbmJzcDsgfCA5Jm5ic3A7IHwgMC44MDkmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyAwLjI1Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC44 MDkmbmJzcDsgJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgMC4yNSZuYnNwOyZuYnNwOyZuYnNw OyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0K PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JiM0MzstLS0tLS0tLS0t LS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij58IEFTMTIzOSAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgMzAg fCA2OSB8IDAuODczNSZuYnNwOyZuYnNwOyB8Jm5ic3A7IDAuNzU1NCZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7 IDAuOTc5NSZuYnNwOyZuYnNwOyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYj NDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3Nw YW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij58IEFTMTc1NSAmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IHwgMTggfCAzMyB8IDAuODcyNSAmbmJzcDsgfCZuYnNwOyAwLjc3NDEmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjk5NjcgJm5ic3A7IHwmbmJzcDsmbmJzcDsgMC45OTU5 ICZuYnNwOyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JiM0MzstLS0t LS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC90dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAs IHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij58IEFTMzI1NyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 IHwgMjcgfCA2NCB8IDAuOTIzJm5ic3A7ICZuYnNwOyB8Jm5ic3A7IDAuNzE4NiZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7IDAuOTkgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODQ3MiAm bmJzcDsgfDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxi cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiYjNDM7LS0tLS0t LS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t JiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBz ZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+fCBBUzM5NjcgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8 IDIxIHwgMzYgfCAwLjc4NTcgJm5ic3A7IHwmbmJzcDsgMC42NDYwICZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTMy NSZuYnNwOyZuYnNwOyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JiM0 MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij58IEFTNjQ2MSAmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7IHwgMTcgfCAzNyB8IDAuOTMzOCZuYnNwOyZuYnNwOyB8Jm5ic3A7IDAuNjkzMyAmbmJz cDsgfCZuYnNwOyZuYnNwOyAwLjk5NjMgJm5ic3A7IHwmbmJzcDsmbmJzcDsgMC43MDc1ICZuYnNw OyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0K PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JiM0MzstLS0tLS0tLS0t LS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij58IEFiaWxlbmUqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMTIg fCAxNSB8IDAuNTYwNiZuYnNwOyZuYnNwOyB8Jm5ic3A7IDAuNjA3OCAmbmJzcDsgfCZuYnNwOyZu YnNwOyAwLjkwOTAgJm5ic3A7IHwmbmJzcDsmbmJzcDsgMC44NzI1ICZuYnNwOyB8PC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0t LSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij58IEFybmVzKiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IHwgNDEgfCA1NyB8IDAuNjIy NSAmbmJzcDsgfCZuYnNwOyAwLjM1MTggJm5ic3A7IHwmbmJzcDsmbmJzcDsgMC43NDg3ICZuYnNw OyB8Jm5ic3A7Jm5ic3A7IDAuNDU2MiAmbmJzcDsgfDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t LSYjNDM7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJy Pg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+fCBBVCZhbXA7VCAm bmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB8IDIyIHwgMzggfCAwLjgyMjUgJm5ic3A7 IHwmbmJzcDsgMC41NjQ3ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7 ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODQ5NyAmbmJzcDsgfDwvc3Bhbj48L3R0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQz Oy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ fCBEZWx0YWNvbSZuYnNwOyAmbmJzcDsmbmJzcDsgfCAxMTN8IDE2MXwgMC41NzcxICZuYnNwOyB8 Jm5ic3A7IDAuNDkxMCAmbmJzcDsgfCZuYnNwOyZuYnNwOyAwLjg1MzkgJm5ic3A7IHwmbmJzcDsm bmJzcDsgMC44MTQ4ICZuYnNwOyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYj NDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3Nw YW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij58IEdhbWJpYSAmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IHwgMjggfCAyOCB8IDAuMDM3ICZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 IDAuMDQgJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC4xODUxICZuYnNwOyB8Jm5ic3A7Jm5i c3A7ICZuYnNwOyAwLjEyICZuYnNwOyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8 L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3Nw YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij58IEdlYW50Jm5ic3A7ICZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsgfCAzNyB8IDU1IHwgMC42OTA2Jm5ic3A7Jm5ic3A7IHwmbmJz cDsgMC4zOTc3ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuODMwMyAmbmJzcDsgfCZuYnNwOyZuYnNw OyAwLjY1ODIgJm5ic3A7IHw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m IzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tJiM0MzstLS0tJiM0MzstLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48 L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnwgR2VybV81MCZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsgfCA1MCB8IDg4IHwgMC45MDA0Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgMC44MzgxICZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7IDAuOTk5NSAmbmJzcDsgfDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7 PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9z cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+fCBHZXJtYW55KiZuYnNwOyAm bmJzcDsmbmJzcDsgfCAyNyB8IDMyIHwgMC42OTQ4ICZuYnNwOyB8Jm5ic3A7IDAuNTk5Jm5ic3A7 ICZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7IDAuOTU0OSAmbmJzcDsgfDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0t LS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYj NDM7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0K PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+fCBJbnRlcm5ldE1DSSZu YnNwOyB8IDE5IHwgMzMgfCAwLjkwMzUgJm5ic3A7IHwmbmJzcDsgMC42Nzk4ICZuYnNwOyB8Jm5i c3A7Jm5ic3A7IDAuOTQxNSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAuOTEzNiAmbmJzcDsg fDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwv c3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiYjNDM7LS0tLS0tLS0tLS0t LS0mIzQzOy0tLS0mIzQzOy0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+fCBJdGFseSogJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyB8IDMzIHwg NTYgfCAwLjc4NCZuYnNwOyAmbmJzcDsgfCZuYnNwOyAwLjU3NDEgJm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMSAmbmJzcDsgJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMC45MjY5 ICZuYnNwOyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JiM0MzstLS0t LS0tLS0tLS0tLSYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC90dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAs IHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij58IE5TRiogJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsgfCAyNiB8IDQzIHwgMC44NiAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgMC42MzQ3ICZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgJm5ic3A7ICZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7ICZuYnNwOyAxICZuYnNwOyAmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3R0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2Vy aWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0mIzQzOy0tLS0m IzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7PC9zcGFuPjwvdHQ+PGJyPg0KPGJyPg0KPGJyPg0KRnVydGhlcm1vcmUsIGFm dGVyIHJlYWRpbmcgdGhlIGRyYWZ0IGFnYWluLWFuZC1hZ2FpbiwgSSBoYXZlIGZvdW5kIHRoYXQg aXQgc2hvdWxkIGJlIG1vcmUgZW1waGFzaXplZCBpbiB0aGUgZHJhZnQgdGhhdCBjYWxjdWxhdGlu ZyBvciBzZWVraW5nIGZvciBhIHJlbW90ZSBMRkEgc3RhZ2luZyBwb2ludCBzaG91bGQgYmUgZG9u ZSBJRiBBTkQgT05MWSBJRiBubyBzaW1wbGUgTEZBIHdlcmUgZm91bmQuIFRoaXMgaXMgaW1wb3J0 YW50LCBzaW5jZSBub3JtYWxseQ0KIHBlb3BsZSBvYnZpb3VzbHkgdGhpbmsgYW5kIG9ic2VydmUg dGhhdCB0aGUgZmFpbHVyZSBjb3ZlcmFnZSBvZiByZW1vdGUgTEZBIHNob3VsZCBiZSBncmVhdGVy IHRoYW4gb3IgZXF1YWwgdG8gdGhlIGNvdmVyYWdlIG9idGFpbmVkIGJ5IHNpbXBsZSBMRkEuIE1v cmVvdmVyLCBwZW9wbGUgYWxzbyB0aGluayB0aGF0IExGQXMgcHJvZHVjZSBhIHN1YnNldCBvZiBy ZW1vdGUgTEZBcy4gSG93ZXZlciwgaWYgYWZ0ZXIgYSBmYWlsdXJlIG9ubHkgUC1zcGFjZXMNCiBh bmQgUS1zcGFjZXMgYXJlIHRha2VuIGludG8gYWNjb3VudCBpbiBvcmRlciB0byBzZWVrIGEgKHJl bW90ZSkgbG9vcC1mcmVlIGFsdGVybmF0ZSwgdGhlbiBpdCBpcyBwb3NzaWJsZSB0aGF0IGEgc2lt cGxlIExGQSB3b3VsZCBub3QgYmUgZm91bmQgcmVzdWx0aW5nIHVucHJvdGVjdGVkIG5vZGUtcGFp cnMuIEJ1dCwgdGhpcyBjYXNlIGNvdWxkIG9ubHkgaGFwcGVuIHdoZW4gbGluayBjb3N0cyBhcmUg bm90IHVuaXQgY29zdHMuIEZvciBhbiBlYXNpZXINCiB1bmRlcnN0YW5kaW5nLCBjb25zaWRlciB0 aGUgbmV0d29yayBkZXBpY3RlZCBiZWxvdzo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDEmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgMTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRi0tLS0t LS0tUy0tLS0tLS0tLS0tWC0tLS0tLS0tRTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyBcPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAxMCBcJm5ic3A7Jm5ic3A7Jm5ic3A7IC8gNCZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsgMTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7IFwm bmJzcDsgLyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSAmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsgXDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi Pjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyAm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUM8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwNCjwvc3Bhbj48L3R0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHwm bmJzcDsgMTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxi cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyB8PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7IDEmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxICZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsgfDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxi cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEEtLS0tLS0tLS0tLS0tLUItLS0tLS0tLS0tLS0tRDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48YnI+DQo8L3NwYW4+PGJyPg0KQXNzdW1lIHRoYXQgUyB3aXNoZXMgdG8gc2VuZCBhIHBh Y2tldCB0byBELCBhbmQgdGhlIHNob3J0ZXN0IHBhdGggZ29lcyB0aHJvdWdoIEUsIHRoZXJlZm9y ZSBpdCBpcyBTLUUtQy1ELiBTdXBwb3NlIHRoYXQgdGhlIGxpbmsgKHMsZSk8YnI+DQpmYWlscywg b3IgZXZlbiB0aGUgbm9kZSBlIGl0c2VsZiBmYWlscy4gSW4gdGhpcyBjYXNlLCBzaW5jZSBMRkEg KGFuZCBpdHMgY2FsY3VsYXRpb24pIG9ubHkgY29uc2lkZXIgYWxsIG90aGVyIG5laWdoYm9ycyBv ZiBzLCB0aGVuIG5vZGUgTiB3b3VsZCBiZSBhbiBlYXN5IExGQSBmb3IgdGhpcyBmYWlsdXJlLCBz aW5jZSBkaXN0KE4sRCkgJmx0OyBkaXN0KE4sUykmIzQzO2Rpc3QoUyxEKS48YnI+DQpIb3dldmVy LCBpZiB3ZSBvbmx5IHNlZWsgcG9zc2libGUgcmVtb3RlIExGQXMsIHRoYW4gYWNjb3JkaW5nIHRv IHRoZSAocilTUEYgY2FsY3VsYXRpb25zLCBvciB0YWtpbmcgaW50byBhY2NvdW50IG91ciBkaXN0 YW5jZS1mdW5jdGlvbiBjb25kaXRpb25zIHdpbGwgcmVzdWx0IHRoYXQgRCdzIFEtc3BhY2Ugd2ls bCBjb250YWluIG5vZGUgTiAoYmVzaWRlcyBzb21lIG90aGVyIG5vZGVzKSwgYnV0IFMncyBQLXNw YWNlIHdvbid0IChpdCB3aWxsIG9ubHkNCiBjb250YWluIG5vZGUgRiBhbmQgd2hhdCBpcyBtb3Jl LCBpZiBub2RlIEYgZG9lcyBub3QgZXhpc3QsIHRoZW4gUydzIFAtc3BhY2Ugd291bGQgYmUgZW1w dHkpLCB0aGVyZWZvcmUgbm8gaW50ZXJzZWN0aW9uIG9mIHRoZSB0d28gc3BhY2VzIHdpbGwgZXhp c3QsIGxlYXZpbmcgdGhpcyBuZXR3b3JrIHZ1bG5lcmFibGUgdG8gdGhlIGZhaWx1cmUgb2YgbGlu ayAocyxlKS48YnI+DQo8YnI+DQpUaGlzIHJlc3VsdHMgdGhhdCBhIG5laWdoYm9yIHNob3VsZCBi ZSBhbHdheXMgcmVhY2hlZCBieSB0aGUgbmVpZ2hib3JpbmcgbGluaywgZXZlbiBpZiB0aGVyZSBl eGlzdHMgYSBzaG9ydGVyLCBidXQgZGVmaW5pdGVseSBiaWdnZXIgaW4gaG9wLWNvdW50IHBhdGgg dG8gaXQuPGJyPg0KQWNjb3JkaW5nIHRvIHRoaXMgY2FzZSAod2hlbiBzZWVraW5nIHNpbXBsZSBM RkEgaXMgbWlzc2VkKSwgdGhlIGNvbmRpdGlvbiBvZiBleHRlbmRlZCBQLXNwYWNlIGRlc2NyaWJl ZCBieSBvdXIgZGlzdGFuY2UgZnVuY3Rpb25zLCBzaG91bGQgYmUgbW9kaWZpZWQgYSBiaXQ6PGJy Pg0KRm9yIHNvdXJjZSA8aT5zPC9pPiwgZGVzdGluYXRpb24gPGk+ZDwvaT4sIGFuZCBuZXh0LWhv cCA8aT5lPC9pPiwgc29tZSBub2RlIDxpPm4gIT0gcyxkPC9pPiBpcyBhbiBleHRlbmRlZCBsaW5r LXByb3RlY3RpbmcgcmVtb3RlIExGQSBmb3IgdGhlDQo8aT5zLWQ8L2k+IHBhaXIgaWYgYW5kIG9u bHkgaWY8YnI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSBNYXRo JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7iiIM8L3NwYW4+diA8L2k+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ 4oiIPC9zcGFuPiBuZWlnaChzKSA6IGRpc3QodiwgbikgJmx0OyBkaXN0KHYsIHMpICYjNDM7IGRp c3QocywgZSkgJiM0MzsgZGlzdChlLCBuKSZuYnNwOw0KPGI+JmFtcDsmYW1wOyBkaXN0KHMsdikg Jmx0OyBkaXN0KHMsZSkgJiM0MzsgZGlzdChlLHYpPC9iPjwvaT48YnI+DQo8aT5kaXN0KG4sIGQp ICZsdDsgZGlzdChuLCBzKSAmIzQzOyBkaXN0KHMsIGQpIC4gPC9pPjxicj4NCjxicj4NCk9uZSBj YW4gZWFzaWx5IG9ic2VydmUgdGhhdCBlbXBoYXNpemluZyBtb3JlIHRoYXQgcmVtb3RlIExGQSBz ZWVraW5nIHByb2Nlc3MgaXMgb25seSAmcXVvdDtleGVjdXRlZCZxdW90OyBhZnRlciBubyBzaW1w bGUgTEZBIGlzIGZvdW5kIGNvdWxkIG11Y2ggbW9yZSBlYXNlIHRoZSB1bmRlcnN0YW5kaW5nIGFu ZCB3b24ndCByZXN1bHQgYSBoZWFkYWNoZSB0byB0aGUgcmVhZGVyIHdobyBhY2NpZGVudGFsbHkg d2FudHMgdG8gY2FsY3VsYXRlIHJMRkEgY292ZXJhZ2UgaW4NCiBzdWNoIG5ldHdvcmsuPGJyPg0K PGJyPg0KUGxlYXNlIGxldCBtZSBrbm93LCBpZiBteSBpbnRlcnByZXRhdGlvbiBpcyBub3QgY29y cmVjdC48YnI+DQpUaGFua3MuPGJyPg0KPGJyPg0KQmVzdCw8YnI+DQpMZXZlbnRlPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F1429C3E9C264E4EAEB43B5422D0D5D11161C6B5ESESSMB307erics_-- From csikor@tmit.bme.hu Fri Aug 2 05:06:28 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D2F11E82BE for ; Fri, 2 Aug 2013 05:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.386 X-Spam-Level: *** X-Spam-Status: No, score=3.386 tagged_above=-999 required=5 tests=[AWL=-1.674, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY9kVy7jZcpq for ; Fri, 2 Aug 2013 05:06:24 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE8811E834A for ; Fri, 2 Aug 2013 05:06:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 7BBCF87350; Fri, 2 Aug 2013 14:06:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-EmHgJN+aVn; Fri, 2 Aug 2013 14:05:53 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id B78E287346; Fri, 2 Aug 2013 14:05:52 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r72C60q7019700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 14:06:00 +0200 Message-ID: <51FBA0A5.1050603@tmit.bme.hu> Date: Fri, 02 Aug 2013 14:05:57 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stephane.litkowski@orange.com Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <94A203EA12AECE4BA92D42DBFFE0AE47189620@eusaamb101.ericsson.se> <51CAE915.4020304@tmit.bme.hu> <51D308D0.5090707@cisco.com> <51FA6C6A.4090200@tmit.bme.hu> <23321_1375431220_51FB6A34_23321_1107_9_EEE55384044474429A926C625D0FCC81095908C18E@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <23321_1375431220_51FB6A34_23321_1107_9_EEE55384044474429A926C625D0FCC81095908C18E@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------000200010006030007040007" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 12:06:28 -0000 This is a multi-part message in MIME format. --------------000200010006030007040007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear Stephane, see comments inline. On 08/02/2013 10:13 AM, stephane.litkowski@orange.com wrote: > Hi, > Correct me if I don't understand correctly what you meant. > "I have found that it should be more emphasized in the draft that > calculating or seeking for a remote LFA staging point should be done > IF AND ONLY IF no simple LFA were found." > This is how the draft is written today : > §3.1 : > "If there > is no such LFA neighbor, then S may be able to create a virtual LFA > by using a tunnel to carry the packet to a point in the network which > is not a direct neighbor of S from which the packet will be delivered > to the destination without looping back to S." > §4.1 : > "Not all links will require protection using a tunneled repair path. > Referring to Figure 1, if E can already be protected via an LFA, S-E > does not need to be protected using a repair tunnel, since all > destinations normally reachable through E must therefore also be > protectable by an LFA. " > The draft also precise that extended P-Space must be used : > "*9.1* > *. > Simplicity* > > The remote LFA algorithm is simple to compute. > > o The extended P space does not require any new computation (it is > known once per-prefix LFA computation is completed). > " Yes, you have right that in most of the cases it is emphasized, probably somehow I did read a previous version of the draft. However, I'm getting a bit confused about you stated below, which is true :) > In your example, N is part of extended P-Space. So N would be a PQ > (it's a normal LFA also as you stated). in the draft: 4.2.2 . Extended P-space ... "This may be calculated by computing the an SPT at each of S's neighbors (N) (excluding E) and excising the subtree reached via the path N->S->E..." In this case, all the neighbors are always examined regardless to the costs of the neighboring link, therefore the extended P-space will always contain all the neighbors except the failed one. Thus it will always contain the simple LFA if it exists. Am I right? > My comment : > - Yes, extended P-Space usage is mandatory in order to maximize > coverage (for me it's clearly explained in the draft) > - draft currently states that remote LFA would be computed only when > normal LFA is not available BUT this is not a good idea. Based on the > use case we are presenting if draft-ietf-rtgwg-lfa-manageability, > there is a strong interrest in always computing rLFA protection then > be able to compare attributes of PQs and normal LFAs to determine > which one is the more efficient based on service provider > requirements. This does not mean that we don't use extended P Space, > extended P-Space need always to be used. > - You are providing NP coverage for rLFA , thanks for the info, but I > just want to highlight that this is just "informational" as a router > is not able to determine that the PQ is providing NP or not for the > specific destination. Determining such PQ attribute would require > extra SPF, as stated in > *draft*-psarkar-rtgwg-*rlfa*-*node*-*protection*-00 > . Calculating these coverages these coverages required all-pair shortest path computation and then NP and LP rLFAs can be easily determine by distance functions > Best Regards, > Stephane > Thanks for your comments, Levente > > ------------------------------------------------------------------------ > *De :* rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] *De > la part de* Levente Csikor > *Envoyé :* jeudi 1 août 2013 16:11 > *À :* stbryant@cisco.com > *Cc :* draft-ietf-rtgwg-remote-lfa@tools.ietf.org; > rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org > *Objet :* Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some > comments and questions > > Dear All, > since our previous works in remote LFA analysis (papers already > sent to these mailing lists) assumed unit cost networks, therefore > as I promised, I calculated the corresponding LFA and rLFA > coverages in those networks with their original link costs. > These networks were inferred from Rocketfuel dataset (/Mahajan, > R., Spring, N., Wetherall, D., Anderson, T.:// > //Inferring link weights using end-to-end measurements. In: ACM > IMC, pp. 231–236 (2002)/), SNDLib (http://sndlib.zib.de), and > TopologyZoo(http://www.topology-zoo.org). The found coverages and > some details are found in the table below, where /n/ and /m/ > denote the number of nodes and the number of links, respectively. > The other columns mark the different coverages obrtained by simple > LFA and remote LFA, where LP indicates the link-protecting case, > while NP notes the case of node protection. > Topologies marked with an asterisk(*) did not have inferred real > link costs from the datasets, so their costs were initially set to > 1 (unit costs). > > I believe that these results computed on real-world networks could > significantly improve the rlfa draft, especially Sec. 9.3., and > the advantages of remote LFA over simple LFA would be more emphasized. > > > +==============+====+====+==========+===========+============+============+ > | Topology | n | m | LFA_LP | LFA_NP | rLFA_LP | > rLFA_NP | > +==============+====+====+==========+===========+============+============+ > | AS1221 | 7 | 9 | 0.809 | 0.25 | 0.809 | 0.25 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1239 | 30 | 69 | 0.8735 | 0.7554 | 1 | > 0.9795 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1755 | 18 | 33 | 0.8725 | 0.7741 | 0.9967 | > 0.9959 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3257 | 27 | 64 | 0.923 | 0.7186 | 0.99 | > 0.8472 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3967 | 21 | 36 | 0.7857 | 0.6460 | 1 | > 0.9325 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS6461 | 17 | 37 | 0.9338 | 0.6933 | 0.9963 | > 0.7075 | > +--------------+----+----+----------+-----------+------------+------------+ > | Abilene* | 12 | 15 | 0.5606 | 0.6078 | 0.9090 | > 0.8725 | > +--------------+----+----+----------+-----------+------------+------------+ > | Arnes* | 41 | 57 | 0.6225 | 0.3518 | 0.7487 | > 0.4562 | > +--------------+----+----+----------+-----------+------------+------------+ > | AT&T | 22 | 38 | 0.8225 | 0.5647 | 1 | 0.8497 | > +--------------+----+----+----------+-----------+------------+------------+ > | Deltacom | 113| 161| 0.5771 | 0.4910 | 0.8539 | > 0.8148 | > +--------------+----+----+----------+-----------+------------+------------+ > | Gambia | 28 | 28 | 0.037 | 0.04 | 0.1851 | > 0.12 | > +--------------+----+----+----------+-----------+------------+------------+ > | Geant | 37 | 55 | 0.6906 | 0.3977 | 0.8303 | > 0.6582 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germ_50 | 50 | 88 | 0.9004 | 0.8381 | 1 | > 0.9995 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germany* | 27 | 32 | 0.6948 | 0.599 | 1 | > 0.9549 | > +--------------+----+----+----------+-----------+------------+------------+ > | InternetMCI | 19 | 33 | 0.9035 | 0.6798 | 0.9415 | > 0.9136 | > +--------------+----+----+----------+-----------+------------+------------+ > | Italy* | 33 | 56 | 0.784 | 0.5741 | 1 | > 0.9269 | > +--------------+----+----+----------+-----------+------------+------------+ > | NSF* | 26 | 43 | 0.86 | 0.6347 | 1 | > 1 | > +--------------+----+----+----------+-----------+------------+------------+ > > > Furthermore, after reading the draft again-and-again, I have found > that it should be more emphasized in the draft that calculating or > seeking for a remote LFA staging point should be done IF AND ONLY > IF no simple LFA were found. This is important, since normally > people obviously think and observe that the failure coverage of > remote LFA should be greater than or equal to the coverage > obtained by simple LFA. Moreover, people also think that LFAs > produce a subset of remote LFAs. However, if after a failure only > P-spaces and Q-spaces are taken into account in order to seek a > (remote) loop-free alternate, then it is possible that a simple > LFA would not be found resulting unprotected node-pairs. But, this > case could only happen when link costs are not unit costs. For an > easier understanding, consider the network depicted below: > 1 1 > F--------S-----------X--------E > \ / \ > 10 \ / 4 \ 1 > \ / 1 \ > N ---------------------------C > | | > 1 | | 1 > | | > | 1 1 | > A--------------B-------------D > > Assume that S wishes to send a packet to D, and the shortest path > goes through E, therefore it is S-E-C-D. Suppose that the link (s,e) > fails, or even the node e itself fails. In this case, since LFA > (and its calculation) only consider all other neighbors of s, then > node N would be an easy LFA for this failure, since dist(N,D) < > dist(N,S)+dist(S,D). > However, if we only seek possible remote LFAs, than according to > the (r)SPF calculations, or taking into account our > distance-function conditions will result that D's Q-space will > contain node N (besides some other nodes), but S's P-space won't > (it will only contain node F and what is more, if node F does not > exist, then S's P-space would be empty), therefore no intersection > of the two spaces will exist, leaving this network vulnerable to > the failure of link (s,e). > > This results that a neighbor should be always reached by the > neighboring link, even if there exists a shorter, but definitely > bigger in hop-count path to it. > According to this case (when seeking simple LFA is missed), the > condition of extended P-space described by our distance functions, > should be modified a bit: > For source /s/, destination /d/, and next-hop /e/, some node /n != > s,d/ is an extended link-protecting remote LFA for the /s-d/ pair > if and only if > /∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, > n)//*&& dist(s,v) < dist(s,e) + dist(e**,v)*/ > /dist(n, d) < dist(n, s) + dist(s, d) . / > > One can easily observe that emphasizing more that remote LFA > seeking process is only "executed" after no simple LFA is found > could much more ease the understanding and won't result a headache > to the reader who accidentally wants to calculate rLFA coverage in > such network. > > Please let me know, if my interpretation is not correct. > Thanks. > > Best, > Levente > > On 07/02/2013 07:07 PM, Stewart Bryant wrote: >> On 26/06/2013 14:13, Levente Csikor wrote: >> >> Levente >> >> In each case below the conditions are surely fulfilled if n=e >> thus I think that in each case the condition needs to be >> changed to : >> >> some node n!={s or e} >>> In order to not to read our full papers and searching the >>> answers, I copied here the relevant parts: >>> *Link-protecting rLFA condition:* >>> For source /s/, destination /d/, and next-hop /e/, some node /n/ >>> /!= s,d/ is a link-protecting remote LFA for the /s-d/ pair if >>> and only if >>> /dist(s, n) < dist(s, e) + dist(e, n)/ (1) >>> /dist(n, d) < dist(n, s) + dist(s, d)/ (2) >>> In these equations, one can easily see, that (1) defines the >>> P-space, while (2) is the condition of Q-space. Furthermore, >>> with these formalized conditions, one can easily observe, that >>> (2) is actually the basic loop-free criterion of pure LFA. >>> >>> *Link-protecting rLFA condition with extended P-space:* >>> For source /s/, destination /d/, and next-hop /e/, some node /n >>> != s,d/ is an extended link-protecting remote LFA for the /s-d/ >>> pair if and only if >>> /∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, >>> n)/// >>> /dist(n, d) < dist(n, s) + dist(s, d) . / >>> >>> *Node-protecting rLFA condition:* >>> For source /s/, destination /d/, and next-hop /e/, some /n != >>> s,d/ is a node-protecting remote LFA for the /s-d/ pair if and >>> only if >>> /dist(s,n) < dist(s,e) + dist(e,n)/// (3) >>> /dist(n,d) < dist(n,e) + dist(e,d) / (4) >>> As it was in the case of link protection, here, (3) defines the >>> P-space, while (4) characterize the Q-space. >>> Here, two important observations can be made, which are the >>> followings: >>> - P-space does not depend on the protection scheme (i.e., link >>> or node protection) >> SB> That falls directly out of the definition of P-space >> SB> since in link you cannot traverse the link to e and in >> SB> node only get to e if you traverse the link to e >> SB> thus the exclusion of the link to e applies in both cases >>> - (4) again is the basic node-protecting loop-free criterion of >>> pure LFA. >>> >>> *Node-protecting rLFA condition with extended P-space:* >>> For source /s/, destination /d/, and next-hop /e/, some node /n >>> != s,d/ is an extended node-protecting remote LFA for the /s-d/ >>> pair if and only if >>> /∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)/ >>> /dist(n, d) < dist(n, e) + dist(e, d) ./ >>> >>> Despite the fact that we only considered unit cost networks, the >>> formal definitions above are *true for any arbitrary weighted >>> network.* >> SB> I do not see where the unit costs come into the text above. >> It looks >> SB> like it is already expressed in terms of arbitrary cost. >> >> SB> Additionally in order to limit the number of SPFs to a practical >> SB> level, we normally suggest that the repair target in not d, but >> SB> instead is e (in the link case) or next hop of e (node case). >> >> SB> Anyway I will work on some text. >> >> - Stewart > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------000200010006030007040007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear Stephane,
see comments inline.
On 08/02/2013 10:13 AM, stephane.litkowski@orange.com wrote:
 
Hi,
 
Correct me if I don't understand correctly what you meant.
 
 "I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found."
 
This is how the draft is written today :
 
§3.1 :
"If there
   is no such LFA neighbor, then S may be able to create a virtual LFA
   by using a tunnel to carry the packet to a point in the network which
   is not a direct neighbor of S from which the packet will be delivered
   to the destination without looping back to S."
 
§4.1 :
"Not all links will require protection using a tunneled repair path.
   Referring to Figure 1, if E can already be protected via an LFA, S-E
   does not need to be protected using a repair tunnel, since all
   destinations normally reachable through E must therefore also be
   protectable by an LFA. "
 
The draft also precise that extended P-Space must be used :
"9.1.  Simplicity

   The remote LFA algorithm is simple to compute.

   o  The extended P space does not require any new computation (it is
      known once per-prefix LFA computation is completed).
"
 
Yes, you have right that in most of the cases it is emphasized, probably somehow I did read a previous version of the draft.

However, I'm getting a bit confused about you stated below, which is true :)
In your example, N is part of extended P-Space. So N would be a PQ (it's a normal LFA also as you stated).
in the draft:
4.2.2. Extended P-space 
... "This may be calculated by computing the an SPT at each of S's neighbors (N) (excluding E) and excising the subtree reached via the path N->S->E..."
In this case, all the neighbors are always examined regardless to the costs of the neighboring link, therefore the extended P-space will always contain all the neighbors except the failed one. Thus it will always contain 
the simple LFA if it exists.
Am I right?
 
 
 
My comment :
- Yes, extended P-Space usage is mandatory in order to maximize coverage (for me it's clearly explained in the draft)
 
- draft currently states that remote LFA would be computed only when normal LFA is not available BUT this is not a good idea. Based on the use case we are presenting if draft-ietf-rtgwg-lfa-manageability, there is a strong interrest in always computing rLFA protection then be able to compare attributes of PQs and normal LFAs to determine which one is the more efficient based on service provider requirements. This does not mean that we don't use extended P Space, extended P-Space need always to be used.
 
- You are providing NP coverage for rLFA , thanks for the info, but I just want to highlight that this is just "informational" as a router is not able to determine that the PQ is providing NP or not for the specific destination. Determining such PQ attribute would require extra SPF, as stated in draft-psarkar-rtgwg-rlfa-node-protection-00.
Calculating these coverages these coverages required all-pair shortest path computation and then NP and LP rLFAs can be easily determine by distance functions
 
 
 
Best Regards,
 
Stephane


Thanks for your comments,

Levente
 

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de Levente Csikor
Envoyé : jeudi 1 août 2013 16:11
À : stbryant@cisco.com
Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org
Objet : Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions

Dear All,
since our previous works in remote LFA analysis (papers already sent to these mailing lists) assumed unit cost networks, therefore as I promised, I calculated the corresponding LFA and rLFA coverages in those networks with their original link costs.
These networks were inferred from Rocketfuel dataset (Mahajan, R., Spring, N., Wetherall, D., Anderson, T.:
Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 231–236 (2002)), SNDLib (http://sndlib.zib.de), and TopologyZoo(http://www.topology-zoo.org). The found coverages and some details are found in the table below, where n and m denote the number of nodes and the number of links, respectively. The other columns mark the different coverages obrtained by simple LFA and remote LFA, where LP indicates the link-protecting case, while NP notes the case of node protection.
Topologies marked with an asterisk(*) did not have inferred real link costs from the datasets, so their costs were initially set to 1 (unit costs).

I believe that these results computed on real-world networks could significantly improve the rlfa draft, especially Sec. 9.3., and the advantages of remote LFA over simple LFA would be more emphasized.


+==============+====+====+==========+===========+============+============+
| Topology     | n  | m  | LFA_LP   | LFA_NP    |  rLFA_LP   |  rLFA_NP   |
+==============+====+====+==========+===========+============+============+
| AS1221       | 7  | 9  | 0.809    |   0.25    |   0.809    |    0.25    |
+--------------+----+----+----------+-----------+------------+------------+
| AS1239       | 30 | 69 | 0.8735   |  0.7554   |     1      |   0.9795   |
+--------------+----+----+----------+-----------+------------+------------+
| AS1755       | 18 | 33 | 0.8725   |  0.7741   |   0.9967   |   0.9959   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3257       | 27 | 64 | 0.923    |  0.7186   |   0.99     |   0.8472   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3967       | 21 | 36 | 0.7857   |  0.6460   |     1      |   0.9325   |
+--------------+----+----+----------+-----------+------------+------------+
| AS6461       | 17 | 37 | 0.9338   |  0.6933   |   0.9963   |   0.7075   |
+--------------+----+----+----------+-----------+------------+------------+
| Abilene*     | 12 | 15 | 0.5606   |  0.6078   |   0.9090   |   0.8725   |
+--------------+----+----+----------+-----------+------------+------------+
| Arnes*       | 41 | 57 | 0.6225   |  0.3518   |   0.7487   |   0.4562   |
+--------------+----+----+----------+-----------+------------+------------+
| AT&T         | 22 | 38 | 0.8225   |  0.5647   |     1      |   0.8497   |
+--------------+----+----+----------+-----------+------------+------------+
| Deltacom     | 113| 161| 0.5771   |  0.4910   |   0.8539   |   0.8148   |
+--------------+----+----+----------+-----------+------------+------------+
| Gambia       | 28 | 28 | 0.037    |   0.04    |   0.1851   |     0.12   |
+--------------+----+----+----------+-----------+------------+------------+
| Geant        | 37 | 55 | 0.6906   |  0.3977   |   0.8303   |   0.6582   |
+--------------+----+----+----------+-----------+------------+------------+
| Germ_50      | 50 | 88 | 0.9004   |  0.8381   |     1      |   0.9995   |
+--------------+----+----+----------+-----------+------------+------------+
| Germany*     | 27 | 32 | 0.6948   |  0.599    |     1      |   0.9549   |
+--------------+----+----+----------+-----------+------------+------------+
| InternetMCI  | 19 | 33 | 0.9035   |  0.6798   |   0.9415   |   0.9136   |
+--------------+----+----+----------+-----------+------------+------------+
| Italy*       | 33 | 56 | 0.784    |  0.5741   |     1      |   0.9269   |
+--------------+----+----+----------+-----------+------------+------------+
| NSF*         | 26 | 43 | 0.86     |  0.6347   |     1      |     1      |
+--------------+----+----+----------+-----------+------------+------------+


Furthermore, after reading the draft again-and-again, I have found that it should be more emphasized in the draft that calculating or seeking for a remote LFA staging point should be done IF AND ONLY IF no simple LFA were found. This is important, since normally people obviously think and observe that the failure coverage of remote LFA should be greater than or equal to the coverage obtained by simple LFA. Moreover, people also think that LFAs produce a subset of remote LFAs. However, if after a failure only P-spaces and Q-spaces are taken into account in order to seek a (remote) loop-free alternate, then it is possible that a simple LFA would not be found resulting unprotected node-pairs. But, this case could only happen when link costs are not unit costs. For an easier understanding, consider the network depicted below:
            1              1
          F--------S-----------X--------E
           \      /                      \
         10 \    / 4                      \  1
             \  /        1                 \
              N ---------------------------C
              |                            |
           1  |                            |  1
              |                            |
              |      1             1       |
              A--------------B-------------D

Assume that S wishes to send a packet to D, and the shortest path goes through E, therefore it is S-E-C-D. Suppose that the link (s,e)
fails, or even the node e itself fails. In this case, since LFA (and its calculation) only consider all other neighbors of s, then node N would be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D).
However, if we only seek possible remote LFAs, than according to the (r)SPF calculations, or taking into account our distance-function conditions will result that D's Q-space will contain node N (besides some other nodes), but S's P-space won't (it will only contain node F and what is more, if node F does not exist, then S's P-space would be empty), therefore no intersection of the two spaces will exist, leaving this network vulnerable to the failure of link (s,e).

This results that a neighbor should be always reached by the neighboring link, even if there exists a shorter, but definitely bigger in hop-count path to it.
According to this case (when seeking simple LFA is missed), the condition of extended P-space described by our distance functions, should be modified a bit:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)  && dist(s,v) < dist(s,e) + dist(e,v)
dist(n, d) < dist(n, s) + dist(s, d) .

One can easily observe that emphasizing more that remote LFA seeking process is only "executed" after no simple LFA is found could much more ease the understanding and won't result a headache to the reader who accidentally wants to calculate rLFA coverage in such network.

Please let me know, if my interpretation is not correct.
Thanks.

Best,
Levente

On 07/02/2013 07:07 PM, Stewart Bryant wrote:
On 26/06/2013 14:13, Levente Csikor wrote:

Levente

In each case below the conditions are surely fulfilled if n=e
thus I think that in each case the condition needs to be
changed to :

some node n!={s or e}
In order to not to read our full papers and searching the answers, I copied here the relevant parts:
Link-protecting rLFA condition:
For source s, destination d, and next-hop e, some node n != s,d is a link-protecting remote LFA for the s-d pair  if and only if
  dist(s, n) < dist(s, e) + dist(e, n)  (1)
  dist(n, d) < dist(n, s) + dist(s, d)  (2)
In these equations, one can easily see, that (1) defines the P-space, while (2) is the condition of Q-space. Furthermore, with these formalized conditions, one can easily observe, that (2) is actually the basic loop-free criterion of pure LFA.

Link-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended link-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)    
dist(n, d) < dist(n, s) + dist(s, d) .                                             

Node-protecting rLFA condition:
For source s, destination d, and next-hop e, some n != s,d is a node-protecting remote LFA for the s-d pair if and only if
dist(s,n) < dist(s,e) + dist(e,n)      (3)
dist(n,d) < dist(n,e) + dist(e,d)     (4)
As it was in the case of link protection, here, (3) defines the P-space, while (4) characterize the Q-space.
Here, two important observations can be made, which are the followings:
 - P-space does not depend on the protection scheme (i.e., link or node protection)
SB> That falls directly out of the definition of P-space
SB> since in link you cannot traverse the link to e and in
SB> node only get to e if you traverse the link to e
SB> thus the exclusion of the link to e applies in both cases
 - (4) again is the basic node-protecting loop-free criterion of pure LFA.

Node-protecting rLFA condition with extended P-space:
For source s, destination d, and next-hop e, some node n != s,d is an extended node-protecting remote LFA for the s-d pair if and only if
∃v ∈ neigh(s) : dist(v, n) < dist(v, e) + dist(e, n)
dist(n, d) < dist(n, e) + dist(e, d) .

Despite the fact that we only considered unit cost networks, the formal definitions above are true for any arbitrary weighted network.
SB> I do not see where the unit costs come into the text above. It looks
SB> like it is already expressed in terms of arbitrary cost.

SB> Additionally in order to limit the number of SPFs to a practical
SB> level, we normally suggest that the repair target in not d, but
SB> instead is e (in the link case) or next hop of e (node case).

SB> Anyway I will work on some text.

- Stewart

_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------000200010006030007040007-- From ietf@meetecho.com Fri Aug 2 05:50:34 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6607111E827F for ; Fri, 2 Aug 2013 05:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFrR3N4rxqkR for ; Fri, 2 Aug 2013 05:50:29 -0700 (PDT) Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id 94D6821E81A6 for ; Fri, 2 Aug 2013 05:48:49 -0700 (PDT) Received: from dell-tcastaldi ([89.246.150.136]) by smtpcmd03.ad.aruba.it with bizsmtp id 7ool1m0112wpE7M01oomsk; Fri, 02 Aug 2013 14:48:47 +0200 Date: Fri, 2 Aug 2013 14:48:45 +0200 (CEST) From: Meetecho Team To: rtgwg@ietf.org Message-ID: <1759551929.3.1375447725136.JavaMail.tcastaldi@dell-tcastaldi> Subject: RTGWG session recording available MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_887106029.1375447725134" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 12:50:34 -0000 ------=_Part_2_887106029.1375447725134 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the RTGWG WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#RTGWG For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_2_887106029.1375447725134-- From curtis@ipv6.occnc.com Fri Aug 2 09:47:57 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD18221E80AE for ; Fri, 2 Aug 2013 09:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEIwcHy9KPKa for ; Fri, 2 Aug 2013 09:47:53 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB5321F9E51 for ; Fri, 2 Aug 2013 09:47:53 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r72GkY1R001966; Fri, 2 Aug 2013 12:46:35 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201308021646.r72GkY1R001966@gateway1.orleans.occnc.com> To: Levente Csikor From: Curtis Villamizar Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions In-reply-to: Your message of "Thu, 01 Aug 2013 16:10:50 +0200." <51FA6C6A.4090200@tmit.bme.hu> Date: Fri, 02 Aug 2013 12:46:34 -0400 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 16:47:57 -0000 Some of the topology data is very old. TopologyZoo lists a "last updated" date which does not correspond to when the network looked the way it did in the update. For example, networks that look to be from the late 1980s or 1990s have dates in 2011 or 2012. NSF looks to be NSFNET circa late 1980s (the AS number would have helped as the DSO, T1, and T3 NSFNET and vBNS all had differenct AS). InternetMCI went out of existance in the mid-1990s. Sprintlink (AS1239) looks to be same era. These show the network cores for provider networks. Some have about 1,000 nodes in their edge network but a small core. Back in the late 1990s a lot of US networks had a flat ISIS IGP with 600 to 1,200 nodes, according to claims made in NANOG presentations at the time or claims made outside of meetings at NANOG or IETF. The data therefore may be real world but a lot of it is about 20 years old and may not reflect the present. Curtis In message <51FA6C6A.4090200@tmit.bme.hu> Levente Csikor writes: > Dear All, > since our previous works in remote LFA analysis (papers already sent to > these mailing lists) assumed unit cost networks, therefore as I > promised, I calculated the corresponding LFA and rLFA coverages in those > networks with their original link costs. > These networks were inferred from Rocketfuel dataset (/Mahajan, R., > Spring, N., Wetherall, D., Anderson, T.:// > //Inferring link weights using end-to-end measurements. In: ACM IMC, pp. > 231–236 (2002)/), SNDLib (http://sndlib.zib.de), and > TopologyZoo(http://www.topology-zoo.org). The found coverages and some > details are found in the table below, where /n/ and /m/ denote the > number of nodes and the number of links, respectively. The other columns > mark the different coverages obrtained by simple LFA and remote LFA, > where LP indicates the link-protecting case, while NP notes the case of > node protection. > Topologies marked with an asterisk(*) did not have inferred real link > costs from the datasets, so their costs were initially set to 1 (unit > costs). > > I believe that these results computed on real-world networks could > significantly improve the rlfa draft, especially Sec. 9.3., and the > advantages of remote LFA over simple LFA would be more emphasized. > > > +==============+====+====+==========+===========+============+============+ > | Topology | n | m | LFA_LP | LFA_NP | rLFA_LP | rLFA_NP | > +==============+====+====+==========+===========+============+============+ > | AS1221 | 7 | 9 | 0.809 | 0.25 | 0.809 | 0.25 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1239 | 30 | 69 | 0.8735 | 0.7554 | 1 | 0.9795 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS1755 | 18 | 33 | 0.8725 | 0.7741 | 0.9967 | 0.9959 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3257 | 27 | 64 | 0.923 | 0.7186 | 0.99 | 0.8472 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS3967 | 21 | 36 | 0.7857 | 0.6460 | 1 | 0.9325 | > +--------------+----+----+----------+-----------+------------+------------+ > | AS6461 | 17 | 37 | 0.9338 | 0.6933 | 0.9963 | 0.7075 | > +--------------+----+----+----------+-----------+------------+------------+ > | Abilene* | 12 | 15 | 0.5606 | 0.6078 | 0.9090 | 0.8725 | > +--------------+----+----+----------+-----------+------------+------------+ > | Arnes* | 41 | 57 | 0.6225 | 0.3518 | 0.7487 | 0.4562 | > +--------------+----+----+----------+-----------+------------+------------+ > | AT&T | 22 | 38 | 0.8225 | 0.5647 | 1 | 0.8497 | > +--------------+----+----+----------+-----------+------------+------------+ > | Deltacom | 113| 161| 0.5771 | 0.4910 | 0.8539 | 0.8148 | > +--------------+----+----+----------+-----------+------------+------------+ > | Gambia | 28 | 28 | 0.037 | 0.04 | 0.1851 | 0.12 | > +--------------+----+----+----------+-----------+------------+------------+ > | Geant | 37 | 55 | 0.6906 | 0.3977 | 0.8303 | 0.6582 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germ_50 | 50 | 88 | 0.9004 | 0.8381 | 1 | 0.9995 | > +--------------+----+----+----------+-----------+------------+------------+ > | Germany* | 27 | 32 | 0.6948 | 0.599 | 1 | 0.9549 | > +--------------+----+----+----------+-----------+------------+------------+ > | InternetMCI | 19 | 33 | 0.9035 | 0.6798 | 0.9415 | 0.9136 | > +--------------+----+----+----------+-----------+------------+------------+ > | Italy* | 33 | 56 | 0.784 | 0.5741 | 1 | 0.9269 | > +--------------+----+----+----------+-----------+------------+------------+ > | NSF* | 26 | 43 | 0.86 | 0.6347 | 1 | 1 | > +--------------+----+----+----------+-----------+------------+------------+ > > > Furthermore, after reading the draft again-and-again, I have found that > it should be more emphasized in the draft that calculating or seeking > for a remote LFA staging point should be done IF AND ONLY IF no simple > LFA were found. This is important, since normally people obviously think > and observe that the failure coverage of remote LFA should be greater > than or equal to the coverage obtained by simple LFA. Moreover, people > also think that LFAs produce a subset of remote LFAs. However, if after > a failure only P-spaces and Q-spaces are taken into account in order to > seek a (remote) loop-free alternate, then it is possible that a simple > LFA would not be found resulting unprotected node-pairs. But, this case > could only happen when link costs are not unit costs. For an easier > understanding, consider the network depicted below: > 1 1 > F--------S-----------X--------E > \ / \ > 10 \ / 4 \ 1 > \ / 1 \ > N ---------------------------C > | | > 1 | | 1 > | | > | 1 1 | > A--------------B-------------D > > Assume that S wishes to send a packet to D, and the shortest path goes > through E, therefore it is S-E-C-D. Suppose that the link (s,e) > fails, or even the node e itself fails. In this case, since LFA (and its > calculation) only consider all other neighbors of s, then node N would > be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D). > However, if we only seek possible remote LFAs, than according to the > (r)SPF calculations, or taking into account our distance-function > conditions will result that D's Q-space will contain node N (besides > some other nodes), but S's P-space won't (it will only contain node F > and what is more, if node F does not exist, then S's P-space would be > empty), therefore no intersection of the two spaces will exist, leaving > this network vulnerable to the failure of link (s,e). > > This results that a neighbor should be always reached by the neighboring > link, even if there exists a shorter, but definitely bigger in hop-count > path to it. > According to this case (when seeking simple LFA is missed), the > condition of extended P-space described by our distance functions, > should be modified a bit: > For source /s/, destination /d/, and next-hop /e/, some node /n != s,d/ > is an extended link-protecting remote LFA for the /s-d/ pair if and only if > /∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)//*&& > dist(s,v) < dist(s,e) + dist(e**,v)*/** > /dist(n, d) < dist(n, s) + dist(s, d) . / > > One can easily observe that emphasizing more that remote LFA seeking > process is only "executed" after no simple LFA is found could much more > ease the understanding and won't result a headache to the reader who > accidentally wants to calculate rLFA coverage in such network. > > Please let me know, if my interpretation is not correct. > Thanks. > > Best, > Levente From csikor@tmit.bme.hu Fri Aug 2 09:57:38 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D7D11E8105 for ; Fri, 2 Aug 2013 09:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTcsnbSJqhNH for ; Fri, 2 Aug 2013 09:57:33 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id A918721F90AC for ; Fri, 2 Aug 2013 09:57:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id E619787350; Fri, 2 Aug 2013 18:57:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+0hCvPj3Wii; Fri, 2 Aug 2013 18:57:12 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 7EAA487346; Fri, 2 Aug 2013 18:57:12 +0200 (CEST) Received: from [192.168.89.148] (catv-178-48-68-91.catv.broadband.hu [178.48.68.91]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r72GvLbu029943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 18:57:22 +0200 Message-ID: <51FBE4E9.5080404@tmit.bme.hu> Date: Fri, 02 Aug 2013 18:57:13 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: curtis@ipv6.occnc.com Subject: Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions References: <201308021646.r72GkY1R001966@gateway1.orleans.occnc.com> In-Reply-To: <201308021646.r72GkY1R001966@gateway1.orleans.occnc.com> Content-Type: multipart/alternative; boundary="------------050301060205030704040701" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 16:57:38 -0000 This is a multi-part message in MIME format. --------------050301060205030704040701 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sending up-to-date topologies are welcome and suggested:) I can calculate the coverage of them. LEMON format is preferred, but GMLor Graph ML, or any humanreadable format could be converted. On 08/02/2013 06:46 PM, Curtis Villamizar wrote: > Some of the topology data is very old. TopologyZoo lists a "last > updated" date which does not correspond to when the network looked the > way it did in the update. For example, networks that look to be from > the late 1980s or 1990s have dates in 2011 or 2012. > > NSF looks to be NSFNET circa late 1980s (the AS number would have > helped as the DSO, T1, and T3 NSFNET and vBNS all had differenct AS). > InternetMCI went out of existance in the mid-1990s. Sprintlink > (AS1239) looks to be same era. > > These show the network cores for provider networks. Some have about > 1,000 nodes in their edge network but a small core. Back in the late > 1990s a lot of US networks had a flat ISIS IGP with 600 to 1,200 > nodes, according to claims made in NANOG presentations at the time or > claims made outside of meetings at NANOG or IETF. > > The data therefore may be real world but a lot of it is about 20 years > old and may not reflect the present. > > Curtis > > > In message <51FA6C6A.4090200@tmit.bme.hu> > Levente Csikor writes: > >> Dear All, >> since our previous works in remote LFA analysis (papers already sent to >> these mailing lists) assumed unit cost networks, therefore as I >> promised, I calculated the corresponding LFA and rLFA coverages in those >> networks with their original link costs. >> These networks were inferred from Rocketfuel dataset (/Mahajan, R., >> Spring, N., Wetherall, D., Anderson, T.:// >> //Inferring link weights using end-to-end measurements. In: ACM IMC, pp. >> 231–236 (2002)/), SNDLib (http://sndlib.zib.de), and >> TopologyZoo(http://www.topology-zoo.org). The found coverages and some >> details are found in the table below, where /n/ and /m/ denote the >> number of nodes and the number of links, respectively. The other columns >> mark the different coverages obrtained by simple LFA and remote LFA, >> where LP indicates the link-protecting case, while NP notes the case of >> node protection. >> Topologies marked with an asterisk(*) did not have inferred real link >> costs from the datasets, so their costs were initially set to 1 (unit >> costs). >> >> I believe that these results computed on real-world networks could >> significantly improve the rlfa draft, especially Sec. 9.3., and the >> advantages of remote LFA over simple LFA would be more emphasized. >> >> >> +==============+====+====+==========+===========+============+============+ >> | Topology | n | m | LFA_LP | LFA_NP | rLFA_LP | rLFA_NP | >> +==============+====+====+==========+===========+============+============+ >> | AS1221 | 7 | 9 | 0.809 | 0.25 | 0.809 | 0.25 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | AS1239 | 30 | 69 | 0.8735 | 0.7554 | 1 | 0.9795 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | AS1755 | 18 | 33 | 0.8725 | 0.7741 | 0.9967 | 0.9959 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | AS3257 | 27 | 64 | 0.923 | 0.7186 | 0.99 | 0.8472 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | AS3967 | 21 | 36 | 0.7857 | 0.6460 | 1 | 0.9325 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | AS6461 | 17 | 37 | 0.9338 | 0.6933 | 0.9963 | 0.7075 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Abilene* | 12 | 15 | 0.5606 | 0.6078 | 0.9090 | 0.8725 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Arnes* | 41 | 57 | 0.6225 | 0.3518 | 0.7487 | 0.4562 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | AT&T | 22 | 38 | 0.8225 | 0.5647 | 1 | 0.8497 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Deltacom | 113| 161| 0.5771 | 0.4910 | 0.8539 | 0.8148 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Gambia | 28 | 28 | 0.037 | 0.04 | 0.1851 | 0.12 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Geant | 37 | 55 | 0.6906 | 0.3977 | 0.8303 | 0.6582 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Germ_50 | 50 | 88 | 0.9004 | 0.8381 | 1 | 0.9995 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Germany* | 27 | 32 | 0.6948 | 0.599 | 1 | 0.9549 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | InternetMCI | 19 | 33 | 0.9035 | 0.6798 | 0.9415 | 0.9136 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | Italy* | 33 | 56 | 0.784 | 0.5741 | 1 | 0.9269 | >> +--------------+----+----+----------+-----------+------------+------------+ >> | NSF* | 26 | 43 | 0.86 | 0.6347 | 1 | 1 | >> +--------------+----+----+----------+-----------+------------+------------+ >> >> >> Furthermore, after reading the draft again-and-again, I have found that >> it should be more emphasized in the draft that calculating or seeking >> for a remote LFA staging point should be done IF AND ONLY IF no simple >> LFA were found. This is important, since normally people obviously think >> and observe that the failure coverage of remote LFA should be greater >> than or equal to the coverage obtained by simple LFA. Moreover, people >> also think that LFAs produce a subset of remote LFAs. However, if after >> a failure only P-spaces and Q-spaces are taken into account in order to >> seek a (remote) loop-free alternate, then it is possible that a simple >> LFA would not be found resulting unprotected node-pairs. But, this case >> could only happen when link costs are not unit costs. For an easier >> understanding, consider the network depicted below: >> 1 1 >> F--------S-----------X--------E >> \ / \ >> 10 \ / 4 \ 1 >> \ / 1 \ >> N ---------------------------C >> | | >> 1 | | 1 >> | | >> | 1 1 | >> A--------------B-------------D >> >> Assume that S wishes to send a packet to D, and the shortest path goes >> through E, therefore it is S-E-C-D. Suppose that the link (s,e) >> fails, or even the node e itself fails. In this case, since LFA (and its >> calculation) only consider all other neighbors of s, then node N would >> be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D). >> However, if we only seek possible remote LFAs, than according to the >> (r)SPF calculations, or taking into account our distance-function >> conditions will result that D's Q-space will contain node N (besides >> some other nodes), but S's P-space won't (it will only contain node F >> and what is more, if node F does not exist, then S's P-space would be >> empty), therefore no intersection of the two spaces will exist, leaving >> this network vulnerable to the failure of link (s,e). >> >> This results that a neighbor should be always reached by the neighboring >> link, even if there exists a shorter, but definitely bigger in hop-count >> path to it. >> According to this case (when seeking simple LFA is missed), the >> condition of extended P-space described by our distance functions, >> should be modified a bit: >> For source /s/, destination /d/, and next-hop /e/, some node /n != s,d/ >> is an extended link-protecting remote LFA for the /s-d/ pair if and only if >> /∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)//*&& >> dist(s,v) < dist(s,e) + dist(e**,v)*/** >> /dist(n, d) < dist(n, s) + dist(s, d) . / >> >> One can easily observe that emphasizing more that remote LFA seeking >> process is only "executed" after no simple LFA is found could much more >> ease the understanding and won't result a headache to the reader who >> accidentally wants to calculate rLFA coverage in such network. >> >> Please let me know, if my interpretation is not correct. >> Thanks. >> >> Best, >> Levente --------------050301060205030704040701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sending up-to-date topologies are welcome and suggested:)
I can calculate the coverage of them.

LEMON format is preferred, but GML or Graph ML, or any human readable format could be converted.
On 08/02/2013 06:46 PM, Curtis Villamizar wrote:
Some of the topology data is very old.  TopologyZoo lists a "last
updated" date which does not correspond to when the network looked the
way it did in the update.  For example, networks that look to be from
the late 1980s or 1990s have dates in 2011 or 2012.

NSF looks to be NSFNET circa late 1980s (the AS number would have
helped as the DSO, T1, and T3 NSFNET and vBNS all had differenct AS).
InternetMCI went out of existance in the mid-1990s.  Sprintlink
(AS1239) looks to be same era.

These show the network cores for provider networks.  Some have about
1,000 nodes in their edge network but a small core.  Back in the late
1990s a lot of US networks had a flat ISIS IGP with 600 to 1,200
nodes, according to claims made in NANOG presentations at the time or
claims made outside of meetings at NANOG or IETF.

The data therefore may be real world but a lot of it is about 20 years
old and may not reflect the present.

Curtis


In message <51FA6C6A.4090200@tmit.bme.hu>
Levente Csikor writes:
 

Dear All,
since our previous works in remote LFA analysis (papers already sent to 
these mailing lists) assumed unit cost networks, therefore as I 
promised, I calculated the corresponding LFA and rLFA coverages in those 
networks with their original link costs.
These networks were inferred from Rocketfuel dataset (/Mahajan, R., 
Spring, N., Wetherall, D., Anderson, T.://
//Inferring link weights using end-to-end measurements. In: ACM IMC, pp. 
231–236 (2002)/), SNDLib (http://sndlib.zib.de), and 
TopologyZoo(http://www.topology-zoo.org). The found coverages and some 
details are found in the table below, where /n/ and /m/ denote the 
number of nodes and the number of links, respectively. The other columns 
mark the different coverages obrtained by simple LFA and remote LFA, 
where LP indicates the link-protecting case, while NP notes the case of 
node protection.
Topologies marked with an asterisk(*) did not have inferred real link 
costs from the datasets, so their costs were initially set to 1 (unit 
costs).
 
I believe that these results computed on real-world networks could 
significantly improve the rlfa draft, especially Sec. 9.3., and the 
advantages of remote LFA over simple LFA would be more emphasized.
 
 
+==============+====+====+==========+===========+============+============+
| Topology     | n  | m  | LFA_LP   | LFA_NP    |  rLFA_LP   | rLFA_NP   |
+==============+====+====+==========+===========+============+============+
| AS1221       | 7  | 9  | 0.809    | 0.25    |   0.809    |    0.25    |
+--------------+----+----+----------+-----------+------------+------------+
| AS1239       | 30 | 69 | 0.8735   | 0.7554 |     1      |   0.9795   |
+--------------+----+----+----------+-----------+------------+------------+
| AS1755       | 18 | 33 | 0.8725   |  0.7741   |   0.9967   |   0.9959   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3257       | 27 | 64 | 0.923    |  0.7186   |   0.99     |   0.8472   |
+--------------+----+----+----------+-----------+------------+------------+
| AS3967       | 21 | 36 | 0.7857   |  0.6460   |     1      |   0.9325   |
+--------------+----+----+----------+-----------+------------+------------+
| AS6461       | 17 | 37 | 0.9338   |  0.6933   |   0.9963   |   0.7075   |
+--------------+----+----+----------+-----------+------------+------------+
| Abilene*     | 12 | 15 | 0.5606   |  0.6078   |   0.9090   |   0.8725   |
+--------------+----+----+----------+-----------+------------+------------+
| Arnes*       | 41 | 57 | 0.6225   |  0.3518   |   0.7487   |   0.4562   |
+--------------+----+----+----------+-----------+------------+------------+
| AT&T         | 22 | 38 | 0.8225   |  0.5647   |     1      |   0.8497   |
+--------------+----+----+----------+-----------+------------+------------+
| Deltacom     | 113| 161| 0.5771   |  0.4910   |   0.8539   |   0.8148   |
+--------------+----+----+----------+-----------+------------+------------+
| Gambia       | 28 | 28 | 0.037    |   0.04    |   0.1851   |     0.12   |
+--------------+----+----+----------+-----------+------------+------------+
| Geant        | 37 | 55 | 0.6906   |  0.3977   |   0.8303   |   0.6582   |
+--------------+----+----+----------+-----------+------------+------------+
| Germ_50      | 50 | 88 | 0.9004   |  0.8381   |     1      |   0.9995   |
+--------------+----+----+----------+-----------+------------+------------+
| Germany*     | 27 | 32 | 0.6948   |  0.599    |     1      |   0.9549   |
+--------------+----+----+----------+-----------+------------+------------+
| InternetMCI  | 19 | 33 | 0.9035   |  0.6798   |   0.9415   |   0.9136   |
+--------------+----+----+----------+-----------+------------+------------+
| Italy*       | 33 | 56 | 0.784    |  0.5741   |     1      |   0.9269   |
+--------------+----+----+----------+-----------+------------+------------+
| NSF*         | 26 | 43 | 0.86     |  0.6347   |     1      |     1      |
+--------------+----+----+----------+-----------+------------+------------+
 
 
Furthermore, after reading the draft again-and-again, I have found that 
it should be more emphasized in the draft that calculating or seeking 
for a remote LFA staging point should be done IF AND ONLY IF no simple 
LFA were found. This is important, since normally people obviously think 
and observe that the failure coverage of remote LFA should be greater 
than or equal to the coverage obtained by simple LFA. Moreover, people 
also think that LFAs produce a subset of remote LFAs. However, if after 
a failure only P-spaces and Q-spaces are taken into account in order to 
seek a (remote) loop-free alternate, then it is possible that a simple 
LFA would not be found resulting unprotected node-pairs. But, this case 
could only happen when link costs are not unit costs. For an easier 
understanding, consider the network depicted below:
          1             1
F--------S-----------X--------E
\ /         \
      10 \    / 4         \  1
      \  /       1             \
N ---------------------------C
|    |
        1  | |  1
           | |
           | 1            1 |
A--------------B-------------D
 
Assume that S wishes to send a packet to D, and the shortest path goes 
through E, therefore it is S-E-C-D. Suppose that the link (s,e)
fails, or even the node e itself fails. In this case, since LFA (and its 
calculation) only consider all other neighbors of s, then node N would 
be an easy LFA for this failure, since dist(N,D) < dist(N,S)+dist(S,D).
However, if we only seek possible remote LFAs, than according to the 
(r)SPF calculations, or taking into account our distance-function 
conditions will result that D's Q-space will contain node N (besides 
some other nodes), but S's P-space won't (it will only contain node F 
and what is more, if node F does not exist, then S's P-space would be 
empty), therefore no intersection of the two spaces will exist, leaving 
this network vulnerable to the failure of link (s,e).
 
This results that a neighbor should be always reached by the neighboring 
link, even if there exists a shorter, but definitely bigger in hop-count 
path to it.
According to this case (when seeking simple LFA is missed), the 
condition of extended P-space described by our distance functions, 
should be modified a bit:
For source /s/, destination /d/, and next-hop /e/, some node /n != s,d/ 
is an extended link-protecting remote LFA for the /s-d/ pair if and only if
/∃v ∈ neigh(s) : dist(v, n) < dist(v, s) + dist(s, e) + dist(e, n)//*&& 
dist(s,v) < dist(s,e) + dist(e**,v)*/**
/dist(n, d) < dist(n, s) + dist(s, d) . /
 
One can easily observe that emphasizing more that remote LFA seeking 
process is only "executed" after no simple LFA is found could much more 
ease the understanding and won't result a headache to the reader who 
accidentally wants to calculate rLFA coverage in such network.
 
Please let me know, if my interpretation is not correct.
Thanks.
 
Best,
Levente

--------------050301060205030704040701-- From curtis@ipv6.occnc.com Fri Aug 2 13:57:43 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496CB11E80E7 for ; Fri, 2 Aug 2013 13:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gew5YOfXepzq for ; Fri, 2 Aug 2013 13:57:39 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id ED69111E8113 for ; Fri, 2 Aug 2013 13:57:38 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r72KsqYW003873; Fri, 2 Aug 2013 16:54:53 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201308022054.r72KsqYW003873@gateway1.orleans.occnc.com> To: Jeff Tantsura From: Curtis Villamizar Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps In-reply-to: Your message of "Sat, 27 Jul 2013 16:38:18 -0000." <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> Date: Fri, 02 Aug 2013 16:54:52 -0400 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 20:57:43 -0000 Jeff, OSPF does not intentionally send a full MTU sized packet as ISIS does. The MTU is simply stated in the Database Description Packet. The set of values to use for common interfaces is stated in Path MTU Discovery Table 1 which is cited for that reason in RFC2328 (OSPFv2). If a provider configures the nominal MTU for an OSPF interface for any given interface type, then it doesn't matter if the vendor considers the MTU to include or exclude L3 framing or VLAN or MPLS labels. For example, if both sides configure 1500 as the value for OSPF to send in the Database Description Packet, then it doesn't really matter if the packet is sent over a PW and a 1500 byte packet would in fact be fragmented along the way. So for OSPF if the two sides are configured to the same nominal MTU, then all is well. OTOH if one has 1500 and the other side can send Ethernet jumbo frames at nominal 9216 bytes, then the adjacency should not come up until the problem is fixed as it would black hole traffic. The current behavior of ISIS is arguably not broken either. If one side can send a packet that the other side will reject in error, then a link should not come up. ISIS goes through the trouble of continuously checking the MTU (and wasting bandwidth) by padding every LSPDU to the largest size that can be sent in addition to negociating. In practice a lot of hardware can receive packets somewhat larger than the stated MTU but the attempt to verify MTU down to the byte causes some problems. My experience while at a provider was that if you figured out the smallest practical MTU in the core and configured all interfaces to that value so as never to fragment within the core, then OSPF always just worked. In both cases, it would be nice to standardize nominal MTU values, allow negociation, and state what the MTU includes. OSPF already simply requires a nominal MTU to match eliminating the need to figure out whether the MTU should be reduced for VLAN tag, or a label, etc. My point was that this should be taken up in the ISIS WG and if needed it should be taken up in the OSPF WG. Curtis In message <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> Jeff Tantsura writes: Curtis, In any known OSPF implementation if MTU on both sides doesn't match OSPF will get stuck in Exchange/Exstart. Regards, Jeff On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar" wrote: > > In message > Alia Atlas writes: > >> We are likely to add this draft to the list to be discussed in the >> meeting. It is discussing some general problems with MTU >> configuration between vendors. While it discusses this for ISIS, >> some aspects also apply to OSPF. >> >> Basically, there are three problems: >> >> a) Some implementations use L2 MTU and others use the L3 MTU >> b) Different implementations pad and check for different lengths. >> Consequences are that ISIS sessions do not make it to Up. >> c) Different numbers of MPLS labels are assumed as the max, resulting in >> fragmentation, and there are generally no controls for it. >> >> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/ >> >> Thanks, >> Alia > > > First of all, the IGP issue is unique to ISIS and should be fixed in > ISIS. ISIS pads the LSPDU fragment to the full MTU to verify that the > full MTU is supported. THis is a misfeature IMHO, but that is the way > it is. OSPF does not have this misfeature. > > The reason that ISIS does this is that IP fragmentation at full line > rate is considered hard to do for high line rates relative to IP > forwarding. Some **very** old routers did this in software and would > crash if you gave them a full line rate load of packets to fragment. > The ISIS practice of padding to full MTU predated the existance of > MPLS and any use at all of VLAN by providers (who still rarely use > VLAN and probably never in core). Many routers today can fragment at > full line rate or close to it for average packet sizes (not > tinygrams). Some can't, but if the rate is very low, they should be > avoided. Providers need to test for this. In modern networks, if > most packets are 1532 or smaller, whether the MTU is somewhat over 4K, > somewhat over 8K, or closer to 9K makes no difference. > > TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment" > bit and looks for the ICMP Would Fragment packets as a hint to lower > the MTU. ISIS could do the same. > > Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls > blocking all ICMP, rather than just blocking forms of ICMP that might > be in some way dangerous. This problem can be avoided by sending only > some packets with "Do Not Fragment" and using SACK to figure out that > those are consistently getting lost (and not counting that as a drop > but rather as an indication to lower the TCP MSS value). > > Instead of trying to figure out the *right* value to configure, the > ISIS protocol needs to get smarter about dealing with different values > of MTU, including small variations created by encapsulation in MPLS. > > IMHO this should be resubmited as a problem statement to the ISIS WG. > > Most providers have already figured out what *they* need to configure > as the MTU on their links and do so by using either program generated > router configurations or using programs to check router configurations > for some level of consistency. BTW- the 4470 number dates back to POS > wanting to have a larger MTU than FDDI. > > As far as configuring a value of 4470 on all routers without ISIS > changes, the provider must first read the vendor literature to find > out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure > out whether further encapsulation will impact the effective MTU. > Looking at the default value provides a good hint. > > If all the traffic coming into a network is at 1532 MTU (or something > in that range) and the provider just wants headroom for PW and other > labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes > no difference at all. Therefore inconsistencies in values over about > 1600 make no difference at all for such a provider. A control packet > here or there might get fragmented but everything (except ISIS) should > work with minor inconsistencies in the configured MTU. > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From akatlas@gmail.com Fri Aug 2 14:06:53 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD7F11E80F9 for ; Fri, 2 Aug 2013 14:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIseEowPc+uJ for ; Fri, 2 Aug 2013 14:06:52 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 076CE21E8050 for ; Fri, 2 Aug 2013 14:06:51 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so2024387obp.8 for ; Fri, 02 Aug 2013 14:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+AH/dQDNPRZlHzMnCgn1dVj0T2wwiJreAITKqV1V+AQ=; b=sbotneYwvST7FqzIYGYWsUMDjWhJZSDHVGg62Nm0pIm938b3mPHrrn2vGTcw3G8P6e B5D9bDhUdY3twNqEqsFXk+tcrlyC8CDvo+KBwUSfZipvn9bopL93dFbStqXIZewA46jp GfktAhFquskwenzsMuD7z7+OgDlC3Ccz1WWk57pRda61yTlXHB3/VSY8SeMZvw6NYZNp eSE41vyA0OCz800wGhSNDIPFfgXtE8Bp6NsaVcWTRSHfuHJDEwYnpIvkygOZpOC6Wcpj 9jAJ+lJ2SK0ZXiMQ37Q5MmDdrYM6+iINzab4WFSDrJExuD7R5pKtL4YbawnJmLd27mtP sJXQ== MIME-Version: 1.0 X-Received: by 10.43.61.199 with SMTP id wx7mr757948icb.14.1375477611518; Fri, 02 Aug 2013 14:06:51 -0700 (PDT) Received: by 10.64.126.71 with HTTP; Fri, 2 Aug 2013 14:06:51 -0700 (PDT) In-Reply-To: <201308022054.r72KsqYW003873@gateway1.orleans.occnc.com> References: <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> <201308022054.r72KsqYW003873@gateway1.orleans.occnc.com> Date: Fri, 2 Aug 2013 17:06:51 -0400 Message-ID: Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps From: Alia Atlas To: "curtis@ipv6.occnc.com" Content-Type: multipart/alternative; boundary=bcaec51f96af6e64e104e2fd56b3 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 21:06:53 -0000 --bcaec51f96af6e64e104e2fd56b3 Content-Type: text/plain; charset=ISO-8859-1 In the RTGWG meeting, there was fairly clear interest in thinking about this issue. Adrian also suggested discussing it with the OPSWG. I believe that Vic is looking for a co-author or so who is interested in helping explore what the right thing to document or do in the IETF context. Alia On Fri, Aug 2, 2013 at 4:54 PM, Curtis Villamizar wrote: > > Jeff, > > OSPF does not intentionally send a full MTU sized packet as ISIS does. > The MTU is simply stated in the Database Description Packet. The set > of values to use for common interfaces is stated in Path MTU Discovery > Table 1 which is cited for that reason in RFC2328 (OSPFv2). If a > provider configures the nominal MTU for an OSPF interface for any > given interface type, then it doesn't matter if the vendor considers > the MTU to include or exclude L3 framing or VLAN or MPLS labels. > > For example, if both sides configure 1500 as the value for OSPF to > send in the Database Description Packet, then it doesn't really matter > if the packet is sent over a PW and a 1500 byte packet would in fact > be fragmented along the way. > > So for OSPF if the two sides are configured to the same nominal MTU, > then all is well. OTOH if one has 1500 and the other side can send > Ethernet jumbo frames at nominal 9216 bytes, then the adjacency should > not come up until the problem is fixed as it would black hole traffic. > > The current behavior of ISIS is arguably not broken either. If one > side can send a packet that the other side will reject in error, then > a link should not come up. ISIS goes through the trouble of > continuously checking the MTU (and wasting bandwidth) by padding every > LSPDU to the largest size that can be sent in addition to > negociating. In practice a lot of hardware can receive packets > somewhat larger than the stated MTU but the attempt to verify MTU down > to the byte causes some problems. > > My experience while at a provider was that if you figured out the > smallest practical MTU in the core and configured all interfaces to > that value so as never to fragment within the core, then OSPF always > just worked. > > In both cases, it would be nice to standardize nominal MTU values, > allow negociation, and state what the MTU includes. OSPF already > simply requires a nominal MTU to match eliminating the need to figure > out whether the MTU should be reduced for VLAN tag, or a label, etc. > > My point was that this should be taken up in the ISIS WG and if needed > it should be taken up in the OSPF WG. > > Curtis > > > In message <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> > Jeff Tantsura writes: > > Curtis, > > In any known OSPF implementation if MTU on both sides doesn't match OSPF > will get stuck in Exchange/Exstart. > > Regards, > Jeff > > On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar" > wrote: > > > > > In message < > CAG4d1rdzpGFLw1Z1XFRYgh2J1TSYS0VLbN4VmsQTLKZ3-tVzpQ@mail.gmail.com> > > Alia Atlas writes: > > > >> We are likely to add this draft to the list to be discussed in the > >> meeting. It is discussing some general problems with MTU > >> configuration between vendors. While it discusses this for ISIS, > >> some aspects also apply to OSPF. > >> > >> Basically, there are three problems: > >> > >> a) Some implementations use L2 MTU and others use the L3 MTU > >> b) Different implementations pad and check for different lengths. > >> Consequences are that ISIS sessions do not make it to Up. > >> c) Different numbers of MPLS labels are assumed as the max, resulting in > >> fragmentation, and there are generally no controls for it. > >> > >> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/ > >> > >> Thanks, > >> Alia > > > > > > First of all, the IGP issue is unique to ISIS and should be fixed in > > ISIS. ISIS pads the LSPDU fragment to the full MTU to verify that the > > full MTU is supported. THis is a misfeature IMHO, but that is the way > > it is. OSPF does not have this misfeature. > > > > The reason that ISIS does this is that IP fragmentation at full line > > rate is considered hard to do for high line rates relative to IP > > forwarding. Some **very** old routers did this in software and would > > crash if you gave them a full line rate load of packets to fragment. > > The ISIS practice of padding to full MTU predated the existance of > > MPLS and any use at all of VLAN by providers (who still rarely use > > VLAN and probably never in core). Many routers today can fragment at > > full line rate or close to it for average packet sizes (not > > tinygrams). Some can't, but if the rate is very low, they should be > > avoided. Providers need to test for this. In modern networks, if > > most packets are 1532 or smaller, whether the MTU is somewhat over 4K, > > somewhat over 8K, or closer to 9K makes no difference. > > > > TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment" > > bit and looks for the ICMP Would Fragment packets as a hint to lower > > the MTU. ISIS could do the same. > > > > Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls > > blocking all ICMP, rather than just blocking forms of ICMP that might > > be in some way dangerous. This problem can be avoided by sending only > > some packets with "Do Not Fragment" and using SACK to figure out that > > those are consistently getting lost (and not counting that as a drop > > but rather as an indication to lower the TCP MSS value). > > > > Instead of trying to figure out the *right* value to configure, the > > ISIS protocol needs to get smarter about dealing with different values > > of MTU, including small variations created by encapsulation in MPLS. > > > > IMHO this should be resubmited as a problem statement to the ISIS WG. > > > > Most providers have already figured out what *they* need to configure > > as the MTU on their links and do so by using either program generated > > router configurations or using programs to check router configurations > > for some level of consistency. BTW- the 4470 number dates back to POS > > wanting to have a larger MTU than FDDI. > > > > As far as configuring a value of 4470 on all routers without ISIS > > changes, the provider must first read the vendor literature to find > > out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure > > out whether further encapsulation will impact the effective MTU. > > Looking at the default value provides a good hint. > > > > If all the traffic coming into a network is at 1532 MTU (or something > > in that range) and the provider just wants headroom for PW and other > > labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes > > no difference at all. Therefore inconsistencies in values over about > > 1600 make no difference at all for such a provider. A control packet > > here or there might get fragmented but everything (except ISIS) should > > work with minor inconsistencies in the configured MTU. > > > > Curtis > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > --bcaec51f96af6e64e104e2fd56b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the RTGWG meeting, there was fairly clear interest in t= hinking about this issue. =A0Adrian also suggested discussing it with the O= PSWG. =A0I believe that Vic is looking for a co-author or so who is interes= ted in helping explore what the right thing to document or do in the IETF c= ontext.

Alia


On Fri, Aug 2, 2013 at 4:54 PM, Curtis Villamizar <c= urtis@ipv6.occnc.com> wrote:

Jeff,

OSPF does not intentionally send a full MTU sized packet as ISIS does.
The MTU is simply stated in the Database Description Packet. =A0The set
of values to use for common interfaces is stated in Path MTU Discovery
Table 1 which is cited for that reason in RFC2328 (OSPFv2). =A0If a
provider configures the nominal MTU for an OSPF interface for any
given interface type, then it doesn't matter if the vendor considers the MTU to include or exclude L3 framing or VLAN or MPLS labels.

For example, if both sides configure 1500 as the value for OSPF to
send in the Database Description Packet, then it doesn't really matter<= br> if the packet is sent over a PW and a 1500 byte packet would in fact
be fragmented along the way.

So for OSPF if the two sides are configured to the same nominal MTU,
then all is well. =A0OTOH if one has 1500 and the other side can send
Ethernet jumbo frames at nominal 9216 bytes, then the adjacency should
not come up until the problem is fixed as it would black hole traffic.

The current behavior of ISIS is arguably not broken either. =A0If one
side can send a packet that the other side will reject in error, then
a link should not come up. =A0ISIS goes through the trouble of
continuously checking the MTU (and wasting bandwidth) by padding every
LSPDU to the largest size that can be sent in addition to
negociating. =A0In practice a lot of hardware can receive packets
somewhat larger than the stated MTU but the attempt to verify MTU down
to the byte causes some problems.

My experience while at a provider was that if you figured out the
smallest practical MTU in the core and configured all interfaces to
that value so as never to fragment within the core, then OSPF always
just worked.

In both cases, it would be nice to standardize nominal MTU values,
allow negociation, and state what the MTU includes. =A0OSPF already
simply requires a nominal MTU to match eliminating the need to figure
out whether the MTU should be reduced for VLAN tag, or a label, etc.

My point was that this should be taken up in the ISIS WG and if needed
it should be taken up in the OSPF WG.

Curtis


In message <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com>
Jeff Tantsura writes:

Curtis,

In any known OSPF implementation if MTU on both sides doesn't match OSP= F will get stuck in Exchange/Exstart.

Regards,
Jeff

On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar" <curtis@ipv6.occnc.com> wrote:

>
> In message <CAG4d1rdzpGFLw1Z1XFRYgh2J1TSYS0VLbN4VmsQTLKZ= 3-tVzpQ@mail.gmail.com>
> Alia Atlas writes:
>
>> We are likely to add this draft to the list to be discussed in the=
>> meeting. =A0It is discussing some general problems with MTU
>> configuration between vendors. =A0While it discusses this for ISIS= ,
>> some aspects also apply to OSPF.
>>
>> Basically, there are three problems:
>>
>> a) Some implementations use L2 MTU and others use the L3 MTU
>> b) Different implementations pad and check for different lengths.<= br> >> =A0 Consequences are that ISIS sessions do not make it to Up.
>> c) Different numbers of MPLS labels are assumed as the max, result= ing in
>> =A0 fragmentation, and there are generally no controls for it.
>>
>> http://datatracker.ietf.org/doc/draft-liu-rtgwg-= mtu-config-ps/
>>
>> Thanks,
>> Alia
>
>
> First of all, the IGP issue is unique to ISIS and should be fixed in > ISIS. =A0ISIS pads the LSPDU fragment to the full MTU to verify that t= he
> full MTU is supported. =A0THis is a misfeature IMHO, but that is the w= ay
> it is. =A0OSPF does not have this misfeature.
>
> The reason that ISIS does this is that IP fragmentation at full line > rate is considered hard to do for high line rates relative to IP
> forwarding. =A0Some **very** old routers did this in software and woul= d
> crash if you gave them a full line rate load of packets to fragment. > The ISIS practice of padding to full MTU predated the existance of
> MPLS and any use at all of VLAN by providers (who still rarely use
> VLAN and probably never in core). =A0Many routers today can fragment a= t
> full line rate or close to it for average packet sizes (not
> tinygrams). =A0Some can't, but if the rate is very low, they shoul= d be
> avoided. =A0Providers need to test for this. =A0In modern networks, if=
> most packets are 1532 or smaller, whether the MTU is somewhat over 4K,=
> somewhat over 8K, or closer to 9K makes no difference.
>
> TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragm= ent"
> bit and looks for the ICMP Would Fragment packets as a hint to lower > the MTU. =A0ISIS could do the same.
>
> Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls > blocking all ICMP, rather than just blocking forms of ICMP that might<= br> > be in some way dangerous. =A0This problem can be avoided by sending on= ly
> some packets with "Do Not Fragment" and using SACK to figure= out that
> those are consistently getting lost (and not counting that as a drop > but rather as an indication to lower the TCP MSS value).
>
> Instead of trying to figure out the *right* value to configure, the > ISIS protocol needs to get smarter about dealing with different values=
> of MTU, including small variations created by encapsulation in MPLS. >
> IMHO this should be resubmited as a problem statement to the ISIS WG.<= br> >
> Most providers have already figured out what *they* need to configure<= br> > as the MTU on their links and do so by using either program generated<= br> > router configurations or using programs to check router configurations=
> for some level of consistency. =A0BTW- the 4470 number dates back to P= OS
> wanting to have a larger MTU than FDDI.
>
> As far as configuring a value of 4470 on all routers without ISIS
> changes, the provider must first read the vendor literature to find > out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure<= br> > out whether further encapsulation will impact the effective MTU.
> Looking at the default value provides a good hint.
>
> If all the traffic coming into a network is at 1532 MTU (or something<= br> > in that range) and the provider just wants headroom for PW and other > labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes<= br> > no difference at all. =A0Therefore inconsistencies in values over abou= t
> 1600 make no difference at all for such a provider. =A0A control packe= t
> here or there might get fragmented but everything (except ISIS) should=
> work with minor inconsistencies in the configured MTU.
>
> Curtis
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg


--bcaec51f96af6e64e104e2fd56b3-- From stephane.litkowski@orange.com Sat Aug 3 12:08:37 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC4321E809E for ; Sat, 3 Aug 2013 12:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=2.055, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q0=0.303, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNULuQcSdQlP for ; Sat, 3 Aug 2013 12:08:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 82E3C21F9FC8 for ; Sat, 3 Aug 2013 12:08:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4F78422CD8C; Sat, 3 Aug 2013 21:08:30 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 327E24C171; Sat, 3 Aug 2013 21:08:30 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Sat, 3 Aug 2013 21:08:30 +0200 From: To: "stbryant@cisco.com" Date: Sat, 3 Aug 2013 21:08:25 +0200 Subject: Remote LFA path length to PQ : draft-shen-mpls-ldp-nnhop-label Thread-Topic: Remote LFA path length to PQ : draft-shen-mpls-ldp-nnhop-label Thread-Index: Ac6QfNRY+GaCPX6xRiSIxGxZ7qr/Ag== Message-ID: <7058_1375556910_51FD552E_7058_10647_1_EEE55384044474429A926C625D0FCC81095908C351@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC81095908C351PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.3.173916 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 19:08:37 -0000 --_000_EEE55384044474429A926C625D0FCC81095908C351PUEXCB2Fnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, Regarding your comment during RTGWG on resurrecting draft-shen-mpls-ldp-nnh= op-label, here are the results of the path length to the best PQ using remo= te LFA node protection draft algorithm : Path len to PQ T1 T2 T3 T4 T5 T6 2 hops 98,78% 90,63% 90,55% 83,90% 99,86% 100,00% The results are pretty good, showing that most of the time the PQ is two ho= ps away, but there is still some situations where the PQ is more far, leadi= ng to the need of tldp session. The analysis was done on 6 topologies (diff= erent network size, network design ...), but may be the results could be wo= rst on some other types of topologies. IMHO, it would not be a good idea to mix two different mechanism with remot= e LFA (establishing TLDP session or using nnhop label) as it may complexify= the code. Moreover using nnhop label, we could imagine some situation wher= e first the PQ is two hops way leading the PLR to request NNHOP label and t= hen due to an event (metric change ?), the path to the PQ becomes 3 or 4 ho= ps away. This kind of situation would be hard to manage, so I would propose= as simplicity to keep TLDP. Moreover implementing segment routing procedur= es would permit to avoid TLDP sessions in a near future as described in STA= TUS BOF. Best Regards, Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC81095908C351PUEXCB2Fnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Stewart,
 
 
Regarding= your=20 comment during RTGWG on resurrecting draft-shen-mpls-ldp-nnhop-label, here = are=20 the results of the path length to the best PQ using remote LFA node protect= ion=20 draft algorithm :
 
Path len to PQ T1 T2 T3 T4 T5 T6
2 hops 98,78% 90,63% 90,55% 83,90% 99,86% 100,00%
 
The resul= ts are=20 pretty good, showing that most of the time the PQ is two hops away, but the= re is=20 still some situations where the PQ is more far, leading to the ne= ed of=20 tldp session. The analysis was done on 6 topologies (different network size= ,=20 network design ...), but may be the results could be worst on some other ty= pes=20 of topologies.
 
IMHO, it = would not=20 be a good idea to mix two different mechanism with remote LFA (establishing= TLDP=20 session or using nnhop label) as it may complexify the code. Moreover using= =20 nnhop label, we could imagine some situation where first the PQ is two hops= way=20 leading the PLR to request NNHOP label and then due to an event (metric cha= nge=20 ?), the path to the PQ becomes 3 or 4 hops away. This kind of situation wou= ld be=20 hard to manage, so I would propose as simplicity to keep TLDP. Moreover=20 implementing segment routing procedures would permit to avoid TLDP sessions= in a=20 near future as described in STATUS BOF.
 
 
Best=20 Regards,
 
Stephane
_______________=
___________________________________________________________________________=
_______________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_EEE55384044474429A926C625D0FCC81095908C351PUEXCB2Fnante_-- From hannes@juniper.net Mon Aug 5 00:48:09 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F5F21F9D17 for ; Mon, 5 Aug 2013 00:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q0=0.303, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+ssXCLGUERF for ; Mon, 5 Aug 2013 00:48:00 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED7721F9D11 for ; Mon, 5 Aug 2013 00:48:00 -0700 (PDT) Received: from mail90-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 07:47:59 +0000 Received: from mail90-co9 (localhost [127.0.0.1]) by mail90-co9-R.bigfish.com (Postfix) with ESMTP id 2A87E18027E for ; Mon, 5 Aug 2013 07:47:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz98dI9371Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh2a8h683h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1155h) Received-SPF: pass (mail90-co9: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=hannes@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail90-co9 (localhost.localdomain [127.0.0.1]) by mail90-co9 (MessageSwitch) id 1375688877564249_6364; Mon, 5 Aug 2013 07:47:57 +0000 (UTC) Received: from CO9EHSMHS027.bigfish.com (unknown [10.236.132.242]) by mail90-co9.bigfish.com (Postfix) with ESMTP id 864686600C0 for ; Mon, 5 Aug 2013 07:47:57 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by CO9EHSMHS027.bigfish.com (10.236.130.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 07:47:57 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 00:47:56 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Mon, 5 Aug 2013 00:47:57 -0700 Received: from DB8EHSOBE004.bigfish.com (213.199.154.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 01:01:51 -0700 Received: from mail140-db8-R.bigfish.com (10.174.8.240) by DB8EHSOBE004.bigfish.com (10.174.4.67) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 07:47:54 +0000 Received: from mail140-db8 (localhost [127.0.0.1]) by mail140-db8-R.bigfish.com (Postfix) with ESMTP id A8A931C01D9 for ; Mon, 5 Aug 2013 07:47:54 +0000 (UTC) Received: from mail140-db8 (localhost.localdomain [127.0.0.1]) by mail140-db8 (MessageSwitch) id 137568887278457_32561; Mon, 5 Aug 2013 07:47:52 +0000 (UTC) Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.230]) by mail140-db8.bigfish.com (Postfix) with ESMTP id 05752180048; Mon, 5 Aug 2013 07:47:52 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 07:47:51 +0000 Received: from smoussly-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.243.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 07:47:48 +0000 Subject: Re: Remote LFA path length to PQ : draft-shen-mpls-ldp-nnhop-label MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <7058_1375556910_51FD552E_7058_10647_1_EEE55384044474429A926C625D0FCC81095908C351@PUEXCB2F.nanterre.francetelecom.fr> Date: Mon, 5 Aug 2013 09:47:54 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <7058_1375556910_51FD552E_7058_10647_1_EEE55384044474429A926C625D0FCC81095908C351@PUEXCB2F.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Stewart Bryant \(stbryant\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 07:48:09 -0000 FWIW i agree to stephane's assertion. - SR provides us a session-less indication what the PQ->Dest SPT Transport label will be, such that implementations does not need to bring up dynamic T-LDP sessions. furthermore with SR there is no topologic assumption how far a PQ node may be located. /hannes On Aug 3, 2013, at 9:08 PM, wrote: > IMHO, it would not be a good idea to mix two different mechanism with = remote LFA (establishing TLDP session or using nnhop label) as it may = complexify the code. Moreover using nnhop label, we could imagine some = situation where first the PQ is two hops way leading the PLR to request = NNHOP label and then due to an event (metric change ?), the path to the = PQ becomes 3 or 4 hops away. This kind of situation would be hard to = manage, so I would propose as simplicity to keep TLDP. > Moreover implementing segment routing procedures would permit to avoid = TLDP sessions in a near future as described in STATUS BOF. = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^= From ginsberg@cisco.com Mon Aug 5 21:45:02 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BB521F9A16 for ; Mon, 5 Aug 2013 21:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gin1y0VojJDm for ; Mon, 5 Aug 2013 21:44:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 19ED621F99A0 for ; Mon, 5 Aug 2013 21:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8504; q=dns/txt; s=iport; t=1375764297; x=1376973897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NjYKDTE2Ocqgyk1U++85qJCZiDUqvjU0yzY2M39rxkU=; b=czenmUKQ84KVbKQ904qfPgOd1koVpdC7Fs4Lhr3/mJwxFhy7jLJxg7pp wsbScADchotrz8YEZMsMdWP9IFtJd6PL/8NRdMiSfoTRoLayIw30yFd+7 EFpKrUcXF8dsAEh3fhnxozUnHRhg/RTuphcpkDv0YVtrzuP0djBWze/qs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABx/AFKtJV2b/2dsb2JhbABbgwY1UL5tgR8WdIIkAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiHdgMPDKx6DYhejmGBBQYrBwaDE3QDmQqQJYFegTmBaAcCFyI X-IronPort-AV: E=Sophos;i="4.89,823,1367971200"; d="scan'208";a="243915287" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2013 04:44:37 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r764ibhn028430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 04:44:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 23:44:37 -0500 From: "Les Ginsberg (ginsberg)" To: "curtis@ipv6.occnc.com" , Jeff Tantsura Subject: RE: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps Thread-Index: AQHOj8LzvBSWs+AoF0yVK/iV1/SdVZmHm+kw Date: Tue, 6 Aug 2013 04:44:37 +0000 Message-ID: References: Your message of "Sat, 27 Jul 2013 16:38:18 -0000." <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> <201308022054.r72KsqYW003873@gateway1.orleans.occnc.com> In-Reply-To: <201308022054.r72KsqYW003873@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 04:45:02 -0000 First, I strongly agree w Tony Li - the inconsistent support of "mtu" confi= guration by different vendors (or even in some cases different boxes made b= y the same vendor) will not be resolved by an IETF specification - however = well motivated. Although the problems seen due to inconsistent mtu configuration may manife= st themselves as routing protocol neighbor bringup issues, this does not im= ply that the routing protocols themselves are broken and need fixing. In re= gards to IS-IS in particular I encourage people to read Sections 5 and 6 of= RFC 3719. This provides a cogent description of how several different prot= ocol parameters interact, how padding is used and why, and what protocol to= ols exist today to help prevent and detect problems related to inconsistent= MTU. If after reading the reference someone still feels that an IS-IS protocol c= hange is needed please bring it to the WG - but be prepared to be very spec= ific as to what you believe needs fixing and how you would propose to do it= , Les > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Friday, August 02, 2013 1:55 PM > To: Jeff Tantsura > Cc: rtgwg@ietf.org > Subject: Re: please read and comment on the MTU problems in draft-liu-rtg= wg- > mtu-config-ps >=20 >=20 > Jeff, >=20 > OSPF does not intentionally send a full MTU sized packet as ISIS does. > The MTU is simply stated in the Database Description Packet. The set > of values to use for common interfaces is stated in Path MTU Discovery > Table 1 which is cited for that reason in RFC2328 (OSPFv2). If a > provider configures the nominal MTU for an OSPF interface for any > given interface type, then it doesn't matter if the vendor considers > the MTU to include or exclude L3 framing or VLAN or MPLS labels. >=20 > For example, if both sides configure 1500 as the value for OSPF to > send in the Database Description Packet, then it doesn't really matter > if the packet is sent over a PW and a 1500 byte packet would in fact > be fragmented along the way. >=20 > So for OSPF if the two sides are configured to the same nominal MTU, > then all is well. OTOH if one has 1500 and the other side can send > Ethernet jumbo frames at nominal 9216 bytes, then the adjacency should > not come up until the problem is fixed as it would black hole traffic. >=20 > The current behavior of ISIS is arguably not broken either. If one > side can send a packet that the other side will reject in error, then > a link should not come up. ISIS goes through the trouble of > continuously checking the MTU (and wasting bandwidth) by padding every > LSPDU to the largest size that can be sent in addition to > negociating. In practice a lot of hardware can receive packets > somewhat larger than the stated MTU but the attempt to verify MTU down > to the byte causes some problems. >=20 > My experience while at a provider was that if you figured out the > smallest practical MTU in the core and configured all interfaces to > that value so as never to fragment within the core, then OSPF always > just worked. >=20 > In both cases, it would be nice to standardize nominal MTU values, > allow negociation, and state what the MTU includes. OSPF already > simply requires a nominal MTU to match eliminating the need to figure > out whether the MTU should be reduced for VLAN tag, or a label, etc. >=20 > My point was that this should be taken up in the ISIS WG and if needed > it should be taken up in the OSPF WG. >=20 > Curtis >=20 >=20 > In message <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> > Jeff Tantsura writes: >=20 > Curtis, >=20 > In any known OSPF implementation if MTU on both sides doesn't match OSPF = will > get stuck in Exchange/Exstart. >=20 > Regards, > Jeff >=20 > On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar" > wrote: >=20 > > > > In message tVzpQ@mail.gmail.com> > > Alia Atlas writes: > > > >> We are likely to add this draft to the list to be discussed in the > >> meeting. It is discussing some general problems with MTU > >> configuration between vendors. While it discusses this for ISIS, > >> some aspects also apply to OSPF. > >> > >> Basically, there are three problems: > >> > >> a) Some implementations use L2 MTU and others use the L3 MTU > >> b) Different implementations pad and check for different lengths. > >> Consequences are that ISIS sessions do not make it to Up. > >> c) Different numbers of MPLS labels are assumed as the max, resulting = in > >> fragmentation, and there are generally no controls for it. > >> > >> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/ > >> > >> Thanks, > >> Alia > > > > > > First of all, the IGP issue is unique to ISIS and should be fixed in > > ISIS. ISIS pads the LSPDU fragment to the full MTU to verify that the > > full MTU is supported. THis is a misfeature IMHO, but that is the way > > it is. OSPF does not have this misfeature. > > > > The reason that ISIS does this is that IP fragmentation at full line > > rate is considered hard to do for high line rates relative to IP > > forwarding. Some **very** old routers did this in software and would > > crash if you gave them a full line rate load of packets to fragment. > > The ISIS practice of padding to full MTU predated the existance of > > MPLS and any use at all of VLAN by providers (who still rarely use > > VLAN and probably never in core). Many routers today can fragment at > > full line rate or close to it for average packet sizes (not > > tinygrams). Some can't, but if the rate is very low, they should be > > avoided. Providers need to test for this. In modern networks, if > > most packets are 1532 or smaller, whether the MTU is somewhat over 4K, > > somewhat over 8K, or closer to 9K makes no difference. > > > > TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment" > > bit and looks for the ICMP Would Fragment packets as a hint to lower > > the MTU. ISIS could do the same. > > > > Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls > > blocking all ICMP, rather than just blocking forms of ICMP that might > > be in some way dangerous. This problem can be avoided by sending only > > some packets with "Do Not Fragment" and using SACK to figure out that > > those are consistently getting lost (and not counting that as a drop > > but rather as an indication to lower the TCP MSS value). > > > > Instead of trying to figure out the *right* value to configure, the > > ISIS protocol needs to get smarter about dealing with different values > > of MTU, including small variations created by encapsulation in MPLS. > > > > IMHO this should be resubmited as a problem statement to the ISIS WG. > > > > Most providers have already figured out what *they* need to configure > > as the MTU on their links and do so by using either program generated > > router configurations or using programs to check router configurations > > for some level of consistency. BTW- the 4470 number dates back to POS > > wanting to have a larger MTU than FDDI. > > > > As far as configuring a value of 4470 on all routers without ISIS > > changes, the provider must first read the vendor literature to find > > out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure > > out whether further encapsulation will impact the effective MTU. > > Looking at the default value provides a good hint. > > > > If all the traffic coming into a network is at 1532 MTU (or something > > in that range) and the provider just wants headroom for PW and other > > labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes > > no difference at all. Therefore inconsistencies in values over about > > 1600 make no difference at all for such a provider. A control packet > > here or there might get fragmented but everything (except ISIS) should > > work with minor inconsistencies in the configured MTU. > > > > Curtis > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From jeff.tantsura@ericsson.com Mon Aug 5 21:52:38 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772A221F9C89 for ; Mon, 5 Aug 2013 21:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu1cJ5Vgbp5z for ; Mon, 5 Aug 2013 21:52:33 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5E0921F9CBD for ; Mon, 5 Aug 2013 21:52:32 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-01-5200810fa46f Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.38.13034.F0180025; Tue, 6 Aug 2013 06:52:31 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 00:52:31 -0400 From: Jeff Tantsura To: "Les Ginsberg (ginsberg)" , "curtis@ipv6.occnc.com" Subject: Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps Thread-Index: AQHOkmDB6EWVyJipqE6NLoRak9R1Kw== Date: Tue, 6 Aug 2013 04:52:30 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748398AB988@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPiC5/I0OQQf8za4vJs86wWWz4s5Hd 4sKb38wOzB5Tfm9k9Viy5CeTx7L7F9kCmKO4bFJSczLLUov07RK4Mi4+v8Je8M6jon3CO5YG xjlWXYycHBICJhLzb19khLDFJC7cW8/WxcjFISRwlFHi2uGtrBDOMkaJ53dOsoNUsQkYSPz/ dpwFxBYRSJVombkByObgYBZQldi8zRYkLCwQLbHk0Fw2iJIYid7Za9ghbD2Jt3ufMIHYLAIq EvtOrwJbzCvgLXF4+W6wkZwCvhJ/358D62UEOuj7qTVg9cwC4hK3nsxngjhUQGLJnvPMELao xMvH/1hBbFGg+W3HzrBDxJUlljzZzwLRqyOxYPcnNgjbWmL1xZtQM7Ulli18zQxxg6DEyZlP WCYwis9Csm4WkvZZSNpnIWmfhaR9ASPrKkaO0uLUstx0I4NNjMBIOybBpruDcc9Ly0OM0hws SuK8q/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpg9DlwvsG+TeZCZcbGLddjFvHKCx4J F93gZPtj5l+2eFmlBGnfDVXvEtL7/vOvFy1+8fjjmv1/4zwP6Wq21gnEerxcFHE7Tr/3RnWg xYRJrwIuLayvbDpY1ru5O6N1d5vUn+uiPFMfnlC49nGvDKvH4TzLFU2Tpt44eaH0V+nsnlsu ISvvdshOVmIpzkg01GIuKk4EAHZFiZ6CAgAA Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 04:52:38 -0000 Les, I have talked to the author, he's no calling for any fixes in routing protocols but merely aiming to document how different vendors treat MTU (IP vs MPLS vs L2, etc) and trying to bring to vendor's attention how cumbersome it is to configure MTU in a multivendor environment. Cheers, Jeff -----Original Message----- From: "Les Ginsberg (ginsberg)" Date: Monday, August 5, 2013 9:44 PM To: "curtis@ipv6.occnc.com" , Jeff Tantsura Cc: "rtgwg@ietf.org" Subject: RE: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps >First, I strongly agree w Tony Li - the inconsistent support of "mtu" >configuration by different vendors (or even in some cases different boxes >made by the same vendor) will not be resolved by an IETF specification - >however well motivated. > >Although the problems seen due to inconsistent mtu configuration may >manifest themselves as routing protocol neighbor bringup issues, this >does not imply that the routing protocols themselves are broken and need >fixing. In regards to IS-IS in particular I encourage people to read >Sections 5 and 6 of RFC 3719. This provides a cogent description of how >several different protocol parameters interact, how padding is used and >why, and what protocol tools exist today to help prevent and detect >problems related to inconsistent MTU. > >If after reading the reference someone still feels that an IS-IS protocol >change is needed please bring it to the WG - but be prepared to be very >specific as to what you believe needs fixing and how you would propose to >do it, > > Les > > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf >>Of >> Curtis Villamizar >> Sent: Friday, August 02, 2013 1:55 PM >> To: Jeff Tantsura >> Cc: rtgwg@ietf.org >> Subject: Re: please read and comment on the MTU problems in >>draft-liu-rtgwg- >> mtu-config-ps >>=20 >>=20 >> Jeff, >>=20 >> OSPF does not intentionally send a full MTU sized packet as ISIS does. >> The MTU is simply stated in the Database Description Packet. The set >> of values to use for common interfaces is stated in Path MTU Discovery >> Table 1 which is cited for that reason in RFC2328 (OSPFv2). If a >> provider configures the nominal MTU for an OSPF interface for any >> given interface type, then it doesn't matter if the vendor considers >> the MTU to include or exclude L3 framing or VLAN or MPLS labels. >>=20 >> For example, if both sides configure 1500 as the value for OSPF to >> send in the Database Description Packet, then it doesn't really matter >> if the packet is sent over a PW and a 1500 byte packet would in fact >> be fragmented along the way. >>=20 >> So for OSPF if the two sides are configured to the same nominal MTU, >> then all is well. OTOH if one has 1500 and the other side can send >> Ethernet jumbo frames at nominal 9216 bytes, then the adjacency should >> not come up until the problem is fixed as it would black hole traffic. >>=20 >> The current behavior of ISIS is arguably not broken either. If one >> side can send a packet that the other side will reject in error, then >> a link should not come up. ISIS goes through the trouble of >> continuously checking the MTU (and wasting bandwidth) by padding every >> LSPDU to the largest size that can be sent in addition to >> negociating. In practice a lot of hardware can receive packets >> somewhat larger than the stated MTU but the attempt to verify MTU down >> to the byte causes some problems. >>=20 >> My experience while at a provider was that if you figured out the >> smallest practical MTU in the core and configured all interfaces to >> that value so as never to fragment within the core, then OSPF always >> just worked. >>=20 >> In both cases, it would be nice to standardize nominal MTU values, >> allow negociation, and state what the MTU includes. OSPF already >> simply requires a nominal MTU to match eliminating the need to figure >> out whether the MTU should be reduced for VLAN tag, or a label, etc. >>=20 >> My point was that this should be taken up in the ISIS WG and if needed >> it should be taken up in the OSPF WG. >>=20 >> Curtis >>=20 >>=20 >> In message <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> >> Jeff Tantsura writes: >>=20 >> Curtis, >>=20 >> In any known OSPF implementation if MTU on both sides doesn't match >>OSPF will >> get stuck in Exchange/Exstart. >>=20 >> Regards, >> Jeff >>=20 >> On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar" >> wrote: >>=20 >> > >> > In message > tVzpQ@mail.gmail.com> >> > Alia Atlas writes: >> > >> >> We are likely to add this draft to the list to be discussed in the >> >> meeting. It is discussing some general problems with MTU >> >> configuration between vendors. While it discusses this for ISIS, >> >> some aspects also apply to OSPF. >> >> >> >> Basically, there are three problems: >> >> >> >> a) Some implementations use L2 MTU and others use the L3 MTU >> >> b) Different implementations pad and check for different lengths. >> >> Consequences are that ISIS sessions do not make it to Up. >> >> c) Different numbers of MPLS labels are assumed as the max, >>resulting in >> >> fragmentation, and there are generally no controls for it. >> >> >> >> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/ >> >> >> >> Thanks, >> >> Alia >> > >> > >> > First of all, the IGP issue is unique to ISIS and should be fixed in >> > ISIS. ISIS pads the LSPDU fragment to the full MTU to verify that the >> > full MTU is supported. THis is a misfeature IMHO, but that is the way >> > it is. OSPF does not have this misfeature. >> > >> > The reason that ISIS does this is that IP fragmentation at full line >> > rate is considered hard to do for high line rates relative to IP >> > forwarding. Some **very** old routers did this in software and would >> > crash if you gave them a full line rate load of packets to fragment. >> > The ISIS practice of padding to full MTU predated the existance of >> > MPLS and any use at all of VLAN by providers (who still rarely use >> > VLAN and probably never in core). Many routers today can fragment at >> > full line rate or close to it for average packet sizes (not >> > tinygrams). Some can't, but if the rate is very low, they should be >> > avoided. Providers need to test for this. In modern networks, if >> > most packets are 1532 or smaller, whether the MTU is somewhat over 4K, >> > somewhat over 8K, or closer to 9K makes no difference. >> > >> > TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment" >> > bit and looks for the ICMP Would Fragment packets as a hint to lower >> > the MTU. ISIS could do the same. >> > >> > Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls >> > blocking all ICMP, rather than just blocking forms of ICMP that might >> > be in some way dangerous. This problem can be avoided by sending only >> > some packets with "Do Not Fragment" and using SACK to figure out that >> > those are consistently getting lost (and not counting that as a drop >> > but rather as an indication to lower the TCP MSS value). >> > >> > Instead of trying to figure out the *right* value to configure, the >> > ISIS protocol needs to get smarter about dealing with different values >> > of MTU, including small variations created by encapsulation in MPLS. >> > >> > IMHO this should be resubmited as a problem statement to the ISIS WG. >> > >> > Most providers have already figured out what *they* need to configure >> > as the MTU on their links and do so by using either program generated >> > router configurations or using programs to check router configurations >> > for some level of consistency. BTW- the 4470 number dates back to POS >> > wanting to have a larger MTU than FDDI. >> > >> > As far as configuring a value of 4470 on all routers without ISIS >> > changes, the provider must first read the vendor literature to find >> > out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure >> > out whether further encapsulation will impact the effective MTU. >> > Looking at the default value provides a good hint. >> > >> > If all the traffic coming into a network is at 1532 MTU (or something >> > in that range) and the provider just wants headroom for PW and other >> > labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes >> > no difference at all. Therefore inconsistencies in values over about >> > 1600 make no difference at all for such a provider. A control packet >> > here or there might get fragmented but everything (except ISIS) should >> > work with minor inconsistencies in the configured MTU. >> > >> > Curtis >> > _______________________________________________ >> > rtgwg mailing list >> > rtgwg@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtgwg >>=20 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg From ginsberg@cisco.com Mon Aug 5 21:57:00 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF63521F9F5F for ; Mon, 5 Aug 2013 21:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMt5t0H0vYzP for ; Mon, 5 Aug 2013 21:56:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B510B21F9F80 for ; Mon, 5 Aug 2013 21:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10491; q=dns/txt; s=iport; t=1375765015; x=1376974615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RUktiQ65dcLv71hED+wMEiFs6gsxA2v3oVZ/JMTmKZY=; b=gqkUiSNuKukP6ZRESbjN/5SF2ObWm08JuQuGUpOG4nUMOynuEuuLRiX3 /xZclNsnlgD14XeJjP6YSFmp84panLMHmwDr7iemlgBWVe7iLWfr+Q8dm GMn+Cn95sneBtozAhiNQg8pmnFebrc3sFMXorIK4cPI1Vkmws+5st3N+Z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAL6AAFKtJV2a/2dsb2JhbABbgwY1UL5tgR8WdIIkAQEBAwEBAQEaHTQLDAQCAQgRAwEBAQEKFAkHJwsUCQgCBAENBQiHdgMJBgysew2IXo5hgQUGKwcGgxN0A5kKkCWBXoE5gWgHAhci X-IronPort-AV: E=Sophos;i="4.89,823,1367971200"; d="scan'208";a="243900752" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 06 Aug 2013 04:56:55 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r764usKl008593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 04:56:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 23:56:54 -0500 From: "Les Ginsberg (ginsberg)" To: Jeff Tantsura , "curtis@ipv6.occnc.com" Subject: RE: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps Thread-Topic: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps Thread-Index: AQHOkmDDxEB5cTrkyEy36lOQuUGcCJmHnMOA Date: Tue, 6 Aug 2013 04:56:53 +0000 Message-ID: References: <60DEDD93F5E54B4AB55647B8B6C748398AB988@eusaamb109.ericsson.se> In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C748398AB988@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 04:57:00 -0000 Jeff - I have the same impression as regards draft-liu-rtgwg-mtu-config-ps as you = just confirmed. However, this thread has included some specific statements = regarding OSPF/IS-IS (NOT by the draft authors). My remarks regarding routi= ng protocols are in response to those statements - not in response to the d= raft. Frankly I think the routing protocol discussion has taken us off topi= c. Les > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Monday, August 05, 2013 9:53 PM > To: Les Ginsberg (ginsberg); curtis@ipv6.occnc.com > Cc: rtgwg@ietf.org > Subject: Re: please read and comment on the MTU problems in draft-liu-rtg= wg- > mtu-config-ps >=20 > Les, >=20 > I have talked to the author, he's no calling for any fixes in routing > protocols but merely aiming to document how different vendors treat MTU > (IP vs MPLS vs L2, etc) and trying to bring to vendor's attention how > cumbersome it is to configure MTU in a multivendor environment. >=20 > Cheers, > Jeff >=20 >=20 > -----Original Message----- > From: "Les Ginsberg (ginsberg)" > Date: Monday, August 5, 2013 9:44 PM > To: "curtis@ipv6.occnc.com" , Jeff Tantsura > > Cc: "rtgwg@ietf.org" > Subject: RE: please read and comment on the MTU problems > in draft-liu-rtgwg-mtu-config-ps >=20 > >First, I strongly agree w Tony Li - the inconsistent support of "mtu" > >configuration by different vendors (or even in some cases different boxe= s > >made by the same vendor) will not be resolved by an IETF specification - > >however well motivated. > > > >Although the problems seen due to inconsistent mtu configuration may > >manifest themselves as routing protocol neighbor bringup issues, this > >does not imply that the routing protocols themselves are broken and need > >fixing. In regards to IS-IS in particular I encourage people to read > >Sections 5 and 6 of RFC 3719. This provides a cogent description of how > >several different protocol parameters interact, how padding is used and > >why, and what protocol tools exist today to help prevent and detect > >problems related to inconsistent MTU. > > > >If after reading the reference someone still feels that an IS-IS protoco= l > >change is needed please bring it to the WG - but be prepared to be very > >specific as to what you believe needs fixing and how you would propose t= o > >do it, > > > > Les > > > > > >> -----Original Message----- > >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > >>Of > >> Curtis Villamizar > >> Sent: Friday, August 02, 2013 1:55 PM > >> To: Jeff Tantsura > >> Cc: rtgwg@ietf.org > >> Subject: Re: please read and comment on the MTU problems in > >>draft-liu-rtgwg- > >> mtu-config-ps > >> > >> > >> Jeff, > >> > >> OSPF does not intentionally send a full MTU sized packet as ISIS does. > >> The MTU is simply stated in the Database Description Packet. The set > >> of values to use for common interfaces is stated in Path MTU Discovery > >> Table 1 which is cited for that reason in RFC2328 (OSPFv2). If a > >> provider configures the nominal MTU for an OSPF interface for any > >> given interface type, then it doesn't matter if the vendor considers > >> the MTU to include or exclude L3 framing or VLAN or MPLS labels. > >> > >> For example, if both sides configure 1500 as the value for OSPF to > >> send in the Database Description Packet, then it doesn't really matter > >> if the packet is sent over a PW and a 1500 byte packet would in fact > >> be fragmented along the way. > >> > >> So for OSPF if the two sides are configured to the same nominal MTU, > >> then all is well. OTOH if one has 1500 and the other side can send > >> Ethernet jumbo frames at nominal 9216 bytes, then the adjacency should > >> not come up until the problem is fixed as it would black hole traffic. > >> > >> The current behavior of ISIS is arguably not broken either. If one > >> side can send a packet that the other side will reject in error, then > >> a link should not come up. ISIS goes through the trouble of > >> continuously checking the MTU (and wasting bandwidth) by padding every > >> LSPDU to the largest size that can be sent in addition to > >> negociating. In practice a lot of hardware can receive packets > >> somewhat larger than the stated MTU but the attempt to verify MTU down > >> to the byte causes some problems. > >> > >> My experience while at a provider was that if you figured out the > >> smallest practical MTU in the core and configured all interfaces to > >> that value so as never to fragment within the core, then OSPF always > >> just worked. > >> > >> In both cases, it would be nice to standardize nominal MTU values, > >> allow negociation, and state what the MTU includes. OSPF already > >> simply requires a nominal MTU to match eliminating the need to figure > >> out whether the MTU should be reduced for VLAN tag, or a label, etc. > >> > >> My point was that this should be taken up in the ISIS WG and if needed > >> it should be taken up in the OSPF WG. > >> > >> Curtis > >> > >> > >> In message <88F3367D-A533-4790-81BD-4778A68052ED@ericsson.com> > >> Jeff Tantsura writes: > >> > >> Curtis, > >> > >> In any known OSPF implementation if MTU on both sides doesn't match > >>OSPF will > >> get stuck in Exchange/Exstart. > >> > >> Regards, > >> Jeff > >> > >> On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar" > >> wrote: > >> > >> > > >> > In message >> tVzpQ@mail.gmail.com> > >> > Alia Atlas writes: > >> > > >> >> We are likely to add this draft to the list to be discussed in the > >> >> meeting. It is discussing some general problems with MTU > >> >> configuration between vendors. While it discusses this for ISIS, > >> >> some aspects also apply to OSPF. > >> >> > >> >> Basically, there are three problems: > >> >> > >> >> a) Some implementations use L2 MTU and others use the L3 MTU > >> >> b) Different implementations pad and check for different lengths. > >> >> Consequences are that ISIS sessions do not make it to Up. > >> >> c) Different numbers of MPLS labels are assumed as the max, > >>resulting in > >> >> fragmentation, and there are generally no controls for it. > >> >> > >> >> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/ > >> >> > >> >> Thanks, > >> >> Alia > >> > > >> > > >> > First of all, the IGP issue is unique to ISIS and should be fixed in > >> > ISIS. ISIS pads the LSPDU fragment to the full MTU to verify that t= he > >> > full MTU is supported. THis is a misfeature IMHO, but that is the w= ay > >> > it is. OSPF does not have this misfeature. > >> > > >> > The reason that ISIS does this is that IP fragmentation at full line > >> > rate is considered hard to do for high line rates relative to IP > >> > forwarding. Some **very** old routers did this in software and woul= d > >> > crash if you gave them a full line rate load of packets to fragment. > >> > The ISIS practice of padding to full MTU predated the existance of > >> > MPLS and any use at all of VLAN by providers (who still rarely use > >> > VLAN and probably never in core). Many routers today can fragment a= t > >> > full line rate or close to it for average packet sizes (not > >> > tinygrams). Some can't, but if the rate is very low, they should be > >> > avoided. Providers need to test for this. In modern networks, if > >> > most packets are 1532 or smaller, whether the MTU is somewhat over 4= K, > >> > somewhat over 8K, or closer to 9K makes no difference. > >> > > >> > TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment= " > >> > bit and looks for the ICMP Would Fragment packets as a hint to lower > >> > the MTU. ISIS could do the same. > >> > > >> > Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls > >> > blocking all ICMP, rather than just blocking forms of ICMP that migh= t > >> > be in some way dangerous. This problem can be avoided by sending on= ly > >> > some packets with "Do Not Fragment" and using SACK to figure out tha= t > >> > those are consistently getting lost (and not counting that as a drop > >> > but rather as an indication to lower the TCP MSS value). > >> > > >> > Instead of trying to figure out the *right* value to configure, the > >> > ISIS protocol needs to get smarter about dealing with different valu= es > >> > of MTU, including small variations created by encapsulation in MPLS. > >> > > >> > IMHO this should be resubmited as a problem statement to the ISIS WG= . > >> > > >> > Most providers have already figured out what *they* need to configur= e > >> > as the MTU on their links and do so by using either program generate= d > >> > router configurations or using programs to check router configuratio= ns > >> > for some level of consistency. BTW- the 4470 number dates back to P= OS > >> > wanting to have a larger MTU than FDDI. > >> > > >> > As far as configuring a value of 4470 on all routers without ISIS > >> > changes, the provider must first read the vendor literature to find > >> > out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figur= e > >> > out whether further encapsulation will impact the effective MTU. > >> > Looking at the default value provides a good hint. > >> > > >> > If all the traffic coming into a network is at 1532 MTU (or somethin= g > >> > in that range) and the provider just wants headroom for PW and other > >> > labels, whether the MTU on some links is 4470 or 4484 (or 9180) make= s > >> > no difference at all. Therefore inconsistencies in values over abou= t > >> > 1600 make no difference at all for such a provider. A control packe= t > >> > here or there might get fragmented but everything (except ISIS) shou= ld > >> > work with minor inconsistencies in the configured MTU. > >> > > >> > Curtis > >> > _______________________________________________ > >> > rtgwg mailing list > >> > rtgwg@ietf.org > >> > https://www.ietf.org/mailman/listinfo/rtgwg > >> > >> _______________________________________________ > >> rtgwg mailing list > >> rtgwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtgwg From stephane.litkowski@orange.com Wed Aug 7 01:51:45 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFAF21E809D for ; Wed, 7 Aug 2013 01:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=1.795, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4QXR8pX2MCa for ; Wed, 7 Aug 2013 01:51:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC9021E80C9 for ; Wed, 7 Aug 2013 01:51:34 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0C2632DC3DE; Wed, 7 Aug 2013 10:51:31 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2AB0E4C1F0; Wed, 7 Aug 2013 10:50:40 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 7 Aug 2013 10:50:38 +0200 From: To: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" Date: Wed, 7 Aug 2013 10:50:37 +0200 Subject: RE: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Topic: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions Thread-Index: Ac6PoWfOXipOfgsHRLS9x1gjiKUggwDqLL9g Message-ID: <29572_1375865490_52020A76_29572_1_5_EEE55384044474429A926C625D0FCC81095B823E64@PUEXCB2F.nanterre.francetelecom.fr> References: <201308021646.r72GkY1R001966@gateway1.orleans.occnc.com> <51FBE4E9.5080404@tmit.bme.hu> In-Reply-To: <51FBE4E9.5080404@tmit.bme.hu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC81095B823E64PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 08:51:46 -0000 --_000_EEE55384044474429A926C625D0FCC81095B823E64PUEXCB2Fnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors and Chairs, Regarding remote LFA draft, I would hope to see some points addressed in th= e draft before going to WGLC. - It would be good to add some simulation results about how much TLDP sessi= on are required (TX and TX+RX), this in order to make people aware on how m= uch rLFA may impact their TLDP session scaling - We already raised the point some months ago about possibly "interop" issu= es in the following cases : * PLR choose a PQ which is not able to accept TLDP session : we verifie= d it in a lab, and we can clearly fall into such situation in a live networ= k, leading to protection not available. * PQ having multiple IP addresses /32 attached, so which one would be u= sed to establish TLDP session ? Current implementations are using some heur= istics and it would be good to document this - Current text states that rLFA is computed only when LFA are not available= and our analysis pointed that this is really not a good idea as in term of= manageability rLFA alternate may be better than LFA alternate. It would be= good that rLFA draft points to potential manageability issues and refers t= o the appropriate draft. Thanks, Best Regards, Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC81095B823E64PUEXCB2Fnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Authors and Chairs,
 
Regarding remote LFA draft, I would hope to see = some=20 points addressed in the draft before going to WGLC.
-=20 It would be good to add some simulation results about how much TLDP session= are=20 required (TX and TX+RX), this in order to make people aware on how much rLF= A may=20 impact their TLDP session scaling
 
-=20 We already raised the point some months ago about possibly "interop" issues= in=20 the following cases :
    * PLR choose a PQ which is no= t able=20 to accept TLDP session : we verified it in a lab, and we can clearly fall i= nto=20 such situation in a live network, leading to protection not=20 available.
 
    * PQ having multiple IP addre= sses=20 /32 attached, so which one would be used to establish TLDP session ? Curren= t=20 implementations are using some heuristics and it would be good to document= =20 this
 
-=20 Current text states that rLFA is computed only when LFA are not available a= nd=20 our analysis pointed that this is really not a good idea as in term of=20 manageability rLFA alternate may be better than LFA alternate. It would be = good=20 that rLFA draft points to potential manageability issues and refers to the= =20 appropriate draft.
 
 
Thanks,
 
Best Regards,
 
Stephane
 
 
 
___________________________________=
___________________________________________________________________________=
___________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_EEE55384044474429A926C625D0FCC81095B823E64PUEXCB2Fnante_-- From fred@cisco.com Tue Aug 13 10:38:30 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936E321E80E8 for ; Tue, 13 Aug 2013 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwRs8uYV+0eH for ; Tue, 13 Aug 2013 10:38:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4403821E80DA for ; Tue, 13 Aug 2013 10:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1428; q=dns/txt; s=iport; t=1376415505; x=1377625105; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=ULr41hgcneiFU//3Xy0Yyvdl/FxrS+rFePTOGZFu9ro=; b=mNXwlM7kQ7EMTwII3A/XUD25eqbImdpNrRMo9b2P8YcHCQ6s4iVVFAg3 P+kJ1tZwZXeZ6mTzdjfupRCBOmZbIr9DS8vWoMh9qWHosuhmCVmcjRLP2 R1LeUq1176DabFEHTdMttRYCUhv+g2d4PZXLkxC9Bjyr5jv8YRk64mbfQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwGABxuClKtJXG//2dsb2JhbABbgwY1UL5egSIWbQeCJAEBAQMBOj8FCwIBGQMBAgsUEDIdCAIEDgUIAYgBBgy4CJALMYMidgOZEZAkgxuCKg X-IronPort-AV: E=Sophos;i="4.89,871,1367971200"; d="scan'208";a="246649299" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 13 Aug 2013 17:38:24 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7DHcOt1014123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 17:38:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 12:38:24 -0500 From: "Fred Baker (fred)" To: "rtgwg@ietf.org" Subject: Source/Destination Routing: draft-baker-rtgwg-src-dst-routing-use-cases-00.txt Thread-Topic: Source/Destination Routing: draft-baker-rtgwg-src-dst-routing-use-cases-00.txt Thread-Index: AQHOmEvoM08hyyts1UOMngjOpevW+A== Date: Tue, 13 Aug 2013 17:38:23 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9837FB@xmb-rcd-x09.cisco.com> References: <20130813173108.25342.12507.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Xia Yin , Shu Yang , "Ole Troan \(otroan\)" , "Markus Stenberg -X \(mstenber - DIGITAL-X INC at Cisco\)" , Lorenzo Colitti X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:38:30 -0000 We would be interested in your comments. > From: > Subject: New Version Notification for draft-baker-rtgwg-src-dst-routing-u= se-cases-00.txt > Date: August 13, 2013 10:31:08 AM PDT > To: Fred Baker >=20 >=20 > A new version of I-D, draft-baker-rtgwg-src-dst-routing-use-cases-00.txt > has been successfully submitted by Fred Baker and posted to the > IETF repository. >=20 > Filename: draft-baker-rtgwg-src-dst-routing-use-cases > Revision: 00 > Title: Requirements and Use Cases for Source/Destination Routing > Creation date: 2013-08-13 > Group: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-baker-rtgwg-sr= c-dst-routing-use-cases-00.txt > Status: http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-ds= t-routing-use-cases > Htmlized: http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-rou= ting-use-cases-00 >=20 >=20 > Abstract: > This note attempts to capture important use cases for source/ > destination routing. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies From fred@cisco.com Fri Aug 16 13:34:59 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7722321F9DB8 for ; Fri, 16 Aug 2013 13:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7Zb+VShC3os for ; Fri, 16 Aug 2013 13:34:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5C11E8167 for ; Fri, 16 Aug 2013 13:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6480; q=dns/txt; s=iport; t=1376685294; x=1377894894; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UDyMQWm77PZi/G7MfqQcRcA0SSj1wMTlvCVcqBgUalM=; b=U3b8bApdRfO1WwUhNvtuUTYRjV0K0KcBBhfFmcNNDpN+2sDQadsif3PU yBGJaAzBJRZLHzVtqF+3+POf0yFLwKroXCgGkwPUm52sqUSQ1n1Wtasoi zINrwc/2Vm95NGYBYMwBsaVUQxHPoTgcLNE8T/ZbXXGL4kfy6cWaqBfWS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEHAEyMDlKtJXG+/2dsb2JhbABbgwY1Ub8ggSsWbQeCIAQBAQEDATo9EgIBCCIUEDIlAgQTCAEShS4HgiEZBgy5OI8DEIEKAjiDG3cDmRGQKIFhgTuBcTk X-IronPort-AV: E=Sophos;i="4.89,897,1367971200"; d="scan'208";a="248306184" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 16 Aug 2013 20:34:54 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7GKYrEs029778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Aug 2013 20:34:53 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 15:34:53 -0500 From: "Fred Baker (fred)" To: "rtgwg@ietf.org" Subject: Re: New Version Notification for draft-baker-rtgwg-src-dst-routing-use-cases-00.txt Thread-Topic: New Version Notification for draft-baker-rtgwg-src-dst-routing-use-cases-00.txt Thread-Index: AQHOmErm8F0IiMSiR0qHnl4PyiwNRJmYo1mA Date: Fri, 16 Aug 2013 20:34:53 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B99B950@xmb-rcd-x09.cisco.com> References: <20130813173108.25342.12507.idtracker@ietfa.amsl.com> In-Reply-To: <20130813173108.25342.12507.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <80A57AB7458952418EAFF8DB095A661E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 20:34:59 -0000 Let me add some information regarding source/destination routing that may b= e useful for context. This note, and its associated discussion, is an outcome from homenet. Homen= et is chartered to describe the tools and technologies needed in an IPv6 ho= me network. One of the issues has been egress routing in a multi-homed netw= ork. Since homenet is not chartered to actually develop routing protocols, = and is working with ospf among others, it seems like the discussion of sour= ce/destination routing should move to rtgwg. You saw my note to rtgwg earli= er in the week; the folks copied on it and I, along with the homenet chairs= and Acee Lindem from OSPF, came up with this document to present a use cas= e discussion. As to the details of the discussion, a number of people have been working o= n the concept of source/destination routing. The first requirement is in eg= ress routing, which Petri Helenius and I played with in RFC 3704. That part= icular project was a bit confusing for me; I was working on something else = (which became RFC 4192 in the fullness of time), and he (as working group c= hair) kept sending me private mail about BCP 38, PA prefixes, uRPF, and get= ting packets to an ISP that was not going to drop them. I finally combined = his email train into one note and sent it to him to post.=20 Here's the deal. Suppose you have a network with two or more upstreams, and= you are using a provider-allocated prefix from each to number your network= : ,-------. ,-' `-. ,---. ,-----. ,' `. / \ +-+ ,' `. / \ / +---+R+-+ ISP 1 --+--- \ / \ +-+ `. ,' ; : ; Customer : `-----' | The Internet | | Network | ,-----. : ; : ; +-+ ,' `. \ / \ +--+R+-+ ISP 2 ---+-- / \ / +-+ `. ,' `. ,' \ / `-----' '-. ,-' `---' `-------' If a host has multiple addresses on every interface, one from each upstream= , and no other information to bias its choice (remember that hosts know lit= tle or nothing about routing apart from being able to calculate that one of= their addresses may be more similar to one of the target's address than an= other), the address it chooses is a coin toss. In a standard network, howev= er, the network probably has a default route to follow, and will deliver a = packet to one of those upstreams. If the upstream has BCP 38 filtering enab= led (and let's hope it does), that gives the host a 1/N probability of sele= cting an address that will in fact get the packet past the filter. Wouldn't= it be nice if somehow it could either select the right address in the firs= t place, or could be assured that the network would get the packet it sent,= with the address it chose, to the upstream that would not discard it? And = wouldn't it be nice if we could automate that in routing, rather than makin= g the administrator manually configure every router to do something like PB= R or MTR? There are a number of proposals in the IETF right now, which I'll list. The= question was raised at IETF 87 whether we could have a common document to = discuss use cases, to ensure that the solutions we develop actually solve t= he problem in question. This document describes the use cases we came up wi= th, and the requirements we drew out of them. http://tools.ietf.org/html/draft-chroboczek-babel-extension-mechanism "Extension Mechanism for the Babel Routing Protocol", Juliusz Chroboczek, 2013-06-30 http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication "Babel HMAC Cryptographic Authentication", Denis Ovsienko, 2013-04-18 http://tools.ietf.org/html/draft-troan-homenet-sadr "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole Troan, Lorenzo Colitti, 2013-02-18 http://tools.ietf.org/html/draft-xu-homenet-traffic-class "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang, Jianping Wu, Fred Baker, 2013-07-15 http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu Yang, Jianping Wu, Dan Wang, 2013-02-18 http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing "Using IS-IS with Role-Based Access Control", Fred Baker, 2013-02-17 http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 2013-02-17 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing "Using OSPFv3 with Role-Based Access Control", Fred Baker, 2013-05-02 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-05-02 http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases "Requirements and Use Cases for Source/Destination Routing", Fred Baker, 2013-08-13 On Aug 13, 2013, at 10:31 AM, internet-drafts@ietf.org wrote: >=20 > A new version of I-D, draft-baker-rtgwg-src-dst-routing-use-cases-00.txt > has been successfully submitted by Fred Baker and posted to the > IETF repository. >=20 > Filename: draft-baker-rtgwg-src-dst-routing-use-cases > Revision: 00 > Title: Requirements and Use Cases for Source/Destination Routing > Creation date: 2013-08-13 > Group: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-baker-rtgwg-sr= c-dst-routing-use-cases-00.txt > Status: http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-ds= t-routing-use-cases > Htmlized: http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-rou= ting-use-cases-00 >=20 >=20 > Abstract: > This note attempts to capture important use cases for source/ > destination routing. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein From aretana@cisco.com Tue Aug 20 05:46:33 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5435011E8219 for ; Tue, 20 Aug 2013 05:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpcO8WA5ZvHP for ; Tue, 20 Aug 2013 05:46:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C045811E80D9 for ; Tue, 20 Aug 2013 05:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1275; q=dns/txt; s=iport; t=1377002784; x=1378212384; h=from:to:subject:date:message-id:mime-version; bh=BU8LQbBVFyFUqDPfQ512+N3RZ+wBQZvbY1Hm5VE5A1M=; b=OlCRjaDRgKAWSXvByT0ZUpjJEeXfdYjdzAoPnMFYCzYHeYHHyX5mJGdG gUfoIn9u/RIedp9CwysKr64gCTpsm2mKqHFmP6eikQC/u4QgazxFrJVPL N5S9lVQRp7JQvZPZaa/zA0x8aA4rpdnEMYUOcMPQT66WPXn7pDQmSUQ2J 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAGBkE1KtJXG9/2dsb2JhbABagkFENVGCU4FlsmiINIEjFm0HghsLAQSBCwELAR5WJwQbAYgHDJJxmV2QK4NTdwOpOYMcgio X-IronPort-AV: E=Sophos;i="4.89,920,1367971200"; d="scan'208,217";a="246418055" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 20 Aug 2013 12:46:22 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7KCkMxF011523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Aug 2013 12:46:22 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.182]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 07:46:22 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: rtgwg Draft Minutes (IETF 87) Thread-Topic: rtgwg Draft Minutes (IETF 87) Thread-Index: AQHOnaNGV6b+Kckl4E662udqvJmV3Q== Date: Tue, 20 Aug 2013 12:46:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E28FFAAADxmbalnx15ciscoc_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 12:46:33 -0000 --_000_BBD66FD99311804F80324E8139B3C94E28FFAAADxmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! I just posted the draft minutes from Berlin. Thanks to Acee for being pour= scribe. http://www.ietf.org/proceedings/87/minutes/minutes-87-rtgwg Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E28FFAAADxmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <9D943B2AEFF1C04A8C413B9B65E658BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

I just posted the draft minutes from Berlin.  Thanks to Acee for = being pour scribe.


Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E28FFAAADxmbalnx15ciscoc_-- From aretana@cisco.com Thu Aug 29 08:02:39 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B58E21F81FF for ; Thu, 29 Aug 2013 08:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6BU1HkqTJZH for ; Thu, 29 Aug 2013 08:02:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 83BF821F9BC1 for ; Thu, 29 Aug 2013 08:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=399; q=dns/txt; s=iport; t=1377788545; x=1378998145; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=lj7YoWXfPL6vt5WGt3vEUzcdJ9QLNVLrK7VEEF4jMzI=; b=DZrRwBQYI8bGwq91eFKiqb7+/n3WtKa3FUl8D8xrpq+7ySZZnHL+JEvS nILxPSoL3LHozM/Kih1zkd9F8PyN+Odiop2UJ9diev1F3VmH+OXEMT6B4 tOTXLh47lKNCKgUU3FpiEz6rts2kKmNpF5hKto/W4nVO5yGxzEsA38NUt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMGAMRhH1KtJXHA/2dsb2JhbABagweBBoJgvVeBJxZtB4IkAQEBBDpRAQgiFEIbAQYDAgQTCId5mBWhKY47gQg4gxyBAAOpWYMggXE5 X-IronPort-AV: E=Sophos;i="4.89,984,1367971200"; d="scan'208";a="252985938" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 29 Aug 2013 15:02:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7TF2N58024868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Aug 2013 15:02:23 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.182]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 10:02:23 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: FW: Mail lost yesterday Thread-Topic: Mail lost yesterday Thread-Index: AQIiuf/NPVJ0u+Yu4la7frHQKSZfMpkEGL+ggAAVhYA= Date: Thu, 29 Aug 2013 15:02:23 +0000 Message-ID: In-Reply-To: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:02:39 -0000 FYI On 8/29/13 10:46 AM, "Adrian Farrel" wrote: >For those of you who haven't noticed the message from Steve Young in >your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific >Time yesterday seems to have been lost. Aside from needing to re-send >all mail you personally sent during that time period, you also need to >inform your working groups. >