From nobody Fri Jul 1 02:45:16 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEF812D516 for ; Fri, 1 Jul 2016 02:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUSxeEtmBV0K for ; Fri, 1 Jul 2016 02:45:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D2FED12D512 for ; Fri, 1 Jul 2016 02:45:12 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4FD2ADB48E755 for ; Fri, 1 Jul 2016 17:45:08 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id A5F011A7EE861; Fri, 1 Jul 2016 17:45:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u619iuKW030361; Fri, 1 Jul 2016 17:44:56 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: "Les Ginsberg (ginsberg)" MIME-Version: 1.0 X-KeepSent: B95E67D7:B48D769D-48257FE3:002D1682; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Fri, 1 Jul 2016 17:45:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-01 17:44:56, Serialize complete at 2016-07-01 17:44:56 Content-Type: multipart/alternative; boundary="=_alternative 00358DCA48257FE3_=" X-MAIL: mse01.zte.com.cn u619iuKW030361 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 09:45:15 -0000 This is a multipart message in MIME format. --=_alternative 00358DCA48257FE3_= Content-Type: text/plain; charset="US-ASCII" His Les, 1) From implementation, because preference algorithm is protocol independent, it is better to do conflict resolution at a common place, not at individual protocol instance. For example, we can do prefix-conflict resolution when generate the preference FIB entry at the common place. For a preference FIB entry, the routing information may get from OSPF by administrative distance, but the SID information may get from ISIS by prefix-conflict algorithm. Then we can do sid-conflict resolution when generate the SID-LIB entry according to the above FIB entry and other sources, it will select a preference FEC to provide forwarding information. So, preference algorithm per prefix/fec is enough. Per range is possible, but implementation is complex. More complex is for "ignor overlay" per range. 2) The restrictions in new section "Scope of SR-MPLS SID Conflicts" maybe not true. Please just consider "Carrier of Carrier" case which deploy IGP+LDP between PE and CE. It is possible to deploy SR LSP in the second level carrier, so that an SR LSP is building from one site to another across the first level carrier, same as an LDP LSP. This means SIDs associated with destinations in Site A will be installed in the forwarding plane of routers in Site B. Thanks Deccan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 00358DCA48257FE3_= Content-Type: text/html; charset="US-ASCII" His Les,

1) From implementation, because preference algorithm is protocol independent, it is better to do conflict resolution at a common place, not at individual protocol instance. For example, we can do prefix-conflict resolution when generate the preference FIB entry at the common place. For a preference FIB entry, the routing information may get from OSPF by administrative distance, but the SID information may get from ISIS by prefix-conflict algorithm. Then we can do sid-conflict resolution when generate the SID-LIB entry according to the above FIB entry and other sources, it will select a preference FEC to provide forwarding information.
So, preference algorithm per prefix/fec is enough. Per range is possible, but implementation is complex. More complex is for "ignor overlay" per range.

2) The restrictions in new section "Scope of SR-MPLS SID Conflicts" maybe not true. Please just consider "Carrier of Carrier" case which deploy IGP+LDP between PE and CE. It is possible to deploy SR LSP in the second level carrier, so that an SR LSP is building from one site to another across the first level carrier, same as an LDP LSP. This means SIDs associated with destinations in Site A will be installed in the forwarding plane of routers in Site B.


Thanks

Deccan 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 00358DCA48257FE3_=-- From nobody Fri Jul 1 08:19:08 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FEB12B005; Fri, 1 Jul 2016 08:19:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160701151906.24589.40199.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2016 08:19:06 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:19:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : OAM Requirements for Segment Routing Network Authors : Nagendra Kumar Carlos Pignataro Nobo Akiya Ruediger Geib Greg Mirsky Stephane Litkowski Filename : draft-ietf-spring-sr-oam-requirement-02.txt Pages : 7 Date : 2016-07-01 Abstract: This document describes a list of functional requirement for OAM in Segment Routing (SR) based network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-oam-requirement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-oam-requirement-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 1 09:12:33 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BC612D75F for ; Fri, 1 Jul 2016 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Al5aOhGG8zJ for ; Fri, 1 Jul 2016 09:12:30 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC0712D759 for ; Fri, 1 Jul 2016 09:12:30 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-09-57768c0af390 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.FF.09012.A0C86775; Fri, 1 Jul 2016 17:28:11 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0294.000; Fri, 1 Jul 2016 12:12:29 -0400 From: David Allan I To: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.txt Thread-Index: AQHR06vsvwtuFnyHk06k9OiuOQAXt6ADuXRg Date: Fri, 1 Jul 2016 16:12:29 +0000 Message-ID: References: <20160701151906.24589.40199.idtracker@ietfa.amsl.com> In-Reply-To: <20160701151906.24589.40199.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPny53T1m4wYy7vBbHL/xmdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuEnGxkLpstWPGm6xtjAuECsi5GTQ0LAROLJ1+9sELaYxIV7 64FsLg4hgaOMEkcXnwRLCAksY5RovhAIYrMJGEjs+f+FsYuRg0NEQF3i2dFwEFNYwFdi89lA iGiAxOK59iDFIgJGEqvXNjOC2CwCKhLvd58BG8gLVD3x3jxmiOGOElcO3GcFsTkFnCRurV4G VsMIdM33U2uYQGxmAXGJW0/mM0FcKSCxZM95ZghbVOLl43+sELaSxKSl51gh6nUkFuz+xAZh a0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaO0uCAnN93IYBMjMOSPSbDp 7mC8P93zEKMAB6MSD2/CtNJwIdbEsuLK3EOMEhzMSiK83yeXhQvxpiRWVqUW5ccXleakFh9i lOZgURLnFXukGC4kkJ5YkpqdmlqQWgSTZeLglGpgnPc0etWsrMbMoreCrooCalP8TueKnnyU 2Pret0vy/M4d73ivz4t8MfvhDr8vWyylOWRf3TORsom4+/T54+w8k0ULqxM/Ra/5fjxDILFp u9KhaEOvF7umiaXcnHDn3PSe1f/VZ+17fPjQtUdT2/z1pWV+zjbPNjec6FfT/fLVNUvBU4p7 nY/1dSuxFGckGmoxFxUnAgBiQKK7dQIAAA== Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 16:12:32 -0000 Hi I looked over this and have a few modest suggestions.... 1) Could be clarified a bit... REQ#2: The SR OAM packet MUST follow exactly the same path as dataplane traffic Suggested change REQ#2: An SR OAM packet MUST follow exactly the same path as the dataplane traffic it is intended to instrument. We could also argue about "exact path", as best we can do is in the nodal s= ense....=20 2) Delete REQ 3 and REQ 4 Reason: Clarity. Packets do not discover anything, systems can. If the syst= em implements ECMP and/or UCMP and the OAM system meets requirement 2, you'= re done. 3) REQ5, question... When you say available, is this in the sense that the path meets a specifi= ed criteria of information transfer capability? Depending on the answer I = may suggest an edit or two...and it may be necessary to include a definitio= n of availability. (definition, not specification as we'll argue till the c= ows come home :-) 4) REQ9, clarification The current text reads like the CC mechanism itself failed, not what it wa= s instrumenting. Suggested tweak... REQ#9: In case of any path failure detected with continuity check, SR = OAM SHOULD support rapid Connectivity Fault localization to isolate the node on which the failure occurs. 5) REQ11 Just reads strange.... for example, an edge node may not be adjacent to a = failure therefore confining actions to edge nodes makes no sense. If the a= ctual intention is to include all consequent actions of OAM states, there w= ill be a few requirements that fall out of this. Something to discuss. There is also the imbedded assumption that transactions are both p2p and bi= -directional. I would like to see REQxx OAM probes may be unidirectional or bi-directional. REQxx+1 OAM probes must be able to instrument p2p, mp2p and p2mp paths. My 2 cents, hope it is useful. Dave -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: Friday, July 01, 2016 8:19 AM To: i-d-announce@ietf.org Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking of the= IETF. Title : OAM Requirements for Segment Routing Network Authors : Nagendra Kumar Carlos Pignataro Nobo Akiya Ruediger Geib Greg Mirsky Stephane Litkowski Filename : draft-ietf-spring-sr-oam-requirement-02.txt Pages : 7 Date : 2016-07-01 Abstract: This document describes a list of functional requirement for OAM in Segment Routing (SR) based network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-oam-requirement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-sr-oam-requirement-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Fri Jul 1 10:13:27 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18BB12B036 for ; Fri, 1 Jul 2016 10:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4eEF8ANqk0x for ; Fri, 1 Jul 2016 10:13:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F7212D501 for ; Fri, 1 Jul 2016 10:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12334; q=dns/txt; s=iport; t=1467393202; x=1468602802; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IbOg0vB3a4LGEkzAajLTfXl0KhBl0fCuCtelkmXQqQk=; b=FCTxY/JCCUR7zWMDPedGdpUlUodo15RKUPAgn5SEyaqRA+S49skoMY77 c7Od7Npusrc3Ukd8qgz5tY4akKDe2+tVF50Hncbb6fJdGa7OZEVW9m4A/ +1Laxq42WhgN27COja1kUEfXKvPlGC89lhondgsTKLxVx/SmrXY902FHd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAgDwo3ZX/4oNJK1dgnBOVnwGtEyFA?= =?us-ascii?q?YF7hhgCgTA4FAEBAQEBAQFlHAuETAEBBS06EhACAQgRBAEBKAcyFAkIAgQOBQi?= =?us-ascii?q?IKMRPAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYohE2EIwEBUYUlBYgXkHkBi3SCS?= =?us-ascii?q?oFxF4Q/iGqQCAEeNoIIHIFMboc/Nn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,558,1459814400"; d="scan'208,217";a="292588269" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2016 17:13:21 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u61HDL1d026957 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2016 17:13:21 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 1 Jul 2016 12:13:20 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Fri, 1 Jul 2016 12:13:20 -0500 From: "Les Ginsberg (ginsberg)" To: "peng.shaofu@zte.com.cn" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution Thread-Index: AQHR031FIMXWd5IUz0elaeiCT6QpkqADscVg Date: Fri, 1 Jul 2016 17:13:20 +0000 Message-ID: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.5.100] Content-Type: multipart/alternative; boundary="_000_7b5699d429614579a332ae7832a27b58XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 17:13:27 -0000 --_000_7b5699d429614579a332ae7832a27b58XCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Deccan - From: peng.shaofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn] Sent: Friday, July 01, 2016 2:46 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution His Les, 1) From implementation, because preference algorithm is protocol independen= t, it is better to do conflict resolution at a common place, not at individ= ual protocol instance. For example, we can do prefix-conflict resolution wh= en generate the preference FIB entry at the common place. For a preference = FIB entry, the routing information may get from OSPF by administrative dist= ance, but the SID information may get from ISIS by prefix-conflict algorith= m. Then we can do sid-conflict resolution when generate the SID-LIB entry a= ccording to the above FIB entry and other sources, it will select a prefere= nce FEC to provide forwarding information. So, preference algorithm per prefix/fec is enough. Per range is possible, b= ut implementation is complex. More complex is for "ignor overlay" per range= . [Les:] Implementation-wise, you are free to implement this in any module yo= u like so long as with the same database you come up with the same answer a= s other nodes in the network. The distinction between "Quarantine" and "Ignore Overlap" is that the latte= r attempts to use those portions of a range which do not have conflicts wit= h other entries. The cost of doing so is having to create "derived entries"= which represent those sub-ranges which do/do not have conflicts. Due to th= e added complexity this is NOT the first choice of the authors. If I were to categorize the two algorithms using your terminology "Quaranti= ne" would be "per range" while "Ignore Overlap" would be "per prefix/FEC". = So it is the latter which is more complex to implement. 2) The restrictions in new section "Scope of SR-MPLS SID Conflicts" maybe n= ot true. Please just consider "Carrier of Carrier" case which deploy IGP+LD= P between PE and CE. It is possible to deploy SR LSP in the second level ca= rrier, so that an SR LSP is building from one site to another across the fi= rst level carrier, same as an LDP LSP. This means SIDs associated with dest= inations in Site A will be installed in the forwarding plane of routers in = Site B. [Les:] We have looked at "Carrier of Carrier" and we disagree with your con= clusion. To reach destinations in Site B from Site A packets will need to t= raverse the PE(s) connected to Site A. What will be installed in the forwar= ding plane of routers in Site A will be labels associated with the SID of t= he PE - not the SIDs for destinations in Site B. In fact, it is possible fo= r destination 1.1.1.1 in Site A to use the same SID as destination 2.2.2.2 = in Site B. This is discussed in Section 4 of the draft. Les Thanks Deccan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an in= tended recipient, any disclosure, reproduction, distribution or other disse= mination or use of the information contained is strictly prohibited. If yo= u have received this mail in error, please delete it and notify us immediat= ely. --_000_7b5699d429614579a332ae7832a27b58XCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deccan -

 <= /p>

From: peng.sha= ofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn]
Sent: Friday, July 01, 2016 2:46 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

His Les,

1) From implementation, because preference algorithm is protocol= independent, it is better to do conflict resolution at a common place, not= at individual protocol instance. For example, we can do prefix-conflict resolution when generate the preference FIB entry at th= e common place. For a preference FIB entry, the routing information may get= from OSPF by administrative distance, but the SID information may get from= ISIS by prefix-conflict algorithm. Then we can do sid-conflict resolution when generate the SID-LIB entry acc= ording to the above FIB entry and other sources, it will select a preferenc= e FEC to provide forwarding information.
So, preference algorithm per prefix/fec is enough. Per range is = possible, but implementation is complex. More complex is for "ignor ov= erlay" per range.

[Les:] Implementation-wise, you are free to implement this in a= ny module you like so long as with the same database you come up with the same answer as other nodes in the network.

The distinction between “Quarantine” and “Ign= ore Overlap” is that the latter attempts to use those portions of a r= ange which do not have conflicts with other entries. The cost of doing so is having t= o create “derived entries” which represent those sub-ranges whi= ch do/do not have conflicts. Due to the added complexity this is NOT the fi= rst choice of the authors.

If I were to categorize the two algorithms using your terminolo= gy “Quarantine” would be “per range” while “I= gnore Overlap” would be “per prefix/FEC”. So it is the latter which is more c= omplex to implement.


2) The restrictions in new section "Scope of SR-MPLS SID Co= nflicts" maybe not true. Please just consider "Carrier of Carrier= " case which deploy IGP+LDP between PE and CE. It is possible to d= eploy SR LSP in the second level carrier, so that an SR LSP is building from one= site to another across the first level carrier, same as an LDP LSP. This m= eans SIDs associated with destinations in Site A will be installed in the f= orwarding plane of routers in Site B.

[Les:] We have looked at “Carrier of= Carrier” and we disagree with your conclusion. To reach destinations= in Site B from Site A packets will need to traverse the PE(s) connected to Site A. What will be installed in the forwarding plane of routers in Si= te A will be labels associated with the SID of the PE – not the SIDs = for destinations in Site B. In fact, it is possible for destination 1.1.1.1= in Site A to use the same SID as destination 2.2.2.2 in Site B. This is discussed in Section 4 of the draft.=

  &nb= sp;Les


Thanks

Deccan 

 
-------------------------------------------=
-------------
ZTE Information Security Notice: The inform=
ation contained in this mail (and any attachment transmitted herewith) is p=
rivileged and confidential and is intended for the exclusive use of the add=
ressee(s).  If you are not an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or use of the information con=
tained is strictly prohibited.  If you have received this mail in erro=
r, please delete it and notify us immediately.
 

 

--_000_7b5699d429614579a332ae7832a27b58XCHALN001ciscocom_-- From nobody Sun Jul 3 19:32:59 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978B412D1BD for ; Sun, 3 Jul 2016 19:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNhkmK4FSy2s for ; Sun, 3 Jul 2016 19:32:56 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DAE6F12D1CA for ; Sun, 3 Jul 2016 19:32:54 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id D5EF097E26A8E for ; Mon, 4 Jul 2016 10:32:50 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 0ABAAD8E36AD4; Mon, 4 Jul 2016 10:32:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u642WY6N080680; Mon, 4 Jul 2016 10:32:34 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> References: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> To: "Les Ginsberg (ginsberg)" MIME-Version: 1.0 X-KeepSent: 253EEBD1:1FEFE348-48257FE6:0005F13C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Mon, 4 Jul 2016 10:32:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-04 10:32:22, Serialize complete at 2016-07-04 10:32:22 Content-Type: multipart/alternative; boundary="=_alternative 000DF7FE48257FE6_=" X-MAIL: mse01.zte.com.cn u642WY6N080680 Archived-At: Cc: "spring@ietf.org" Subject: [spring] =?gb2312?b?tPC4tDogUkU6ICBkcmFmdC1pZXRmLXNwcmluZy1jb25m?= =?gb2312?b?bGljdC1yZXNvbHV0aW9u?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 02:32:58 -0000 This is a multipart message in MIME format. --=_alternative 000DF7FE48257FE6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TGVzLCANCg0KU2VlIGlubGluZS4NCg0KDQoNCg0KDQoNCg0KIkxlcyBHaW5zYmVyZyAoZ2luc2Jl cmcpIiA8Z2luc2JlcmdAY2lzY28uY29tPiANCjIwMTYtMDctMDIgMDE6MTMNCg0KytW8/sjLDQoi cGVuZy5zaGFvZnVAenRlLmNvbS5jbiIgPHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24+LCANCrOty80N CiJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQrW98ziDQpSRTogW3NwcmluZ10g ZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg0KDQoNCg0KDQoNCg0KRGVjY2Fu IC0NCiANCkZyb206IHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24gW21haWx0bzpwZW5nLnNoYW9mdUB6 dGUuY29tLmNuXSANClNlbnQ6IEZyaWRheSwgSnVseSAwMSwgMjAxNiAyOjQ2IEFNDQpUbzogTGVz IEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzcHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb c3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uDQogDQpIaXMgTGVz LCANCg0KMSkgRnJvbSBpbXBsZW1lbnRhdGlvbiwgYmVjYXVzZSBwcmVmZXJlbmNlIGFsZ29yaXRo bSBpcyBwcm90b2NvbCANCmluZGVwZW5kZW50LCBpdCBpcyBiZXR0ZXIgdG8gZG8gY29uZmxpY3Qg cmVzb2x1dGlvbiBhdCBhIGNvbW1vbiBwbGFjZSwgbm90IA0KYXQgaW5kaXZpZHVhbCBwcm90b2Nv bCBpbnN0YW5jZS4gRm9yIGV4YW1wbGUsIHdlIGNhbiBkbyBwcmVmaXgtY29uZmxpY3QgDQpyZXNv bHV0aW9uIHdoZW4gZ2VuZXJhdGUgdGhlIHByZWZlcmVuY2UgRklCIGVudHJ5IGF0IHRoZSBjb21t b24gcGxhY2UuIEZvciANCmEgcHJlZmVyZW5jZSBGSUIgZW50cnksIHRoZSByb3V0aW5nIGluZm9y bWF0aW9uIG1heSBnZXQgZnJvbSBPU1BGIGJ5IA0KYWRtaW5pc3RyYXRpdmUgZGlzdGFuY2UsIGJ1 dCB0aGUgU0lEIGluZm9ybWF0aW9uIG1heSBnZXQgZnJvbSBJU0lTIGJ5IA0KcHJlZml4LWNvbmZs aWN0IGFsZ29yaXRobS4gVGhlbiB3ZSBjYW4gZG8gc2lkLWNvbmZsaWN0IHJlc29sdXRpb24gd2hl biANCmdlbmVyYXRlIHRoZSBTSUQtTElCIGVudHJ5IGFjY29yZGluZyB0byB0aGUgYWJvdmUgRklC IGVudHJ5IGFuZCBvdGhlciANCnNvdXJjZXMsIGl0IHdpbGwgc2VsZWN0IGEgcHJlZmVyZW5jZSBG RUMgdG8gcHJvdmlkZSBmb3J3YXJkaW5nIA0KaW5mb3JtYXRpb24uIA0KU28sIHByZWZlcmVuY2Ug YWxnb3JpdGhtIHBlciBwcmVmaXgvZmVjIGlzIGVub3VnaC4gUGVyIHJhbmdlIGlzIHBvc3NpYmxl LCANCmJ1dCBpbXBsZW1lbnRhdGlvbiBpcyBjb21wbGV4LiBNb3JlIGNvbXBsZXggaXMgZm9yICJp Z25vciBvdmVybGF5IiBwZXIgDQpyYW5nZS4gDQoNCltMZXM6XSBJbXBsZW1lbnRhdGlvbi13aXNl LCB5b3UgYXJlIGZyZWUgdG8gaW1wbGVtZW50IHRoaXMgaW4gYW55IG1vZHVsZSANCnlvdSBsaWtl IHNvIGxvbmcgYXMgd2l0aCB0aGUgc2FtZSBkYXRhYmFzZSB5b3UgY29tZSB1cCB3aXRoIHRoZSBz YW1lIA0KYW5zd2VyIGFzIG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrLg0KVGhlIGRpc3RpbmN0 aW9uIGJldHdlZW4gobBRdWFyYW50aW5lobEgYW5kIKGwSWdub3JlIE92ZXJsYXChsSBpcyB0aGF0 IHRoZSANCmxhdHRlciBhdHRlbXB0cyB0byB1c2UgdGhvc2UgcG9ydGlvbnMgb2YgYSByYW5nZSB3 aGljaCBkbyBub3QgaGF2ZSANCmNvbmZsaWN0cyB3aXRoIG90aGVyIGVudHJpZXMuIFRoZSBjb3N0 IG9mIGRvaW5nIHNvIGlzIGhhdmluZyB0byBjcmVhdGUgobANCmRlcml2ZWQgZW50cmllc6GxIHdo aWNoIHJlcHJlc2VudCB0aG9zZSBzdWItcmFuZ2VzIHdoaWNoIGRvL2RvIG5vdCBoYXZlIA0KY29u ZmxpY3RzLiBEdWUgdG8gdGhlIGFkZGVkIGNvbXBsZXhpdHkgdGhpcyBpcyBOT1QgdGhlIGZpcnN0 IGNob2ljZSBvZiB0aGUgDQphdXRob3JzLiANCklmIEkgd2VyZSB0byBjYXRlZ29yaXplIHRoZSB0 d28gYWxnb3JpdGhtcyB1c2luZyB5b3VyIHRlcm1pbm9sb2d5IKGwDQpRdWFyYW50aW5lobEgd291 bGQgYmUgobBwZXIgcmFuZ2WhsSB3aGlsZSChsElnbm9yZSBPdmVybGFwobEgd291bGQgYmUgobAN CnBlciBwcmVmaXgvRkVDobEuIFNvIGl0IGlzIHRoZSBsYXR0ZXIgd2hpY2ggaXMgbW9yZSBjb21w bGV4IHRvIGltcGxlbWVudC4NCltEZWNjYW5dIFlvdSBhcmUgcmlnaHQsIGFzIHBlciBwcmVmaXgv RkVDIGlzIGFjdHVhbGx5IHRvIHNwbGl0IHRoZSANCm9yaWdpbmFsIHJhbmdlIHRvIHRoZSBzbWFs bGVzdCBvbmVzLiBNeSBtZWFuaW5nIGlzIHRoYXQgdGhlcmUgaXMgbm8gcmFuZ2UgDQppZGVhIGR1 cmluZyBjb25mbGljdCBwcm9jZXNzIHBoYXNlIGF0IHRoZSBjb21tb24gcGxhY2UsIGFsbCBpcyBk b25lIGJhc2VkIA0Kb24gdGhlIGV4aXN0aW5nIGRhdGEgc3RydWN0dXJlIHBlciBwcmVmaXgvRkVD LiBNYXBwaW5nIHJhbmdlIG9ubHkgYXBwZWFyIA0KaW4gdGhlIGluZGl2aWR1YWwgcHJvdG9jb2wg aW5zdGFuY2UsIGJ1dCBpdCBpcyBhbHdheXMgdG8gYmUgc3BsaXQgdG8gdGhlIA0Kc21hbGxlc3Qg b25lcywgZm9yIHJhIGZvciBjb25mbGljdCBmdW5jdGlvbi4NCg0KMikgVGhlIHJlc3RyaWN0aW9u cyBpbiBuZXcgc2VjdGlvbiAiU2NvcGUgb2YgU1ItTVBMUyBTSUQgQ29uZmxpY3RzIiBtYXliZSAN Cm5vdCB0cnVlLiBQbGVhc2UganVzdCBjb25zaWRlciAiQ2FycmllciBvZiBDYXJyaWVyIiBjYXNl IHdoaWNoIGRlcGxveSANCklHUCtMRFAgYmV0d2VlbiBQRSBhbmQgQ0UuIEl0IGlzIHBvc3NpYmxl IHRvIGRlcGxveSBTUiBMU1AgaW4gdGhlIHNlY29uZCANCmxldmVsIGNhcnJpZXIsIHNvIHRoYXQg YW4gU1IgTFNQIGlzIGJ1aWxkaW5nIGZyb20gb25lIHNpdGUgdG8gYW5vdGhlciANCmFjcm9zcyB0 aGUgZmlyc3QgbGV2ZWwgY2Fycmllciwgc2FtZSBhcyBhbiBMRFAgTFNQLiBUaGlzIG1lYW5zIFNJ RHMgDQphc3NvY2lhdGVkIHdpdGggZGVzdGluYXRpb25zIGluIFNpdGUgQSB3aWxsIGJlIGluc3Rh bGxlZCBpbiB0aGUgZm9yd2FyZGluZyANCnBsYW5lIG9mIHJvdXRlcnMgaW4gU2l0ZSBCLiANCg0K W0xlczpdIFdlIGhhdmUgbG9va2VkIGF0IKGwQ2FycmllciBvZiBDYXJyaWVyobEgYW5kIHdlIGRp c2FncmVlIHdpdGggeW91ciANCmNvbmNsdXNpb24uIFRvIHJlYWNoIGRlc3RpbmF0aW9ucyBpbiBT aXRlIEIgZnJvbSBTaXRlIEEgcGFja2V0cyB3aWxsIG5lZWQgDQp0byB0cmF2ZXJzZSB0aGUgUEUo cykgY29ubmVjdGVkIHRvIFNpdGUgQS4gV2hhdCB3aWxsIGJlIGluc3RhbGxlZCBpbiB0aGUgDQpm b3J3YXJkaW5nIHBsYW5lIG9mIHJvdXRlcnMgaW4gU2l0ZSBBIHdpbGwgYmUgbGFiZWxzIGFzc29j aWF0ZWQgd2l0aCB0aGUgDQpTSUQgb2YgdGhlIFBFIKhDIG5vdCB0aGUgU0lEcyBmb3IgZGVzdGlu YXRpb25zIGluIFNpdGUgQi4gSW4gZmFjdCwgaXQgaXMgDQpwb3NzaWJsZSBmb3IgZGVzdGluYXRp b24gMS4xLjEuMSBpbiBTaXRlIEEgdG8gdXNlIHRoZSBzYW1lIFNJRCBhcyANCmRlc3RpbmF0aW9u IDIuMi4yLjIgaW4gU2l0ZSBCLiBUaGlzIGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQgb2YgdGhl IA0KZHJhZnQuDQpbRGVjY2FuXSBTb3JyeSwgSSBjYW5ub3QgdW5kZXJzdGFuZCBob3cgdG8gZnVs ZmlsbCB0aGlzIGNhc2UgeWV0LiBJTU8sIA0KcGFja2V0cyBmcm9tIHNpdGUgQSBuZWVkIGNvbnRh aW4gU0lEcyBmb3IgZGVzdGluYXRpb25zIGluIHNpdGUgQiwgc28gdGhhdCANCnBhY2tldHMgY2Fu IGZvcndhcmQgdG8gdGhlIHNwZWNpZmljIGRlc3RpbmF0aW9uIGNvcnJlY3RseSwgdGhlIFNJRCBv ZiB0aGUgDQpQRSBjYW4gb25seSBiZSB1c2VkIHRvIGZvcndhcmQgcGFja2V0cyB0byB0aGUgUEUu IEFsdGhvdWdoLCBhdCB0aGUgaW5ncmVzcyANCm5vZGUgaW4gc2l0ZSBBLCB3ZSBjYW4gZW5jYXBz dWxhdGUgU0lEIG9mIHRoZSBQRSBhZ2FpbiB0byBoaWRlIFNJRCBvZiBzaXRlIA0KQiBiZWZvcmUg c2VuZGluZyBwYWNrZXRzLCB0aGUgaW5ncmVzcyBub2RlIGluIHNpdGUgQSBhbmQgdGhlIFBFIG5l ZWQgc3RpbGwgDQpzZWUgdGhlIFNJRCBvZiBzaXRlIEIuIEEgbm9kZSBpbiBzaXRlIEEgY2FuIG5v dCBlbnN1cmUgaXQgd2lsbCBvbmx5IGFjdCBhcyANCmEgdHJhbnNpdCByb2xlLiBDb3VsZCB5b3Ug ZXhwbGFpbiBtb3JlPw0KDQogICBMZXMNCg0KVGhhbmtzIA0KDQpEZWNjYW4gDQogDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgDQooYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBw cml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgDQphbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNs dXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCANCmFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIA0KZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIA0KaW1tZWRpYXRl bHkuDQogDQogDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0 dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u LCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz IGltbWVkaWF0ZWx5Lg0K --=_alternative 000DF7FE48257FE6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxlcywgPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWUgaW5saW5lLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0xlcyBHaW5z YmVyZyAoZ2luc2JlcmcpJnF1b3Q7DQombHQ7Z2luc2JlcmdAY2lzY28uY29tJmd0OzwvYj4gPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYtMDctMDIgMDE6MTM8 L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7cGVuZy5zaGFvZnVAenRlLmNvbS5jbiZxdW90OyAmbHQ7cGVuZy5zaGFvZnVAenRlLmNv bS5jbiZndDssDQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90 OyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtzcHJpbmdd IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb248L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJD YWxpYnJpIj5EZWNjYW4gLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9t YSI+PGI+RnJvbTo8L2I+IHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24gWzwvZm9udD48YSBocmVmPW1h aWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPm1h aWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4gRnJpZGF5LCBKdWx5IDAxLCAyMDE2IDI6NDYg QU08Yj48YnI+DQpUbzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpPGI+PGJyPg0KQ2M6PC9i PiBzcHJpbmdAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIGRyYWZ0 LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+SGlzIExlcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQoxKSBG cm9tIGltcGxlbWVudGF0aW9uLCBiZWNhdXNlIHByZWZlcmVuY2UgYWxnb3JpdGhtIGlzIHByb3Rv Y29sIGluZGVwZW5kZW50LA0KaXQgaXMgYmV0dGVyIHRvIGRvIGNvbmZsaWN0IHJlc29sdXRpb24g YXQgYSBjb21tb24gcGxhY2UsIG5vdCBhdCBpbmRpdmlkdWFsDQpwcm90b2NvbCBpbnN0YW5jZS4g Rm9yIGV4YW1wbGUsIHdlIGNhbiBkbyBwcmVmaXgtY29uZmxpY3QgcmVzb2x1dGlvbiB3aGVuDQpn ZW5lcmF0ZSB0aGUgcHJlZmVyZW5jZSBGSUIgZW50cnkgYXQgdGhlIGNvbW1vbiBwbGFjZS4gRm9y IGEgcHJlZmVyZW5jZQ0KRklCIGVudHJ5LCB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBtYXkgZ2V0 IGZyb20gT1NQRiBieSBhZG1pbmlzdHJhdGl2ZQ0KZGlzdGFuY2UsIGJ1dCB0aGUgU0lEIGluZm9y bWF0aW9uIG1heSBnZXQgZnJvbSBJU0lTIGJ5IHByZWZpeC1jb25mbGljdA0KYWxnb3JpdGhtLiBU aGVuIHdlIGNhbiBkbyBzaWQtY29uZmxpY3QgcmVzb2x1dGlvbiB3aGVuIGdlbmVyYXRlIHRoZSBT SUQtTElCDQplbnRyeSBhY2NvcmRpbmcgdG8gdGhlIGFib3ZlIEZJQiBlbnRyeSBhbmQgb3RoZXIg c291cmNlcywgaXQgd2lsbCBzZWxlY3QNCmEgcHJlZmVyZW5jZSBGRUMgdG8gcHJvdmlkZSBmb3J3 YXJkaW5nIGluZm9ybWF0aW9uLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClNvLCBwcmVmZXJl bmNlIGFsZ29yaXRobSBwZXIgcHJlZml4L2ZlYyBpcyBlbm91Z2guIFBlciByYW5nZSBpcyBwb3Nz aWJsZSwNCmJ1dCBpbXBsZW1lbnRhdGlvbiBpcyBjb21wbGV4LiBNb3JlIGNvbXBsZXggaXMgZm9y ICZxdW90O2lnbm9yIG92ZXJsYXkmcXVvdDsNCnBlciByYW5nZS48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48Yj48aT5bTGVzOl0gSW1wbGVtZW50YXRpb24t d2lzZSwNCnlvdSBhcmUgZnJlZSB0byBpbXBsZW1lbnQgdGhpcyBpbiBhbnkgbW9kdWxlIHlvdSBs aWtlIHNvIGxvbmcgYXMgd2l0aCB0aGUNCnNhbWUgZGF0YWJhc2UgeW91IGNvbWUgdXAgd2l0aCB0 aGUgc2FtZSBhbnN3ZXIgYXMgb3RoZXIgbm9kZXMgaW4gdGhlIG5ldHdvcmsuPC9pPjwvYj48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+ VGhlIGRpc3RpbmN0aW9uIGJldHdlZW4NCqGwUXVhcmFudGluZaGxIGFuZCChsElnbm9yZSBPdmVy bGFwobEgaXMgdGhhdCB0aGUgbGF0dGVyIGF0dGVtcHRzIHRvDQp1c2UgdGhvc2UgcG9ydGlvbnMg b2YgYSByYW5nZSB3aGljaCBkbyBub3QgaGF2ZSBjb25mbGljdHMgd2l0aCBvdGhlciBlbnRyaWVz Lg0KVGhlIGNvc3Qgb2YgZG9pbmcgc28gaXMgaGF2aW5nIHRvIGNyZWF0ZSChsGRlcml2ZWQgZW50 cmllc6GxIHdoaWNoIHJlcHJlc2VudA0KdGhvc2Ugc3ViLXJhbmdlcyB3aGljaCBkby9kbyBub3Qg aGF2ZSBjb25mbGljdHMuIER1ZSB0byB0aGUgYWRkZWQgY29tcGxleGl0eQ0KdGhpcyBpcyBOT1Qg dGhlIGZpcnN0IGNob2ljZSBvZiB0aGUgYXV0aG9ycy4gPC9pPjwvYj48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+SWYgSSB3ZXJlIHRv IGNhdGVnb3JpemUNCnRoZSB0d28gYWxnb3JpdGhtcyB1c2luZyB5b3VyIHRlcm1pbm9sb2d5IKGw UXVhcmFudGluZaGxIHdvdWxkIGJlIKGwcGVyDQpyYW5nZaGxIHdoaWxlIKGwSWdub3JlIE92ZXJs YXChsSB3b3VsZCBiZSChsHBlciBwcmVmaXgvRkVDobEuIFNvIGl0DQppcyB0aGUgbGF0dGVyIHdo aWNoIGlzIG1vcmUgY29tcGxleCB0byBpbXBsZW1lbnQuPC9pPjwvYj48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5bRGVjY2FuXSBZb3UgYXJlIHJpZ2h0LCBhcyBwZXIgcHJl Zml4L0ZFQw0KaXMgYWN0dWFsbHkgdG8gc3BsaXQgdGhlIG9yaWdpbmFsIHJhbmdlIHRvIHRoZSBz bWFsbGVzdCBvbmVzLiBNeSBtZWFuaW5nDQppcyB0aGF0IHRoZXJlIGlzIG5vIHJhbmdlIGlkZWEg ZHVyaW5nIGNvbmZsaWN0IHByb2Nlc3MgcGhhc2UgYXQgdGhlIGNvbW1vbg0KcGxhY2UsIGFsbCBp cyBkb25lIGJhc2VkIG9uIHRoZSBleGlzdGluZyBkYXRhIHN0cnVjdHVyZSBwZXIgcHJlZml4L0ZF Qy4NCk1hcHBpbmcgcmFuZ2Ugb25seSBhcHBlYXIgaW4gdGhlIGluZGl2aWR1YWwgcHJvdG9jb2wg aW5zdGFuY2UsIGJ1dCBpdCBpcw0KYWx3YXlzIHRvIGJlIHNwbGl0IHRvIHRoZSBzbWFsbGVzdCBv bmVzLCBmb3IgcmEgZm9yIGNvbmZsaWN0IGZ1bmN0aW9uLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCjIpIFRoZSByZXN0cmljdGlvbnMgaW4gbmV3IHNlY3Rpb24g JnF1b3Q7U2NvcGUgb2YgU1ItTVBMUyBTSUQgQ29uZmxpY3RzJnF1b3Q7DQptYXliZSBub3QgdHJ1 ZS4gUGxlYXNlIGp1c3QgY29uc2lkZXIgJnF1b3Q7Q2FycmllciBvZiBDYXJyaWVyJnF1b3Q7IGNh c2UNCndoaWNoIGRlcGxveSBJR1ArTERQIGJldHdlZW4gUEUgYW5kIENFLiBJdCBpcyBwb3NzaWJs ZSB0byBkZXBsb3kgU1IgTFNQDQppbiB0aGUgc2Vjb25kIGxldmVsIGNhcnJpZXIsIHNvIHRoYXQg YW4gU1IgTFNQIGlzIGJ1aWxkaW5nIGZyb20gb25lIHNpdGUNCnRvIGFub3RoZXIgYWNyb3NzIHRo ZSBmaXJzdCBsZXZlbCBjYXJyaWVyLCBzYW1lIGFzIGFuIExEUCBMU1AuIFRoaXMgbWVhbnMNClNJ RHMgYXNzb2NpYXRlZCB3aXRoIGRlc3RpbmF0aW9ucyBpbiBTaXRlIEEgd2lsbCBiZSBpbnN0YWxs ZWQgaW4gdGhlIGZvcndhcmRpbmcNCnBsYW5lIG9mIHJvdXRlcnMgaW4gU2l0ZSBCLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48Yj48aT48YnI+DQpbTGVzOl0gV2Ug aGF2ZSBsb29rZWQgYXQgobBDYXJyaWVyIG9mIENhcnJpZXKhsSBhbmQgd2UgZGlzYWdyZWUgd2l0 aA0KeW91ciBjb25jbHVzaW9uLiBUbyByZWFjaCBkZXN0aW5hdGlvbnMgaW4gU2l0ZSBCIGZyb20g U2l0ZSBBIHBhY2tldHMgd2lsbA0KbmVlZCB0byB0cmF2ZXJzZSB0aGUgUEUocykgY29ubmVjdGVk IHRvIFNpdGUgQS4gV2hhdCB3aWxsIGJlIGluc3RhbGxlZA0KaW4gdGhlIGZvcndhcmRpbmcgcGxh bmUgb2Ygcm91dGVycyBpbiBTaXRlIEEgd2lsbCBiZSBsYWJlbHMgYXNzb2NpYXRlZA0Kd2l0aCB0 aGUgU0lEIG9mIHRoZSBQRSCoQyBub3QgdGhlIFNJRHMgZm9yIGRlc3RpbmF0aW9ucyBpbiBTaXRl IEIuIEluIGZhY3QsDQppdCBpcyBwb3NzaWJsZSBmb3IgZGVzdGluYXRpb24gMS4xLjEuMSBpbiBT aXRlIEEgdG8gdXNlIHRoZSBzYW1lIFNJRCBhcw0KZGVzdGluYXRpb24gMi4yLjIuMiBpbiBTaXRl IEIuIFRoaXMgaXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNCBvZiB0aGUgZHJhZnQuPC9pPjwvYj48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMwMDQwODAgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj5bRGVjY2FuXSBTb3JyeSwgSQ0KY2Fubm90IHVuZGVyc3RhbmQgaG93IHRvIGZ1bGZpbGwg dGhpcyBjYXNlIHlldC4gSU1PLDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPg0KPC9m b250Pjxmb250IHNpemU9MyBjb2xvcj0jMDA0MDgwIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+cGFj a2V0cyBmcm9tIHNpdGUNCkEgbmVlZCBjb250YWluIFNJRHMgZm9yIGRlc3RpbmF0aW9ucyBpbiBz aXRlIEIsIHNvIHRoYXQgcGFja2V0cyBjYW4gZm9yd2FyZA0KdG8gdGhlIHNwZWNpZmljIGRlc3Rp bmF0aW9uIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPmNvcnJlY3RseSwNCnRoZSBT SUQgb2YgdGhlIFBFIGNhbiBvbmx5IGJlIHVzZWQgdG8gZm9yd2FyZCBwYWNrZXRzIHRvIHRoZSBQ RS4gQWx0aG91Z2gsDQphdCB0aGUgaW5ncmVzcyBub2RlIGluIHNpdGUgQSwgd2UgY2FuIGVuY2Fw c3VsYXRlIFNJRCBvZiB0aGUgUEUgYWdhaW4gdG8NCmhpZGUgU0lEIG9mIHNpdGUgQiBiZWZvcmUg c2VuZGluZyBwYWNrZXRzLCB0aGUgaW5ncmVzcyBub2RlIGluIHNpdGUgQSBhbmQNCnRoZSBQRSBu ZWVkIHN0aWxsIHNlZSB0aGUgU0lEIG9mIHNpdGUgQi4gQSBub2RlIGluIHNpdGUgQSBjYW4gbm90 IGVuc3VyZQ0KaXQgd2lsbCBvbmx5IGFjdCBhcyBhIHRyYW5zaXQgcm9sZS4gQ291bGQgeW91IGV4 cGxhaW4gbW9yZT88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMwMDQwODAg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsgJm5ic3A7TGVzPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhhbmtzIDwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpEZWNjYW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIg TmV3Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5l dyI+WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5DQpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQNCmhlcmV3 aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlDQp1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gJm5ic3A7SWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwg ZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mDQp0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZl IHJlY2VpdmVkDQp0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlm eSB1cyBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9y PSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBk aXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1t ZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJi bHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhl cmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZv ciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0 cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRp YXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 000DF7FE48257FE6_=-- From nobody Sun Jul 3 19:37:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525C812D1BD for ; Sun, 3 Jul 2016 19:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMH_faVkSUqY for ; Sun, 3 Jul 2016 19:37:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE2612D0F1 for ; Sun, 3 Jul 2016 19:37:09 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 54CDB532CF9F6; Mon, 4 Jul 2016 10:37:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u642alcN095240; Mon, 4 Jul 2016 10:36:47 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: References: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> To: "Les Ginsberg (ginsberg)" MIME-Version: 1.0 X-KeepSent: 29F3BA63:D3B43E5C-48257FE6:000E1BEF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Mon, 4 Jul 2016 10:36:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-04 10:36:35, Serialize complete at 2016-07-04 10:36:35 Content-Type: multipart/alternative; boundary="=_alternative 000E5AB348257FE6_=" X-MAIL: mse01.zte.com.cn u642alcN095240 Archived-At: Cc: "spring@ietf.org" Subject: [spring] =?gb2312?b?tPC4tDogUkU6ICBkcmFmdC1pZXRmLXNwcmluZy1jb25m?= =?gb2312?b?bGljdC1yZXNvbHV0aW9u?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 02:37:12 -0000 This is a multipart message in MIME format. --=_alternative 000E5AB348257FE6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TGVzLA0KDQpzb3JyeSwgY29ycmVjdCBhIHNwZWxsaW5nIG1pc3Rha2UNCg0KDQoNCg0KDQrF7cnZ uLsxNTM4MTUvdXNlci96dGVfbHRkDQoyMDE2LTA3LTA0IDEwOjMyDQoNCsrVvP7Iyw0KIkxlcyBH aW5zYmVyZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29tPiwgDQqzrcvNDQoic3ByaW5n QGlldGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0K1vfM4g0KtPC4tDogUkU6IFtzcHJpbmddIGRy YWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KDQoNCg0KDQpMZXMsIA0KDQpT ZWUgaW5saW5lLg0KDQoNCg0KDQoNCg0KDQoNCiJMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSIgPGdp bnNiZXJnQGNpc2NvLmNvbT4gDQoyMDE2LTA3LTAyIDAxOjEzDQoNCsrVvP7Iyw0KInBlbmcuc2hh b2Z1QHp0ZS5jb20uY24iIDxwZW5nLnNoYW9mdUB6dGUuY29tLmNuPiwgDQqzrcvNDQoic3ByaW5n QGlldGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0K1vfM4g0KUkU6IFtzcHJpbmddIGRyYWZ0LWll dGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KDQoNCg0KDQoNCkRlY2NhbiAtDQogDQpG cm9tOiBwZW5nLnNoYW9mdUB6dGUuY29tLmNuIFttYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5j bl0gDQpTZW50OiBGcmlkYXksIEp1bHkgMDEsIDIwMTYgMjo0NiBBTQ0KVG86IExlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpDQpDYzogc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NwcmluZ10g ZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg0KIA0KSGlzIExlcywgDQoNCjEp IEZyb20gaW1wbGVtZW50YXRpb24sIGJlY2F1c2UgcHJlZmVyZW5jZSBhbGdvcml0aG0gaXMgcHJv dG9jb2wgDQppbmRlcGVuZGVudCwgaXQgaXMgYmV0dGVyIHRvIGRvIGNvbmZsaWN0IHJlc29sdXRp b24gYXQgYSBjb21tb24gcGxhY2UsIG5vdCANCmF0IGluZGl2aWR1YWwgcHJvdG9jb2wgaW5zdGFu Y2UuIEZvciBleGFtcGxlLCB3ZSBjYW4gZG8gcHJlZml4LWNvbmZsaWN0IA0KcmVzb2x1dGlvbiB3 aGVuIGdlbmVyYXRlIHRoZSBwcmVmZXJlbmNlIEZJQiBlbnRyeSBhdCB0aGUgY29tbW9uIHBsYWNl LiBGb3IgDQphIHByZWZlcmVuY2UgRklCIGVudHJ5LCB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBt YXkgZ2V0IGZyb20gT1NQRiBieSANCmFkbWluaXN0cmF0aXZlIGRpc3RhbmNlLCBidXQgdGhlIFNJ RCBpbmZvcm1hdGlvbiBtYXkgZ2V0IGZyb20gSVNJUyBieSANCnByZWZpeC1jb25mbGljdCBhbGdv cml0aG0uIFRoZW4gd2UgY2FuIGRvIHNpZC1jb25mbGljdCByZXNvbHV0aW9uIHdoZW4gDQpnZW5l cmF0ZSB0aGUgU0lELUxJQiBlbnRyeSBhY2NvcmRpbmcgdG8gdGhlIGFib3ZlIEZJQiBlbnRyeSBh bmQgb3RoZXIgDQpzb3VyY2VzLCBpdCB3aWxsIHNlbGVjdCBhIHByZWZlcmVuY2UgRkVDIHRvIHBy b3ZpZGUgZm9yd2FyZGluZyANCmluZm9ybWF0aW9uLiANClNvLCBwcmVmZXJlbmNlIGFsZ29yaXRo bSBwZXIgcHJlZml4L2ZlYyBpcyBlbm91Z2guIFBlciByYW5nZSBpcyBwb3NzaWJsZSwgDQpidXQg aW1wbGVtZW50YXRpb24gaXMgY29tcGxleC4gTW9yZSBjb21wbGV4IGlzIGZvciAiaWdub3Igb3Zl cmxheSIgcGVyIA0KcmFuZ2UuIA0KDQpbTGVzOl0gSW1wbGVtZW50YXRpb24td2lzZSwgeW91IGFy ZSBmcmVlIHRvIGltcGxlbWVudCB0aGlzIGluIGFueSBtb2R1bGUgDQp5b3UgbGlrZSBzbyBsb25n IGFzIHdpdGggdGhlIHNhbWUgZGF0YWJhc2UgeW91IGNvbWUgdXAgd2l0aCB0aGUgc2FtZSANCmFu c3dlciBhcyBvdGhlciBub2RlcyBpbiB0aGUgbmV0d29yay4NClRoZSBkaXN0aW5jdGlvbiBiZXR3 ZWVuIKGwUXVhcmFudGluZaGxIGFuZCChsElnbm9yZSBPdmVybGFwobEgaXMgdGhhdCB0aGUgDQps YXR0ZXIgYXR0ZW1wdHMgdG8gdXNlIHRob3NlIHBvcnRpb25zIG9mIGEgcmFuZ2Ugd2hpY2ggZG8g bm90IGhhdmUgDQpjb25mbGljdHMgd2l0aCBvdGhlciBlbnRyaWVzLiBUaGUgY29zdCBvZiBkb2lu ZyBzbyBpcyBoYXZpbmcgdG8gY3JlYXRlIKGwDQpkZXJpdmVkIGVudHJpZXOhsSB3aGljaCByZXBy ZXNlbnQgdGhvc2Ugc3ViLXJhbmdlcyB3aGljaCBkby9kbyBub3QgaGF2ZSANCmNvbmZsaWN0cy4g RHVlIHRvIHRoZSBhZGRlZCBjb21wbGV4aXR5IHRoaXMgaXMgTk9UIHRoZSBmaXJzdCBjaG9pY2Ug b2YgdGhlIA0KYXV0aG9ycy4gDQpJZiBJIHdlcmUgdG8gY2F0ZWdvcml6ZSB0aGUgdHdvIGFsZ29y aXRobXMgdXNpbmcgeW91ciB0ZXJtaW5vbG9neSChsA0KUXVhcmFudGluZaGxIHdvdWxkIGJlIKGw cGVyIHJhbmdlobEgd2hpbGUgobBJZ25vcmUgT3ZlcmxhcKGxIHdvdWxkIGJlIKGwDQpwZXIgcHJl Zml4L0ZFQ6GxLiBTbyBpdCBpcyB0aGUgbGF0dGVyIHdoaWNoIGlzIG1vcmUgY29tcGxleCB0byBp bXBsZW1lbnQuDQpbRGVjY2FuXSBZb3UgYXJlIHJpZ2h0LCBhcyBwZXIgcHJlZml4L0ZFQyBpcyBh Y3R1YWxseSB0byBzcGxpdCB0aGUgDQpvcmlnaW5hbCByYW5nZSB0byB0aGUgc21hbGxlc3Qgb25l cy4gTXkgbWVhbmluZyBpcyB0aGF0IHRoZXJlIGlzIG5vIHJhbmdlIA0KaWRlYSBkdXJpbmcgY29u ZmxpY3QgcHJvY2VzcyBwaGFzZSBhdCB0aGUgY29tbW9uIHBsYWNlLCBhbGwgaXMgZG9uZSBiYXNl ZCANCm9uIHRoZSBleGlzdGluZyBkYXRhIHN0cnVjdHVyZSBwZXIgcHJlZml4L0ZFQy4gTWFwcGlu ZyByYW5nZSBvbmx5IGFwcGVhciANCmluIHRoZSBpbmRpdmlkdWFsIHByb3RvY29sIGluc3RhbmNl LCBidXQgaXQgaXMgYWx3YXlzIHRvIGJlIHNwbGl0IHRvIHRoZSANCnNtYWxsZXN0IG9uZXMsIG5v dCBmb3IgY29uZmxpY3QgZnVuY3Rpb24uDQoNCjIpIFRoZSByZXN0cmljdGlvbnMgaW4gbmV3IHNl Y3Rpb24gIlNjb3BlIG9mIFNSLU1QTFMgU0lEIENvbmZsaWN0cyIgbWF5YmUgDQpub3QgdHJ1ZS4g UGxlYXNlIGp1c3QgY29uc2lkZXIgIkNhcnJpZXIgb2YgQ2FycmllciIgY2FzZSB3aGljaCBkZXBs b3kgDQpJR1ArTERQIGJldHdlZW4gUEUgYW5kIENFLiBJdCBpcyBwb3NzaWJsZSB0byBkZXBsb3kg U1IgTFNQIGluIHRoZSBzZWNvbmQgDQpsZXZlbCBjYXJyaWVyLCBzbyB0aGF0IGFuIFNSIExTUCBp cyBidWlsZGluZyBmcm9tIG9uZSBzaXRlIHRvIGFub3RoZXIgDQphY3Jvc3MgdGhlIGZpcnN0IGxl dmVsIGNhcnJpZXIsIHNhbWUgYXMgYW4gTERQIExTUC4gVGhpcyBtZWFucyBTSURzIA0KYXNzb2Np YXRlZCB3aXRoIGRlc3RpbmF0aW9ucyBpbiBTaXRlIEEgd2lsbCBiZSBpbnN0YWxsZWQgaW4gdGhl IGZvcndhcmRpbmcgDQpwbGFuZSBvZiByb3V0ZXJzIGluIFNpdGUgQi4gDQoNCltMZXM6XSBXZSBo YXZlIGxvb2tlZCBhdCChsENhcnJpZXIgb2YgQ2FycmllcqGxIGFuZCB3ZSBkaXNhZ3JlZSB3aXRo IHlvdXIgDQpjb25jbHVzaW9uLiBUbyByZWFjaCBkZXN0aW5hdGlvbnMgaW4gU2l0ZSBCIGZyb20g U2l0ZSBBIHBhY2tldHMgd2lsbCBuZWVkIA0KdG8gdHJhdmVyc2UgdGhlIFBFKHMpIGNvbm5lY3Rl ZCB0byBTaXRlIEEuIFdoYXQgd2lsbCBiZSBpbnN0YWxsZWQgaW4gdGhlIA0KZm9yd2FyZGluZyBw bGFuZSBvZiByb3V0ZXJzIGluIFNpdGUgQSB3aWxsIGJlIGxhYmVscyBhc3NvY2lhdGVkIHdpdGgg dGhlIA0KU0lEIG9mIHRoZSBQRSCoQyBub3QgdGhlIFNJRHMgZm9yIGRlc3RpbmF0aW9ucyBpbiBT aXRlIEIuIEluIGZhY3QsIGl0IGlzIA0KcG9zc2libGUgZm9yIGRlc3RpbmF0aW9uIDEuMS4xLjEg aW4gU2l0ZSBBIHRvIHVzZSB0aGUgc2FtZSBTSUQgYXMgDQpkZXN0aW5hdGlvbiAyLjIuMi4yIGlu IFNpdGUgQi4gVGhpcyBpcyBkaXNjdXNzZWQgaW4gU2VjdGlvbiA0IG9mIHRoZSANCmRyYWZ0Lg0K W0RlY2Nhbl0gU29ycnksIEkgY2Fubm90IHVuZGVyc3RhbmQgaG93IHRvIGZ1bGZpbGwgdGhpcyBj YXNlIHlldC4gSU1PLCANCnBhY2tldHMgZnJvbSBzaXRlIEEgbmVlZCBjb250YWluIFNJRHMgZm9y IGRlc3RpbmF0aW9ucyBpbiBzaXRlIEIsIHNvIHRoYXQgDQpwYWNrZXRzIGNhbiBmb3J3YXJkIHRv IHRoZSBzcGVjaWZpYyBkZXN0aW5hdGlvbiBjb3JyZWN0bHksIHRoZSBTSUQgb2YgdGhlIA0KUEUg Y2FuIG9ubHkgYmUgdXNlZCB0byBmb3J3YXJkIHBhY2tldHMgdG8gdGhlIFBFLiBBbHRob3VnaCwg YXQgdGhlIGluZ3Jlc3MgDQpub2RlIGluIHNpdGUgQSwgd2UgY2FuIGVuY2Fwc3VsYXRlIFNJRCBv ZiB0aGUgUEUgYWdhaW4gdG8gaGlkZSBTSUQgb2Ygc2l0ZSANCkIgYmVmb3JlIHNlbmRpbmcgcGFj a2V0cywgdGhlIGluZ3Jlc3Mgbm9kZSBpbiBzaXRlIEEgYW5kIHRoZSBQRSBuZWVkIHN0aWxsIA0K c2VlIHRoZSBTSUQgb2Ygc2l0ZSBCLiBBIG5vZGUgaW4gc2l0ZSBBIGNhbiBub3QgZW5zdXJlIGl0 IHdpbGwgb25seSBhY3QgYXMgDQphIHRyYW5zaXQgcm9sZS4gQ291bGQgeW91IGV4cGxhaW4gbW9y ZT8NCg0KICAgTGVzDQoNClRoYW5rcyANCg0KRGVjY2FuIA0KIA0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIA0K KGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIA0KYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBv ZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgDQphbiBpbnRlbmRlZCByZWNpcGll bnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciAN CmRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJy b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmltbWVkaWF0ZWx5Lg0KIA0KIA0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGlu dGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5 Lg0K --=_alternative 000E5AB348257FE6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxlcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNvcnJ5LCBjb3JyZWN0IGEgc3BlbGxpbmcgbWlz dGFrZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPsXtydm4 uzE1MzgxNS91c2VyL3p0ZV9sdGQ8L2I+PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjIwMTYtMDctMDQgMTA6MzI8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7TGVzIEdpbnNiZXJnIChnaW5zYmVyZykm cXVvdDsNCiZsdDtnaW5zYmVyZ0BjaXNjby5jb20mZ3Q7LCA8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0OzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+tPC4tDogUkU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb248L2ZvbnQ+PGEgaHJlZj1Ob3RlczovLy80ODI1N0YyOTAwMDc3OTk2L0NEMkYz MjVEODYwQzc0RDE0ODI1NkM1MjAwNDQ3NUY3LzQ4MjU3RjI5MDAwNzc5OTY0ODI1N0ZFMzAwNUU5 RTZGPsG0vdM8L2E+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+TGVzLCA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlNlZSBpbmxpbmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7TGVzIEdpbnNiZXJnIChnaW5z YmVyZykmcXVvdDsNCiZsdDtnaW5zYmVyZ0BjaXNjby5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNi0wNy0wMiAwMToxMzwvZm9udD4NCjx0 ZCB3aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtwZW5n LnNoYW9mdUB6dGUuY29tLmNuJnF1b3Q7ICZsdDtwZW5nLnNoYW9mdUB6dGUuY29tLmNuJmd0OywN CjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7c3ByaW5nQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJp bmdAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW3NwcmluZ10gZHJhZnQtaWV0 Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPkRl Y2NhbiAtPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9t OjwvYj4gcGVuZy5zaGFvZnVAenRlLmNvbS5jbiBbPC9mb250PjxhIGhyZWY9bWFpbHRvOnBlbmcu c2hhb2Z1QHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+bWFpbHRvOnBlbmcu c2hhb2Z1QHp0ZS5jb20uY248L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0N CjxiPjxicj4NClNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMDEsIDIwMTYgMjo0NiBBTTxiPjxicj4N ClRvOjwvYj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk8Yj48YnI+DQpDYzo8L2I+IHNwcmluZ0Bp ZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij5IaXMgTGVzLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjEpIEZyb20gaW1wbGVt ZW50YXRpb24sIGJlY2F1c2UgcHJlZmVyZW5jZSBhbGdvcml0aG0gaXMgcHJvdG9jb2wgaW5kZXBl bmRlbnQsDQppdCBpcyBiZXR0ZXIgdG8gZG8gY29uZmxpY3QgcmVzb2x1dGlvbiBhdCBhIGNvbW1v biBwbGFjZSwgbm90IGF0IGluZGl2aWR1YWwNCnByb3RvY29sIGluc3RhbmNlLiBGb3IgZXhhbXBs ZSwgd2UgY2FuIGRvIHByZWZpeC1jb25mbGljdCByZXNvbHV0aW9uIHdoZW4NCmdlbmVyYXRlIHRo ZSBwcmVmZXJlbmNlIEZJQiBlbnRyeSBhdCB0aGUgY29tbW9uIHBsYWNlLiBGb3IgYSBwcmVmZXJl bmNlDQpGSUIgZW50cnksIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIG1heSBnZXQgZnJvbSBPU1BG IGJ5IGFkbWluaXN0cmF0aXZlDQpkaXN0YW5jZSwgYnV0IHRoZSBTSUQgaW5mb3JtYXRpb24gbWF5 IGdldCBmcm9tIElTSVMgYnkgcHJlZml4LWNvbmZsaWN0DQphbGdvcml0aG0uIFRoZW4gd2UgY2Fu IGRvIHNpZC1jb25mbGljdCByZXNvbHV0aW9uIHdoZW4gZ2VuZXJhdGUgdGhlIFNJRC1MSUINCmVu dHJ5IGFjY29yZGluZyB0byB0aGUgYWJvdmUgRklCIGVudHJ5IGFuZCBvdGhlciBzb3VyY2VzLCBp dCB3aWxsIHNlbGVjdA0KYSBwcmVmZXJlbmNlIEZFQyB0byBwcm92aWRlIGZvcndhcmRpbmcgaW5m b3JtYXRpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU28sIHByZWZlcmVuY2UgYWxnb3Jp dGhtIHBlciBwcmVmaXgvZmVjIGlzIGVub3VnaC4gUGVyIHJhbmdlIGlzIHBvc3NpYmxlLA0KYnV0 IGltcGxlbWVudGF0aW9uIGlzIGNvbXBsZXguIE1vcmUgY29tcGxleCBpcyBmb3IgJnF1b3Q7aWdu b3Igb3ZlcmxheSZxdW90Ow0KcGVyIHJhbmdlLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPjxiPjxpPltMZXM6XSBJbXBsZW1lbnRhdGlvbi13aXNlLA0KeW91 IGFyZSBmcmVlIHRvIGltcGxlbWVudCB0aGlzIGluIGFueSBtb2R1bGUgeW91IGxpa2Ugc28gbG9u ZyBhcyB3aXRoIHRoZQ0Kc2FtZSBkYXRhYmFzZSB5b3UgY29tZSB1cCB3aXRoIHRoZSBzYW1lIGFu c3dlciBhcyBvdGhlciBub2RlcyBpbiB0aGUgbmV0d29yay48L2k+PC9iPjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48Yj48aT5UaGUgZGlzdGlu Y3Rpb24gYmV0d2Vlbg0KobBRdWFyYW50aW5lobEgYW5kIKGwSWdub3JlIE92ZXJsYXChsSBpcyB0 aGF0IHRoZSBsYXR0ZXIgYXR0ZW1wdHMgdG8NCnVzZSB0aG9zZSBwb3J0aW9ucyBvZiBhIHJhbmdl IHdoaWNoIGRvIG5vdCBoYXZlIGNvbmZsaWN0cyB3aXRoIG90aGVyIGVudHJpZXMuDQpUaGUgY29z dCBvZiBkb2luZyBzbyBpcyBoYXZpbmcgdG8gY3JlYXRlIKGwZGVyaXZlZCBlbnRyaWVzobEgd2hp Y2ggcmVwcmVzZW50DQp0aG9zZSBzdWItcmFuZ2VzIHdoaWNoIGRvL2RvIG5vdCBoYXZlIGNvbmZs aWN0cy4gRHVlIHRvIHRoZSBhZGRlZCBjb21wbGV4aXR5DQp0aGlzIGlzIE5PVCB0aGUgZmlyc3Qg Y2hvaWNlIG9mIHRoZSBhdXRob3JzLiA8L2k+PC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48Yj48aT5JZiBJIHdlcmUgdG8gY2F0ZWdvcml6 ZQ0KdGhlIHR3byBhbGdvcml0aG1zIHVzaW5nIHlvdXIgdGVybWlub2xvZ3kgobBRdWFyYW50aW5l obEgd291bGQgYmUgobBwZXINCnJhbmdlobEgd2hpbGUgobBJZ25vcmUgT3ZlcmxhcKGxIHdvdWxk IGJlIKGwcGVyIHByZWZpeC9GRUOhsS4gU28gaXQNCmlzIHRoZSBsYXR0ZXIgd2hpY2ggaXMgbW9y ZSBjb21wbGV4IHRvIGltcGxlbWVudC48L2k+PC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPltEZWNjYW5dIFlvdSBhcmUgcmlnaHQsIGFzIHBlciBwcmVmaXgvRkVDDQpp cyBhY3R1YWxseSB0byBzcGxpdCB0aGUgb3JpZ2luYWwgcmFuZ2UgdG8gdGhlIHNtYWxsZXN0IG9u ZXMuIE15IG1lYW5pbmcNCmlzIHRoYXQgdGhlcmUgaXMgbm8gcmFuZ2UgaWRlYSBkdXJpbmcgY29u ZmxpY3QgcHJvY2VzcyBwaGFzZSBhdCB0aGUgY29tbW9uDQpwbGFjZSwgYWxsIGlzIGRvbmUgYmFz ZWQgb24gdGhlIGV4aXN0aW5nIGRhdGEgc3RydWN0dXJlIHBlciBwcmVmaXgvRkVDLg0KTWFwcGlu ZyByYW5nZSBvbmx5IGFwcGVhciBpbiB0aGUgaW5kaXZpZHVhbCBwcm90b2NvbCBpbnN0YW5jZSwg YnV0IGl0IGlzDQphbHdheXMgdG8gYmUgc3BsaXQgdG8gdGhlIHNtYWxsZXN0IG9uZXMsIG5vdCBm b3IgY29uZmxpY3QgZnVuY3Rpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KMikgVGhlIHJlc3RyaWN0aW9ucyBpbiBuZXcgc2VjdGlvbiAmcXVvdDtTY29wZSBv ZiBTUi1NUExTIFNJRCBDb25mbGljdHMmcXVvdDsNCm1heWJlIG5vdCB0cnVlLiBQbGVhc2UganVz dCBjb25zaWRlciAmcXVvdDtDYXJyaWVyIG9mIENhcnJpZXImcXVvdDsgY2FzZQ0Kd2hpY2ggZGVw bG95IElHUCtMRFAgYmV0d2VlbiBQRSBhbmQgQ0UuIEl0IGlzIHBvc3NpYmxlIHRvIGRlcGxveSBT UiBMU1ANCmluIHRoZSBzZWNvbmQgbGV2ZWwgY2Fycmllciwgc28gdGhhdCBhbiBTUiBMU1AgaXMg YnVpbGRpbmcgZnJvbSBvbmUgc2l0ZQ0KdG8gYW5vdGhlciBhY3Jvc3MgdGhlIGZpcnN0IGxldmVs IGNhcnJpZXIsIHNhbWUgYXMgYW4gTERQIExTUC4gVGhpcyBtZWFucw0KU0lEcyBhc3NvY2lhdGVk IHdpdGggZGVzdGluYXRpb25zIGluIFNpdGUgQSB3aWxsIGJlIGluc3RhbGxlZCBpbiB0aGUgZm9y d2FyZGluZw0KcGxhbmUgb2Ygcm91dGVycyBpbiBTaXRlIEIuPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MDA0MDgwIGZhY2U9IkNhbGlicmkiPjxiPjxpPjxicj4NCltMZXM6XSBXZSBoYXZlIGxvb2tlZCBh dCChsENhcnJpZXIgb2YgQ2FycmllcqGxIGFuZCB3ZSBkaXNhZ3JlZSB3aXRoDQp5b3VyIGNvbmNs dXNpb24uIFRvIHJlYWNoIGRlc3RpbmF0aW9ucyBpbiBTaXRlIEIgZnJvbSBTaXRlIEEgcGFja2V0 cyB3aWxsDQpuZWVkIHRvIHRyYXZlcnNlIHRoZSBQRShzKSBjb25uZWN0ZWQgdG8gU2l0ZSBBLiBX aGF0IHdpbGwgYmUgaW5zdGFsbGVkDQppbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBvZiByb3V0ZXJz IGluIFNpdGUgQSB3aWxsIGJlIGxhYmVscyBhc3NvY2lhdGVkDQp3aXRoIHRoZSBTSUQgb2YgdGhl IFBFIKhDIG5vdCB0aGUgU0lEcyBmb3IgZGVzdGluYXRpb25zIGluIFNpdGUgQi4gSW4gZmFjdCwN Cml0IGlzIHBvc3NpYmxlIGZvciBkZXN0aW5hdGlvbiAxLjEuMS4xIGluIFNpdGUgQSB0byB1c2Ug dGhlIHNhbWUgU0lEIGFzDQpkZXN0aW5hdGlvbiAyLjIuMi4yIGluIFNpdGUgQi4gVGhpcyBpcyBk aXNjdXNzZWQgaW4gU2VjdGlvbiA0IG9mIHRoZSBkcmFmdC48L2k+PC9iPjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgY29sb3I9IzAwNDA4MCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltEZWNjYW5d IFNvcnJ5LCBJDQpjYW5ub3QgdW5kZXJzdGFuZCBob3cgdG8gZnVsZmlsbCB0aGlzIGNhc2UgeWV0 LiBJTU8sPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGNvbG9yPSMwMDQwODAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5wYWNrZXRzIGZyb20gc2l0 ZQ0KQSBuZWVkIGNvbnRhaW4gU0lEcyBmb3IgZGVzdGluYXRpb25zIGluIHNpdGUgQiwgc28gdGhh dCBwYWNrZXRzIGNhbiBmb3J3YXJkDQp0byB0aGUgc3BlY2lmaWMgZGVzdGluYXRpb24gPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Y29ycmVjdGx5LA0KdGhlIFNJRCBvZiB0aGUgUEUg Y2FuIG9ubHkgYmUgdXNlZCB0byBmb3J3YXJkIHBhY2tldHMgdG8gdGhlIFBFLiBBbHRob3VnaCwN CmF0IHRoZSBpbmdyZXNzIG5vZGUgaW4gc2l0ZSBBLCB3ZSBjYW4gZW5jYXBzdWxhdGUgU0lEIG9m IHRoZSBQRSBhZ2FpbiB0bw0KaGlkZSBTSUQgb2Ygc2l0ZSBCIGJlZm9yZSBzZW5kaW5nIHBhY2tl dHMsIHRoZSBpbmdyZXNzIG5vZGUgaW4gc2l0ZSBBIGFuZA0KdGhlIFBFIG5lZWQgc3RpbGwgc2Vl IHRoZSBTSUQgb2Ygc2l0ZSBCLiBBIG5vZGUgaW4gc2l0ZSBBIGNhbiBub3QgZW5zdXJlDQppdCB3 aWxsIG9ubHkgYWN0IGFzIGEgdHJhbnNpdCByb2xlLiBDb3VsZCB5b3UgZXhwbGFpbiBtb3JlPzwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9IzAwNDA4MCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOyAmbmJzcDtMZXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpUaGFua3MgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkRlY2Nh bjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij5aVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkNCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZA0KaGVyZXdpdGgpIGlzIHByaXZp bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUN CnVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRl ZCByZWNpcGllbnQsIGFueQ0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YNCnRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCnRo aXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0 ZWx5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiZuYnNwOzwvZm9udD4NCjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlz IHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNs dXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBv ciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwg aW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0K PC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 000E5AB348257FE6_=-- From nobody Mon Jul 4 00:51:43 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0026E12D0A5; Mon, 4 Jul 2016 00:51:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160704075141.2574.57473.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2016 00:51:41 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 07:51:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing interworking with LDP Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Filename : draft-ietf-spring-segment-routing-ldp-interop-04.txt Pages : 20 Date : 2016-07-04 Abstract: A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This drafts describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 4 00:53:27 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D64712B01A for ; Mon, 4 Jul 2016 00:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV8wwEoYtCum for ; Mon, 4 Jul 2016 00:53:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1BF12B012 for ; Mon, 4 Jul 2016 00:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3178; q=dns/txt; s=iport; t=1467618804; x=1468828404; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JbNY6Sheaj4BHcrBbF9oWUrrmVepMxpRVVi3gUCZStU=; b=Inta1lCTXq4Ko2eXlokYDhwHFulX/NWYYuQy97rV89ubTQAOQsyC14ly b0gQIi9slEMyFqG/x8vLCgjOLrYS3JpMImcE5qTpIrQa0M8kK5TRmt9hO U3Y5ZyvGIVQTkxSjeNQ4nAsbtgY6zXXX065koOPkl+wl2tPBIT3vVCbIW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgB6FXpX/5pdJa1cgz5WfAa5LYF5J?= =?us-ascii?q?IUqSgIcgRU4FAEBAQEBAQFlJ4RMAQEEAQEBIRE6EAsCAQgSBgICJgICAiULFQI?= =?us-ascii?q?OAgQTiCgIDqpBjz0BAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGFJ4F4glWEQIMBK?= =?us-ascii?q?4IvBZkTAYYIiD6Bak6ECIhqkAkBHjaDcG6IDX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,573,1459814400"; d="scan'208";a="121893909" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2016 07:53:23 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u647rNUE018518 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Jul 2016 07:53:23 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 4 Jul 2016 03:53:22 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 4 Jul 2016 03:53:22 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-04.txt Thread-Index: AQHR1cjrg/zvWlfZ/0e6aIcfNaTfS6AIKb6A Date: Mon, 4 Jul 2016 07:53:22 +0000 Message-ID: References: <20160704075141.2574.57473.idtracker@ietfa.amsl.com> In-Reply-To: <20160704075141.2574.57473.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.220] Content-Type: text/plain; charset="utf-8" Content-ID: <428EB1BDC9BB35458478A4898757CD77@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 07:53:26 -0000 QWRkZWQgdGV4dCBvbiBMRFAgd2hlbiB1c2VkIGluIOKAnGluZGVwZW5kZW50IHZzLiBvcmRlcmVk 4oCdIGRpc3RyaWJ1dGlvbiBtb2RlLg0KDQp0aGFua3MuDQpzLg0KDQoNCj4gT24gSnVsIDQsIDIw MTYsIGF0IDk6NTEgQU0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4gDQo+IA0K PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIFNvdXJjZSBQYWNrZXQgUm91dGluZyBpbiBOZXR3b3JraW5nIG9mIHRoZSBJRVRGLg0KPiAN Cj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFNlZ21lbnQgUm91dGluZyBpbnRlcndvcmtpbmcg d2l0aCBMRFANCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IENsYXJlbmNlIEZpbHNmaWxzDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVmYW5vIFByZXZpZGkNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIEFobWVkIEJhc2hhbmR5DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBC cnVubyBEZWNyYWVuZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgU3RlcGhhbmUgTGl0a293 c2tpDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctbGRwLWludGVyb3AtMDQudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAyMA0KPiAJRGF0ZSAg ICAgICAgICAgIDogMjAxNi0wNy0wNA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgQSBTZWdtZW50IFJv dXRpbmcgKFNSKSBub2RlIHN0ZWVycyBhIHBhY2tldCB0aHJvdWdoIGEgY29udHJvbGxlZCBzZXQN Cj4gICBvZiBpbnN0cnVjdGlvbnMsIGNhbGxlZCBzZWdtZW50cywgYnkgcHJlcGVuZGluZyB0aGUg cGFja2V0IHdpdGggYW4gU1INCj4gICBoZWFkZXIuICBBIHNlZ21lbnQgY2FuIHJlcHJlc2VudCBh bnkgaW5zdHJ1Y3Rpb24sIHRvcG9sb2dpY2FsIG9yDQo+ICAgc2VydmljZS1iYXNlZC4gIFNSIGFs bG93cyB0byBlbmZvcmNlIGEgZmxvdyB0aHJvdWdoIGFueSB0b3BvbG9naWNhbA0KPiAgIHBhdGgg YW5kIHNlcnZpY2UgY2hhaW4gd2hpbGUgbWFpbnRhaW5pbmcgcGVyLWZsb3cgc3RhdGUgb25seSBh dCB0aGUNCj4gICBpbmdyZXNzIG5vZGUgdG8gdGhlIFNSIGRvbWFpbi4NCj4gDQo+ICAgVGhlIFNl Z21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgY2FuIGJlIGRpcmVjdGx5IGFwcGxpZWQgdG8gdGhl IE1QTFMNCj4gICBkYXRhIHBsYW5lIHdpdGggbm8gY2hhbmdlIGluIHRoZSBmb3J3YXJkaW5nIHBs YW5lLiAgVGhpcyBkcmFmdHMNCj4gICBkZXNjcmliZXMgaG93IFNlZ21lbnQgUm91dGluZyBvcGVy YXRlcyBpbiBhIG5ldHdvcmsgd2hlcmUgTERQIGlzDQo+ICAgZGVwbG95ZWQgYW5kIGluIHRoZSBj YXNlIHdoZXJlIFNSLWNhcGFibGUgYW5kIG5vbi1TUi1jYXBhYmxlIG5vZGVzDQo+ICAgY29leGlz dC4NCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcC8NCj4gDQo+IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9wLTA0 DQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3AtMDQNCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmluZ0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQo= From nobody Mon Jul 4 01:00:23 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE96612D0C2 for ; Mon, 4 Jul 2016 01:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLDPVj3ogdNU for ; Mon, 4 Jul 2016 01:00:18 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C956012B012 for ; Mon, 4 Jul 2016 01:00:17 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id q132so111984150lfe.3 for ; Mon, 04 Jul 2016 01:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3G2QqQnDBHi3wD6L0jT1X0BTcZAKg1NO3xezmWLvuZU=; b=DiMe0F83vYlsLJN50O6XbMPNUA0ECZlCf062WJ1MeaJ8ipQD9d4anrE+7Wh7X6Qu+b A0JyFC01uKOYFsgFHm63MPsf1Tya61sRLdOKPyQwsWnmjE+lTd+QvKp/V0CdkjVus1Tv Ug9aMwTUyM+SkZBVSmvZ1r+ssD/F0H3Rk+GTXQXptT6Ye+meY8E+GFB9rwJw8Z51eIlA t1JxPsHzY7XyNNyv9E7qXrWOMTrLZ9lUlC0Xz73KAhCI/txgNpRw2SC/QG8ytexn7mFl ztUhH7trogymaX7WvpKV/opnyP6gzU7/TWIWJm7oLTgeQtxk9YO8V3uyzKK1/MmfMtUv 5imA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3G2QqQnDBHi3wD6L0jT1X0BTcZAKg1NO3xezmWLvuZU=; b=bCVyGZGfBoNpSNWf7drc5BabcrdiunJXPAaxE2CkEkpXpmKZi16ia6AF+qHWoK+Zvj X0ZHpuENLp5KGjvQSgXBrzEoClRiMmeHCB5qSkodnlAx5DelERrQAeRmLo9EhkuHmJsf tk8ET83jejLSfH/AzGbIEPYUQuXGSH3uzGz/8hFS1H9mzCVeaQywlq+I5TjLKgWlIRz/ PPhKZBCZcbuRvuqub3fOQjztrlSmDADvizZHA83lKmmevhTk8IJ37TDoVr9rTSd4hOl5 35aapwJxtAkm54EBIcnzxMkuEk6PVB1n5XKzsUSgDMUvfL9qRg6N/gv47ch5oPG9DLCg xUaw== X-Gm-Message-State: ALyK8tL/rBIP5Nd5gHs9+aUgra+jXfOQ+dDyUz4fjc3F58Nf1Db9G1EZNaaNIkmMOeKEL7wbjdgyv6IjUkIV6A== X-Received: by 10.25.18.35 with SMTP id h35mr2005335lfi.82.1467619215889; Mon, 04 Jul 2016 01:00:15 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Mon, 4 Jul 2016 01:00:14 -0700 (PDT) In-Reply-To: References: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> From: Robert Raszuk Date: Mon, 4 Jul 2016 10:00:14 +0200 X-Google-Sender-Auth: _C6DT3wn-waUUATH-v2AY7OU7KY Message-ID: To: peng.shaofu@zte.com.cn Content-Type: multipart/alternative; boundary=001a113fbed2075aa40536caba73 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" Subject: Re: [spring] =?utf-8?b?562U5aSNOiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29u?= =?utf-8?q?flict-resolution?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 08:00:22 -0000 --001a113fbed2075aa40536caba73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Peng, On the point #2 you are right that externally received SIDs will be installed in the data plane of PEs. However you need to observe that they will be installed in completely separate "contexts" in data plane hence current addition (after I brought this issue few weeks back) has been accurately addressed in new sections 3.2.6 and 4. All what you are saying is true and the current draft enables one to do that yet to keep consistent base topology in the network. Well modulo comments from Bruno which have not been yet well addressed. Cheers, R. On Mon, Jul 4, 2016 at 4:32 AM, wrote: > Les, > > See inline. > > > > > > > *"Les Ginsberg (ginsberg)" >* > > 2016-07-02 01:13 > =E6=94=B6=E4=BB=B6=E4=BA=BA > "peng.shaofu@zte.com.cn" , > > =E6=8A=84=E9=80=81 > "spring@ietf.org" > > =E4=B8=BB=E9=A2=98 > RE: [spring] draft-ietf-spring-conflict-resolution > > > > > Deccan - > > *From:* peng.shaofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn > ] > * Sent:* Friday, July 01, 2016 2:46 AM > * To:* Les Ginsberg (ginsberg) > * Cc:* spring@ietf.org > * Subject:* Re: [spring] draft-ietf-spring-conflict-resolution > > His Les, > > 1) From implementation, because preference algorithm is protocol > independent, it is better to do conflict resolution at a common place, no= t > at individual protocol instance. For example, we can do prefix-conflict > resolution when generate the preference FIB entry at the common place. Fo= r > a preference FIB entry, the routing information may get from OSPF by > administrative distance, but the SID information may get from ISIS by > prefix-conflict algorithm. Then we can do sid-conflict resolution when > generate the SID-LIB entry according to the above FIB entry and other > sources, it will select a preference FEC to provide forwarding informatio= n. > So, preference algorithm per prefix/fec is enough. Per range is possible, > but implementation is complex. More complex is for "ignor overlay" per > range. > > *[Les:] Implementation-wise, you are free to implement this in any module > you like so long as with the same database you come up with the same answ= er > as other nodes in the network.* > *The distinction between =E2=80=9CQuarantine=E2=80=9D and =E2=80=9CIgnore= Overlap=E2=80=9D is that the > latter attempts to use those portions of a range which do not have > conflicts with other entries. The cost of doing so is having to create > =E2=80=9Cderived entries=E2=80=9D which represent those sub-ranges which = do/do not have > conflicts. Due to the added complexity this is NOT the first choice of th= e > authors. * > *If I were to categorize the two algorithms using your terminology > =E2=80=9CQuarantine=E2=80=9D would be =E2=80=9Cper range=E2=80=9D while = =E2=80=9CIgnore Overlap=E2=80=9D would be =E2=80=9Cper > prefix/FEC=E2=80=9D. So it is the latter which is more complex to impleme= nt.* > [Deccan] You are right, as per prefix/FEC is actually to split the > original range to the smallest ones. My meaning is that there is no range > idea during conflict process phase at the common place, all is done based > on the existing data structure per prefix/FEC. Mapping range only appear = in > the individual protocol instance, but it is always to be split to the > smallest ones, for ra for conflict function. > > 2) The restrictions in new section "Scope of SR-MPLS SID Conflicts" maybe > not true. Please just consider "Carrier of Carrier" case which deploy > IGP+LDP between PE and CE. It is possible to deploy SR LSP in the second > level carrier, so that an SR LSP is building from one site to another > across the first level carrier, same as an LDP LSP. This means SIDs > associated with destinations in Site A will be installed in the forwardin= g > plane of routers in Site B. > > * [Les:] We have looked at =E2=80=9CCarrier of Carrier=E2=80=9D and we di= sagree with your > conclusion. To reach destinations in Site B from Site A packets will need > to traverse the PE(s) connected to Site A. What will be installed in the > forwarding plane of routers in Site A will be labels associated with the > SID of the PE =E2=80=93 not the SIDs for destinations in Site B. In fact,= it is > possible for destination 1.1.1.1 in Site A to use the same SID as > destination 2.2.2.2 in Site B. This is discussed in Section 4 of the draf= t.* > [Deccan] Sorry, I cannot understand how to fulfill this case yet. IMO, pa= ckets > from site A need contain SIDs for destinations in site B, so that packets > can forward to the specific destination correctly, the SID of the PE can > only be used to forward packets to the PE. Although, at the ingress node = in > site A, we can encapsulate SID of the PE again to hide SID of site B befo= re > sending packets, the ingress node in site A and the PE need still see the > SID of site B. A node in site A can not ensure it will only act as a > transit role. Could you explain more? > > Les > > Thanks > > Deccan > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > (and any attachment transmitted herewith) is privileged and confidential > and is intended for the exclusive use of the addressee(s). If you are no= t > an intended recipient, any disclosure, reproduction, distribution or othe= r > dissemination or use of the information contained is strictly prohibited. > If you have received this mail in error, please delete it and notify us > immediately. > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --001a113fbed2075aa40536caba73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Peng,

On the point #2 you are right that externally receiv= ed SIDs will be installed in the data plane of PEs.=C2=A0

However you need to observe that they= will be installed in completely separate "contexts" in data plan= e hence current addition (after I brought this issue few weeks back) has be= en accurately addressed in new sections 3.2.6 and 4.=C2=A0

All what you are saying is true and t= he =C2=A0current draft enables one to do that yet to keep consistent base t= opology in the network. Well modulo comments from Bruno which have not been= yet well addressed.=C2=A0

Cheers,
R.


On Mon, Jul 4, 2016 at 4:32 AM, = <peng.shaofu@zte.com.cn> wrote:
Les,

See inline.






"Les Ginsber= g (ginsberg)" <ginsberg@cisco.= com>

2016-07-02 01:13

=E6=94=B6=E4=BB= =B6=E4=BA=BA
"peng.shaofu@zte.com.cn" <<= a href=3D"mailto:peng.shaofu@zte.com.cn" target=3D"_blank">peng.shaofu@zte.= com.cn>,
=E6=8A=84=E9=80= =81
"spring@ietf.org" <spring@ietf.org>
=E4=B8=BB=E9=A2= =98
RE: [spring] draft-ietf-sprin= g-conflict-resolution





Deccan -
=C2=A0
From: peng.shaofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn]
Sent: Friday, July 01, 2016 2:46 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.or= g
Subject: Re: [spring] draft-ietf-spring-conflict-resolution
=C2=A0
His Les,

1) From implementation, because preference algorithm is protocol independen= t, it is better to do conflict resolution at a common place, not at individual protocol instance. For example, we can do prefix-conflict resolution when generate the preference FIB entry at the common place. For a preference FIB entry, the routing information may get from OSPF by administrative distance, but the SID information may get from ISIS by prefix-conflict algorithm. Then we can do sid-conflict resolution when generate the SID-LIB entry according to the above FIB entry and other sources, it will select a preference FEC to provide forwarding information.
So, preference algorithm per prefix/fec is enough. Per range is possible, but implementation is complex. More complex is for "ignor overlay"= ; per range.

[Les:] Implem= entation-wise, you are free to implement this in any module you like so long as with the same database you come up with the same answer as other nodes in the networ= k.
The distincti= on between =E2=80=9CQuarantine=E2=80=9D and =E2=80=9CIgnore Overlap=E2=80=9D is that t= he latter attempts to use those portions of a range which do not have conflicts with other entrie= s. The cost of doing so is having to create =E2=80=9Cderived entries=E2=80=9D = which represent those sub-ranges which do/do not have conflicts. Due to the added complexit= y this is NOT the first choice of the authors.
If I were to = categorize the two algorithms using your terminology =E2=80=9CQuarantine=E2=80=9D woul= d be =E2=80=9Cper range=E2=80=9D while =E2=80=9CIgnore Overlap=E2=80=9D would be =E2=80=9Cper= prefix/FEC=E2=80=9D. So it is the latter which is more complex to implement.
[Deccan] You are right, as per p= refix/FEC is actually to split the original range to the smallest ones. My meaning is that there is no range idea during conflict process phase at the common place, all is done based on the existing data structure per prefix/FEC. Mapping range only appear in the individual protocol instance, but it is always to be split to the smallest ones, for ra for conflict function.

2) The restrictions in new section "Scope of SR-MPLS SID Conflicts&quo= t; maybe not true. Please just consider "Carrier of Carrier" case which deploy IGP+LDP between PE and CE. It is possible to deploy SR LSP in the second level carrier, so that an SR LSP is building from one site to another across the first level carrier, same as an LDP LSP. This means SIDs associated with destinations in Site A will be installed in the forwar= ding plane of routers in Site B.

[Les:] We have looked at =E2=80=9CCarrier of Carrier=E2=80=9D and we disagr= ee with your conclusion. To reach destinations in Site B from Site A packets will need to traverse the PE(s) connected to Site A. What will be installed in the forwarding plane of routers in Site A will be labels associated with the SID of the PE =E2=80=93 not the SIDs for destinations in Site B. I= n fact, it is possible for destination 1.1.1.1 in Site A to use the same SID as destination 2.2.2.2 in Site B. This is discussed in Section 4 of the draft.=
[Dec= can] Sorry, I cannot understand how to fulfill this case yet. IMO, packets = from site A need contain SIDs for destinations in site B, so that packets can forward to the specific destination correctl= y, the SID of the PE can only be used to forward packets to the PE. Although, at the ingress node in site A, we can encapsulate SID of the PE again to hide SID of site B before sending packets, the ingress node in site A and the PE need still see the SID of site B. A node in site A can not ensure it will only act as a transit role. Could you explain more?

=C2=A0 =C2= =A0Les

Thanks

Deccan
=C2=A0
------------------= --------------------------------------
ZTE Information Se= curity Notice: The information contained in this mail (and any attachment transmit= ted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).=C2=A0 If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.=C2=A0 If you have receive= d this mail in error, please delete it and notify us immediately.
=C2=A0
=C2=A0 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


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


--001a113fbed2075aa40536caba73-- From nobody Mon Jul 4 05:07:13 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80C212D0C4 for ; Mon, 4 Jul 2016 05:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt40WDZDbNWy for ; Mon, 4 Jul 2016 05:07:07 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFD1127058 for ; Mon, 4 Jul 2016 05:07:06 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 3BE5C203F6; Mon, 4 Jul 2016 14:07:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id D1BD420066; Mon, 4 Jul 2016 14:07:04 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0294.000; Mon, 4 Jul 2016 14:07:04 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwAAFyNVQACk7FpAAGrmsQACp0a4w Date: Mon, 4 Jul 2016 12:07:04 +0000 Message-ID: <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F92A129OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 12:07:11 -0000 --_000_53C29892C857584299CBF5D05346208A0F92A129OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 3:12 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I don't find your representation complete as regards all of the attributes = which are proposed to be used by the conflict resolution algorithm - so it = is therefore hard for me to use/understand this representation when applyin= g the defined preference rule. This is true for me even after reading your explanations below. But it is far more important to have a common understanding of the algorith= m proposal than it is to be arguing over whose encoding is "better". If the= encoding in the draft is not clear or could use improvement, I welcome you= r feedback. As far as your "pseudo-code": - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID The fact that you can represent an algorithm in a few lines does not mean t= he implementation of the algorithm is just as simple. [Bruno] Sure. But if we want to compare implementation complexity, we'll ne= ed to agree on how much we want to go into details, in order to have meanin= gful comparison. So far this is not clear to me as you sometimes argue that= data structure is implementation specific and you don't want to go into th= is (which I agree) and sometime you detail the data structure. There is also the option to consider this as "implementation issue" and let= this to implementations. Coming back to my per FEC algo, all what is required from the data structur= e, is a way/API to get the data back, though 2 keys: get me the SID matchin= g prefix P1 (for the first line), get me the prefixes matching the SID SIDi= for the second line. That seem like a reasonable requirement on the data s= tructure, and any option in your draft also requires this to detect prefix = conflict and SID conflict (since this is all my per FEC algo is doing in th= ese 2 first lines). Going into more details, my per FEC algo only requires to detail that one p= refix or SID belong to a range (of prefix or SID) while your per range algo= requires to compute range intersection which is harder. So the API to fetc= h the data can only be easier. Consider what needs to be done to implement "Find all SIDi advertised for the prefix P1" In its simplest form, we have a list of all SID advertisements (PFX and SRM= S) that we have received. One could imagine walking all the entries, lookin= g to see if the prefix of interest is present within the advertised range. = But, of course, at large scale such an approach is extremely inefficient - = so we immediately start considering ways to improve performance. Inserting = received entries into an ordered tree of some kind is an obvious way to imp= rove performance. When one further considers that calculating conflict reso= lution only needs to be done when a change to the received database occurs = (which post startup is infrequent) it becomes very attractive to cache the = "winning entries" so that if one wants to retrieve the SID for a given pref= ix we only have to examine a subset of the total database - ignoring the lo= sers. [Bruno] I agree that the per range algo (ignore overlap only) will be able = to ignore the losers but at the cost of a more complex algo and at the cost= of creating new derived entries. It's not clear to me if the net result is= positive. Plus I would expect that the number of conflit is small compared= to the number of prefix /SID so this looks like a second order optimizatio= n. In this context, we can appreciate the difference between the three propose= d algorithms. In particular comparing "Quarantine" with "ignore overlap onl= y", a key difference is that "Quarantine" only needs to determine whether a= received entry is a winning entry or a losing entry. "Ignore overlap only"= has to be capable of breaking received entries with ranges > 1 into multip= le "derived" entries (some winning, some losing), which means we now need t= o track the "derived entries" against the original received entry so that i= f the received entry is updated/deleted we can find all the derived entries= and delete/regenerate the derived entries as needed. This is what adds com= plexity. [Bruno] and that it why the per FEC algo seems easier. So it would seem useful to add it in the draft so that we can all discuss i= t. All proposed algorithms can be implemented, but it does seem prudent to con= sider implementation complexity as part of our decision process - and the d= iscussion/examples in Section 3 are meant to help in doing this. It is worthwhile restating that when conflicts are present we cannot guaran= tee that forwarding will work correctly no matter what algorithm is used. [Bruno] I'm not sure to see what you have in mind exactly. Can you elaborat= e? To me consistency seem enough. The more complex the implementation the more likely it is that bugs will b= e present and the more likely it is that interoperability issues will arise= . Whether these costs/risks are worth the "value add" when the outcome cann= ot be guaranteed to be correct - only guaranteed to be consistent - is an i= mportant consideration. Also important to remember that conflicts MUST be eliminated by correcting = the misconfigurations that caused them - so conflict resolution is really o= nly an interim measure until the corrections can be made. [Bruno] By "interim" we are at minimum talking about 10s of minutes, if not= more than 1 hour since identifying the root cause may not be obvious. The = impact is very significant on the network. The "Quarantine" algo has the potential to kill 100s PE and 1000s of VPN cu= stomers, so a single configuration change on a unrelated router which may n= ot even be in production (i.e. where configuration checks and operations ho= urs may be relaxed) No one should be lulled into thinking that because we have conflict resolut= ion deployed that correcting the configuration when conflicts are detected = is not a priority. [Bruno] I could not agree more that conflict needs to be identified and fix= ed. Note that I'm the one having asked for defining YANG notifications to r= eport this. You are welcomed to state in the draft that conflicts needs to be reported = to the network operator, in particular though yang notification, and other = existing means. Plus that network operator needs to fixed them ASAP (but st= ill carefully) Thanks --Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:00 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. [Bruno] I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there w= as a way to make progress by asking clarification questions on the points w= hich were not clear, or at least explicitly refusing to consider the email. I also note that what bothered you in my representation was my addition of = the type of advertisement (prefix or MS). But you finally have just added i= n the latest version of the draft "Src- PFX or SRMS" . So there was probabl= y a way to communicate. Besides the algo did not use any specification representation, just names. = So I'll copy/paste it below, please ask clarification questions for the par= ts which are not clear enough. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, for P1, we get a list of (SIDi, Pij) Get the best (SIDi, Pij) as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? [Bruno] - MS/prefix SID is the type of advertisement. In your new version, you call= it SRMS/PFX. - SID is the SID found in the Mapping Entrie - Rx is the loopback (prefix) or router Rx So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and= means: For prefix R2, we found a MS mapping entries advertising SID2 for t= his prefix, and then I found a MS mapping entries advertising prefix R2 for= SID2. Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . [Bruno] I agree that since the above algo used 2 mapping entries to provide= s the (SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted.= That being said, this is not important for this discussion. Let's just con= sidered that their exist a preference algorithm, which takes as input a lis= t of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition = of "best" is not pertinent) ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. [Bruno] Indeed, this is my expectation. But I would need someone's review t= o confirm this. But the difference is that the proposed algo is simple (2 lines of pseudo c= ode), with very modest resquirement data structure use to store the mapping= entries. Indeed, all it needs is a function returning the list of mapping = entries associated/matching a given prefix. And function returning the list= of mapping entries associated/matching a given SID. In particular, there is no need for splitting mapping entries which is the = main complexity of your proposed "Preference algorithm/ignore overlap only"= . (according to your own text). -- Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy. I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F92A129OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,

 

Please see inline [Bruno]

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:12 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

I don&#= 8217;t find your representation complete as regards all of the attributes w= hich are proposed to be used by the conflict resolution algorithm – s= o it is therefore hard for me to use/understand this representation when applying the defined preference rule.

This is= true for me even after reading your explanations below.

&n= bsp;

But it = is far more important to have a common understanding of the algorithm propo= sal than it is to be arguing over whose encoding is “better”. I= f the encoding in the draft is not clear or could use improvement, I welcome your feedback.

&n= bsp;

As far = as your “pseudo-code”:

&n= bsp;

- Find all SIDi advertised for the prefix P1 =             &nb= sp;            =             &nb= sp;            =         // identification of Prefix conf= licts

        &n= bsp;       - For each SIDi find all the prefi= x Pij associated with SIDi         =      // identification of SID conflicts=

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

        &n= bsp;       then use SIDij for P1

        &n= bsp;       else return no SID      = ;            &n= bsp;      

&n= bsp;

The fac= t that you can represent an algorithm in a few lines does not mean the impl= ementation of the algorithm is just as simple.

&n= bsp;

[Bruno] Sure. But if we want to= compare implementation complexity, we’ll need to agree on how much w= e want to go into details, in order to have meaningful comparison. So far t= his is not clear to me as you sometimes argue that data structure is implementation specific and you don’t want to= go into this (which I agree) and sometime you detail the data structure.

There is also the option to con= sider this as “implementation issue” and let this to implementa= tions.

 

Coming back to my per FEC algo,= all what is required from the data structure, is a way/API to get the data= back, though 2 keys: get me the SID matching prefix P1 (for the first line= ), get me the prefixes matching the SID SIDi for the second line. That seem like a reasonable requirement on t= he data structure, and any option in your draft also requires this to detec= t prefix conflict and SID conflict (since this is all my per FEC algo is do= ing in these 2 first lines).

 

Going into more details, my per= FEC algo only requires to detail that one prefix or SID belong to a range = (of prefix or SID) while your per range algo requires to compute range inte= rsection which is harder. So the API to fetch the data can only be easier.

&n= bsp;

&n= bsp;

&n= bsp;

Conside= r what needs to be done to implement

&n= bsp;

 &= nbsp; “Find all SIDi advertised for the prefix P1”

&n= bsp;

In its = simplest form, we have a list of all SID advertisements (PFX and SRMS) that= we have received. One could imagine walking all the entries, looking to se= e if the prefix of interest is present within the advertised range. But, of course, at large scale such an approa= ch is extremely inefficient – so we immediately start considering way= s to improve performance. Inserting received entries into an ordered tree o= f some kind is an obvious way to improve performance. When one further considers that calculating conflict resoluti= on only needs to be done when a change to the received database occurs (whi= ch post startup is infrequent) it becomes very attractive to cache the R= 20;winning entries” so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of= the total database – ignoring the losers.

[Bruno] I agree that the per ra= nge algo (ignore overlap only) will be able to ignore the losers but at the= cost of a more complex algo and at the cost of creating new derived entrie= s. It’s not clear to me if the net result is positive. Plus I would expect that the number of conflit is small compa= red to the number of prefix /SID so this looks like a second order optimiza= tion.

&n= bsp;

In this= context, we can appreciate the difference between the three proposed algor= ithms. In particular comparing “Quarantine” with “ignore = overlap only”, a key difference is that “Quarantine” only needs to determine whether a received entry is a winning entry or a losing= entry. “Ignore overlap only” has to be capable of breaking rec= eived entries with ranges > 1 into multiple “derived” entrie= s (some winning, some losing), which means we now need to track the “derived entries” against the original received entry so t= hat if the received entry is updated/deleted we can find all the derived en= tries and delete/regenerate the derived entries as needed. This is what add= s complexity.

[Bruno] and that it why the per= FEC algo seems easier.

So it would seem useful to add = it in the draft so that we can all discuss it.

&n= bsp;

All pro= posed algorithms can be implemented, but it does seem prudent to consider i= mplementation complexity as part of our decision process – and the di= scussion/examples in Section 3 are meant to help in doing this.

&n= bsp;

It is w= orthwhile restating that when conflicts are present we cannot guarantee tha= t forwarding will work correctly no matter what algorithm is used.

[Bruno] I’m not sure to s= ee what you have in mind exactly. Can you elaborate? To me consistency seem= enough.

 T= he more complex the implementation the more likely it is that bugs will be = present and the more likely it is that interoperability issues will arise. = Whether these costs/risks are worth the “value add” when the outcome cannot be guaranteed to be correct – onl= y guaranteed to be consistent – is an important consideration.=

&n= bsp;

Also im= portant to remember that conflicts MUST be eliminated by correcting the mis= configurations that caused them – so conflict resolution is really on= ly an interim measure until the corrections can be made.

[Bruno] By “interim”= ; we are at minimum talking about 10s of minutes, if not more than 1 hour s= ince identifying the root cause may not be obvious. The impact is very sign= ificant on the network.

The “Quarantine” al= go has the potential to kill 100s PE and 1000s of VPN customers, so a singl= e configuration change on a unrelated router which may not even be in produ= ction (i.e. where configuration checks and operations hours may be relaxed)

&n= bsp;

&n= bsp;

No one = should be lulled into thinking that because we have conflict resolution dep= loyed that correcting the configuration when conflicts are detected is not = a priority.

[Bruno] I could not agree more = that conflict needs to be identified and fixed. Note that I’m the one= having asked for defining YANG notifications to report this.

You are welcomed to state in th= e draft that conflicts needs to be reported to the network operator, in par= ticular though yang notification, and other existing means. Plus that netwo= rk operator needs to fixed them ASAP (but still carefully)

 

Thanks

--Bruno

&n= bsp;

 &= nbsp; Les

&n= bsp;

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks = for the discussion. Please see inline [Bruno]

&n= bsp;

&n= bsp;

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

As the = thread below documents, I stated that I did not understand your representat= ion and asked for clarification – suggesting that you use the format = defined in the draft.

You sta= ted that you could not do that and we were at a point where no progress cou= ld be made.

[Bruno]= I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there was a way to make progress by asking cl= arification questions on the points which were not clear, or at least expli= citly refusing to consider the email.

I also note that what bot=
hered you in my representation was my addition of the type of advertisement=
 (prefix or MS). But you finally have just added in the latest version of t=
he draft “Src- PFX or SRMS” . So there was probably a way to communica=
te.

&n= bsp;

&n= bsp;

Besides= the algo did not use any specification representation, just names. So I= 217;ll copy/paste it below, please ask clarification questions for the part= s which are not clear enough.

&n= bsp;

The pro= blem that we need to solve, is to find the SID for a prefix (P1).

The alg= o could be:

- Find = all SIDi advertised for the prefix P1      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  // identification of Prefix conflicts

 &= nbsp;           &nbs= p;  - For each SIDi find all the prefix Pij associated with SIDi =              //= identification of SID conflicts

&n= bsp;

// as a= result, for P1, we get a list of (SIDi, Pij)

&n= bsp;

Get the= best (SIDi, Pij) as per the preference algorithm.

If best= Pij =3D=3D P1

 &= nbsp;           &nbs= p;  then use SIDij for P1

 &= nbsp;           &nbs= p;  else return no SID        =             &nb= sp;     / no SID available for this prefix P1

&n= bsp;

&n= bsp;

&n= bsp;

To illu= strate my confusion, one of your examples is:

&n= bsp;

For R2, the algo evaluates a conflict between the foll= owing advertisments:

   R2 - SID2 - R2 (MS, MS)=

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, p= refix SID)

  

&n= bsp;

Now, wh= at does “R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]=

- MS/pr= efix SID is the type of advertisement. In your new version, you call it SRM= S/PFX.

- SID i= s the SID found in the Mapping Entrie

- Rx is= the loopback (prefix) or router Rx

&n= bsp;

So R= 20;R2 - SID2 - R2 (MS, MS)” is the outpout of the algo describe= d above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this p= refix, and then I found a MS mapping entries advertising prefix R2 for SID2.

&n= bsp;

Does it= mean  “On R2, SID2 is assigned to prefix R2 from two different = mapping server entries?” I really have no idea.

&n= bsp;

And you= conclude the example by saying

&n= bsp;

Best one is R2 - SID12 - R2 (smaller range (prefix SID= ),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.=

&n= bsp;

But sin= ce there is no representation of “range” in your examples I rea= lly have no idea how you came to this conclusion .

[Bruno]= I agree that since the above algo used 2 mapping entries to provides the (= SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted. That b= eing said, this is not important for this discussion. Let’s just considered that their exist a preference algo= rithm, which takes as input a list of (SIDi, Piij) for P1, and gives as out= pout the “best” one. (definition of “best” is not p= ertinent)

&n= bsp;

&n= bsp;

??=

&n= bsp;

As rega= rds “per FEC/Prefix”, I believe this is what “ignore over= lap only” does.

[Bruno]= Indeed, this is my expectation. But I would need someone’s review to= confirm this.

But the= difference is that the proposed algo is simple (2 lines of pseudo code), w= ith very modest resquirement data structure use to store the mapping entrie= s. Indeed, all it needs is a function returning the list of mapping entries associated/matching a given prefix. = And function returning the list of mapping entries associated/matching a gi= ven SID.

In part= icular, there is no need for splitting mapping entries which is the main co= mplexity of your proposed “Preference algorithm/ignore overlap only&#= 8221;. (according to your own text).

&n= bsp;

-- Brun= o

&n= bsp;

&n= bsp;

 &= nbsp;  Les

&n= bsp;

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks = for the updated draft.

&n= bsp;

IINM, y= ou have not answered my below email/proposal. I had waited for the new vers= ion of the draft but it also does not touch this subject.=

&n= bsp;

So, cou= ld you please consider and answer my comment?

&n= bsp;

In shor= t, in an implementation-independent sentence:

&n= bsp;

> I'm wondering if we could = address the conflict on a per FEC/Prefix basis rather than on a per IGP adv= ertisement (range) basis.

> If so, this may avoid the = discussion between the Quarantine vs ignore policy.

&n= bsp;

&n= bsp;

Thanks<= o:p>

Bruno

&n= bsp;

&n= bsp;

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]<= /o:p>

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

I am ha= ving difficulty parsing the examples you provide below as they seem to inco= rporate advertisement source into the description whereas the draft deliber= ately omits source.

[Bruno] My text does not incorp= orate the source, but the type of source IOW the type of sub-TLV.

&n= bsp;

So it d= oes not matter if R2 sends an advertisement or R12 sends advertisement or b= oth of them do (which could happen when an advertisement is leaked) –= what matters is what unique entries are in the database independent of source.

[Bruno] It may not matter for y= our algorithm (pending another thread), but it does for the one I proposed.=

&n= bsp;

It woul= d be good if you could present your examples using the format defined in th= e draft i.e.:

[Bruno] My examples are describ= ed in plain text. Then the examples giving intermediate steps of my algo us= es the data that are needed i.e. the type of advertisement (Prefix-SID vs M= S).

Then finally, my algo runs on a= per FEC/IP Prefix basis, and not on a per IGP advertisement basis which yo= ur format describe.

So I’m sorry but I don= 217;t see how to indulge your request.

&n= bsp;

    Pi - Initial prefix<= /span>

     Pe - End prefix

     L -  Prefix length

     Lx - Maximum prefix lengt= h (32 for IPv4, 128 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm<= /span>

 

     A Mapping Entry is then t= he tuple: (Pi/L, Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L= ))

     Se =3D Si + (R-1)<= /i>

 

Example:     (192.0.2.120/32, = 200, 1, 0, 0)

&n= bsp;

As rega= rds your proposal

&n= bsp;

- Find all SIDi advertised for the prefix P1 =             &nb= sp;            =             &nb= sp;            =         // identification of Prefix conf= licts

        &n= bsp;       - For each SIDi find all the prefi= x Pij associated with SIDi         =      // identification of SID conflicts=

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

        &n= bsp;       then use SIDij for P1

        &n= bsp;       else return no SID      = ;            &n= bsp;      

&n= bsp;

this to= me specifies an implementation – which isn’t necessary.

[Bruno] Well, _you_ are = the one talking about implementation, and more specifically implementation = complexity.

Assuming the above algo works, = it looks relatively simple to implement, in which case, I would not buy the= argument about implementation complexity which is the only argument in fav= or or the “ignore” or “quarantine” policy.

Bottom line, I would welcome yo= ur feedback and comments on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

&n= bsp;

&n= bsp;

However= , there is one important point which has not been specified in the draft wh= ich reading your post has brought to my attention – that is the order= in which checks are made.

The dra= ft states:

&n= bsp;

“= Prefix conflicts are specific to mapping entries sharing  the same top= ology and algorithm.”

“= SID conflicts are independent of address-family,  independent of prefi= x len, independent of topology, and independent  of algorithm.”<= o:p>

&n= bsp;

If we c= onsider an example where a network supports two VPNs, the significance of o= rdering in the evaluation of conflicts will be highlighted:

&n= bsp;

VPN1:

(192.0.= 2.1/32, 100, 1, 1, 0)

(192.0.= 2.1/32, 200, 1, 1, 0)

&n= bsp;

&n= bsp;

VPN2:

&n= bsp;

(192.0.= 2.100/32, 200, 1, 2, 0)

&n= bsp;

If we e= valuate prefix conflicts first, then the following entries are “activ= e”:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

(192.0.= 2.100/32, 200, 1, 2, 0) !VPN2

&n= bsp;

If we e= valuate SID conflicts first, then the following entries are “active&#= 8221;:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

&n= bsp;

The lat= ter choice is suboptimal because it prevents use of the VPN2 entry unnecess= arily.

&n= bsp;

This po= int needs to be made explicit in the draft.

&n= bsp;

 &= nbsp;  Les

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, p= lease find below some feedback on the policy.

 

I'm wondering if we could addre= ss the conflict on a per FEC/Prefix basis rather than on a per IGP advertis= ement basis.

If so, this may avoid the discu= ssion between the Quarantine vs ignore policy.

 

The problem that we need to sol= ve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for = the prefix P1          &n= bsp;            = ;            &n= bsp;            = ;           // identifica= tion of Prefix conflicts

     &= nbsp;          - For each SIDi= find all the prefix Pij associated with SIDi     =          // identification of SID c= onflicts

 

// as a result, we get a list o= f SIDi – Pij for P1

 

Get the best as per the prefere= nce algorithm.

If best Pij =3D=3D P1

     &= nbsp;          then use SIDij = for P1

     &= nbsp;          else return no = SID            =             &nb= sp; / no SID available for this prefix P1

 

     &= nbsp;         

   Note that it would= probably be better for the preference algo to put the SID tie-brake before= the prefix tie-break as with the prefix tie-break, we suffer from the conf= lict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding = a valid entry.   But for the below examples, I used the preferenc= e algo from draft-ietf-*-00

     &= nbsp;         

 

Below are examples, running thi= s policy on typical configuration error cases.   

Examples

3.4.4.  Network operation<= o:p>

 

   Consider the follo= wing simple network example:

 

   1.  100 nodes= : R1 to R100;

 

   2.  IP Loopba= cks are from 192.0.2.1 to 192.0.2.100:

 

   3.  SID are f= rom 1 to 100;

 

   4.  R1 to R50= are SR capable and advertised their own SID using

     &= nbsp; Prefix-SID sub-TLV;

 

   5.  R51 to R1= 00 are SR non-capable, running LDP and their SID are

      =  advertised by two redundant Mapping Server MS1 and MS2;

 

   6.  As the nu= mber of nodes which are SR capable are expected to

     &= nbsp; increase and as in real deployment their Loopback addresses would

     &= nbsp; no the contiguous, the Mapping servers advertisement covers all<= /o:p>

     &= nbsp; Loopbacks: (192.0.2.1/32, 1, 100);

 

   Subsequent section= s evaluate the consequences of a single

   configuration erro= r, for all conflict resolution options.

 

3.4.4.1.  Example 1: SID c= onfigured on 1 node conflict with SID

     &= nbsp;    configured on another node

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   12.  That SID= conflicts with the Prefix-SID advertised by R12 and the Mapping Server Adv= ertisement for R12.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R12, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS= , MS)

   R2 - SID12 - R12 (= prefix SID, MS)

   R2 - SID12 - = R2  (prefix SID, prefix SID)

   =

   

   Best one is R= 2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID12 i= s selected for R2.

   =

   For R12, the = algo evaluates a conflict between the following advertisments:

   R12 - SID12 - R12 = (prefix SID, prefix SID)

   R12 - SID12 - R2&n= bsp; (prefix SID, prefix SID)

   R12 - SID12 - R12 = (prefix SID, MS)

   R12 - SID12 - R2&n= bsp; (MS, prefix SID)

   R12 - SID12 - R12 = (MS, MS)

   =

   Best one is R= 12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), sma= ller starting adresse (R2))

   R12 <> = R2 =3D=3D> R12 has no SID.

   =

   3.4.4.2. = ; Example 2: SID configured on 1 node conflict with SID

     &= nbsp;    configured on the Mapping Server<= /p>

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   52.  That SID= conflicts with the Mapping Server advertisements of MS1<= /p>

   and MS2 for the lo= opback of R52.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R52, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID52 - R2&nb= sp; (prefix SID, prefix SID)

   R2 - SID52 - R52 (= prefix SID, MS)

   R2 - SID2  - = R2  (MS, MS)

   =

   Best one is R= 2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID52 i= s selected for R2.

   =

   For R52, the = algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 = (MS, MS)

   R52 - SID52 - R2&n= bsp; (MS, prefix SID)

   =

   Best one is R= 52 - SID52 - R2 (smaller range (prefix SID))

   R52 <> R2 = =3D=3D> R52 has no SID.

   =

   

3.4.4.3.  Example 3: wrong= configuration of a MS

 

   Following a typo d= uring configuration, MS1 is configured

   (192.0.2.0/32, 1, = 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That

   advertisement conf= licts with the Mapping Server advertisements of MS2

   and the Prefix-SID= advertised by R1...R50.

   =

   We have a con= flict for all routers except R100.

   =

   For LDP only = routers R51 to R99 we have a conflict between both MS advertisement.

   For R52, the algo = evaluates a conflict between the following advertisments:=

   R52 - SID52 - R52 = (MS2, MS2)

   R52 - SID52 - R51 = (MS2, MS1)

   R52 - SID53 - R52 = (MS1, MS1)

   R52 - SID53 - R53 = (MS1, MS2)

 

   Best one is R52 - = SID52 - R51 (smaller starting address)

   R52 <> R51 = =3D=3D> R52 has no SID.

   =

   For SR router= s, R1 to 50, we have a conflict between both MS advertisement and Prefix SI= D advertisements.

   For R2, the algo e= valuates a conflict between the following advertisments:<= /p>

   R2 - SID 2 - R2 (P= refix SID, Prefix SID)

   R2 - SID 2 - R2 (P= refix SID, MS2)

   R2 - SID 2 - R1 (P= refix SID, MS1)

   R2 - SID 2 - R2 (M= S2, MS2)

   R2 - SID 2 - R2 (M= S2, Prefix SID)

   R2 - SID 2 - R1 (M= S2, MS1)

   R2 - SID 3 - R2&nb= sp; (MS1, MS1)

   R2 - SID 3 - R3&nb= sp; (MS1, MS2)

   R2 - SID 3 - R3&nb= sp; (MS1, Prefix SID)

   =

   Best one is R= 2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 =3D=3D R2 hence= R2 use SID2.

 

Regards,

Bruno

 

_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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 author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F92A129OPEXCLILM21corp_-- From nobody Mon Jul 4 05:07:19 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFD1127058 for ; Mon, 4 Jul 2016 05:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q03EWdXd-7q for ; Mon, 4 Jul 2016 05:07:11 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6824A12D0B3 for ; Mon, 4 Jul 2016 05:07:11 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 04ACDC03E7; Mon, 4 Jul 2016 14:07:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id C1B95400D3; Mon, 4 Jul 2016 14:07:09 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0294.000; Mon, 4 Jul 2016 14:07:09 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution-01 Thread-Index: AdHV6o0E/qlZMiJZSjCljyO2j8K1qg== Date: Mon, 4 Jul 2016 12:07:08 +0000 Message-ID: <19159_1467634029_577A516D_19159_16159_10_53C29892C857584299CBF5D05346208A0F92A139@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: [spring] draft-ietf-spring-conflict-resolution-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 12:07:13 -0000 Hi Les, When talking about SID conflicts I think the document should spell out what= it means by SID. Indeed, the architecture document defines SID as: "SID: a Segment Identifier. Examples of SIDs are: a MPLS label, an index value in a MPLS label space, an IPv6 address. Other types of SIDs can be defined in the future." https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08#section-2 Indeed, when talking about SID conflicts - it matters that we do not compare apple and orange i.e. MPLS labels and = index in SRGB. - we can't compare index from different protocols (e.g. OSPF & IS-IS) unles= s they advertise the same SRGB (which is only a specific case). So either the document considers that a SID is an "index" and in this case,= we just can't compare them across protocols. Or it consider that a SID is a "MPLS labels" and in this case, as the IGP a= dvertisement typically advertise index for global SIDs, there is a need to = maps the received SID advertisement into the SRGB of the local node. This needs to be crystal clear. Thanks -- Bruno ___________________________________________________________________________= ______________________________________________ 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. From nobody Mon Jul 4 05:07:22 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5712D0CA for ; Mon, 4 Jul 2016 05:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg4-6OuhZlpj for ; Mon, 4 Jul 2016 05:07:10 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B3612D0AD for ; Mon, 4 Jul 2016 05:07:09 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 1DA3FA024A; Mon, 4 Jul 2016 14:07:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id CFB7D1A00F4; Mon, 4 Jul 2016 14:07:07 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0294.000; Mon, 4 Jul 2016 14:07:07 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACPs+VAAIaJeEACo/YOg Date: Mon, 4 Jul 2016 12:07:07 +0000 Message-ID: <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> In-Reply-To: <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F92A131OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 12:07:14 -0000 --_000_53C29892C857584299CBF5D05346208A0F92A131OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, Please see inline [Bruno3] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 3:36 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:19 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) [Bruno] IOW, the draft does not resolve SID conflict if all routers do not = receive exactly the same set of advertisement from all routing protocols. That's indeed can be a valid simplification if the WG choose to, but this s= hould clearly be indicated in the document, in a section targeting network = operator since this point will need to be read and enforced by network oper= ator rather than protocol implementors. =A73.2.8 already partly address thi= s, but IMO a text clearly expressing the requirements on network operator w= ould be useful. [Les2:] No policy can guarantee consistent results network wide if the data= bases on different nodes are inconsistent. This isn't a "simplification" - = it is a fact. As you point out, Section 3.2.8 already states: "In order to obtain consistent active entries all nodes in a network MUST have the same mapping entry database." If you believe this is not explicit enough please suggest some text. [Bruno3] Section 4 Manageability Considerations Detecting and resolving conflicts in a consistent way requires that all nod= es consider the same set of SIDs advertisements. Network operations should = be aware that the conflict resolution algorithm defined in this document wi= ll not succeed in selecting a consistent resolution across all nodes, if al= l nodes do not receive the exact same set of SIDs advertisements. This may = be in particular the case when multiple IGP instances are used and all rout= ers do not participate in the same set of IGP instances. This may occurs fo= r example if one network transition from one IGP protocol to another IGP (e= .g. from OSPFv2 to IS-IS). This may also happen if IGP areas/level are used= and SIDs are not flooded in all areas/levels. One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. [Bruno] IOW, don't make configuration errors ;-) Are you implying that the SRMS configuration (hence yang model) should be p= er node rather than per protocol? or at least should be configurable by nod= e (and possibly also by protocols) [Les2:] My point is (humorous ideas aside...) that if a deployment uses mul= tiple protocols, the easiest way to guarantee that the SID mapping database= on all nodes in the network is consistent is to restrict SID advertisement= s to SRMS advertisements. [Bruno3] Clearly, the fewer the number of advertisements for a given prefix= , the less change of conflict. But I fail to see why only using SRMS guarantee anything. e.g. if different= nodes use a different set of routing protocols, you have conflicts. Idem i= f the misconfiguration consist in adding a SID to a IGP prefix (PFX adverti= sement) A small number of nodes (as few as 1 - more if redundancy is desired) are s= etup as mapping servers and all SIDs which are required network-wide are co= nfigured on these nodes and advertised by the protocol instance(s) on that = node. In this way it is not necessary to guarantee that all prefix reachabi= lity from all of the protocol instances running in the network are present = in all the protocol instance sub-domains which exist - it is only necessary= to insure that all protocol instances advertise the same set of SRMS entri= es. [Bruno3] In the end, this gets back to requiring no configuration mistakes. It isn't the only way to support this - but it is likely to be the simplest= and least error prone. In any case this isn't a requirement - it was a res= ponse to your question as to how it might be possible to get consistent SID= mapping databases on all nodes in such a case. This is no way changes how = the YANG model is defined. SRMS config is always node specific. If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. [Bruno]There is also the point of configuring different SRGB space in diffe= rent IGP protocols. In which case, SIDs may conflict but this is not an iss= ue as label will not conflict. We stopped short of that in this revision because we felt there were enough= substantive changes and points on which consensus is still a work in progr= ess that it would not be the optimal way forward. [Bruno] +1 and thanks. Releasing an updated version has been useful to re-i= nitiate the discussion. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. [Bruno] Well, the some prefix/routing consistency is also required for IP p= refixes. When then same IP prefix is advertised in different IGPs, admin di= stance is a common existing way to define which routing protocol takes prec= edence. I'm not sure why it should not also be taken into consideration for= SR Prefix conflits [Les2:] Please see my response to Stephane on the same point. I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. [Bruno] Question was that, at a very/too high level, the issue of conflict = across topology seems close to the issue of conflict across routing protoco= ls: we have different topologies. Hence a na=EFve question: how exactly is= this different. One part of the answer, is the simplification proposed when multiple protoc= ols is used (i.e. your first answer above). Another part is that for multi-topology, compared to multi-protocols, all i= nformation from all topologies are flooded to all nodes. Another part is the forwarding model used for Multi-Topology. In general, h= ttps://tools.ietf.org/html/rfc5120#section-8 seems to assume that each topo= logy has one dedicated RIB/FIB. In such condition, there is no conflict (pr= efix or SID) so no need to detect and resolve conflict. So here there may b= e different models and eventually, we don't 'have the same one in mind. In a lesser extend, even for multi-protocols, we may have those multiple fo= rwarding models. To some extent, this seems related to the definition of "S= R domain". e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be thi= s is something that needs to be configurable [Les2:] Please reread Section 3.1.2. While there are no "Prefix-conflicts" = across topologies, there are "SID Conflicts". This is important to understa= nd. [Bruno3] Conflicts are related to a forwarding context i.e. FIB. This is eq= ually important to understand. Please read https://tools.ietf.org/html/rfc5= 120#section-8.2.2 and 8.2.1 to see that topologies may not share the same f= orwarding context hence do not conflict in term of prefix & SID. --Bruno As regards multiple protocols operating in the same topology, from a forwar= ding perspective we do not care what protocol is the winning route. What we= care about is that our nexthop has chosen the same SID for a given prefix.= This is why "source" is deliberately excluded from consideration by the co= nflict resolution algorithm. Les Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F92A131OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,=

 

Please see inline [Bru= no3]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:36 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno &= #8211;

&n= bsp;

Inline.=

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 

Thanks = for the discussion. Please see inline [Bruno]

&n= bsp;

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno &= #8211;

&n= bsp;

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 

IINM, I= ’ve not seen the follow up on one of my below questions.

So let = me restate a comment:

&n= bsp;

The SR-= MPLS SID conflicts algo requires that all nodes consider the same mapping a= dvertisements.

How is = this ensured, if it indifferently considers advertisements from all protoco= ls, while some nodes could participate only in a subset of the protocols? e= .g. OSPF only routers would consider a different set of information compared to OSPF+IS-IS routers.

&n= bsp;

[= Les:] If you run multiple protocol instances (whether multiple instances of= the same protocol or instances of different protocols) then you need to in= sure that at least one of the two conditions below is true:

=B7       = ;  All routers receive the equivalent set of advertisements=

=B7       = ;  There are no conflicts J=

&n= bsp;

[Bruno]= IOW, the draft does not resolve SID conflict if all routers do not receive= exactly the same set of advertisement from all routing protocols.

That= 217;s indeed can be a valid simplification if the WG choose to, but this sh= ould clearly be indicated in the document, in a section targeting network o= perator since this point will need to be read and enforced by network operator rather than protocol implementors. =A73.2= .8 already partly address this, but IMO a text clearly expressing the requi= rements on network operator would be useful.

&n= bsp;

[= Les2:] No policy can guarantee consistent results network wide if the datab= ases on different nodes are inconsistent. This isn’t a “simplif= ication” – it is a fact. As you point out, Section 3.2.8 already states:

<= o:p> 

“In order to obtain consistent active en= tries all nodes in a network

&= nbsp;  MUST have the same mapping entry database.”

<= o:p> 

If y= ou believe this is not explicit enough please suggest some text.=

[Bruno3]

Section= 4 Manageability Considerations

Detecti= ng and resolving conflicts in a consistent way requires that all nodes cons= ider the same set of SIDs advertisements. Network operations should be awar= e that the conflict resolution algorithm defined in this document will not succeed in selecting a consistent resolu= tion across all nodes, if all nodes do not receive the exact same set of SI= Ds advertisements. This may be in particular the case when multiple IGP ins= tances are used and all routers do not participate in the same set of IGP instances. This may occurs for e= xample if one network transition from one IGP protocol to another IGP (e.g.= from OSPFv2 to IS-IS). This may also happen if IGP areas/level are used an= d SIDs are not flooded in all areas/levels.

&n= bsp;

&n= bsp;

One = way of insuring the first point is to exclusively use a mapping server to a= dvertise SIDs, configure your SRMS entries in a protocol independent manner= , and insure that the SRMS advertisements are sent in all of the protocol instance specific sub-domains.<= /span>

[Bruno]= IOW, don’t make configuration errors ;-)

Are you= implying that the SRMS configuration (hence yang model) should be per node= rather than per protocol? or at least should be configurable by node (and = possibly also by protocols)

 

[= Les2:] My point is (humorous ideas aside…) that if a deployment uses = multiple protocols, the easiest way to guarantee that the SID mapping datab= ase on all nodes in the network is consistent is to restrict SID advertisements to SRMS advertisements.=

[Bruno3= ] Clearly, the fewer the number of advertisements for a given prefix, the l= ess change of conflict.

But I f= ail to see why only using SRMS guarantee anything. e.g. if different nodes = use a different set of routing protocols, you have conflicts. Idem if the m= isconfiguration consist in adding a SID to a IGP prefix (PFX advertisement)

&n= bsp;

<= o:p> 

A= small number of nodes (as few as 1 – more if redundancy is desired) = are setup as mapping servers and all SIDs which are required network-wide a= re configured on these nodes and advertised by the protocol instance(s) on that node. In this way it is not necessary = to guarantee that all prefix reachability from all of the protocol instance= s running in the network are present in all the protocol instance sub-domai= ns which exist – it is only necessary to insure that all protocol instances advertise the same set of SRMS entri= es.<= /o:p>

[Bruno3= ] In the end, this gets back to requiring no configuration mistakes.<= o:p>

I= t isn’t the only way to support this – but it is likely to be t= he simplest and least error prone. In any case this isn’t a requireme= nt – it was a response to your question as to how it might be possible to get consistent SID mapping databases on all nodes in such a= case. This is no way changes how the YANG model is defined. SRMS config is= always node specific.

<= o:p> 

 

If t= he intent is to deliberately use different labels in the forwarding plane f= or the same destination depending upon which protocol advertised the prefix= , this introduces a number of new requirements – not the least of which is duplicate entries for the same prefix in= the forwarding plane.  As has been discussed publicly in a different = thread, there are cases (e.g. merging two networks) were such a requirement= may exist – but it is the exception rather than the rule and as it consumes more resources in the forwarding plane an= d introduces implementation complexity independent of conflict resolution i= t is not the primary case the draft focuses on. Nevertheless, this is a cas= e which the draft will address in the next revision.

[Bruno]= There is also the point of configuring different SRGB space in different IG= P protocols. In which case, SIDs may conflict but this is not an issue as l= abel will not conflict.

We s= topped short of that in this revision because we felt there were enough sub= stantive changes and points on which consensus is still a work in progress = that it would not be the optimal way forward.

[Bruno]= +1 and thanks. Releasing an updated version has been useful to re-init= iate the discussion.=

&n= bsp;

Thinkin= g more about this, I guess that this is only important for the entries whic= h are inserted in the forwarding plane. Hence, in case of conflict between = protocols, I think that the preference algorithm should take into account the protocol preference (aka administra= tive distance).

&n= bsp;

[= Les:] As admin distance is neither an attribute of SRMS entries nor guarant= eed to be consistent on all routers for all prefixes this is not a desirabl= e approach.

[Bruno]= Well, the some prefix/routing consistency is also required for IP prefixes= . When then same IP prefix is advertised in different IGPs, admin distance = is a common existing way to define which routing protocol takes precedence. I’m not sure why it should not al= so be taken into consideration for SR Prefix conflits

&n= bsp;

[= Les2:] Please see my response to Stephane on the same point.

&n= bsp;

I’= ;m also not sure to see why is the problem different compared to Multi-Topo= logy. Could you please elaborate?

[= Les:] I am unclear what your question is. Are you asking why we need differ= ent SIDs in different topologies? Please clarify.=

[Bruno]= Question was that, at a very/too high level, the issue of conflict across = topology seems close to the issue of conflict across routing protocols: &nb= sp;we have different topologies. Hence a na=EFve question: how exactly is this different.

One par= t of the answer, is the simplification proposed when multiple protocols is = used (i.e. your first answer above).

Another= part is that for multi-topology, compared to multi-protocols, all informat= ion from all topologies are flooded to all nodes.

Another= part is the forwarding model used for Multi-Topology. In general, https://tools.iet= f.org/html/rfc5120#section-8 seems to assume that ea= ch topology has one dedicated RIB/FIB. In such condition, there is no confl= ict (prefix or SID) so no need to detect and resolve conflict. So here ther= e may be different models and eventually, we don’t ‘have the same one in mind.

In a le= sser extend, even for multi-protocols, we may have those multiple forwardin= g models. To some extent, this seems related to the definition of “SR= domain”. e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be this is something that needs to be configurable<= o:p>

&n= bsp;

<= o:p> 

[= Les2:] Please reread Section 3.1.2. While there are no “Prefix-confli= cts” across topologies, there are “SID Conflicts”. This i= s important to understand.

[Bruno3= ] Conflicts are related to a forwarding context i.e. FIB. This is equally i= mportant to understand. Please read https://tools.ietf.org/html/rfc5120#= section-8.2.2 and 8.2.1 to see that t= opologies may not share the same forwarding context hence do not conflict i= n term of prefix & SID.

--Bruno=

<= o:p> 

A= s regards multiple protocols operating in the same topology, from a forward= ing perspective we do not care what protocol is the winning route. What we = care about is that our nexthop has chosen the same SID for a given prefix. This is why “source” is delib= erately excluded from consideration by the conflict resolution algorithm.

<= o:p> 

&= nbsp;   Les

<= o:p> 

&= nbsp;   Les

&n= bsp;

&n= bsp;

Thanks,=

Bruno

&n= bsp;

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,

&n= bsp;

Thanks = for your reply.

Please = see inline [Bruno]

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno &= #8211;

&n= bsp;

Inline.=

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, p= lease find below some comments:

 

--

Isn’t this document speci= fic to the MPLS dataplane?

If so, it could be indicated in= the introduction, and possibly in the abstract. Then this indication could= be removed from the 1rst sentence of sections 2 & 3.=

&n= bsp;

[= Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open = the possibility that if there is some SRv6 conflict resolution that needs t= o be specified it could be added into this document – which is why the Introduction is dataplane agnostic,= but each section states specifically that it is relevant to SR-MPLS.<= /o:p>

<= o:p> 

I= am not aware of any SRv6 conflict resolution that is required at this poin= t, but I prefer to leave the possibility open if that is OK with you.<= /o:p>

[Bruno]= ok, great.

--

=A73

“Mapping entries have an explicit con= text which includes the topology and the SR algorithm.“

A priori you could add “the routing p= rotocol”.

 

[= Les:] No – the source of advertisements is deliberately left out. It = matters not whether the source of the advertisement is a protocol or an SRM= S – nor does it matter which protocol provides the advertisement. You see that “admin distance” is not mentio= ned at all and that is quite deliberate. This insures that consistent choic= es are made on nodes regardless of which protocol might have the best route= on a given node.

[Bruno]= Well, the fact is that mapping entries do have, as explicit context, the r= outing protocol used to advertise them. After, you can should to use that i= nformation, or not.

--

=A73

“When conflicts occur, it is not
   possible for routers to know which of the confli=
cting advertisements
   is "correct".  If a router choose=
s to use one of the conflicting
   entries forwarding loops and/or blackholes may r=
esult unless it can
   be guaranteed that all other routers in the netw=
ork make the same
   choice.  Making the same choice requires th=
at all routers have
   identical sets of advertisements and that they a=
ll use the same
   selection algorithm. =BB<=
/pre>

 


I think we agree on the technical part, but I found the formu=
lation slightly biased. I would propose


“When conflicts occur, it is not


   possible for routers to know which of the confli=
cting advertisements


   is "correct".  In order to avoid =
forwarding loops and/or blackholes, there is a need for all nodes to make t=
he same choice.


  Making the same choice requires that all routers have<=
o:p>


   identical sets of advertisements and that they a=
ll use the same


   selection algorithm. This is the purpose of this=
 document. =BB


--


[=
Les:] I am fine with this change.


[Bruno]=
 Thanks


&n=
bsp;


=A73.1


“Various types of conflicts may occur”=



What about :s/Various/Two


&n=
bsp;


[=
Les:] “Two” is fine. Just means we will have to change it if we=
 come up with a third type of conflict.
J


[Bruno]=
 Indeed, but in this case the change may be much larger (e.g. the whole alg=
o)


--


I agree with Robert’s &nb=
sp;and Uma’s comment with regards to making this conflict resolution =
an inter- protocol/routing_table issue. In particular, between SR domains, =
there is not requirement to have unique SIDs. Hence between
 PE and CE, between ASes (both within and across organization), the same SI=
D could be reused independently).



&n=
bsp;


[=
Les:] There is more to be said on this topic – co-authors are activel=
y discussing this point and we’ll respond more fully to Robert’=
s post in time. But, the draft is NOT trying to define conflict
 resolution across “SR domains”. Perhaps we need language to ma=
ke that more explicit.


[Bruno]=
 ok. Regarding inter-protocol, in order to have consistency of the prefix-S=
ID mapping across the domain we need:


a) all nodes use the same algo



b) all nodes using this algo have the same data<=
/o:p>


 


“a” requires this draft=



“b” requires that all nodes have the same=
 set of SR  info. This forbid that some node are considering IS-IS =
3; OSPF SR data, while some node are only considering IS-IS data.
 Otherwise, all IS-IS routers would not take the same decision. So, unless =
we can guarantee that the flooding area is the same for IS-IS and OSPF, we =
can't have the algo using the SR data from multiple routing protocols. I do=
n't think that we can guarantee
 this (nor that implementation will check this) e.g. when some nodes are pa=
rt of multiple routing domain or when gradually transitioning from one IGP =
to another.


 


So in s=
hort, this SR-conflict algo should probably be restricted to SR information=
 from a single protocol


&n=
bsp;


> From: Le=
s Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
 > Sent: Sunday, May 01, 2016 7:11 AM


>&nbs=
p;


>
We are indeed defining co=
nflict resolution across all the SID advertisements regardless of source (p=
rotocol or SRMS)


> Why?=
 Because we need consistent use of SIDs in the forwarding plane<=
/span>


 


No: in the forwarding plane, we=
 need a consistent use of MPLS label.


[=
Les:] As you know, SRGB range can be different for different nodes, so the =
actual label that is used to send a packet for a given destination via Node=
 A may be different than the label used
 to send the same packet via Node B. It is the SID that needs to be the sam=
e – not the label.



I=
t is true that SIDs are not installed in the forwarding plane – the l=
abels derived from the SID/SRGB are what is actually installed in the forwa=
rding plane – but I think my use of the word
 SID in this context is correct.


[Bruno]=
 My point was that the formulation assumes that a single SRGB is used per n=
odes. In which case, we have a bijection between SID and labels. But if we =
have a SRGB per protocol, we don’t have
 a bijection any more and we can have the same SID in IS-IS and OSPF (inclu=
ding for different prefix), which will be mapped to different labels in the=
 forwarding plane.


&n=
bsp;


Plus only within an SR domain. =
Actually, even within a domain, this is dependent on whether SRGB is config=
ured on a per node or a per protocol basis. I’m not sure how much the=
 agreement has been reached on that one.


&n=
bsp;


[=
Les:] The draft currently addresses deployments where a single (set of) SRG=
B ranges applies to the box. This is by far the most common use case. There=
 is a much more limited use case where
 protocol specific SRGBs and protocol specific SIDs may be required. The dr=
aft will address that in a future revision


[Bruno]=
 ok, may be this should be stated in the draft, as otherwise you’ll k=
eep getting comments, or we may forget this point.


Thanks<=
o:p>


--Bruno=



&=
#8211; but in spirit the same rules will apply – they will just have =
to take into account “duplicate forwarding domains”. Note that =
this will also require multiple incoming label entries/prefix
 be supported by the routers in such a network.

&n=
bsp;


--


Typo:


=A72


OLD : Range 3: (500, 5990


NEW : Range 3: (500, 599)


 


(somewhat significant as otherwise range 3 conflict with ra=
nge 2)


&n=
bsp;


[=
Les:] Agreed – thanx for spotting this.


<=
o:p> 


&=
nbsp;  Les<=
/b>


 


Thanks,


Regards,


Bruno


_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


T=
hank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F92A131OPEXCLILM21corp_-- From nobody Mon Jul 4 05:30:54 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F307612B018; Mon, 4 Jul 2016 05:30:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160704123049.2602.94374.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2016 05:30:49 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 12:30:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing Architecture Authors : Clarence Filsfils Stefano Previdi Bruno Decraene Stephane Litkowski Rob Shakir Filename : draft-ietf-spring-segment-routing-09.txt Pages : 29 Date : 2016-07-04 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. Segment Routing can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address of the packet. The next active segment is indicated by a pointer in the new routing header. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 4 05:33:27 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B37E12D0E7 for ; Mon, 4 Jul 2016 05:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szyAAwiCzGxx for ; Mon, 4 Jul 2016 05:33:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A7A12B018 for ; Mon, 4 Jul 2016 05:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2367; q=dns/txt; s=iport; t=1467635604; x=1468845204; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Hy5DmWWyfVx3sIhPonhx/Er1m0peeMieTnV8bEPVBrM=; b=LE24401FJudsXhJci9O8zxtRzzNa9FBhjegRjVC2mgAioaaGkZqGnBbV NkSYargB5PIVa4fuqZ7mRgMf6UIHSb/37Io3Y+uidCKS56h72AHgz6g0a AvL3NVBs3LQNLwogbV41HPPqmjcxkxvjKqf0pByM3iIros4qmPCAL7gk4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AgCkVnpX/5xdJa1cgz5WfAa5L4F5J?= =?us-ascii?q?IV0AoE1OBQBAQEBAQEBZSeETAEBBAE6PQcLAgEIEgYeEDIXDgIEE4goCA66AwE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARyGKIF4glWEQIMsgi8FjgSLDwGGCIg+gWpOh?= =?us-ascii?q?AiIapAJAR42g3BuAYgMfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,574,1459814400"; d="scan'208";a="120204504" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2016 12:33:23 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u64CXN1A024346 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Jul 2016 12:33:23 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 4 Jul 2016 08:33:22 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 4 Jul 2016 08:33:22 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: New Version Notification for draft-ietf-spring-segment-routing-09.txt Thread-Index: AQHR1e/o0scFX2wcYUauCc+piLVe/aAId6wA Date: Mon, 4 Jul 2016 12:33:22 +0000 Message-ID: References: <20160704123050.2602.54228.idtracker@ietfa.amsl.com> In-Reply-To: <20160704123050.2602.54228.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.220] Content-Type: text/plain; charset="us-ascii" Content-ID: <7A23DD25B754BE4BA5F6A285EC064B8C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] New Version Notification for draft-ietf-spring-segment-routing-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 12:33:26 -0000 Hi, Security and Manageability sections have been added.=20 Thanks. s. > On Jul 4, 2016, at 2:30 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-spring-segment-routing-09.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-ietf-spring-segment-routing > Revision: 09 > Title: Segment Routing Architecture > Document date: 2016-07-04 > Group: spring > Pages: 29 > URL: https://www.ietf.org/internet-drafts/draft-ietf-spring-se= gment-routing-09.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-spring-segmen= t-routing/ > Htmlized: https://tools.ietf.org/html/draft-ietf-spring-segment-rou= ting-09 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-seg= ment-routing-09 >=20 > Abstract: > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through an ordered list of instructions, called > segments. A segment can represent any instruction, topological or > service-based. A segment can have a local semantic to an SR node or > global within an SR domain. SR allows to enforce a flow through any > topological path and service chain while maintaining per-flow state > only at the ingress node to the SR domain. >=20 > Segment Routing can be directly applied to the MPLS architecture with > no change on the forwarding plane. A segment is encoded as an MPLS > label. An ordered list of segments is encoded as a stack of labels. > The segment to process is on the top of the stack. Upon completion > of a segment, the related label is popped from the stack. >=20 > Segment Routing can be applied to the IPv6 architecture, with a new > type of routing header. A segment is encoded as an IPv6 address. An > ordered list of segments is encoded as an ordered list of IPv6 > addresses in the routing header. The active segment is indicated by > the Destination Address of the packet. The next active segment is > indicated by a pointer in the new routing header. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon Jul 4 20:57:42 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE4A12D0B4 for ; Mon, 4 Jul 2016 20:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJOdlYJ2jncf for ; Mon, 4 Jul 2016 20:57:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D8E7612D0F5 for ; Mon, 4 Jul 2016 20:57:36 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 61083BBF815FE for ; Tue, 5 Jul 2016 11:57:32 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id DE7F94B2D6DFF; Tue, 5 Jul 2016 11:57:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u653uh7m013457; Tue, 5 Jul 2016 11:56:43 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: References: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> To: Robert Raszuk MIME-Version: 1.0 X-KeepSent: 6104EF3F:44613D28-48257FE7:000D2CBB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Tue, 5 Jul 2016 11:56:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-05 11:56:27, Serialize complete at 2016-07-05 11:56:27 Content-Type: multipart/alternative; boundary="=_alternative 0015AC0C48257FE7_=" X-MAIL: mse01.zte.com.cn u653uh7m013457 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , rraszuk@gmail.com Subject: [spring] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSRTogZHJhZnQtaWV0Zi1z?= =?gb2312?b?cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg==?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 03:57:41 -0000 This is a multipart message in MIME format. --=_alternative 0015AC0C48257FE7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIHRoaW5rIGl0IGlzIGJldHRlciB0byBhZGQgbW9yZSBkZXNjcmlwdGlv biB0byBzZWN0aW9uIDQgdG8gZWxpbWluYXRlIA0KY29uZnVzaW9uLiBOb3cgd2Ugb25seSBnZXQg YSAic3RhdGVtZW50IiB0aGF0IHRoZXJlIGlzIG5vIHByb2JsZW0sIGJ1dCBub3QgDQpob3cuIEZv ciBleGFtcGxlLCBpZiBzZXBhcmF0ZSAiY29udGV4dHMiIGluIGRhdGEgcGxhbmUgYXMgeW91IHNh aWQgaXMgYSANCnN1Z2dlc3Rpb24gbWV0aG9kIHRvIGZ1bGZpbGwgdGhpcyBjYXNlPyBOb3RlIHRo YXQgSUxNIGNvcnJlc3BvbmRpbmcgdG8gU1IgDQpsYWJlbCBoYXMgbm8gImNvbnRleHRzIiBpbiBk YXRhIHBsYW5lIGN1cnJlbnRseS4NCg0KTGV0J3MgZmlyc3QgY29uY2VybiBpc3N1ZXMgaW4gY29u dHJvbCBwbGFuZS4gDQpTdXBwb3NlZCB0aGF0IHRoZXJlIGFyZSBzaXRlIEEsQixDIGF0dGFjaGlu ZyB0byBwcm92aWRlciBuZXR3b3JrIHRocm91Z2ggDQpQRTEsUEUyLFBFMyByZXNwZWN0aXZlbHks IGFuZCBBLEIsQyBiZWxvbmcgdG8gc2FtZSB2cmYgbmV0d29yay4gU3VwcG9zZWQgDQp0aGF0IGRl c3RpbmF0aW9uIDEuMS4xLjEgaW4gc2l0ZSBBLCAyLjIuMi4yIGluIHNpdGUgQiwgMy4zLjMuMyBp biBzaXRlIEMgDQphc3NpZ24gdGhlIHNhbWUgcHJlZml4LXNpZC4NCkJlY2F1c2UgSSBoYXZlIG5v IGVudGlyZSBpZGVhIGFib3V0IHRoZSBzb2x1dGlvbiBiZWhpbmQgc2VjdGlvbiA0LCBJIGp1c3Qg DQpsaXN0IHRoZSBxdWVzdGlvbnMgYXMgZm9sbG93aW5nOg0KDQoxKSBQRTEncyBCR1Agd2lsbCBy ZWNlaXZlIFZQTnY0IHByZWZpeCgyLjIuMi4yKSBmcm9tIFBFMiB3aXRoIHByZWZpeC1zaWQgDQpz YW1lIGFzIFZQTnY0IHByZWZpeCgzLjMuMy4zKSBmcm9tIFBFMywgZG9lcyBpdCBkbyBjb25mbGlj dCBwcm9jZXNzIGluIA0KdGhpcyBwaGFzZT8NCjIpIFBFMSdzIEJHUCB3aWxsIGltcG9ydCBWUE52 NCByb3V0ZSB0byBsb2NhbCB2cmYsIHNvIGluIHRoZSBzYW1lIFZQTiANCnJvdXRpbmcgdGFibGUs IHByZWZpeCgyLjIuMi4yKSBhbmQgcHJlZml4KDMuMy4zLjMpIGhhdmUgdGhlIHNhbWUgDQpwcmVm aXgtc2lkLCBkb2VzIGl0IGRvIGNvbmZsaWN0IHByb2Nlc3MgaW4gdGhpcyBwaGFzZT8NCjMpIFBF MSdzIElHUCB3aWxsIHJlZGlzdHJpYnV0ZSBCR1Agcm91dGVzIGluIHRoZSB2cmYsIHNvIElHUCB3 aWxsIGFsc28gc2VlIA0KdHdvIHByZWZpeGVzIGhhdmUgdGhlIHNhbWUgcHJlZml4LXNpZCwgZG9l cyBpdCBkbyBjb25mbGljdCBwcm9jZXNzIGluIHRoaXMgDQpwaGFzZT8NCjQpIEVhY2ggcm91dGVy IGluIHNpdGUgQSB3aWxsIHJlY2VpdmUgcGVyZml4IGZsb29kLCBzbyBhdCBlYWNoIHJvdXRlciBp dHMgDQpJR1Agd2lsbCBhbHNvIHNlZSB0d28gcHJlZml4ZXMgaGF2ZSB0aGUgc2FtZSBwcmVmaXgt c2lkLCBkb2VzIGl0IGRvIA0KY29uZmxpY3QgcHJvY2VzcyBpbiB0aGlzIHBoYXNlPw0KDQoNClRo YW5rcw0KDQpEZWNjYW4NCg0KDQoNCg0KDQoNClJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsu bmV0PiANCreivP7IyzogIHJyYXN6dWtAZ21haWwuY29tDQoyMDE2LTA3LTA0IDE2OjAwDQoNCsrV vP7Iyw0KcGVuZy5zaGFvZnVAenRlLmNvbS5jbiwgDQqzrcvNDQoiTGVzIEdpbnNiZXJnIChnaW5z YmVyZykiIDxnaW5zYmVyZ0BjaXNjby5jb20+LCAic3ByaW5nQGlldGYub3JnIiANCjxzcHJpbmdA aWV0Zi5vcmc+DQrW98ziDQpSZTogW3NwcmluZ10gtPC4tDogUkU6IGRyYWZ0LWlldGYtc3ByaW5n LWNvbmZsaWN0LXJlc29sdXRpb24NCg0KDQoNCg0KDQoNCkhpIFBlbmcsDQoNCk9uIHRoZSBwb2lu dCAjMiB5b3UgYXJlIHJpZ2h0IHRoYXQgZXh0ZXJuYWxseSByZWNlaXZlZCBTSURzIHdpbGwgYmUg DQppbnN0YWxsZWQgaW4gdGhlIGRhdGEgcGxhbmUgb2YgUEVzLiANCg0KSG93ZXZlciB5b3UgbmVl ZCB0byBvYnNlcnZlIHRoYXQgdGhleSB3aWxsIGJlIGluc3RhbGxlZCBpbiBjb21wbGV0ZWx5IA0K c2VwYXJhdGUgImNvbnRleHRzIiBpbiBkYXRhIHBsYW5lIGhlbmNlIGN1cnJlbnQgYWRkaXRpb24g KGFmdGVyIEkgYnJvdWdodCANCnRoaXMgaXNzdWUgZmV3IHdlZWtzIGJhY2spIGhhcyBiZWVuIGFj Y3VyYXRlbHkgYWRkcmVzc2VkIGluIG5ldyBzZWN0aW9ucyANCjMuMi42IGFuZCA0LiANCg0KQWxs IHdoYXQgeW91IGFyZSBzYXlpbmcgaXMgdHJ1ZSBhbmQgdGhlICBjdXJyZW50IGRyYWZ0IGVuYWJs ZXMgb25lIHRvIGRvIA0KdGhhdCB5ZXQgdG8ga2VlcCBjb25zaXN0ZW50IGJhc2UgdG9wb2xvZ3kg aW4gdGhlIG5ldHdvcmsuIFdlbGwgbW9kdWxvIA0KY29tbWVudHMgZnJvbSBCcnVubyB3aGljaCBo YXZlIG5vdCBiZWVuIHlldCB3ZWxsIGFkZHJlc3NlZC4gDQoNCkNoZWVycywNClIuDQoNCg0KT24g TW9uLCBKdWwgNCwgMjAxNiBhdCA0OjMyIEFNLCA8cGVuZy5zaGFvZnVAenRlLmNvbS5jbj4gd3Jv dGU6DQpMZXMsIA0KDQpTZWUgaW5saW5lLiANCg0KDQoNCg0KDQoNCg0KIkxlcyBHaW5zYmVyZyAo Z2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29tPiANCjIwMTYtMDctMDIgMDE6MTMgDQoNCg0K ytW8/sjLDQoicGVuZy5zaGFvZnVAenRlLmNvbS5jbiIgPHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24+ LCANCrOty80NCiJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+IA0K1vfM4g0KUkU6 IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KDQoNCg0K DQoNCg0KDQpEZWNjYW4gLSANCiAgDQpGcm9tOiBwZW5nLnNoYW9mdUB6dGUuY29tLmNuIFttYWls dG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbl0gDQpTZW50OiBGcmlkYXksIEp1bHkgMDEsIDIwMTYg Mjo0NiBBTQ0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpDYzogc3ByaW5nQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1 dGlvbiANCiAgDQpIaXMgTGVzLCANCg0KMSkgRnJvbSBpbXBsZW1lbnRhdGlvbiwgYmVjYXVzZSBw cmVmZXJlbmNlIGFsZ29yaXRobSBpcyBwcm90b2NvbCANCmluZGVwZW5kZW50LCBpdCBpcyBiZXR0 ZXIgdG8gZG8gY29uZmxpY3QgcmVzb2x1dGlvbiBhdCBhIGNvbW1vbiBwbGFjZSwgbm90IA0KYXQg aW5kaXZpZHVhbCBwcm90b2NvbCBpbnN0YW5jZS4gRm9yIGV4YW1wbGUsIHdlIGNhbiBkbyBwcmVm aXgtY29uZmxpY3QgDQpyZXNvbHV0aW9uIHdoZW4gZ2VuZXJhdGUgdGhlIHByZWZlcmVuY2UgRklC IGVudHJ5IGF0IHRoZSBjb21tb24gcGxhY2UuIEZvciANCmEgcHJlZmVyZW5jZSBGSUIgZW50cnks IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIG1heSBnZXQgZnJvbSBPU1BGIGJ5IA0KYWRtaW5pc3Ry YXRpdmUgZGlzdGFuY2UsIGJ1dCB0aGUgU0lEIGluZm9ybWF0aW9uIG1heSBnZXQgZnJvbSBJU0lT IGJ5IA0KcHJlZml4LWNvbmZsaWN0IGFsZ29yaXRobS4gVGhlbiB3ZSBjYW4gZG8gc2lkLWNvbmZs aWN0IHJlc29sdXRpb24gd2hlbiANCmdlbmVyYXRlIHRoZSBTSUQtTElCIGVudHJ5IGFjY29yZGlu ZyB0byB0aGUgYWJvdmUgRklCIGVudHJ5IGFuZCBvdGhlciANCnNvdXJjZXMsIGl0IHdpbGwgc2Vs ZWN0IGEgcHJlZmVyZW5jZSBGRUMgdG8gcHJvdmlkZSBmb3J3YXJkaW5nIA0KaW5mb3JtYXRpb24u IA0KU28sIHByZWZlcmVuY2UgYWxnb3JpdGhtIHBlciBwcmVmaXgvZmVjIGlzIGVub3VnaC4gUGVy IHJhbmdlIGlzIHBvc3NpYmxlLCANCmJ1dCBpbXBsZW1lbnRhdGlvbiBpcyBjb21wbGV4LiBNb3Jl IGNvbXBsZXggaXMgZm9yICJpZ25vciBvdmVybGF5IiBwZXIgDQpyYW5nZS4gDQoNCltMZXM6XSBJ bXBsZW1lbnRhdGlvbi13aXNlLCB5b3UgYXJlIGZyZWUgdG8gaW1wbGVtZW50IHRoaXMgaW4gYW55 IG1vZHVsZSANCnlvdSBsaWtlIHNvIGxvbmcgYXMgd2l0aCB0aGUgc2FtZSBkYXRhYmFzZSB5b3Ug Y29tZSB1cCB3aXRoIHRoZSBzYW1lIA0KYW5zd2VyIGFzIG90aGVyIG5vZGVzIGluIHRoZSBuZXR3 b3JrLiANClRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIKGwUXVhcmFudGluZaGxIGFuZCChsElnbm9y ZSBPdmVybGFwobEgaXMgdGhhdCB0aGUgDQpsYXR0ZXIgYXR0ZW1wdHMgdG8gdXNlIHRob3NlIHBv cnRpb25zIG9mIGEgcmFuZ2Ugd2hpY2ggZG8gbm90IGhhdmUgDQpjb25mbGljdHMgd2l0aCBvdGhl ciBlbnRyaWVzLiBUaGUgY29zdCBvZiBkb2luZyBzbyBpcyBoYXZpbmcgdG8gY3JlYXRlIKGwDQpk ZXJpdmVkIGVudHJpZXOhsSB3aGljaCByZXByZXNlbnQgdGhvc2Ugc3ViLXJhbmdlcyB3aGljaCBk by9kbyBub3QgaGF2ZSANCmNvbmZsaWN0cy4gRHVlIHRvIHRoZSBhZGRlZCBjb21wbGV4aXR5IHRo aXMgaXMgTk9UIHRoZSBmaXJzdCBjaG9pY2Ugb2YgdGhlIA0KYXV0aG9ycy4gDQpJZiBJIHdlcmUg dG8gY2F0ZWdvcml6ZSB0aGUgdHdvIGFsZ29yaXRobXMgdXNpbmcgeW91ciB0ZXJtaW5vbG9neSCh sA0KUXVhcmFudGluZaGxIHdvdWxkIGJlIKGwcGVyIHJhbmdlobEgd2hpbGUgobBJZ25vcmUgT3Zl cmxhcKGxIHdvdWxkIGJlIKGwDQpwZXIgcHJlZml4L0ZFQ6GxLiBTbyBpdCBpcyB0aGUgbGF0dGVy IHdoaWNoIGlzIG1vcmUgY29tcGxleCB0byBpbXBsZW1lbnQuIA0KW0RlY2Nhbl0gWW91IGFyZSBy aWdodCwgYXMgcGVyIHByZWZpeC9GRUMgaXMgYWN0dWFsbHkgdG8gc3BsaXQgdGhlIA0Kb3JpZ2lu YWwgcmFuZ2UgdG8gdGhlIHNtYWxsZXN0IG9uZXMuIE15IG1lYW5pbmcgaXMgdGhhdCB0aGVyZSBp cyBubyByYW5nZSANCmlkZWEgZHVyaW5nIGNvbmZsaWN0IHByb2Nlc3MgcGhhc2UgYXQgdGhlIGNv bW1vbiBwbGFjZSwgYWxsIGlzIGRvbmUgYmFzZWQgDQpvbiB0aGUgZXhpc3RpbmcgZGF0YSBzdHJ1 Y3R1cmUgcGVyIHByZWZpeC9GRUMuIE1hcHBpbmcgcmFuZ2Ugb25seSBhcHBlYXIgDQppbiB0aGUg aW5kaXZpZHVhbCBwcm90b2NvbCBpbnN0YW5jZSwgYnV0IGl0IGlzIGFsd2F5cyB0byBiZSBzcGxp dCB0byB0aGUgDQpzbWFsbGVzdCBvbmVzLCBmb3IgcmEgZm9yIGNvbmZsaWN0IGZ1bmN0aW9uLiAN Cg0KMikgVGhlIHJlc3RyaWN0aW9ucyBpbiBuZXcgc2VjdGlvbiAiU2NvcGUgb2YgU1ItTVBMUyBT SUQgQ29uZmxpY3RzIiBtYXliZSANCm5vdCB0cnVlLiBQbGVhc2UganVzdCBjb25zaWRlciAiQ2Fy cmllciBvZiBDYXJyaWVyIiBjYXNlIHdoaWNoIGRlcGxveSANCklHUCtMRFAgYmV0d2VlbiBQRSBh bmQgQ0UuIEl0IGlzIHBvc3NpYmxlIHRvIGRlcGxveSBTUiBMU1AgaW4gdGhlIHNlY29uZCANCmxl dmVsIGNhcnJpZXIsIHNvIHRoYXQgYW4gU1IgTFNQIGlzIGJ1aWxkaW5nIGZyb20gb25lIHNpdGUg dG8gYW5vdGhlciANCmFjcm9zcyB0aGUgZmlyc3QgbGV2ZWwgY2Fycmllciwgc2FtZSBhcyBhbiBM RFAgTFNQLiBUaGlzIG1lYW5zIFNJRHMgDQphc3NvY2lhdGVkIHdpdGggZGVzdGluYXRpb25zIGlu IFNpdGUgQSB3aWxsIGJlIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZyANCnBsYW5lIG9mIHJv dXRlcnMgaW4gU2l0ZSBCLiANCg0KW0xlczpdIFdlIGhhdmUgbG9va2VkIGF0IKGwQ2FycmllciBv ZiBDYXJyaWVyobEgYW5kIHdlIGRpc2FncmVlIHdpdGggeW91ciANCmNvbmNsdXNpb24uIFRvIHJl YWNoIGRlc3RpbmF0aW9ucyBpbiBTaXRlIEIgZnJvbSBTaXRlIEEgcGFja2V0cyB3aWxsIG5lZWQg DQp0byB0cmF2ZXJzZSB0aGUgUEUocykgY29ubmVjdGVkIHRvIFNpdGUgQS4gV2hhdCB3aWxsIGJl IGluc3RhbGxlZCBpbiB0aGUgDQpmb3J3YXJkaW5nIHBsYW5lIG9mIHJvdXRlcnMgaW4gU2l0ZSBB IHdpbGwgYmUgbGFiZWxzIGFzc29jaWF0ZWQgd2l0aCB0aGUgDQpTSUQgb2YgdGhlIFBFIKhDIG5v dCB0aGUgU0lEcyBmb3IgZGVzdGluYXRpb25zIGluIFNpdGUgQi4gSW4gZmFjdCwgaXQgaXMgDQpw b3NzaWJsZSBmb3IgZGVzdGluYXRpb24gMS4xLjEuMSBpbiBTaXRlIEEgdG8gdXNlIHRoZSBzYW1l IFNJRCBhcyANCmRlc3RpbmF0aW9uIDIuMi4yLjIgaW4gU2l0ZSBCLiBUaGlzIGlzIGRpc2N1c3Nl ZCBpbiBTZWN0aW9uIDQgb2YgdGhlIA0KZHJhZnQuIA0KW0RlY2Nhbl0gU29ycnksIEkgY2Fubm90 IHVuZGVyc3RhbmQgaG93IHRvIGZ1bGZpbGwgdGhpcyBjYXNlIHlldC4gSU1PLCANCnBhY2tldHMg ZnJvbSBzaXRlIEEgbmVlZCBjb250YWluIFNJRHMgZm9yIGRlc3RpbmF0aW9ucyBpbiBzaXRlIEIs IHNvIHRoYXQgDQpwYWNrZXRzIGNhbiBmb3J3YXJkIHRvIHRoZSBzcGVjaWZpYyBkZXN0aW5hdGlv biBjb3JyZWN0bHksIHRoZSBTSUQgb2YgdGhlIA0KUEUgY2FuIG9ubHkgYmUgdXNlZCB0byBmb3J3 YXJkIHBhY2tldHMgdG8gdGhlIFBFLiBBbHRob3VnaCwgYXQgdGhlIGluZ3Jlc3MgDQpub2RlIGlu IHNpdGUgQSwgd2UgY2FuIGVuY2Fwc3VsYXRlIFNJRCBvZiB0aGUgUEUgYWdhaW4gdG8gaGlkZSBT SUQgb2Ygc2l0ZSANCkIgYmVmb3JlIHNlbmRpbmcgcGFja2V0cywgdGhlIGluZ3Jlc3Mgbm9kZSBp biBzaXRlIEEgYW5kIHRoZSBQRSBuZWVkIHN0aWxsIA0Kc2VlIHRoZSBTSUQgb2Ygc2l0ZSBCLiBB IG5vZGUgaW4gc2l0ZSBBIGNhbiBub3QgZW5zdXJlIGl0IHdpbGwgb25seSBhY3QgYXMgDQphIHRy YW5zaXQgcm9sZS4gQ291bGQgeW91IGV4cGxhaW4gbW9yZT8gDQoNCiAgIExlcyANCg0KVGhhbmtz IA0KDQpEZWNjYW4gDQogIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0gDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFu ZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4g IElmIHlvdSBhcmUgbm90IA0KYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwg cmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVz ZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICAN CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBp dCBhbmQgbm90aWZ5IHVzIA0KaW1tZWRpYXRlbHkuIA0KICANCiAgDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmls ZWdlZCBhbmQgY29uZmlkZW50aWFsIA0KYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl IHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgDQphbiBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBv dGhlciANCmRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwg aW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmltbWVkaWF0ZWx5Lg0K DQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IA0KYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3Rp ZnkgdXMgDQppbW1lZGlhdGVseS4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkg aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFp bCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 0015AC0C48257FE7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJvYmVydCw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgaXQgaXMgYmV0dGVyIHRv IGFkZCBtb3JlIGRlc2NyaXB0aW9uDQp0byBzZWN0aW9uIDQgdG8gZWxpbWluYXRlIGNvbmZ1c2lv bi4gTm93IHdlIG9ubHkgZ2V0IGEgJnF1b3Q7c3RhdGVtZW50JnF1b3Q7DQp0aGF0IHRoZXJlIGlz IG5vIHByb2JsZW0sIGJ1dCBub3QgaG93LiBGb3IgZXhhbXBsZSwgaWYgc2VwYXJhdGUgJnF1b3Q7 Y29udGV4dHMmcXVvdDsNCmluIGRhdGEgcGxhbmUgYXMgeW91IHNhaWQgaXMgYSBzdWdnZXN0aW9u IG1ldGhvZCB0byBmdWxmaWxsIHRoaXMgY2FzZT8NCk5vdGUgdGhhdCBJTE0gY29ycmVzcG9uZGlu ZyB0byBTUiBsYWJlbCBoYXMgbm8gJnF1b3Q7Y29udGV4dHMmcXVvdDsgaW4NCmRhdGEgcGxhbmUg Y3VycmVudGx5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+TGV0J3MgZmlyc3QgY29uY2VybiBpc3N1ZXMgaW4gY29udHJvbA0KcGxhbmUuIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U3VwcG9zZWQgdGhhdCB0aGVyZSBh cmUgc2l0ZSBBLEIsQyBhdHRhY2hpbmcNCnRvIHByb3ZpZGVyIG5ldHdvcmsgdGhyb3VnaCBQRTEs UEUyLFBFMyByZXNwZWN0aXZlbHksIGFuZCBBLEIsQyBiZWxvbmcNCnRvIHNhbWUgdnJmIG5ldHdv cmsuIFN1cHBvc2VkIHRoYXQgZGVzdGluYXRpb24gMS4xLjEuMSBpbiBzaXRlIEEsIDIuMi4yLjIN CmluIHNpdGUgQiwgMy4zLjMuMyBpbiBzaXRlIEMgYXNzaWduIHRoZSBzYW1lIHByZWZpeC1zaWQu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZWNhdXNlIEkgaGF2 ZSBubyBlbnRpcmUgaWRlYSBhYm91dA0KdGhlIHNvbHV0aW9uIGJlaGluZCBzZWN0aW9uIDQsIEkg anVzdCBsaXN0IHRoZSBxdWVzdGlvbnMgYXMgZm9sbG93aW5nOjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MSkgUEUxJ3MgQkdQIHdpbGwgcmVjZWl2ZSBW UE52NCBwcmVmaXgoMi4yLjIuMikNCmZyb20gUEUyIHdpdGggcHJlZml4LXNpZCBzYW1lIGFzIFZQ TnY0IHByZWZpeCgzLjMuMy4zKSBmcm9tIFBFMywgZG9lcyBpdA0KZG8gY29uZmxpY3QgcHJvY2Vz cyBpbiB0aGlzIHBoYXNlPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+MikgUEUxJ3MgQkdQIHdpbGwgaW1wb3J0IFZQTnY0IHJvdXRlDQp0byBsb2NhbCB2cmYsIHNv IGluIHRoZSBzYW1lIFZQTiByb3V0aW5nIHRhYmxlLCBwcmVmaXgoMi4yLjIuMikgYW5kIHByZWZp eCgzLjMuMy4zKQ0KaGF2ZSB0aGUgc2FtZSBwcmVmaXgtc2lkLCBkb2VzIGl0IGRvIGNvbmZsaWN0 IHByb2Nlc3MgaW4gdGhpcyBwaGFzZT88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjMpIFBFMSdzIElHUCB3aWxsIHJlZGlzdHJpYnV0ZSBCR1Agcm91dGVzDQppbiB0 aGUgdnJmLCBzbyBJR1Agd2lsbCBhbHNvIHNlZSB0d28gcHJlZml4ZXMgaGF2ZSB0aGUgc2FtZSBw cmVmaXgtc2lkLA0KZG9lcyBpdCBkbyBjb25mbGljdCBwcm9jZXNzIGluIHRoaXMgcGhhc2U/PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj40KSBFYWNoIHJvdXRlciBp biBzaXRlIEEgd2lsbCByZWNlaXZlDQpwZXJmaXggZmxvb2QsIHNvIGF0IGVhY2ggcm91dGVyIGl0 cyBJR1Agd2lsbCBhbHNvIHNlZSB0d28gcHJlZml4ZXMgaGF2ZQ0KdGhlIHNhbWUgcHJlZml4LXNp ZCwgZG9lcyBpdCBkbyBjb25mbGljdCBwcm9jZXNzIGluIHRoaXMgcGhhc2U/PC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+VGhhbmtzPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RGVjY2FuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQw JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Um9iZXJ0IFJhc3p1ayAmbHQ7cm9i ZXJ0QHJhc3p1ay5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3JyYXN6dWtAZ21haWwuY29tPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYtMDctMDQgMTY6MDA8L2ZvbnQ+DQo8dGQg d2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+cGVuZy5zaGFvZnVA enRlLmNvbS5jbiwgPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKSZxdW90Ow0KJmx0O2dpbnNiZXJnQGNpc2NvLmNvbSZndDssICZxdW90O3NwcmluZ0BpZXRm Lm9yZyZxdW90OyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6 IFtzcHJpbmddILTwuLQ6IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj5IaSBQZW5nLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPk9uIHRoZSBwb2ludCAjMiB5b3UgYXJlIHJpZ2h0IHRoYXQgZXh0ZXJuYWxseQ0KcmVj ZWl2ZWQgU0lEcyB3aWxsIGJlIGluc3RhbGxlZCBpbiB0aGUgZGF0YSBwbGFuZSBvZiBQRXMuJm5i c3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+SG93ZXZlciB5 b3UgbmVlZCB0byBvYnNlcnZlIHRoYXQgdGhleSB3aWxsDQpiZSBpbnN0YWxsZWQgaW4gY29tcGxl dGVseSBzZXBhcmF0ZSAmcXVvdDtjb250ZXh0cyZxdW90OyBpbiBkYXRhIHBsYW5lDQpoZW5jZSBj dXJyZW50IGFkZGl0aW9uIChhZnRlciBJIGJyb3VnaHQgdGhpcyBpc3N1ZSBmZXcgd2Vla3MgYmFj aykgaGFzDQpiZWVuIGFjY3VyYXRlbHkgYWRkcmVzc2VkIGluIG5ldyBzZWN0aW9ucyAzLjIuNiBh bmQgNC4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5B bGwgd2hhdCB5b3UgYXJlIHNheWluZyBpcyB0cnVlIGFuZCB0aGUgJm5ic3A7Y3VycmVudA0KZHJh ZnQgZW5hYmxlcyBvbmUgdG8gZG8gdGhhdCB5ZXQgdG8ga2VlcCBjb25zaXN0ZW50IGJhc2UgdG9w b2xvZ3kgaW4gdGhlDQpuZXR3b3JrLiBXZWxsIG1vZHVsbyBjb21tZW50cyBmcm9tIEJydW5vIHdo aWNoIGhhdmUgbm90IGJlZW4geWV0IHdlbGwgYWRkcmVzc2VkLiZuYnNwOzwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkNoZWVycyw8YnI+DQpSLjwvZm9udD4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+T24gTW9uLCBKdWwgNCwgMjAxNiBhdCA0OjMyIEFN LCAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY24gdGFyZ2V0 PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5wZW5nLnNoYW9mdUB6dGUuY29tLmNu PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDsNCndyb3RlOjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TGVzLCA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU2VlIGlubGluZS48 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPGJyPg0K PC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTQ4JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7TGVzIEdpbnNi ZXJnIChnaW5zYmVyZykmcXVvdDsNCiZsdDs8L2I+PC9mb250PjxhIGhyZWY9bWFpbHRvOmdpbnNi ZXJnQGNpc2NvLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPjxiPjx1PmdpbnNiZXJnQGNpc2NvLmNvbTwvdT48L2I+PC9mb250PjwvYT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDE2LTA3LTAyIDAxOjEzPC9mb250Pjxmb250 IHNpemU9Mz4NCjwvZm9udD4NCjx0ZCB3aWR0aD01MSU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTEwJT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0 aD04OSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OzwvZm9udD48YSBocmVm PW1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+cGVuZy5zaGFvZnVAenRlLmNvbS5jbjwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCiZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnBlbmcuc2hhb2Z1 QHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ Jmd0OywNCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOnNw cmluZ0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPjx1PnNwcmluZ0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c3By aW5nQGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+c3ByaW5nQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5SRTogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlv bjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KRGVjY2FuIC08L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9Mz4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkZyb206PC9iPiA8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cGVuZy5zaGFvZnVAenRlLmNv bS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KWzwvZm9udD48 YSBocmVmPW1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5tYWlsdG86cGVuZy5zaGFvZnVAenRl LmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPjxi cj4NClNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMDEsIDIwMTYgMjo0NiBBTTxiPjxicj4NClRvOjwv Yj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk8Yj48YnI+DQpDYzo8L2I+IDwvZm9udD48YSBocmVm PW1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnNwcmluZ0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10g ZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwvZm9udD48Zm9udCBzaXplPTM+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KJm5ic3A7 PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KSGlzIExlcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjEpIEZyb20gaW1wbGVt ZW50YXRpb24sIGJlY2F1c2UgcHJlZmVyZW5jZSBhbGdvcml0aG0gaXMgcHJvdG9jb2wgaW5kZXBl bmRlbnQsDQppdCBpcyBiZXR0ZXIgdG8gZG8gY29uZmxpY3QgcmVzb2x1dGlvbiBhdCBhIGNvbW1v biBwbGFjZSwgbm90IGF0IGluZGl2aWR1YWwNCnByb3RvY29sIGluc3RhbmNlLiBGb3IgZXhhbXBs ZSwgd2UgY2FuIGRvIHByZWZpeC1jb25mbGljdCByZXNvbHV0aW9uIHdoZW4NCmdlbmVyYXRlIHRo ZSBwcmVmZXJlbmNlIEZJQiBlbnRyeSBhdCB0aGUgY29tbW9uIHBsYWNlLiBGb3IgYSBwcmVmZXJl bmNlDQpGSUIgZW50cnksIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIG1heSBnZXQgZnJvbSBPU1BG IGJ5IGFkbWluaXN0cmF0aXZlDQpkaXN0YW5jZSwgYnV0IHRoZSBTSUQgaW5mb3JtYXRpb24gbWF5 IGdldCBmcm9tIElTSVMgYnkgcHJlZml4LWNvbmZsaWN0DQphbGdvcml0aG0uIFRoZW4gd2UgY2Fu IGRvIHNpZC1jb25mbGljdCByZXNvbHV0aW9uIHdoZW4gZ2VuZXJhdGUgdGhlIFNJRC1MSUINCmVu dHJ5IGFjY29yZGluZyB0byB0aGUgYWJvdmUgRklCIGVudHJ5IGFuZCBvdGhlciBzb3VyY2VzLCBp dCB3aWxsIHNlbGVjdA0KYSBwcmVmZXJlbmNlIEZFQyB0byBwcm92aWRlIGZvcndhcmRpbmcgaW5m b3JtYXRpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU28sIHByZWZlcmVuY2UgYWxnb3Jp dGhtIHBlciBwcmVmaXgvZmVjIGlzIGVub3VnaC4gUGVyIHJhbmdlIGlzIHBvc3NpYmxlLA0KYnV0 IGltcGxlbWVudGF0aW9uIGlzIGNvbXBsZXguIE1vcmUgY29tcGxleCBpcyBmb3IgJnF1b3Q7aWdu b3Igb3ZlcmxheSZxdW90Ow0KcGVyIHJhbmdlLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+PGJyPg0KW0xlczpdIEltcGxl bWVudGF0aW9uLXdpc2UsIHlvdSBhcmUgZnJlZSB0byBpbXBsZW1lbnQgdGhpcyBpbiBhbnkgbW9k dWxlDQp5b3UgbGlrZSBzbyBsb25nIGFzIHdpdGggdGhlIHNhbWUgZGF0YWJhc2UgeW91IGNvbWUg dXAgd2l0aCB0aGUgc2FtZSBhbnN3ZXINCmFzIG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrLjwv aT48L2I+PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPjxiPjxpPjxicj4NClRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIKGw UXVhcmFudGluZaGxIGFuZCChsElnbm9yZSBPdmVybGFwobEgaXMgdGhhdA0KdGhlIGxhdHRlciBh dHRlbXB0cyB0byB1c2UgdGhvc2UgcG9ydGlvbnMgb2YgYSByYW5nZSB3aGljaCBkbyBub3QgaGF2 ZQ0KY29uZmxpY3RzIHdpdGggb3RoZXIgZW50cmllcy4gVGhlIGNvc3Qgb2YgZG9pbmcgc28gaXMg aGF2aW5nIHRvIGNyZWF0ZQ0KobBkZXJpdmVkIGVudHJpZXOhsSB3aGljaCByZXByZXNlbnQgdGhv c2Ugc3ViLXJhbmdlcyB3aGljaCBkby9kbyBub3QNCmhhdmUgY29uZmxpY3RzLiBEdWUgdG8gdGhl IGFkZGVkIGNvbXBsZXhpdHkgdGhpcyBpcyBOT1QgdGhlIGZpcnN0IGNob2ljZQ0Kb2YgdGhlIGF1 dGhvcnMuIDxicj4NCklmIEkgd2VyZSB0byBjYXRlZ29yaXplIHRoZSB0d28gYWxnb3JpdGhtcyB1 c2luZyB5b3VyIHRlcm1pbm9sb2d5IKGwUXVhcmFudGluZaGxDQp3b3VsZCBiZSChsHBlciByYW5n ZaGxIHdoaWxlIKGwSWdub3JlIE92ZXJsYXChsSB3b3VsZCBiZSChsHBlciBwcmVmaXgvRkVDobEu DQpTbyBpdCBpcyB0aGUgbGF0dGVyIHdoaWNoIGlzIG1vcmUgY29tcGxleCB0byBpbXBsZW1lbnQu PC9pPjwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KW0RlY2Nhbl0gWW91IGFyZSByaWdodCwgYXMgcGVyIHByZWZpeC9GRUMgaXMg YWN0dWFsbHkgdG8gc3BsaXQgdGhlIG9yaWdpbmFsDQpyYW5nZSB0byB0aGUgc21hbGxlc3Qgb25l cy4gTXkgbWVhbmluZyBpcyB0aGF0IHRoZXJlIGlzIG5vIHJhbmdlIGlkZWEgZHVyaW5nDQpjb25m bGljdCBwcm9jZXNzIHBoYXNlIGF0IHRoZSBjb21tb24gcGxhY2UsIGFsbCBpcyBkb25lIGJhc2Vk IG9uIHRoZSBleGlzdGluZw0KZGF0YSBzdHJ1Y3R1cmUgcGVyIHByZWZpeC9GRUMuIE1hcHBpbmcg cmFuZ2Ugb25seSBhcHBlYXIgaW4gdGhlIGluZGl2aWR1YWwNCnByb3RvY29sIGluc3RhbmNlLCBi dXQgaXQgaXMgYWx3YXlzIHRvIGJlIHNwbGl0IHRvIHRoZSBzbWFsbGVzdCBvbmVzLCBmb3INCnJh IGZvciBjb25mbGljdCBmdW5jdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQoyKSBUaGUgcmVzdHJpY3Rpb25zIGluIG5l dyBzZWN0aW9uICZxdW90O1Njb3BlIG9mIFNSLU1QTFMgU0lEIENvbmZsaWN0cyZxdW90Ow0KbWF5 YmUgbm90IHRydWUuIFBsZWFzZSBqdXN0IGNvbnNpZGVyICZxdW90O0NhcnJpZXIgb2YgQ2Fycmll ciZxdW90OyBjYXNlDQp3aGljaCBkZXBsb3kgSUdQK0xEUCBiZXR3ZWVuIFBFIGFuZCBDRS4gSXQg aXMgcG9zc2libGUgdG8gZGVwbG95IFNSIExTUA0KaW4gdGhlIHNlY29uZCBsZXZlbCBjYXJyaWVy LCBzbyB0aGF0IGFuIFNSIExTUCBpcyBidWlsZGluZyBmcm9tIG9uZSBzaXRlDQp0byBhbm90aGVy IGFjcm9zcyB0aGUgZmlyc3QgbGV2ZWwgY2Fycmllciwgc2FtZSBhcyBhbiBMRFAgTFNQLiBUaGlz IG1lYW5zDQpTSURzIGFzc29jaWF0ZWQgd2l0aCBkZXN0aW5hdGlvbnMgaW4gU2l0ZSBBIHdpbGwg YmUgaW5zdGFsbGVkIGluIHRoZSBmb3J3YXJkaW5nDQpwbGFuZSBvZiByb3V0ZXJzIGluIFNpdGUg Qi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+PGJyPg0KPGJyPg0K W0xlczpdIFdlIGhhdmUgbG9va2VkIGF0IKGwQ2FycmllciBvZiBDYXJyaWVyobEgYW5kIHdlIGRp c2FncmVlIHdpdGgNCnlvdXIgY29uY2x1c2lvbi4gVG8gcmVhY2ggZGVzdGluYXRpb25zIGluIFNp dGUgQiBmcm9tIFNpdGUgQSBwYWNrZXRzIHdpbGwNCm5lZWQgdG8gdHJhdmVyc2UgdGhlIFBFKHMp IGNvbm5lY3RlZCB0byBTaXRlIEEuIFdoYXQgd2lsbCBiZSBpbnN0YWxsZWQNCmluIHRoZSBmb3J3 YXJkaW5nIHBsYW5lIG9mIHJvdXRlcnMgaW4gU2l0ZSBBIHdpbGwgYmUgbGFiZWxzIGFzc29jaWF0 ZWQNCndpdGggdGhlIFNJRCBvZiB0aGUgUEUgqEMgbm90IHRoZSBTSURzIGZvciBkZXN0aW5hdGlv bnMgaW4gU2l0ZSBCLiBJbiBmYWN0LA0KaXQgaXMgcG9zc2libGUgZm9yIGRlc3RpbmF0aW9uIDEu MS4xLjEgaW4gU2l0ZSBBIHRvIHVzZSB0aGUgc2FtZSBTSUQgYXMNCmRlc3RpbmF0aW9uIDIuMi4y LjIgaW4gU2l0ZSBCLiBUaGlzIGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQgb2YgdGhlIGRyYWZ0 LjwvaT48L2I+PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9 IzAwNDA4MCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCltEZWNjYW5dIFNvcnJ5LCBJIGNh bm5vdCB1bmRlcnN0YW5kIGhvdyB0byBmdWxmaWxsIHRoaXMgY2FzZSB5ZXQuIElNTyw8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzAw NDA4MCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPnBhY2tldHMgZnJvbSBzaXRlDQpBIG5lZWQgY29u dGFpbiBTSURzIGZvciBkZXN0aW5hdGlvbnMgaW4gc2l0ZSBCLCBzbyB0aGF0IHBhY2tldHMgY2Fu IGZvcndhcmQNCnRvIHRoZSBzcGVjaWZpYyBkZXN0aW5hdGlvbiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj5jb3JyZWN0bHksDQp0aGUgU0lEIG9mIHRoZSBQRSBjYW4gb25seSBiZSB1 c2VkIHRvIGZvcndhcmQgcGFja2V0cyB0byB0aGUgUEUuIEFsdGhvdWdoLA0KYXQgdGhlIGluZ3Jl c3Mgbm9kZSBpbiBzaXRlIEEsIHdlIGNhbiBlbmNhcHN1bGF0ZSBTSUQgb2YgdGhlIFBFIGFnYWlu IHRvDQpoaWRlIFNJRCBvZiBzaXRlIEIgYmVmb3JlIHNlbmRpbmcgcGFja2V0cywgdGhlIGluZ3Jl c3Mgbm9kZSBpbiBzaXRlIEEgYW5kDQp0aGUgUEUgbmVlZCBzdGlsbCBzZWUgdGhlIFNJRCBvZiBz aXRlIEIuIEEgbm9kZSBpbiBzaXRlIEEgY2FuIG5vdCBlbnN1cmUNCml0IHdpbGwgb25seSBhY3Qg YXMgYSB0cmFuc2l0IHJvbGUuIENvdWxkIHlvdSBleHBsYWluIG1vcmU/PC9mb250Pjxmb250IHNp emU9Mz4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9IzAwNDA4MCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxicj4NCiZuYnNwOyAmbmJzcDtMZXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpUaGFua3MgPGJyPg0K PGJyPg0KRGVjY2FuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsDQphbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNl IG9mIHRoZSBhZGRyZXNzZWUocykuJm5ic3A7IElmIHlvdQ0KYXJlIG5vdCBhbiBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbg0Kb3Ig b3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp cyBzdHJpY3RseQ0KcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlDQppdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5 LjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJDb3VyaWVyIE5ldyI+PGJyPg0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTM+IDxicj4NCjwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+ PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRl ZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsDQphbmQgaXMgaW50ZW5k ZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lmIHlv dQ0KYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIGRpc3RyaWJ1dGlvbg0Kb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseQ0KcHJvaGliaXRlZC4gJm5ic3A7SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlDQppdCBh bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjxm b250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVl Pjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbA0KYW5kIGlzIGludGVu ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAmbmJzcDtJZiB5 b3UNCmFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9k dWN0aW9uLCBkaXN0cmlidXRpb24NCm9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkNCnByb2hpYml0ZWQuICZuYnNwO0lm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZQ0KaXQg YW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTM+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9 MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c3ByaW5nQGll dGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PnNwcmluZ0BpZXRmLm9yZzwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJl Zj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3ByaW5nPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9u dD4NCjxicj4NCjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUg dXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp cGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJy b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250 PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVn ZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNl IG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGll bnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBk aXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3Is IHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250Pjwv cHJlPjxicj4NCg== --=_alternative 0015AC0C48257FE7_=-- From nobody Mon Jul 4 23:05:27 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87212D11D for ; Mon, 4 Jul 2016 23:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJCMNUhCAn_m for ; Mon, 4 Jul 2016 23:05:20 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F00612B043 for ; Mon, 4 Jul 2016 23:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44879; q=dns/txt; s=iport; t=1467698720; x=1468908320; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OiYoSUunVtphk5ha6BxssM4XDWe+eNSTcpEfS+fvYBw=; b=ROEn98btuCU9/STVXNn9bhI/cr6TaSvgJnxskVfZdM90o8LPtMqWd6s6 Lw7ORr9i46mjQvaIp3NV697zWwAN7QQpt9yc94qXCm/AgDAX7fXccBbXR qSIF3E13ODs/q95tLNJ9jNHSp8KJQ5aMDOXOeV0rU9rMOt9zYvXUkMbn2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQBKTXtX/51dJa1cgnBOVnwGgniqN?= =?us-ascii?q?IwQgXcihSxKAhyBIjgUAQEBAQEBAWUnhEwBAQUBAQohOgcLEAIBBgIRBAEBIQE?= =?us-ascii?q?GBQICHwYLFAYDCAIEAQ0FCBMEh3cDFw6MPp0XCIsODYQOAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWGJ4RNgkOBYAEBMhUKgkeCXgWIGosYJ4UGNAGLdEKCCYFxF4Q?= =?us-ascii?q?/iGqIF4dyAR42gggFF4FMbodENn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,578,1459814400"; d="scan'208,217";a="293492120" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 06:05:18 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u6565I4w026773 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 06:05:18 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 01:05:17 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 01:05:17 -0500 From: "Les Ginsberg (ginsberg)" To: "peng.shaofu@zte.com.cn" , Robert Raszuk Thread-Topic: =?gb2312?B?UmU6IFtzcHJpbmddILTwuLQ6IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25m?= =?gb2312?Q?lict-resolution?= Thread-Index: AQHR1coclOrWFaWmy0OCg22P0KHrvqAJissA///MC6A= Date: Tue, 5 Jul 2016 06:05:17 +0000 Message-ID: References: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.5.100] Content-Type: multipart/alternative; boundary="_000_cd2e332d6d0b479bb93be8dbf63cab9aXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "rraszuk@gmail.com" Subject: Re: [spring] =?gb2312?b?tPC4tDogUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZs?= =?gb2312?b?aWN0LXJlc29sdXRpb24=?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 06:05:26 -0000 --_000_cd2e332d6d0b479bb93be8dbf63cab9aXCHALN001ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVjY2FuIKhDDQoNClRoZXJlIGlzIGEgZGlzdGluY3Rpb24gYmV0d2VlbiB3aGF0IGxhYmVscyBt YXkgYmUgaW5jbHVkZWQgaW4gdGhlIGVuY2Fwc3VsYXRpb24gZm9yIGEgcGFja2V0IGFuZCB3aGF0 IGxhYmVscyB3aWxsIGJlIKGwdG9wIG9mIHN0YWNrobEuIEl0IGlzIG9ubHkgdGhlIGxhdHRlciB3 aGljaCBnZXRzIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4NCg0KVG8gcmVhY2gg ZGVzdGluYXRpb25zIGluIFNpdGUgQiBmcm9tIGEgbm9kZSBpbiBTaXRlIEEgdGhlIHBhY2tldCBo YXMgdG8gYmUgc2VudCB0byBhIENFIGluIHNpdGUgQiB2aWEgYSBQRSBhY2Nlc3NpYmxlIHRvIG5v ZGVzIGluIFNpdGUgQS4gU28gZW5jYXBzdWxhdGlvbiB0byBhIGRlc3RpbmF0aW9uIFogaW4gc2l0 ZSBCIHdvdWxkIGxvb2sgbGlrZToNCg0KICBMYWJlbCBmb3IgQ0UtQiBhc3NpZ25lZCBieSBQRS1B DQogIExhYmVsIGZvciBEZXN0aW5hdGlvbiBaDQoNCk5vZGVzIGluIFNpdGUgQSB3aWxsIG5ldmVy IFBPUCB0aGUgdG9wIGxhYmVsIKhDIHNvIHRoZXkgd2lsbCBuZXZlciByZWNlaXZlIGEgcGFja2V0 IGFkZHJlc3NlZCB0byBaIHdoZXJlIHRoZSB0b3AgbGFiZWwgaXMgobBaobEuIEFueSBsYWJlbCAo b3IgdGhlIFNJRCB1c2VkIHRvIGRlcml2ZSBpdCkgdGhhdCB3b26hr3QgYmUgdG9wIG9mIHN0YWNr IGluIFNpdGUgQSBpcyBub3QgcGFydCBvZiB0aGUgZGF0YWJhc2UgdXNlZCBmb3IgY29uZmxpY3Qg cmVzb2x1dGlvbiBpbiBTaXRlIEEuDQoNCk5vdGUgdGhhdCB0aGlzIGlzIHN0YW5kYXJkIE1QTFMg Zm9yd2FyZGluZyBiZWhhdmlvciBmb3IgdGhpcyBkZXBsb3ltZW50IKhDIHRoZSB1c2Ugb2YgU1Ig aGFzIG5vdCBjaGFuZ2VkIHRoaXMgaW4gYW55IHdheS4NCg0KICAgTGVzDQoNCg0KDQpGcm9tOiBw ZW5nLnNoYW9mdUB6dGUuY29tLmNuIFttYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbl0NClNl bnQ6IE1vbmRheSwgSnVseSAwNCwgMjAxNiA4OjU3IFBNDQpUbzogUm9iZXJ0IFJhc3p1aw0KQ2M6 IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOyBycmFzenVrQGdtYWlsLmNvbTsgc3ByaW5nQGlldGYu b3JnDQpTdWJqZWN0OiC08Li0OiBSZTogW3NwcmluZ10gtPC4tDogUkU6IGRyYWZ0LWlldGYtc3By aW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KSGkgUm9iZXJ0LA0KDQpJIHRoaW5rIGl0IGlzIGJl dHRlciB0byBhZGQgbW9yZSBkZXNjcmlwdGlvbiB0byBzZWN0aW9uIDQgdG8gZWxpbWluYXRlIGNv bmZ1c2lvbi4gTm93IHdlIG9ubHkgZ2V0IGEgInN0YXRlbWVudCIgdGhhdCB0aGVyZSBpcyBubyBw cm9ibGVtLCBidXQgbm90IGhvdy4gRm9yIGV4YW1wbGUsIGlmIHNlcGFyYXRlICJjb250ZXh0cyIg aW4gZGF0YSBwbGFuZSBhcyB5b3Ugc2FpZCBpcyBhIHN1Z2dlc3Rpb24gbWV0aG9kIHRvIGZ1bGZp bGwgdGhpcyBjYXNlPyBOb3RlIHRoYXQgSUxNIGNvcnJlc3BvbmRpbmcgdG8gU1IgbGFiZWwgaGFz IG5vICJjb250ZXh0cyIgaW4gZGF0YSBwbGFuZSBjdXJyZW50bHkuDQoNCkxldCdzIGZpcnN0IGNv bmNlcm4gaXNzdWVzIGluIGNvbnRyb2wgcGxhbmUuDQpTdXBwb3NlZCB0aGF0IHRoZXJlIGFyZSBz aXRlIEEsQixDIGF0dGFjaGluZyB0byBwcm92aWRlciBuZXR3b3JrIHRocm91Z2ggUEUxLFBFMixQ RTMgcmVzcGVjdGl2ZWx5LCBhbmQgQSxCLEMgYmVsb25nIHRvIHNhbWUgdnJmIG5ldHdvcmsuIFN1 cHBvc2VkIHRoYXQgZGVzdGluYXRpb24gMS4xLjEuMSBpbiBzaXRlIEEsIDIuMi4yLjIgaW4gc2l0 ZSBCLCAzLjMuMy4zIGluIHNpdGUgQyBhc3NpZ24gdGhlIHNhbWUgcHJlZml4LXNpZC4NCkJlY2F1 c2UgSSBoYXZlIG5vIGVudGlyZSBpZGVhIGFib3V0IHRoZSBzb2x1dGlvbiBiZWhpbmQgc2VjdGlv biA0LCBJIGp1c3QgbGlzdCB0aGUgcXVlc3Rpb25zIGFzIGZvbGxvd2luZzoNCg0KMSkgUEUxJ3Mg QkdQIHdpbGwgcmVjZWl2ZSBWUE52NCBwcmVmaXgoMi4yLjIuMikgZnJvbSBQRTIgd2l0aCBwcmVm aXgtc2lkIHNhbWUgYXMgVlBOdjQgcHJlZml4KDMuMy4zLjMpIGZyb20gUEUzLCBkb2VzIGl0IGRv IGNvbmZsaWN0IHByb2Nlc3MgaW4gdGhpcyBwaGFzZT8NCjIpIFBFMSdzIEJHUCB3aWxsIGltcG9y dCBWUE52NCByb3V0ZSB0byBsb2NhbCB2cmYsIHNvIGluIHRoZSBzYW1lIFZQTiByb3V0aW5nIHRh YmxlLCBwcmVmaXgoMi4yLjIuMikgYW5kIHByZWZpeCgzLjMuMy4zKSBoYXZlIHRoZSBzYW1lIHBy ZWZpeC1zaWQsIGRvZXMgaXQgZG8gY29uZmxpY3QgcHJvY2VzcyBpbiB0aGlzIHBoYXNlPw0KMykg UEUxJ3MgSUdQIHdpbGwgcmVkaXN0cmlidXRlIEJHUCByb3V0ZXMgaW4gdGhlIHZyZiwgc28gSUdQ IHdpbGwgYWxzbyBzZWUgdHdvIHByZWZpeGVzIGhhdmUgdGhlIHNhbWUgcHJlZml4LXNpZCwgZG9l cyBpdCBkbyBjb25mbGljdCBwcm9jZXNzIGluIHRoaXMgcGhhc2U/DQo0KSBFYWNoIHJvdXRlciBp biBzaXRlIEEgd2lsbCByZWNlaXZlIHBlcmZpeCBmbG9vZCwgc28gYXQgZWFjaCByb3V0ZXIgaXRz IElHUCB3aWxsIGFsc28gc2VlIHR3byBwcmVmaXhlcyBoYXZlIHRoZSBzYW1lIHByZWZpeC1zaWQs IGRvZXMgaXQgZG8gY29uZmxpY3QgcHJvY2VzcyBpbiB0aGlzIHBoYXNlPw0KDQoNClRoYW5rcw0K DQpEZWNjYW4NCg0KDQoNCg0KUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRv OnJvYmVydEByYXN6dWsubmV0Pj4NCreivP7IyzogIHJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpy cmFzenVrQGdtYWlsLmNvbT4NCg0KMjAxNi0wNy0wNCAxNjowMA0KDQrK1bz+yMsNCg0KcGVuZy5z aGFvZnVAenRlLmNvbS5jbjxtYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbj4sDQoNCrOty80N Cg0KIkxlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29tPG1haWx0bzpn aW5zYmVyZ0BjaXNjby5jb20+PiwgInNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYu b3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCg0K1vfM4g0K DQpSZTogW3NwcmluZ10gtPC4tDogUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24NCg0KDQoNCg0KDQoNCg0KSGkgUGVuZywNCg0KT24gdGhlIHBvaW50ICMyIHlvdSBhcmUg cmlnaHQgdGhhdCBleHRlcm5hbGx5IHJlY2VpdmVkIFNJRHMgd2lsbCBiZSBpbnN0YWxsZWQgaW4g dGhlIGRhdGEgcGxhbmUgb2YgUEVzLg0KDQpIb3dldmVyIHlvdSBuZWVkIHRvIG9ic2VydmUgdGhh dCB0aGV5IHdpbGwgYmUgaW5zdGFsbGVkIGluIGNvbXBsZXRlbHkgc2VwYXJhdGUgImNvbnRleHRz IiBpbiBkYXRhIHBsYW5lIGhlbmNlIGN1cnJlbnQgYWRkaXRpb24gKGFmdGVyIEkgYnJvdWdodCB0 aGlzIGlzc3VlIGZldyB3ZWVrcyBiYWNrKSBoYXMgYmVlbiBhY2N1cmF0ZWx5IGFkZHJlc3NlZCBp biBuZXcgc2VjdGlvbnMgMy4yLjYgYW5kIDQuDQoNCkFsbCB3aGF0IHlvdSBhcmUgc2F5aW5nIGlz IHRydWUgYW5kIHRoZSAgY3VycmVudCBkcmFmdCBlbmFibGVzIG9uZSB0byBkbyB0aGF0IHlldCB0 byBrZWVwIGNvbnNpc3RlbnQgYmFzZSB0b3BvbG9neSBpbiB0aGUgbmV0d29yay4gV2VsbCBtb2R1 bG8gY29tbWVudHMgZnJvbSBCcnVubyB3aGljaCBoYXZlIG5vdCBiZWVuIHlldCB3ZWxsIGFkZHJl c3NlZC4NCg0KQ2hlZXJzLA0KUi4NCg0KDQpPbiBNb24sIEp1bCA0LCAyMDE2IGF0IDQ6MzIgQU0s IDxwZW5nLnNoYW9mdUB6dGUuY29tLmNuPG1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPj4g d3JvdGU6DQpMZXMsDQoNClNlZSBpbmxpbmUuDQoNCg0KDQoNCiJMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKSIgPGdpbnNiZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tPj4NCg0K MjAxNi0wNy0wMiAwMToxMw0KDQoNCsrVvP7Iyw0KDQoicGVuZy5zaGFvZnVAenRlLmNvbS5jbjxt YWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbj4iIDxwZW5nLnNoYW9mdUB6dGUuY29tLmNuPG1h aWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPj4sDQoNCrOty80NCg0KInNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPj4NCg0K1vfM4g0KDQpSRTogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJpbmctY29u ZmxpY3QtcmVzb2x1dGlvbg0KDQoNCg0KDQoNCg0KDQoNCkRlY2NhbiAtDQoNCkZyb206IHBlbmcu c2hhb2Z1QHp0ZS5jb20uY248bWFpbHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY24+IFttYWlsdG86 cGVuZy5zaGFvZnVAenRlLmNvbS5jbl0NClNlbnQ6IEZyaWRheSwgSnVseSAwMSwgMjAxNiAyOjQ2 IEFNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNw cmluZy1jb25mbGljdC1yZXNvbHV0aW9uDQoNCkhpcyBMZXMsDQoNCjEpIEZyb20gaW1wbGVtZW50 YXRpb24sIGJlY2F1c2UgcHJlZmVyZW5jZSBhbGdvcml0aG0gaXMgcHJvdG9jb2wgaW5kZXBlbmRl bnQsIGl0IGlzIGJldHRlciB0byBkbyBjb25mbGljdCByZXNvbHV0aW9uIGF0IGEgY29tbW9uIHBs YWNlLCBub3QgYXQgaW5kaXZpZHVhbCBwcm90b2NvbCBpbnN0YW5jZS4gRm9yIGV4YW1wbGUsIHdl IGNhbiBkbyBwcmVmaXgtY29uZmxpY3QgcmVzb2x1dGlvbiB3aGVuIGdlbmVyYXRlIHRoZSBwcmVm ZXJlbmNlIEZJQiBlbnRyeSBhdCB0aGUgY29tbW9uIHBsYWNlLiBGb3IgYSBwcmVmZXJlbmNlIEZJ QiBlbnRyeSwgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gbWF5IGdldCBmcm9tIE9TUEYgYnkgYWRt aW5pc3RyYXRpdmUgZGlzdGFuY2UsIGJ1dCB0aGUgU0lEIGluZm9ybWF0aW9uIG1heSBnZXQgZnJv bSBJU0lTIGJ5IHByZWZpeC1jb25mbGljdCBhbGdvcml0aG0uIFRoZW4gd2UgY2FuIGRvIHNpZC1j b25mbGljdCByZXNvbHV0aW9uIHdoZW4gZ2VuZXJhdGUgdGhlIFNJRC1MSUIgZW50cnkgYWNjb3Jk aW5nIHRvIHRoZSBhYm92ZSBGSUIgZW50cnkgYW5kIG90aGVyIHNvdXJjZXMsIGl0IHdpbGwgc2Vs ZWN0IGEgcHJlZmVyZW5jZSBGRUMgdG8gcHJvdmlkZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLg0K U28sIHByZWZlcmVuY2UgYWxnb3JpdGhtIHBlciBwcmVmaXgvZmVjIGlzIGVub3VnaC4gUGVyIHJh bmdlIGlzIHBvc3NpYmxlLCBidXQgaW1wbGVtZW50YXRpb24gaXMgY29tcGxleC4gTW9yZSBjb21w bGV4IGlzIGZvciAiaWdub3Igb3ZlcmxheSIgcGVyIHJhbmdlLg0KDQpbTGVzOl0gSW1wbGVtZW50 YXRpb24td2lzZSwgeW91IGFyZSBmcmVlIHRvIGltcGxlbWVudCB0aGlzIGluIGFueSBtb2R1bGUg eW91IGxpa2Ugc28gbG9uZyBhcyB3aXRoIHRoZSBzYW1lIGRhdGFiYXNlIHlvdSBjb21lIHVwIHdp dGggdGhlIHNhbWUgYW5zd2VyIGFzIG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrLg0KVGhlIGRp c3RpbmN0aW9uIGJldHdlZW4gobBRdWFyYW50aW5lobEgYW5kIKGwSWdub3JlIE92ZXJsYXChsSBp cyB0aGF0IHRoZSBsYXR0ZXIgYXR0ZW1wdHMgdG8gdXNlIHRob3NlIHBvcnRpb25zIG9mIGEgcmFu Z2Ugd2hpY2ggZG8gbm90IGhhdmUgY29uZmxpY3RzIHdpdGggb3RoZXIgZW50cmllcy4gVGhlIGNv c3Qgb2YgZG9pbmcgc28gaXMgaGF2aW5nIHRvIGNyZWF0ZSChsGRlcml2ZWQgZW50cmllc6GxIHdo aWNoIHJlcHJlc2VudCB0aG9zZSBzdWItcmFuZ2VzIHdoaWNoIGRvL2RvIG5vdCBoYXZlIGNvbmZs aWN0cy4gRHVlIHRvIHRoZSBhZGRlZCBjb21wbGV4aXR5IHRoaXMgaXMgTk9UIHRoZSBmaXJzdCBj aG9pY2Ugb2YgdGhlIGF1dGhvcnMuDQpJZiBJIHdlcmUgdG8gY2F0ZWdvcml6ZSB0aGUgdHdvIGFs Z29yaXRobXMgdXNpbmcgeW91ciB0ZXJtaW5vbG9neSChsFF1YXJhbnRpbmWhsSB3b3VsZCBiZSCh sHBlciByYW5nZaGxIHdoaWxlIKGwSWdub3JlIE92ZXJsYXChsSB3b3VsZCBiZSChsHBlciBwcmVm aXgvRkVDobEuIFNvIGl0IGlzIHRoZSBsYXR0ZXIgd2hpY2ggaXMgbW9yZSBjb21wbGV4IHRvIGlt cGxlbWVudC4NCltEZWNjYW5dIFlvdSBhcmUgcmlnaHQsIGFzIHBlciBwcmVmaXgvRkVDIGlzIGFj dHVhbGx5IHRvIHNwbGl0IHRoZSBvcmlnaW5hbCByYW5nZSB0byB0aGUgc21hbGxlc3Qgb25lcy4g TXkgbWVhbmluZyBpcyB0aGF0IHRoZXJlIGlzIG5vIHJhbmdlIGlkZWEgZHVyaW5nIGNvbmZsaWN0 IHByb2Nlc3MgcGhhc2UgYXQgdGhlIGNvbW1vbiBwbGFjZSwgYWxsIGlzIGRvbmUgYmFzZWQgb24g dGhlIGV4aXN0aW5nIGRhdGEgc3RydWN0dXJlIHBlciBwcmVmaXgvRkVDLiBNYXBwaW5nIHJhbmdl IG9ubHkgYXBwZWFyIGluIHRoZSBpbmRpdmlkdWFsIHByb3RvY29sIGluc3RhbmNlLCBidXQgaXQg aXMgYWx3YXlzIHRvIGJlIHNwbGl0IHRvIHRoZSBzbWFsbGVzdCBvbmVzLCBmb3IgcmEgZm9yIGNv bmZsaWN0IGZ1bmN0aW9uLg0KDQoyKSBUaGUgcmVzdHJpY3Rpb25zIGluIG5ldyBzZWN0aW9uICJT Y29wZSBvZiBTUi1NUExTIFNJRCBDb25mbGljdHMiIG1heWJlIG5vdCB0cnVlLiBQbGVhc2UganVz dCBjb25zaWRlciAiQ2FycmllciBvZiBDYXJyaWVyIiBjYXNlIHdoaWNoIGRlcGxveSBJR1ArTERQ IGJldHdlZW4gUEUgYW5kIENFLiBJdCBpcyBwb3NzaWJsZSB0byBkZXBsb3kgU1IgTFNQIGluIHRo ZSBzZWNvbmQgbGV2ZWwgY2Fycmllciwgc28gdGhhdCBhbiBTUiBMU1AgaXMgYnVpbGRpbmcgZnJv bSBvbmUgc2l0ZSB0byBhbm90aGVyIGFjcm9zcyB0aGUgZmlyc3QgbGV2ZWwgY2Fycmllciwgc2Ft ZSBhcyBhbiBMRFAgTFNQLiBUaGlzIG1lYW5zIFNJRHMgYXNzb2NpYXRlZCB3aXRoIGRlc3RpbmF0 aW9ucyBpbiBTaXRlIEEgd2lsbCBiZSBpbnN0YWxsZWQgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUg b2Ygcm91dGVycyBpbiBTaXRlIEIuDQoNCltMZXM6XSBXZSBoYXZlIGxvb2tlZCBhdCChsENhcnJp ZXIgb2YgQ2FycmllcqGxIGFuZCB3ZSBkaXNhZ3JlZSB3aXRoIHlvdXIgY29uY2x1c2lvbi4gVG8g cmVhY2ggZGVzdGluYXRpb25zIGluIFNpdGUgQiBmcm9tIFNpdGUgQSBwYWNrZXRzIHdpbGwgbmVl ZCB0byB0cmF2ZXJzZSB0aGUgUEUocykgY29ubmVjdGVkIHRvIFNpdGUgQS4gV2hhdCB3aWxsIGJl IGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBvZiByb3V0ZXJzIGluIFNpdGUgQSB3 aWxsIGJlIGxhYmVscyBhc3NvY2lhdGVkIHdpdGggdGhlIFNJRCBvZiB0aGUgUEUgqEMgbm90IHRo ZSBTSURzIGZvciBkZXN0aW5hdGlvbnMgaW4gU2l0ZSBCLiBJbiBmYWN0LCBpdCBpcyBwb3NzaWJs ZSBmb3IgZGVzdGluYXRpb24gMS4xLjEuMSBpbiBTaXRlIEEgdG8gdXNlIHRoZSBzYW1lIFNJRCBh cyBkZXN0aW5hdGlvbiAyLjIuMi4yIGluIFNpdGUgQi4gVGhpcyBpcyBkaXNjdXNzZWQgaW4gU2Vj dGlvbiA0IG9mIHRoZSBkcmFmdC4NCltEZWNjYW5dIFNvcnJ5LCBJIGNhbm5vdCB1bmRlcnN0YW5k IGhvdyB0byBmdWxmaWxsIHRoaXMgY2FzZSB5ZXQuIElNTywgcGFja2V0cyBmcm9tIHNpdGUgQSBu ZWVkIGNvbnRhaW4gU0lEcyBmb3IgZGVzdGluYXRpb25zIGluIHNpdGUgQiwgc28gdGhhdCBwYWNr ZXRzIGNhbiBmb3J3YXJkIHRvIHRoZSBzcGVjaWZpYyBkZXN0aW5hdGlvbiBjb3JyZWN0bHksIHRo ZSBTSUQgb2YgdGhlIFBFIGNhbiBvbmx5IGJlIHVzZWQgdG8gZm9yd2FyZCBwYWNrZXRzIHRvIHRo ZSBQRS4gQWx0aG91Z2gsIGF0IHRoZSBpbmdyZXNzIG5vZGUgaW4gc2l0ZSBBLCB3ZSBjYW4gZW5j YXBzdWxhdGUgU0lEIG9mIHRoZSBQRSBhZ2FpbiB0byBoaWRlIFNJRCBvZiBzaXRlIEIgYmVmb3Jl IHNlbmRpbmcgcGFja2V0cywgdGhlIGluZ3Jlc3Mgbm9kZSBpbiBzaXRlIEEgYW5kIHRoZSBQRSBu ZWVkIHN0aWxsIHNlZSB0aGUgU0lEIG9mIHNpdGUgQi4gQSBub2RlIGluIHNpdGUgQSBjYW4gbm90 IGVuc3VyZSBpdCB3aWxsIG9ubHkgYWN0IGFzIGEgdHJhbnNpdCByb2xlLiBDb3VsZCB5b3UgZXhw bGFpbiBtb3JlPw0KDQogICBMZXMNCg0KVGhhbmtzDQoNCkRlY2Nhbg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ug b2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVu dCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRp c3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwg cGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg cHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk IHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9y IG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQoN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhl cmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZv ciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0 cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRp YXRlbHkuDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz IGltbWVkaWF0ZWx5Lg0KDQoNCg0K --_000_cd2e332d6d0b479bb93be8dbf63cab9aXCHALN001ciscocom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Deccan =A8C

 <= /p>

There is a distinction be= tween what labels may be included in the encapsulation for a packet and wha= t labels will be =A1=B0top of stack=A1=B1. It is only the latter which gets installed in the forwarding plane.

 <= /p>

To reach destinations in = Site B from a node in Site A the packet has to be sent to a CE in site B vi= a a PE accessible to nodes in Site A. So encapsulation to a destination Z in site B would look like:

 <= /p>

  Label for CE-B ass= igned by PE-A

  Label for Destinat= ion Z

 <= /p>

Nodes in Site A will neve= r POP the top label =A8C so they will never receive a packet addressed to Z= where the top label is =A1=B0Z=A1=B1. Any label (or the SID used to derive it) that won=A1=AFt be top of stack in Site A is not part of the da= tabase used for conflict resolution in Site A.

 <= /p>

Note that this is standar= d MPLS forwarding behavior for this deployment =A8C the use of SR has not c= hanged this in any way.

 <= /p>

   Les

 <= /p>

 <= /p>

 <= /p>

From: peng.sha= ofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn]
Sent: Monday, July 04, 2016 8:57 PM
To: Robert Raszuk
Cc: Les Ginsberg (ginsberg); rraszuk@gmail.com; spring@ietf.org
Subject: =B4= =F0=B8=B4: Re: [spring] =B4=F0=B8=B4<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">: RE: draft-ietf-spring-conflict-resolution

 

Hi Robert,=

I think it is better to add more description to section 4 to eli= minate confusion. Now we only get a "statement" that there is no = problem, but not how. For example, if separate "contexts" in data plane as you said is a suggestion method to fulfill this case? Note that I= LM corresponding to SR label has no "contexts" in data plane curr= ently.

Let's first concern issues in control plane.
Supposed that there are site A,B,C attaching to provider network= through PE1,PE2,PE3 respectively, and A,B,C belong to same vrf network. Su= pposed that destination 1.1.1.1 in site A, 2.2.2.2 in site B, 3.3.3.3 in site C assign the same prefix-sid.
Because I have no entire idea about the solution behind section = 4, I just list the questions as following:

1) PE1's BGP will receive VPNv4 prefix(2.2.2.2) from PE2 with pr= efix-sid same as VPNv4 prefix(3.3.3.3) from PE3, does it do conflict proces= s in this phase?
2) PE1's BGP will import VPNv4 route to local vrf, so in the sam= e VPN routing table, prefix(2.2.2.2) and prefix(3.3.3.3) have the same pref= ix-sid, does it do conflict process in this phase?
3) PE1's IGP will redistribute BGP routes in the vrf, so IGP wil= l also see two prefixes have the same prefix-sid, does it do conflict proce= ss in this phase?
4) Each router in site A will receive perfix flood, so at each r= outer its IGP will also see two prefixes have the same prefix-sid, does it = do conflict process in this phase?


Thanks

Deccan




Robert Raszuk <robert@raszuk.net>
=B7=A2=BC=FE=C8=CB:  rraszuk@gmail.com

2016-07-04 16:00

=CA=D5=BC=FE=C8=CB<= /p>

= peng.shaofu@zte.com.cn,

=B3=AD=CB=CD

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "spring@ietf.org" <spring@ietf.org>

=D6=F7=CC=E2

Re: [spring] =B4=F0=B8=B4: RE: draft-ietf-spring-conflict-resolution

 




Hi Peng,

On the point #2 you are right that externally received SIDs will= be installed in the data plane of PEs. 

However you need to observe that they will be installed in compl= etely separate "contexts" in data plane hence current addition (a= fter I brought this issue few weeks back) has been accurately addressed in new sections 3.2.6 and 4. 

All what you are saying is true and the  current draft enab= les one to do that yet to keep consistent base topology in the network. Wel= l modulo comments from Bruno which have not been yet well addressed. <= /span>

Cheers,
R.


On Mon, Jul 4, 2016 at 4:32 AM, <peng.shaofu@zte.com.cn> wrote:
Les,

See inline.




"Les Ginsberg (ginsberg)" <= ;ginsberg@cisco.com>

2016-07-02 01:13

 

=CA=D5=BC=FE=C8=CB<= /p>

"peng.shaofu@zte.com.cn<= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f"">" <peng.shaofu@zte.com.cn>,

=B3=AD=CB=CD

"spring@ietf.org"= ; <= spring@ietf.org>

=D6=F7=CC=E2

RE: [spring] draft-ietf-spring-conflict-re= solution

 





Deccan -
 
From: peng.shaofu@zte.com.cn [mailto:peng.shaofu@z= te.com.cn]
Sent: Friday, July 01, 2016 2:46 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-res= olution <= br>  
His Les,

1) From implementation, because preference algorithm is protocol independen= t, it is better to do conflict resolution at a common place, not at individ= ual protocol instance. For example, we can do prefix-conflict resolution wh= en generate the preference FIB entry at the common place. For a preference FIB entry, the routing information m= ay get from OSPF by administrative distance, but the SID information may ge= t from ISIS by prefix-conflict algorithm. Then we can do sid-conflict resol= ution when generate the SID-LIB entry according to the above FIB entry and other sources, it will select a= preference FEC to provide forwarding information.
So, preference algorithm per prefix/fec is enough. Per range is possible, b= ut implementation is complex. More complex is for "ignor overlay"= per range.

[Les:] Implementation-wise, you are free to implement this in any module yo= u like so long as with the same database you come up with the same answer a= s other nodes in the network.
The distinction between =A1=B0Quarantine=A1=B1 and =A1=B0Ignore Overlap=A1= =B1 is that the latter attempts to use those portions of a range which do n= ot have conflicts with other entries. The cost of doing so is having to cre= ate =A1=B0derived entries=A1=B1 which represent those sub-ranges which do/do not have conflicts. Due to the added complexity this is NOT th= e first choice of the authors.
If I were to categorize the two algorithms using your terminology =A1=B0Qua= rantine=A1=B1 would be =A1=B0per range=A1=B1 while =A1=B0Ignore Overlap=A1= =B1 would be =A1=B0per prefix/FEC=A1=B1. So it is the latter which is more = complex to implement.
[Deccan] You are right, as per prefix/FEC is actually to split the original= range to the smallest ones. My meaning is that there is no range idea duri= ng conflict process phase at the common place, all is done based on the exi= sting data structure per prefix/FEC. Mapping range only appear in the individual protocol instance, but it is a= lways to be split to the smallest ones, for ra for conflict function.

2) The restrictions in new section "Scope of SR-MPLS SID Conflicts&quo= t; maybe not true. Please just consider "Carrier of Carrier" case= which deploy IGP+LDP between PE and CE. It is possible to deploy SR LS= P in the second level carrier, so that an SR LSP is building from one site to another across the first level carrier, same as an LDP LS= P. This means SIDs associated with destinations in Site A will be installed= in the forwarding plane of routers in Site B.

[Les:] We have looked at =A1=B0Carrier of Carrier=A1=B1 and we disagree wit= h your conclusion. To reach destinations in Site B from Site A packets will= need to traverse the PE(s) connected to Site A. What will be installed in = the forwarding plane of routers in Site A will be labels associated with the SID of the PE =A8C not the SIDs for des= tinations in Site B. In fact, it is possible for destination 1.1.1.1 in Sit= e A to use the same SID as destination 2.2.2.2 in Site B. This is discussed= in Section 4 of the draft.
[Deccan] Sorry, I cannot understand how to fulfill this case yet. IMO, packets from site A need contain SIDs for destinations = in site B, so that packets can forward to the specific destination correctly, the SID of the PE can only be used to forward = packets to the PE. Although, at the ingress node in site A, we can encapsul= ate SID of the PE again to hide SID of site B before sending packets, the ingress node in site A and the PE need still see the SID of s= ite B. A node in site A can not ensure it will only act as a transit role. = Could you explain more?

   Les

Thanks

Deccan
 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s).  If you are not = an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the informatio= n contained is strictly prohibited.  If you have received this mail in= error, please delete it and notify us immediately.
 
 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail= (and any attachment transmitted herewith) is privileged and confidential a= nd is intended for the exclusive use of the addressee(s).  If you are = not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the informatio= n contained is strictly prohibited.  If you have received this mail in= error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail= (and any attachment transmitted herewith) is privileged and confidential a= nd is intended for the exclusive use of the addressee(s).  If you are = not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the informatio= n contained is strictly prohibited.  If you have received this mail in= error, please delete it and notify us immediately.




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


 
-------------------------------------------=
-------------
ZTE Information Security Notice: The inform=
ation contained in this mail (and any attachment transmitted herewith) is p=
rivileged and confidential and is intended for the exclusive use of the add=
ressee(s).  If you are not an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or use of the information con=
tained is strictly prohibited.  If you have received this mail in erro=
r, please delete it and notify us immediately.
 

 

--_000_cd2e332d6d0b479bb93be8dbf63cab9aXCHALN001ciscocom_-- From nobody Tue Jul 5 00:08:38 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E928C12B05F for ; Tue, 5 Jul 2016 00:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqZyioXtbboh for ; Tue, 5 Jul 2016 00:08:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3346612D14F for ; Tue, 5 Jul 2016 00:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113901; q=dns/txt; s=iport; t=1467702510; x=1468912110; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KXKYh3Yl+A8w3wHAKCSJV9rohMLBg7nc1RAhF9ti+5s=; b=XuzPF1+WUyvUUAOVgBzQ7BxvE0Fwgyy0RvE7WuKqxXJsFep7oGclek4i eT2bnMKj1xeAGvsTTuusQ9mGuv1usYuAChzh2x/dleUDSlC5T/lZ5tORb KRFXLMW/9N5lbRaG0KdF+48ULPSFgN4z5A6LVNHzNB0FbAM6w429HMdIo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQCfXHtX/49dJa1cgnBOVnwGuTyBd?= =?us-ascii?q?4YYAoE+OBQBAQEBAQEBZRwLhEwBAQQBGgESTAULAgEIEQQBASEBBgcyFAkIAgQ?= =?us-ascii?q?OBQiIIAi5JAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4NKgQOEEhEBBkIKhSUFh?= =?us-ascii?q?geCE4YihR2FOgGJAoJygkuBcYRWiGqMIx6DSAEeNoIIBReBTG6HRDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,578,1459814400"; d="scan'208,217";a="293508681" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 07:08:24 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6578O9E001359 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 07:08:24 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 02:08:23 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 02:08:23 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwAAFyNVQACk7FpAAGrmsQACp0a4wACubJnA= Date: Tue, 5 Jul 2016 07:08:23 +0000 Message-ID: <91fcbdba712143e890609f6a513f8528@XCH-ALN-001.cisco.com> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.5.100] Content-Type: multipart/alternative; boundary="_000_91fcbdba712143e890609f6a513f8528XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 07:08:37 -0000 --_000_91fcbdba712143e890609f6a513f8528XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - Consider the following simple case: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2: (SRMS, 1.1.1.1/32, 200, 10, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) There is a misconfiguration here, but we don't know what was really intende= d. A few (of many) possibilities: ERROR #1: Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !St= arting SID error ERROR #2: Entry #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Sta= rting prefix error The draft defines two candidate preference rules which could be applied: Quarantine ---------------- As we evaluate prefix conflicts first, we compare Entry #1 and Entry #2 and= choose Entry #1 the winner (source is PFX). Entry #2 is then not used (qua= rantined) and the set of active entries is: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) Ignore Conflict Only ------------------------- In this case we split Entry #2 into two derived entries: Entry #2A: (SRMS, 1.1.1.1/32, 200, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry 2A is then ignored and we then have to evaluate SID conflicts between= the derived entry 2B and Entry #3. For this we have to split Entry 3 into= two derived entries: Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Entry #3B: (SRMS, 2.2.2.3/32, 201, 9. 0, 0) Entry 2B wins over entry 3B since it has a smaller range. Active entries are then: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Note that in this example both preference rules result in 11 destinations h= aving non-conflicting SIDs. Now, which of these maximizes delivery of traf= fic? The answer to that depends upon the type of configuration error that w= as made. If Error #1 was made, there is no way to differentiate the two preference r= ules. However, if Error #2 was made, then Quarantine is clearly better because th= e destinations 1.1.1.2 - 1.1.1.10 were never intended to have assigned SIDs= and may not even exist as destinations in the network, yet "Ignore Conflic= t Only" favors those prefixes. The point I am trying to make is that it is incorrect to say "If we maximiz= e the number of advertised entries which we use we will always do a better = job of delivering traffic." This example illustrates that this isn't always= true. A few more comments inline. From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Monday, July 04, 2016 5:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 3:12 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I don't find your representation complete as regards all of the attributes = which are proposed to be used by the conflict resolution algorithm - so it = is therefore hard for me to use/understand this representation when applyin= g the defined preference rule. This is true for me even after reading your explanations below. But it is far more important to have a common understanding of the algorith= m proposal than it is to be arguing over whose encoding is "better". If the= encoding in the draft is not clear or could use improvement, I welcome you= r feedback. As far as your "pseudo-code": - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID The fact that you can represent an algorithm in a few lines does not mean t= he implementation of the algorithm is just as simple. [Bruno] Sure. But if we want to compare implementation complexity, we'll ne= ed to agree on how much we want to go into details, in order to have meanin= gful comparison. So far this is not clear to me as you sometimes argue that= data structure is implementation specific and you don't want to go into th= is (which I agree) and sometime you detail the data structure. There is also the option to consider this as "implementation issue" and let= this to implementations. Coming back to my per FEC algo, all what is required from the data structur= e, is a way/API to get the data back, though 2 keys: get me the SID matchin= g prefix P1 (for the first line), get me the prefixes matching the SID SIDi= for the second line. That seem like a reasonable requirement on the data s= tructure, and any option in your draft also requires this to detect prefix = conflict and SID conflict (since this is all my per FEC algo is doing in th= ese 2 first lines). Going into more details, my per FEC algo only requires to detail that one p= refix or SID belong to a range (of prefix or SID) while your per range algo= requires to compute range intersection which is harder. So the API to fetc= h the data can only be easier. [Les:] Range intersection is easy to compute - the algorithm is present in = the draft at the end of Section 3.1.1. Consider what needs to be done to implement "Find all SIDi advertised for the prefix P1" In its simplest form, we have a list of all SID advertisements (PFX and SRM= S) that we have received. One could imagine walking all the entries, lookin= g to see if the prefix of interest is present within the advertised range. = But, of course, at large scale such an approach is extremely inefficient - = so we immediately start considering ways to improve performance. Inserting = received entries into an ordered tree of some kind is an obvious way to imp= rove performance. When one further considers that calculating conflict reso= lution only needs to be done when a change to the received database occurs = (which post startup is infrequent) it becomes very attractive to cache the = "winning entries" so that if one wants to retrieve the SID for a given pref= ix we only have to examine a subset of the total database - ignoring the lo= sers. [Bruno] I agree that the per range algo (ignore overlap only) will be able = to ignore the losers but at the cost of a more complex algo and at the cost= of creating new derived entries. It's not clear to me if the net result is= positive. Plus I would expect that the number of conflit is small compared= to the number of prefix /SID so this looks like a second order optimizatio= n. In this context, we can appreciate the difference between the three propose= d algorithms. In particular comparing "Quarantine" with "ignore overlap onl= y", a key difference is that "Quarantine" only needs to determine whether a= received entry is a winning entry or a losing entry. "Ignore overlap only"= has to be capable of breaking received entries with ranges > 1 into multip= le "derived" entries (some winning, some losing), which means we now need t= o track the "derived entries" against the original received entry so that i= f the received entry is updated/deleted we can find all the derived entries= and delete/regenerate the derived entries as needed. This is what adds com= plexity. [Bruno] and that it why the per FEC algo seems easier. So it would seem useful to add it in the draft so that we can all discuss i= t. [Les:] Ignore overlap only is the same as per FEC. We may use different wor= ds to describe it, but the end behavior is the same. Les All proposed algorithms can be implemented, but it does seem prudent to con= sider implementation complexity as part of our decision process - and the d= iscussion/examples in Section 3 are meant to help in doing this. It is worthwhile restating that when conflicts are present we cannot guaran= tee that forwarding will work correctly no matter what algorithm is used. [Bruno] I'm not sure to see what you have in mind exactly. Can you elaborat= e? To me consistency seem enough. The more complex the implementation the more likely it is that bugs will b= e present and the more likely it is that interoperability issues will arise= . Whether these costs/risks are worth the "value add" when the outcome cann= ot be guaranteed to be correct - only guaranteed to be consistent - is an i= mportant consideration. Also important to remember that conflicts MUST be eliminated by correcting = the misconfigurations that caused them - so conflict resolution is really o= nly an interim measure until the corrections can be made. [Bruno] By "interim" we are at minimum talking about 10s of minutes, if not= more than 1 hour since identifying the root cause may not be obvious. The = impact is very significant on the network. The "Quarantine" algo has the potential to kill 100s PE and 1000s of VPN cu= stomers, so a single configuration change on a unrelated router which may n= ot even be in production (i.e. where configuration checks and operations ho= urs may be relaxed) No one should be lulled into thinking that because we have conflict resolut= ion deployed that correcting the configuration when conflicts are detected = is not a priority. [Bruno] I could not agree more that conflict needs to be identified and fix= ed. Note that I'm the one having asked for defining YANG notifications to r= eport this. You are welcomed to state in the draft that conflicts needs to be reported = to the network operator, in particular though yang notification, and other = existing means. Plus that network operator needs to fixed them ASAP (but st= ill carefully) Thanks --Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:00 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. [Bruno] I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there w= as a way to make progress by asking clarification questions on the points w= hich were not clear, or at least explicitly refusing to consider the email. I also note that what bothered you in my representation was my addition of = the type of advertisement (prefix or MS). But you finally have just added i= n the latest version of the draft "Src- PFX or SRMS" . So there was probabl= y a way to communicate. Besides the algo did not use any specification representation, just names. = So I'll copy/paste it below, please ask clarification questions for the par= ts which are not clear enough. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, for P1, we get a list of (SIDi, Pij) Get the best (SIDi, Pij) as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? [Bruno] - MS/prefix SID is the type of advertisement. In your new version, you call= it SRMS/PFX. - SID is the SID found in the Mapping Entrie - Rx is the loopback (prefix) or router Rx So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and= means: For prefix R2, we found a MS mapping entries advertising SID2 for t= his prefix, and then I found a MS mapping entries advertising prefix R2 for= SID2. Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . [Bruno] I agree that since the above algo used 2 mapping entries to provide= s the (SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted.= That being said, this is not important for this discussion. Let's just con= sidered that their exist a preference algorithm, which takes as input a lis= t of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition = of "best" is not pertinent) ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. [Bruno] Indeed, this is my expectation. But I would need someone's review t= o confirm this. But the difference is that the proposed algo is simple (2 lines of pseudo c= ode), with very modest resquirement data structure use to store the mapping= entries. Indeed, all it needs is a function returning the list of mapping = entries associated/matching a given prefix. And function returning the list= of mapping entries associated/matching a given SID. In particular, there is no need for splitting mapping entries which is the = main complexity of your proposed "Preference algorithm/ignore overlap only"= . (according to your own text). -- Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active"= : (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_91fcbdba712143e890609f6a513f8528XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

Consider the following= simple case:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2: (SRMS, 1.1.1= .1/32, 200, 10, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

There is a misconfigur= ation here, but we don’t know what was really intended. A few (of man= y) possibilities:

 

ERROR #1:   = Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !Starting SID e= rror

ERROR #2:  Entry = #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Starting prefix erro= r

 

The draft defines two = candidate preference rules which could be applied:

 

Quarantine<= /span>

----------------<= /o:p>

As we evaluate prefix = conflicts first, we compare Entry #1 and Entry #2 and choose Entry #1 the w= inner (source is PFX). Entry #2 is then not used (quarantined) and the set = of active entries is:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

Ignore Conflict Only

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

In this case we split = Entry #2 into two derived entries:

 

Entry #2A: (SRMS, 1.1.= 1.1/32, 200, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

 

Entry 2A is then ignor= ed and we then have to evaluate SID conflicts between the derived entry 2B = and Entry #3.  For this we have to split Entry 3 into two derived entr= ies:

 

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

Entry #3B: (SRMS, 2.2.= 2.3/32, 201, 9. 0, 0)

 

Entry 2B wins over ent= ry 3B since it has a smaller range.

 

Active entries are the= n:

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

 

Note that in this exam= ple both preference rules result in 11 destinations having non-conflicting = SIDs.  Now, which of these maximizes delivery of traffic? The answer t= o that depends upon the type of configuration error that was made.

If Error #1 was made, = there is no way to differentiate the two preference rules.

However, if Error #2 w= as made, then Quarantine is clearly better because the destinations 1.1.1.2= – 1.1.1.10 were never intended to have assigned SIDs and may not eve= n exist as destinations in the network, yet “Ignore Conflict Only” favors those prefixes.

 

The point I am trying = to make is that it is incorrect to say “If we maximize the number of = advertised entries which we use we will always do a better job of deliverin= g traffic.” This example illustrates that this isn’t always true.

 

A few more comments in= line.

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Please see inline [Bruno]

 = ;

 = ;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:12 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I don’t find you= r representation complete as regards all of the attributes which are propos= ed to be used by the conflict resolution algorithm – so it is therefo= re hard for me to use/understand this representation when applying the defined preference rule.

This is true for me ev= en after reading your explanations below.

 

But it is far more imp= ortant to have a common understanding of the algorithm proposal than it is = to be arguing over whose encoding is “better”. If the encoding = in the draft is not clear or could use improvement, I welcome your feedback.

 

As far as your “= pseudo-code”:

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

The fact that you can = represent an algorithm in a few lines does not mean the implementation of t= he algorithm is just as simple.

 

[Bruno] Sure. But if we want to compare implementati= on complexity, we’ll need to agree on how much we want to go into det= ails, in order to have meaningful comparison. So far this is not clear to m= e as you sometimes argue that data structure is implementation specific and you don’t want to go into this (which= I agree) and sometime you detail the data structure.

There is also the option to consider this as “= implementation issue” and let this to implementations.

 

Coming back to my per FEC algo, all what is required= from the data structure, is a way/API to get the data back, though 2 keys:= get me the SID matching prefix P1 (for the first line), get me the prefixe= s matching the SID SIDi for the second line. That seem like a reasonable requirement on the data structure, and a= ny option in your draft also requires this to detect prefix conflict and SI= D conflict (since this is all my per FEC algo is doing in these 2 first lin= es).

 

Going into more details, my per FEC algo only requir= es to detail that one prefix or SID belong to a range (of prefix or SID) wh= ile your per range algo requires to compute range intersection which is har= der. So the API to fetch the data can only be easier.

 

 

[Les:] Range int= ersection is easy to compute – the algorithm is present in the draft = at the end of  Section 3.1.1.

 

Consider what needs to= be done to implement

 

   “Fi= nd all SIDi advertised for the prefix P1”

 

In its simplest form, = we have a list of all SID advertisements (PFX and SRMS) that we have receiv= ed. One could imagine walking all the entries, looking to see if the prefix= of interest is present within the advertised range. But, of course, at large scale such an approach is extremely ineffi= cient – so we immediately start considering ways to improve performan= ce. Inserting received entries into an ordered tree of some kind is an obvi= ous way to improve performance. When one further considers that calculating conflict resolution only needs to be do= ne when a change to the received database occurs (which post startup is inf= requent) it becomes very attractive to cache the “winning entriesR= 21; so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database = – ignoring the losers.

[Bruno] I agree that the per range algo (ignore over= lap only) will be able to ignore the losers but at the cost of a more compl= ex algo and at the cost of creating new derived entries. It’s not cle= ar to me if the net result is positive. Plus I would expect that the number of conflit is small compared to the nu= mber of prefix /SID so this looks like a second order optimization.

 

In this context, we ca= n appreciate the difference between the three proposed algorithms. In parti= cular comparing “Quarantine” with “ignore overlap only= 221;, a key difference is that “Quarantine” only needs to deter= mine whether a received entry is a winning entry or a losing entry. “Igno= re overlap only” has to be capable of breaking received entries with = ranges > 1 into multiple “derived” entries (some winning, so= me losing), which means we now need to track the “derived entriesR= 21; against the original received entry so that if the received entry is updat= ed/deleted we can find all the derived entries and delete/regenerate the de= rived entries as needed. This is what adds complexity.

[Bruno] and that it why the per FEC algo seems easie= r.

So it would seem useful to add it in the draft so th= at we can all discuss it.

 

[Les:] Ignore ov= erlap only is the same as per FEC. We may use different words to describe i= t, but the end behavior is the same.

 

   Les=

 

 

All proposed algorithm= s can be implemented, but it does seem prudent to consider implementation c= omplexity as part of our decision process – and the discussion/exampl= es in Section 3 are meant to help in doing this.

 

It is worthwhile resta= ting that when conflicts are present we cannot guarantee that forwarding wi= ll work correctly no matter what algorithm is used.

[Bruno] I’m not sure to see what you have in m= ind exactly. Can you elaborate? To me consistency seem enough.

 The more complex= the implementation the more likely it is that bugs will be present and the= more likely it is that interoperability issues will arise. Whether these c= osts/risks are worth the “value add” when the outcome cannot be guaranteed to be correct – only guaranteed to = be consistent – is an important consideration.

 

Also important to reme= mber that conflicts MUST be eliminated by correcting the misconfigurations = that caused them – so conflict resolution is really only an interim m= easure until the corrections can be made.

[Bruno] By “interim” we are at minimum t= alking about 10s of minutes, if not more than 1 hour since identifying the = root cause may not be obvious. The impact is very significant on the networ= k.

The “Quarantine” algo has the potential = to kill 100s PE and 1000s of VPN customers, so a single configuration chang= e on a unrelated router which may not even be in production (i.e. where con= figuration checks and operations hours may be relaxed)

 

 

No one should be lulle= d into thinking that because we have conflict resolution deployed that corr= ecting the configuration when conflicts are detected is not a priority.

[Bruno] I could not agree more that conflict needs t= o be identified and fixed. Note that I’m the one having asked for def= ining YANG notifications to report this.

You are welcomed to state in the draft that conflict= s needs to be reported to the network operator, in particular though yang n= otification, and other existing means. Plus that network operator needs to = fixed them ASAP (but still carefully)

 

Thanks

--Bruno

 

   Les<= /o:p>

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,<= /o:p>

 = ;

Thanks for the discuss= ion. Please see inline [Bruno]

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

As the thread below do= cuments, I stated that I did not understand your representation and asked f= or clarification – suggesting that you use the format defined in the = draft.

You stated that you co= uld not do that and we were at a point where no progress could be made.

[Bruno] I could _no= t_ use your format since your format did not include the information ne= ed. This is not a whim but a technical issue. So I asked you to still consi= der the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification q= uestions on the points which were not clear, or at least explicitly refusin= g to consider the email.

I also note that what bothered you in my=
 representation was my addition of the type of advertisement (prefix or MS)=
. But you finally have just added in the latest version of the draft “=
; . So there w=
as probably a way to communicate.

 

 

Besides the algo did n= ot use any specification representation, just names. So I’ll copy/pas= te it below, please ask clarification questions for the parts which are not= clear enough.

 

The problem that we ne= ed to solve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advert= ised for the prefix P1         = ;            &n= bsp;            = ;            &n= bsp;            // i= dentification of Prefix conflicts

   &nbs= p;            - For = each SIDi find all the prefix Pij associated with SIDi   &nb= sp;          // identification= of SID conflicts

 

// as a result, for P1= , we get a list of (SIDi, Pij)

 

Get the best (SIDi, Pi= j) as per the preference algorithm.

If best Pij =3D=3D P1<= o:p>

   &nbs= p;            then u= se SIDij for P1

   &nbs= p;            else r= eturn no SID          &nb= sp;            =    / no SID available for this prefix P1

 

 

 

To illustrate my confu= sion, one of your examples is:

 

For R2, the algo evaluates a conflict between the following advertismen= ts:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

 

Now, what does “= R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]

- MS/prefix SID is the= type of advertisement. In your new version, you call it SRMS/PFX.

- SID is the SID found= in the Mapping Entrie

- Rx is the loopback (= prefix) or router Rx

 

So “R2 - SID2 - R2 (MS, MS)” is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

 

Does it mean  = 220;On R2, SID2 is assigned to prefix R2 from two different mapping server = entries?” I really have no idea.

 

And you conclude the e= xample by saying

 

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID))

   =3D=3D> SID12 is selected for R2.=

 

But since there is no = representation of “range” in your examples I really have no ide= a how you came to this conclusion .

[Bruno] I agree that s= ince the above algo used 2 mapping entries to provides the (SIDi, Pij), the= preference algo (=A73.2.4) would need to be adapted. That being said, this= is not important for this discussion. Let’s just considered that their exist a preference algorithm, which= takes as input a list of (SIDi, Piij) for P1, and gives as outpout the = 220;best” one. (definition of “best” is not pertinent)

 

 

??

 

As regards “per = FEC/Prefix”, I believe this is what “ignore overlap only”= does.

[Bruno] Indeed, this i= s my expectation. But I would need someone’s review to confirm this.<= o:p>

But the difference is = that the proposed algo is simple (2 lines of pseudo code), with very modest= resquirement data structure use to store the mapping entries. Indeed, all = it needs is a function returning the list of mapping entries associated/matching a given prefix. And function r= eturning the list of mapping entries associated/matching a given SID.<= /o:p>

In particular, there i= s no need for splitting mapping entries which is the main complexity of you= r proposed “Preference algorithm/ignore overlap only”. (accordi= ng to your own text).

 

-- Bruno

 

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,<= /o:p>

 = ;

Thanks for the updated= draft.

 

IINM, you have not ans= wered my below email/proposal. I had waited for the new version of the draf= t but it also does not touch this subject.

 

So, could you please c= onsider and answer my comment?

 

In short, in an implem= entation-independent sentence:

 

> I'm wondering if we could address the conflict = on a per FEC/Prefix basis rather than on a per IGP advertisement (range) ba= sis.

> If so, this may avoid the discussion between th= e Quarantine vs ignore policy.

 

 

Thanks

Bruno

 

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce.

[Bruno] My text does not incorporate the source, but= the type of source IOW the type of sub-TLV.

 

So it does not matter = if R2 sends an advertisement or R12 sends advertisement or both of them do = (which could happen when an advertisement is leaked) – what matters i= s what unique entries are in the database independent of source.

[Bruno] It may not matter for your algorithm (pendin= g another thread), but it does for the one I proposed.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

[Bruno] My examples are described in plain text. The= n the examples giving intermediate steps of my algo uses the data that are = needed i.e. the type of advertisement (Prefix-SID vs MS).

Then finally, my algo runs on a per FEC/IP Prefix ba= sis, and not on a per IGP advertisement basis which your format describe.

So I’m sorry but I don’t see how to indu= lge your request.

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /i>

     Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

     Pe =3D (Pi + ((= R-1) << (Lx-L))

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

this to me specifies a= n implementation – which isn’t necessary.

[Bruno] Well, _you_ are the one talking about= implementation, and more specifically implementation complexity.

Assuming the above algo works, it looks relatively s= imple to implement, in which case, I would not buy the argument about imple= mentation complexity which is the only argument in favor or the “igno= re” or “quarantine” policy.

Bottom line, I would welcome your feedback and comme= nts on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

 

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:=

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:<= /o:p>

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_91fcbdba712143e890609f6a513f8528XCHALN001ciscocom_-- From nobody Tue Jul 5 00:20:06 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE7C12B013 for ; Tue, 5 Jul 2016 00:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgdX07x9Qzf3 for ; Tue, 5 Jul 2016 00:19:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC2D12B05F for ; Tue, 5 Jul 2016 00:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84995; q=dns/txt; s=iport; t=1467703198; x=1468912798; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J3oajtCryCewRF2Szws5OMEEOt2ozRhMs6GFoyinCzE=; b=TaOpwpfmo5kBo1pWdoYiynHyq8RpkhbPMg+Xuyo0Z38MjnvZ5bnCTmsx OrHwlCni+XWn7f+ZD8bH74wmbmnzYt/hwbRGDnOa10gWeTt373p4UpF66 jUV5DKBunDmsa51LH3sEeOXdLeez/AfLdnVJ2GIpCwn0bHO7sO3DoRPfK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQDJXntX/5JdJa1cgnBOVnwGuTyBd?= =?us-ascii?q?yKFdgKBPzgUAQEBAQEBAWUcC4RMAQEEAQwOARJMBQsCAQgRBAEBFgsBBgcyFAk?= =?us-ascii?q?IAgQOBQiIIAgOuRcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYng0qBA4QSCgcBB?= =?us-ascii?q?kwJhRwFjjyFCBWFOgGGCIJ6hT2BcYRWgy57hEGQCQEeNoIIHIFMbgEBhzMPFx9?= =?us-ascii?q?/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,578,1459814400"; d="scan'208,217";a="125064455" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 07:19:54 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u657JsV3013291 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 07:19:54 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 02:19:53 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 02:19:53 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACPs+VAAIaJeEACo/YOgACyjGFA= Date: Tue, 5 Jul 2016 07:19:53 +0000 Message-ID: <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.5.100] Content-Type: multipart/alternative; boundary="_000_269896ae1e214e9295130d1999b614c0XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 07:20:05 -0000 --_000_269896ae1e214e9295130d1999b614c0XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - SR-MPLS utilizes existing MPLS forwarding behavior without change. In this = model, the received label serves as the forwarding instruction for the pack= et. This means that if two packets are received for the same destination bu= t we want the packet to follow two different forwarding "topologies", then = we need to have two different labels. One can imagine a different model, where the forwarding instruction is deri= ved from the label AND some other attribute of the packet - and the latter = could be used to select a forwarding topology. However, this is not existin= g MPLS forwarding behavior and since SR explicitly utilizes the existing MP= LS forwarding behavior we not propose any extensions. This is why different SIDs are required for the same destination in differe= nt topologies. Les From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Monday, July 04, 2016 5:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Les, Please see inline [Bruno3] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 3:36 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:19 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) [Bruno] IOW, the draft does not resolve SID conflict if all routers do not = receive exactly the same set of advertisement from all routing protocols. That's indeed can be a valid simplification if the WG choose to, but this s= hould clearly be indicated in the document, in a section targeting network = operator since this point will need to be read and enforced by network oper= ator rather than protocol implementors. =A73.2.8 already partly address thi= s, but IMO a text clearly expressing the requirements on network operator w= ould be useful. [Les2:] No policy can guarantee consistent results network wide if the data= bases on different nodes are inconsistent. This isn't a "simplification" - = it is a fact. As you point out, Section 3.2.8 already states: "In order to obtain consistent active entries all nodes in a network MUST have the same mapping entry database." If you believe this is not explicit enough please suggest some text. [Bruno3] Section 4 Manageability Considerations Detecting and resolving conflicts in a consistent way requires that all nod= es consider the same set of SIDs advertisements. Network operations should = be aware that the conflict resolution algorithm defined in this document wi= ll not succeed in selecting a consistent resolution across all nodes, if al= l nodes do not receive the exact same set of SIDs advertisements. This may = be in particular the case when multiple IGP instances are used and all rout= ers do not participate in the same set of IGP instances. This may occurs fo= r example if one network transition from one IGP protocol to another IGP (e= .g. from OSPFv2 to IS-IS). This may also happen if IGP areas/level are used= and SIDs are not flooded in all areas/levels. One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. [Bruno] IOW, don't make configuration errors ;-) Are you implying that the SRMS configuration (hence yang model) should be p= er node rather than per protocol? or at least should be configurable by nod= e (and possibly also by protocols) [Les2:] My point is (humorous ideas aside...) that if a deployment uses mul= tiple protocols, the easiest way to guarantee that the SID mapping database= on all nodes in the network is consistent is to restrict SID advertisement= s to SRMS advertisements. [Bruno3] Clearly, the fewer the number of advertisements for a given prefix= , the less change of conflict. But I fail to see why only using SRMS guarantee anything. e.g. if different= nodes use a different set of routing protocols, you have conflicts. Idem i= f the misconfiguration consist in adding a SID to a IGP prefix (PFX adverti= sement) A small number of nodes (as few as 1 - more if redundancy is desired) are s= etup as mapping servers and all SIDs which are required network-wide are co= nfigured on these nodes and advertised by the protocol instance(s) on that = node. In this way it is not necessary to guarantee that all prefix reachabi= lity from all of the protocol instances running in the network are present = in all the protocol instance sub-domains which exist - it is only necessary= to insure that all protocol instances advertise the same set of SRMS entri= es. [Bruno3] In the end, this gets back to requiring no configuration mistakes. It isn't the only way to support this - but it is likely to be the simplest= and least error prone. In any case this isn't a requirement - it was a res= ponse to your question as to how it might be possible to get consistent SID= mapping databases on all nodes in such a case. This is no way changes how = the YANG model is defined. SRMS config is always node specific. If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. [Bruno]There is also the point of configuring different SRGB space in diffe= rent IGP protocols. In which case, SIDs may conflict but this is not an iss= ue as label will not conflict. We stopped short of that in this revision because we felt there were enough= substantive changes and points on which consensus is still a work in progr= ess that it would not be the optimal way forward. [Bruno] +1 and thanks. Releasing an updated version has been useful to re-i= nitiate the discussion. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. [Bruno] Well, the some prefix/routing consistency is also required for IP p= refixes. When then same IP prefix is advertised in different IGPs, admin di= stance is a common existing way to define which routing protocol takes prec= edence. I'm not sure why it should not also be taken into consideration for= SR Prefix conflits [Les2:] Please see my response to Stephane on the same point. I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. [Bruno] Question was that, at a very/too high level, the issue of conflict = across topology seems close to the issue of conflict across routing protoco= ls: we have different topologies. Hence a na=EFve question: how exactly is= this different. One part of the answer, is the simplification proposed when multiple protoc= ols is used (i.e. your first answer above). Another part is that for multi-topology, compared to multi-protocols, all i= nformation from all topologies are flooded to all nodes. Another part is the forwarding model used for Multi-Topology. In general, h= ttps://tools.ietf.org/html/rfc5120#section-8 seems to assume that each topo= logy has one dedicated RIB/FIB. In such condition, there is no conflict (pr= efix or SID) so no need to detect and resolve conflict. So here there may b= e different models and eventually, we don't 'have the same one in mind. In a lesser extend, even for multi-protocols, we may have those multiple fo= rwarding models. To some extent, this seems related to the definition of "S= R domain". e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be thi= s is something that needs to be configurable [Les2:] Please reread Section 3.1.2. While there are no "Prefix-conflicts" = across topologies, there are "SID Conflicts". This is important to understa= nd. [Bruno3] Conflicts are related to a forwarding context i.e. FIB. This is eq= ually important to understand. Please read https://tools.ietf.org/html/rfc5= 120#section-8.2.2 and 8.2.1 to see that topologies may not share the same f= orwarding context hence do not conflict in term of prefix & SID. --Bruno As regards multiple protocols operating in the same topology, from a forwar= ding perspective we do not care what protocol is the winning route. What we= care about is that our nexthop has chosen the same SID for a given prefix.= This is why "source" is deliberately excluded from consideration by the co= nflict resolution algorithm. Les Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_269896ae1e214e9295130d1999b614c0XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

SR-MPLS utilizes exist= ing MPLS forwarding behavior without change. In this model, the received la= bel serves as the forwarding instruction for the packet. This means that if= two packets are received for the same destination but we want the packet to follow two different forwarding R= 20;topologies”, then we need to have two different labels.=

 

One can imagine a diff= erent model, where the forwarding instruction is derived from the label AND= some other attribute of the packet – and the latter could be used to= select a forwarding topology. However, this is not existing MPLS forwarding behavior and since SR explicitly utilizes = the existing MPLS forwarding behavior we not propose any extensions.

 

This is why different = SIDs are required for the same destination in different topologies.

 

    Les=

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Les,<= /o:p>

 = ;

Please see= inline [Bruno3]

 = ;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:36 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

Inline.

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 = ;

Thanks for the discuss= ion. Please see inline [Bruno]

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 = ;

IINM, I’ve not s= een the follow up on one of my below questions.

So let me restate a co= mment:

 

The SR-MPLS SID confli= cts algo requires that all nodes consider the same mapping advertisements.<= o:p>

How is this ensured, i= f it indifferently considers advertisements from all protocols, while some = nodes could participate only in a subset of the protocols? e.g. OSPF only r= outers would consider a different set of information compared to OSPF+IS-IS routers.

 

[Les:] If you ru= n multiple protocol instances (whether multiple instances of the same proto= col or instances of different protocols) then you need to insure that at le= ast one of the two conditions below is true:

=B7         All routers re= ceive the equivalent set of advertisements

=B7         There are no c= onflicts J

 

[Bruno] IOW, the draft= does not resolve SID conflict if all routers do not receive exactly the sa= me set of advertisement from all routing protocols.

That’s indeed ca= n be a valid simplification if the WG choose to, but this should clearly be= indicated in the document, in a section targeting network operator since t= his point will need to be read and enforced by network operator rather than protocol implementors. =A73.2.8 already pa= rtly address this, but IMO a text clearly expressing the requirements on ne= twork operator would be useful.

 

[Les2:] No polic= y can guarantee consistent results network wide if the databases on differe= nt nodes are inconsistent. This isn’t a “simplification” = – it is a fact. As you point out, Section 3.2.8 already states:

 

“In order to obtain consistent active entries all nodes= in a network

   MUS= T have the same mapping entry database.”

 

If you believe this= is not explicit enough please suggest some text.

[Bruno3] <= o:p>

Section 4 Manageabilit= y Considerations

Detecting and resolvin= g conflicts in a consistent way requires that all nodes consider the same s= et of SIDs advertisements. Network operations should be aware that the conf= lict resolution algorithm defined in this document will not succeed in selecting a consistent resolution across= all nodes, if all nodes do not receive the exact same set of SIDs advertis= ements. This may be in particular the case when multiple IGP instances are = used and all routers do not participate in the same set of IGP instances. This may occurs for example if one netwo= rk transition from one IGP protocol to another IGP (e.g. from OSPFv2 to IS-= IS). This may also happen if IGP areas/level are used and SIDs are not floo= ded in all areas/levels.

 

 

One way of insuring= the first point is to exclusively use a mapping server to advertise SIDs, = configure your SRMS entries in a protocol independent manner, and insure th= at the SRMS advertisements are sent in all of the protocol instance specific sub-domains.

[Bruno] IOW, don’= ;t make configuration errors ;-)

Are you implying that = the SRMS configuration (hence yang model) should be per node rather than pe= r protocol? or at least should be configurable by node (and possibly also b= y protocols)<= /p>

 

[Les2:] My point= is (humorous ideas aside…) that if a deployment uses multiple protoc= ols, the easiest way to guarantee that the SID mapping database on all node= s in the network is consistent is to restrict SID advertisements to SRMS advertisements.

[Bruno3] Clearly, the = fewer the number of advertisements for a given prefix, the less change of c= onflict.

But I fail to see why = only using SRMS guarantee anything. e.g. if different nodes use a different= set of routing protocols, you have conflicts. Idem if the misconfiguration= consist in adding a SID to a IGP prefix (PFX advertisement)

 

 

A small number o= f nodes (as few as 1 – more if redundancy is desired) are setup as ma= pping servers and all SIDs which are required network-wide are configured o= n these nodes and advertised by the protocol instance(s) on that node. In this way it is not necessary to guarantee tha= t all prefix reachability from all of the protocol instances running in the= network are present in all the protocol instance sub-domains which exist &= #8211; it is only necessary to insure that all protocol instances advertise the same set of SRMS entries.=

[Bruno3] In the end, t= his gets back to requiring no configuration mistakes.<= /b>

It isn’t t= he only way to support this – but it is likely to be the simplest and= least error prone. In any case this isn’t a requirement – it w= as a response to your question as to how it might be possible to get consistent SID mapping databases on all nodes in such a case. This = is no way changes how the YANG model is defined. SRMS config is always node= specific.

 

 

If the intent is to= deliberately use different labels in the forwarding plane for the same des= tination depending upon which protocol advertised the prefix, this introduc= es a number of new requirements – not the least of which is duplicate entries for the same prefix in the forward= ing plane.  As has been discussed publicly in a different thread, ther= e are cases (e.g. merging two networks) were such a requirement may exist &= #8211; but it is the exception rather than the rule and as it consumes more resources in the forwarding plane and int= roduces implementation complexity independent of conflict resolution it is = not the primary case the draft focuses on. Nevertheless, this is a case whi= ch the draft will address in the next revision.

[Bruno]There is also t= he point of configuring different SRGB space in different IGP protocols. In= which case, SIDs may conflict but this is not an issue as label will not c= onflict.

We stopped short of= that in this revision because we felt there were enough substantive change= s and points on which consensus is still a work in progress that it would n= ot be the optimal way forward.

[Bruno] +1 and tha= nks. Releasing an updated version has been useful to re-initiate the discus= sion.

 

Thinking more about th= is, I guess that this is only important for the entries which are inserted = in the forwarding plane. Hence, in case of conflict between protocols, I th= ink that the preference algorithm should take into account the protocol preference (aka administrative distance). <= o:p>

 

[Les:] As admin = distance is neither an attribute of SRMS entries nor guaranteed to be consi= stent on all routers for all prefixes this is not a desirable approach.

[Bruno] Well, the some= prefix/routing consistency is also required for IP prefixes. When then sam= e IP prefix is advertised in different IGPs, admin distance is a common exi= sting way to define which routing protocol takes precedence. I’m not sure why it should not also be taken into = consideration for SR Prefix conflits

 

[Les2:] Please s= ee my response to Stephane on the same point.

 

I’m also not sur= e to see why is the problem different compared to Multi-Topology. Could you= please elaborate?

[Les:] I am uncl= ear what your question is. Are you asking why we need different SIDs in dif= ferent topologies? Please clarify.

[Bruno] Question was t= hat, at a very/too high level, the issue of conflict across topology seems = close to the issue of conflict across routing protocols:  we have diff= erent topologies. Hence a na=EFve question: how exactly is this different.

One part of the answer= , is the simplification proposed when multiple protocols is used (i.e. your= first answer above).

Another part is that f= or multi-topology, compared to multi-protocols, all information from all to= pologies are flooded to all nodes.

Another part is the fo= rwarding model used for Multi-Topology. In general, https://tools.iet= f.org/html/rfc5120#section-8 seems to assume that each topology has= one dedicated RIB/FIB. In such condition, there is no conflict (prefix or = SID) so no need to detect and resolve conflict. So here there may be differ= ent models and eventually, we don’t ‘have the same one in mind.

In a lesser extend, ev= en for multi-protocols, we may have those multiple forwarding models. To so= me extent, this seems related to the definition of “SR domain”.= e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be this is something that needs to be configurable

 

 

[Les2:] Please r= eread Section 3.1.2. While there are no “Prefix-conflicts” acro= ss topologies, there are “SID Conflicts”. This is important to = understand.

[Bruno3] Conflicts are= related to a forwarding context i.e. FIB. This is equally important to und= erstand. Please read https://tools.ietf.org/html/rfc5120#section-8.2.2 and 8.2.1 to see that topologies may n= ot share the same forwarding context hence do not conflict in term of prefi= x & SID.

--Bruno

 

As regards multi= ple protocols operating in the same topology, from a forwarding perspective= we do not care what protocol is the winning route. What we care about is t= hat our nexthop has chosen the same SID for a given prefix. This is why “source” is deliberately e= xcluded from consideration by the conflict resolution algorithm.=

 

  &nbs= p; Les

 

  &nbs= p; Les

 

 

Thanks,

Bruno

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,=

 

Thanks for your reply.=

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

Inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, please find below some= comments:

 

--

Isn’t this document specific to the MPLS datap= lane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

 

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document – which is why the Introduction is dataplane agnostic, but each sect= ion states specifically that it is relevant to SR-MPLS.

 

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.

[Bruno] ok, great.<= i>

--

=A73

“Mapping entries have an explicit context which incl= udes the topology and the SR algorithm.“

A priori you could add “the routing protocol”.=

 

[Les:] No –= ; the source of advertisements is deliberately left out. It matters not whe= ther the source of the advertisement is a protocol or an SRMS – nor d= oes it matter which protocol provides the advertisement. You see that “admin distance” is not mentioned at all and that= is quite deliberate. This insures that consistent choices are made on node= s regardless of which protocol might have the best route on a given node.

[Bruno] Well, the fact= is that mapping entries do have, as explicit context, the routing protocol= used to advertise them. After, you can should to use that information, or = not.

--

=A73

&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  If a router chooses to use one of=
 the conflicting
&=
nbsp;  entries forwarding loops and/or blackholes may result unless it=
 can
&=
nbsp;  be guaranteed that all other routers in the network make the sa=
me
&=
nbsp;  choice.  Making the same choice requires that all routers =
have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. =BB
<=
o:p> 
I=
 think we agree on the technical part, but I found the formulation slightly=
 biased. I would propose
&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  In order to avoid forwarding loop=
s and/or blackholes, there is a need for all nodes to make the same choice.=

&=
nbsp; Making the same choice requires that all routers have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. This is the purpose of this document. =
;=BB

--

[Les:] I am fine= with this change.

[Bruno] Thanks

 

=A73.1

&=
#8220;Various types of conflicts may occur”
W=
hat about :s/Various/Two

 

[Les:] “Tw= o” is fine. Just means we will have to change it if we come up with a= third type of conflict. J<= o:p>

[Bruno] Indeed, but in= this case the change may be much larger (e.g. the whole algo)

--

I agree with Robert’s  and Uma’s co= mment with regards to making this conflict resolution an inter- protocol/ro= uting_table issue. In particular, between SR domains, there is not requirem= ent to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

 

[Les:] There is = more to be said on this topic – co-authors are actively discussing th= is point and we’ll respond more fully to Robert’s post in time.= But, the draft is NOT trying to define conflict resolution across “SR domains”. Perhaps we need language to make that mor= e explicit.

[Bruno] ok. Regarding = inter-protocol, in order to have consistency of the prefix-SID mapping acro= ss the domain we need:

a) all nodes use the same algo

b) all nodes using this algo have the same data

 

“a” requires this draft

“b” requires that all nodes have the same set of SR = ; info. This forbid that some node are considering IS-IS + OSPF SR data= , while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guar= antee that the flooding area is the same for IS-IS and OSPF, we can't have = the algo using the SR data from multiple routing protocols. I don't think t= hat we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple = routing domain or when gradually transitioning from one IGP to another.

 

So in short, this SR-c= onflict algo should probably be restricted to SR information from a single = protocol

 

> From: Les Ginsberg (gin= sberg) [mailto:ginsberg@cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

> =

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same – no= t the label.

It is true that = SIDs are not installed in the forwarding plane – the labels derived f= rom the SID/SRGB are what is actually installed in the forwarding plane = 211; but I think my use of the word SID in this context is correct.

[Bruno] My point was t= hat the formulation assumes that a single SRGB is used per nodes. In which = case, we have a bijection between SID and labels. But if we have a SRGB per= protocol, we don’t have a bijection any more and we can have the same SID in IS-IS and OSPF (including for dif= ferent prefix), which will be mapped to different labels in the forwarding = plane.

 

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I’m not sure how much the agreement has been r= eached on that one.

 

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision

[Bruno] ok, may be thi= s should be stated in the draft, as otherwise you’ll keep getting com= ments, or we may forget this point.

Thanks

--Bruno

– but in s= pirit the same rules will apply – they will just have to take into ac= count “duplicate forwarding domains”. Note that this will also = require multiple incoming label entries/prefix be supported by the routers in such a network.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with range 2)

 

[Les:] Agreed &#= 8211; thanx for spotting this.

 

   Les<= /span>

 = ;

Thanks,

Regards,

Bruno

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_269896ae1e214e9295130d1999b614c0XCHALN001ciscocom_-- From nobody Tue Jul 5 00:22:09 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D3D12D137 for ; Tue, 5 Jul 2016 00:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L_U26osk7bS for ; Tue, 5 Jul 2016 00:22:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F5D12D124 for ; Tue, 5 Jul 2016 00:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2705; q=dns/txt; s=iport; t=1467703325; x=1468912925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PbaVTaLIJYvKTq/wTCJykV+FZ95J1yW2XfMx3vJ0pt0=; b=R8CWdIIQLCWnotxSXIcwo9cMDE679sqHwufPg9jZpfIw0SYk3TFCzL6W lFCoagvrfz05aIVVclTk6d8oBpr5d0ouJfB1vUY58dalsYwHwJYTPvvMT on62oH7L2LKMyumKyPpKqA8C/C2gft8Vm5B7ido6npGON9s4rE1b04/uf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQC1X3tX/5xdJa1cgz5WfAa5PIF3J?= =?us-ascii?q?IV0AoE/OBQBAQEBAQEBZRwLhEwBAQU6PwwEAgEIEQEDAQEfCQcyFAMGCAEBBA4?= =?us-ascii?q?FCIgoDrkYAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNhBIRAYV3BZkTAYYIi?= =?us-ascii?q?DeBcYRWiGqQCQEeNoIIHIFMbodENn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,578,1459814400"; d="scan'208";a="120447335" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 07:22:04 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u657M4TT012693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 07:22:04 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 02:22:03 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 02:22:03 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution-01 Thread-Index: AdHV6o0E/qlZMiJZSjCljyO2j8K1qgAoxueg Date: Tue, 5 Jul 2016 07:22:03 +0000 Message-ID: <33389c9b78894e60a822caaab2ea509a@XCH-ALN-001.cisco.com> References: <19159_1467634029_577A516D_19159_16159_10_53C29892C857584299CBF5D05346208A0F92A139@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <19159_1467634029_577A516D_19159_16159_10_53C29892C857584299CBF5D05346208A0F92A139@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.5.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 07:22:07 -0000 Bruno - I agree with your point. The draft is only discussing SIDs as index values.= We will add some language to make that clear in the next revision. Thanx. Les > -----Original Message----- > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > Sent: Monday, July 04, 2016 5:07 AM > To: Les Ginsberg (ginsberg) > Cc: spring@ietf.org > Subject: draft-ietf-spring-conflict-resolution-01 >=20 > Hi Les, >=20 > When talking about SID conflicts I think the document should spell out wh= at it > means by SID. >=20 > Indeed, the architecture document defines SID as: > "SID: a Segment Identifier. Examples of SIDs are: a MPLS label, an > index value in a MPLS label space, an IPv6 address. Other types of > SIDs can be defined in the future." > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08#section-= 2 >=20 >=20 > Indeed, when talking about SID conflicts > - it matters that we do not compare apple and orange i.e. MPLS labels an= d > index in SRGB. > - we can't compare index from different protocols (e.g. OSPF & IS-IS) unl= ess > they advertise the same SRGB (which is only a specific case). >=20 >=20 > So either the document considers that a SID is an "index" and in this cas= e, we > just can't compare them across protocols. > Or it consider that a SID is a "MPLS labels" and in this case, as the IGP > advertisement typically advertise index for global SIDs, there is a need = to > maps the received SID advertisement into the SRGB of the local node. >=20 > This needs to be crystal clear. >=20 > Thanks > -- Bruno >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > 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 de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Tue Jul 5 00:29:47 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED7B12D111 for ; Tue, 5 Jul 2016 00:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4ey6a1BkWKT for ; Tue, 5 Jul 2016 00:29:40 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E566412B015 for ; Tue, 5 Jul 2016 00:29:39 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id q132so128920317lfe.3 for ; Tue, 05 Jul 2016 00:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zOO1aXP7z3xdTnfuz0iMBtO/zW0nPh1QA70mDyivE+I=; b=dKA6CDiUPwWYmO8XgojOsEtIC0qwUjpXFOfrzidST9BAdAIUw/ssKw9lRq+wUTX6ZU C2aD71AaZPO5lbBGAXAdSYdtmfLHDxIsiELLF9cKOA4nn5Mwt6LFRJI5dk9gefDwIMwK uWgimkSuLl/sAnhgP6ym1q4POcJ1UHDWMbD2OCtZnfZ/ndD8pmLzNoYClrL3dgJwH7Mu BiM2MHin/BPB8IXY7eVut1D3cQYcRb0pJdJlPfclo9ouGTd4QB4u+rGGl2fMyyGZ89eY 0ftVJ2M+9uQ7+2E4mIF1oMKFwGBmnZBis4sPjYkcllsyt9SEW44fU7ZoH+la2Rm0Vauc Jz1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zOO1aXP7z3xdTnfuz0iMBtO/zW0nPh1QA70mDyivE+I=; b=bcNIzRWx4kutjCuWu3MYswdaO85kRhlcdCfjKFvUe5ZGpyaR/U6u5iiEyp+Cqbav3z FJrYiA8XKjeo3WsupgIVfolqO17BC3sGyhd5SSPtYpPPKGvyQS9l2uh1IssJOekyHqg4 3mJBQLhbWJOSETIP+Jd8oEvDnV0xtYn85zegUp/2kqXLcL8RN1NcEcU3VBMGyE4PCVTS vsSvw9xicVpyzjlYAAqEBorHpDIbZD9VA1VXt5wzC8YVw9KLqMZkFMkNeh0HoE0Mcjnp lxio4GLi9qImTfcGmYOW5ViKVCRBeCLmL/aqpJKF3DxiM6Vi9OPd0iiw3rRqqW1X705v Golg== X-Gm-Message-State: ALyK8tLvEwg+/WGl94WwROGR9czMqRKhyXZLY29DoI7QFNn3OQeTZGGpIjzp6EJBsw0k4LdIYvustjMG3S2iAg== X-Received: by 10.25.91.139 with SMTP id p133mr4506751lfb.167.1467703777750; Tue, 05 Jul 2016 00:29:37 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Tue, 5 Jul 2016 00:29:36 -0700 (PDT) In-Reply-To: <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> From: Robert Raszuk Date: Tue, 5 Jul 2016 09:29:36 +0200 X-Google-Sender-Auth: BFvLq4O3neRv_67DDX-7CCnNR68 Message-ID: To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=001a11412b584ef54f0536de6ae4 Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 07:29:45 -0000 --001a11412b584ef54f0536de6ae4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Les, > However, this is not existing MPLS forwarding behavior and since SR > explicitly utilizes the existing MPLS forwarding behavior we not propose > any extensions. I am afraid the above assertion is not correct. Existing MPLS forwarding already for a long time uses context-labels to set required topology for forwarding. https://tools.ietf.org/html/rfc5331 Thx, R. On Tue, Jul 5, 2016 at 9:19 AM, Les Ginsberg (ginsberg) wrote: > Bruno =E2=80=93 > > > > SR-MPLS utilizes existing MPLS forwarding behavior without change. In thi= s > model, the received label serves as the forwarding instruction for the > packet. This means that if two packets are received for the same > destination but we want the packet to follow two different forwarding > =E2=80=9Ctopologies=E2=80=9D, then we need to have two different labels. > > > > One can imagine a different model, where the forwarding instruction is > derived from the label AND some other attribute of the packet =E2=80=93 a= nd the > latter could be used to select a forwarding topology. However, this is no= t > existing MPLS forwarding behavior and since SR explicitly utilizes the > existing MPLS forwarding behavior we not propose any extensions. > > > > This is why different SIDs are required for the same destination in > different topologies. > > > > Les > > > > > > *From:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > *Sent:* Monday, July 04, 2016 5:07 AM > > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Les, > > > > Please see inline [Bruno3] > > > > *From:* Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > *Sent:* Friday, July 01, 2016 3:36 AM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno =E2=80=93 > > > > Inline. > > > > *From:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com > ] > *Sent:* Thursday, June 30, 2016 5:10 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Hi Les, > > > > Thanks for the discussion. Please see inline [Bruno] > > > > *From:* Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > *Sent:* Wednesday, June 29, 2016 6:19 PM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno =E2=80=93 > > > > > > *From:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com > ] > *Sent:* Wednesday, June 29, 2016 7:22 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Hi Les, > > > > IINM, I=E2=80=99ve not seen the follow up on one of my below questions. > > So let me restate a comment: > > > > The SR-MPLS SID conflicts algo requires that all nodes consider the same > mapping advertisements. > > How is this ensured, if it indifferently considers advertisements from al= l > protocols, while some nodes could participate only in a subset of the > protocols? e.g. OSPF only routers would consider a different set of > information compared to OSPF+IS-IS routers. > > > > *[Les:] If you run multiple protocol instances (whether multiple instance= s > of the same protocol or instances of different protocols) then you need t= o > insure that at least one of the two conditions below is true:* > > =C2=B7 All routers receive the equivalent set of advertisements > > =C2=B7 There are no conflicts J > > > > [Bruno] IOW, the draft does not resolve SID conflict if all routers do no= t > receive exactly the same set of advertisement from all routing protocols. > > That=E2=80=99s indeed can be a valid simplification if the WG choose to, = but this > should clearly be indicated in the document, in a section targeting netwo= rk > operator since this point will need to be read and enforced by network > operator rather than protocol implementors. =C2=A73.2.8 already partly ad= dress > this, but IMO a text clearly expressing the requirements on network > operator would be useful. > > > > *[Les2:] No policy can guarantee consistent results network wide if the > databases on different nodes are inconsistent. This isn=E2=80=99t a > =E2=80=9Csimplification=E2=80=9D =E2=80=93 it is a fact. As you point out= , Section 3.2.8 already > states:* > > > > *=E2=80=9CIn order to obtain consistent active entries all nodes in a net= work* > > * MUST have the same mapping entry database.=E2=80=9D* > > > > *If you believe this is not explicit enough please suggest some text.* > > [Bruno3] > > Section 4 Manageability Considerations > > Detecting and resolving conflicts in a consistent way requires that all > nodes consider the same set of SIDs advertisements. Network operations > should be aware that the conflict resolution algorithm defined in this > document will not succeed in selecting a consistent resolution across all > nodes, if all nodes do not receive the exact same set of SIDs > advertisements. This may be in particular the case when multiple IGP > instances are used and all routers do not participate in the same set of > IGP instances. This may occurs for example if one network transition from > one IGP protocol to another IGP (e.g. from OSPFv2 to IS-IS). This may als= o > happen if IGP areas/level are used and SIDs are not flooded in all > areas/levels. > > > > > > *One way of insuring the first point is to exclusively use a mapping > server to advertise SIDs, configure your SRMS entries in a protocol > independent manner, and insure that the SRMS advertisements are sent in a= ll > of the protocol instance specific sub-domains.* > > [Bruno] IOW, don=E2=80=99t make configuration errors ;-) > > Are you implying that the SRMS configuration (hence yang model) should be > per node rather than per protocol? or at least should be configurable by > node (and possibly also by protocols) > > > > *[Les2:] My point is (humorous ideas aside=E2=80=A6) that if a deployment= uses > multiple protocols, the easiest way to guarantee that the SID mapping > database on all nodes in the network is consistent is to restrict SID > advertisements to SRMS advertisements.* > > [Bruno3] Clearly, the fewer the number of advertisements for a given > prefix, the less change of conflict. > > But I fail to see why only using SRMS guarantee anything. e.g. if > different nodes use a different set of routing protocols, you have > conflicts. Idem if the misconfiguration consist in adding a SID to a IGP > prefix (PFX advertisement) > > > > > > *A small number of nodes (as few as 1 =E2=80=93 more if redundancy is des= ired) are > setup as mapping servers and all SIDs which are required network-wide are > configured on these nodes and advertised by the protocol instance(s) on > that node. In this way it is not necessary to guarantee that all prefix > reachability from all of the protocol instances running in the network ar= e > present in all the protocol instance sub-domains which exist =E2=80=93 it= is only > necessary to insure that all protocol instances advertise the same set of > SRMS entries.* > > [Bruno3] In the end, this gets back to requiring no configuration mistake= s. > > *It isn=E2=80=99t the only way to support this =E2=80=93 but it is likely= to be the > simplest and least error prone. In any case this isn=E2=80=99t a requirem= ent =E2=80=93 it > was a response to your question as to how it might be possible to get > consistent SID mapping databases on all nodes in such a case. This is no > way changes how the YANG model is defined. SRMS config is always node > specific.* > > > > > > *If the intent is to deliberately use different labels in the forwarding > plane for the same destination depending upon which protocol advertised t= he > prefix, this introduces a number of new requirements =E2=80=93 not the le= ast of > which is duplicate entries for the same prefix in the forwarding plane. = As > has been discussed publicly in a different thread, there are cases (e.g. > merging two networks) were such a requirement may exist =E2=80=93 but it = is the > exception rather than the rule and as it consumes more resources in the > forwarding plane and introduces implementation complexity independent of > conflict resolution it is not the primary case the draft focuses on. > Nevertheless, this is a case which the draft will address in the next > revision.* > > [Bruno]There is also the point of configuring different SRGB space in > different IGP protocols. In which case, SIDs may conflict but this is not > an issue as label will not conflict. > > *We stopped short of that in this revision because we felt there were > enough substantive changes and points on which consensus is still a work = in > progress that it would not be the optimal way forward.* > > [Bruno] +1 and thanks. Releasing an updated version has been useful to > re-initiate the discussion. > > > > Thinking more about this, I guess that this is only important for the > entries which are inserted in the forwarding plane. Hence, in case of > conflict between protocols, I think that the preference algorithm should > take into account the protocol preference (aka administrative distance). > > > > *[Les:] As admin distance is neither an attribute of SRMS entries nor > guaranteed to be consistent on all routers for all prefixes this is not a > desirable approach. * > > [Bruno] Well, the some prefix/routing consistency is also required for IP > prefixes. When then same IP prefix is advertised in different IGPs, admin > distance is a common existing way to define which routing protocol takes > precedence. I=E2=80=99m not sure why it should not also be taken into con= sideration > for SR Prefix conflits > > > > *[Les2:] Please see my response to Stephane on the same point.* > > > > I=E2=80=99m also not sure to see why is the problem different compared to > Multi-Topology. Could you please elaborate? > > *[Les:] I am unclear what your question is. Are you asking why we need > different SIDs in different topologies? Please clarify.* > > [Bruno] Question was that, at a very/too high level, the issue of conflic= t > across topology seems close to the issue of conflict across routing > protocols: we have different topologies. Hence a na=C3=AFve question: ho= w > exactly is this different. > > One part of the answer, is the simplification proposed when multiple > protocols is used (i.e. your first answer above). > > Another part is that for multi-topology, compared to multi-protocols, all > information from all topologies are flooded to all nodes. > > Another part is the forwarding model used for Multi-Topology. In general, > https://tools.ietf.org/html/rfc5120#section-8 seems to assume that each > topology has one dedicated RIB/FIB. In such condition, there is no confli= ct > (prefix or SID) so no need to detect and resolve conflict. So here there > may be different models and eventually, we don=E2=80=99t =E2=80=98have th= e same one in mind. > > In a lesser extend, even for multi-protocols, we may have those multiple > forwarding models. To some extent, this seems related to the definition o= f > =E2=80=9CSR domain=E2=80=9D. e.g. if we have 2 IGPs, do we have 1 or 2 SR= domains? May be > this is something that needs to be configurable > > > > > > *[Les2:] Please reread Section 3.1.2. While there are no > =E2=80=9CPrefix-conflicts=E2=80=9D across topologies, there are =E2=80=9C= SID Conflicts=E2=80=9D. This is > important to understand.* > > [Bruno3] Conflicts are related to a forwarding context i.e. FIB. This is > equally important to understand. Please read > https://tools.ietf.org/html/rfc5120#section-8.2.2 and 8.2.1 to see that > topologies may not share the same forwarding context hence do not conflic= t > in term of prefix & SID. > > --Bruno > > > > *As regards multiple protocols operating in the same topology, from a > forwarding perspective we do not care what protocol is the winning route. > What we care about is that our nexthop has chosen the same SID for a give= n > prefix. This is why =E2=80=9Csource=E2=80=9D is deliberately excluded fro= m consideration by > the conflict resolution algorithm.* > > > > * Les* > > > > * Les* > > > > > > Thanks, > > Bruno > > > > *From:* spring [mailto:spring-bounces@ietf.org ]= *On > Behalf Of *bruno.decraene@orange.com > *Sent:* Wednesday, May 18, 2016 1:57 PM > *To:* Les Ginsberg (ginsberg); spring@ietf.org > *Subject:* Re: [spring] draft-ietf-spring-conflict-resolution > > > > Les, > > > > Thanks for your reply. > > Please see inline [Bruno] > > > > *From:* Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > *Sent:* Saturday, May 14, 2016 8:30 PM > *To:* DECRAENE Bruno IMT/OLN; spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno =E2=80=93 > > > > Inline. > > > > *From:* spring [mailto:spring-bounces@ietf.org ]= *On > Behalf Of *bruno.decraene@orange.com > *Sent:* Thursday, May 12, 2016 8:23 AM > *To:* spring@ietf.org > *Subject:* [spring] draft-ietf-spring-conflict-resolution > > > > Hi, > > > > As an individual contributor, please find below some comments: > > > > -- > > Isn=E2=80=99t this document specific to the MPLS dataplane? > > If so, it could be indicated in the introduction, and possibly in the > abstract. Then this indication could be removed from the 1rst sentence of > sections 2 & 3. > > > > *[Les:] Currently all discussion is regarding SR-MPLS. The draft leaves > open the possibility that if there is some SRv6 conflict resolution that > needs to be specified it could be added into this document =E2=80=93 whic= h is why > the Introduction is dataplane agnostic, but each section states > specifically that it is relevant to SR-MPLS.* > > > > *I am not aware of any SRv6 conflict resolution that is required at this > point, but I prefer to leave the possibility open if that is OK with you.= * > > [Bruno] ok, great. > > -- > > =C2=A73 > > =E2=80=9CMapping entries have an explicit context which includes the topo= logy and > the SR algorithm.=E2=80=9C > > A priori you could add =E2=80=9Cthe routing protocol=E2=80=9D. > > > > *[Les:] No =E2=80=93 the source of advertisements is deliberately left ou= t. It > matters not whether the source of the advertisement is a protocol or an > SRMS =E2=80=93 nor does it matter which protocol provides the advertiseme= nt. You > see that =E2=80=9Cadmin distance=E2=80=9D is not mentioned at all and tha= t is quite > deliberate. This insures that consistent choices are made on nodes > regardless of which protocol might have the best route on a given node.* > > [Bruno] Well, the fact is that mapping entries do have, as explicit > context, the routing protocol used to advertise them. After, you can shou= ld > to use that information, or not. > > -- > > =C2=A73 > > =E2=80=9CWhen conflicts occur, it is not > > possible for routers to know which of the conflicting advertisements > > is "correct". If a router chooses to use one of the conflicting > > entries forwarding loops and/or blackholes may result unless it can > > be guaranteed that all other routers in the network make the same > > choice. Making the same choice requires that all routers have > > identical sets of advertisements and that they all use the same > > selection algorithm. =C2=BB > > > > I think we agree on the technical part, but I found the formulation sligh= tly biased. I would propose > > =E2=80=9CWhen conflicts occur, it is not > > possible for routers to know which of the conflicting advertisements > > is "correct". In order to avoid forwarding loops and/or blackholes, t= here is a need for all nodes to make the same choice. > > Making the same choice requires that all routers have > > identical sets of advertisements and that they all use the same > > selection algorithm. This is the purpose of this document. =C2=BB > > -- > > *[Les:] I am fine with this change.* > > [Bruno] Thanks > > > > =C2=A73.1 > > =E2=80=9CVarious types of conflicts may occur=E2=80=9D > > What about :s/Various/Two > > > > *[Les:] =E2=80=9CTwo=E2=80=9D is fine. Just means we will have to change = it if we come up > with a third type of conflict. **J* > > [Bruno] Indeed, but in this case the change may be much larger (e.g. the > whole algo) > > -- > > I agree with Robert=E2=80=99s and Uma=E2=80=99s comment with regards to = making this > conflict resolution an inter- protocol/routing_table issue. In particular= , > between SR domains, there is not requirement to have unique SIDs. Hence > between PE and CE, between ASes (both within and across organization), th= e > same SID could be reused independently). > > > > *[Les:] There is more to be said on this topic =E2=80=93 co-authors are a= ctively > discussing this point and we=E2=80=99ll respond more fully to Robert=E2= =80=99s post in > time. But, the draft is NOT trying to define conflict resolution across = =E2=80=9CSR > domains=E2=80=9D. Perhaps we need language to make that more explicit.* > > [Bruno] ok. Regarding inter-protocol, in order to have consistency of the > prefix-SID mapping across the domain we need: > > a) all nodes use the same algo > > b) all nodes using this algo have the same data > > > > =E2=80=9Ca=E2=80=9D requires this draft > > =E2=80=9Cb=E2=80=9D requires that all nodes have the same set of SR info= . This forbid > that some node are considering IS-IS + OSPF SR data, while some node are > only considering IS-IS data. Otherwise, all IS-IS routers would not take > the same decision. So, unless we can guarantee that the flooding area is > the same for IS-IS and OSPF, we can't have the algo using the SR data fro= m > multiple routing protocols. I don't think that we can guarantee this (nor > that implementation will check this) e.g. when some nodes are part of > multiple routing domain or when gradually transitioning from one IGP to > another. > > > > So in short, this SR-conflict algo should probably be restricted to SR > information from a single protocol > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > Sent: Sunday, May 01, 2016 7:11 AM > > > > > > We are indeed defining conflict resolution across all the SID > advertisements regardless of source (protocol or SRMS) > > > Why? Because we need consistent use of SIDs in the forwarding plane > > > > No: in the forwarding plane, we need a consistent use of MPLS label. > > *[Les:] As you know, SRGB range can be different for different nodes, so > the actual label that is used to send a packet for a given destination vi= a > Node A may be different than the label used to send the same packet via > Node B. It is the SID that needs to be the same =E2=80=93 not the label. = * > > *It is true that SIDs are not installed in the forwarding plane =E2=80=93= the > labels derived from the SID/SRGB are what is actually installed in the > forwarding plane =E2=80=93 but I think my use of the word SID in this con= text is > correct.* > > [Bruno] My point was that the formulation assumes that a single SRGB is > used per nodes. In which case, we have a bijection between SID and labels= . > But if we have a SRGB per protocol, we don=E2=80=99t have a bijection any= more and > we can have the same SID in IS-IS and OSPF (including for different > prefix), which will be mapped to different labels in the forwarding plane= . > > > > Plus only within an SR domain. Actually, even within a domain, this is > dependent on whether SRGB is configured on a per node or a per protocol > basis. I=E2=80=99m not sure how much the agreement has been reached on th= at one. > > > > *[Les:] The draft currently addresses deployments where a single (set of) > SRGB ranges applies to the box. This is by far the most common use case. > There is a much more limited use case where protocol specific SRGBs and > protocol specific SIDs may be required. The draft will address that in a > future revision* > > [Bruno] ok, may be this should be stated in the draft, as otherwise you= =E2=80=99ll > keep getting comments, or we may forget this point. > > Thanks > > --Bruno > > *=E2=80=93 but in spirit the same rules will apply =E2=80=93 they will ju= st have to take > into account =E2=80=9Cduplicate forwarding domains=E2=80=9D. Note that th= is will also > require multiple incoming label entries/prefix be supported by the router= s > in such a network.* > > > > -- > > Typo: > > =C2=A72 > > OLD : Range 3: (500, 5990 > > NEW : Range 3: (500, 599) > > > > (somewhat significant as otherwise range 3 conflict with range 2) > > > > *[Les:] Agreed =E2=80=93 thanx for spotting this.* > > > > *Les* > > > > Thanks, > > Regards, > > Bruno > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --001a11412b584ef54f0536de6ae4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On= Tue, Jul 5, 2016 at 9:19 AM, Les Ginsberg (ginsberg) <= ;ginsberg@cisco.com= > wrote:

Bruno =E2=80=93=

=C2=A0

SR-MPLS utilizes exist= ing MPLS forwarding behavior without change. In this model, the received la= bel serves as the forwarding instruction for the packet. This means that if= two packets are received for the same destination but we want the packet to follow two different forwarding =E2= =80=9Ctopologies=E2=80=9D, then we need to have two different labels.

=C2=A0

One can imagine a diff= erent model, where the forwarding instruction is derived from the label AND= some other attribute of the packet =E2=80=93 and the latter could be used = to select a forwarding topology. However, this is not existing MPLS forwarding behavior and since SR explicitly utilizes = the existing MPLS forwarding behavior we not propose any extensions.=

=C2=A0

This is why different = SIDs are required for the same destination in different topologies.<= u>

=C2=A0

=C2=A0=C2=A0=C2=A0 Les=

=C2=A0

=C2=A0

From: bruno.decraene@oran= ge.com [mailto:bruno.decraene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM


To: Les Ginsberg (ginsberg)
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution

=C2=A0

Les,

=C2= =A0

Please see= inline [Bruno3]

=C2= =A0

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:36 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution

=C2=A0

Bruno =E2=80=93=

=C2=A0

Inline.<= /span>

=C2=A0

From: bruno.decrae= ne@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution

=C2=A0

Hi Les,=

=C2= =A0

Thanks for the discuss= ion. Please see inline [Bruno]

=C2=A0

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution

=C2=A0

Bruno =E2=80=93=

=C2=A0

=C2=A0

From: bruno.decrae= ne@orange.com [mailto:bruno.decraene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution

=C2=A0

Hi Les,=

=C2= =A0

IINM, I=E2=80=99ve not= seen the follow up on one of my below questions.

So let me restate a co= mment:

=C2=A0

The SR-MPLS SID confli= cts algo requires that all nodes consider the same mapping advertisements.<= u>

How is this ensured, i= f it indifferently considers advertisements from all protocols, while some = nodes could participate only in a subset of the protocols? e.g. OSPF only r= outers would consider a different set of information compared to OSPF+IS-IS routers.

=C2=A0

[Les:] If you ru= n multiple protocol instances (whether multiple instances of the same proto= col or instances of different protocols) then you need to insure that at le= ast one of the two conditions below is true:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 All routers recei= ve the equivalent set of advertisements

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 There are no conf= licts J

=C2=A0

[Bruno] IOW, the draft= does not resolve SID conflict if all routers do not receive exactly the sa= me set of advertisement from all routing protocols.

That=E2=80=99s indeed = can be a valid simplification if the WG choose to, but this should clearly = be indicated in the document, in a section targeting network operator since= this point will need to be read and enforced by network operator rather than protocol implementors. =C2=A73.2.8 already= partly address this, but IMO a text clearly expressing the requirements on= network operator would be useful.

=C2=A0

[Les2:] No polic= y can guarantee consistent results network wide if the databases on differe= nt nodes are inconsistent. This isn=E2=80=99t a =E2=80=9Csimplification=E2= =80=9D =E2=80=93 it is a fact. As you point out, Section 3.2.8 already states:

=C2=A0=

=E2=80=9CIn order to obtain consistent active entries all nod= es in a network

=C2=A0=C2=A0 MUS= T have the same mapping entry database.=E2=80=9D

=C2=A0=

If you believe this= is not explicit enough please suggest some text.<= /p>

[Bruno3] <= u>

Section 4 Manageabilit= y Considerations

Detecting and resolvin= g conflicts in a consistent way requires that all nodes consider the same s= et of SIDs advertisements. Network operations should be aware that the conf= lict resolution algorithm defined in this document will not succeed in selecting a consistent resolution across= all nodes, if all nodes do not receive the exact same set of SIDs advertis= ements. This may be in particular the case when multiple IGP instances are = used and all routers do not participate in the same set of IGP instances. This may occurs for example if one netwo= rk transition from one IGP protocol to another IGP (e.g. from OSPFv2 to IS-= IS). This may also happen if IGP areas/level are used and SIDs are not floo= ded in all areas/levels.

=C2=A0

=C2=A0

One way of insuring= the first point is to exclusively use a mapping server to advertise SIDs, = configure your SRMS entries in a protocol independent manner, and insure th= at the SRMS advertisements are sent in all of the protocol instance specific sub-domains.=

[Bruno] IOW, don=E2=80= =99t make configuration errors ;-)

Are you implying that = the SRMS configuration (hence yang model) should be per node rather than pe= r protocol? or at least should be configurable by node (and possibly also b= y protocols)

=C2=A0

[Les2:] My point= is (humorous ideas aside=E2=80=A6) that if a deployment uses multiple prot= ocols, the easiest way to guarantee that the SID mapping database on all no= des in the network is consistent is to restrict SID advertisements to SRMS advertisements.

[Bruno3] Clearly, the = fewer the number of advertisements for a given prefix, the less change of c= onflict.

But I fail to see why = only using SRMS guarantee anything. e.g. if different nodes use a different= set of routing protocols, you have conflicts. Idem if the misconfiguration= consist in adding a SID to a IGP prefix (PFX advertisement)

=C2=A0

=C2=A0=

A small number o= f nodes (as few as 1 =E2=80=93 more if redundancy is desired) are setup as = mapping servers and all SIDs which are required network-wide are configured= on these nodes and advertised by the protocol instance(s) on that node. In this way it is not necessary to guarantee tha= t all prefix reachability from all of the protocol instances running in the= network are present in all the protocol instance sub-domains which exist = =E2=80=93 it is only necessary to insure that all protocol instances advertise the same set of SRMS entries.=

[Bruno3] In the end, t= his gets back to requiring no configuration mistakes.

It isn=E2=80=99t= the only way to support this =E2=80=93 but it is likely to be the simplest= and least error prone. In any case this isn=E2=80=99t a requirement =E2=80= =93 it was a response to your question as to how it might be possible to get consistent SID mapping databases on all nodes in such a case. This = is no way changes how the YANG model is defined. SRMS config is always node= specific.

=C2=A0=

=C2=A0

If the intent is to= deliberately use different labels in the forwarding plane for the same des= tination depending upon which protocol advertised the prefix, this introduc= es a number of new requirements =E2=80=93 not the least of which is duplicate entries for the same prefix in the forward= ing plane.=C2=A0 As has been discussed publicly in a different thread, ther= e are cases (e.g. merging two networks) were such a requirement may exist = =E2=80=93 but it is the exception rather than the rule and as it consumes more resources in the forwarding plane and int= roduces implementation complexity independent of conflict resolution it is = not the primary case the draft focuses on. Nevertheless, this is a case whi= ch the draft will address in the next revision.

[Bruno]There is also t= he point of configuring different SRGB space in different IGP protocols. In= which case, SIDs may conflict but this is not an issue as label will not c= onflict.

We stopped short of= that in this revision because we felt there were enough substantive change= s and points on which consensus is still a work in progress that it would n= ot be the optimal way forward.

[Bruno] +1 and thanks.= Releasing an updated version has been useful to re-initiate the discussion= .

=C2=A0

Thinking more about th= is, I guess that this is only important for the entries which are inserted = in the forwarding plane. Hence, in case of conflict between protocols, I th= ink that the preference algorithm should take into account the protocol preference (aka administrative distance). <= u>

=C2=A0

[Les:] As admin = distance is neither an attribute of SRMS entries nor guaranteed to be consi= stent on all routers for all prefixes this is not a desirable approach.

[Bruno] Well, the some= prefix/routing consistency is also required for IP prefixes. When then sam= e IP prefix is advertised in different IGPs, admin distance is a common exi= sting way to define which routing protocol takes precedence. I=E2=80=99m not sure why it should not also be taken int= o consideration for SR Prefix conflits

=C2=A0

[Les2:] Please s= ee my response to Stephane on the same point.<= /p>

=C2=A0

I=E2=80=99m also not s= ure to see why is the problem different compared to Multi-Topology. Could y= ou please elaborate?

[Les:] I am uncl= ear what your question is. Are you asking why we need different SIDs in dif= ferent topologies? Please clarify.

[Bruno] Question was t= hat, at a very/too high level, the issue of conflict across topology seems = close to the issue of conflict across routing protocols: =C2=A0we have diff= erent topologies. Hence a na=C3=AFve question: how exactly is this different.

One part of the answer= , is the simplification proposed when multiple protocols is used (i.e. your= first answer above).

Another part is that f= or multi-topology, compared to multi-protocols, all information from all to= pologies are flooded to all nodes.

Another part is the fo= rwarding model used for Multi-Topology. In general, https://tools.ietf.org/html/rfc5120#section-8 seems to assume that each topology has= one dedicated RIB/FIB. In such condition, there is no conflict (prefix or = SID) so no need to detect and resolve conflict. So here there may be differ= ent models and eventually, we don=E2=80=99t =E2=80=98have the same one in mind.

In a lesser extend, ev= en for multi-protocols, we may have those multiple forwarding models. To so= me extent, this seems related to the definition of =E2=80=9CSR domain=E2=80= =9D. e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be this is something that needs to be configurable

=C2=A0

=C2=A0=

[Les2:] Please r= eread Section 3.1.2. While there are no =E2=80=9CPrefix-conflicts=E2=80=9D = across topologies, there are =E2=80=9CSID Conflicts=E2=80=9D. This is impor= tant to understand.

[Bruno3] Conflicts are= related to a forwarding context i.e. FIB. This is equally important to und= erstand. Please read https://tools.ietf.org/html/rfc51= 20#section-8.2.2 and 8.2.1 to see that topologies may n= ot share the same forwarding context hence do not conflict in term of prefi= x & SID.

--Bruno

=C2=A0=

As regards multi= ple protocols operating in the same topology, from a forwarding perspective= we do not care what protocol is the winning route. What we care about is t= hat our nexthop has chosen the same SID for a given prefix. This is why =E2=80=9Csource=E2=80=9D is deliberate= ly excluded from consideration by the conflict resolution algorithm.=

=C2=A0=

=C2=A0=C2=A0=C2= =A0 Les

=C2=A0=

=C2=A0=C2=A0=C2= =A0 Les

=C2=A0

=C2=A0

Thanks,<= /span>

Bruno

=C2=A0

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

=C2=A0

Les,

=C2=A0

Thanks for your reply.=

Please see inline [Bru= no]

=C2=A0

From: Les Gins= berg (ginsberg) [ma= ilto:ginsberg@cisco.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution

=C2=A0

Bruno =E2=80=93=

=C2=A0

Inline.<= /span>

=C2=A0

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@= orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">
Subject: [spring] draft-ietf-spring-conflict-resolution

=C2=A0

Hi,

=C2=A0

As an individual contributor, please find below some= comments:

=C2=A0

--

Isn=E2=80=99t this document specific to the MPLS dat= aplane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

=C2=A0

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document =E2=80=93 which is why the Introduction is dataplane agnostic, but each se= ction states specifically that it is relevant to SR-MPLS.

=C2=A0=

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.=

[Bruno] ok, great.<= i>

--

=C2=A73

=E2=80=9CMapping entries have an explicit context which in= cludes the topology and the SR algorithm.=E2=80=9C

A priori you could add =E2=80=9Cthe routing protocol=E2=80= =9D.

=C2=A0

[Les:] No =E2=80= =93 the source of advertisements is deliberately left out. It matters not w= hether the source of the advertisement is a protocol or an SRMS =E2=80=93 n= or does it matter which protocol provides the advertisement. You see that =E2=80=9Cadmin distance=E2=80=9D is not mentioned at all and = that is quite deliberate. This insures that consistent choices are made on = nodes regardless of which protocol might have the best route on a given nod= e.

[Bruno] Well, the fact= is that mapping entries do have, as explicit context, the routing protocol= used to advertise them. After, you can should to use that information, or = not.

--

=C2=A73

=
=E2=80=9CWhen conflicts occur, it is not
=
=C2=A0=C2=A0 possible for routers to know which of the conflicting advertis=
ements
=
=C2=A0=C2=A0 is "correct".=C2=A0 If a router chooses to use one o=
f the conflicting
=
=C2=A0=C2=A0 entries forwarding loops and/or blackholes may result unless i=
t can
=
=C2=A0=C2=A0 be guaranteed that all other routers in the network make the s=
ame
=
=C2=A0=C2=A0 choice.=C2=A0 Making the same choice requires that all routers=
 have
=
=C2=A0=C2=A0 identical sets of advertisements and that they all use the sam=
e
=
=C2=A0=C2=A0 selection algorithm.=C2=A0=C2=BB
<=
u>=C2=A0
I=
 think we agree on the technical part, but I found the formulation slightly=
 biased. I would propose
=
=E2=80=9CWhen conflicts occur, it is not
=
=C2=A0=C2=A0 possible for routers to know which of the conflicting advertis=
ements
=
=C2=A0=C2=A0 is "correct".=C2=A0 In order to avoid forwarding loo=
ps and/or blackholes, there is a need for all nodes to make the same choice=
.
=
=C2=A0 Making the same choice requires that all routers have<=
/span>
=
=C2=A0=C2=A0 identical sets of advertisements and that they all use the sam=
e
=
=C2=A0=C2=A0 selection algorithm. This is the purpose of this document.=C2=
=A0=C2=BB

--

[Les:] I am fine= with this change.

[Bruno] Thanks

=C2=A0

=C2=A73.1

=
=E2=80=9CVarious types of conflicts may occur=E2=80=9D=

W=
hat about :s/Various/Two

=C2=A0

[Les:] =E2=80=9C= Two=E2=80=9D is fine. Just means we will have to change it if we come up wi= th a third type of conflict. J<= u>

[Bruno] Indeed, but in= this case the change may be much larger (e.g. the whole algo)=

--

I agree with Robert=E2=80=99s =C2=A0and Uma=E2=80=99= s comment with regards to making this conflict resolution an inter- protoco= l/routing_table issue. In particular, between SR domains, there is not requ= irement to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

=C2=A0

[Les:] There is = more to be said on this topic =E2=80=93 co-authors are actively discussing = this point and we=E2=80=99ll respond more fully to Robert=E2=80=99s post in= time. But, the draft is NOT trying to define conflict resolution across =E2=80=9CSR domains=E2=80=9D. Perhaps we need language to make that= more explicit.

[Bruno] ok. Regarding = inter-protocol, in order to have consistency of the prefix-SID mapping acro= ss the domain we need:

a) all nodes use the same algo

b) all nodes using this algo have the same data=

=C2=A0

=E2=80=9Ca=E2=80=9D requires this draft

=E2=80=9Cb=E2=80=9D requires that all nodes have the same set of SR= =C2=A0 info. This forbid that some node are considering IS-IS + OSPF SR dat= a, while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guar= antee that the flooding area is the same for IS-IS and OSPF, we can't h= ave the algo using the SR data from multiple routing protocols. I don't= think that we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple = routing domain or when gradually transitioning from one IGP to another.<= /u>

=C2=A0

So in short, this SR-c= onflict algo should probably be restricted to SR information from a single = protocol

=C2=A0

> From: Les Ginsberg (gin= sberg) [mailto:ginsberg@cisco.= com] > Sent: Sunday, May 01, 2016 7:11 AM

>=C2=A0

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

=C2=A0

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same =E2=80=93 = not the label.

It is true that = SIDs are not installed in the forwarding plane =E2=80=93 the labels derived= from the SID/SRGB are what is actually installed in the forwarding plane = =E2=80=93 but I think my use of the word SID in this context is correct.

[Bruno] My point was t= hat the formulation assumes that a single SRGB is used per nodes. In which = case, we have a bijection between SID and labels. But if we have a SRGB per= protocol, we don=E2=80=99t have a bijection any more and we can have the same SID in IS-IS and OSPF (including for dif= ferent prefix), which will be mapped to different labels in the forwarding = plane.

=C2=A0

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I=E2=80=99m not sure how much the agreement has been= reached on that one.

=C2=A0

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision

[Bruno] ok, may be thi= s should be stated in the draft, as otherwise you=E2=80=99ll keep getting c= omments, or we may forget this point.

Thanks

--Bruno

=E2=80=93 but in= spirit the same rules will apply =E2=80=93 they will just have to take int= o account =E2=80=9Cduplicate forwarding domains=E2=80=9D. Note that this wi= ll also require multiple incoming label entries/prefix be supported by the routers in such a network.

=C2=A0

--

Typo:

=C2=A72

OLD=C2=A0: Range 3: (500, 5990

NEW=C2=A0: Range 3: (500, 599)

=C2=A0

(somewhat significant as otherwise range 3 conflict with range 2)

=C2=A0

[Les:] Agreed = =E2=80=93 thanx for spotting this.

=C2=A0=

=C2=A0=C2=A0 Les

=C2= =A0

Thanks,

Regards,

Bruno

________________________________________________________________=
_________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc<=
/pre>

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
u>=C2=A0


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.=



I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.
____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.
____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.
____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.

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


--001a11412b584ef54f0536de6ae4-- From nobody Tue Jul 5 01:49:58 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532D312B037 for ; Tue, 5 Jul 2016 01:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c06PPdFTGCGt for ; Tue, 5 Jul 2016 01:49:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8367F12D187 for ; Tue, 5 Jul 2016 01:49:51 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 528CA2DC3B4; Tue, 5 Jul 2016 10:49:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2D3C74C099; Tue, 5 Jul 2016 10:49:50 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0294.000; Tue, 5 Jul 2016 10:49:50 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution-01 Thread-Index: AdHV6o0E/qlZMiJZSjCljyO2j8K1qgAoxuegAAKLfAA= Date: Tue, 5 Jul 2016 08:49:49 +0000 Message-ID: <2927_1467708590_577B74AE_2927_1037_7_53C29892C857584299CBF5D05346208A0F92B925@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <19159_1467634029_577A516D_19159_16159_10_53C29892C857584299CBF5D05346208A0F92A139@OPEXCLILM21.corporate.adroot.infra.ftgroup> <33389c9b78894e60a822caaab2ea509a@XCH-ALN-001.cisco.com> In-Reply-To: <33389c9b78894e60a822caaab2ea509a@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 08:49:56 -0000 Les, Thanks for the clarification with regarding to the meaning of SID. Now, if the draft considers index, I'm afraid comparing index from differen= t protocols (using different SRGB) is meaningless. e.g. IGP1:=20 SRGB: 1000-2000 Mapping entry: (PFX, 1.1.1.1/32, 1, 1, 0, 0) IGP2:=20 SRGB: 2000-3000 Mapping entry: (PFX, 2.2.2.2/32, 1, 1, 0, 0) In this example, looking at the index, there is a SID conflict as the same = index is given to 2 prefixes. However, what matters is the conflict in the forwarding table. And in the M= PLS one, the first mapping uses label 1001 while the second mapping uses la= bels 2001, so there is no conflict. More importantly, we can also craft an example where SID index do not confl= ict, while MPLS label conflict. Thanks, -- Bruno > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Tuesday, July 05, 2016 9:22 AM > To: DECRAENE Bruno IMT/OLN > Cc: spring@ietf.org > Subject: RE: draft-ietf-spring-conflict-resolution-01 >=20 > Bruno - >=20 > I agree with your point. The draft is only discussing SIDs as index value= s. We will add some > language to make that clear in the next revision. > Thanx. >=20 > Les >=20 >=20 > > -----Original Message----- > > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > > Sent: Monday, July 04, 2016 5:07 AM > > To: Les Ginsberg (ginsberg) > > Cc: spring@ietf.org > > Subject: draft-ietf-spring-conflict-resolution-01 > > > > Hi Les, > > > > When talking about SID conflicts I think the document should spell out = what it > > means by SID. > > > > Indeed, the architecture document defines SID as: > > "SID: a Segment Identifier. Examples of SIDs are: a MPLS label, an > > index value in a MPLS label space, an IPv6 address. Other types of > > SIDs can be defined in the future." > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08#sectio= n-2 > > > > > > Indeed, when talking about SID conflicts > > - it matters that we do not compare apple and orange i.e. MPLS labels = and > > index in SRGB. > > - we can't compare index from different protocols (e.g. OSPF & IS-IS) u= nless > > they advertise the same SRGB (which is only a specific case). > > > > > > So either the document considers that a SID is an "index" and in this c= ase, we > > just can't compare them across protocols. > > Or it consider that a SID is a "MPLS labels" and in this case, as the I= GP > > advertisement typically advertise index for global SIDs, there is a nee= d to > > maps the received SID advertisement into the SRGB of the local node. > > > > This needs to be crystal clear. > > > > Thanks > > -- Bruno > > > > > > __________________________________________________________ > > __________________________________________________________ > > _____ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, e= xploites > > ou copies sans autorisation. Si vous avez recu ce message par erreur, v= euillez > > 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 distribute= d, > > 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 b= een > > modified, changed or falsified. > > Thank you. ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Jul 5 03:03:50 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CD12B012 for ; Tue, 5 Jul 2016 03:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsOyv7t-VaLg for ; Tue, 5 Jul 2016 03:03:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6D412B049 for ; Tue, 5 Jul 2016 03:03:44 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 89A4722B50B8F; Tue, 5 Jul 2016 18:03:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u65A3LjV013917; Tue, 5 Jul 2016 18:03:21 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: References: <7b5699d429614579a332ae7832a27b58@XCH-ALN-001.cisco.com> To: "Les Ginsberg (ginsberg)" MIME-Version: 1.0 X-KeepSent: 79A3CFC1:9E8DBF21-48257FE7:002CCD2A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Tue, 5 Jul 2016 18:03:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-05 18:03:06, Serialize complete at 2016-07-05 18:03:06 Content-Type: multipart/alternative; boundary="=_alternative 00373D7E48257FE7_=" X-MAIL: mse01.zte.com.cn u65A3LjV013917 Archived-At: Cc: "spring@ietf.org" , "rraszuk@gmail.com" , Robert Raszuk Subject: [spring] =?gb2312?b?tPC4tDogUkU6IFJlOiAgtPC4tDogUkU6IGRyYWZ0LWll?= =?gb2312?b?dGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24=?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 10:03:49 -0000 This is a multipart message in MIME format. --=_alternative 00373D7E48257FE7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TGVzLA0KDQpCZWZvcmUgU1IsIGZvciBhbGwgSSBrbm93LCB0aGUgTVBMUyBmb3J3YXJkaW5nIGJl aGF2aW9yIGZvciAiQ2FycmllcidzIA0KQ2FycmllciIgb2Z0ZW4gaW5jbHVkZXMgdHdvIGZvcm1z LCBlaXRoZXIgYW4gTERQIGxhYmVsIGZvciBEZXN0aW5hdGlvbiBaLCANCm9yIGEgQkdQIGxhYmVs ICh1bmRlciBhbiBvdXRlci1sYWJlbCBmb3IgQkdQIG5leHRob3Agcm91dGVyKSBmb3IgDQpEZXN0 aW5hdGlvbiBaLCBpLmUuIGluZ3Jlc3Mgbm9kZSBpbiBzaXRlIEEgdXNlIGFuIGxhYmVsIGRpcmVj dGx5IHRvIA0KZGVzdGluYXRpb24gWiByYXRoZXIgdGhhbiBmaXJzdCBhbiBsYWJlbCB0byBDRS1C IHRoZW4gYW4gbGFiZWwgdG8gDQpkZXN0aW5hdGlvbiBaLg0KSSBkb24ndCBrbm93IGlmIHRoZXJl IGFyZSBvdGhlciBkb2N1bWVudHMsIGV4Y2VwdCByZmM0MzY0LCB0byBkZWZpbmUgb3RoZXIgDQpm b3J3YXJkaW5nIGJlaGF2aW9ycy4gUGxlYXNlIHByb21wdCBtZS4NCg0KSG93ZXZlciwgSSBhZ3Jl ZSB0aGF0IGl0IHdpbGwgYmUgbW9yZSBmbGV4aWJsZSB3aXRoIGZvcndhcmRpbmcgYmVoYXZpb3Ig DQp3aGVuIHVzaW5nIFNSLiBJdCBpcyBwb3NzaWJsZSB0byBlbmNhcHN1bGF0ZSBsYWJlbCBzdGFj ayBhcyB5b3UgZ2l2ZW46DQoNCiAgTGFiZWwgZm9yIENFLUIgYXNzaWduZWQgYnkgUEUtQQ0KICBM YWJlbCBmb3IgRGVzdGluYXRpb24gWiAoYXNzaWduZWQgYnkgQ0UtQiA/PykNCg0KQnV0IHRoZSBw cm9ibGVtIGlzIHN0aWxsIGV4aXN0aW5nOg0KMSkgSG93IGFib3V0IGlmICJMYWJlbCBmb3IgQ0Ut QiIgY29uZmxpY3Qgd2l0aCBhbnkgcHJlZml4LXNpZCBpbiBzaXRlIEEgPw0KMikgSXQgaXMgdGhl IGluZ3Jlc3Mgbm9kZSBpbiBzaXRlIEEgdG8gZW5jYXBzdWxhdGUgIkxhYmVsIGZvciBEZXN0aW5h dGlvbiANCloiLCBzbywgaG93IGFib3V0ICJMYWJlbCBmb3IgRGVzdGluYXRpb24gWiIgY29uZmxp Y3Qgd2l0aCBhbnkgcHJlZml4LXNpZCANCmluIHNpdGUgQT8gSW4gb3RoZXIgd29yZHMsIGhvdyBk b2VzIHRoZSBpbmdyZXNzIG5vZGUgaW4gc2l0ZSBBIHRvIGRvIA0KY29uZmxpY3QgcHJvY2VzcyB3 aGVuIHRoZSBhYm92ZSBjb25mbGljdCBvY2N1cnM/IEFuZCwgaG93IGRvZXMgdGhlIGluZ3Jlc3Mg DQpub2RlIGVuc3VyZSB0aGF0IGl0IG5ldmVyIGFjdCBhcyBhIHRyYW5zaXQgcm9sZSBzbyB0aGF0 IG5vIG5lZWQgdG8gY3JlYXRlIA0KSUxNIGZvciBEZXN0aW5hdGlvbiBaIGFuZCBpZ25vcmUgdGhl IHNpZCBjb25mbGljdCBwcm9jZXNzIChJIGd1ZXNzIHRoYXQgDQptYXliZSB5b3UgcmVnYXJkIHRo YXQgRlROIG5lZWQgbm90IGludm9sdmUgY29uZmxpY3QgcXVlc3Rpb25zLCBhcyBTUiBsYWJlbCAN CmlzIG91dC1sYWJlbD8pLg0KDQoNClRoYW5rcw0KDQpEZWNjYW4NCg0KDQoNCg0KDQoNCg0KIkxl cyBHaW5zYmVyZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29tPiANCjIwMTYtMDctMDUg MTQ6MDUNCg0KytW8/sjLDQoicGVuZy5zaGFvZnVAenRlLmNvbS5jbiIgPHBlbmcuc2hhb2Z1QHp0 ZS5jb20uY24+LCBSb2JlcnQgUmFzenVrIA0KPHJvYmVydEByYXN6dWsubmV0PiwgDQqzrcvNDQoi cnJhc3p1a0BnbWFpbC5jb20iIDxycmFzenVrQGdtYWlsLmNvbT4sICJzcHJpbmdAaWV0Zi5vcmci IA0KPHNwcmluZ0BpZXRmLm9yZz4NCtb3zOINClJFOiBSZTogW3NwcmluZ10gtPC4tDogUkU6IGRy YWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KDQoNCg0KDQoNCkRlY2NhbiCo Qw0KIA0KVGhlcmUgaXMgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHdoYXQgbGFiZWxzIG1heSBiZSBp bmNsdWRlZCBpbiB0aGUgDQplbmNhcHN1bGF0aW9uIGZvciBhIHBhY2tldCBhbmQgd2hhdCBsYWJl bHMgd2lsbCBiZSChsHRvcCBvZiBzdGFja6GxLiBJdCBpcyANCm9ubHkgdGhlIGxhdHRlciB3aGlj aCBnZXRzIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4NCiANClRvIHJlYWNoIGRl c3RpbmF0aW9ucyBpbiBTaXRlIEIgZnJvbSBhIG5vZGUgaW4gU2l0ZSBBIHRoZSBwYWNrZXQgaGFz IHRvIGJlIA0Kc2VudCB0byBhIENFIGluIHNpdGUgQiB2aWEgYSBQRSBhY2Nlc3NpYmxlIHRvIG5v ZGVzIGluIFNpdGUgQS4gU28gDQplbmNhcHN1bGF0aW9uIHRvIGEgZGVzdGluYXRpb24gWiBpbiBz aXRlIEIgd291bGQgbG9vayBsaWtlOg0KIA0KICBMYWJlbCBmb3IgQ0UtQiBhc3NpZ25lZCBieSBQ RS1BDQogIExhYmVsIGZvciBEZXN0aW5hdGlvbiBaDQogDQpOb2RlcyBpbiBTaXRlIEEgd2lsbCBu ZXZlciBQT1AgdGhlIHRvcCBsYWJlbCCoQyBzbyB0aGV5IHdpbGwgbmV2ZXIgcmVjZWl2ZSANCmEg cGFja2V0IGFkZHJlc3NlZCB0byBaIHdoZXJlIHRoZSB0b3AgbGFiZWwgaXMgobBaobEuIEFueSBs YWJlbCAob3IgdGhlIA0KU0lEIHVzZWQgdG8gZGVyaXZlIGl0KSB0aGF0IHdvbqGvdCBiZSB0b3Ag b2Ygc3RhY2sgaW4gU2l0ZSBBIGlzIG5vdCBwYXJ0IA0Kb2YgdGhlIGRhdGFiYXNlIHVzZWQgZm9y IGNvbmZsaWN0IHJlc29sdXRpb24gaW4gU2l0ZSBBLg0KIA0KTm90ZSB0aGF0IHRoaXMgaXMgc3Rh bmRhcmQgTVBMUyBmb3J3YXJkaW5nIGJlaGF2aW9yIGZvciB0aGlzIGRlcGxveW1lbnQgqEMgDQp0 aGUgdXNlIG9mIFNSIGhhcyBub3QgY2hhbmdlZCB0aGlzIGluIGFueSB3YXkuDQogDQogICBMZXMN CiANCiANCiANCkZyb206IHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24gW21haWx0bzpwZW5nLnNoYW9m dUB6dGUuY29tLmNuXSANClNlbnQ6IE1vbmRheSwgSnVseSAwNCwgMjAxNiA4OjU3IFBNDQpUbzog Um9iZXJ0IFJhc3p1aw0KQ2M6IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOyBycmFzenVrQGdtYWls LmNvbTsgc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiC08Li0OiBSZTogW3NwcmluZ10gtPC4tDog UkU6IA0KZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg0KIA0KSGkgUm9iZXJ0 LCANCg0KSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gYWRkIG1vcmUgZGVzY3JpcHRpb24gdG8gc2Vj dGlvbiA0IHRvIGVsaW1pbmF0ZSANCmNvbmZ1c2lvbi4gTm93IHdlIG9ubHkgZ2V0IGEgInN0YXRl bWVudCIgdGhhdCB0aGVyZSBpcyBubyBwcm9ibGVtLCBidXQgbm90IA0KaG93LiBGb3IgZXhhbXBs ZSwgaWYgc2VwYXJhdGUgImNvbnRleHRzIiBpbiBkYXRhIHBsYW5lIGFzIHlvdSBzYWlkIGlzIGEg DQpzdWdnZXN0aW9uIG1ldGhvZCB0byBmdWxmaWxsIHRoaXMgY2FzZT8gTm90ZSB0aGF0IElMTSBj b3JyZXNwb25kaW5nIHRvIFNSIA0KbGFiZWwgaGFzIG5vICJjb250ZXh0cyIgaW4gZGF0YSBwbGFu ZSBjdXJyZW50bHkuIA0KDQpMZXQncyBmaXJzdCBjb25jZXJuIGlzc3VlcyBpbiBjb250cm9sIHBs YW5lLiANClN1cHBvc2VkIHRoYXQgdGhlcmUgYXJlIHNpdGUgQSxCLEMgYXR0YWNoaW5nIHRvIHBy b3ZpZGVyIG5ldHdvcmsgdGhyb3VnaCANClBFMSxQRTIsUEUzIHJlc3BlY3RpdmVseSwgYW5kIEEs QixDIGJlbG9uZyB0byBzYW1lIHZyZiBuZXR3b3JrLiBTdXBwb3NlZCANCnRoYXQgZGVzdGluYXRp b24gMS4xLjEuMSBpbiBzaXRlIEEsIDIuMi4yLjIgaW4gc2l0ZSBCLCAzLjMuMy4zIGluIHNpdGUg QyANCmFzc2lnbiB0aGUgc2FtZSBwcmVmaXgtc2lkLiANCkJlY2F1c2UgSSBoYXZlIG5vIGVudGly ZSBpZGVhIGFib3V0IHRoZSBzb2x1dGlvbiBiZWhpbmQgc2VjdGlvbiA0LCBJIGp1c3QgDQpsaXN0 IHRoZSBxdWVzdGlvbnMgYXMgZm9sbG93aW5nOiANCg0KMSkgUEUxJ3MgQkdQIHdpbGwgcmVjZWl2 ZSBWUE52NCBwcmVmaXgoMi4yLjIuMikgZnJvbSBQRTIgd2l0aCBwcmVmaXgtc2lkIA0Kc2FtZSBh cyBWUE52NCBwcmVmaXgoMy4zLjMuMykgZnJvbSBQRTMsIGRvZXMgaXQgZG8gY29uZmxpY3QgcHJv Y2VzcyBpbiANCnRoaXMgcGhhc2U/IA0KMikgUEUxJ3MgQkdQIHdpbGwgaW1wb3J0IFZQTnY0IHJv dXRlIHRvIGxvY2FsIHZyZiwgc28gaW4gdGhlIHNhbWUgVlBOIA0Kcm91dGluZyB0YWJsZSwgcHJl Zml4KDIuMi4yLjIpIGFuZCBwcmVmaXgoMy4zLjMuMykgaGF2ZSB0aGUgc2FtZSANCnByZWZpeC1z aWQsIGRvZXMgaXQgZG8gY29uZmxpY3QgcHJvY2VzcyBpbiB0aGlzIHBoYXNlPyANCjMpIFBFMSdz IElHUCB3aWxsIHJlZGlzdHJpYnV0ZSBCR1Agcm91dGVzIGluIHRoZSB2cmYsIHNvIElHUCB3aWxs IGFsc28gc2VlIA0KdHdvIHByZWZpeGVzIGhhdmUgdGhlIHNhbWUgcHJlZml4LXNpZCwgZG9lcyBp dCBkbyBjb25mbGljdCBwcm9jZXNzIGluIHRoaXMgDQpwaGFzZT8gDQo0KSBFYWNoIHJvdXRlciBp biBzaXRlIEEgd2lsbCByZWNlaXZlIHBlcmZpeCBmbG9vZCwgc28gYXQgZWFjaCByb3V0ZXIgaXRz IA0KSUdQIHdpbGwgYWxzbyBzZWUgdHdvIHByZWZpeGVzIGhhdmUgdGhlIHNhbWUgcHJlZml4LXNp ZCwgZG9lcyBpdCBkbyANCmNvbmZsaWN0IHByb2Nlc3MgaW4gdGhpcyBwaGFzZT8gDQoNCg0KVGhh bmtzIA0KDQpEZWNjYW4gDQoNCg0KDQoNCg0KUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ+IA0Kt6K8/sjLOiAgcnJhc3p1a0BnbWFpbC5jb20gDQoyMDE2LTA3LTA0IDE2OjAwIA0KDQoN CsrVvP7Iyw0KcGVuZy5zaGFvZnVAenRlLmNvbS5jbiwgDQqzrcvNDQoiTGVzIEdpbnNiZXJnIChn aW5zYmVyZykiIDxnaW5zYmVyZ0BjaXNjby5jb20+LCAic3ByaW5nQGlldGYub3JnIiA8DQpzcHJp bmdAaWV0Zi5vcmc+IA0K1vfM4g0KUmU6IFtzcHJpbmddILTwuLQ6IFJFOiBkcmFmdC1pZXRmLXNw cmluZy1jb25mbGljdC1yZXNvbHV0aW9uDQogDQoNCg0KDQoNCg0KDQoNCg0KSGkgUGVuZywgDQoN Ck9uIHRoZSBwb2ludCAjMiB5b3UgYXJlIHJpZ2h0IHRoYXQgZXh0ZXJuYWxseSByZWNlaXZlZCBT SURzIHdpbGwgYmUgDQppbnN0YWxsZWQgaW4gdGhlIGRhdGEgcGxhbmUgb2YgUEVzLiAgDQoNCkhv d2V2ZXIgeW91IG5lZWQgdG8gb2JzZXJ2ZSB0aGF0IHRoZXkgd2lsbCBiZSBpbnN0YWxsZWQgaW4g Y29tcGxldGVseSANCnNlcGFyYXRlICJjb250ZXh0cyIgaW4gZGF0YSBwbGFuZSBoZW5jZSBjdXJy ZW50IGFkZGl0aW9uIChhZnRlciBJIGJyb3VnaHQgDQp0aGlzIGlzc3VlIGZldyB3ZWVrcyBiYWNr KSBoYXMgYmVlbiBhY2N1cmF0ZWx5IGFkZHJlc3NlZCBpbiBuZXcgc2VjdGlvbnMgDQozLjIuNiBh bmQgNC4gIA0KDQpBbGwgd2hhdCB5b3UgYXJlIHNheWluZyBpcyB0cnVlIGFuZCB0aGUgIGN1cnJl bnQgZHJhZnQgZW5hYmxlcyBvbmUgdG8gZG8gDQp0aGF0IHlldCB0byBrZWVwIGNvbnNpc3RlbnQg YmFzZSB0b3BvbG9neSBpbiB0aGUgbmV0d29yay4gV2VsbCBtb2R1bG8gDQpjb21tZW50cyBmcm9t IEJydW5vIHdoaWNoIGhhdmUgbm90IGJlZW4geWV0IHdlbGwgYWRkcmVzc2VkLiAgDQoNCkNoZWVy cywNClIuIA0KDQoNCk9uIE1vbiwgSnVsIDQsIDIwMTYgYXQgNDozMiBBTSwgPHBlbmcuc2hhb2Z1 QHp0ZS5jb20uY24+IHdyb3RlOiANCkxlcywgDQoNClNlZSBpbmxpbmUuIA0KDQoNCg0KDQoNCiJM ZXMgR2luc2JlcmcgKGdpbnNiZXJnKSIgPGdpbnNiZXJnQGNpc2NvLmNvbT4gDQoyMDE2LTA3LTAy IDAxOjEzIA0KIA0KDQoNCsrVvP7Iyw0KInBlbmcuc2hhb2Z1QHp0ZS5jb20uY24iIDxwZW5nLnNo YW9mdUB6dGUuY29tLmNuPiwgDQqzrcvNDQoic3ByaW5nQGlldGYub3JnIiA8c3ByaW5nQGlldGYu b3JnPiANCtb3zOINClJFOiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNv bHV0aW9uDQogDQoNCg0KDQoNCg0KDQoNCg0KDQpEZWNjYW4gLSANCiAgDQpGcm9tOiBwZW5nLnNo YW9mdUB6dGUuY29tLmNuIFttYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbl0gDQpTZW50OiBG cmlkYXksIEp1bHkgMDEsIDIwMTYgMjo0NiBBTQ0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2Jlcmcp DQpDYzogc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtaWV0Zi1z cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiANCiAgDQpIaXMgTGVzLCANCg0KMSkgRnJvbSBpbXBs ZW1lbnRhdGlvbiwgYmVjYXVzZSBwcmVmZXJlbmNlIGFsZ29yaXRobSBpcyBwcm90b2NvbCANCmlu ZGVwZW5kZW50LCBpdCBpcyBiZXR0ZXIgdG8gZG8gY29uZmxpY3QgcmVzb2x1dGlvbiBhdCBhIGNv bW1vbiBwbGFjZSwgbm90IA0KYXQgaW5kaXZpZHVhbCBwcm90b2NvbCBpbnN0YW5jZS4gRm9yIGV4 YW1wbGUsIHdlIGNhbiBkbyBwcmVmaXgtY29uZmxpY3QgDQpyZXNvbHV0aW9uIHdoZW4gZ2VuZXJh dGUgdGhlIHByZWZlcmVuY2UgRklCIGVudHJ5IGF0IHRoZSBjb21tb24gcGxhY2UuIEZvciANCmEg cHJlZmVyZW5jZSBGSUIgZW50cnksIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIG1heSBnZXQgZnJv bSBPU1BGIGJ5IA0KYWRtaW5pc3RyYXRpdmUgZGlzdGFuY2UsIGJ1dCB0aGUgU0lEIGluZm9ybWF0 aW9uIG1heSBnZXQgZnJvbSBJU0lTIGJ5IA0KcHJlZml4LWNvbmZsaWN0IGFsZ29yaXRobS4gVGhl biB3ZSBjYW4gZG8gc2lkLWNvbmZsaWN0IHJlc29sdXRpb24gd2hlbiANCmdlbmVyYXRlIHRoZSBT SUQtTElCIGVudHJ5IGFjY29yZGluZyB0byB0aGUgYWJvdmUgRklCIGVudHJ5IGFuZCBvdGhlciAN CnNvdXJjZXMsIGl0IHdpbGwgc2VsZWN0IGEgcHJlZmVyZW5jZSBGRUMgdG8gcHJvdmlkZSBmb3J3 YXJkaW5nIA0KaW5mb3JtYXRpb24uIA0KU28sIHByZWZlcmVuY2UgYWxnb3JpdGhtIHBlciBwcmVm aXgvZmVjIGlzIGVub3VnaC4gUGVyIHJhbmdlIGlzIHBvc3NpYmxlLCANCmJ1dCBpbXBsZW1lbnRh dGlvbiBpcyBjb21wbGV4LiBNb3JlIGNvbXBsZXggaXMgZm9yICJpZ25vciBvdmVybGF5IiBwZXIg DQpyYW5nZS4gDQoNCltMZXM6XSBJbXBsZW1lbnRhdGlvbi13aXNlLCB5b3UgYXJlIGZyZWUgdG8g aW1wbGVtZW50IHRoaXMgaW4gYW55IG1vZHVsZSANCnlvdSBsaWtlIHNvIGxvbmcgYXMgd2l0aCB0 aGUgc2FtZSBkYXRhYmFzZSB5b3UgY29tZSB1cCB3aXRoIHRoZSBzYW1lIA0KYW5zd2VyIGFzIG90 aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrLiANClRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIKGwUXVh cmFudGluZaGxIGFuZCChsElnbm9yZSBPdmVybGFwobEgaXMgdGhhdCB0aGUgDQpsYXR0ZXIgYXR0 ZW1wdHMgdG8gdXNlIHRob3NlIHBvcnRpb25zIG9mIGEgcmFuZ2Ugd2hpY2ggZG8gbm90IGhhdmUg DQpjb25mbGljdHMgd2l0aCBvdGhlciBlbnRyaWVzLiBUaGUgY29zdCBvZiBkb2luZyBzbyBpcyBo YXZpbmcgdG8gY3JlYXRlIKGwDQpkZXJpdmVkIGVudHJpZXOhsSB3aGljaCByZXByZXNlbnQgdGhv c2Ugc3ViLXJhbmdlcyB3aGljaCBkby9kbyBub3QgaGF2ZSANCmNvbmZsaWN0cy4gRHVlIHRvIHRo ZSBhZGRlZCBjb21wbGV4aXR5IHRoaXMgaXMgTk9UIHRoZSBmaXJzdCBjaG9pY2Ugb2YgdGhlIA0K YXV0aG9ycy4gDQpJZiBJIHdlcmUgdG8gY2F0ZWdvcml6ZSB0aGUgdHdvIGFsZ29yaXRobXMgdXNp bmcgeW91ciB0ZXJtaW5vbG9neSChsA0KUXVhcmFudGluZaGxIHdvdWxkIGJlIKGwcGVyIHJhbmdl obEgd2hpbGUgobBJZ25vcmUgT3ZlcmxhcKGxIHdvdWxkIGJlIKGwDQpwZXIgcHJlZml4L0ZFQ6Gx LiBTbyBpdCBpcyB0aGUgbGF0dGVyIHdoaWNoIGlzIG1vcmUgY29tcGxleCB0byBpbXBsZW1lbnQu IA0KW0RlY2Nhbl0gWW91IGFyZSByaWdodCwgYXMgcGVyIHByZWZpeC9GRUMgaXMgYWN0dWFsbHkg dG8gc3BsaXQgdGhlIA0Kb3JpZ2luYWwgcmFuZ2UgdG8gdGhlIHNtYWxsZXN0IG9uZXMuIE15IG1l YW5pbmcgaXMgdGhhdCB0aGVyZSBpcyBubyByYW5nZSANCmlkZWEgZHVyaW5nIGNvbmZsaWN0IHBy b2Nlc3MgcGhhc2UgYXQgdGhlIGNvbW1vbiBwbGFjZSwgYWxsIGlzIGRvbmUgYmFzZWQgDQpvbiB0 aGUgZXhpc3RpbmcgZGF0YSBzdHJ1Y3R1cmUgcGVyIHByZWZpeC9GRUMuIE1hcHBpbmcgcmFuZ2Ug b25seSBhcHBlYXIgDQppbiB0aGUgaW5kaXZpZHVhbCBwcm90b2NvbCBpbnN0YW5jZSwgYnV0IGl0 IGlzIGFsd2F5cyB0byBiZSBzcGxpdCB0byB0aGUgDQpzbWFsbGVzdCBvbmVzLCBmb3IgcmEgZm9y IGNvbmZsaWN0IGZ1bmN0aW9uLiANCg0KMikgVGhlIHJlc3RyaWN0aW9ucyBpbiBuZXcgc2VjdGlv biAiU2NvcGUgb2YgU1ItTVBMUyBTSUQgQ29uZmxpY3RzIiBtYXliZSANCm5vdCB0cnVlLiBQbGVh c2UganVzdCBjb25zaWRlciAiQ2FycmllciBvZiBDYXJyaWVyIiBjYXNlIHdoaWNoIGRlcGxveSAN CklHUCtMRFAgYmV0d2VlbiBQRSBhbmQgQ0UuIEl0IGlzIHBvc3NpYmxlIHRvIGRlcGxveSBTUiBM U1AgaW4gdGhlIHNlY29uZCANCmxldmVsIGNhcnJpZXIsIHNvIHRoYXQgYW4gU1IgTFNQIGlzIGJ1 aWxkaW5nIGZyb20gb25lIHNpdGUgdG8gYW5vdGhlciANCmFjcm9zcyB0aGUgZmlyc3QgbGV2ZWwg Y2Fycmllciwgc2FtZSBhcyBhbiBMRFAgTFNQLiBUaGlzIG1lYW5zIFNJRHMgDQphc3NvY2lhdGVk IHdpdGggZGVzdGluYXRpb25zIGluIFNpdGUgQSB3aWxsIGJlIGluc3RhbGxlZCBpbiB0aGUgZm9y d2FyZGluZyANCnBsYW5lIG9mIHJvdXRlcnMgaW4gU2l0ZSBCLiANCg0KW0xlczpdIFdlIGhhdmUg bG9va2VkIGF0IKGwQ2FycmllciBvZiBDYXJyaWVyobEgYW5kIHdlIGRpc2FncmVlIHdpdGggeW91 ciANCmNvbmNsdXNpb24uIFRvIHJlYWNoIGRlc3RpbmF0aW9ucyBpbiBTaXRlIEIgZnJvbSBTaXRl IEEgcGFja2V0cyB3aWxsIG5lZWQgDQp0byB0cmF2ZXJzZSB0aGUgUEUocykgY29ubmVjdGVkIHRv IFNpdGUgQS4gV2hhdCB3aWxsIGJlIGluc3RhbGxlZCBpbiB0aGUgDQpmb3J3YXJkaW5nIHBsYW5l IG9mIHJvdXRlcnMgaW4gU2l0ZSBBIHdpbGwgYmUgbGFiZWxzIGFzc29jaWF0ZWQgd2l0aCB0aGUg DQpTSUQgb2YgdGhlIFBFIKhDIG5vdCB0aGUgU0lEcyBmb3IgZGVzdGluYXRpb25zIGluIFNpdGUg Qi4gSW4gZmFjdCwgaXQgaXMgDQpwb3NzaWJsZSBmb3IgZGVzdGluYXRpb24gMS4xLjEuMSBpbiBT aXRlIEEgdG8gdXNlIHRoZSBzYW1lIFNJRCBhcyANCmRlc3RpbmF0aW9uIDIuMi4yLjIgaW4gU2l0 ZSBCLiBUaGlzIGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQgb2YgdGhlIA0KZHJhZnQuIA0KW0Rl Y2Nhbl0gU29ycnksIEkgY2Fubm90IHVuZGVyc3RhbmQgaG93IHRvIGZ1bGZpbGwgdGhpcyBjYXNl IHlldC4gSU1PLCANCnBhY2tldHMgZnJvbSBzaXRlIEEgbmVlZCBjb250YWluIFNJRHMgZm9yIGRl c3RpbmF0aW9ucyBpbiBzaXRlIEIsIHNvIHRoYXQgDQpwYWNrZXRzIGNhbiBmb3J3YXJkIHRvIHRo ZSBzcGVjaWZpYyBkZXN0aW5hdGlvbiBjb3JyZWN0bHksIHRoZSBTSUQgb2YgdGhlIA0KUEUgY2Fu IG9ubHkgYmUgdXNlZCB0byBmb3J3YXJkIHBhY2tldHMgdG8gdGhlIFBFLiBBbHRob3VnaCwgYXQg dGhlIGluZ3Jlc3MgDQpub2RlIGluIHNpdGUgQSwgd2UgY2FuIGVuY2Fwc3VsYXRlIFNJRCBvZiB0 aGUgUEUgYWdhaW4gdG8gaGlkZSBTSUQgb2Ygc2l0ZSANCkIgYmVmb3JlIHNlbmRpbmcgcGFja2V0 cywgdGhlIGluZ3Jlc3Mgbm9kZSBpbiBzaXRlIEEgYW5kIHRoZSBQRSBuZWVkIHN0aWxsIA0Kc2Vl IHRoZSBTSUQgb2Ygc2l0ZSBCLiBBIG5vZGUgaW4gc2l0ZSBBIGNhbiBub3QgZW5zdXJlIGl0IHdp bGwgb25seSBhY3QgYXMgDQphIHRyYW5zaXQgcm9sZS4gQ291bGQgeW91IGV4cGxhaW4gbW9yZT8g DQoNCiAgIExlcyANCg0KVGhhbmtzIA0KDQpEZWNjYW4gDQogIA0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAN CihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg YW5kIGNvbmZpZGVudGlhbCANCmFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ug b2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IA0KYW4gaW50ZW5kZWQgcmVjaXBp ZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIg DQpkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgDQppbW1lZGlhdGVseS4gDQogIA0K ICANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQooYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgDQphbmQgaXMgaW50ZW5k ZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJl IG5vdCANCmFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIA0KZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiANCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5 IHVzIA0KaW1tZWRpYXRlbHkuDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIA0KKGFuZCBhbnkg YXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlk ZW50aWFsIA0KYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgDQphbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciANCmRpc3NlbWlu YXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmltbWVkaWF0ZWx5Lg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcg bGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0KDQoNCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFu ZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4g IElmIHlvdSBhcmUgbm90IA0KYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwg cmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVz ZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIA0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0 IGFuZCBub3RpZnkgdXMgDQppbW1lZGlhdGVseS4NCiANCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 00373D7E48257FE7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxlcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlZm9yZSBTUiwgZm9yIGFsbCBJIGtub3csIHRo ZSBNUExTDQpmb3J3YXJkaW5nIGJlaGF2aW9yIGZvciAmcXVvdDtDYXJyaWVyJ3MgQ2FycmllciZx dW90OyBvZnRlbiBpbmNsdWRlcyB0d28NCmZvcm1zLCBlaXRoZXIgYW4gTERQIGxhYmVsIGZvciBE ZXN0aW5hdGlvbiBaLCBvciBhIEJHUCBsYWJlbCAodW5kZXIgYW4NCm91dGVyLWxhYmVsIGZvciBC R1AgbmV4dGhvcCByb3V0ZXIpIGZvciBEZXN0aW5hdGlvbiBaLCBpLmUuIGluZ3Jlc3Mgbm9kZQ0K aW4gc2l0ZSBBIHVzZSBhbiBsYWJlbCBkaXJlY3RseSB0byBkZXN0aW5hdGlvbiBaIHJhdGhlciB0 aGFuIGZpcnN0IGFuIGxhYmVsDQp0byBDRS1CIHRoZW4gYW4gbGFiZWwgdG8gZGVzdGluYXRpb24g Wi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZG9uJ3Qga25v dyBpZiB0aGVyZSBhcmUgb3RoZXIgZG9jdW1lbnRzLA0KZXhjZXB0IHJmYzQzNjQsIHRvIGRlZmlu ZSBvdGhlciBmb3J3YXJkaW5nIGJlaGF2aW9ycy4gUGxlYXNlIHByb21wdCBtZS48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvd2V2ZXIsIEkgYWdyZWUg dGhhdCBpdCB3aWxsIGJlIG1vcmUNCmZsZXhpYmxlIHdpdGggZm9yd2FyZGluZyBiZWhhdmlvciB3 aGVuIHVzaW5nIFNSLiBJdCBpcyBwb3NzaWJsZSB0byBlbmNhcHN1bGF0ZQ0KbGFiZWwgc3RhY2sg YXMgeW91IGdpdmVuOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7IExhYmVsIGZvciBDRS1CIGFzc2lnbmVkIGJ5IFBFLUE8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBMYWJlbCBmb3IgRGVzdGluYXRp b24gWiAoYXNzaWduZWQNCmJ5IENFLUIgPz8pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5CdXQgdGhlIHByb2JsZW0gaXMgc3RpbGwgZXhpc3Rpbmc6PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xKSBIb3cgYWJvdXQgaWYg JnF1b3Q7TGFiZWwgZm9yIENFLUImcXVvdDsNCmNvbmZsaWN0IHdpdGggYW55IHByZWZpeC1zaWQg aW4gc2l0ZSBBID88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIp IEl0IGlzIHRoZSBpbmdyZXNzIG5vZGUgaW4gc2l0ZSBBDQp0byBlbmNhcHN1bGF0ZSAmcXVvdDtM YWJlbCBmb3IgRGVzdGluYXRpb24gWiZxdW90Oywgc28sIGhvdyBhYm91dCAmcXVvdDtMYWJlbA0K Zm9yIERlc3RpbmF0aW9uIFomcXVvdDsgY29uZmxpY3Qgd2l0aCBhbnkgcHJlZml4LXNpZCBpbiBz aXRlIEE/IEluIG90aGVyDQp3b3JkcywgaG93IGRvZXMgdGhlIGluZ3Jlc3Mgbm9kZSBpbiBzaXRl IEEgdG8gZG8gY29uZmxpY3QgcHJvY2VzcyB3aGVuDQp0aGUgYWJvdmUgY29uZmxpY3Qgb2NjdXJz PyBBbmQsIGhvdyBkb2VzIHRoZSBpbmdyZXNzIG5vZGUgZW5zdXJlIHRoYXQgaXQNCm5ldmVyIGFj dCBhcyBhIHRyYW5zaXQgcm9sZSBzbyB0aGF0IG5vIG5lZWQgdG8gY3JlYXRlIElMTSBmb3IgRGVz dGluYXRpb24NClogYW5kIGlnbm9yZSB0aGUgc2lkIGNvbmZsaWN0IHByb2Nlc3MgKEkgZ3Vlc3Mg dGhhdCBtYXliZSB5b3UgcmVnYXJkIHRoYXQNCkZUTiBuZWVkIG5vdCBpbnZvbHZlIGNvbmZsaWN0 IHF1ZXN0aW9ucywgYXMgU1IgbGFiZWwgaXMgb3V0LWxhYmVsPykuPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlY2NhbjwvZm9udD4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0xlcyBH aW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7DQombHQ7Z2luc2JlcmdAY2lzY28uY29tJmd0OzwvYj4g PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYtMDctMDUgMTQ6 MDU8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7cGVuZy5zaGFvZnVAenRlLmNvbS5jbiZxdW90OyAmbHQ7cGVuZy5zaGFvZnVAenRl LmNvbS5jbiZndDssDQpSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDssIDwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7cnJhc3p1a0BnbWFpbC5jb20mcXVvdDsgJmx0O3JyYXN6 dWtAZ21haWwuY29tJmd0OywNCiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5n QGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFJlOiBbc3ByaW5nXSC08Li0OiBS RTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwvZm9udD48L3RhYmxlPg0K PGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9 IkNhbGlicmkiPkRlY2NhbiCoQzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4 MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw MDQwODAgZmFjZT0iQ2FsaWJyaSI+VGhlcmUgaXMgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuDQp3aGF0 IGxhYmVscyBtYXkgYmUgaW5jbHVkZWQgaW4gdGhlIGVuY2Fwc3VsYXRpb24gZm9yIGEgcGFja2V0 IGFuZCB3aGF0DQpsYWJlbHMgd2lsbCBiZSChsHRvcCBvZiBzdGFja6GxLiBJdCBpcyBvbmx5IHRo ZSBsYXR0ZXIgd2hpY2ggZ2V0cyBpbnN0YWxsZWQNCmluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+ VG8gcmVhY2ggZGVzdGluYXRpb25zIGluDQpTaXRlIEIgZnJvbSBhIG5vZGUgaW4gU2l0ZSBBIHRo ZSBwYWNrZXQgaGFzIHRvIGJlIHNlbnQgdG8gYSBDRSBpbiBzaXRlDQpCIHZpYSBhIFBFIGFjY2Vz c2libGUgdG8gbm9kZXMgaW4gU2l0ZSBBLiBTbyBlbmNhcHN1bGF0aW9uIHRvIGEgZGVzdGluYXRp b24NClogaW4gc2l0ZSBCIHdvdWxkIGxvb2sgbGlrZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOyBMYWJlbCBmb3IgQ0UtQiBh c3NpZ25lZA0KYnkgUEUtQTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBm YWNlPSJDYWxpYnJpIj4mbmJzcDsgTGFiZWwgZm9yIERlc3RpbmF0aW9uDQpaPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5Ob2RlcyBpbiBT aXRlIEEgd2lsbCBuZXZlcg0KUE9QIHRoZSB0b3AgbGFiZWwgqEMgc28gdGhleSB3aWxsIG5ldmVy IHJlY2VpdmUgYSBwYWNrZXQgYWRkcmVzc2VkIHRvIFoNCndoZXJlIHRoZSB0b3AgbGFiZWwgaXMg obBaobEuIEFueSBsYWJlbCAob3IgdGhlIFNJRCB1c2VkIHRvIGRlcml2ZSBpdCkNCnRoYXQgd29u oa90IGJlIHRvcCBvZiBzdGFjayBpbiBTaXRlIEEgaXMgbm90IHBhcnQgb2YgdGhlIGRhdGFiYXNl IHVzZWQNCmZvciBjb25mbGljdCByZXNvbHV0aW9uIGluIFNpdGUgQS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPk5vdGUgdGhhdCB0aGlz IGlzIHN0YW5kYXJkDQpNUExTIGZvcndhcmRpbmcgYmVoYXZpb3IgZm9yIHRoaXMgZGVwbG95bWVu dCCoQyB0aGUgdXNlIG9mIFNSIGhhcyBub3QgY2hhbmdlZA0KdGhpcyBpbiBhbnkgd2F5LjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7ICZuYnNwO0xlczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNl PSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48Yj5Gcm9tOjwvYj4gcGVuZy5zaGFvZnVAenRlLmNvbS5jbiBbPC9mb250PjxhIGhy ZWY9bWFpbHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9t YSI+bWFpbHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY248L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBm YWNlPSJUYWhvbWEiPl0NCjxiPjxicj4NClNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMDQsIDIwMTYg ODo1NyBQTTxiPjxicj4NClRvOjwvYj4gUm9iZXJ0IFJhc3p1azxiPjxicj4NCkNjOjwvYj4gTGVz IEdpbnNiZXJnIChnaW5zYmVyZyk7IHJyYXN6dWtAZ21haWwuY29tOyBzcHJpbmdAaWV0Zi5vcmc8 Yj48YnI+DQpTdWJqZWN0OjwvYj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij608Li0PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjoNClJlOiBbc3ByaW5nXSA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPrTwuLQ8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IlRhaG9tYSI+Og0KUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkhpIFJvYmVydCw8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gYWRkIG1vcmUgZGVzY3Jp cHRpb24gdG8gc2VjdGlvbiA0IHRvIGVsaW1pbmF0ZQ0KY29uZnVzaW9uLiBOb3cgd2Ugb25seSBn ZXQgYSAmcXVvdDtzdGF0ZW1lbnQmcXVvdDsgdGhhdCB0aGVyZSBpcyBubyBwcm9ibGVtLA0KYnV0 IG5vdCBob3cuIEZvciBleGFtcGxlLCBpZiBzZXBhcmF0ZSAmcXVvdDtjb250ZXh0cyZxdW90OyBp biBkYXRhIHBsYW5lDQphcyB5b3Ugc2FpZCBpcyBhIHN1Z2dlc3Rpb24gbWV0aG9kIHRvIGZ1bGZp bGwgdGhpcyBjYXNlPyBOb3RlIHRoYXQgSUxNDQpjb3JyZXNwb25kaW5nIHRvIFNSIGxhYmVsIGhh cyBubyAmcXVvdDtjb250ZXh0cyZxdW90OyBpbiBkYXRhIHBsYW5lIGN1cnJlbnRseS48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KTGV0J3MgZmlyc3QgY29uY2VybiBpc3N1ZXMgaW4gY29udHJv bCBwbGFuZS4gPGJyPg0KU3VwcG9zZWQgdGhhdCB0aGVyZSBhcmUgc2l0ZSBBLEIsQyBhdHRhY2hp bmcgdG8gcHJvdmlkZXIgbmV0d29yayB0aHJvdWdoDQpQRTEsUEUyLFBFMyByZXNwZWN0aXZlbHks IGFuZCBBLEIsQyBiZWxvbmcgdG8gc2FtZSB2cmYgbmV0d29yay4gU3VwcG9zZWQNCnRoYXQgZGVz dGluYXRpb24gMS4xLjEuMSBpbiBzaXRlIEEsIDIuMi4yLjIgaW4gc2l0ZSBCLCAzLjMuMy4zIGlu IHNpdGUNCkMgYXNzaWduIHRoZSBzYW1lIHByZWZpeC1zaWQuPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K QmVjYXVzZSBJIGhhdmUgbm8gZW50aXJlIGlkZWEgYWJvdXQgdGhlIHNvbHV0aW9uIGJlaGluZCBz ZWN0aW9uIDQsIEkganVzdA0KbGlzdCB0aGUgcXVlc3Rpb25zIGFzIGZvbGxvd2luZzo8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KMSkgUEUxJ3MgQkdQIHdpbGwgcmVjZWl2ZSBWUE52NCBwcmVm aXgoMi4yLjIuMikgZnJvbSBQRTIgd2l0aCBwcmVmaXgtc2lkDQpzYW1lIGFzIFZQTnY0IHByZWZp eCgzLjMuMy4zKSBmcm9tIFBFMywgZG9lcyBpdCBkbyBjb25mbGljdCBwcm9jZXNzIGluDQp0aGlz IHBoYXNlPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjIpIFBFMSdzIEJHUCB3aWxsIGltcG9ydCBWUE52 NCByb3V0ZSB0byBsb2NhbCB2cmYsIHNvIGluIHRoZSBzYW1lIFZQTiByb3V0aW5nDQp0YWJsZSwg cHJlZml4KDIuMi4yLjIpIGFuZCBwcmVmaXgoMy4zLjMuMykgaGF2ZSB0aGUgc2FtZSBwcmVmaXgt c2lkLCBkb2VzDQppdCBkbyBjb25mbGljdCBwcm9jZXNzIGluIHRoaXMgcGhhc2U/PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NCjMpIFBFMSdzIElHUCB3aWxsIHJlZGlzdHJpYnV0ZSBCR1Agcm91dGVzIGlu IHRoZSB2cmYsIHNvIElHUCB3aWxsIGFsc28NCnNlZSB0d28gcHJlZml4ZXMgaGF2ZSB0aGUgc2Ft ZSBwcmVmaXgtc2lkLCBkb2VzIGl0IGRvIGNvbmZsaWN0IHByb2Nlc3MNCmluIHRoaXMgcGhhc2U/ PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KNCkgRWFjaCByb3V0ZXIgaW4gc2l0ZSBBIHdpbGwgcmVjZWl2 ZSBwZXJmaXggZmxvb2QsIHNvIGF0IGVhY2ggcm91dGVyIGl0cw0KSUdQIHdpbGwgYWxzbyBzZWUg dHdvIHByZWZpeGVzIGhhdmUgdGhlIHNhbWUgcHJlZml4LXNpZCwgZG9lcyBpdCBkbyBjb25mbGlj dA0KcHJvY2VzcyBpbiB0aGlzIHBoYXNlPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N ClRoYW5rczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkRlY2NhbjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJy Pg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTMwJT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPlJvYmVydCBSYXN6dWsgJmx0 OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxiPjx1PnJvYmVydEByYXN6dWsubmV0PC91PjwvYj48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+Jmd0OzwvYj4NCjwvZm9udD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0Kt6K8/sjLPC9mb250Pjxmb250IHNp emU9MSBmYWNlPSJBcmlhbCI+OiAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cnJhc3p1a0Bn bWFpbC5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnJyYXN6dWtA Z21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0K PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4yMDE2LTA3LTA0IDE2OjAwPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02 OSU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTclPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkyJT48YSBocmVmPW1haWx0bzpwZW5nLnNoYW9m dUB6dGUuY29tLmNuPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5wZW5n LnNoYW9mdUB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFs Ij4sDQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSZxdW90OyAm bHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT48Zm9udCBzaXplPTEg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+Z2luc2JlcmdAY2lzY28uY29tPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7LA0KJnF1b3Q7PC9mb250PjxhIGhyZWY9 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlh bCI+PHU+c3ByaW5nQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFy aWFsIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c3ByaW5nQGlldGYub3JnPjxm b250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5zcHJpbmdAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+UmU6IFtzcHJpbmddIDwvZm9u dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+tPC4tDwvZm9udD48Zm9udCBzaXplPTEg ZmFjZT0iQXJpYWwiPjoNClJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u PC9mb250PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBQ ZW5nLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCk9uIHRoZSBwb2ludCAjMiB5b3UgYXJlIHJp Z2h0IHRoYXQgZXh0ZXJuYWxseSByZWNlaXZlZCBTSURzIHdpbGwgYmUgaW5zdGFsbGVkDQppbiB0 aGUgZGF0YSBwbGFuZSBvZiBQRXMuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KSG93 ZXZlciB5b3UgbmVlZCB0byBvYnNlcnZlIHRoYXQgdGhleSB3aWxsIGJlIGluc3RhbGxlZCBpbiBj b21wbGV0ZWx5IHNlcGFyYXRlDQomcXVvdDtjb250ZXh0cyZxdW90OyBpbiBkYXRhIHBsYW5lIGhl bmNlIGN1cnJlbnQgYWRkaXRpb24gKGFmdGVyIEkgYnJvdWdodA0KdGhpcyBpc3N1ZSBmZXcgd2Vl a3MgYmFjaykgaGFzIGJlZW4gYWNjdXJhdGVseSBhZGRyZXNzZWQgaW4gbmV3IHNlY3Rpb25zDQoz LjIuNiBhbmQgNC4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBbGwgd2hhdCB5b3Ug YXJlIHNheWluZyBpcyB0cnVlIGFuZCB0aGUgJm5ic3A7Y3VycmVudCBkcmFmdCBlbmFibGVzIG9u ZQ0KdG8gZG8gdGhhdCB5ZXQgdG8ga2VlcCBjb25zaXN0ZW50IGJhc2UgdG9wb2xvZ3kgaW4gdGhl IG5ldHdvcmsuIFdlbGwgbW9kdWxvDQpjb21tZW50cyBmcm9tIEJydW5vIHdoaWNoIGhhdmUgbm90 IGJlZW4geWV0IHdlbGwgYWRkcmVzc2VkLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CkNoZWVycyw8YnI+DQpSLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxi cj4NCjxicj4NCjxicj4NCk9uIE1vbiwgSnVsIDQsIDIwMTYgYXQgNDozMiBBTSwgJmx0OzwvZm9u dD48YSBocmVmPW1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+cGVuZy5zaGFvZnVAenRl LmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7 DQp3cm90ZTogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KTGVzLCA8YnI+ DQo8YnI+DQpTZWUgaW5saW5lLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0KPHA+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQ3JT48Zm9udCBzaXpl PTEgZmFjZT0iQXJpYWwiPjxiPiZxdW90O0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7DQom bHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20gdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGI+PHU+Z2luc2JlcmdA Y2lzY28uY29tPC91PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+ Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MjAxNi0wNy0w MiAwMToxMzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8 dGQgd2lkdGg9NTIlPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+ DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MTAlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg5JT48Zm9udCBzaXplPTEgZmFjZT0iQXJp YWwiPiZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnBlbmcu c2hhb2Z1QHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwi PiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNu IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnBl bmcuc2hhb2Z1QHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJp YWwiPiZndDssDQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c3By aW5nQGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i QXJpYWwiPjx1PnNwcmluZ0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNl PSJBcmlhbCI+JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5z cHJpbmdAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZn dDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ UkU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb248L2ZvbnQ+ PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250 Pg0KPHA+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl Pg0KPGJyPjwvdGFibGU+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxi cj4NCjxicj4NCkRlY2NhbiAtPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpGcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9bWFp bHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY24gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnBlbmcuc2hhb2Z1QHp0ZS5jb20uY248L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86 cGVuZy5zaGFvZnVAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY248L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4g RnJpZGF5LCBKdWx5IDAxLCAyMDE2IDI6NDYgQU08Yj48YnI+DQpUbzo8L2I+IExlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpPGI+PGJyPg0KQ2M6PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c3ByaW5n QGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFo b21hIj48dT5zcHJpbmdAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3By aW5nLWNvbmZsaWN0LXJlc29sdXRpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkhpcyBMZXMsPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQo8YnI+DQoxKSBGcm9tIGltcGxlbWVudGF0aW9uLCBiZWNhdXNlIHByZWZlcmVuY2UgYWxnb3Jp dGhtIGlzIHByb3RvY29sIGluZGVwZW5kZW50LA0KaXQgaXMgYmV0dGVyIHRvIGRvIGNvbmZsaWN0 IHJlc29sdXRpb24gYXQgYSBjb21tb24gcGxhY2UsIG5vdCBhdCBpbmRpdmlkdWFsDQpwcm90b2Nv bCBpbnN0YW5jZS4gRm9yIGV4YW1wbGUsIHdlIGNhbiBkbyBwcmVmaXgtY29uZmxpY3QgcmVzb2x1 dGlvbiB3aGVuDQpnZW5lcmF0ZSB0aGUgcHJlZmVyZW5jZSBGSUIgZW50cnkgYXQgdGhlIGNvbW1v biBwbGFjZS4gRm9yIGEgcHJlZmVyZW5jZQ0KRklCIGVudHJ5LCB0aGUgcm91dGluZyBpbmZvcm1h dGlvbiBtYXkgZ2V0IGZyb20gT1NQRiBieSBhZG1pbmlzdHJhdGl2ZQ0KZGlzdGFuY2UsIGJ1dCB0 aGUgU0lEIGluZm9ybWF0aW9uIG1heSBnZXQgZnJvbSBJU0lTIGJ5IHByZWZpeC1jb25mbGljdA0K YWxnb3JpdGhtLiBUaGVuIHdlIGNhbiBkbyBzaWQtY29uZmxpY3QgcmVzb2x1dGlvbiB3aGVuIGdl bmVyYXRlIHRoZSBTSUQtTElCDQplbnRyeSBhY2NvcmRpbmcgdG8gdGhlIGFib3ZlIEZJQiBlbnRy eSBhbmQgb3RoZXIgc291cmNlcywgaXQgd2lsbCBzZWxlY3QNCmEgcHJlZmVyZW5jZSBGRUMgdG8g cHJvdmlkZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N ClNvLCBwcmVmZXJlbmNlIGFsZ29yaXRobSBwZXIgcHJlZml4L2ZlYyBpcyBlbm91Z2guIFBlciBy YW5nZSBpcyBwb3NzaWJsZSwNCmJ1dCBpbXBsZW1lbnRhdGlvbiBpcyBjb21wbGV4LiBNb3JlIGNv bXBsZXggaXMgZm9yICZxdW90O2lnbm9yIG92ZXJsYXkmcXVvdDsNCnBlciByYW5nZS48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48Yj48aT48YnI+DQo8YnI+DQpbTGVzOl0gSW1w bGVtZW50YXRpb24td2lzZSwgeW91IGFyZSBmcmVlIHRvIGltcGxlbWVudCB0aGlzIGluIGFueSBt b2R1bGUNCnlvdSBsaWtlIHNvIGxvbmcgYXMgd2l0aCB0aGUgc2FtZSBkYXRhYmFzZSB5b3UgY29t ZSB1cCB3aXRoIHRoZSBzYW1lIGFuc3dlcg0KYXMgb3RoZXIgbm9kZXMgaW4gdGhlIG5ldHdvcmsu PC9pPjwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxiPjxpPjxicj4NClRoZSBk aXN0aW5jdGlvbiBiZXR3ZWVuIKGwUXVhcmFudGluZaGxIGFuZCChsElnbm9yZSBPdmVybGFwobEg aXMgdGhhdA0KdGhlIGxhdHRlciBhdHRlbXB0cyB0byB1c2UgdGhvc2UgcG9ydGlvbnMgb2YgYSBy YW5nZSB3aGljaCBkbyBub3QgaGF2ZQ0KY29uZmxpY3RzIHdpdGggb3RoZXIgZW50cmllcy4gVGhl IGNvc3Qgb2YgZG9pbmcgc28gaXMgaGF2aW5nIHRvIGNyZWF0ZQ0KobBkZXJpdmVkIGVudHJpZXOh sSB3aGljaCByZXByZXNlbnQgdGhvc2Ugc3ViLXJhbmdlcyB3aGljaCBkby9kbyBub3QNCmhhdmUg Y29uZmxpY3RzLiBEdWUgdG8gdGhlIGFkZGVkIGNvbXBsZXhpdHkgdGhpcyBpcyBOT1QgdGhlIGZp cnN0IGNob2ljZQ0Kb2YgdGhlIGF1dGhvcnMuIDxicj4NCklmIEkgd2VyZSB0byBjYXRlZ29yaXpl IHRoZSB0d28gYWxnb3JpdGhtcyB1c2luZyB5b3VyIHRlcm1pbm9sb2d5IKGwUXVhcmFudGluZaGx DQp3b3VsZCBiZSChsHBlciByYW5nZaGxIHdoaWxlIKGwSWdub3JlIE92ZXJsYXChsSB3b3VsZCBi ZSChsHBlciBwcmVmaXgvRkVDobEuDQpTbyBpdCBpcyB0aGUgbGF0dGVyIHdoaWNoIGlzIG1vcmUg Y29tcGxleCB0byBpbXBsZW1lbnQuPC9pPjwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KW0RlY2Nh bl0gWW91IGFyZSByaWdodCwgYXMgcGVyIHByZWZpeC9GRUMgaXMgYWN0dWFsbHkgdG8gc3BsaXQg dGhlIG9yaWdpbmFsDQpyYW5nZSB0byB0aGUgc21hbGxlc3Qgb25lcy4gTXkgbWVhbmluZyBpcyB0 aGF0IHRoZXJlIGlzIG5vIHJhbmdlIGlkZWEgZHVyaW5nDQpjb25mbGljdCBwcm9jZXNzIHBoYXNl IGF0IHRoZSBjb21tb24gcGxhY2UsIGFsbCBpcyBkb25lIGJhc2VkIG9uIHRoZSBleGlzdGluZw0K ZGF0YSBzdHJ1Y3R1cmUgcGVyIHByZWZpeC9GRUMuIE1hcHBpbmcgcmFuZ2Ugb25seSBhcHBlYXIg aW4gdGhlIGluZGl2aWR1YWwNCnByb3RvY29sIGluc3RhbmNlLCBidXQgaXQgaXMgYWx3YXlzIHRv IGJlIHNwbGl0IHRvIHRoZSBzbWFsbGVzdCBvbmVzLCBmb3INCnJhIGZvciBjb25mbGljdCBmdW5j dGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQoyKSBUaGUgcmVzdHJpY3Rpb25zIGluIG5l dyBzZWN0aW9uICZxdW90O1Njb3BlIG9mIFNSLU1QTFMgU0lEIENvbmZsaWN0cyZxdW90Ow0KbWF5 YmUgbm90IHRydWUuIFBsZWFzZSBqdXN0IGNvbnNpZGVyICZxdW90O0NhcnJpZXIgb2YgQ2Fycmll ciZxdW90OyBjYXNlDQp3aGljaCBkZXBsb3kgSUdQK0xEUCBiZXR3ZWVuIFBFIGFuZCBDRS4gSXQg aXMgcG9zc2libGUgdG8gZGVwbG95IFNSIExTUA0KaW4gdGhlIHNlY29uZCBsZXZlbCBjYXJyaWVy LCBzbyB0aGF0IGFuIFNSIExTUCBpcyBidWlsZGluZyBmcm9tIG9uZSBzaXRlDQp0byBhbm90aGVy IGFjcm9zcyB0aGUgZmlyc3QgbGV2ZWwgY2Fycmllciwgc2FtZSBhcyBhbiBMRFAgTFNQLiBUaGlz IG1lYW5zDQpTSURzIGFzc29jaWF0ZWQgd2l0aCBkZXN0aW5hdGlvbnMgaW4gU2l0ZSBBIHdpbGwg YmUgaW5zdGFsbGVkIGluIHRoZSBmb3J3YXJkaW5nDQpwbGFuZSBvZiByb3V0ZXJzIGluIFNpdGUg Qi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGI+PGk+PGJyPg0KPGJyPg0K W0xlczpdIFdlIGhhdmUgbG9va2VkIGF0IKGwQ2FycmllciBvZiBDYXJyaWVyobEgYW5kIHdlIGRp c2FncmVlIHdpdGgNCnlvdXIgY29uY2x1c2lvbi4gVG8gcmVhY2ggZGVzdGluYXRpb25zIGluIFNp dGUgQiBmcm9tIFNpdGUgQSBwYWNrZXRzIHdpbGwNCm5lZWQgdG8gdHJhdmVyc2UgdGhlIFBFKHMp IGNvbm5lY3RlZCB0byBTaXRlIEEuIFdoYXQgd2lsbCBiZSBpbnN0YWxsZWQNCmluIHRoZSBmb3J3 YXJkaW5nIHBsYW5lIG9mIHJvdXRlcnMgaW4gU2l0ZSBBIHdpbGwgYmUgbGFiZWxzIGFzc29jaWF0 ZWQNCndpdGggdGhlIFNJRCBvZiB0aGUgUEUgqEMgbm90IHRoZSBTSURzIGZvciBkZXN0aW5hdGlv bnMgaW4gU2l0ZSBCLiBJbiBmYWN0LA0KaXQgaXMgcG9zc2libGUgZm9yIGRlc3RpbmF0aW9uIDEu MS4xLjEgaW4gU2l0ZSBBIHRvIHVzZSB0aGUgc2FtZSBTSUQgYXMNCmRlc3RpbmF0aW9uIDIuMi4y LjIgaW4gU2l0ZSBCLiBUaGlzIGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDQgb2YgdGhlIGRyYWZ0 LjwvaT48L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48 Zm9udCBzaXplPTMgY29sb3I9IzAwNDA4MCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCltE ZWNjYW5dIFNvcnJ5LCBJIGNhbm5vdCB1bmRlcnN0YW5kIGhvdyB0byBmdWxmaWxsIHRoaXMgY2Fz ZSB5ZXQuIElNTyw8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48Zm9u dCBzaXplPTMgY29sb3I9IzAwNDA4MCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPnBhY2tldHMgZnJv bSBzaXRlDQpBIG5lZWQgY29udGFpbiBTSURzIGZvciBkZXN0aW5hdGlvbnMgaW4gc2l0ZSBCLCBz byB0aGF0IHBhY2tldHMgY2FuIGZvcndhcmQNCnRvIHRoZSBzcGVjaWZpYyBkZXN0aW5hdGlvbiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5jb3JyZWN0bHksDQp0aGUgU0lEIG9mIHRo ZSBQRSBjYW4gb25seSBiZSB1c2VkIHRvIGZvcndhcmQgcGFja2V0cyB0byB0aGUgUEUuIEFsdGhv dWdoLA0KYXQgdGhlIGluZ3Jlc3Mgbm9kZSBpbiBzaXRlIEEsIHdlIGNhbiBlbmNhcHN1bGF0ZSBT SUQgb2YgdGhlIFBFIGFnYWluIHRvDQpoaWRlIFNJRCBvZiBzaXRlIEIgYmVmb3JlIHNlbmRpbmcg cGFja2V0cywgdGhlIGluZ3Jlc3Mgbm9kZSBpbiBzaXRlIEEgYW5kDQp0aGUgUEUgbmVlZCBzdGls bCBzZWUgdGhlIFNJRCBvZiBzaXRlIEIuIEEgbm9kZSBpbiBzaXRlIEEgY2FuIG5vdCBlbnN1cmUN Cml0IHdpbGwgb25seSBhY3QgYXMgYSB0cmFuc2l0IHJvbGUuIENvdWxkIHlvdSBleHBsYWluIG1v cmU/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBz aXplPTMgY29sb3I9IzAwNDA4MCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxicj4NCiAm bmJzcDsgTGVzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KVGhhbmtzIDxicj4NCjxicj4NCkRl Y2NhbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNt aXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbA0KYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAmbmJzcDtJ ZiB5b3UNCmFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24NCm9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkNCnByb2hpYml0ZWQuICZuYnNw O0lmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZQ0K aXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBO ZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQogPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsDQphbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lmIHlvdQ0KYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlv bg0Kb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpcyBzdHJpY3RseQ0KcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlDQppdCBhbmQgbm90aWZ5IHVzIGltbWVk aWF0ZWx5Ljxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCihhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbA0KYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAm bmJzcDtJZiB5b3UNCmFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3Vy ZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24NCm9yIG90aGVyIGRpc3NlbWluYXRpb24gb3Ig dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkNCnByb2hpYml0ZWQu ICZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl bGV0ZQ0KaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcg bGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48 YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5zcHJpbmdAaWV0Zi5vcmc8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+ DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eQ0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkDQpoZXJld2l0aCkg aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZQ0KdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFu IGludGVuZGVkIHJlY2lwaWVudCwgYW55DQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZg0KdGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNl aXZlZA0KdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkg aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFp bCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K DQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 00373D7E48257FE7_=-- From nobody Tue Jul 5 05:13:41 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED6712D516 for ; Tue, 5 Jul 2016 05:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO--qpSDB2nr for ; Tue, 5 Jul 2016 05:13:34 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D6112D0A8 for ; Tue, 5 Jul 2016 05:13:33 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 73F1B20380; Tue, 5 Jul 2016 14:13:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 3942B1A0074; Tue, 5 Jul 2016 14:13:32 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0294.000; Tue, 5 Jul 2016 14:13:30 +0200 From: To: "Les Ginsberg (ginsberg)" , DECRAENE Bruno IMT/OLN Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACE8TpAAIX4q4ADi0V8g Date: Tue, 5 Jul 2016 12:13:29 +0000 Message-ID: <29546_1467720812_577BA46C_29546_10552_1_2be66f3d-73a1-46bd-8961-c6a7c72c80ee@OPEXCLILM7E.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1587_1467273411_5774D0C3_1587_760_1_9504d9b8-54bf-471a-ab89-dc6b3e1e8132@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20318c905e5e42859e4868f36bda319e@XCH-ALN-001.cisco.com> In-Reply-To: <20318c905e5e42859e4868f36bda319e@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_2be66f3d73a146bd8961c6a7c72c80eeOPEXCLILM7Ecorporateadr_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 12:13:39 -0000 --_000_2be66f3d73a146bd8961c6a7c72c80eeOPEXCLILM7Ecorporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, Some comments inline Thanks, From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 02:14 To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Stephane - From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Thursday, June 30, 2016 12:57 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, Administrative distance (protocol preference) has always been used in route= r implementation for a while. Yes inconsistent configuration of admin dista= nce can cause routing issues (loops or whatever ...). I'm not sure we can r= eally bypass it ... [Les:] First, you do not address the lack of admin distance for SRMS entrie= s - which for me is sufficient to make the use of this attribute inappropri= ate in this context. Second, inconsistency in admin distance config is always potentially danger= ous, but when applied to local route preference it simply means that the lo= cal router chooses to follow the path provided by Protocol A rather than Pr= otocol B. So long as it sends this to a node which is running Protocol A pr= esumably the packet still has a chance to be forwarded to its destination. = In the case of SIDs however, using a different SID means that the label use= d to forward the packet is likely to be interpreted differently by nodes a= long the path - so the risk of misforwarding is significant. Finally, we have deliberately made the conflict resolution protocol indepen= dent so as to allow consistent resolution when multiple protocols are in us= e. Using admin distance runs counter to that model. [SLI] I'm afraid that if we are not precise on the behavior regarding admin= distance, implementations will use it as they done today. So if you have a route to 1.1.1.1/32 coming from both OSPF and ISIS with a = collision, the best admin distance will be installed with the associated ou= tgoing label. Same thing can happen with LFIB entry. Regarding the preference algorithm, the SRMS weight must also need to be ta= ken into account (as stated by Stefano, the conflict draft will need to be = updated accordingly). We may be able to put it just after PFX > SRMS. [Les:] Yes, we started to incorporate that, but we discovered that OSPF cur= rently has no equivalent to the "weight" field in IS-IS Binding TLV entries= . This is because SRMS advertisements in OSPF use the Extended Prefix Range= TLV and the Prefix SID sub-TLV (see https://www.ietf.org/id/draft-ietf-os= pf-segment-routing-extensions-08.txt - Sections 4 and 5). The only reason I= S-IS has "weight" is because it was put into the Binding TLV in support of = other use cases (various ERO objects) - not for SRMS advertisements. This a= lso got us thinking that the granularity of preference between mapping serv= ers is more logically associated with the server - not with an individual a= dvertisement from that server. Which in turn suggests a new extensions to p= er node SR Capabilities advertisements would be more appropriate. [SLI] Having granularity per range is needed, it's not just a question of d= efining primary backup scenarios. It's also a question of allowing migratio= ns of SID blocks within mapping server advertisement by letting control to = the operator on what will be the active range. Moreover this kind of scenar= io also requires the ignore overlap only to prevent a range to be fully rej= ected while operator to keep the non overlapping part. None of this has yet been discussed publicly - so we do not know what direc= tion the WG may want to go as regards SRMS and "weight". We therefore left = it out of this revision of conflict resolution. [SLI] It's independent of the protocol encoding. We define a mechanism for = SRMS preference then protocols may encode it in different way, using existi= ng weight field or not ... One other point regarding the draft is that it must be stated clearly that = the different approach presented cannot be mixed in a network deployment, o= therwise inconsistent behavior may occur. [Les:] The point of the draft is to (based on consensus) define one - and o= nly one - conflict resolution policy which all nodes MUST support. The fact= that alternatives are currently discussed in the draft is a reflection of = the current draft state (still evolving) - not an indication that we are go= ing to allow multiple algorithms to be deployed. [SLI] Would be good to state it in the document. The last point, as Bruno, from an operational network perspective, I'm more= in favor to push the ignore overlap only rather than the quarantine which = could break forwarding to a lot of destinations. [Les:] Thanx for the input. Les Best Regards, Stephane From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Wednesday, June 29, 2016 18:19 To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. We stopped shor= t of that in this revision because we felt there were enough substantive ch= anges and points on which consensus is still a work in progress that it wou= ld not be the optimal way forward. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_2be66f3d73a146bd8961c6a7c72c80eeOPEXCLILM7Ecorporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

Some comments inline

 

Thanks,

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 02:14
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Stephane -<= /span>

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Thursday, June 30, 2016 12:57 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 

Administrative distanc= e (protocol preference) has always been used in router implementation for a= while. Yes inconsistent configuration of admin distance can cause routing = issues (loops or whatever …). I’m not sure we can really bypass it …

[Les:] First, yo= u do not address the lack of admin distance for SRMS entries – which = for me is sufficient to make the use of this attribute inappropriate in thi= s context.

Second, inconsis= tency in admin distance config is always potentially dangerous, but when ap= plied to local route preference it simply means that the local router choos= es to follow the path provided by Protocol A rather than Protocol B. So long as it sends this to a node which is runn= ing Protocol A presumably the packet still has a chance to be forwarded to = its destination. In the case of SIDs however, using a different SID means t= hat the label used to forward the packet is likely to  be interpreted differently by nodes along the pa= th – so the risk of misforwarding is significant.

Finally, we have= deliberately made the conflict resolution protocol independent so as to al= low consistent resolution when multiple protocols are in use. Using admin d= istance runs counter to that model.

 

[SLI] I’m = afraid that if we are not precise on the behavior regarding admin distance,= implementations will use it as they done today.<= /p>

So if you have a= route to 1.1.1.1/32 coming from both OSPF and ISIS with a collision, the b= est admin distance will be installed with the associated outgoing label. Sa= me thing can happen with LFIB entry.

 

 

Regarding the preferen= ce algorithm, the SRMS weight must also need to be taken into account (as s= tated by Stefano, the conflict draft will need to be updated accordingly). = We may be able to put it just after PFX > SRMS.

 

[Les:] Yes, we s= tarted to incorporate that, but we discovered that OSPF currently has no eq= uivalent to the “weight” field in IS-IS Binding TLV entries. Th= is is because SRMS advertisements in OSPF use the Extended Prefix Range TLV and the Prefix SID sub-TLV  (see https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-08.txt - Sections 4 and 5). The only reason IS-IS has “weight” is b= ecause it was put into the Binding TLV in support of other use cases (vario= us ERO objects) – not for SRMS advertisements. This also got us thinking that the granularity of preference between mappi= ng servers is more logically associated with the server – not with an= individual advertisement from that server. Which in turn suggests a new ex= tensions to per node SR Capabilities advertisements would be more appropriate.

 

[SLI] Having gra= nularity per range is needed, it’s not just a question of defining pr= imary backup scenarios. It’s also a question of allowing migrations o= f SID blocks within mapping server advertisement by letting control to the operator on what will be the active range. Moreo= ver this kind of scenario also requires the ignore overlap only to prevent = a range to be fully rejected while operator to keep the non overlapping par= t.

 

 

None of this has= yet been discussed publicly – so we do not know what direction the W= G may want to go as regards SRMS and “weight”. We therefore lef= t it out of this revision of conflict resolution.=

[SLI] It’s= independent of the protocol encoding. We define a mechanism for SRMS prefe= rence then protocols may encode it in different way, using existing weight = field or not …

 

 

 

One other point regard= ing the draft is that it must be stated clearly that the different approach= presented cannot be mixed in a network deployment, otherwise inconsistent = behavior may occur.

 

[Les:] The point= of the draft is to (based on consensus) define one – and only one &#= 8211; conflict resolution policy which all nodes MUST support. The fact tha= t alternatives are currently discussed in the draft is a reflection of the current draft state (still evolving) – not an= indication that we are going to allow multiple algorithms to be deployed.<= /span>

[SLI] Would be good to= state it in the document.

 

 

The last point, as Bru= no, from an operational network perspective, I’m more in favor to pus= h the ignore overlap only rather than the quarantine which could break forw= arding to a lot of destinations.

 

[Les:] Thanx for= the input.

 

   Les=

 

Best Regards,

 

Stephane

 

 

 

Bruno –

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 

IINM, I’ve not s= een the follow up on one of my below questions.

So let me restate a co= mment:

 

The SR-MPLS SID confli= cts algo requires that all nodes consider the same mapping advertisements.<= /span>

How is this ensured, i= f it indifferently considers advertisements from all protocols, while some = nodes could participate only in a subset of the protocols? e.g. OSPF only r= outers would consider a different set of information compared to OSPF+IS-IS routers.

 

[Les:] If you ru= n multiple protocol instances (whether multiple instances of the same proto= col or instances of different protocols) then you need to insure that at le= ast one of the two conditions below is true:

=B7         All routers re= ceive the equivalent set of advertisements

=B7         There are no c= onflicts J

 

One way of insuring= the first point is to exclusively use a mapping server to advertise SIDs, = configure your SRMS entries in a protocol independent manner, and insure th= at the SRMS advertisements are sent in all of the protocol instance specific sub-domains.

 

If the intent is to= deliberately use different labels in the forwarding plane for the same des= tination depending upon which protocol advertised the prefix, this introduc= es a number of new requirements – not the least of which is duplicate entries for the same prefix in the forward= ing plane.  As has been discussed publicly in a different thread, ther= e are cases (e.g. merging two networks) were such a requirement may exist &= #8211; but it is the exception rather than the rule and as it consumes more resources in the forwarding plane and int= roduces implementation complexity independent of conflict resolution it is = not the primary case the draft focuses on. Nevertheless, this is a case whi= ch the draft will address in the next revision. We stopped short of that in this revision because we felt t= here were enough substantive changes and points on which consensus is still= a work in progress that it would not be the optimal way forward.

 

Thinking more about th= is, I guess that this is only important for the entries which are inserted = in the forwarding plane. Hence, in case of conflict between protocols, I th= ink that the preference algorithm should take into account the protocol preference (aka administrative distance). <= /span>

 

[Les:] As admin = distance is neither an attribute of SRMS entries nor guaranteed to be consi= stent on all routers for all prefixes this is not a desirable approach.

 

I’m also not sur= e to see why is the problem different compared to Multi-Topology. Could you= please elaborate?

[Les:] I am uncl= ear what your question is. Are you asking why we need different SIDs in dif= ferent topologies? Please clarify.

 

  &nbs= p; Les

 

 

Thanks,

Bruno

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,=

 

Thanks for your reply.=

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

Inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution<= /o:p>

 

Hi,

 

As an individual contributor, please find below some= comments:

 

--

Isn’t this document specific to the MPLS datap= lane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

 

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document – which is why the Introduction is dataplane agnostic, but each sect= ion states specifically that it is relevant to SR-MPLS.=

 

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.<= /o:p>

[Bruno] ok, great.

--

=A73

“Mapping entries have an explicit context which incl= udes the topology and the SR algorithm.“

A priori you could add “the routing protocol”.=

 

[Les:] No –= ; the source of advertisements is deliberately left out. It matters not whe= ther the source of the advertisement is a protocol or an SRMS – nor d= oes it matter which protocol provides the advertisement. You see that “admin distance” is not mentioned at all and that= is quite deliberate. This insures that consistent choices are made on node= s regardless of which protocol might have the best route on a given node.

[Bruno] Well, the fact= is that mapping entries do have, as explicit context, the routing protocol= used to advertise them. After, you can should to use that information, or = not.

--

=A73

&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  If a router chooses to use one of=
 the conflicting
&=
nbsp;  entries forwarding loops and/or blackholes may result unless it=
 can
&=
nbsp;  be guaranteed that all other routers in the network make the sa=
me
&=
nbsp;  choice.  Making the same choice requires that all routers =
have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. =BB
&=
nbsp;
I=
 think we agree on the technical part, but I found the formulation slightly=
 biased. I would propose
&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  In order to avoid forwarding loop=
s and/or blackholes, there is a need for all nodes to make the same choice.=

&=
nbsp; Making the same choice requires that all routers have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. This is the purpose of this document. =
;=BB

--

[Les:] I am fine= with this change.

[Bruno] Thanks<= o:p>

 

=A73.1

&=
#8220;Various types of conflicts may occur”
W=
hat about :s/Various/Two

 

[Les:] “Tw= o” is fine. Just means we will have to change it if we come up with a= third type of conflict. J<= /span>

[Bruno] Indeed, but in= this case the change may be much larger (e.g. the whole algo)<= /o:p>

--

I agree with Robert’s  and Uma’s co= mment with regards to making this conflict resolution an inter- protocol/ro= uting_table issue. In particular, between SR domains, there is not requirem= ent to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

 

[Les:] There is = more to be said on this topic – co-authors are actively discussing th= is point and we’ll respond more fully to Robert’s post in time.= But, the draft is NOT trying to define conflict resolution across “SR domains”. Perhaps we need language to make that mor= e explicit.

[Bruno] ok. Regarding = inter-protocol, in order to have consistency of the prefix-SID mapping acro= ss the domain we need:

a) all nodes use the same algo

b) all nodes using this algo have the same data

 

“a” requires this draft

“b” requires that all nodes have the same set of SR = ; info. This forbid that some node are considering IS-IS + OSPF SR data= , while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guar= antee that the flooding area is the same for IS-IS and OSPF, we can't have = the algo using the SR data from multiple routing protocols. I don't think t= hat we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple = routing domain or when gradually transitioning from one IGP to another.

 

So in short, this SR-c= onflict algo should probably be restricted to SR information from a single = protocol

 

> From: Les Ginsberg (gin= sberg) [mailto:ginsberg@cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

> =

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same – no= t the label.

It is true that = SIDs are not installed in the forwarding plane – the labels derived f= rom the SID/SRGB are what is actually installed in the forwarding plane = 211; but I think my use of the word SID in this context is correct.

[Bruno] My point was t= hat the formulation assumes that a single SRGB is used per nodes. In which = case, we have a bijection between SID and labels. But if we have a SRGB per= protocol, we don’t have a bijection any more and we can have the same SID in IS-IS and OSPF (including for dif= ferent prefix), which will be mapped to different labels in the forwarding = plane.

 

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I’m not sure how much the agreement has been r= eached on that one.

 

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision

[Bruno] ok, may be thi= s should be stated in the draft, as otherwise you’ll keep getting com= ments, or we may forget this point.

Thanks

--Bruno

– but in s= pirit the same rules will apply – they will just have to take into ac= count “duplicate forwarding domains”. Note that this will also = require multiple incoming label entries/prefix be supported by the routers in such a network.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with range 2)

 

[Les:] Agreed &#= 8211; thanx for spotting this.

 

   Les<= /b>

 

Thanks,

Regards,

Bruno

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


&=
nbsp;


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.=



I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_2be66f3d73a146bd8961c6a7c72c80eeOPEXCLILM7Ecorporateadr_-- From nobody Tue Jul 5 09:54:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CAA12D60D for ; Tue, 5 Jul 2016 09:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-rFFQdSJV2u for ; Tue, 5 Jul 2016 09:54:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3572E12D5D2 for ; Tue, 5 Jul 2016 09:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129110; q=dns/txt; s=iport; t=1467737679; x=1468947279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qJysJhm1dG3wgIgg2dOWRIBNzRVn5s+PurrWvgMxK1w=; b=lIHph3t7k+Hh1HmPIdyWf0alxUw6bLA3zXgfCM1fn/agDFaO31JyJqNa WQlgkOk8Ob1Rb9rTqQrQSdaYZwghQuUAXQSZYltNOgQ1Pm7tXsN47KdKC 5nssSHLKAO48NbIknV7vd9OfM2lIFpeeGQC8BVMbJIGDWI4bvfjXls4D3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAgDU5XtX/5hdJa1cgnBOVnwGgniqO?= =?us-ascii?q?IwQgXcihSxKAhyBGDgUAQEBAQEBAWUnhEwBAQQBAQEKDgEICkELBQsCAQYCEQQ?= =?us-ascii?q?BARYLAQYDAgICHwYLFAkIAgQOBQgTh3sDDwgOjiGdHYsrDYQlAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWGJ4NKgQOCQ4FPCgcBBi0fCYJCgloFk0QVhQY0AYYIgnq?= =?us-ascii?q?DNIIJgXGEVoMue4RBiBeHcgEeNoIIHIFMbgEBhw4PFx8BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,580,1459814400"; d="scan'208,217";a="293729631" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 16:54:37 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u65GsbKc001048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 16:54:37 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 11:54:35 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 11:54:36 -0500 From: "Les Ginsberg (ginsberg)" To: Robert Raszuk Thread-Topic: [spring] draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACPs+VAAIaJeEACo/YOgACyjGFAACzDAAAAI54Tg Date: Tue, 5 Jul 2016 16:54:35 +0000 Message-ID: References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.73] Content-Type: multipart/alternative; boundary="_000_fd37aeb70f4940818f83b7f4d48abf68XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 16:54:43 -0000 --_000_fd37aeb70f4940818f83b7f4d48abf68XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0IOKAkw0KDQpVc2Ugb2YgUkZDIDUzMzEgd291bGQgcmVxdWlyZSB0aGF0IHdlIGhhdmUg YSB3YXkgdG8gYWR2ZXJ0aXNlIHRoZSBjb250ZXh0IGxhYmVsIGFzc29jaWF0ZWQgd2l0aCBhIHBy ZWZpeC1TSUQgYWR2ZXJ0aXNlbWVudCAod2hldGhlciBpbiBwcmVmaXggcmVhY2hhYmlsaXR5IG9y IFNSTVMpLiBUaGlzIGNhcGFiaWxpdHkgZG9lcyBub3QgY3VycmVudGx5IGV4aXN0Lg0KDQpTbyBJ IGJlbGlldmUgbXkgYW5zd2VyIGlzIGNvcnJlY3QgYmFzZWQgb24gZXhpc3RpbmcgZGVmaW5pdGlv biBvZiBTUi1NUExTIHN1cHBvcnQuDQoNCkkgYW0gYWxzbyBub3QgYXdhcmUgdGhhdCBSRkMgNTMz MSBoYXMgYmVlbiBwcm9wb3NlZCBhcyBhIGdlbmVyaWMgc29sdXRpb24gdG8gUkZDIDUxMjAgc3R5 bGUgTVQgZXZlbiBvdXRzaWRlIG9mIFNSIOKAkyBhbmQgbGlrZWx5IGZvciB0aGUgc2FtZSByZWFz b24g4oCTIGJlY2F1c2UgdGhlcmUgaXMgbm8gZXhpc3RpbmcgbWVjaGFuaXNtIGZvciBhZHZlcnRp c2luZyB0aGUgY29udGV4dCBsYWJlbHMgYXNzb2NpYXRlZCB3aXRoIGEgcHJlZml4L01UIHBhaXIu DQoNCiAgIExlcw0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0Bn bWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDA1LCAyMDE2IDEyOjMwIEFNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tOyBzcHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3By aW5nXSBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uDQoNCkhpIExlcywNCg0K PiBIb3dldmVyLCB0aGlzIGlzIG5vdCBleGlzdGluZyBNUExTIGZvcndhcmRpbmcgYmVoYXZpb3Ig YW5kIHNpbmNlIFNSDQo+IGV4cGxpY2l0bHkgdXRpbGl6ZXMgdGhlIGV4aXN0aW5nIE1QTFMgZm9y d2FyZGluZyBiZWhhdmlvciB3ZSBub3QgcHJvcG9zZQ0KPiBhbnkgZXh0ZW5zaW9ucy4NCg0KSSBh bSBhZnJhaWQgdGhlIGFib3ZlIGFzc2VydGlvbiBpcyBub3QgY29ycmVjdC4gRXhpc3RpbmcgTVBM UyBmb3J3YXJkaW5nIGFscmVhZHkNCmZvciBhIGxvbmcgdGltZSB1c2VzIGNvbnRleHQtbGFiZWxz IHRvIHNldCByZXF1aXJlZCB0b3BvbG9neSBmb3IgZm9yd2FyZGluZy4NCg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzUzMzENCg0KVGh4LA0KUi4NCg0KDQpPbiBUdWUsIEp1bCA1LCAy MDE2IGF0IDk6MTkgQU0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5j b208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+IHdyb3RlOg0KQnJ1bm8g4oCTDQoNClNSLU1Q TFMgdXRpbGl6ZXMgZXhpc3RpbmcgTVBMUyBmb3J3YXJkaW5nIGJlaGF2aW9yIHdpdGhvdXQgY2hh bmdlLiBJbiB0aGlzIG1vZGVsLCB0aGUgcmVjZWl2ZWQgbGFiZWwgc2VydmVzIGFzIHRoZSBmb3J3 YXJkaW5nIGluc3RydWN0aW9uIGZvciB0aGUgcGFja2V0LiBUaGlzIG1lYW5zIHRoYXQgaWYgdHdv IHBhY2tldHMgYXJlIHJlY2VpdmVkIGZvciB0aGUgc2FtZSBkZXN0aW5hdGlvbiBidXQgd2Ugd2Fu dCB0aGUgcGFja2V0IHRvIGZvbGxvdyB0d28gZGlmZmVyZW50IGZvcndhcmRpbmcg4oCcdG9wb2xv Z2llc+KAnSwgdGhlbiB3ZSBuZWVkIHRvIGhhdmUgdHdvIGRpZmZlcmVudCBsYWJlbHMuDQoNCk9u ZSBjYW4gaW1hZ2luZSBhIGRpZmZlcmVudCBtb2RlbCwgd2hlcmUgdGhlIGZvcndhcmRpbmcgaW5z dHJ1Y3Rpb24gaXMgZGVyaXZlZCBmcm9tIHRoZSBsYWJlbCBBTkQgc29tZSBvdGhlciBhdHRyaWJ1 dGUgb2YgdGhlIHBhY2tldCDigJMgYW5kIHRoZSBsYXR0ZXIgY291bGQgYmUgdXNlZCB0byBzZWxl Y3QgYSBmb3J3YXJkaW5nIHRvcG9sb2d5LiBIb3dldmVyLCB0aGlzIGlzIG5vdCBleGlzdGluZyBN UExTIGZvcndhcmRpbmcgYmVoYXZpb3IgYW5kIHNpbmNlIFNSIGV4cGxpY2l0bHkgdXRpbGl6ZXMg dGhlIGV4aXN0aW5nIE1QTFMgZm9yd2FyZGluZyBiZWhhdmlvciB3ZSBub3QgcHJvcG9zZSBhbnkg ZXh0ZW5zaW9ucy4NCg0KVGhpcyBpcyB3aHkgZGlmZmVyZW50IFNJRHMgYXJlIHJlcXVpcmVkIGZv ciB0aGUgc2FtZSBkZXN0aW5hdGlvbiBpbiBkaWZmZXJlbnQgdG9wb2xvZ2llcy4NCg0KICAgIExl cw0KDQoNCkZyb206IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20+IFttYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86 YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT5dDQpTZW50OiBNb25kYXksIEp1bHkgMDQsIDIwMTYg NTowNyBBTQ0KDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzcHJpbmdAaWV0Zi5v cmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXNwcmlu Zy1jb25mbGljdC1yZXNvbHV0aW9uDQoNCkxlcywNCg0KUGxlYXNlIHNlZSBpbmxpbmUgW0JydW5v M10NCg0KRnJvbTogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgW21haWx0bzpnaW5zYmVyZ0BjaXNj by5jb21dDQpTZW50OiBGcmlkYXksIEp1bHkgMDEsIDIwMTYgMzozNiBBTQ0KVG86IERFQ1JBRU5F IEJydW5vIElNVC9PTE4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uDQoN CkJydW5vIOKAkw0KDQpJbmxpbmUuDQoNCkZyb206IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208 bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+IFttYWlsdG86YnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDMwLCAyMDE2IDU6MTAgQU0NClRvOiBM ZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPg0KU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24NCg0KSGkgTGVzLA0KDQpUaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLiBQbGVhc2Ugc2Vl IGlubGluZSBbQnJ1bm9dDQoNCkZyb206IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIFttYWlsdG86 Z2luc2JlcmdAY2lzY28uY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDY6MTkg UE0NClRvOiBERUNSQUVORSBCcnVubyBJTVQvT0xODQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxp Y3QtcmVzb2x1dGlvbg0KDQpCcnVubyDigJMNCg0KDQpGcm9tOiBicnVuby5kZWNyYWVuZUBvcmFu Z2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiBbbWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjksIDIwMTYgNzoyMiBB TQ0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxp Y3QtcmVzb2x1dGlvbg0KDQpIaSBMZXMsDQoNCklJTk0sIEnigJl2ZSBub3Qgc2VlbiB0aGUgZm9s bG93IHVwIG9uIG9uZSBvZiBteSBiZWxvdyBxdWVzdGlvbnMuDQpTbyBsZXQgbWUgcmVzdGF0ZSBh IGNvbW1lbnQ6DQoNClRoZSBTUi1NUExTIFNJRCBjb25mbGljdHMgYWxnbyByZXF1aXJlcyB0aGF0 IGFsbCBub2RlcyBjb25zaWRlciB0aGUgc2FtZSBtYXBwaW5nIGFkdmVydGlzZW1lbnRzLg0KSG93 IGlzIHRoaXMgZW5zdXJlZCwgaWYgaXQgaW5kaWZmZXJlbnRseSBjb25zaWRlcnMgYWR2ZXJ0aXNl bWVudHMgZnJvbSBhbGwgcHJvdG9jb2xzLCB3aGlsZSBzb21lIG5vZGVzIGNvdWxkIHBhcnRpY2lw YXRlIG9ubHkgaW4gYSBzdWJzZXQgb2YgdGhlIHByb3RvY29scz8gZS5nLiBPU1BGIG9ubHkgcm91 dGVycyB3b3VsZCBjb25zaWRlciBhIGRpZmZlcmVudCBzZXQgb2YgaW5mb3JtYXRpb24gY29tcGFy ZWQgdG8gT1NQRitJUy1JUyByb3V0ZXJzLg0KDQpbTGVzOl0gSWYgeW91IHJ1biBtdWx0aXBsZSBw cm90b2NvbCBpbnN0YW5jZXMgKHdoZXRoZXIgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1l IHByb3RvY29sIG9yIGluc3RhbmNlcyBvZiBkaWZmZXJlbnQgcHJvdG9jb2xzKSB0aGVuIHlvdSBu ZWVkIHRvIGluc3VyZSB0aGF0IGF0IGxlYXN0IG9uZSBvZiB0aGUgdHdvIGNvbmRpdGlvbnMgYmVs b3cgaXMgdHJ1ZToNCg0K4oCiICAgICAgICAgQWxsIHJvdXRlcnMgcmVjZWl2ZSB0aGUgZXF1aXZh bGVudCBzZXQgb2YgYWR2ZXJ0aXNlbWVudHMNCg0K4oCiICAgICAgICAgVGhlcmUgYXJlIG5vIGNv bmZsaWN0cyDimLoNCg0KW0JydW5vXSBJT1csIHRoZSBkcmFmdCBkb2VzIG5vdCByZXNvbHZlIFNJ RCBjb25mbGljdCBpZiBhbGwgcm91dGVycyBkbyBub3QgcmVjZWl2ZSBleGFjdGx5IHRoZSBzYW1l IHNldCBvZiBhZHZlcnRpc2VtZW50IGZyb20gYWxsIHJvdXRpbmcgcHJvdG9jb2xzLg0KVGhhdOKA mXMgaW5kZWVkIGNhbiBiZSBhIHZhbGlkIHNpbXBsaWZpY2F0aW9uIGlmIHRoZSBXRyBjaG9vc2Ug dG8sIGJ1dCB0aGlzIHNob3VsZCBjbGVhcmx5IGJlIGluZGljYXRlZCBpbiB0aGUgZG9jdW1lbnQs IGluIGEgc2VjdGlvbiB0YXJnZXRpbmcgbmV0d29yayBvcGVyYXRvciBzaW5jZSB0aGlzIHBvaW50 IHdpbGwgbmVlZCB0byBiZSByZWFkIGFuZCBlbmZvcmNlZCBieSBuZXR3b3JrIG9wZXJhdG9yIHJh dGhlciB0aGFuIHByb3RvY29sIGltcGxlbWVudG9ycy4gwqczLjIuOCBhbHJlYWR5IHBhcnRseSBh ZGRyZXNzIHRoaXMsIGJ1dCBJTU8gYSB0ZXh0IGNsZWFybHkgZXhwcmVzc2luZyB0aGUgcmVxdWly ZW1lbnRzIG9uIG5ldHdvcmsgb3BlcmF0b3Igd291bGQgYmUgdXNlZnVsLg0KDQpbTGVzMjpdIE5v IHBvbGljeSBjYW4gZ3VhcmFudGVlIGNvbnNpc3RlbnQgcmVzdWx0cyBuZXR3b3JrIHdpZGUgaWYg dGhlIGRhdGFiYXNlcyBvbiBkaWZmZXJlbnQgbm9kZXMgYXJlIGluY29uc2lzdGVudC4gVGhpcyBp c27igJl0IGEg4oCcc2ltcGxpZmljYXRpb27igJ0g4oCTIGl0IGlzIGEgZmFjdC4gQXMgeW91IHBv aW50IG91dCwgU2VjdGlvbiAzLjIuOCBhbHJlYWR5IHN0YXRlczoNCg0K4oCcSW4gb3JkZXIgdG8g b2J0YWluIGNvbnNpc3RlbnQgYWN0aXZlIGVudHJpZXMgYWxsIG5vZGVzIGluIGEgbmV0d29yaw0K ICAgTVVTVCBoYXZlIHRoZSBzYW1lIG1hcHBpbmcgZW50cnkgZGF0YWJhc2Uu4oCdDQoNCklmIHlv dSBiZWxpZXZlIHRoaXMgaXMgbm90IGV4cGxpY2l0IGVub3VnaCBwbGVhc2Ugc3VnZ2VzdCBzb21l IHRleHQuDQpbQnJ1bm8zXQ0KU2VjdGlvbiA0IE1hbmFnZWFiaWxpdHkgQ29uc2lkZXJhdGlvbnMN CkRldGVjdGluZyBhbmQgcmVzb2x2aW5nIGNvbmZsaWN0cyBpbiBhIGNvbnNpc3RlbnQgd2F5IHJl cXVpcmVzIHRoYXQgYWxsIG5vZGVzIGNvbnNpZGVyIHRoZSBzYW1lIHNldCBvZiBTSURzIGFkdmVy dGlzZW1lbnRzLiBOZXR3b3JrIG9wZXJhdGlvbnMgc2hvdWxkIGJlIGF3YXJlIHRoYXQgdGhlIGNv bmZsaWN0IHJlc29sdXRpb24gYWxnb3JpdGhtIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCB3aWxs IG5vdCBzdWNjZWVkIGluIHNlbGVjdGluZyBhIGNvbnNpc3RlbnQgcmVzb2x1dGlvbiBhY3Jvc3Mg YWxsIG5vZGVzLCBpZiBhbGwgbm9kZXMgZG8gbm90IHJlY2VpdmUgdGhlIGV4YWN0IHNhbWUgc2V0 IG9mIFNJRHMgYWR2ZXJ0aXNlbWVudHMuIFRoaXMgbWF5IGJlIGluIHBhcnRpY3VsYXIgdGhlIGNh c2Ugd2hlbiBtdWx0aXBsZSBJR1AgaW5zdGFuY2VzIGFyZSB1c2VkIGFuZCBhbGwgcm91dGVycyBk byBub3QgcGFydGljaXBhdGUgaW4gdGhlIHNhbWUgc2V0IG9mIElHUCBpbnN0YW5jZXMuIFRoaXMg bWF5IG9jY3VycyBmb3IgZXhhbXBsZSBpZiBvbmUgbmV0d29yayB0cmFuc2l0aW9uIGZyb20gb25l IElHUCBwcm90b2NvbCB0byBhbm90aGVyIElHUCAoZS5nLiBmcm9tIE9TUEZ2MiB0byBJUy1JUyku IFRoaXMgbWF5IGFsc28gaGFwcGVuIGlmIElHUCBhcmVhcy9sZXZlbCBhcmUgdXNlZCBhbmQgU0lE cyBhcmUgbm90IGZsb29kZWQgaW4gYWxsIGFyZWFzL2xldmVscy4NCg0KDQpPbmUgd2F5IG9mIGlu c3VyaW5nIHRoZSBmaXJzdCBwb2ludCBpcyB0byBleGNsdXNpdmVseSB1c2UgYSBtYXBwaW5nIHNl cnZlciB0byBhZHZlcnRpc2UgU0lEcywgY29uZmlndXJlIHlvdXIgU1JNUyBlbnRyaWVzIGluIGEg cHJvdG9jb2wgaW5kZXBlbmRlbnQgbWFubmVyLCBhbmQgaW5zdXJlIHRoYXQgdGhlIFNSTVMgYWR2 ZXJ0aXNlbWVudHMgYXJlIHNlbnQgaW4gYWxsIG9mIHRoZSBwcm90b2NvbCBpbnN0YW5jZSBzcGVj aWZpYyBzdWItZG9tYWlucy4NCltCcnVub10gSU9XLCBkb27igJl0IG1ha2UgY29uZmlndXJhdGlv biBlcnJvcnMgOy0pDQpBcmUgeW91IGltcGx5aW5nIHRoYXQgdGhlIFNSTVMgY29uZmlndXJhdGlv biAoaGVuY2UgeWFuZyBtb2RlbCkgc2hvdWxkIGJlIHBlciBub2RlIHJhdGhlciB0aGFuIHBlciBw cm90b2NvbD8gb3IgYXQgbGVhc3Qgc2hvdWxkIGJlIGNvbmZpZ3VyYWJsZSBieSBub2RlIChhbmQg cG9zc2libHkgYWxzbyBieSBwcm90b2NvbHMpDQoNCltMZXMyOl0gTXkgcG9pbnQgaXMgKGh1bW9y b3VzIGlkZWFzIGFzaWRl4oCmKSB0aGF0IGlmIGEgZGVwbG95bWVudCB1c2VzIG11bHRpcGxlIHBy b3RvY29scywgdGhlIGVhc2llc3Qgd2F5IHRvIGd1YXJhbnRlZSB0aGF0IHRoZSBTSUQgbWFwcGlu ZyBkYXRhYmFzZSBvbiBhbGwgbm9kZXMgaW4gdGhlIG5ldHdvcmsgaXMgY29uc2lzdGVudCBpcyB0 byByZXN0cmljdCBTSUQgYWR2ZXJ0aXNlbWVudHMgdG8gU1JNUyBhZHZlcnRpc2VtZW50cy4NCltC cnVubzNdIENsZWFybHksIHRoZSBmZXdlciB0aGUgbnVtYmVyIG9mIGFkdmVydGlzZW1lbnRzIGZv ciBhIGdpdmVuIHByZWZpeCwgdGhlIGxlc3MgY2hhbmdlIG9mIGNvbmZsaWN0Lg0KQnV0IEkgZmFp bCB0byBzZWUgd2h5IG9ubHkgdXNpbmcgU1JNUyBndWFyYW50ZWUgYW55dGhpbmcuIGUuZy4gaWYg ZGlmZmVyZW50IG5vZGVzIHVzZSBhIGRpZmZlcmVudCBzZXQgb2Ygcm91dGluZyBwcm90b2NvbHMs IHlvdSBoYXZlIGNvbmZsaWN0cy4gSWRlbSBpZiB0aGUgbWlzY29uZmlndXJhdGlvbiBjb25zaXN0 IGluIGFkZGluZyBhIFNJRCB0byBhIElHUCBwcmVmaXggKFBGWCBhZHZlcnRpc2VtZW50KQ0KDQoN CkEgc21hbGwgbnVtYmVyIG9mIG5vZGVzIChhcyBmZXcgYXMgMSDigJMgbW9yZSBpZiByZWR1bmRh bmN5IGlzIGRlc2lyZWQpIGFyZSBzZXR1cCBhcyBtYXBwaW5nIHNlcnZlcnMgYW5kIGFsbCBTSURz IHdoaWNoIGFyZSByZXF1aXJlZCBuZXR3b3JrLXdpZGUgYXJlIGNvbmZpZ3VyZWQgb24gdGhlc2Ug bm9kZXMgYW5kIGFkdmVydGlzZWQgYnkgdGhlIHByb3RvY29sIGluc3RhbmNlKHMpIG9uIHRoYXQg bm9kZS4gSW4gdGhpcyB3YXkgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byBndWFyYW50ZWUgdGhhdCBh bGwgcHJlZml4IHJlYWNoYWJpbGl0eSBmcm9tIGFsbCBvZiB0aGUgcHJvdG9jb2wgaW5zdGFuY2Vz IHJ1bm5pbmcgaW4gdGhlIG5ldHdvcmsgYXJlIHByZXNlbnQgaW4gYWxsIHRoZSBwcm90b2NvbCBp bnN0YW5jZSBzdWItZG9tYWlucyB3aGljaCBleGlzdCDigJMgaXQgaXMgb25seSBuZWNlc3Nhcnkg dG8gaW5zdXJlIHRoYXQgYWxsIHByb3RvY29sIGluc3RhbmNlcyBhZHZlcnRpc2UgdGhlIHNhbWUg c2V0IG9mIFNSTVMgZW50cmllcy4NCltCcnVubzNdIEluIHRoZSBlbmQsIHRoaXMgZ2V0cyBiYWNr IHRvIHJlcXVpcmluZyBubyBjb25maWd1cmF0aW9uIG1pc3Rha2VzLg0KSXQgaXNu4oCZdCB0aGUg b25seSB3YXkgdG8gc3VwcG9ydCB0aGlzIOKAkyBidXQgaXQgaXMgbGlrZWx5IHRvIGJlIHRoZSBz aW1wbGVzdCBhbmQgbGVhc3QgZXJyb3IgcHJvbmUuIEluIGFueSBjYXNlIHRoaXMgaXNu4oCZdCBh IHJlcXVpcmVtZW50IOKAkyBpdCB3YXMgYSByZXNwb25zZSB0byB5b3VyIHF1ZXN0aW9uIGFzIHRv IGhvdyBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBnZXQgY29uc2lzdGVudCBTSUQgbWFwcGluZyBk YXRhYmFzZXMgb24gYWxsIG5vZGVzIGluIHN1Y2ggYSBjYXNlLiBUaGlzIGlzIG5vIHdheSBjaGFu Z2VzIGhvdyB0aGUgWUFORyBtb2RlbCBpcyBkZWZpbmVkLiBTUk1TIGNvbmZpZyBpcyBhbHdheXMg bm9kZSBzcGVjaWZpYy4NCg0KDQpJZiB0aGUgaW50ZW50IGlzIHRvIGRlbGliZXJhdGVseSB1c2Ug ZGlmZmVyZW50IGxhYmVscyBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBmb3IgdGhlIHNhbWUgZGVz dGluYXRpb24gZGVwZW5kaW5nIHVwb24gd2hpY2ggcHJvdG9jb2wgYWR2ZXJ0aXNlZCB0aGUgcHJl Zml4LCB0aGlzIGludHJvZHVjZXMgYSBudW1iZXIgb2YgbmV3IHJlcXVpcmVtZW50cyDigJMgbm90 IHRoZSBsZWFzdCBvZiB3aGljaCBpcyBkdXBsaWNhdGUgZW50cmllcyBmb3IgdGhlIHNhbWUgcHJl Zml4IGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLiAgQXMgaGFzIGJlZW4gZGlzY3Vzc2VkIHB1Ymxp Y2x5IGluIGEgZGlmZmVyZW50IHRocmVhZCwgdGhlcmUgYXJlIGNhc2VzIChlLmcuIG1lcmdpbmcg dHdvIG5ldHdvcmtzKSB3ZXJlIHN1Y2ggYSByZXF1aXJlbWVudCBtYXkgZXhpc3Qg4oCTIGJ1dCBp dCBpcyB0aGUgZXhjZXB0aW9uIHJhdGhlciB0aGFuIHRoZSBydWxlIGFuZCBhcyBpdCBjb25zdW1l cyBtb3JlIHJlc291cmNlcyBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBhbmQgaW50cm9kdWNlcyBp bXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IGluZGVwZW5kZW50IG9mIGNvbmZsaWN0IHJlc29sdXRp b24gaXQgaXMgbm90IHRoZSBwcmltYXJ5IGNhc2UgdGhlIGRyYWZ0IGZvY3VzZXMgb24uIE5ldmVy dGhlbGVzcywgdGhpcyBpcyBhIGNhc2Ugd2hpY2ggdGhlIGRyYWZ0IHdpbGwgYWRkcmVzcyBpbiB0 aGUgbmV4dCByZXZpc2lvbi4NCltCcnVub11UaGVyZSBpcyBhbHNvIHRoZSBwb2ludCBvZiBjb25m aWd1cmluZyBkaWZmZXJlbnQgU1JHQiBzcGFjZSBpbiBkaWZmZXJlbnQgSUdQIHByb3RvY29scy4g SW4gd2hpY2ggY2FzZSwgU0lEcyBtYXkgY29uZmxpY3QgYnV0IHRoaXMgaXMgbm90IGFuIGlzc3Vl IGFzIGxhYmVsIHdpbGwgbm90IGNvbmZsaWN0Lg0KV2Ugc3RvcHBlZCBzaG9ydCBvZiB0aGF0IGlu IHRoaXMgcmV2aXNpb24gYmVjYXVzZSB3ZSBmZWx0IHRoZXJlIHdlcmUgZW5vdWdoIHN1YnN0YW50 aXZlIGNoYW5nZXMgYW5kIHBvaW50cyBvbiB3aGljaCBjb25zZW5zdXMgaXMgc3RpbGwgYSB3b3Jr IGluIHByb2dyZXNzIHRoYXQgaXQgd291bGQgbm90IGJlIHRoZSBvcHRpbWFsIHdheSBmb3J3YXJk Lg0KW0JydW5vXSArMSBhbmQgdGhhbmtzLiBSZWxlYXNpbmcgYW4gdXBkYXRlZCB2ZXJzaW9uIGhh cyBiZWVuIHVzZWZ1bCB0byByZS1pbml0aWF0ZSB0aGUgZGlzY3Vzc2lvbi4NCg0KVGhpbmtpbmcg bW9yZSBhYm91dCB0aGlzLCBJIGd1ZXNzIHRoYXQgdGhpcyBpcyBvbmx5IGltcG9ydGFudCBmb3Ig dGhlIGVudHJpZXMgd2hpY2ggYXJlIGluc2VydGVkIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLiBI ZW5jZSwgaW4gY2FzZSBvZiBjb25mbGljdCBiZXR3ZWVuIHByb3RvY29scywgSSB0aGluayB0aGF0 IHRoZSBwcmVmZXJlbmNlIGFsZ29yaXRobSBzaG91bGQgdGFrZSBpbnRvIGFjY291bnQgdGhlIHBy b3RvY29sIHByZWZlcmVuY2UgKGFrYSBhZG1pbmlzdHJhdGl2ZSBkaXN0YW5jZSkuDQoNCltMZXM6 XSBBcyBhZG1pbiBkaXN0YW5jZSBpcyBuZWl0aGVyIGFuIGF0dHJpYnV0ZSBvZiBTUk1TIGVudHJp ZXMgbm9yIGd1YXJhbnRlZWQgdG8gYmUgY29uc2lzdGVudCBvbiBhbGwgcm91dGVycyBmb3IgYWxs IHByZWZpeGVzIHRoaXMgaXMgbm90IGEgZGVzaXJhYmxlIGFwcHJvYWNoLg0KW0JydW5vXSBXZWxs LCB0aGUgc29tZSBwcmVmaXgvcm91dGluZyBjb25zaXN0ZW5jeSBpcyBhbHNvIHJlcXVpcmVkIGZv ciBJUCBwcmVmaXhlcy4gV2hlbiB0aGVuIHNhbWUgSVAgcHJlZml4IGlzIGFkdmVydGlzZWQgaW4g ZGlmZmVyZW50IElHUHMsIGFkbWluIGRpc3RhbmNlIGlzIGEgY29tbW9uIGV4aXN0aW5nIHdheSB0 byBkZWZpbmUgd2hpY2ggcm91dGluZyBwcm90b2NvbCB0YWtlcyBwcmVjZWRlbmNlLiBJ4oCZbSBu b3Qgc3VyZSB3aHkgaXQgc2hvdWxkIG5vdCBhbHNvIGJlIHRha2VuIGludG8gY29uc2lkZXJhdGlv biBmb3IgU1IgUHJlZml4IGNvbmZsaXRzDQoNCltMZXMyOl0gUGxlYXNlIHNlZSBteSByZXNwb25z ZSB0byBTdGVwaGFuZSBvbiB0aGUgc2FtZSBwb2ludC4NCg0KSeKAmW0gYWxzbyBub3Qgc3VyZSB0 byBzZWUgd2h5IGlzIHRoZSBwcm9ibGVtIGRpZmZlcmVudCBjb21wYXJlZCB0byBNdWx0aS1Ub3Bv bG9neS4gQ291bGQgeW91IHBsZWFzZSBlbGFib3JhdGU/DQpbTGVzOl0gSSBhbSB1bmNsZWFyIHdo YXQgeW91ciBxdWVzdGlvbiBpcy4gQXJlIHlvdSBhc2tpbmcgd2h5IHdlIG5lZWQgZGlmZmVyZW50 IFNJRHMgaW4gZGlmZmVyZW50IHRvcG9sb2dpZXM/IFBsZWFzZSBjbGFyaWZ5Lg0KW0JydW5vXSBR dWVzdGlvbiB3YXMgdGhhdCwgYXQgYSB2ZXJ5L3RvbyBoaWdoIGxldmVsLCB0aGUgaXNzdWUgb2Yg Y29uZmxpY3QgYWNyb3NzIHRvcG9sb2d5IHNlZW1zIGNsb3NlIHRvIHRoZSBpc3N1ZSBvZiBjb25m bGljdCBhY3Jvc3Mgcm91dGluZyBwcm90b2NvbHM6ICB3ZSBoYXZlIGRpZmZlcmVudCB0b3BvbG9n aWVzLiBIZW5jZSBhIG5hw692ZSBxdWVzdGlvbjogaG93IGV4YWN0bHkgaXMgdGhpcyBkaWZmZXJl bnQuDQpPbmUgcGFydCBvZiB0aGUgYW5zd2VyLCBpcyB0aGUgc2ltcGxpZmljYXRpb24gcHJvcG9z ZWQgd2hlbiBtdWx0aXBsZSBwcm90b2NvbHMgaXMgdXNlZCAoaS5lLiB5b3VyIGZpcnN0IGFuc3dl ciBhYm92ZSkuDQpBbm90aGVyIHBhcnQgaXMgdGhhdCBmb3IgbXVsdGktdG9wb2xvZ3ksIGNvbXBh cmVkIHRvIG11bHRpLXByb3RvY29scywgYWxsIGluZm9ybWF0aW9uIGZyb20gYWxsIHRvcG9sb2dp ZXMgYXJlIGZsb29kZWQgdG8gYWxsIG5vZGVzLg0KQW5vdGhlciBwYXJ0IGlzIHRoZSBmb3J3YXJk aW5nIG1vZGVsIHVzZWQgZm9yIE11bHRpLVRvcG9sb2d5LiBJbiBnZW5lcmFsLCBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTEyMCNzZWN0aW9uLTggc2VlbXMgdG8gYXNzdW1lIHRoYXQg ZWFjaCB0b3BvbG9neSBoYXMgb25lIGRlZGljYXRlZCBSSUIvRklCLiBJbiBzdWNoIGNvbmRpdGlv biwgdGhlcmUgaXMgbm8gY29uZmxpY3QgKHByZWZpeCBvciBTSUQpIHNvIG5vIG5lZWQgdG8gZGV0 ZWN0IGFuZCByZXNvbHZlIGNvbmZsaWN0LiBTbyBoZXJlIHRoZXJlIG1heSBiZSBkaWZmZXJlbnQg bW9kZWxzIGFuZCBldmVudHVhbGx5LCB3ZSBkb27igJl0IOKAmGhhdmUgdGhlIHNhbWUgb25lIGlu IG1pbmQuDQpJbiBhIGxlc3NlciBleHRlbmQsIGV2ZW4gZm9yIG11bHRpLXByb3RvY29scywgd2Ug bWF5IGhhdmUgdGhvc2UgbXVsdGlwbGUgZm9yd2FyZGluZyBtb2RlbHMuIFRvIHNvbWUgZXh0ZW50 LCB0aGlzIHNlZW1zIHJlbGF0ZWQgdG8gdGhlIGRlZmluaXRpb24gb2Yg4oCcU1IgZG9tYWlu4oCd LiBlLmcuIGlmIHdlIGhhdmUgMiBJR1BzLCBkbyB3ZSBoYXZlIDEgb3IgMiBTUiBkb21haW5zPyBN YXkgYmUgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBjb25maWd1cmFibGUNCg0K DQpbTGVzMjpdIFBsZWFzZSByZXJlYWQgU2VjdGlvbiAzLjEuMi4gV2hpbGUgdGhlcmUgYXJlIG5v IOKAnFByZWZpeC1jb25mbGljdHPigJ0gYWNyb3NzIHRvcG9sb2dpZXMsIHRoZXJlIGFyZSDigJxT SUQgQ29uZmxpY3Rz4oCdLiBUaGlzIGlzIGltcG9ydGFudCB0byB1bmRlcnN0YW5kLg0KW0JydW5v M10gQ29uZmxpY3RzIGFyZSByZWxhdGVkIHRvIGEgZm9yd2FyZGluZyBjb250ZXh0IGkuZS4gRklC LiBUaGlzIGlzIGVxdWFsbHkgaW1wb3J0YW50IHRvIHVuZGVyc3RhbmQuIFBsZWFzZSByZWFkIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MTIwI3NlY3Rpb24tOC4yLjIgYW5kIDguMi4x IHRvIHNlZSB0aGF0IHRvcG9sb2dpZXMgbWF5IG5vdCBzaGFyZSB0aGUgc2FtZSBmb3J3YXJkaW5n IGNvbnRleHQgaGVuY2UgZG8gbm90IGNvbmZsaWN0IGluIHRlcm0gb2YgcHJlZml4ICYgU0lELg0K LS1CcnVubw0KDQpBcyByZWdhcmRzIG11bHRpcGxlIHByb3RvY29scyBvcGVyYXRpbmcgaW4gdGhl IHNhbWUgdG9wb2xvZ3ksIGZyb20gYSBmb3J3YXJkaW5nIHBlcnNwZWN0aXZlIHdlIGRvIG5vdCBj YXJlIHdoYXQgcHJvdG9jb2wgaXMgdGhlIHdpbm5pbmcgcm91dGUuIFdoYXQgd2UgY2FyZSBhYm91 dCBpcyB0aGF0IG91ciBuZXh0aG9wIGhhcyBjaG9zZW4gdGhlIHNhbWUgU0lEIGZvciBhIGdpdmVu IHByZWZpeC4gVGhpcyBpcyB3aHkg4oCcc291cmNl4oCdIGlzIGRlbGliZXJhdGVseSBleGNsdWRl ZCBmcm9tIGNvbnNpZGVyYXRpb24gYnkgdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gYWxnb3JpdGht Lg0KDQogICAgTGVzDQoNCiAgICBMZXMNCg0KDQpUaGFua3MsDQpCcnVubw0KDQpGcm9tOiBzcHJp bmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+DQpTZW50 OiBXZWRuZXNkYXksIE1heSAxOCwgMjAxNiAxOjU3IFBNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5z YmVyZyk7IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KTGVz LA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQpQbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dDQoN CkZyb206IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIFttYWlsdG86Z2luc2JlcmdAY2lzY28uY29t XQ0KU2VudDogU2F0dXJkYXksIE1heSAxNCwgMjAxNiA4OjMwIFBNDQpUbzogREVDUkFFTkUgQnJ1 bm8gSU1UL09MTjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg0KDQpCcnVubyDi gJMNCg0KSW5saW5lLg0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20+DQpTZW50OiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IDg6MjMg QU0NClRvOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6 IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KSGksDQoN CkFzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3IsIHBsZWFzZSBmaW5kIGJlbG93IHNvbWUgY29t bWVudHM6DQoNCi0tDQpJc27igJl0IHRoaXMgZG9jdW1lbnQgc3BlY2lmaWMgdG8gdGhlIE1QTFMg ZGF0YXBsYW5lPw0KSWYgc28sIGl0IGNvdWxkIGJlIGluZGljYXRlZCBpbiB0aGUgaW50cm9kdWN0 aW9uLCBhbmQgcG9zc2libHkgaW4gdGhlIGFic3RyYWN0LiBUaGVuIHRoaXMgaW5kaWNhdGlvbiBj b3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIDFyc3Qgc2VudGVuY2Ugb2Ygc2VjdGlvbnMgMiAmIDMu DQoNCltMZXM6XSBDdXJyZW50bHkgYWxsIGRpc2N1c3Npb24gaXMgcmVnYXJkaW5nIFNSLU1QTFMu IFRoZSBkcmFmdCBsZWF2ZXMgb3BlbiB0aGUgcG9zc2liaWxpdHkgdGhhdCBpZiB0aGVyZSBpcyBz b21lIFNSdjYgY29uZmxpY3QgcmVzb2x1dGlvbiB0aGF0IG5lZWRzIHRvIGJlIHNwZWNpZmllZCBp dCBjb3VsZCBiZSBhZGRlZCBpbnRvIHRoaXMgZG9jdW1lbnQg4oCTIHdoaWNoIGlzIHdoeSB0aGUg SW50cm9kdWN0aW9uIGlzIGRhdGFwbGFuZSBhZ25vc3RpYywgYnV0IGVhY2ggc2VjdGlvbiBzdGF0 ZXMgc3BlY2lmaWNhbGx5IHRoYXQgaXQgaXMgcmVsZXZhbnQgdG8gU1ItTVBMUy4NCg0KSSBhbSBu b3QgYXdhcmUgb2YgYW55IFNSdjYgY29uZmxpY3QgcmVzb2x1dGlvbiB0aGF0IGlzIHJlcXVpcmVk IGF0IHRoaXMgcG9pbnQsIGJ1dCBJIHByZWZlciB0byBsZWF2ZSB0aGUgcG9zc2liaWxpdHkgb3Bl biBpZiB0aGF0IGlzIE9LIHdpdGggeW91Lg0KW0JydW5vXSBvaywgZ3JlYXQuDQotLQ0KwqczDQri gJxNYXBwaW5nIGVudHJpZXMgaGF2ZSBhbiBleHBsaWNpdCBjb250ZXh0IHdoaWNoIGluY2x1ZGVz IHRoZSB0b3BvbG9neSBhbmQgdGhlIFNSIGFsZ29yaXRobS7igJwNCkEgcHJpb3JpIHlvdSBjb3Vs ZCBhZGQg4oCcdGhlIHJvdXRpbmcgcHJvdG9jb2zigJ0uDQoNCltMZXM6XSBObyDigJMgdGhlIHNv dXJjZSBvZiBhZHZlcnRpc2VtZW50cyBpcyBkZWxpYmVyYXRlbHkgbGVmdCBvdXQuIEl0IG1hdHRl cnMgbm90IHdoZXRoZXIgdGhlIHNvdXJjZSBvZiB0aGUgYWR2ZXJ0aXNlbWVudCBpcyBhIHByb3Rv Y29sIG9yIGFuIFNSTVMg4oCTIG5vciBkb2VzIGl0IG1hdHRlciB3aGljaCBwcm90b2NvbCBwcm92 aWRlcyB0aGUgYWR2ZXJ0aXNlbWVudC4gWW91IHNlZSB0aGF0IOKAnGFkbWluIGRpc3RhbmNl4oCd IGlzIG5vdCBtZW50aW9uZWQgYXQgYWxsIGFuZCB0aGF0IGlzIHF1aXRlIGRlbGliZXJhdGUuIFRo aXMgaW5zdXJlcyB0aGF0IGNvbnNpc3RlbnQgY2hvaWNlcyBhcmUgbWFkZSBvbiBub2RlcyByZWdh cmRsZXNzIG9mIHdoaWNoIHByb3RvY29sIG1pZ2h0IGhhdmUgdGhlIGJlc3Qgcm91dGUgb24gYSBn aXZlbiBub2RlLg0KW0JydW5vXSBXZWxsLCB0aGUgZmFjdCBpcyB0aGF0IG1hcHBpbmcgZW50cmll cyBkbyBoYXZlLCBhcyBleHBsaWNpdCBjb250ZXh0LCB0aGUgcm91dGluZyBwcm90b2NvbCB1c2Vk IHRvIGFkdmVydGlzZSB0aGVtLiBBZnRlciwgeW91IGNhbiBzaG91bGQgdG8gdXNlIHRoYXQgaW5m b3JtYXRpb24sIG9yIG5vdC4NCi0tDQrCpzMNCg0K4oCcV2hlbiBjb25mbGljdHMgb2NjdXIsIGl0 IGlzIG5vdA0KDQogICBwb3NzaWJsZSBmb3Igcm91dGVycyB0byBrbm93IHdoaWNoIG9mIHRoZSBj b25mbGljdGluZyBhZHZlcnRpc2VtZW50cw0KDQogICBpcyAiY29ycmVjdCIuICBJZiBhIHJvdXRl ciBjaG9vc2VzIHRvIHVzZSBvbmUgb2YgdGhlIGNvbmZsaWN0aW5nDQoNCiAgIGVudHJpZXMgZm9y d2FyZGluZyBsb29wcyBhbmQvb3IgYmxhY2tob2xlcyBtYXkgcmVzdWx0IHVubGVzcyBpdCBjYW4N Cg0KICAgYmUgZ3VhcmFudGVlZCB0aGF0IGFsbCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3b3Jr IG1ha2UgdGhlIHNhbWUNCg0KICAgY2hvaWNlLiAgTWFraW5nIHRoZSBzYW1lIGNob2ljZSByZXF1 aXJlcyB0aGF0IGFsbCByb3V0ZXJzIGhhdmUNCg0KICAgaWRlbnRpY2FsIHNldHMgb2YgYWR2ZXJ0 aXNlbWVudHMgYW5kIHRoYXQgdGhleSBhbGwgdXNlIHRoZSBzYW1lDQoNCiAgIHNlbGVjdGlvbiBh bGdvcml0aG0uIMK7DQoNCg0KDQpJIHRoaW5rIHdlIGFncmVlIG9uIHRoZSB0ZWNobmljYWwgcGFy dCwgYnV0IEkgZm91bmQgdGhlIGZvcm11bGF0aW9uIHNsaWdodGx5IGJpYXNlZC4gSSB3b3VsZCBw cm9wb3NlDQoNCuKAnFdoZW4gY29uZmxpY3RzIG9jY3VyLCBpdCBpcyBub3QNCg0KICAgcG9zc2li bGUgZm9yIHJvdXRlcnMgdG8ga25vdyB3aGljaCBvZiB0aGUgY29uZmxpY3RpbmcgYWR2ZXJ0aXNl bWVudHMNCg0KICAgaXMgImNvcnJlY3QiLiAgSW4gb3JkZXIgdG8gYXZvaWQgZm9yd2FyZGluZyBs b29wcyBhbmQvb3IgYmxhY2tob2xlcywgdGhlcmUgaXMgYSBuZWVkIGZvciBhbGwgbm9kZXMgdG8g bWFrZSB0aGUgc2FtZSBjaG9pY2UuDQoNCiAgTWFraW5nIHRoZSBzYW1lIGNob2ljZSByZXF1aXJl cyB0aGF0IGFsbCByb3V0ZXJzIGhhdmUNCg0KICAgaWRlbnRpY2FsIHNldHMgb2YgYWR2ZXJ0aXNl bWVudHMgYW5kIHRoYXQgdGhleSBhbGwgdXNlIHRoZSBzYW1lDQoNCiAgIHNlbGVjdGlvbiBhbGdv cml0aG0uIFRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudC4gwrsNCi0tDQpbTGVz Ol0gSSBhbSBmaW5lIHdpdGggdGhpcyBjaGFuZ2UuDQpbQnJ1bm9dIFRoYW5rcw0KDQrCpzMuMQ0K DQrigJxWYXJpb3VzIHR5cGVzIG9mIGNvbmZsaWN0cyBtYXkgb2NjdXLigJ0NCg0KV2hhdCBhYm91 dCA6cy9WYXJpb3VzL1R3bw0KDQpbTGVzOl0g4oCcVHdv4oCdIGlzIGZpbmUuIEp1c3QgbWVhbnMg d2Ugd2lsbCBoYXZlIHRvIGNoYW5nZSBpdCBpZiB3ZSBjb21lIHVwIHdpdGggYSB0aGlyZCB0eXBl IG9mIGNvbmZsaWN0LiDimLoNCltCcnVub10gSW5kZWVkLCBidXQgaW4gdGhpcyBjYXNlIHRoZSBj aGFuZ2UgbWF5IGJlIG11Y2ggbGFyZ2VyIChlLmcuIHRoZSB3aG9sZSBhbGdvKQ0KLS0NCkkgYWdy ZWUgd2l0aCBSb2JlcnTigJlzICBhbmQgVW1h4oCZcyBjb21tZW50IHdpdGggcmVnYXJkcyB0byBt YWtpbmcgdGhpcyBjb25mbGljdCByZXNvbHV0aW9uIGFuIGludGVyLSBwcm90b2NvbC9yb3V0aW5n X3RhYmxlIGlzc3VlLiBJbiBwYXJ0aWN1bGFyLCBiZXR3ZWVuIFNSIGRvbWFpbnMsIHRoZXJlIGlz IG5vdCByZXF1aXJlbWVudCB0byBoYXZlIHVuaXF1ZSBTSURzLiBIZW5jZSBiZXR3ZWVuIFBFIGFu ZCBDRSwgYmV0d2VlbiBBU2VzIChib3RoIHdpdGhpbiBhbmQgYWNyb3NzIG9yZ2FuaXphdGlvbiks IHRoZSBzYW1lIFNJRCBjb3VsZCBiZSByZXVzZWQgaW5kZXBlbmRlbnRseSkuDQoNCltMZXM6XSBU aGVyZSBpcyBtb3JlIHRvIGJlIHNhaWQgb24gdGhpcyB0b3BpYyDigJMgY28tYXV0aG9ycyBhcmUg YWN0aXZlbHkgZGlzY3Vzc2luZyB0aGlzIHBvaW50IGFuZCB3ZeKAmWxsIHJlc3BvbmQgbW9yZSBm dWxseSB0byBSb2JlcnTigJlzIHBvc3QgaW4gdGltZS4gQnV0LCB0aGUgZHJhZnQgaXMgTk9UIHRy eWluZyB0byBkZWZpbmUgY29uZmxpY3QgcmVzb2x1dGlvbiBhY3Jvc3Mg4oCcU1IgZG9tYWluc+KA nS4gUGVyaGFwcyB3ZSBuZWVkIGxhbmd1YWdlIHRvIG1ha2UgdGhhdCBtb3JlIGV4cGxpY2l0Lg0K W0JydW5vXSBvay4gUmVnYXJkaW5nIGludGVyLXByb3RvY29sLCBpbiBvcmRlciB0byBoYXZlIGNv bnNpc3RlbmN5IG9mIHRoZSBwcmVmaXgtU0lEIG1hcHBpbmcgYWNyb3NzIHRoZSBkb21haW4gd2Ug bmVlZDoNCmEpIGFsbCBub2RlcyB1c2UgdGhlIHNhbWUgYWxnbw0KYikgYWxsIG5vZGVzIHVzaW5n IHRoaXMgYWxnbyBoYXZlIHRoZSBzYW1lIGRhdGENCg0K4oCcYeKAnSByZXF1aXJlcyB0aGlzIGRy YWZ0DQrigJxi4oCdIHJlcXVpcmVzIHRoYXQgYWxsIG5vZGVzIGhhdmUgdGhlIHNhbWUgc2V0IG9m IFNSICBpbmZvLiBUaGlzIGZvcmJpZCB0aGF0IHNvbWUgbm9kZSBhcmUgY29uc2lkZXJpbmcgSVMt SVMgKyBPU1BGIFNSIGRhdGEsIHdoaWxlIHNvbWUgbm9kZSBhcmUgb25seSBjb25zaWRlcmluZyBJ Uy1JUyBkYXRhLiBPdGhlcndpc2UsIGFsbCBJUy1JUyByb3V0ZXJzIHdvdWxkIG5vdCB0YWtlIHRo ZSBzYW1lIGRlY2lzaW9uLiBTbywgdW5sZXNzIHdlIGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgZmxv b2RpbmcgYXJlYSBpcyB0aGUgc2FtZSBmb3IgSVMtSVMgYW5kIE9TUEYsIHdlIGNhbid0IGhhdmUg dGhlIGFsZ28gdXNpbmcgdGhlIFNSIGRhdGEgZnJvbSBtdWx0aXBsZSByb3V0aW5nIHByb3RvY29s cy4gSSBkb24ndCB0aGluayB0aGF0IHdlIGNhbiBndWFyYW50ZWUgdGhpcyAobm9yIHRoYXQgaW1w bGVtZW50YXRpb24gd2lsbCBjaGVjayB0aGlzKSBlLmcuIHdoZW4gc29tZSBub2RlcyBhcmUgcGFy dCBvZiBtdWx0aXBsZSByb3V0aW5nIGRvbWFpbiBvciB3aGVuIGdyYWR1YWxseSB0cmFuc2l0aW9u aW5nIGZyb20gb25lIElHUCB0byBhbm90aGVyLg0KDQpTbyBpbiBzaG9ydCwgdGhpcyBTUi1jb25m bGljdCBhbGdvIHNob3VsZCBwcm9iYWJseSBiZSByZXN0cmljdGVkIHRvIFNSIGluZm9ybWF0aW9u IGZyb20gYSBzaW5nbGUgcHJvdG9jb2wNCg0KPiBGcm9tOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJn KSBbbWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbV0gPiBTZW50OiBTdW5kYXksIE1heSAwMSwgMjAx NiA3OjExIEFNDQo+DQo+IFdlIGFyZSBpbmRlZWQgZGVmaW5pbmcgY29uZmxpY3QgcmVzb2x1dGlv biBhY3Jvc3MgYWxsIHRoZSBTSUQgYWR2ZXJ0aXNlbWVudHMgcmVnYXJkbGVzcyBvZiBzb3VyY2Ug KHByb3RvY29sIG9yIFNSTVMpDQo+IFdoeT8gQmVjYXVzZSB3ZSBuZWVkIGNvbnNpc3RlbnQgdXNl IG9mIFNJRHMgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUNCg0KTm86IGluIHRoZSBmb3J3YXJkaW5n IHBsYW5lLCB3ZSBuZWVkIGEgY29uc2lzdGVudCB1c2Ugb2YgTVBMUyBsYWJlbC4NCltMZXM6XSBB cyB5b3Uga25vdywgU1JHQiByYW5nZSBjYW4gYmUgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgbm9k ZXMsIHNvIHRoZSBhY3R1YWwgbGFiZWwgdGhhdCBpcyB1c2VkIHRvIHNlbmQgYSBwYWNrZXQgZm9y IGEgZ2l2ZW4gZGVzdGluYXRpb24gdmlhIE5vZGUgQSBtYXkgYmUgZGlmZmVyZW50IHRoYW4gdGhl IGxhYmVsIHVzZWQgdG8gc2VuZCB0aGUgc2FtZSBwYWNrZXQgdmlhIE5vZGUgQi4gSXQgaXMgdGhl IFNJRCB0aGF0IG5lZWRzIHRvIGJlIHRoZSBzYW1lIOKAkyBub3QgdGhlIGxhYmVsLg0KSXQgaXMg dHJ1ZSB0aGF0IFNJRHMgYXJlIG5vdCBpbnN0YWxsZWQgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUg 4oCTIHRoZSBsYWJlbHMgZGVyaXZlZCBmcm9tIHRoZSBTSUQvU1JHQiBhcmUgd2hhdCBpcyBhY3R1 YWxseSBpbnN0YWxsZWQgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUg4oCTIGJ1dCBJIHRoaW5rIG15 IHVzZSBvZiB0aGUgd29yZCBTSUQgaW4gdGhpcyBjb250ZXh0IGlzIGNvcnJlY3QuDQpbQnJ1bm9d IE15IHBvaW50IHdhcyB0aGF0IHRoZSBmb3JtdWxhdGlvbiBhc3N1bWVzIHRoYXQgYSBzaW5nbGUg U1JHQiBpcyB1c2VkIHBlciBub2Rlcy4gSW4gd2hpY2ggY2FzZSwgd2UgaGF2ZSBhIGJpamVjdGlv biBiZXR3ZWVuIFNJRCBhbmQgbGFiZWxzLiBCdXQgaWYgd2UgaGF2ZSBhIFNSR0IgcGVyIHByb3Rv Y29sLCB3ZSBkb27igJl0IGhhdmUgYSBiaWplY3Rpb24gYW55IG1vcmUgYW5kIHdlIGNhbiBoYXZl IHRoZSBzYW1lIFNJRCBpbiBJUy1JUyBhbmQgT1NQRiAoaW5jbHVkaW5nIGZvciBkaWZmZXJlbnQg cHJlZml4KSwgd2hpY2ggd2lsbCBiZSBtYXBwZWQgdG8gZGlmZmVyZW50IGxhYmVscyBpbiB0aGUg Zm9yd2FyZGluZyBwbGFuZS4NCg0KUGx1cyBvbmx5IHdpdGhpbiBhbiBTUiBkb21haW4uIEFjdHVh bGx5LCBldmVuIHdpdGhpbiBhIGRvbWFpbiwgdGhpcyBpcyBkZXBlbmRlbnQgb24gd2hldGhlciBT UkdCIGlzIGNvbmZpZ3VyZWQgb24gYSBwZXIgbm9kZSBvciBhIHBlciBwcm90b2NvbCBiYXNpcy4g SeKAmW0gbm90IHN1cmUgaG93IG11Y2ggdGhlIGFncmVlbWVudCBoYXMgYmVlbiByZWFjaGVkIG9u IHRoYXQgb25lLg0KDQpbTGVzOl0gVGhlIGRyYWZ0IGN1cnJlbnRseSBhZGRyZXNzZXMgZGVwbG95 bWVudHMgd2hlcmUgYSBzaW5nbGUgKHNldCBvZikgU1JHQiByYW5nZXMgYXBwbGllcyB0byB0aGUg Ym94LiBUaGlzIGlzIGJ5IGZhciB0aGUgbW9zdCBjb21tb24gdXNlIGNhc2UuIFRoZXJlIGlzIGEg bXVjaCBtb3JlIGxpbWl0ZWQgdXNlIGNhc2Ugd2hlcmUgcHJvdG9jb2wgc3BlY2lmaWMgU1JHQnMg YW5kIHByb3RvY29sIHNwZWNpZmljIFNJRHMgbWF5IGJlIHJlcXVpcmVkLiBUaGUgZHJhZnQgd2ls bCBhZGRyZXNzIHRoYXQgaW4gYSBmdXR1cmUgcmV2aXNpb24NCltCcnVub10gb2ssIG1heSBiZSB0 aGlzIHNob3VsZCBiZSBzdGF0ZWQgaW4gdGhlIGRyYWZ0LCBhcyBvdGhlcndpc2UgeW914oCZbGwg a2VlcCBnZXR0aW5nIGNvbW1lbnRzLCBvciB3ZSBtYXkgZm9yZ2V0IHRoaXMgcG9pbnQuDQpUaGFu a3MNCi0tQnJ1bm8NCuKAkyBidXQgaW4gc3Bpcml0IHRoZSBzYW1lIHJ1bGVzIHdpbGwgYXBwbHkg 4oCTIHRoZXkgd2lsbCBqdXN0IGhhdmUgdG8gdGFrZSBpbnRvIGFjY291bnQg4oCcZHVwbGljYXRl IGZvcndhcmRpbmcgZG9tYWluc+KAnS4gTm90ZSB0aGF0IHRoaXMgd2lsbCBhbHNvIHJlcXVpcmUg bXVsdGlwbGUgaW5jb21pbmcgbGFiZWwgZW50cmllcy9wcmVmaXggYmUgc3VwcG9ydGVkIGJ5IHRo ZSByb3V0ZXJzIGluIHN1Y2ggYSBuZXR3b3JrLg0KDQotLQ0KVHlwbzoNCsKnMg0KT0xEIDogUmFu Z2UgMzogKDUwMCwgNTk5MA0KTkVXIDogUmFuZ2UgMzogKDUwMCwgNTk5KQ0KDQooc29tZXdoYXQg c2lnbmlmaWNhbnQgYXMgb3RoZXJ3aXNlIHJhbmdlIDMgY29uZmxpY3Qgd2l0aCByYW5nZSAyKQ0K DQpbTGVzOl0gQWdyZWVkIOKAkyB0aGFueCBmb3Igc3BvdHRpbmcgdGhpcy4NCg0KICAgTGVzDQoN ClRoYW5rcywNClJlZ2FyZHMsDQpCcnVubw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIN Cg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0K dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoN CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4NCg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s DQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nDQoNCg== --_000_fd37aeb70f4940818f83b7f4d48abf68XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb2JlcnQg4oCTPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5V c2Ugb2YgUkZDIDUzMzEgd291bGQgcmVxdWlyZSB0aGF0IHdlIGhhdmUgYSB3YXkgdG8gYWR2ZXJ0 aXNlIHRoZSBjb250ZXh0IGxhYmVsIGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeC1TSUQgYWR2ZXJ0 aXNlbWVudCAod2hldGhlciBpbiBwcmVmaXggcmVhY2hhYmlsaXR5IG9yDQogU1JNUykuIFRoaXMg Y2FwYWJpbGl0eSBkb2VzIG5vdCBjdXJyZW50bHkgZXhpc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBJIGJlbGll dmUgbXkgYW5zd2VyIGlzIGNvcnJlY3QgYmFzZWQgb24gZXhpc3RpbmcgZGVmaW5pdGlvbiBvZiBT Ui1NUExTIHN1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIGFsc28gbm90IGF3YXJlIHRoYXQgUkZDIDUz MzEgaGFzIGJlZW4gcHJvcG9zZWQgYXMgYSBnZW5lcmljIHNvbHV0aW9uIHRvIFJGQyA1MTIwIHN0 eWxlIE1UIGV2ZW4gb3V0c2lkZSBvZiBTUiDigJMgYW5kIGxpa2VseSBmb3IgdGhlIHNhbWUgcmVh c29uIOKAkyBiZWNhdXNlDQogdGhlcmUgaXMgbm8gZXhpc3RpbmcgbWVjaGFuaXNtIGZvciBhZHZl cnRpc2luZyB0aGUgY29udGV4dCBsYWJlbHMgYXNzb2NpYXRlZCB3aXRoIGEgcHJlZml4L01UIHBh aXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgTGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBy cmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMDUs IDIwMTYgMTI6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpPGJy Pg0KPGI+Q2M6PC9iPiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tOyBzcHJpbmdAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZs aWN0LXJlc29sdXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBMZXMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IEhvd2V2ZXIs IHRoaXMgaXMgbm90IGV4aXN0aW5nIE1QTFMgZm9yd2FyZGluZyBiZWhhdmlvciBhbmQgc2luY2Ug U1ImbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mZ3Q7IGV4cGxpY2l0bHkgdXRpbGl6ZXMgdGhlIGV4aXN0aW5nIE1QTFMg Zm9yd2FyZGluZyBiZWhhdmlvciB3ZSBub3QgcHJvcG9zZSZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgYW55IGV4 dGVuc2lvbnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkkgYW0gYWZyYWlkIHRoZSBhYm92ZSBhc3NlcnRpb24gaXMgbm90IGNvcnJlY3QuIEV4aXN0aW5n IE1QTFMgZm9yd2FyZGluZyBhbHJlYWR5Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmZvciBhIGxvbmcgdGlt ZSB1c2VzIGNvbnRleHQtbGFiZWxzIHRvIHNldCByZXF1aXJlZCB0b3BvbG9neSBmb3IgZm9yd2Fy ZGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzMxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTMzMTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaHgsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlIuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFR1ZSwgSnVsIDUsIDIwMTYgYXQgOToxOSBBTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgJmx0 OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5naW5z YmVyZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnJ1 bm8g4oCTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U1ItTVBMUyB1 dGlsaXplcyBleGlzdGluZyBNUExTIGZvcndhcmRpbmcgYmVoYXZpb3Igd2l0aG91dCBjaGFuZ2Uu IEluIHRoaXMgbW9kZWwsIHRoZSByZWNlaXZlZCBsYWJlbCBzZXJ2ZXMgYXMgdGhlIGZvcndhcmRp bmcgaW5zdHJ1Y3Rpb24gZm9yIHRoZSBwYWNrZXQuDQogVGhpcyBtZWFucyB0aGF0IGlmIHR3byBw YWNrZXRzIGFyZSByZWNlaXZlZCBmb3IgdGhlIHNhbWUgZGVzdGluYXRpb24gYnV0IHdlIHdhbnQg dGhlIHBhY2tldCB0byBmb2xsb3cgdHdvIGRpZmZlcmVudCBmb3J3YXJkaW5nIOKAnHRvcG9sb2dp ZXPigJ0sIHRoZW4gd2UgbmVlZCB0byBoYXZlIHR3byBkaWZmZXJlbnQgbGFiZWxzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9uZSBjYW4gaW1hZ2luZSBhIGRpZmZl cmVudCBtb2RlbCwgd2hlcmUgdGhlIGZvcndhcmRpbmcgaW5zdHJ1Y3Rpb24gaXMgZGVyaXZlZCBm cm9tIHRoZSBsYWJlbCBBTkQgc29tZSBvdGhlciBhdHRyaWJ1dGUgb2YgdGhlIHBhY2tldCDigJMg YW5kIHRoZSBsYXR0ZXINCiBjb3VsZCBiZSB1c2VkIHRvIHNlbGVjdCBhIGZvcndhcmRpbmcgdG9w b2xvZ3kuIEhvd2V2ZXIsIHRoaXMgaXMgbm90IGV4aXN0aW5nIE1QTFMgZm9yd2FyZGluZyBiZWhh dmlvciBhbmQgc2luY2UgU1IgZXhwbGljaXRseSB1dGlsaXplcyB0aGUgZXhpc3RpbmcgTVBMUyBm b3J3YXJkaW5nIGJlaGF2aW9yIHdlIG5vdCBwcm9wb3NlIGFueSBleHRlbnNpb25zLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgd2h5IGRpZmZlcmVudCBT SURzIGFyZSByZXF1aXJlZCBmb3IgdGhlIHNhbWUgZGVzdGluYXRpb24gaW4gZGlmZmVyZW50IHRv cG9sb2dpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IExlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4gW21haWx0 bzo8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgSnVseSAwNCwgMjAxNiA1OjA3IEFNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGVzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxl YXNlIHNlZSBpbmxpbmUgW0JydW5vM108L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExlcyBHaW5zYmVyZw0KIChnaW5zYmVyZykg WzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86Z2luc2JlcmdAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1 bHkgMDEsIDIwMTYgMzozNiBBTTxicj4NCjxiPlRvOjwvYj4gREVDUkFFTkUgQnJ1bm8gSU1UL09M Tjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGRy YWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb248L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnJ1bm8g4oCTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SW5saW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4NCjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9i bGFuayI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzpicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDMw LCAyMDE2IDU6MTAgQU08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpPGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQt aWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkhpIExlcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbi4gUGxlYXNlIHNlZSBpbmxpbmUgW0Jy dW5vXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBMZXMgR2luc2JlcmcNCiAoZ2luc2JlcmcpIFs8YSBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDY6MTkgUE08YnI+DQo8 Yj5Ubzo8L2I+IERFQ1JBRU5FIEJydW5vIElNVC9PTE48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1y ZXNvbHV0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJy dW5vIOKAkzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0 bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SnVuZSAyOSwgMjAxNiA3OjIyIEFNPGJyPg0KPGI+VG86PC9iPiBMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb248L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5IaSBMZXMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPklJTk0sIEnigJl2ZSBub3Qgc2VlbiB0aGUgZm9sbG93IHVwIG9uIG9u ZSBvZiBteSBiZWxvdyBxdWVzdGlvbnMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyBsZXQgbWUgcmVz dGF0ZSBhIGNvbW1lbnQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhlIFNSLU1QTFMgU0lEIGNvbmZsaWN0cyBhbGdvIHJlcXVpcmVzIHRoYXQgYWxsIG5vZGVzIGNv bnNpZGVyIHRoZSBzYW1lIG1hcHBpbmcgYWR2ZXJ0aXNlbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SG93IGlzIHRoaXMgZW5zdXJlZCwgaWYgaXQgaW5kaWZmZXJlbnRseSBjb25zaWRlcnMgYWR2ZXJ0 aXNlbWVudHMgZnJvbSBhbGwgcHJvdG9jb2xzLCB3aGlsZSBzb21lIG5vZGVzIGNvdWxkIHBhcnRp Y2lwYXRlIG9ubHkgaW4gYSBzdWJzZXQgb2YgdGhlIHByb3RvY29scz8NCiBlLmcuIE9TUEYgb25s eSByb3V0ZXJzIHdvdWxkIGNvbnNpZGVyIGEgZGlmZmVyZW50IHNldCBvZiBpbmZvcm1hdGlvbiBj b21wYXJlZCB0byBPU1BGJiM0MztJUy1JUyByb3V0ZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMZXM6XSBJZiB5b3UgcnVuIG11bHRpcGxlIHByb3Rv Y29sIGluc3RhbmNlcyAod2hldGhlciBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgcHJv dG9jb2wgb3IgaW5zdGFuY2VzIG9mIGRpZmZlcmVudCBwcm90b2NvbHMpIHRoZW4geW91IG5lZWQN CiB0byBpbnN1cmUgdGhhdCBhdCBsZWFzdCBvbmUgb2YgdGhlIHR3byBjb25kaXRpb25zIGJlbG93 IGlzIHRydWU6PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkFsbCByb3V0ZXJzIHJlY2VpdmUgdGhlIGVxdWl2YWxlbnQgc2V0IG9mIGFkdmVydGlzZW1lbnRz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJv bDtjb2xvcjojMUY0OTdEIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGVyZSBhcmUgbm8gY29u ZmxpY3RzIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPko8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5bQnJ1bm9d IElPVywgdGhlIGRyYWZ0IGRvZXMgbm90IHJlc29sdmUgU0lEIGNvbmZsaWN0IGlmIGFsbCByb3V0 ZXJzIGRvIG5vdCByZWNlaXZlIGV4YWN0bHkgdGhlIHNhbWUgc2V0IG9mIGFkdmVydGlzZW1lbnQg ZnJvbSBhbGwgcm91dGluZyBwcm90b2NvbHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+VGhhdOKAmXMgaW5k ZWVkIGNhbiBiZSBhIHZhbGlkIHNpbXBsaWZpY2F0aW9uIGlmIHRoZSBXRyBjaG9vc2UgdG8sIGJ1 dCB0aGlzIHNob3VsZCBjbGVhcmx5IGJlIGluZGljYXRlZCBpbiB0aGUgZG9jdW1lbnQsIGluIGEg c2VjdGlvbiB0YXJnZXRpbmcgbmV0d29yaw0KIG9wZXJhdG9yIHNpbmNlIHRoaXMgcG9pbnQgd2ls bCBuZWVkIHRvIGJlIHJlYWQgYW5kIGVuZm9yY2VkIGJ5IG5ldHdvcmsgb3BlcmF0b3IgcmF0aGVy IHRoYW4gcHJvdG9jb2wgaW1wbGVtZW50b3JzLiDCpzMuMi44IGFscmVhZHkgcGFydGx5IGFkZHJl c3MgdGhpcywgYnV0IElNTyBhIHRleHQgY2xlYXJseSBleHByZXNzaW5nIHRoZSByZXF1aXJlbWVu dHMgb24gbmV0d29yayBvcGVyYXRvciB3b3VsZCBiZSB1c2VmdWwuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 aT48c3BhbiBzdHlsZT0iY29sb3I6I0MwMDAwMCI+W0xlczI6XSBObyBwb2xpY3kgY2FuIGd1YXJh bnRlZSBjb25zaXN0ZW50IHJlc3VsdHMgbmV0d29yayB3aWRlIGlmIHRoZSBkYXRhYmFzZXMgb24g ZGlmZmVyZW50IG5vZGVzIGFyZSBpbmNvbnNpc3RlbnQuIFRoaXMgaXNu4oCZdCBhIOKAnHNpbXBs aWZpY2F0aW9u4oCdDQog4oCTIGl0IGlzIGEgZmFjdC4gQXMgeW91IHBvaW50IG91dCwgU2VjdGlv biAzLjIuOCBhbHJlYWR5IHN0YXRlczo8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZu YnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjE1Ljc1cHQiPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAi PuKAnEluIG9yZGVyIHRvIG9idGFpbiBjb25zaXN0ZW50IGFjdGl2ZSBlbnRyaWVzIGFsbCBub2Rl cyBpbiBhIG5ldHdvcms8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZuYnNwOyZuYnNw OyBNVVNUIGhhdmUgdGhlIHNhbWUgbWFwcGluZyBlbnRyeSBkYXRhYmFzZS7igJ08L3NwYW4+PC9p PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6I0MwMDAwMCI+ SWYgeW91IGJlbGlldmUgdGhpcyBpcyBub3QgZXhwbGljaXQgZW5vdWdoIHBsZWFzZSBzdWdnZXN0 IHNvbWUgdGV4dC48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVubzNdDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5TZWN0aW9uIDQgTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9uczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkRldGVjdGluZyBhbmQgcmVzb2x2aW5nIGNvbmZsaWN0cyBpbiBhIGNvbnNp c3RlbnQgd2F5IHJlcXVpcmVzIHRoYXQgYWxsIG5vZGVzIGNvbnNpZGVyIHRoZSBzYW1lIHNldCBv ZiBTSURzIGFkdmVydGlzZW1lbnRzLiBOZXR3b3JrIG9wZXJhdGlvbnMgc2hvdWxkDQogYmUgYXdh cmUgdGhhdCB0aGUgY29uZmxpY3QgcmVzb2x1dGlvbiBhbGdvcml0aG0gZGVmaW5lZCBpbiB0aGlz IGRvY3VtZW50IHdpbGwgbm90IHN1Y2NlZWQgaW4gc2VsZWN0aW5nIGEgY29uc2lzdGVudCByZXNv bHV0aW9uIGFjcm9zcyBhbGwgbm9kZXMsIGlmIGFsbCBub2RlcyBkbyBub3QgcmVjZWl2ZSB0aGUg ZXhhY3Qgc2FtZSBzZXQgb2YgU0lEcyBhZHZlcnRpc2VtZW50cy4gVGhpcyBtYXkgYmUgaW4gcGFy dGljdWxhciB0aGUgY2FzZSB3aGVuDQogbXVsdGlwbGUgSUdQIGluc3RhbmNlcyBhcmUgdXNlZCBh bmQgYWxsIHJvdXRlcnMgZG8gbm90IHBhcnRpY2lwYXRlIGluIHRoZSBzYW1lIHNldCBvZiBJR1Ag aW5zdGFuY2VzLiBUaGlzIG1heSBvY2N1cnMgZm9yIGV4YW1wbGUgaWYgb25lIG5ldHdvcmsgdHJh bnNpdGlvbiBmcm9tIG9uZSBJR1AgcHJvdG9jb2wgdG8gYW5vdGhlciBJR1AgKGUuZy4gZnJvbSBP U1BGdjIgdG8gSVMtSVMpLiBUaGlzIG1heSBhbHNvIGhhcHBlbiBpZiBJR1AgYXJlYXMvbGV2ZWwN CiBhcmUgdXNlZCBhbmQgU0lEcyBhcmUgbm90IGZsb29kZWQgaW4gYWxsIGFyZWFzL2xldmVscy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5PbmUgd2F5IG9mIGluc3VyaW5nIHRoZSBmaXJzdCBwb2ludCBpcyB0byBleGNs dXNpdmVseSB1c2UgYSBtYXBwaW5nIHNlcnZlciB0byBhZHZlcnRpc2UgU0lEcywgY29uZmlndXJl IHlvdXIgU1JNUyBlbnRyaWVzIGluIGEgcHJvdG9jb2wgaW5kZXBlbmRlbnQNCiBtYW5uZXIsIGFu ZCBpbnN1cmUgdGhhdCB0aGUgU1JNUyBhZHZlcnRpc2VtZW50cyBhcmUgc2VudCBpbiBhbGwgb2Yg dGhlIHByb3RvY29sIGluc3RhbmNlIHNwZWNpZmljIHN1Yi1kb21haW5zLjwvc3Bhbj48L2I+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODA2NEEyIj5bQnJ1bm9dIElPVywgZG9u4oCZdCBtYWtlIGNvbmZpZ3VyYXRpb24gZXJyb3JzIDst KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4MDY0QTIiPkFyZSB5b3UgaW1wbHlpbmcgdGhhdCB0aGUgU1JNUyBjb25maWd1 cmF0aW9uIChoZW5jZSB5YW5nIG1vZGVsKSBzaG91bGQgYmUgcGVyIG5vZGUgcmF0aGVyIHRoYW4g cGVyIHByb3RvY29sPyBvciBhdCBsZWFzdCBzaG91bGQgYmUgY29uZmlndXJhYmxlIGJ5IG5vZGUN CiAoYW5kIHBvc3NpYmx5IGFsc28gYnkgcHJvdG9jb2xzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojQzAwMDAwIj5bTGVzMjpdIE15IHBvaW50IGlzIChodW1v cm91cyBpZGVhcyBhc2lkZeKApikgdGhhdCBpZiBhIGRlcGxveW1lbnQgdXNlcyBtdWx0aXBsZSBw cm90b2NvbHMsIHRoZSBlYXNpZXN0IHdheSB0byBndWFyYW50ZWUgdGhhdCB0aGUgU0lEIG1hcHBp bmcgZGF0YWJhc2UNCiBvbiBhbGwgbm9kZXMgaW4gdGhlIG5ldHdvcmsgaXMgY29uc2lzdGVudCBp cyB0byByZXN0cmljdCBTSUQgYWR2ZXJ0aXNlbWVudHMgdG8gU1JNUyBhZHZlcnRpc2VtZW50cy48 L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVubzNdIENsZWFybHksIHRoZSBmZXdlciB0aGUg bnVtYmVyIG9mIGFkdmVydGlzZW1lbnRzIGZvciBhIGdpdmVuIHByZWZpeCwgdGhlIGxlc3MgY2hh bmdlIG9mIGNvbmZsaWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCBJIGZhaWwgdG8gc2VlIHdoeSBv bmx5IHVzaW5nIFNSTVMgZ3VhcmFudGVlIGFueXRoaW5nLiBlLmcuIGlmIGRpZmZlcmVudCBub2Rl cyB1c2UgYSBkaWZmZXJlbnQgc2V0IG9mIHJvdXRpbmcgcHJvdG9jb2xzLCB5b3UgaGF2ZSBjb25m bGljdHMuIElkZW0NCiBpZiB0aGUgbWlzY29uZmlndXJhdGlvbiBjb25zaXN0IGluIGFkZGluZyBh IFNJRCB0byBhIElHUCBwcmVmaXggKFBGWCBhZHZlcnRpc2VtZW50KTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6I0MwMDAwMCI+QSBzbWFsbCBudW1iZXIgb2Ygbm9kZXMgKGFzIGZldyBhcyAxIOKAkyBtb3Jl IGlmIHJlZHVuZGFuY3kgaXMgZGVzaXJlZCkgYXJlIHNldHVwIGFzIG1hcHBpbmcgc2VydmVycyBh bmQgYWxsIFNJRHMgd2hpY2ggYXJlIHJlcXVpcmVkIG5ldHdvcmstd2lkZQ0KIGFyZSBjb25maWd1 cmVkIG9uIHRoZXNlIG5vZGVzIGFuZCBhZHZlcnRpc2VkIGJ5IHRoZSBwcm90b2NvbCBpbnN0YW5j ZShzKSBvbiB0aGF0IG5vZGUuIEluIHRoaXMgd2F5IGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gZ3Vh cmFudGVlIHRoYXQgYWxsIHByZWZpeCByZWFjaGFiaWxpdHkgZnJvbSBhbGwgb2YgdGhlIHByb3Rv Y29sIGluc3RhbmNlcyBydW5uaW5nIGluIHRoZSBuZXR3b3JrIGFyZSBwcmVzZW50IGluIGFsbCB0 aGUgcHJvdG9jb2wgaW5zdGFuY2UNCiBzdWItZG9tYWlucyB3aGljaCBleGlzdCDigJMgaXQgaXMg b25seSBuZWNlc3NhcnkgdG8gaW5zdXJlIHRoYXQgYWxsIHByb3RvY29sIGluc3RhbmNlcyBhZHZl cnRpc2UgdGhlIHNhbWUgc2V0IG9mIFNSTVMgZW50cmllcy48L3NwYW4+PC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPltCcnVubzNdIEluIHRoZSBlbmQsIHRoaXMgZ2V0cyBiYWNrIHRvIHJlcXVpcmluZyBubyBj b25maWd1cmF0aW9uIG1pc3Rha2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPkl0IGlzbuKAmXQg dGhlIG9ubHkgd2F5IHRvIHN1cHBvcnQgdGhpcyDigJMgYnV0IGl0IGlzIGxpa2VseSB0byBiZSB0 aGUgc2ltcGxlc3QgYW5kIGxlYXN0IGVycm9yIHByb25lLiBJbiBhbnkgY2FzZSB0aGlzIGlzbuKA mXQgYSByZXF1aXJlbWVudCDigJMgaXQgd2FzDQogYSByZXNwb25zZSB0byB5b3VyIHF1ZXN0aW9u IGFzIHRvIGhvdyBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBnZXQgY29uc2lzdGVudCBTSUQgbWFw cGluZyBkYXRhYmFzZXMgb24gYWxsIG5vZGVzIGluIHN1Y2ggYSBjYXNlLiBUaGlzIGlzIG5vIHdh eSBjaGFuZ2VzIGhvdyB0aGUgWUFORyBtb2RlbCBpcyBkZWZpbmVkLiBTUk1TIGNvbmZpZyBpcyBh bHdheXMgbm9kZSBzcGVjaWZpYy48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPklmIHRoZSBpbnRlbnQgaXMgdG8gZGVsaWJlcmF0ZWx5IHVzZSBkaWZmZXJlbnQgbGFiZWxz IGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIGZvciB0aGUgc2FtZSBkZXN0aW5hdGlvbiBkZXBlbmRp bmcgdXBvbiB3aGljaCBwcm90b2NvbCBhZHZlcnRpc2VkIHRoZQ0KIHByZWZpeCwgdGhpcyBpbnRy b2R1Y2VzIGEgbnVtYmVyIG9mIG5ldyByZXF1aXJlbWVudHMg4oCTIG5vdCB0aGUgbGVhc3Qgb2Yg d2hpY2ggaXMgZHVwbGljYXRlIGVudHJpZXMgZm9yIHRoZSBzYW1lIHByZWZpeCBpbiB0aGUgZm9y d2FyZGluZyBwbGFuZS4mbmJzcDsgQXMgaGFzIGJlZW4gZGlzY3Vzc2VkIHB1YmxpY2x5IGluIGEg ZGlmZmVyZW50IHRocmVhZCwgdGhlcmUgYXJlIGNhc2VzIChlLmcuIG1lcmdpbmcgdHdvIG5ldHdv cmtzKSB3ZXJlIHN1Y2ggYSByZXF1aXJlbWVudA0KIG1heSBleGlzdCDigJMgYnV0IGl0IGlzIHRo ZSBleGNlcHRpb24gcmF0aGVyIHRoYW4gdGhlIHJ1bGUgYW5kIGFzIGl0IGNvbnN1bWVzIG1vcmUg cmVzb3VyY2VzIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIGFuZCBpbnRyb2R1Y2VzIGltcGxlbWVu dGF0aW9uIGNvbXBsZXhpdHkgaW5kZXBlbmRlbnQgb2YgY29uZmxpY3QgcmVzb2x1dGlvbiBpdCBp cyBub3QgdGhlIHByaW1hcnkgY2FzZSB0aGUgZHJhZnQgZm9jdXNlcyBvbi4gTmV2ZXJ0aGVsZXNz LCB0aGlzDQogaXMgYSBjYXNlIHdoaWNoIHRoZSBkcmFmdCB3aWxsIGFkZHJlc3MgaW4gdGhlIG5l eHQgcmV2aXNpb24uPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub11UaGVyZSBpcyBhbHNvIHRo ZSBwb2ludCBvZiBjb25maWd1cmluZyBkaWZmZXJlbnQgU1JHQiBzcGFjZSBpbiBkaWZmZXJlbnQg SUdQIHByb3RvY29scy4gSW4gd2hpY2ggY2FzZSwgU0lEcyBtYXkgY29uZmxpY3QgYnV0IHRoaXMg aXMgbm90IGFuIGlzc3VlDQogYXMgbGFiZWwgd2lsbCBub3QgY29uZmxpY3QuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+V2Ugc3RvcHBlZCBzaG9ydCBvZiB0aGF0IGluIHRoaXMgcmV2aXNpb24gYmVjYXVz ZSB3ZSBmZWx0IHRoZXJlIHdlcmUgZW5vdWdoIHN1YnN0YW50aXZlIGNoYW5nZXMgYW5kIHBvaW50 cyBvbiB3aGljaCBjb25zZW5zdXMgaXMgc3RpbGwgYSB3b3JrIGluIHByb2dyZXNzDQogdGhhdCBp dCB3b3VsZCBub3QgYmUgdGhlIG9wdGltYWwgd2F5IGZvcndhcmQuPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0 QTIiPltCcnVub10gJiM0MzsxIGFuZCB0aGFua3MuIFJlbGVhc2luZyBhbiB1cGRhdGVkIHZlcnNp b24gaGFzIGJlZW4gdXNlZnVsIHRvIHJlLWluaXRpYXRlIHRoZSBkaXNjdXNzaW9uLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoaW5raW5nIG1vcmUgYWJvdXQgdGhp cywgSSBndWVzcyB0aGF0IHRoaXMgaXMgb25seSBpbXBvcnRhbnQgZm9yIHRoZSBlbnRyaWVzIHdo aWNoIGFyZSBpbnNlcnRlZCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gSGVuY2UsIGluIGNhc2Ug b2YgY29uZmxpY3QNCiBiZXR3ZWVuIHByb3RvY29scywgSSB0aGluayB0aGF0IHRoZSBwcmVmZXJl bmNlIGFsZ29yaXRobSBzaG91bGQgdGFrZSBpbnRvIGFjY291bnQgdGhlIHByb3RvY29sIHByZWZl cmVuY2UgKGFrYSBhZG1pbmlzdHJhdGl2ZSBkaXN0YW5jZSkuDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxp PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bTGVzOl0gQXMgYWRtaW4gZGlzdGFuY2UgaXMg bmVpdGhlciBhbiBhdHRyaWJ1dGUgb2YgU1JNUyBlbnRyaWVzIG5vciBndWFyYW50ZWVkIHRvIGJl IGNvbnNpc3RlbnQgb24gYWxsIHJvdXRlcnMgZm9yIGFsbCBwcmVmaXhlcyB0aGlzIGlzIG5vdCBh DQogZGVzaXJhYmxlIGFwcHJvYWNoLiA8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub10g V2VsbCwgdGhlIHNvbWUgcHJlZml4L3JvdXRpbmcgY29uc2lzdGVuY3kgaXMgYWxzbyByZXF1aXJl ZCBmb3IgSVAgcHJlZml4ZXMuIFdoZW4gdGhlbiBzYW1lIElQIHByZWZpeCBpcyBhZHZlcnRpc2Vk IGluIGRpZmZlcmVudCBJR1BzLCBhZG1pbiBkaXN0YW5jZQ0KIGlzIGEgY29tbW9uIGV4aXN0aW5n IHdheSB0byBkZWZpbmUgd2hpY2ggcm91dGluZyBwcm90b2NvbCB0YWtlcyBwcmVjZWRlbmNlLiBJ 4oCZbSBub3Qgc3VyZSB3aHkgaXQgc2hvdWxkIG5vdCBhbHNvIGJlIHRha2VuIGludG8gY29uc2lk ZXJhdGlvbiBmb3IgU1IgUHJlZml4IGNvbmZsaXRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBz dHlsZT0iY29sb3I6I0MwMDAwMCI+W0xlczI6XSBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIHRvIFN0 ZXBoYW5lIG9uIHRoZSBzYW1lIHBvaW50Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SeKAmW0gYWxzbyBub3Qgc3VyZSB0byBzZWUgd2h5IGlzIHRoZSBw cm9ibGVtIGRpZmZlcmVudCBjb21wYXJlZCB0byBNdWx0aS1Ub3BvbG9neS4gQ291bGQgeW91IHBs ZWFzZSBlbGFib3JhdGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0xlczpdIEkgYW0gdW5jbGVh ciB3aGF0IHlvdXIgcXVlc3Rpb24gaXMuIEFyZSB5b3UgYXNraW5nIHdoeSB3ZSBuZWVkIGRpZmZl cmVudCBTSURzIGluIGRpZmZlcmVudCB0b3BvbG9naWVzPyBQbGVhc2UgY2xhcmlmeS48L3NwYW4+ PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub10gUXVlc3Rpb24gd2FzIHRoYXQsIGF0IGEgdmVyeS90 b28gaGlnaCBsZXZlbCwgdGhlIGlzc3VlIG9mIGNvbmZsaWN0IGFjcm9zcyB0b3BvbG9neSBzZWVt cyBjbG9zZSB0byB0aGUgaXNzdWUgb2YgY29uZmxpY3QgYWNyb3NzIHJvdXRpbmcgcHJvdG9jb2xz Og0KICZuYnNwO3dlIGhhdmUgZGlmZmVyZW50IHRvcG9sb2dpZXMuIEhlbmNlIGEgbmHDr3ZlIHF1 ZXN0aW9uOiBob3cgZXhhY3RseSBpcyB0aGlzIGRpZmZlcmVudC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5P bmUgcGFydCBvZiB0aGUgYW5zd2VyLCBpcyB0aGUgc2ltcGxpZmljYXRpb24gcHJvcG9zZWQgd2hl biBtdWx0aXBsZSBwcm90b2NvbHMgaXMgdXNlZCAoaS5lLiB5b3VyIGZpcnN0IGFuc3dlciBhYm92 ZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzgwNjRBMiI+QW5vdGhlciBwYXJ0IGlzIHRoYXQgZm9yIG11bHRpLXRvcG9s b2d5LCBjb21wYXJlZCB0byBtdWx0aS1wcm90b2NvbHMsIGFsbCBpbmZvcm1hdGlvbiBmcm9tIGFs bCB0b3BvbG9naWVzIGFyZSBmbG9vZGVkIHRvIGFsbCBub2Rlcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5B bm90aGVyIHBhcnQgaXMgdGhlIGZvcndhcmRpbmcgbW9kZWwgdXNlZCBmb3IgTXVsdGktVG9wb2xv Z3kuIEluIGdlbmVyYWwsDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTEyMCNzZWN0aW9uLTgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTEyMCNzZWN0aW9uLTg8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+c2VlbXMgdG8gYXNzdW1lIHRo YXQgZWFjaCB0b3BvbG9neSBoYXMgb25lIGRlZGljYXRlZCBSSUIvRklCLiBJbiBzdWNoIGNvbmRp dGlvbiwgdGhlcmUgaXMgbm8gY29uZmxpY3QgKHByZWZpeCBvciBTSUQpIHNvIG5vIG5lZWQgdG8g ZGV0ZWN0IGFuZCByZXNvbHZlIGNvbmZsaWN0LiBTbyBoZXJlIHRoZXJlIG1heSBiZSBkaWZmZXJl bnQgbW9kZWxzIGFuZCBldmVudHVhbGx5LCB3ZSBkb27igJl0DQog4oCYaGF2ZSB0aGUgc2FtZSBv bmUgaW4gbWluZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5JbiBhIGxlc3NlciBleHRlbmQsIGV2ZW4gZm9y IG11bHRpLXByb3RvY29scywgd2UgbWF5IGhhdmUgdGhvc2UgbXVsdGlwbGUgZm9yd2FyZGluZyBt b2RlbHMuIFRvIHNvbWUgZXh0ZW50LCB0aGlzIHNlZW1zIHJlbGF0ZWQgdG8gdGhlIGRlZmluaXRp b24gb2Yg4oCcU1INCiBkb21haW7igJ0uIGUuZy4gaWYgd2UgaGF2ZSAyIElHUHMsIGRvIHdlIGhh dmUgMSBvciAyIFNSIGRvbWFpbnM/IE1heSBiZSB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IG5lZWRz IHRvIGJlIGNvbmZpZ3VyYWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6I0MwMDAwMCI+W0xlczI6XSBQ bGVhc2UgcmVyZWFkIFNlY3Rpb24gMy4xLjIuIFdoaWxlIHRoZXJlIGFyZSBubyDigJxQcmVmaXgt Y29uZmxpY3Rz4oCdIGFjcm9zcyB0b3BvbG9naWVzLCB0aGVyZSBhcmUg4oCcU0lEIENvbmZsaWN0 c+KAnS4gVGhpcyBpcyBpbXBvcnRhbnQgdG8gdW5kZXJzdGFuZC48L3NwYW4+PC9pPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPltCcnVubzNdIENvbmZsaWN0cyBhcmUgcmVsYXRlZCB0byBhIGZvcndhcmRpbmcgY29u dGV4dCBpLmUuIEZJQi4gVGhpcyBpcyBlcXVhbGx5IGltcG9ydGFudCB0byB1bmRlcnN0YW5kLiBQ bGVhc2UgcmVhZA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj48YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTEyMCNzZWN0aW9uLTguMi4yIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUxMjAjc2VjdGlvbi04LjIu MjwvYT4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+YW5kIDguMi4xIHRvIHNl ZSB0aGF0IHRvcG9sb2dpZXMgbWF5IG5vdCBzaGFyZSB0aGUgc2FtZSBmb3J3YXJkaW5nIGNvbnRl eHQgaGVuY2UgZG8gbm90IGNvbmZsaWN0IGluIHRlcm0gb2YgcHJlZml4ICZhbXA7IFNJRC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4tLUJydW5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojQzAwMDAwIj5BcyByZWdhcmRzIG11bHRpcGxlIHByb3RvY29scyBv cGVyYXRpbmcgaW4gdGhlIHNhbWUgdG9wb2xvZ3ksIGZyb20gYSBmb3J3YXJkaW5nIHBlcnNwZWN0 aXZlIHdlIGRvIG5vdCBjYXJlIHdoYXQgcHJvdG9jb2wgaXMgdGhlIHdpbm5pbmcgcm91dGUuDQog V2hhdCB3ZSBjYXJlIGFib3V0IGlzIHRoYXQgb3VyIG5leHRob3AgaGFzIGNob3NlbiB0aGUgc2Ft ZSBTSUQgZm9yIGEgZ2l2ZW4gcHJlZml4LiBUaGlzIGlzIHdoeSDigJxzb3VyY2XigJ0gaXMgZGVs aWJlcmF0ZWx5IGV4Y2x1ZGVkIGZyb20gY29uc2lkZXJhdGlvbiBieSB0aGUgY29uZmxpY3QgcmVz b2x1dGlvbiBhbGdvcml0aG0uPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojQzAwMDAwIj4mbmJzcDs8 L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZuYnNwOyZuYnNwOyZuYnNwOyBMZXM8L3Nw YW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlczwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkJydW5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHNwcmluZw0KIFs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208 L2E+PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDE4LCAyMDE2IDE6NTcgUE08YnI+ DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOyA8YSBocmVmPSJtYWlsdG86c3By aW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1y ZXNvbHV0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxl cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlv dXIgcmVwbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBpbmxpbmUgW0JydW5vXTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgWzxh IGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 Z2luc2JlcmdAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWF5 IDE0LCAyMDE2IDg6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IERFQ1JBRU5FIEJydW5vIElNVC9PTE47 IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNwcmlu Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGRyYWZ0LWlldGYtc3ByaW5n LWNvbmZsaWN0LXJlc29sdXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJydW5vIOKAkzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklubGluZS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNwcmluZyBbPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48YSBo cmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzpzcHJpbmctYm91bmNl c0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0ibWFp bHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208 L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBNYXkgMTIsIDIwMTYgODoyMyBBTTxicj4NCjxiPlRvOjwvYj4gPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zcHJp bmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBhbiBpbmRpdmlkdWFsIGNv bnRyaWJ1dG9yLCBwbGVhc2UgZmluZCBiZWxvdyBzb21lIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SXNu4oCZdCB0aGlzIGRvY3VtZW50IHNwZWNpZmljIHRvIHRoZSBNUExTIGRhdGFwbGFuZT88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgc28sIGl0IGNvdWxkIGJlIGlu ZGljYXRlZCBpbiB0aGUgaW50cm9kdWN0aW9uLCBhbmQgcG9zc2libHkgaW4gdGhlIGFic3RyYWN0 LiBUaGVuIHRoaXMgaW5kaWNhdGlvbiBjb3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIDFyc3Qgc2Vu dGVuY2Ugb2Ygc2VjdGlvbnMgMiAmYW1wOyAzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+W0xlczpdIEN1cnJlbnRseSBhbGwgZGlzY3Vzc2lvbiBpcyByZWdhcmRpbmcg U1ItTVBMUy4gVGhlIGRyYWZ0IGxlYXZlcyBvcGVuIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGlmIHRo ZXJlIGlzIHNvbWUgU1J2NiBjb25mbGljdCByZXNvbHV0aW9uIHRoYXQNCiBuZWVkcyB0byBiZSBz cGVjaWZpZWQgaXQgY291bGQgYmUgYWRkZWQgaW50byB0aGlzIGRvY3VtZW50IOKAkyB3aGljaCBp cyB3aHkgdGhlIEludHJvZHVjdGlvbiBpcyBkYXRhcGxhbmUgYWdub3N0aWMsIGJ1dCBlYWNoIHNl Y3Rpb24gc3RhdGVzIHNwZWNpZmljYWxseSB0aGF0IGl0IGlzIHJlbGV2YW50IHRvIFNSLU1QTFMu PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBTUnY2IGNvbmZsaWN0IHJlc29sdXRp b24gdGhhdCBpcyByZXF1aXJlZCBhdCB0aGlzIHBvaW50LCBidXQgSSBwcmVmZXIgdG8gbGVhdmUg dGhlIHBvc3NpYmlsaXR5IG9wZW4gaWYgdGhhdCBpcyBPSyB3aXRoIHlvdS48L3NwYW4+PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPltCcnVub10gb2ssIGdyZWF0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+wqczPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij7igJxNYXBwaW5nIGVudHJpZXMgaGF2ZSBhbiBleHBsaWNpdCBjb250ZXh0IHdoaWNoIGluY2x1 ZGVzIHRoZSB0b3BvbG9neSBhbmQgdGhlIFNSIGFsZ29yaXRobS7igJw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BIHByaW9yaSB5b3UgY291 bGQgYWRkIOKAnHRoZSByb3V0aW5nIHByb3RvY29s4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+W0xlczpdIE5vIOKAkyB0aGUgc291cmNlIG9mIGFkdmVydGlz ZW1lbnRzIGlzIGRlbGliZXJhdGVseSBsZWZ0IG91dC4gSXQgbWF0dGVycyBub3Qgd2hldGhlciB0 aGUgc291cmNlIG9mIHRoZSBhZHZlcnRpc2VtZW50IGlzIGEgcHJvdG9jb2wgb3IgYW4gU1JNUw0K IOKAkyBub3IgZG9lcyBpdCBtYXR0ZXIgd2hpY2ggcHJvdG9jb2wgcHJvdmlkZXMgdGhlIGFkdmVy dGlzZW1lbnQuIFlvdSBzZWUgdGhhdCDigJxhZG1pbiBkaXN0YW5jZeKAnSBpcyBub3QgbWVudGlv bmVkIGF0IGFsbCBhbmQgdGhhdCBpcyBxdWl0ZSBkZWxpYmVyYXRlLiBUaGlzIGluc3VyZXMgdGhh dCBjb25zaXN0ZW50IGNob2ljZXMgYXJlIG1hZGUgb24gbm9kZXMgcmVnYXJkbGVzcyBvZiB3aGlj aCBwcm90b2NvbCBtaWdodCBoYXZlIHRoZSBiZXN0IHJvdXRlDQogb24gYSBnaXZlbiBub2RlLjwv c3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0JydW5vXSBXZWxsLCB0aGUgZmFjdCBpcyB0aGF0IG1h cHBpbmcgZW50cmllcyBkbyBoYXZlLCBhcyBleHBsaWNpdCBjb250ZXh0LCB0aGUgcm91dGluZyBw cm90b2NvbCB1c2VkIHRvIGFkdmVydGlzZSB0aGVtLiBBZnRlciwgeW91IGNhbiBzaG91bGQgdG8g dXNlDQogdGhhdCBpbmZvcm1hdGlvbiwgb3Igbm90Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj7CpzM8bzpwPjwvbzpwPjwvcD4NCjxwcmU+4oCcV2hlbiBj b25mbGljdHMgb2NjdXIsIGl0IGlzIG5vdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBwb3NzaWJsZSBmb3Igcm91dGVycyB0byBrbm93IHdoaWNoIG9mIHRoZSBjb25mbGljdGlu ZyBhZHZlcnRpc2VtZW50czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpcyAm cXVvdDtjb3JyZWN0JnF1b3Q7LiZuYnNwOyBJZiBhIHJvdXRlciBjaG9vc2VzIHRvIHVzZSBvbmUg b2YgdGhlIGNvbmZsaWN0aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGVu dHJpZXMgZm9yd2FyZGluZyBsb29wcyBhbmQvb3IgYmxhY2tob2xlcyBtYXkgcmVzdWx0IHVubGVz cyBpdCBjYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYmUgZ3VhcmFudGVl ZCB0aGF0IGFsbCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3b3JrIG1ha2UgdGhlIHNhbWU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2hvaWNlLiZuYnNwOyBNYWtpbmcgdGhl IHNhbWUgY2hvaWNlIHJlcXVpcmVzIHRoYXQgYWxsIHJvdXRlcnMgaGF2ZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpZGVudGljYWwgc2V0cyBvZiBhZHZlcnRpc2VtZW50cyBh bmQgdGhhdCB0aGV5IGFsbCB1c2UgdGhlIHNhbWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgc2VsZWN0aW9uIGFsZ29yaXRobS4mbmJzcDvCuzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkgdGhpbmsgd2UgYWdyZWUgb24gdGhl IHRlY2huaWNhbCBwYXJ0LCBidXQgSSBmb3VuZCB0aGUgZm9ybXVsYXRpb24gc2xpZ2h0bHkgYmlh c2VkLiBJIHdvdWxkIHByb3Bvc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7igJxXaGVuIGNvbmZs aWN0cyBvY2N1ciwgaXQgaXMgbm90PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IHBvc3NpYmxlIGZvciByb3V0ZXJzIHRvIGtub3cgd2hpY2ggb2YgdGhlIGNvbmZsaWN0aW5nIGFk dmVydGlzZW1lbnRzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGlzICZxdW90 O2NvcnJlY3QmcXVvdDsuJm5ic3A7IEluIG9yZGVyIHRvIGF2b2lkIGZvcndhcmRpbmcgbG9vcHMg YW5kL29yIGJsYWNraG9sZXMsIHRoZXJlIGlzIGEgbmVlZCBmb3IgYWxsIG5vZGVzIHRvIG1ha2Ug dGhlIHNhbWUgY2hvaWNlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBNYWtpbmcgdGhl IHNhbWUgY2hvaWNlIHJlcXVpcmVzIHRoYXQgYWxsIHJvdXRlcnMgaGF2ZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpZGVudGljYWwgc2V0cyBvZiBhZHZlcnRpc2VtZW50cyBh bmQgdGhhdCB0aGV5IGFsbCB1c2UgdGhlIHNhbWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgc2VsZWN0aW9uIGFsZ29yaXRobS4gVGhpcyBpcyB0aGUgcHVycG9zZSBvZiB0aGlz IGRvY3VtZW50LiZuYnNwO8K7PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMZXM6XSBJIGFtIGZpbmUgd2l0aCB0aGlzIGNoYW5nZS48 L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVub10gVGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7CpzMu MTxvOnA+PC9vOnA+PC9wPg0KPHByZT7igJxWYXJpb3VzIHR5cGVzIG9mIGNvbmZsaWN0cyBtYXkg b2NjdXLigJ08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XaGF0IGFib3V0IDpzL1ZhcmlvdXMvVHdv PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMZXM6XSDigJxUd2/i gJ0gaXMgZmluZS4gSnVzdCBtZWFucyB3ZSB3aWxsIGhhdmUgdG8gY2hhbmdlIGl0IGlmIHdlIGNv bWUgdXAgd2l0aCBhIHRoaXJkIHR5cGUgb2YgY29uZmxpY3QuDQo8L3NwYW4+PC9pPjwvYj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3Nw YW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVub10gSW5kZWVkLCBidXQgaW4gdGhpcyBjYXNlIHRo ZSBjaGFuZ2UgbWF5IGJlIG11Y2ggbGFyZ2VyIChlLmcuIHRoZSB3aG9sZSBhbGdvKTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhZ3JlZSB3aXRoIFJvYmVydOKAmXMgJm5ic3A7YW5k IFVtYeKAmXMgY29tbWVudCB3aXRoIHJlZ2FyZHMgdG8gbWFraW5nIHRoaXMgY29uZmxpY3QgcmVz b2x1dGlvbiBhbiBpbnRlci0gcHJvdG9jb2wvcm91dGluZ190YWJsZSBpc3N1ZS4gSW4gcGFydGlj dWxhciwgYmV0d2VlbiBTUiBkb21haW5zLCB0aGVyZSBpcyBub3QNCiByZXF1aXJlbWVudCB0byBo YXZlIHVuaXF1ZSBTSURzLiBIZW5jZSBiZXR3ZWVuIFBFIGFuZCBDRSwgYmV0d2VlbiBBU2VzIChi b3RoIHdpdGhpbiBhbmQgYWNyb3NzIG9yZ2FuaXphdGlvbiksIHRoZSBzYW1lIFNJRCBjb3VsZCBi ZSByZXVzZWQgaW5kZXBlbmRlbnRseSkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPltMZXM6XSBUaGVyZSBpcyBtb3JlIHRvIGJlIHNhaWQgb24gdGhpcyB0b3BpYyDi gJMgY28tYXV0aG9ycyBhcmUgYWN0aXZlbHkgZGlzY3Vzc2luZyB0aGlzIHBvaW50IGFuZCB3ZeKA mWxsIHJlc3BvbmQgbW9yZSBmdWxseSB0byBSb2JlcnTigJlzIHBvc3QgaW4NCiB0aW1lLiBCdXQs IHRoZSBkcmFmdCBpcyBOT1QgdHJ5aW5nIHRvIGRlZmluZSBjb25mbGljdCByZXNvbHV0aW9uIGFj cm9zcyDigJxTUiBkb21haW5z4oCdLiBQZXJoYXBzIHdlIG5lZWQgbGFuZ3VhZ2UgdG8gbWFrZSB0 aGF0IG1vcmUgZXhwbGljaXQuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIG9rLiBS ZWdhcmRpbmcgaW50ZXItcHJvdG9jb2wsIGluIG9yZGVyIHRvIGhhdmUgY29uc2lzdGVuY3kgb2Yg dGhlIHByZWZpeC1TSUQgbWFwcGluZyBhY3Jvc3MgdGhlIGRvbWFpbiB3ZSBuZWVkOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMC41cHQi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmEpIGFsbCBub2RlcyB1c2UgdGhlIHNhbWUg YWxnbyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MTAuNXB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5iKSBhbGwgbm9kZXMg dXNpbmcgdGhpcyBhbGdvIGhhdmUgdGhlIHNhbWUgZGF0YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMC41cHQiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMC41cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPuKAnGHigJ0gcmVxdWlyZXMgdGhpcyBkcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMC41cHQiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPuKAnGLigJ0gcmVxdWlyZXMgdGhhdCBhbGwgbm9kZXMgaGF2ZSB0aGUgc2Ft ZSBzZXQgb2YgU1ImbmJzcDsgaW5mby4gVGhpcyBmb3JiaWQgdGhhdCBzb21lIG5vZGUgYXJlIGNv bnNpZGVyaW5nIElTLUlTICYjNDM7IE9TUEYgU1IgZGF0YSwgd2hpbGUgc29tZSBub2RlIGFyZSBv bmx5IGNvbnNpZGVyaW5nIElTLUlTIGRhdGEuIE90aGVyd2lzZSwgYWxsIElTLUlTIHJvdXRlcnMg d291bGQgbm90IHRha2UgdGhlIHNhbWUgZGVjaXNpb24uDQogU28sIHVubGVzcyB3ZSBjYW4gZ3Vh cmFudGVlIHRoYXQgdGhlIGZsb29kaW5nIGFyZWEgaXMgdGhlIHNhbWUgZm9yIElTLUlTIGFuZCBP U1BGLCB3ZSBjYW4ndCBoYXZlIHRoZSBhbGdvIHVzaW5nIHRoZSBTUiBkYXRhIGZyb20gbXVsdGlw bGUgcm91dGluZyBwcm90b2NvbHMuIEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBjYW4gZ3VhcmFudGVl IHRoaXMgKG5vciB0aGF0IGltcGxlbWVudGF0aW9uIHdpbGwgY2hlY2sgdGhpcykgZS5nLiB3aGVu IHNvbWUgbm9kZXMNCiBhcmUgcGFydCBvZiBtdWx0aXBsZSByb3V0aW5nIGRvbWFpbiBvciB3aGVu IGdyYWR1YWxseSB0cmFuc2l0aW9uaW5nIGZyb20gb25lIElHUCB0byBhbm90aGVyLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMC41cHQi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNv IGluIHNob3J0LCB0aGlzIFNSLWNvbmZsaWN0IGFsZ28gc2hvdWxkIHByb2JhYmx5IGJlIHJlc3Ry aWN0ZWQgdG8gU1IgaW5mb3JtYXRpb24gZnJvbSBhIHNpbmdsZSBwcm90b2NvbDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgRnJvbTogTGVz IEdpbnNiZXJnIChnaW5zYmVyZykgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0ibWFp bHRvOmdpbnNiZXJnQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+bWFpbHRvOmdpbnNiZXJnQGNpc2Nv LmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5dDQogJmd0OyBTZW50OiBTdW5kYXksIE1heSAwMSwgMjAxNiA3OjExIEFNPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZndDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldlIGFyZSBpbmRlZWQg ZGVmaW5pbmcgY29uZmxpY3QgcmVzb2x1dGlvbiBhY3Jvc3MgYWxsIHRoZSBTSUQgYWR2ZXJ0aXNl bWVudHMgcmVnYXJkbGVzcyBvZiBzb3VyY2UgKHByb3RvY29sIG9yIFNSTVMpPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZndDsgV2h5PyBCZWNhdXNlIHdlIG5lZWQgY29uc2lzdGVudCB1c2Ugb2YgU0lEcyBpbiB0 aGUgZm9yd2FyZGluZyBwbGFuZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5v OiBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSwgd2UgbmVlZCBhIGNvbnNpc3RlbnQgdXNlIG9mIE1Q TFMgbGFiZWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bTGVzOl0gQXMgeW91IGtub3csIFNSR0IgcmFuZ2Ug Y2FuIGJlIGRpZmZlcmVudCBmb3IgZGlmZmVyZW50IG5vZGVzLCBzbyB0aGUgYWN0dWFsIGxhYmVs IHRoYXQgaXMgdXNlZCB0byBzZW5kIGEgcGFja2V0IGZvciBhIGdpdmVuIGRlc3RpbmF0aW9uDQog dmlhIE5vZGUgQSBtYXkgYmUgZGlmZmVyZW50IHRoYW4gdGhlIGxhYmVsIHVzZWQgdG8gc2VuZCB0 aGUgc2FtZSBwYWNrZXQgdmlhIE5vZGUgQi4gSXQgaXMgdGhlIFNJRCB0aGF0IG5lZWRzIHRvIGJl IHRoZSBzYW1lIOKAkyBub3QgdGhlIGxhYmVsLg0KPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JdCBpcyB0cnVlIHRoYXQgU0lEcyBhcmUgbm90IGluc3RhbGxlZCBpbiB0aGUgZm9yd2Fy ZGluZyBwbGFuZSDigJMgdGhlIGxhYmVscyBkZXJpdmVkIGZyb20gdGhlIFNJRC9TUkdCIGFyZSB3 aGF0IGlzIGFjdHVhbGx5IGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZw0KIHBsYW5lIOKAkyBi dXQgSSB0aGluayBteSB1c2Ugb2YgdGhlIHdvcmQgU0lEIGluIHRoaXMgY29udGV4dCBpcyBjb3Jy ZWN0Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0JydW5vXSBNeSBwb2ludCB3YXMgdGhhdCB0 aGUgZm9ybXVsYXRpb24gYXNzdW1lcyB0aGF0IGEgc2luZ2xlIFNSR0IgaXMgdXNlZCBwZXIgbm9k ZXMuIEluIHdoaWNoIGNhc2UsIHdlIGhhdmUgYSBiaWplY3Rpb24gYmV0d2VlbiBTSUQgYW5kIGxh YmVscy4gQnV0DQogaWYgd2UgaGF2ZSBhIFNSR0IgcGVyIHByb3RvY29sLCB3ZSBkb27igJl0IGhh dmUgYSBiaWplY3Rpb24gYW55IG1vcmUgYW5kIHdlIGNhbiBoYXZlIHRoZSBzYW1lIFNJRCBpbiBJ Uy1JUyBhbmQgT1NQRiAoaW5jbHVkaW5nIGZvciBkaWZmZXJlbnQgcHJlZml4KSwgd2hpY2ggd2ls bCBiZSBtYXBwZWQgdG8gZGlmZmVyZW50IGxhYmVscyBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlBsdXMgb25seSB3aXRoaW4gYW4gU1IgZG9tYWluLiBBY3R1YWxseSwgZXZl biB3aXRoaW4gYSBkb21haW4sIHRoaXMgaXMgZGVwZW5kZW50IG9uIHdoZXRoZXIgU1JHQiBpcyBj b25maWd1cmVkIG9uIGEgcGVyIG5vZGUgb3IgYSBwZXIgcHJvdG9jb2wgYmFzaXMuIEnigJltIG5v dCBzdXJlIGhvdyBtdWNoIHRoZSBhZ3JlZW1lbnQNCiBoYXMgYmVlbiByZWFjaGVkIG9uIHRoYXQg b25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0xlczpdIFRoZSBk cmFmdCBjdXJyZW50bHkgYWRkcmVzc2VzIGRlcGxveW1lbnRzIHdoZXJlIGEgc2luZ2xlIChzZXQg b2YpIFNSR0IgcmFuZ2VzIGFwcGxpZXMgdG8gdGhlIGJveC4gVGhpcyBpcyBieSBmYXIgdGhlIG1v c3QgY29tbW9uIHVzZSBjYXNlLg0KIFRoZXJlIGlzIGEgbXVjaCBtb3JlIGxpbWl0ZWQgdXNlIGNh c2Ugd2hlcmUgcHJvdG9jb2wgc3BlY2lmaWMgU1JHQnMgYW5kIHByb3RvY29sIHNwZWNpZmljIFNJ RHMgbWF5IGJlIHJlcXVpcmVkLiBUaGUgZHJhZnQgd2lsbCBhZGRyZXNzIHRoYXQgaW4gYSBmdXR1 cmUgcmV2aXNpb248L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVub10gb2ssIG1heSBiZSB0 aGlzIHNob3VsZCBiZSBzdGF0ZWQgaW4gdGhlIGRyYWZ0LCBhcyBvdGhlcndpc2UgeW914oCZbGwg a2VlcCBnZXR0aW5nIGNvbW1lbnRzLCBvciB3ZSBtYXkgZm9yZ2V0IHRoaXMgcG9pbnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS1CcnVubzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPuKAkyBidXQgaW4gc3Bpcml0IHRoZSBzYW1lIHJ1bGVzIHdpbGwgYXBwbHkg4oCT IHRoZXkgd2lsbCBqdXN0IGhhdmUgdG8gdGFrZSBpbnRvIGFjY291bnQg4oCcZHVwbGljYXRlIGZv cndhcmRpbmcgZG9tYWluc+KAnS4gTm90ZSB0aGF0IHRoaXMgd2lsbCBhbHNvIHJlcXVpcmUNCiBt dWx0aXBsZSBpbmNvbWluZyBsYWJlbCBlbnRyaWVzL3ByZWZpeCBiZSBzdXBwb3J0ZWQgYnkgdGhl IHJvdXRlcnMgaW4gc3VjaCBhIG5ldHdvcmsuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlR5cG86PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPsKnMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVy Ij5PTEQmbmJzcDs6IFJhbmdlIDM6ICg1MDAsIDU5OTA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXIiPk5FVyZuYnNwOzogUmFuZ2UgMzogKDUwMCwgNTk5KTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb3VyaWVyIj4oc29tZXdoYXQgc2lnbmlmaWNhbnQgYXMgb3RoZXJ3aXNlIHJh bmdlIDMgY29uZmxpY3Qgd2l0aCByYW5nZSAyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPltMZXM6XSBBZ3JlZWQg4oCTIHRoYW54IGZvciBzcG90dGluZyB0 aGlzLjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGVzPC9zcGFuPjwvaT48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+QnJ1 bm88L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gPC9zcGFu Pk1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4N CjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS Ij5UaGFuayB5b3UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHBy ZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5h IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+T3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG UiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5rIHlvdS48L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5r IHlvdS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPjxzcGFu IGxhbmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFu ayB5b3UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_fd37aeb70f4940818f83b7f4d48abf68XCHALN001ciscocom_-- From nobody Tue Jul 5 10:24:25 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884DB12D128 for ; Tue, 5 Jul 2016 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYJENoDRSzPC for ; Tue, 5 Jul 2016 10:24:17 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0A112B060 for ; Tue, 5 Jul 2016 10:24:16 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id h129so139372714lfh.1 for ; Tue, 05 Jul 2016 10:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kXYcTP3R83P1NlaSYgs+YV7rZx5FEvYym/sunOD7+GI=; b=kW2z3ecg76IfLO28UTzXOwGsW/3l2tML6o91tFp8sJycnYYPRRS0iO27TbdNqme+Rf 0YlxsaNS96jRl++ZQkgTJvb9hGjkLUBXMVNeMHYx/zdr4fk8zOKHBZdb/zYOi91A16BJ 3EGgGZGZOruV++mD+1D94/v3fyin8gg0LO0/Yn1dR+iStn4WS0SWF310RX8JkzVnx0Qh EcWnmrF18YjYbZC2bxfSeObaBv76w/m7LfNP1zVWwVvYiQCdEEKM2gFvSYeYGpiFNAr/ F0ioWWWYLsWZsbkjXDJAA1qLBqkJIdoxojPxSvmYOd3KdoQHKk3/liGRAVwQrqKb7k0V YWHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kXYcTP3R83P1NlaSYgs+YV7rZx5FEvYym/sunOD7+GI=; b=JsAq5xQN2MRWU3tV7vEefNAle1R6YERVcwZDA86Tgkh3QGlxRwZZrh7j8aUQApSSai ere+ognkpbPoXpfQtkZVKmIR/YzGz6plsEbL8MUdtgKPzbf9H5xtk2sP33s83WYKRWeo ZqZxlx2gZO+vkx/+ENwfXh5mdplnDN1ae5cbyw5LnQ1xg9+wYOHyjx/0O+0jWgwTDoKM RP+6AhpCVdOzBcVyWBTuW1P1YiKd7b7HVxP5d546shPjAZb6+tB1bTOOvSje9uSugae+ gXFrDA9E01nE7n1/8dhN+m9SZIFvQhd4CirwmTwVg58OHug/Wjs+oOGy3HmVvIBjs6ye YiXA== X-Gm-Message-State: ALyK8tKSb5bHWGh+WhpjepDVF6O8Kovt1VqW8klp1iy2+aaCJCY8Y90VR1eyPgRCH46b5J4Alb+sFvGK6lcunw== X-Received: by 10.25.84.65 with SMTP id i62mr5381071lfb.88.1467739454107; Tue, 05 Jul 2016 10:24:14 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Tue, 5 Jul 2016 10:24:12 -0700 (PDT) In-Reply-To: References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> From: Robert Raszuk Date: Tue, 5 Jul 2016 19:24:12 +0200 X-Google-Sender-Auth: 0gUoa2VJlYd6MRDZevMcQOkLH78 Message-ID: To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=001a11411f28c8f4160536e6b8d0 Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 17:24:22 -0000 --001a11411f28c8f4160536e6b8d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Les, Use of context label for SR has been proposed 3 years back .. https://tools.ietf.org/html/draft-raszuk-mpls-domain-wide-labels-05 I keep the draft, but I am about to drop it if there is no further interest. It beats me that group of folks went with such protocol pollution recommending use of indexes where no one I spoke with looking at SR deployment is not planning to have any use for it. As you may have noticed use of indexes even complicates your draft :) - - - Speaking of which how are you going to decide on which algorithm is to be chosen in section 3.2 ? I have similar observation as Stephane that it is very confusing at this point to provide many different ways in the document which is going to go for RFC. It is clearly not going to be easy to see a "rough consensus" - that can be used to gather forum feedback to progress the doc or not .. but I think it will rather be hard to judge as far as algorithm selection. Or are you going to run doodle ? Cheers, Robert. On Tue, Jul 5, 2016 at 6:54 PM, Les Ginsberg (ginsberg) wrote: > Robert =E2=80=93 > > > > Use of RFC 5331 would require that we have a way to advertise the context > label associated with a prefix-SID advertisement (whether in prefix > reachability or SRMS). This capability does not currently exist. > > > > So I believe my answer is correct based on existing definition of SR-MPLS > support. > > > > I am also not aware that RFC 5331 has been proposed as a generic solution > to RFC 5120 style MT even outside of SR =E2=80=93 and likely for the same= reason =E2=80=93 > because there is no existing mechanism for advertising the context labels > associated with a prefix/MT pair. > > > > Les > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 05, 2016 12:30 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* bruno.decraene@orange.com; spring@ietf.org > *Subject:* Re: [spring] draft-ietf-spring-conflict-resolution > > > > Hi Les, > > > > > However, this is not existing MPLS forwarding behavior and since SR > > > explicitly utilizes the existing MPLS forwarding behavior we not propos= e > > > any extensions. > > > > I am afraid the above assertion is not correct. Existing MPLS forwarding > already > > for a long time uses context-labels to set required topology for > forwarding. > > > > https://tools.ietf.org/html/rfc5331 > > > > Thx, > > R. > > > > > > On Tue, Jul 5, 2016 at 9:19 AM, Les Ginsberg (ginsberg) < > ginsberg@cisco.com> wrote: > > Bruno =E2=80=93 > > > > SR-MPLS utilizes existing MPLS forwarding behavior without change. In thi= s > model, the received label serves as the forwarding instruction for the > packet. This means that if two packets are received for the same > destination but we want the packet to follow two different forwarding > =E2=80=9Ctopologies=E2=80=9D, then we need to have two different labels. > > > > One can imagine a different model, where the forwarding instruction is > derived from the label AND some other attribute of the packet =E2=80=93 a= nd the > latter could be used to select a forwarding topology. However, this is no= t > existing MPLS forwarding behavior and since SR explicitly utilizes the > existing MPLS forwarding behavior we not propose any extensions. > > > > This is why different SIDs are required for the same destination in > different topologies. > > > > Les > > > > > > *From:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > *Sent:* Monday, July 04, 2016 5:07 AM > > > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Les, > > > > Please see inline [Bruno3] > > > > *From:* Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > *Sent:* Friday, July 01, 2016 3:36 AM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno =E2=80=93 > > > > Inline. > > > > *From:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com > ] > *Sent:* Thursday, June 30, 2016 5:10 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Hi Les, > > > > Thanks for the discussion. Please see inline [Bruno] > > > > *From:* Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > *Sent:* Wednesday, June 29, 2016 6:19 PM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno =E2=80=93 > > > > > > *From:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com > ] > *Sent:* Wednesday, June 29, 2016 7:22 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Hi Les, > > > > IINM, I=E2=80=99ve not seen the follow up on one of my below questions. > > So let me restate a comment: > > > > The SR-MPLS SID conflicts algo requires that all nodes consider the same > mapping advertisements. > > How is this ensured, if it indifferently considers advertisements from al= l > protocols, while some nodes could participate only in a subset of the > protocols? e.g. OSPF only routers would consider a different set of > information compared to OSPF+IS-IS routers. > > > > *[Les:] If you run multiple protocol instances (whether multiple instance= s > of the same protocol or instances of different protocols) then you need t= o > insure that at least one of the two conditions below is true:* > > =C2=B7 All routers receive the equivalent set of advertisements > > =C2=B7 There are no conflicts J > > > > [Bruno] IOW, the draft does not resolve SID conflict if all routers do no= t > receive exactly the same set of advertisement from all routing protocols. > > That=E2=80=99s indeed can be a valid simplification if the WG choose to, = but this > should clearly be indicated in the document, in a section targeting netwo= rk > operator since this point will need to be read and enforced by network > operator rather than protocol implementors. =C2=A73.2.8 already partly ad= dress > this, but IMO a text clearly expressing the requirements on network > operator would be useful. > > > > *[Les2:] No policy can guarantee consistent results network wide if the > databases on different nodes are inconsistent. This isn=E2=80=99t a > =E2=80=9Csimplification=E2=80=9D =E2=80=93 it is a fact. As you point out= , Section 3.2.8 already > states:* > > > > *=E2=80=9CIn order to obtain consistent active entries all nodes in a net= work* > > * MUST have the same mapping entry database.=E2=80=9D* > > > > *If you believe this is not explicit enough please suggest some text.* > > [Bruno3] > > Section 4 Manageability Considerations > > Detecting and resolving conflicts in a consistent way requires that all > nodes consider the same set of SIDs advertisements. Network operations > should be aware that the conflict resolution algorithm defined in this > document will not succeed in selecting a consistent resolution across all > nodes, if all nodes do not receive the exact same set of SIDs > advertisements. This may be in particular the case when multiple IGP > instances are used and all routers do not participate in the same set of > IGP instances. This may occurs for example if one network transition from > one IGP protocol to another IGP (e.g. from OSPFv2 to IS-IS). This may als= o > happen if IGP areas/level are used and SIDs are not flooded in all > areas/levels. > > > > > > *One way of insuring the first point is to exclusively use a mapping > server to advertise SIDs, configure your SRMS entries in a protocol > independent manner, and insure that the SRMS advertisements are sent in a= ll > of the protocol instance specific sub-domains.* > > [Bruno] IOW, don=E2=80=99t make configuration errors ;-) > > Are you implying that the SRMS configuration (hence yang model) should be > per node rather than per protocol? or at least should be configurable by > node (and possibly also by protocols) > > > > *[Les2:] My point is (humorous ideas aside=E2=80=A6) that if a deployment= uses > multiple protocols, the easiest way to guarantee that the SID mapping > database on all nodes in the network is consistent is to restrict SID > advertisements to SRMS advertisements.* > > [Bruno3] Clearly, the fewer the number of advertisements for a given > prefix, the less change of conflict. > > But I fail to see why only using SRMS guarantee anything. e.g. if > different nodes use a different set of routing protocols, you have > conflicts. Idem if the misconfiguration consist in adding a SID to a IGP > prefix (PFX advertisement) > > > > > > *A small number of nodes (as few as 1 =E2=80=93 more if redundancy is des= ired) are > setup as mapping servers and all SIDs which are required network-wide are > configured on these nodes and advertised by the protocol instance(s) on > that node. In this way it is not necessary to guarantee that all prefix > reachability from all of the protocol instances running in the network ar= e > present in all the protocol instance sub-domains which exist =E2=80=93 it= is only > necessary to insure that all protocol instances advertise the same set of > SRMS entries.* > > [Bruno3] In the end, this gets back to requiring no configuration mistake= s. > > *It isn=E2=80=99t the only way to support this =E2=80=93 but it is likely= to be the > simplest and least error prone. In any case this isn=E2=80=99t a requirem= ent =E2=80=93 it > was a response to your question as to how it might be possible to get > consistent SID mapping databases on all nodes in such a case. This is no > way changes how the YANG model is defined. SRMS config is always node > specific.* > > > > > > *If the intent is to deliberately use different labels in the forwarding > plane for the same destination depending upon which protocol advertised t= he > prefix, this introduces a number of new requirements =E2=80=93 not the le= ast of > which is duplicate entries for the same prefix in the forwarding plane. = As > has been discussed publicly in a different thread, there are cases (e.g. > merging two networks) were such a requirement may exist =E2=80=93 but it = is the > exception rather than the rule and as it consumes more resources in the > forwarding plane and introduces implementation complexity independent of > conflict resolution it is not the primary case the draft focuses on. > Nevertheless, this is a case which the draft will address in the next > revision.* > > [Bruno]There is also the point of configuring different SRGB space in > different IGP protocols. In which case, SIDs may conflict but this is not > an issue as label will not conflict. > > *We stopped short of that in this revision because we felt there were > enough substantive changes and points on which consensus is still a work = in > progress that it would not be the optimal way forward.* > > [Bruno] +1 and thanks. Releasing an updated version has been useful to > re-initiate the discussion. > > > > Thinking more about this, I guess that this is only important for the > entries which are inserted in the forwarding plane. Hence, in case of > conflict between protocols, I think that the preference algorithm should > take into account the protocol preference (aka administrative distance). > > > > *[Les:] As admin distance is neither an attribute of SRMS entries nor > guaranteed to be consistent on all routers for all prefixes this is not a > desirable approach. * > > [Bruno] Well, the some prefix/routing consistency is also required for IP > prefixes. When then same IP prefix is advertised in different IGPs, admin > distance is a common existing way to define which routing protocol takes > precedence. I=E2=80=99m not sure why it should not also be taken into con= sideration > for SR Prefix conflits > > > > *[Les2:] Please see my response to Stephane on the same point.* > > > > I=E2=80=99m also not sure to see why is the problem different compared to > Multi-Topology. Could you please elaborate? > > *[Les:] I am unclear what your question is. Are you asking why we need > different SIDs in different topologies? Please clarify.* > > [Bruno] Question was that, at a very/too high level, the issue of conflic= t > across topology seems close to the issue of conflict across routing > protocols: we have different topologies. Hence a na=C3=AFve question: ho= w > exactly is this different. > > One part of the answer, is the simplification proposed when multiple > protocols is used (i.e. your first answer above). > > Another part is that for multi-topology, compared to multi-protocols, all > information from all topologies are flooded to all nodes. > > Another part is the forwarding model used for Multi-Topology. In general, > https://tools.ietf.org/html/rfc5120#section-8 seems to assume that each > topology has one dedicated RIB/FIB. In such condition, there is no confli= ct > (prefix or SID) so no need to detect and resolve conflict. So here there > may be different models and eventually, we don=E2=80=99t =E2=80=98have th= e same one in mind. > > In a lesser extend, even for multi-protocols, we may have those multiple > forwarding models. To some extent, this seems related to the definition o= f > =E2=80=9CSR domain=E2=80=9D. e.g. if we have 2 IGPs, do we have 1 or 2 SR= domains? May be > this is something that needs to be configurable > > > > > > *[Les2:] Please reread Section 3.1.2. While there are no > =E2=80=9CPrefix-conflicts=E2=80=9D across topologies, there are =E2=80=9C= SID Conflicts=E2=80=9D. This is > important to understand.* > > [Bruno3] Conflicts are related to a forwarding context i.e. FIB. This is > equally important to understand. Please read > https://tools.ietf.org/html/rfc5120#section-8.2.2 and 8.2.1 to see that > topologies may not share the same forwarding context hence do not conflic= t > in term of prefix & SID. > > --Bruno > > > > *As regards multiple protocols operating in the same topology, from a > forwarding perspective we do not care what protocol is the winning route. > What we care about is that our nexthop has chosen the same SID for a give= n > prefix. This is why =E2=80=9Csource=E2=80=9D is deliberately excluded fro= m consideration by > the conflict resolution algorithm.* > > > > * Les* > > > > * Les* > > > > > > Thanks, > > Bruno > > > > *From:* spring [mailto:spring-bounces@ietf.org ]= *On > Behalf Of *bruno.decraene@orange.com > *Sent:* Wednesday, May 18, 2016 1:57 PM > *To:* Les Ginsberg (ginsberg); spring@ietf.org > *Subject:* Re: [spring] draft-ietf-spring-conflict-resolution > > > > Les, > > > > Thanks for your reply. > > Please see inline [Bruno] > > > > *From:* Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > *Sent:* Saturday, May 14, 2016 8:30 PM > *To:* DECRAENE Bruno IMT/OLN; spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno =E2=80=93 > > > > Inline. > > > > *From:* spring [mailto:spring-bounces@ietf.org ]= *On > Behalf Of *bruno.decraene@orange.com > *Sent:* Thursday, May 12, 2016 8:23 AM > *To:* spring@ietf.org > *Subject:* [spring] draft-ietf-spring-conflict-resolution > > > > Hi, > > > > As an individual contributor, please find below some comments: > > > > -- > > Isn=E2=80=99t this document specific to the MPLS dataplane? > > If so, it could be indicated in the introduction, and possibly in the > abstract. Then this indication could be removed from the 1rst sentence of > sections 2 & 3. > > > > *[Les:] Currently all discussion is regarding SR-MPLS. The draft leaves > open the possibility that if there is some SRv6 conflict resolution that > needs to be specified it could be added into this document =E2=80=93 whic= h is why > the Introduction is dataplane agnostic, but each section states > specifically that it is relevant to SR-MPLS.* > > > > *I am not aware of any SRv6 conflict resolution that is required at this > point, but I prefer to leave the possibility open if that is OK with you.= * > > [Bruno] ok, great. > > -- > > =C2=A73 > > =E2=80=9CMapping entries have an explicit context which includes the topo= logy and > the SR algorithm.=E2=80=9C > > A priori you could add =E2=80=9Cthe routing protocol=E2=80=9D. > > > > *[Les:] No =E2=80=93 the source of advertisements is deliberately left ou= t. It > matters not whether the source of the advertisement is a protocol or an > SRMS =E2=80=93 nor does it matter which protocol provides the advertiseme= nt. You > see that =E2=80=9Cadmin distance=E2=80=9D is not mentioned at all and tha= t is quite > deliberate. This insures that consistent choices are made on nodes > regardless of which protocol might have the best route on a given node.* > > [Bruno] Well, the fact is that mapping entries do have, as explicit > context, the routing protocol used to advertise them. After, you can shou= ld > to use that information, or not. > > -- > > =C2=A73 > > =E2=80=9CWhen conflicts occur, it is not > > possible for routers to know which of the conflicting advertisements > > is "correct". If a router chooses to use one of the conflicting > > entries forwarding loops and/or blackholes may result unless it can > > be guaranteed that all other routers in the network make the same > > choice. Making the same choice requires that all routers have > > identical sets of advertisements and that they all use the same > > selection algorithm. =C2=BB > > > > I think we agree on the technical part, but I found the formulation sligh= tly biased. I would propose > > =E2=80=9CWhen conflicts occur, it is not > > possible for routers to know which of the conflicting advertisements > > is "correct". In order to avoid forwarding loops and/or blackholes, t= here is a need for all nodes to make the same choice. > > Making the same choice requires that all routers have > > identical sets of advertisements and that they all use the same > > selection algorithm. This is the purpose of this document. =C2=BB > > -- > > *[Les:] I am fine with this change.* > > [Bruno] Thanks > > > > =C2=A73.1 > > =E2=80=9CVarious types of conflicts may occur=E2=80=9D > > What about :s/Various/Two > > > > *[Les:] =E2=80=9CTwo=E2=80=9D is fine. Just means we will have to change = it if we come up > with a third type of conflict. **J* > > [Bruno] Indeed, but in this case the change may be much larger (e.g. the > whole algo) > > -- > > I agree with Robert=E2=80=99s and Uma=E2=80=99s comment with regards to = making this > conflict resolution an inter- protocol/routing_table issue. In particular= , > between SR domains, there is not requirement to have unique SIDs. Hence > between PE and CE, between ASes (both within and across organization), th= e > same SID could be reused independently). > > > > *[Les:] There is more to be said on this topic =E2=80=93 co-authors are a= ctively > discussing this point and we=E2=80=99ll respond more fully to Robert=E2= =80=99s post in > time. But, the draft is NOT trying to define conflict resolution across = =E2=80=9CSR > domains=E2=80=9D. Perhaps we need language to make that more explicit.* > > [Bruno] ok. Regarding inter-protocol, in order to have consistency of the > prefix-SID mapping across the domain we need: > > a) all nodes use the same algo > > b) all nodes using this algo have the same data > > > > =E2=80=9Ca=E2=80=9D requires this draft > > =E2=80=9Cb=E2=80=9D requires that all nodes have the same set of SR info= . This forbid > that some node are considering IS-IS + OSPF SR data, while some node are > only considering IS-IS data. Otherwise, all IS-IS routers would not take > the same decision. So, unless we can guarantee that the flooding area is > the same for IS-IS and OSPF, we can't have the algo using the SR data fro= m > multiple routing protocols. I don't think that we can guarantee this (nor > that implementation will check this) e.g. when some nodes are part of > multiple routing domain or when gradually transitioning from one IGP to > another. > > > > So in short, this SR-conflict algo should probably be restricted to SR > information from a single protocol > > > > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com > ] > Sent: Sunday, May 01, 2016 7:11 AM > > > > > > We are indeed defining conflict resolution across all the SID > advertisements regardless of source (protocol or SRMS) > > > Why? Because we need consistent use of SIDs in the forwarding plane > > > > No: in the forwarding plane, we need a consistent use of MPLS label. > > *[Les:] As you know, SRGB range can be different for different nodes, so > the actual label that is used to send a packet for a given destination vi= a > Node A may be different than the label used to send the same packet via > Node B. It is the SID that needs to be the same =E2=80=93 not the label. = * > > *It is true that SIDs are not installed in the forwarding plane =E2=80=93= the > labels derived from the SID/SRGB are what is actually installed in the > forwarding plane =E2=80=93 but I think my use of the word SID in this con= text is > correct.* > > [Bruno] My point was that the formulation assumes that a single SRGB is > used per nodes. In which case, we have a bijection between SID and labels= . > But if we have a SRGB per protocol, we don=E2=80=99t have a bijection any= more and > we can have the same SID in IS-IS and OSPF (including for different > prefix), which will be mapped to different labels in the forwarding plane= . > > > > Plus only within an SR domain. Actually, even within a domain, this is > dependent on whether SRGB is configured on a per node or a per protocol > basis. I=E2=80=99m not sure how much the agreement has been reached on th= at one. > > > > *[Les:] The draft currently addresses deployments where a single (set of) > SRGB ranges applies to the box. This is by far the most common use case. > There is a much more limited use case where protocol specific SRGBs and > protocol specific SIDs may be required. The draft will address that in a > future revision* > > [Bruno] ok, may be this should be stated in the draft, as otherwise you= =E2=80=99ll > keep getting comments, or we may forget this point. > > Thanks > > --Bruno > > *=E2=80=93 but in spirit the same rules will apply =E2=80=93 they will ju= st have to take > into account =E2=80=9Cduplicate forwarding domains=E2=80=9D. Note that th= is will also > require multiple incoming label entries/prefix be supported by the router= s > in such a network.* > > > > -- > > Typo: > > =C2=A72 > > OLD : Range 3: (500, 5990 > > NEW : Range 3: (500, 599) > > > > (somewhat significant as otherwise range 3 conflict with range 2) > > > > *[Les:] Agreed =E2=80=93 thanx for spotting this.* > > > > *Les* > > > > Thanks, > > Regards, > > Bruno > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --001a11411f28c8f4160536e6b8d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Les,

=
Use of context label for SR has been proposed 3 years ba= ck ..

https://tools.ietf.org/html/draf= t-raszuk-mpls-domain-wide-labels-05

I keep= the draft, but I am about to drop it if there is no further interest. It b= eats me that group of folks went with such protocol pollution recommending = use of indexes where no one I spoke with looking at SR deployment is not pl= anning to have any use for it.=C2=A0

 --001a11411f28c8f4160536e6b8d0-- From nobody Tue Jul 5 10:25:32 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796F112D66E for ; Tue, 5 Jul 2016 10:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkV8aiQKjjzw for ; Tue, 5 Jul 2016 10:25:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4210412D526 for ; Tue, 5 Jul 2016 10:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139374; q=dns/txt; s=iport; t=1467739510; x=1468949110; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=19BLOJH+r4GOdY2AIXdFLyyLdBvchY/wMxixKAy0fck=; b=MgWyv+vZ4T7LmIeJA2fy6x5db6i7xEvsU/+JjQ4DT8+vf006ZFuvDtYF C14Vis858MQ+HLyGHKfSzaAbgLLHymPugoFnwBXfP2YsarnR9JoP/8FBm u57ciPTGpCy8yfYkzS6wsBUkma/Nbq9aiKEuf6KW2lbTFOdsQsWALC299 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AgDd7HtX/5JdJa1cgnBOVnwGuUCBd?= =?us-ascii?q?4YYAoE0OBQBAQEBAQEBZRwLhEwBAQQBDA4BEkUHBQsCAQgRBAEBFgsBBgcyFAk?= =?us-ascii?q?IAgQOBQiIIAi7MAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4NKgQOEEhEBBkIKC?= =?us-ascii?q?YUcBYYHghOGIoUdhToBiQKCcoJLgXGEVohqjCMeg0gBHjaCCAUXgUxuhx82AX4?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.28,580,1464652800"; d="scan'208,217";a="120644441" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 17:25:02 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u65HP2N4006614 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 17:25:02 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 12:25:01 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 12:25:01 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwAAFyNVQACk7FpAAGrmsQACp0a4wACubJnAAAvwWgAAUDtkg Date: Tue, 5 Jul 2016 17:25:01 +0000 Message-ID: References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> <91fcbdba712143e890609f6a513f8528@XCH-ALN-001.cisco.com> <2921_1467708583_577B74A7_2921_256_5_53C29892C857584299CBF5D05346208A0F92B91D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <2921_1467708583_577B74A7_2921_256_5_53C29892C857584299CBF5D05346208A0F92B91D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.73] Content-Type: multipart/alternative; boundary="_000_eb0cf69db74641599fc1843aaaa51586XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 17:25:30 -0000 --_000_eb0cf69db74641599fc1843aaaa51586XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - Two comments: 1)As we both can come up with examples where a given preference algorithm = will result in "better" behavior than another, continuing to debate which o= ne is "best" has no end. The answer depends upon what types of errors are i= ntroduced in the configuration and that isn't predictable. If it is necessa= ry for us to agree on which algorithm is "best" I doubt that consensus will= ever be reached. It therefore is more important to me to focus on implemen= tation complexity and the importance of identifying and correcting misconfi= gurations ASAP. 2)There are two logical databases that an implementation has to support. On= e of them is the set of received advertisements which can include entries w= ith a variety of ranges. The second one is the set of mapping entries which= are in use for lookups. Your discussion of your "per FEC algorithm" below defines the second datab= ase as a set of entries all of which have a range of 1. Whether this is goo= d implementation model or not I am not commenting on here. But this does no= t eliminate the need to maintain the first database - and to be able to ass= ociate entries in the second database with the corresponding received entry= from which they may have been derived. There is work in maintaining that r= elationship which does not directly bear on the lookup for a given SID but = still has to be done if one uses "per FEC" or "Ignore Overlap Only". This w= ork is not required for the "per range" or "Quarantine" algorithm. It is th= is additional work that I refer to when I say that "per FEC" has a higher i= mplementation cost/complexity. Les From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Tuesday, July 05, 2016 1:50 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 05, 2016 9:08 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - Consider the following simple case: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2: (SRMS, 1.1.1.1/32, 200, 10, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) There is a misconfiguration here, but we don't know what was really intende= d. A few (of many) possibilities: ERROR #1: Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !St= arting SID error ERROR #2: Entry #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Sta= rting prefix error The draft defines two candidate preference rules which could be applied: Quarantine ---------------- As we evaluate prefix conflicts first, we compare Entry #1 and Entry #2 and= choose Entry #1 the winner (source is PFX). Entry #2 is then not used (qua= rantined) and the set of active entries is: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) Ignore Conflict Only ------------------------- In this case we split Entry #2 into two derived entries: Entry #2A: (SRMS, 1.1.1.1/32, 200, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry 2A is then ignored and we then have to evaluate SID conflicts between= the derived entry 2B and Entry #3. For this we have to split Entry 3 into= two derived entries: Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Entry #3B: (SRMS, 2.2.2.3/32, 201, 9. 0, 0) Entry 2B wins over entry 3B since it has a smaller range. Active entries are then: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Note that in this example both preference rules result in 11 destinations h= aving non-conflicting SIDs. [Bruno] Yes. The important part is =AB in this example =BB. Now do we agree= that in average, Quarantine will result in dropping more destinations than= Ignore conflict only? Now, which of these maximizes delivery of traffic? The answer to that depe= nds upon the type of configuration error that was made. If Error #1 was made, there is no way to differentiate the two preference r= ules. However, if Error #2 was made, then Quarantine is clearly better because th= e destinations 1.1.1.2 - 1.1.1.10 were never intended to have assigned SIDs= and may not even exist as destinations in the network, yet "Ignore Conflic= t Only" favors those prefixes. The point I am trying to make is that it is incorrect to say "If we maximiz= e the number of advertised entries which we use we will always do a better = job of delivering traffic." This example illustrates that this isn't always= true. [Bruno] OK. Clearly, we can find an example where an algorithm is better th= an the other. After all, we all agree that there has been a configuration e= rror. There are 2 points: a) how many destination you keep using b) in case of conflict which of the entries you select I agree that "b" is more or less random and hence there are many cases wher= e we'll pick the wrong one. Yet, we try to make reasonable choices. That th= e point of discussing the preference algorithm (3.2.4). (Although it's very= easy to argue that we can make the wrong choice, I don't feel that's a rea= son not to try discussing it and make choice. e.g. "PFX source wins over SR= MS source" is one: we give preference to SR nodes rather than LDP nodes. Regarding a, I feel that maximizing the number of destinations kept, is lik= ely to give the best result in average. I don't have a proof, but it feel l= ike playing loto: even if each choice is random ("b"), the more you try ("a= ") the better your chances. A few more comments inline. From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Monday, July 04, 2016 5:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 3:12 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I don't find your representation complete as regards all of the attributes = which are proposed to be used by the conflict resolution algorithm - so it = is therefore hard for me to use/understand this representation when applyin= g the defined preference rule. This is true for me even after reading your explanations below. But it is far more important to have a common understanding of the algorith= m proposal than it is to be arguing over whose encoding is "better". If the= encoding in the draft is not clear or could use improvement, I welcome you= r feedback. As far as your "pseudo-code": - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID The fact that you can represent an algorithm in a few lines does not mean t= he implementation of the algorithm is just as simple. [Bruno] Sure. But if we want to compare implementation complexity, we'll ne= ed to agree on how much we want to go into details, in order to have meanin= gful comparison. So far this is not clear to me as you sometimes argue that= data structure is implementation specific and you don't want to go into th= is (which I agree) and sometime you detail the data structure. There is also the option to consider this as "implementation issue" and let= this to implementations. Coming back to my per FEC algo, all what is required from the data structur= e, is a way/API to get the data back, though 2 keys: get me the SID matchin= g prefix P1 (for the first line), get me the prefixes matching the SID SIDi= for the second line. That seem like a reasonable requirement on the data s= tructure, and any option in your draft also requires this to detect prefix = conflict and SID conflict (since this is all my per FEC algo is doing in th= ese 2 first lines). Going into more details, my per FEC algo only requires to detail that one p= refix or SID belong to a range (of prefix or SID) while your per range algo= requires to compute range intersection which is harder. So the API to fetc= h the data can only be easier. [Les:] Range intersection is easy to compute - the algorithm is present in = the draft at the end of Section 3.1.1. [Bruno] In order to have a meaningful discussion, we need to define the lev= el of details that we want to take into account, because you're not using t= he same one to discuss your algo and mine. 1) As a first level of comparison, using the description at the end of sect= ion 3.1.1 as a model, for range prefix conflict your algo is: 1)(T1 =3D=3D T2) && (A1 =3D=3D A2) 2)P1 <=3D P2 3)The prefixes are in the same address family. 2)L1 =3D=3D L2 3)(P1e >=3D P2) && ((S1 + (P2 - P1)) !=3D S2) So for (FEC) prefix conflict my algo is: 1)(T1 =3D=3D T2) && (A1 =3D=3D A2) 2)P1 =3D P2 3)The prefixes are in the same address family. 2)L1 =3D=3D L2 (BTW, in the draft, there is a typo in the numbering) It looks clear that FEC comparison is easier than prefix range intersection= . 2) Going deeper, at the algo complexity The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all the = algo complexity is coming from the datastructure. It seems pretty reasonabl= e to find a datastructure << o(n) (e.g. a tree, but you will be much better= than me in finding one) For the range algo, it's not clear to me that a data structure can be found= to automatically find the result. If not, the algo seems to compare all en= tries two by two, which would get o(n*(n-1)...(2)) i.e. o(n!) Consider what needs to be done to implement "Find all SIDi advertised for the prefix P1" In its simplest form, we have a list of all SID advertisements (PFX and SRM= S) that we have received. One could imagine walking all the entries, lookin= g to see if the prefix of interest is present within the advertised range. = But, of course, at large scale such an approach is extremely inefficient - = so we immediately start considering ways to improve performance. Inserting = received entries into an ordered tree of some kind is an obvious way to imp= rove performance. When one further considers that calculating conflict reso= lution only needs to be done when a change to the received database occurs = (which post startup is infrequent) it becomes very attractive to cache the = "winning entries" so that if one wants to retrieve the SID for a given pref= ix we only have to examine a subset of the total database - ignoring the lo= sers. [Bruno] I agree that the per range algo (ignore overlap only) will be able = to ignore the losers but at the cost of a more complex algo and at the cost= of creating new derived entries. It's not clear to me if the net result is= positive. Plus I would expect that the number of conflit is small compared= to the number of prefix /SID so this looks like a second order optimizatio= n. In this context, we can appreciate the difference between the three propose= d algorithms. In particular comparing "Quarantine" with "ignore overlap onl= y", a key difference is that "Quarantine" only needs to determine whether a= received entry is a winning entry or a losing entry. "Ignore overlap only"= has to be capable of breaking received entries with ranges > 1 into multip= le "derived" entries (some winning, some losing), which means we now need t= o track the "derived entries" against the original received entry so that i= f the received entry is updated/deleted we can find all the derived entries= and delete/regenerate the derived entries as needed. This is what adds com= plexity. [Bruno] and that it why the per FEC algo seems easier. So it would seem useful to add it in the draft so that we can all discuss i= t. [Les:] Ignore overlap only is the same as per FEC. We may use different wor= ds to describe it, but the end behavior is the same. [Bruno] good if this get the same result. Yet the algo is different. -- Bruno Les All proposed algorithms can be implemented, but it does seem prudent to con= sider implementation complexity as part of our decision process - and the d= iscussion/examples in Section 3 are meant to help in doing this. It is worthwhile restating that when conflicts are present we cannot guaran= tee that forwarding will work correctly no matter what algorithm is used. [Bruno] I'm not sure to see what you have in mind exactly. Can you elaborat= e? To me consistency seem enough. The more complex the implementation the more likely it is that bugs will b= e present and the more likely it is that interoperability issues will arise= . Whether these costs/risks are worth the "value add" when the outcome cann= ot be guaranteed to be correct - only guaranteed to be consistent - is an i= mportant consideration. Also important to remember that conflicts MUST be eliminated by correcting = the misconfigurations that caused them - so conflict resolution is really o= nly an interim measure until the corrections can be made. [Bruno] By "interim" we are at minimum talking about 10s of minutes, if not= more than 1 hour since identifying the root cause may not be obvious. The = impact is very significant on the network. The "Quarantine" algo has the potential to kill 100s PE and 1000s of VPN cu= stomers, so a single configuration change on a unrelated router which may n= ot even be in production (i.e. where configuration checks and operations ho= urs may be relaxed) No one should be lulled into thinking that because we have conflict resolut= ion deployed that correcting the configuration when conflicts are detected = is not a priority. [Bruno] I could not agree more that conflict needs to be identified and fix= ed. Note that I'm the one having asked for defining YANG notifications to r= eport this. You are welcomed to state in the draft that conflicts needs to be reported = to the network operator, in particular though yang notification, and other = existing means. Plus that network operator needs to fixed them ASAP (but st= ill carefully) Thanks --Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:00 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. [Bruno] I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there w= as a way to make progress by asking clarification questions on the points w= hich were not clear, or at least explicitly refusing to consider the email. I also note that what bothered you in my representation was my addition of = the type of advertisement (prefix or MS). But you finally have just added i= n the latest version of the draft "Src- PFX or SRMS" . So there was probabl= y a way to communicate. Besides the algo did not use any specification representation, just names. = So I'll copy/paste it below, please ask clarification questions for the par= ts which are not clear enough. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, for P1, we get a list of (SIDi, Pij) Get the best (SIDi, Pij) as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? [Bruno] - MS/prefix SID is the type of advertisement. In your new version, you call= it SRMS/PFX. - SID is the SID found in the Mapping Entrie - Rx is the loopback (prefix) or router Rx So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and= means: For prefix R2, we found a MS mapping entries advertising SID2 for t= his prefix, and then I found a MS mapping entries advertising prefix R2 for= SID2. Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . [Bruno] I agree that since the above algo used 2 mapping entries to provide= s the (SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted.= That being said, this is not important for this discussion. Let's just con= sidered that their exist a preference algorithm, which takes as input a lis= t of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition = of "best" is not pertinent) ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. [Bruno] Indeed, this is my expectation. But I would need someone's review t= o confirm this. But the difference is that the proposed algo is simple (2 lines of pseudo c= ode), with very modest resquirement data structure use to store the mapping= entries. Indeed, all it needs is a function returning the list of mapping = entries associated/matching a given prefix. And function returning the list= of mapping entries associated/matching a given SID. In particular, there is no need for splitting mapping entries which is the = main complexity of your proposed "Preference algorithm/ignore overlap only"= . (according to your own text). -- Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active"= : (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_eb0cf69db74641599fc1843aaaa51586XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

Two comments:

 

1)As we both can come = up with examples where a given  preference algorithm will result in &#= 8220;better” behavior than another, continuing to debate which one is= “best” has no end. The answer depends upon what types of errors are introduced in the configuration and that isn’t predict= able. If it is necessary for us to agree on which algorithm is “best&= #8221; I doubt that consensus will ever be reached. It therefore is more im= portant to me to focus on implementation complexity and the importance of identifying and correcting misconfigurations ASAP.

 

2)There are two logica= l databases that an implementation has to support. One of them is the set o= f received advertisements which can include entries with a variety of range= s. The second one is the set of mapping entries which are in use for lookups.

Your discussion of you= r “per FEC algorithm”  below defines the second database a= s a set of entries all of which have a range of 1. Whether this is good imp= lementation model or not I am not commenting on here. But this does not eliminate the need to maintain the first database –= ; and to be able to associate entries in the second database with the corre= sponding received entry from which they may have been derived. There is wor= k in maintaining that relationship which does not directly bear on the lookup for a given SID but still has to be d= one if one uses “per FEC” or “Ignore Overlap Only”.= This work is not required for the “per range” or “Quaran= tine” algorithm. It is this additional work that I refer to when I sa= y that “per FEC” has a higher implementation cost/complexity.

 

   Les<= /o:p>

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Tuesday, July 05, 2016 1:50 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com= ]
Sent: Tuesday, July 05, 2016 9:08 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

Consider the following= simple case:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2: (SRMS, 1.1.1= .1/32, 200, 10, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

There is a misconfigur= ation here, but we don’t know what was really intended. A few (of man= y) possibilities:

 

ERROR #1:   = Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !Starting SID e= rror

ERROR #2:  Entry = #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Starting prefix erro= r

 

The draft defines two = candidate preference rules which could be applied:

 

Quarantine<= /span>

----------------<= /o:p>

As we evaluate prefix = conflicts first, we compare Entry #1 and Entry #2 and choose Entry #1 the w= inner (source is PFX). Entry #2 is then not used (quarantined) and the set = of active entries is:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

Ignore Conflict Only

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

In this case we split = Entry #2 into two derived entries:

 

Entry #2A: (SRMS, 1.1.= 1.1/32, 200, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

 

Entry 2A is then ignor= ed and we then have to evaluate SID conflicts between the derived entry 2B = and Entry #3.  For this we have to split Entry 3 into two derived entr= ies:

 

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

Entry #3B: (SRMS, 2.2.= 2.3/32, 201, 9. 0, 0)

 

Entry 2B wins over ent= ry 3B since it has a smaller range.

 

Active entries are the= n:

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

 

Note that in this exam= ple both preference rules result in 11 destinations having non-conflicting = SIDs.

[Bruno] Yes. The impor= tant part is =AB in this example =BB. Now do we agree that in ave= rage, Quarantine will result in dropping more destinations than Ignore conf= lict only?

 

 Now, which of th= ese maximizes delivery of traffic? The answer to that depends upon the type= of configuration error that was made.

If Error #1 was made, = there is no way to differentiate the two preference rules.

However, if Error #2 w= as made, then Quarantine is clearly better because the destinations 1.1.1.2= – 1.1.1.10 were never intended to have assigned SIDs and may not eve= n exist as destinations in the network, yet “Ignore Conflict Only” favors those prefixes.

 

The point I am trying = to make is that it is incorrect to say “If we maximize the number of = advertised entries which we use we will always do a better job of deliverin= g traffic.” This example illustrates that this isn’t always true.

[Bruno] OK. Clearly, w= e can find an example where an algorithm is better than the other. After al= l, we all agree that there has been a configuration error.

There are 2 points:

a)&n= bsp;     how many desti= nation you keep using

b)&n= bsp;     in case of con= flict which of the entries you select

 

I agree that “b&= #8221; is more or less random and hence there are many cases where we’= ;ll pick the wrong one. Yet, we try to make reasonable choices. That the po= int of discussing the preference algorithm (3.2.4). (Although it’s very easy to argue that we can make the wrong choice, I donR= 17;t feel that’s a reason not to try discussing it and make choice. e= .g. “PFX source wins over SRMS s= ource” is one: we give preference to SR nodes rather than LDP nodes.

 

Regarding a, I feel th= at maximizing the number of destinations kept, is likely to give the best r= esult in average. I don’t have a proof, but it feel like playing loto= : even if each choice is random (“b”), the more you try (“a”) the better your chances.  <= /span>

 

 

A few more comments in= line.

 

 

From: bruno.decraene@orange.com [<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif"">mailto:bruno.decraene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Please see inline [Bruno]

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com= ]
Sent: Friday, July 01, 2016 3:12 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I don’t find you= r representation complete as regards all of the attributes which are propos= ed to be used by the conflict resolution algorithm – so it is therefo= re hard for me to use/understand this representation when applying the defined preference rule.

This is true for me ev= en after reading your explanations below.

 

But it is far more imp= ortant to have a common understanding of the algorithm proposal than it is = to be arguing over whose encoding is “better”. If the encoding = in the draft is not clear or could use improvement, I welcome your feedback.

 

As far as your “= pseudo-code”:

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

The fact that you can = represent an algorithm in a few lines does not mean the implementation of t= he algorithm is just as simple.

 

[Bruno] Sure. But if we want to compare implementati= on complexity, we’ll need to agree on how much we want to go into det= ails, in order to have meaningful comparison. So far this is not clear to m= e as you sometimes argue that data structure is implementation specific and you don’t want to go into this (which= I agree) and sometime you detail the data structure.

There is also the option to consider this as “= implementation issue” and let this to implementations.

 

Coming back to my per FEC algo, all what is required= from the data structure, is a way/API to get the data back, though 2 keys:= get me the SID matching prefix P1 (for the first line), get me the prefixe= s matching the SID SIDi for the second line. That seem like a reasonable requirement on the data structure, and a= ny option in your draft also requires this to detect prefix conflict and SI= D conflict (since this is all my per FEC algo is doing in these 2 first lin= es).

 

Going into more details, my per FEC algo only requir= es to detail that one prefix or SID belong to a range (of prefix or SID) wh= ile your per range algo requires to compute range intersection which is har= der. So the API to fetch the data can only be easier.

 

 

[Les:] Range int= ersection is easy to compute – the algorithm is present in the draft = at the end of  Section 3.1.1.

[Bruno] In order to ha= ve a meaningful discussion, we need to define the level of details that we = want to take into account, because you’re not using the same one to d= iscuss your algo and mine.

1) As a first level of= comparison, using the description at the end of section 3.1.1 as a model, = for range prefix conflict your algo is:

   1)(T1 =3D=3D T2) && (A1 =3D=3D A2)

   2)P1 <=3D P2

   3)The prefixes are in the same address family= .

   2)L1 =3D=3D L2

   3)(P1e >=3D P2) && ((S1 + (P2 = - P1)) !=3D S2)

 

So for (FEC) prefix co= nflict my algo is:

   1)(T1 =3D=3D T2) && (A1 =3D=3D A2)

   2)P1 =3D P2

   3)The prefixes are in the same address family= .

   2)L1 =3D=3D L2

 

(BTW, in the draft, th= ere is a typo in the numbering)

It looks clear that FE= C comparison is easier than prefix range intersection.

 

2) Going deeper, at th= e algo complexity

 

The FEC algo needs: ge= t_SIDs(Prefix), and all the work is done. So all the algo complexity is com= ing from the datastructure. It seems pretty reasonable to find a datastruct= ure << o(n) (e.g. a tree, but you will be much better than me in finding one)

For the range algo, it= ’s not clear to me that a data structure can be found to automaticall= y find the result. If not, the algo seems to compare all entries two by two= , which would get o(n*(n-1)…(2)) i.e. o(n!)

 

 

 

 

Consider what needs to= be done to implement

 

   “Fi= nd all SIDi advertised for the prefix P1”

 

In its simplest form, = we have a list of all SID advertisements (PFX and SRMS) that we have receiv= ed. One could imagine walking all the entries, looking to see if the prefix= of interest is present within the advertised range. But, of course, at large scale such an approach is extremely ineffi= cient – so we immediately start considering ways to improve performan= ce. Inserting received entries into an ordered tree of some kind is an obvi= ous way to improve performance. When one further considers that calculating conflict resolution only needs to be do= ne when a change to the received database occurs (which post startup is inf= requent) it becomes very attractive to cache the “winning entriesR= 21; so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database = – ignoring the losers.

[Bruno] I agree that the per range algo (ignore over= lap only) will be able to ignore the losers but at the cost of a more compl= ex algo and at the cost of creating new derived entries. It’s not cle= ar to me if the net result is positive. Plus I would expect that the number of conflit is small compared to the nu= mber of prefix /SID so this looks like a second order optimization.

 

In this context, we ca= n appreciate the difference between the three proposed algorithms. In parti= cular comparing “Quarantine” with “ignore overlap only= 221;, a key difference is that “Quarantine” only needs to deter= mine whether a received entry is a winning entry or a losing entry. “Igno= re overlap only” has to be capable of breaking received entries with = ranges > 1 into multiple “derived” entries (some winning, so= me losing), which means we now need to track the “derived entriesR= 21; against the original received entry so that if the received entry is updat= ed/deleted we can find all the derived entries and delete/regenerate the de= rived entries as needed. This is what adds complexity.

[Bruno] and that it why the per FEC algo seems easie= r.

So it would seem useful to add it in the draft so th= at we can all discuss it.

 

[Les:] Ignore ov= erlap only is the same as per FEC. We may use different words to describe i= t, but the end behavior is the same.

[Bruno] good if this g= et the same result. Yet the algo is different.

 

-- Bruno

 

   Les=

 

 

All proposed algorithm= s can be implemented, but it does seem prudent to consider implementation c= omplexity as part of our decision process – and the discussion/exampl= es in Section 3 are meant to help in doing this.

 

It is worthwhile resta= ting that when conflicts are present we cannot guarantee that forwarding wi= ll work correctly no matter what algorithm is used.

[Bruno] I’m not sure to see what you have in m= ind exactly. Can you elaborate? To me consistency seem enough.

 The more complex= the implementation the more likely it is that bugs will be present and the= more likely it is that interoperability issues will arise. Whether these c= osts/risks are worth the “value add” when the outcome cannot be guaranteed to be correct – only guaranteed to = be consistent – is an important consideration.

 

Also important to reme= mber that conflicts MUST be eliminated by correcting the misconfigurations = that caused them – so conflict resolution is really only an interim m= easure until the corrections can be made.

[Bruno] By “interim” we are at minimum t= alking about 10s of minutes, if not more than 1 hour since identifying the = root cause may not be obvious. The impact is very significant on the networ= k.

The “Quarantine” algo has the potential = to kill 100s PE and 1000s of VPN customers, so a single configuration chang= e on a unrelated router which may not even be in production (i.e. where con= figuration checks and operations hours may be relaxed)

 

 

No one should be lulle= d into thinking that because we have conflict resolution deployed that corr= ecting the configuration when conflicts are detected is not a priority.

[Bruno] I could not agree more that conflict needs t= o be identified and fixed. Note that I’m the one having asked for def= ining YANG notifications to report this.

You are welcomed to state in the draft that conflict= s needs to be reported to the network operator, in particular though yang n= otification, and other existing means. Plus that network operator needs to = fixed them ASAP (but still carefully)

 

Thanks

--Bruno

 

   Les<= /o:p>

 

 

From: bruno.decraene@orange.com [<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif"">mailto:bruno.decraene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks for the discuss= ion. Please see inline [Bruno]

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com= ]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

As the thread below do= cuments, I stated that I did not understand your representation and asked f= or clarification – suggesting that you use the format defined in the = draft.

You stated that you co= uld not do that and we were at a point where no progress could be made.

[Bruno] I could _no= t_ use your format since your format did not include the information ne= ed. This is not a whim but a technical issue. So I asked you to still consi= der the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification q= uestions on the points which were not clear, or at least explicitly refusin= g to consider the email.

I also note that what bothered you in my=
 representation was my addition of the type of advertisement (prefix or MS)=
. But you finally have just added in the latest version of the draft “=
; . So there w=
as probably a way to communicate.

 

 

Besides the algo did n= ot use any specification representation, just names. So I’ll copy/pas= te it below, please ask clarification questions for the parts which are not= clear enough.

 

The problem that we ne= ed to solve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advert= ised for the prefix P1         = ;            &n= bsp;            = ;            &n= bsp;            // i= dentification of Prefix conflicts

   &nbs= p;            - For = each SIDi find all the prefix Pij associated with SIDi   &nb= sp;          // identification= of SID conflicts

 

// as a result, for P1= , we get a list of (SIDi, Pij)

 

Get the best (SIDi, Pi= j) as per the preference algorithm.

If best Pij =3D=3D P1<= o:p>

   &nbs= p;            then u= se SIDij for P1

   &nbs= p;            else r= eturn no SID          &nb= sp;            =    / no SID available for this prefix P1

 

 

 

To illustrate my confu= sion, one of your examples is:

 

For R2, the algo evaluates a conflict between the following advertismen= ts:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

 

Now, what does “= R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]

- MS/prefix SID is the= type of advertisement. In your new version, you call it SRMS/PFX.

- SID is the SID found= in the Mapping Entrie

- Rx is the loopback (= prefix) or router Rx

 

So “R2 - SID2 - R2 (MS, MS)” is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

 

Does it mean  = 220;On R2, SID2 is assigned to prefix R2 from two different mapping server = entries?” I really have no idea.

 

And you conclude the e= xample by saying

 

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID))

   =3D=3D> SID12 is selected for R2.=

 

But since there is no = representation of “range” in your examples I really have no ide= a how you came to this conclusion .

[Bruno] I agree that s= ince the above algo used 2 mapping entries to provides the (SIDi, Pij), the= preference algo (=A73.2.4) would need to be adapted. That being said, this= is not important for this discussion. Let’s just considered that their exist a preference algorithm, which= takes as input a list of (SIDi, Piij) for P1, and gives as outpout the = 220;best” one. (definition of “best” is not pertinent)

 

 

??

 

As regards “per = FEC/Prefix”, I believe this is what “ignore overlap only”= does.

[Bruno] Indeed, this i= s my expectation. But I would need someone’s review to confirm this.<= o:p>

But the difference is = that the proposed algo is simple (2 lines of pseudo code), with very modest= resquirement data structure use to store the mapping entries. Indeed, all = it needs is a function returning the list of mapping entries associated/matching a given prefix. And function r= eturning the list of mapping entries associated/matching a given SID.<= /o:p>

In particular, there i= s no need for splitting mapping entries which is the main complexity of you= r proposed “Preference algorithm/ignore overlap only”. (accordi= ng to your own text).

 

-- Bruno

 

 

    Les=

 

 

From: bruno.decraene@orange.com [<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif"">mailto:bruno.decraene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks for the updated= draft.

 

IINM, you have not ans= wered my below email/proposal. I had waited for the new version of the draf= t but it also does not touch this subject.

 

So, could you please c= onsider and answer my comment?

 

In short, in an implem= entation-independent sentence:

 

> I'm wondering if we could address the conflict = on a per FEC/Prefix basis rather than on a per IGP advertisement (range) ba= sis.

> If so, this may avoid the discussion between th= e Quarantine vs ignore policy.

 

 

Thanks

Bruno

 

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org<= /span>
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com= ]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce.

[Bruno] My text does not incorporate the source, but= the type of source IOW the type of sub-TLV.

 

So it does not matter = if R2 sends an advertisement or R12 sends advertisement or both of them do = (which could happen when an advertisement is leaked) – what matters i= s what unique entries are in the database independent of source.

[Bruno] It may not matter for your algorithm (pendin= g another thread), but it does for the one I proposed.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

[Bruno] My examples are described in plain text. The= n the examples giving intermediate steps of my algo uses the data that are = needed i.e. the type of advertisement (Prefix-SID vs MS).

Then finally, my algo runs on a per FEC/IP Prefix ba= sis, and not on a per IGP advertisement basis which your format describe.

So I’m sorry but I don’t see how to indu= lge your request.

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /i>

     Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

     Pe =3D (Pi + ((= R-1) << (Lx-L))

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

this to me specifies a= n implementation – which isn’t necessary.

[Bruno] Well, _you_ are the one talking about= implementation, and more specifically implementation complexity.

Assuming the above algo works, it looks relatively s= imple to implement, in which case, I would not buy the argument about imple= mentation complexity which is the only argument in favor or the “igno= re” or “quarantine” policy.

Bottom line, I would welcome your feedback and comme= nts on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

 

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:=

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:<= /o:p>

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_eb0cf69db74641599fc1843aaaa51586XCHALN001ciscocom_-- From nobody Wed Jul 6 08:31:49 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FAF12B01F; Wed, 6 Jul 2016 08:31:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706153143.26812.22071.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 08:31:43 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-05.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 15:31:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing with MPLS data plane Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Martin Horneffer Rob Shakir Jeff Tantsura Edward Crabbe Filename : draft-ietf-spring-segment-routing-mpls-05.txt Pages : 15 Date : 2016-07-06 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change in the forwarding plane. This drafts describes how Segment Routing operates on top of the MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 6 08:35:50 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E99312D6AB for ; Wed, 6 Jul 2016 08:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUi30w_tirf0 for ; Wed, 6 Jul 2016 08:35:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0334D12D5C3 for ; Wed, 6 Jul 2016 08:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1837; q=dns/txt; s=iport; t=1467819330; x=1469028930; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GmnGzvIS9/gfZPgEjJvO8KsRHmFivKDMb1jYRLmBGxA=; b=ERFhCkwGTXhcqEw8OT5KinSpnsbJOxfcVodJaBpdhPyPcpJqg9F91kKn oWFDaFQIkY1mA/vEN7CecZKuzwbgw8Tb6KjegVoNWHRxstidj3HE7r0Uz S9HZEbzeiAKSG04/pDPQHDEQxa90fKnP5+jIrfVIvN+59ZnGTNN7PDeOi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAPJH1X/4gNJK1dgz5WfAa5EYF3J?= =?us-ascii?q?IV0AoEqOBQBAQEBAQEBZSeETAEBBAE6PQcLAgEIEgYeEDIXDgIEE4goCA68KgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4F4CIJNhECDLIIvBY4Eiw8BhgiIPoFqT?= =?us-ascii?q?oQIiGqQCQEeNoNwbgGHcn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="scan'208";a="293674183" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2016 15:35:29 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u66FZSGH024401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jul 2016 15:35:29 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 11:35:28 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 11:35:28 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: New Version Notification for draft-ietf-spring-segment-routing-mpls-05.txt Thread-Index: AQHR15uCYqJzp13WVkqRX6TX9ANRD6ALy+GA Date: Wed, 6 Jul 2016 15:35:28 +0000 Message-ID: <4C694B52-2A72-4859-BAB9-4D1D3A8E2671@cisco.com> References: <20160706153144.26812.69500.idtracker@ietfa.amsl.com> In-Reply-To: <20160706153144.26812.69500.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.175.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <90E51C62421EB94DB936AD3E1CF602CE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] New Version Notification for draft-ietf-spring-segment-routing-mpls-05.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 15:35:37 -0000 Hi, integrated comments on SRMS and sRGB and added reference on Manageability a= nd Security sections. Thanks. s. =20 > On Jul 6, 2016, at 5:31 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-spring-segment-routing-mpls-05.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-ietf-spring-segment-routing-mpls > Revision: 05 > Title: Segment Routing with MPLS data plane > Document date: 2016-07-06 > Group: spring > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-ietf-spring-se= gment-routing-mpls-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-spring-segmen= t-routing-mpls/ > Htmlized: https://tools.ietf.org/html/draft-ietf-spring-segment-rou= ting-mpls-05 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-seg= ment-routing-mpls-05 >=20 > Abstract: > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through a controlled set of instructions, called > segments, by prepending the packet with an SR header. A segment can > represent any instruction, topological or service-based. SR allows > to enforce a flow through any topological path and service chain > while maintaining per-flow state only at the ingress node to the SR > domain. >=20 > Segment Routing can be directly applied to the MPLS architecture with > no change in the forwarding plane. This drafts describes how Segment > Routing operates on top of the MPLS data plane. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Jul 6 21:14:45 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16A012D1D8 for ; Wed, 6 Jul 2016 21:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nzLbOt3MK7v for ; Wed, 6 Jul 2016 21:14:40 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2A312D0C3 for ; Wed, 6 Jul 2016 21:14:40 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-46-577dd6ed3b41 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 6F.E7.03614.DE6DD775; Thu, 7 Jul 2016 06:13:33 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0294.000; Thu, 7 Jul 2016 00:14:39 -0400 From: Gregory Mirsky To: David Allan I , "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.txt Thread-Index: AQHR06vsArfNwudLBk2IB1qZgLqlnqAEAnGAgAgQdOA= Date: Thu, 7 Jul 2016 04:14:38 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221AC388D@eusaamb103.ericsson.se> References: <20160701151906.24589.40199.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPlO7ba7XhBsdmmVgcv/Cb0YHRY8mS n0wBjFFcNimpOZllqUX6dglcGTtnPWEr+K5Y8fPtQ7YGxgVSXYycHBICJhK7mvazQNhiEhfu rWfrYuTiEBI4yijxon8bC4SzjFFiwuod7CBVbAJGEi829oDZIgKhEp0T5gHZHBzCAr4Sm88G gpgiAgESi+faQ1RYSSy/94ARxGYRUJHouX+LGcTmBar+fucEM8T4VkaJw0emgo3kFPCTeNZ2 FqyIEeig76fWMIHYzALiEreezGeCOFRAYsme88wQtqjEy8f/WCFsJYmPv+ezQ9TrSCzY/YkN wtaWWLbwNdRiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI0dpcUFObrqR4SZGYOAfk2Bz 3MG4t9fzEKMAB6MSD29CfW24EGtiWXFl7iFGCQ5mJRHejstAId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rz6LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYxKWyoOfef4V1AWE158SVCxNWv+qYDjSUvW PDmyYWGtyMdjir9fOb+c9XvtMnbPFBVrM84AmTUntBbcEddJOaaxMC+iSdG4XEfuZ8H97Hjp pCtLsi/ksVz9yqcdE8/6e8ZC15faJyeHb5OT2lR6OzWmWOrBqSlNK6oq5fNTWcO0uJ6d7v0R ckuJpTgj0VCLuag4EQAG9c1ceAIAAA== Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 04:14:43 -0000 Hi Dave, many thanks for your thorough review and insightful comments. Apologies for= the delayed response as we been tied in with other activities. Will discus= s and continue work after the meeting. Regards, Greg -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of David Allan I Sent: Friday, July 01, 2016 9:12 AM To: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.t= xt Hi I looked over this and have a few modest suggestions.... 1) Could be clarified a bit... REQ#2: The SR OAM packet MUST follow exactly the same path as dataplane traffic Suggested change REQ#2: An SR OAM packet MUST follow exactly the same path as the dataplane traffic it is intended to instrument. We could also argue about "exact path", as best we can do is in the nodal s= ense....=20 2) Delete REQ 3 and REQ 4 Reason: Clarity. Packets do not discover anything, systems can. If the syst= em implements ECMP and/or UCMP and the OAM system meets requirement 2, you'= re done. 3) REQ5, question... When you say available, is this in the sense that the path meets a specifi= ed criteria of information transfer capability? Depending on the answer I = may suggest an edit or two...and it may be necessary to include a definitio= n of availability. (definition, not specification as we'll argue till the c= ows come home :-) 4) REQ9, clarification The current text reads like the CC mechanism itself failed, not what it wa= s instrumenting. Suggested tweak... REQ#9: In case of any path failure detected with continuity check, SR = OAM SHOULD support rapid Connectivity Fault localization to isolate the node on which the failure occurs. 5) REQ11 Just reads strange.... for example, an edge node may not be adjacent to a = failure therefore confining actions to edge nodes makes no sense. If the a= ctual intention is to include all consequent actions of OAM states, there w= ill be a few requirements that fall out of this. Something to discuss. There is also the imbedded assumption that transactions are both p2p and bi= -directional. I would like to see REQxx OAM probes may be unidirectional or bi-directional. REQxx+1 OAM probes must be able to instrument p2p, mp2p and p2mp paths. My 2 cents, hope it is useful. Dave -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: Friday, July 01, 2016 8:19 AM To: i-d-announce@ietf.org Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking of the= IETF. Title : OAM Requirements for Segment Routing Network Authors : Nagendra Kumar Carlos Pignataro Nobo Akiya Ruediger Geib Greg Mirsky Stephane Litkowski Filename : draft-ietf-spring-sr-oam-requirement-02.txt Pages : 7 Date : 2016-07-01 Abstract: This document describes a list of functional requirement for OAM in Segment Routing (SR) based network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-oam-requirement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-sr-oam-requirement-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Jul 7 07:45:49 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9212D7B4; Thu, 7 Jul 2016 07:45:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707144548.23670.62102.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 07:45:48 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:45:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Use-cases for Resiliency in SPRING Authors : Pierre Francois Clarence Filsfils Bruno Decraene Rob Shakir Filename : draft-ietf-spring-resiliency-use-cases-04.txt Pages : 9 Date : 2016-07-07 Abstract: This document describes the use cases for resiliency in SPRING networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cases-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 11:36:02 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1271712D129; Thu, 7 Jul 2016 11:35:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707183557.23721.8624.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 11:35:57 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 18:35:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-03.txt Pages : 25 Date : 2016-07-07 Abstract: This document defines a YANG data model ([RFC6020]) for segment routing ([I-D.ietf-spring-segment-routing]) configuration and operation. This YANG model is intended to be used on network elements to configure or operate segment routing. This document defines also generic containers that SHOULD be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 18:07:25 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4616212D5FC for ; Thu, 7 Jul 2016 18:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHIIGncZpfAX for ; Thu, 7 Jul 2016 18:07:19 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0055.outbound.protection.outlook.com [104.47.42.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3036212D0FD for ; Thu, 7 Jul 2016 18:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nQ6IgQKowtqFrHCD1OpxZy91000OLcSHAiarrz8V+Ok=; b=F/yMBFr3eJKRMWY+M3nR2IK72kJ8XMJSNItCfryLyphgmBnkP1jGR8VNjURBeGk8G3a635ih5teXjI/Rr/EmpEsmCT6CgdLwvBXIW+hKk1PkvF0qliDcpm4wmUaXT6iyMPG3LLHToU5v3mXPNj+2c80K91XjooQnBLdAzceRZ/o= Received: from DM2PR10CA0058.namprd10.prod.outlook.com (10.141.241.26) by CY1PR1001MB1130.namprd10.prod.outlook.com (10.165.2.26) with Microsoft SMTP Server (TLS) id 15.1.528.16; Fri, 8 Jul 2016 01:07:17 +0000 Received: from BL2FFO11FD050.protection.gbl (2a01:111:f400:7c09::115) by DM2PR10CA0058.outlook.office365.com (2a01:111:e400:2464::26) with Microsoft SMTP Server (TLS) id 15.1.539.14 via Frontend Transport; Fri, 8 Jul 2016 01:07:17 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.24) smtp.mailfrom=infinera.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.24 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.24; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.24) by BL2FFO11FD050.mail.protection.outlook.com (10.173.161.212) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Fri, 8 Jul 2016 01:07:16 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd2.infinera.com (10.100.103.229) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 7 Jul 2016 18:06:18 -0700 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Thu, 7 Jul 2016 18:06:17 -0700 From: Sanjoy Bardhan To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-bardhan-spring-poi-sr-oam-00.txt Thread-Index: AdHYtO3EaoWx8KAxR0KsuUO4txaBdg== Date: Fri, 8 Jul 2016 01:06:17 +0000 Message-ID: <6614e62fe35a44228eb802172c1f4455@sv-ex13-prd1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.24; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(377454003)(199003)(377424004)(53754006)(13464003)(189002)(108616004)(10400500002)(47776003)(92566002)(450100001)(50986999)(6806005)(7636002)(2906002)(110136002)(86362001)(54356999)(189998001)(107886002)(11100500001)(15650500001)(15975445007)(77096005)(2501003)(87936001)(2900100001)(3846002)(102836003)(33646002)(5640700001)(2351001)(50466002)(586003)(19580405001)(19580395003)(1730700003)(6116002)(8936002)(7696003)(246002)(7736002)(230783001)(16796002)(8676002)(5003600100003)(7846002)(356003)(305945005)(24736003)(23676002)(106466001)(53416004); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR1001MB1130; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail2.infinera.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD050; 1:4wATHK/BEGTkE1VcluUpJS9Qe/cszIfGGwC63r2Zp4OAPImbsEufLAQTTERY1DxYo5L3ZOUmOH+VbTVM/pB/8sdo6LLYXervBZb7kf8NtSc7ou/hiphck63kFsrsZB9mJ2MGJlS9Undp+5XGQMsi6BC8JX1iW4vhCiW9hJT3KJdLyWH7s7+evIT2rV4Oc7QKJ/UrQHfC/c5UK41kqILtNdJwzsr4cmRHiHKvB4c2Bw4ujZeQQFuaaUebtoB2nUU/IX1naHaBMB6xQRZVywGF8OTY3G+UI+4R9eQfNtXB7X5zw1WWkel8YT/MqhNGiBVL5ObtDmynmzMTh3WiqWz5EinLMHoIOEYIf64s5Zks+rXdYNx4Vu+IodVcE2QiM25N4BwnZfF6r7NW+GBzR5Hpm7EdU+/1EcPRgSzgnSG/4plJM7PmHQSDaX5XBQhNuiId+0WUygPJfwpKwu6lTqIaW/GthkVd06E6zVqrnOfabn1a8AdLg1/e4swPsSe7A54/fREW7RES/rMaIqTzaDs+KNm2sCbwf3GeQi2BalMa5Bo= X-MS-Office365-Filtering-Correlation-Id: 10eb0ed9-07ae-48ce-c462-08d3a6cc3486 X-Microsoft-Exchange-Diagnostics: 1; CY1PR1001MB1130; 2:m1R0SH31B2xbXgo40rrGQjrnXt2dQ5ltkEw+c+P1pAtYtiCAAXEvDmp4rZnpGCEEJOvOeuiAzkGNhOnMwVnQb1Z/mJoBQVfXsCkE8Kql3sAdEpgwi8stcHtetjy1EGjdNn+R+DM3TLu4aWP5GwPCvRABnP/touz9HV1hn9fUoeTb5Nk2EbER4tDcs8kkNgjK; 3:fPIl5eyLJROHQFaK1yG+ExF9Gw4q/mOymsO2EN2+qDLnXwrK+ZeZyhyPDdJ9kmW6xOvTysoTlu4UPLk17AqdmEEgetanmt5qpy028IfHSeBp7LUGd5+vSfw7uqP/f0NtmFuLUciao/lPK/IX+tAiog0oIh09VxLAVG70BC+h2D9qGBEIZNgVERpFQTWirvpjbVKJKmGz9YTvOtW+31K7Lje+BEOwsXsYLhee0q2oMAdVNS9BCQaoWoaDF2+TA6pxpHUBKfigq+1QO9ySuTO1Vg==; 25:oCpfTWQX0Tfr52HBy7TAZwslAqJ68CBIz7nZUj6a5OPo2hP7IwfxSOOWMUdWfJ7rj9k3OX7Sy7Eg4+NQdTbgszZaKotxEXEL/mVTwz4zrDLllnav1s7ycyrBDE43JNa4AXsbm+CLBU/+UQLIH3Wssi7jIZV25B7WfAp/kjX7qlABSwBAJppRjyq3xU42+frkw2QF73gWPrebMH7svntGeBkLPbiPyNOdw/NWva6T6QsnYRQU17HFlZcMkfXA79rP5MFJoHKOivf8hVy3t2FjLRzlcZkeWK0ObU9zC7z/KRAZxkVECd6uMn8V7vJLjUxiSFFU8CeOlH/nGuuOIdXKYQhgUAYrNbb1ftYoayMKdLbOyNnVXEaVn3QwFTTVetxEArYRFGMDacZg4V9M95LVxGvUXQbibhL4b/3xlzNGFLQ= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CY1PR1001MB1130; X-Microsoft-Exchange-Diagnostics: 1; CY1PR1001MB1130; 31:eiJUtyipH3cxw4JQ+71MezrZpNIUGguzh+9HLq8zL4PknjM9WE7+KdN/5jkea3KlruT5MuGsWqwSo7rdkNvEGgIwKC+TN6ghg3V9o++CD0wTAn8bvooIG17rxCVCXEJ3S8NYSqmqJuZ6KOhtE/TiJzGupU0Chq7HQ/g9h4Lrcb/hQrPlH4ePFcuSOp9zQaAOzDGp79fbNmcxpeDr8lmhkw==; 4:aXFwdJiTBq2ibqXHlEiltjoJVURfIqUua1AmKVnIL6qXHtkYq/lg2BluirwZLvEricwMxSR8roaOONnueY36blwdfoWtmbo7iDVuCG0+roCf95MdYxzGnVrJ5/GudWajnU8HI37oa3wxKvsGtYTKWGAaTiKxeEi58bmm7FzvIWrLYnYEaFwFFsRZqas8RAVZmUV2SLUG/LaqMm//F8w6DegNzkjG3hCi4TbkRSDWs8UR09n4Q/r1r65HS7GlTWfsUvKqolOtt8bJ7or4RmCnWOunQdymHtIKFFvr6n5we3YKVYZIlm2NPvMMY7HAJHeKvtgQpWpfqbruEw7e32KTMFLpZaYsUexDv9Lgcyn9u6Fe9TH1HEiasK3BVXg0PpaZTXj4HFO4g19X6TsaSB9+KZ/m8KMa6vJNoiQofPl9ixEB+ikoIYQPg4Qpo6einBrgBW1XO9Gr2RCs9875Pp4GnMdurzrMZHtSSjdY9TGuhjkeVz6GyXtLJT+ZE0mEAriB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13015025)(13018025)(5005006)(8121501046)(13024025)(13023025)(13017025)(3002001)(10201501046); SRVR:CY1PR1001MB1130; BCL:0; PCL:0; RULEID:; SRVR:CY1PR1001MB1130; X-Forefront-PRVS: 0997523C40 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjEwMDFNQjExMzA7MjM6aFRzcEFvajZ1MWZrUFA0bWl0Rm1vV0dW?= =?utf-8?B?SlJlcEVEWmdEL3VOTXgrZXluRGwvRXhmazlIcURuYVF1bTNPV2kyWUVIQUo5?= =?utf-8?B?QW1CZTAzVDUvYlgxUDBUVGNqUnRhd01TeGd0WERLekQ2ODAzOGZGVUJnQ0xt?= =?utf-8?B?Y0ltUklHZ1ovVlJPczhXZm1xUEN4Tm4wT244bTlwRWRxa0V0TDc1MllUZ0kw?= =?utf-8?B?b05MbHZNZGVGc0J0VzBhdHZCNUVlcnltY1BObEphSUVGMFZWOEQ3bjVVaXJt?= =?utf-8?B?TngvclB2SUtTU3RtTFBqOTlsYW00NU5nWEtudHRQcWhxenE1endWL2RSWmlr?= =?utf-8?B?eVJzaVlpdENtUXIvVG5qS2gxQU1DSUVTNGFlcUxZcEFDd0lSNzRoTFhzN2Q3?= =?utf-8?B?ME1XSDNLWDNRSVZUemNqYkRoTStKOXlUM2tRK3c4bHc2MncxR1duQ096M1NM?= =?utf-8?B?dFhaZ1pCeGlia1cvOXE5dmNLUVBKN2s3ajltNW9uRjlqVGt4MldvZ1RvYVd2?= =?utf-8?B?ODBJcXQ5bHg3MDBPY1lmSUJ6RXE3aTVNemtsdGo1MWp4NXpqWUZzcklTQzVj?= =?utf-8?B?R0dqSGNmb2xVbzRtK21TeFV2UUlxVUFjTUtHd2M1KzRrWU9DdE5nYkp4b2hE?= =?utf-8?B?Tzh3UmQxdmpicTdWRUtJcFFQYWJTSW9lZWhwNXFjOVY0RG8vTUR6aGUyWXdY?= =?utf-8?B?c0hHdlBRZmdXWmN6OXYwOHRPS050U1N4b2poc3VDeWFteWhHMkxxT2EyVlAv?= =?utf-8?B?NmxraWcxbURzclFROWdwckZRcEpPenJVNmNXamNkeEVXRG1UbmptMUZ3emVw?= =?utf-8?B?VWEyanJ0bkhCTTRNaU5YSWJvT2NyS2tCajE3UlRjbU5OanFCSzc2WDVxcHNq?= =?utf-8?B?S29HdlNSWU8rZ2FVS3dLMlJ6bVhJTmdLMmVhNFczTCtUSEhwc3hHd1NFV0wz?= =?utf-8?B?bnU3VHJBUmxQV2Z0ZlRCckpHZTZ3WXRqbWJhZWNGTlcvY0t6dVpOY3JmaDFU?= =?utf-8?B?aHQwaXpOQTFIVWc5elNmTEtNTmlmaW9neVQ4MVJtTU9LMVlIb2gzR1dCalZF?= =?utf-8?B?dVdLTmZZTTRROWtVOXVLeTZ4WVByL01rVlBVdmhSUjVNKzBRelJVc2VEMVNQ?= =?utf-8?B?Qld5T2g5Ni8rVjJRQjQ3elRuZkZYVDdmNXl4MjRwRE1CNFVHN3k3MkxXQzRu?= =?utf-8?B?TUo0V1NqZ2N3ZFRRT1AzRllaV2YvYzRETER6Y0R5Y1Q2NTdJOERwN1dCcjdT?= =?utf-8?B?ODRDQmhpZUZ5Ti96b2VFVmRYYTFCeFdqbjYrRUFhanJBd2dKZ3VldnNqcytQ?= =?utf-8?B?QlhJSmZjSkNMTHc4NXdEKzFlQmJmTjlwZ2lpL0tTQWc4aCtvMmQvWndiYlhw?= =?utf-8?B?d1NwdFU5T1FKak8xcFg3T3gyR1BoY2lKUlhjT2pzM1JoNVRJSGQxK0o2enlq?= =?utf-8?B?dmpoVHc1blB2NFBYUGdqK0N1VFBSUkdqRmFQSVFLdFBwaENaRmRjWFN3bjdj?= =?utf-8?B?Y3RnYXVXU0lkZ01kQ0dSaTF5NWJkeWZXMkFkRGdHZHlUdkxrTGo0TjQySUFa?= =?utf-8?B?V1prcmpYZ2RJcXAvcGRob2FURDZxT1VEOVJyTjdYaHFHVWxPVldHZUZLRUdJ?= =?utf-8?B?ajFWaFVaTGF2OVR0ejFMVnJVUHNBV0lkYlc0OTRJWXJJdVk2b3JuMmVGeEZu?= =?utf-8?B?MWRsSXNuQTVrcWl5Z21ndWN0TlowWGYrNjcxVEI5d1NNVW5IYXdpYWFuSE81?= =?utf-8?B?NGlLVTRHVWlna1lWQWNZUlo2MDdQc3llY2FEa25WcjllUkRBR2VTR1FyOGR4?= =?utf-8?B?d1RralEzS0ZQbmVpQkFjbG56Zys3L2d5R3htNVFUTkFRODc1UEpaMXNNVW04?= =?utf-8?Q?7GxQOx+TMhAIanMkLjxHYOwDesdqjTGbYC?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR1001MB1130; 6:9iptkdjPumm7lwlSqgLSqn65C6vEyMPzMVOKjqNZ4wDM9hVv59WCeOYEg+Qg1BIg7sf8DSVH/PgysXVrz5rRZfS1VGV+tLHqanZQaggHbYoiO3Qg4bsnGxDac4UB6u+UxEcPAotMoni6NDh4mAvVfRDh133NHVqchY3/thikuvmWjBxtuGdq2SA5wNO+oyHld9O7Lj+fupIMNonlOxSNiPfo1VZKYYgEbOOa6/FmXW2KZTyleSy6u4NrDfbkv+FRqtG+upAT3IpbYeRqYjYiURc4kGWKHvRt1NB4XugkZjo=; 5:52xL4Se/9wyEHdGUVD3vkuOUG1S44BsDYE0Ucm+RGjDlrfKRaLFMISkrZtqTjNBGbgxMrH6rjJrUnvSmp2F9mGHFch8yLrUI81qjiUlOYc1hv+vVG8frUN7zipktXQp3NqyjxOU+uvm74juzUUJVCQ==; 24:bIajUV/Xe5KpE2dLX+Hm1oyfi7MZTaEELQ3pzAYaxoDp801ugXo0cyPXrMuhFFst3jIjAD+MDm/bNh5mfPa7KFBZivZ6wVra2mNkyPxRQdk=; 7:HbxR0HGJ4bzLpQIyDr0uOORRq+03P+jfL60YDrtXK4Wop03d6fpoHK5dPhK1xxSLZFoffTrkTU1vFhaGOqvfn0YJDgphyNh2qa2f5HCk5zF3P/p8tv4/Ib8VTt08BgjbFsQtcdsHMdhNjF39N5yPXbidKKCXEIzOd+L6hNNxI54ox4E2cRxVUnWxHbr5gq8Ii+RoX9OSVHlkOYzaHNPifkdMhSHuVTlA9YPt7ZHtZLjRALZPlEKyAtW+L+YqSrmX SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2016 01:07:16.9634 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.24]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR1001MB1130 Archived-At: Subject: [spring] FW: New Version Notification for draft-bardhan-spring-poi-sr-oam-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 01:07:23 -0000 SGkgYWxsLA0KVGhlIGZvbGxvd2luZyBkcmFmdCBkZXNjcmliZXMgYSBsaXN0IG9mIGZ1bmN0aW9u YWwgcmVxdWlyZW1lbnRzIGZvciAgIHRyYW5zcG9ydCBzZWdtZW50IE9BTSBpbiBTZWdtZW50IFJv dXRpbmcgKFNSKSBiYXNlZCBuZXR3b3Jrcy4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1iYXJkaGFuLXNwcmluZy1wb2ktc3Itb2FtLTAwLnR4dA0KUGxlYXNlIHJl dmlldyBhbmQgbGV0IHVzIGtub3cgb2YgYW55IGNvbW1lbnRzLsKgDQpCZXN0IHJlZ2FyZHMsDQpT YW5qb3ksIE1hZGh1a2FyLCBSYW1lc2ggYW5kIEplZmYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBKdWx5IDA3LCAyMDE2IDY6MDEgUE0N ClRvOiBSYW1lc2ggU3VicmFobWFuaWFtIDxSU3VicmFobWFuaWFtQGluZmluZXJhLmNvbT47IEpl ZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgTWFkaHVrYXIgQW5hbmQgPE1B bmFuZEBpbmZpbmVyYS5jb20+OyBTYW5qb3kgQmFyZGhhbiA8c2JhcmRoYW5AaW5maW5lcmEuY29t Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iYXJkaGFuLXNw cmluZy1wb2ktc3Itb2FtLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1i YXJkaGFuLXNwcmluZy1wb2ktc3Itb2FtLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBTYW5qb3kgQmFyZGhhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCk5hbWU6CQlkcmFmdC1iYXJkaGFuLXNwcmluZy1wb2ktc3Itb2FtDQpSZXZpc2lvbjoJ MDANClRpdGxlOgkJT0FNIGZvciBQYWNrZXQtT3B0aWNhbCBJbnRlZ3JhdGlvbiBpbiBTZWdtZW50 IFJvdXRpbmcNCkRvY3VtZW50IGRhdGU6CTIwMTYtMDctMDcNCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmFyZGhhbi1zcHJpbmctcG9pLXNyLW9hbS0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i YXJkaGFuLXNwcmluZy1wb2ktc3Itb2FtLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1iYXJkaGFuLXNwcmluZy1wb2ktc3Itb2FtLTAwDQoNCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGxpc3Qgb2YgZnVuY3Rpb25hbCBy ZXF1aXJlbWVudHMgZm9yDQogICB0cmFuc3BvcnQgc2VnbWVudCBPQU0gaW4gU2VnbWVudCBSb3V0 aW5nIChTUikgYmFzZWQgbmV0d29ya3MuDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From nobody Thu Jul 7 18:09:01 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDDC12D12B for ; Thu, 7 Jul 2016 18:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LlqczWMrTgO for ; Thu, 7 Jul 2016 18:08:56 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0083.outbound.protection.outlook.com [104.47.38.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB7F12D126 for ; Thu, 7 Jul 2016 18:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Llettopd4/c5wkD9Lq3zh5SoprBzatSZJsVjabQ48GU=; b=y+D6FtpH1ZqEY9VFphpQz8LrCoEljspk3F2802jR56t7Jx165J0NHH+sjsCS+LmEYzkpx/2JRWgDDNg+O2l4IACnlI9c6QGJmzhGKzdU1hCleWpzCWKEZRL8g1d6/2jwZV+LeQkmxqjqRx9x9qYEigb3YtrgG6bCjLnpWVPHTVA= Received: from DM2PR10CA0011.namprd10.prod.outlook.com (10.160.213.21) by DM3PR1001MB1136.namprd10.prod.outlook.com (10.164.195.134) with Microsoft SMTP Server (TLS) id 15.1.539.14; Fri, 8 Jul 2016 01:08:54 +0000 Received: from BL2FFO11OLC009.protection.gbl (2a01:111:f400:7c09::129) by DM2PR10CA0011.outlook.office365.com (2a01:111:e400:5014::21) with Microsoft SMTP Server (TLS) id 15.1.534.14 via Frontend Transport; Fri, 8 Jul 2016 01:08:54 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by BL2FFO11OLC009.mail.protection.outlook.com (10.173.160.145) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Fri, 8 Jul 2016 01:08:53 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 7 Jul 2016 18:07:55 -0700 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Thu, 7 Jul 2016 18:07:55 -0700 From: Madhukar Anand To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-anand-spring-poi-sr-01.txt Thread-Index: AQHR2LAYEfMGRmDec0eeHhOMRwXnTqANt55A Date: Fri, 8 Jul 2016 01:07:54 +0000 Message-ID: <0b8fd3ce74bd48b98ba3570ab4f0ac39@sv-ex13-prd1.infinera.com> References: <20160708003236.18789.67079.idtracker@ietfa.amsl.com> In-Reply-To: <20160708003236.18789.67079.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(199003)(377424004)(377454003)(13464003)(53754006)(189002)(6806005)(2351001)(2906002)(189998001)(1730700003)(8676002)(2900100001)(2950100001)(47776003)(246002)(19580395003)(19580405001)(16796002)(50466002)(77096005)(92566002)(15975445007)(87936001)(6116002)(102836003)(53416004)(3846002)(11100500001)(110136002)(107886002)(586003)(23676002)(8936002)(5003600100003)(86362001)(80792005)(54356999)(450100001)(76176999)(50986999)(305945005)(33646002)(230783001)(2501003)(5640700001)(356003)(7736002)(106466001)(108616004)(10400500002)(106116001)(7636002)(7846002)(7696003)(24736003)(15650500001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM3PR1001MB1136; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail1.infinera.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC009; 1:GprDQhRA9SVFf04OvNiEQ8APe2tWHZSEQXos3pF8zClUIjp2R8oEfwzgoUbZVwX0TarynvXa0nK2wueadjqJ89UojQlHPTb1q7CayaEniVdWrjVquZ8MJMqj7vUIhiRYWsCWA1mkCiUXClF81aX458fdhDPEtRHFTz29fqMBHm+CIkYM5++QZl0GTEeF5bzTImX90cUNDujn+hOZgvtUewYV8PAmTubYr53etyoPe/5eBAHNqTH3E+WzewQaTNUM7DhrLKN4wXE1JbhLCwHF7SP2Yy9ueU7VpLu0AcfriNttCXGcNLmqtMxafn86q8nSG30CixhfPt+FbTW+MOgizGg9ur4gTJq4mpvX7qK8hewEVc0+EjjL4wbJhd7RFcmpkTUqCljJeaMwgoOe4DkfJQaO6x5B46CJ62Mqo0QnD9cfMcb06PdE5ihkm0UQxLEI1JncWGp4dBtsgAbY7+ev2Po5C1vQjykHhFjD96KQjS9D1xaJOAoyj91bn02J/6aq6BAOZZAZY29d/bbBa09X58O3spHtgQaxLW9OFJb/bII= X-MS-Office365-Filtering-Correlation-Id: dc1e3ddd-9710-4c9b-0c24-08d3a6cc6e24 X-Microsoft-Exchange-Diagnostics: 1; DM3PR1001MB1136; 2:5sGY9KXWGbQPAj3gmcuhfeoFjyhCJnaKyj/dtWp2FFaIWYyac1Oi+DAhB5sOrbDpW0Twyps9AbnKuQMTjB5LbPawChedrKksKzyNvhu5g3+6CA43GxdrA4tVALhqJFIy2ueDiRATzSZzyDILD5BaSdPBmdUXOJSE7tWU5mr1UiwDP8VgszREHVwLvHWBmXCZ; 3:V+CDj1dxZszU2LWAoGK0p2OGmEw1WGq1mfrDyA6OCGGPMCjCfgWEe2GZDlZVhHdZd62g8gVHN4aOSJHP/RBFTF1bXxFf7P07xtzEtp4iDtmnIs/D/mZ5e8x0L7+hEn0U/10w7T70xo+mtxjqzy8lNQwXqUVefOL4bqZQB0OIhNhGDVNf07RT1X9ufI0P/fzcYEdgAgYwQlEdBRnIlKSMBrUYCWO167L567yVICpw/jDtkJK5vuGJmvG74S65c2WmXxgDTmKzTAFNDr4sqdChTA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:DM3PR1001MB1136; X-Microsoft-Exchange-Diagnostics: 1; DM3PR1001MB1136; 25:ZiiuRIelrU29HecUl723KvgWp2/NLmRy7a1mnsXeeSpC6IMjmSqxhMxcTuji5Gtvc2ZBGrWfH5dcZJdYabR09ONnSNPhiZtr3k20wwxMm3aG0wWUqNxEER9jV6DLVbkCX9vQEfZNY1bD7YWNpr8uK5Jw7QEkUKFwXliW+3abhoeT0ucD+bZ0W+FGOYm9flyJCb1qI/sELa6YrDX4ug7dpVnbr90Zk/m1xSrGcUuAbHjay9/Kx4ra1/PG6CE086PzVsIK655B3Dzo8nQj6iO6UhMcweET9V42tXye8nQ5cXKqgoG0mfxbsQC8SGxvw6/TOIfVhkijmR12aqFCYdfGQUiHPM/e7HUfp9BRL3zVe67fTdw6Za5+YnIiV8AC6kog9GSaYDeglwuRrPfiDNOHyeG0atoLtny3oALL+A4Xeew5sqLF49xabSKTX61uYutLZ6Jtw0Q5gGP2ljQ9B8nUYGfW7Osg3Xj44+g4nld1R0F475Sgk8K2ILvospkzn9Z5y/yN5/rOObgxMeL4SmU4RtiC9TX+1u0bA8+0BNF6Hk4qz8Vibkfc06zTFaVgBUuNXZlEgGYyVodIqg2wK0puMez6fNEKwWO3hYPHNo6I9EhwMqmYt0OHZ27YBglr6zkSmijBfhqDGgCFVFu9fxbn/XcJowe7jCOFEzLsL8DPkAua1e7/z70D7mB707n1mOSyPp7NtBNiwnNKcq4Q0gfwxTyVrMHKaAFAT0YV5VMMM1u6T0ctAVYXzSQ/1J8GPxPb4nt0HXsk/1w2AC62qfXTH1LglptHWfGRQWZvjUYGlrBM5OKTNlMHlpgZfXHK3OLkfWzOwjcf8YGAbYAJO6k7ls5uUxaqp+Et1YL+GaYK+Se6OcKALqdObSfVavzsYPP2++UAtYdglNFx1jQDAKDg4g== X-Microsoft-Exchange-Diagnostics: 1; DM3PR1001MB1136; 31:ZkwnzkinW1RkygB/9ZmWHh8SYSHkJ2jK7dgBk7cDTCzBQpVeP0TLyKmTN1aa9HI0E+wDmZy3ecG9GTZQj2fPdrFEHkGzhO1pqSHBAw4jPI0s2Jgjey/ETAchOnq5PCZhk8dm4Cpb8qCl6Fbeh5R6+VmNTfcpYkje/Nyg5nyqAZ8fEHRzhRxqs/X61K17MQDHyh8az2u7Zi7duPgPmFJiKQ==; 4:oox7gg+LeI8TKZ/UMFrnDNHIMibeTionHMJowetQyLK98qULCNSHgtb03SU2V+bsbodgntlXCqQ8LLywF9hto1mEwjMSPhVQIz1Asa4z4cEv7l2vfcSqHu4whnibI32HMfh6cNvMq/w6lhqOBTz/0/9rQsDPuk2b+biLhBkBw1RUQ3R+FQaYYcXTbNyYYsY5Qb4nJBFHEqZgQ4+JfIJNvk0DFskX4ZSZc/1yqLXhn8Z6heSq92MxO/7P7X/ZxTE3Xkk/cGxHUO24r1ZQ62lX85ZhDOax8jR3UbqOVTvp2osF/EeEj20u4D4+lKG/QRI7LfU+nWonNPvGHOIHXVIUVIBSkFxWMj+xPQSgt3HJISYrhZObudCi4VHKbyiyt3EC6+7/MhX4IYW3As/KhR3/2t0kFBA4hqZGrXSmGb2kacFkX7G6Bs2jqz8yvchBymmPxppkPX/WTybG0xp6022sPvFX4Uub7G/qx5WpQsFBwDzseNKmI7CAcC54KdnYZE0X X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13024025)(13023025)(13017025)(13015025)(13018025)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM3PR1001MB1136; BCL:0; PCL:0; RULEID:; SRVR:DM3PR1001MB1136; X-Forefront-PRVS: 0997523C40 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTNQUjEwMDFNQjExMzY7MjM6SjFhYmpwT05Jc1FCUUVPcnVaYm5haXZP?= =?utf-8?B?MlkrMEJwU1YyTUVJeCtNOEc3MDNiQzRjSytZK1lBeXlqbm5Td2dCeHRrRmI3?= =?utf-8?B?a0J2ZlI2VkRjQ2ZJYjFiaHBEMVEzRzk2QXlaWVEvOHRHTThYNWdpR3puV0I1?= =?utf-8?B?VXlVS0JBem9qVVZXbFlGYkx1TkI2UWswZFBkYWd4OURkTVBRMkRFQlpWOG8z?= =?utf-8?B?VVFTUnJjTlRDL2gzckZ3clhSWDQvL2VKWU9hOUs0R29aWFFiUXRCc2xUNUU2?= =?utf-8?B?MWxFbjdTdndUeHQzL1cxNmFBbWxiU3lTcGdnWkw1S1Jxam1ZOU9CR1Z4UGk3?= =?utf-8?B?Q01SSkhzZVM5UXE3b3ZON0pUSjNMb0hoMTF0ZVM2UTdvMVpxQzBIb214T1Zy?= =?utf-8?B?aFR2b0xuajd1NGRoNVBEVE5qTHlIaTNaem4wajNyaVkzbDV6Tnkwb2d6cHA5?= =?utf-8?B?aEZKY1NsOEJOeWZCSWZFcGt0S3JhU3dpZlJtMTFrcHFVTzQ0SDdobmd3ejdV?= =?utf-8?B?QnVxOFV3TCtzYlRVNWdMd1h5SllUWXNhSVQwWlYwWkNkZEJCSFZIWHo5UGpq?= =?utf-8?B?QU5sUG0zdGJYZ3B3Wmtqcy9VWTNUMVRwL0ZQM1VqanQ0S1FkMnR4QUtncTBC?= =?utf-8?B?RHFkSXhETUNFUVQ5T2FDc1FVYzN0UWN4Y1JXVS8wYk1YcmRjd1hxd3VFRXNX?= =?utf-8?B?aW14QjdmSXpBdjJTMW82UUtwcWRDWk5UTjZyQkxNMXVRNERqdms1V1VSbXR5?= =?utf-8?B?Ym9ScE5KQ3d5ak1BSjFiKzN0K2hPRk5WQnE3UGV4WFFvaGQwRmpsOGU5QUwr?= =?utf-8?B?clY4amtTbDUrYnhyUGdMSG4rSUVlSG13bmIvWlZsNUVtaytXWUc2SzNNQjR3?= =?utf-8?B?VEg2cEVaNTJRSkQ2MmtRdmYyOXRCT2FaQWNEMWZPREN6SmhLaUlWc1psL2dT?= =?utf-8?B?OTRRNFprZ3pwVDJnVmlVd2t1aFpRNGlhNTNlSWpYTXR3ZnVqNk9Ud1UvUkNG?= =?utf-8?B?WjllZCtZV2JIVnBOSVhwRjBlUGpwRHV5dkdBanJhS21uR2RzNTNJbnY1N0pM?= =?utf-8?B?aDRER09FUDZTZUNvaCtpOFlhVDBhU1R4TStzRVpkVjFtRnBsNEIwV3A0STd3?= =?utf-8?B?dHFlSXZwckFMVExtd04xcEY0U3BYYnBmbTAxQk85RVpoejhnZFJTaFRtR3dB?= =?utf-8?B?QjJRUFNmVkp4MEpMdmZDNUQ3N1RZcTFJT0dvd3FrcUF2SktKb0hVWGlTSjlj?= =?utf-8?B?UnpVTHlNUWM3dFZWWmZmakpKNWMwYUxXZnBYZHYrYmFCTjhPK0VyK2F1MkRw?= =?utf-8?B?ZTZKTmY0eHpYdVVReVQ3bExJUGpQNEZOM04xb1lWNkNjaEd2NlNpY1R5MWh5?= =?utf-8?B?b0h5OTlTbHNTYkFFaGNLcHBiSzhGMmVuTnVkNjNFTmYvVHpkeFozblV2WW53?= =?utf-8?B?WWVpZ0VNQ0VheEVqK2M1RWxNVnMzZHdkY29ENGtPNVJlVWRoQU9oZVg3aW82?= =?utf-8?B?bUtmWHBnWWZSMDV0K29nbnJud1U0ems4anlwL29BMHB3czZRVGozakd5TzUw?= =?utf-8?B?NjFLY05mTU9JZlBHN0Nwd2Z4SzVRVUVNTDZXTk1rT09aTHVUbkdvNzg1VStt?= =?utf-8?B?K1RpTU1XNmFUMVZkNldyQ09EMlNCNm1LR2dUOUgwa3htTUlsYXVYdEx5b2dI?= =?utf-8?B?K3p5Q1JibEx3OGhjUVRqeFo5dnVRVTlsT0lzZHFRaXF5RUI4OTdJeUc5dFo4?= =?utf-8?B?VGFmS1hYQjBrUmZHQ0RLUDhFL0tya293VCs0Qlhya0t4a0MvU2dndU5iVXBy?= =?utf-8?B?SFoxSUlxWVJJL1lZWG5GSzBsd2l1QzAzR0FoME5sTFZBbW15Y1BSZUxDOWtD?= =?utf-8?B?M21tbDY1WmpVbWdlc3pYOEwxcHVDYzJmUFpNNEl5cnozVWVSN1hIbTFkdHox?= =?utf-8?B?elI3ai9rMEtVTHhsb3hPUnF2YnpOYlhoR0FrR29YWGVVd1VQTGpjdkhkZFgy?= =?utf-8?B?djl3RVdOVVNoNzBjTU1vNitPN3BuZnp6d21KOWl3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; DM3PR1001MB1136; 6:th4B3iVb6l4tPf8S8ta5nmCzDELTZTPrzTVjMcqCqt51Kn3QI+eghJAffWvarNsGo+aLKXUmq4bm+o/TQAjuvifpLs/ag78oinKEFUtdJ+b0JaQIUtyEv8wfDwFk2V2UZ5BDHkqR2sMbziupCqLudSsNpwt+m1TM18RRAzD41Kx+Ix6RLeCytI9xplT6a479ygMTHaBmXN9tL/6t8WzO8MkreHtMX17HFNJiSHIYSmxyahAHhjZOYdL/Hu8eEAreLHyj13ufUa1UVfPH5BR0AdP4RwUyQrqG9vG+pBC/qQY=; 5:KO9bp51dGGi2cZjd/ecgjgUdOPPsvuvkA6M0DKTDfQf1USIv+ZyasrPMuANZqFoFLZRA/sYmGV7bNxgXcaJ85eLNd/oYUJfxNcFk9roKEzs+SaM07aNhLEvywWzsdh+CtNQW2+aFQsNAnxZSgLMeeA==; 24:cUBcCA0Fs4hlFPw1dmyA14Emb6lb5YooNKFoX5I/XdG+YoZK6VxJRIrtA+xjsl8OlQXF3tdqfDTm1D5z/SyjuwcQE5/phEJS2HcphYThA4A=; 7:3RzM0OlwoVgoCQAt+NfMK+x4Ml7+LKJepM8KIZgj+MK7g8XAN+9ZnENSm+4I/f8oMsjaq+ejqQdh5Kchih3lywGMMY8S4I7ayaN9K4yF4aFC62EkOxnW6Kj4bbwYYIGLVeLG+GTWCoGADzyyKDHH26pp8lNN+Cjo0taU3oZN7/+GUqt/3+Sa11WMsGI85ucA5+ys+aynrpvZO1Rbccdi7ntjwQbCYpFsAzZMNaIebVSWopcUfP29BxHoRW8znn6V SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2016 01:08:53.8895 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR1001MB1136 Archived-At: Subject: [spring] FW: New Version Notification for draft-anand-spring-poi-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 01:08:58 -0000 SGkgQWxsLA0KDQpUaGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFuIHVwZGF0ZSB0byB0aGUgdHJhbnNw b3J0IHNlZ21lbnQgZHJhZnQgKHZlcnNpb24gMDApIHdlIHByZXNlbnRlZCAgYXQgSUVURjk1LiBX ZSBoYXZlIGluY29ycG9yYXRlZCB0aGUgZmVlZGJhY2sgcmVjZWl2ZWQsIHByaW1hcmlseSB0aGUg dXNlIG9mIEJpbmRpbmcgU0lEcyBpbiB0aGUgZGVzY3JpcHRpb24gb2YgdHJhbnNwb3J0IHNlZ21l bnQuIA0KDQpQbGVhc2UgcmV2aWV3IGFuZCBsZXQgdXMga25vdyBvZiBhbnkgY29tbWVudHMuIA0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFuYW5kLXNwcmluZy1w b2ktc3ItMDEudHh0DQoNCkJlc3QgcmVnYXJkcywNCk1hZGh1a2FyLCBTYW5qb3ksIFJhbWVzaCBh bmQgSmVmZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDog VGh1cnNkYXksIEp1bHkgMDcsIDIwMTYgNTozMyBQTQ0KVG86IEplZmYgVGFudHN1cmEgPGplZmZ0 YW50LmlldGZAZ21haWwuY29tPjsgTWFkaHVrYXIgQW5hbmQgPE1BbmFuZEBpbmZpbmVyYS5jb20+ OyBTYW5qb3kgQmFyZGhhbiA8c2JhcmRoYW5AaW5maW5lcmEuY29tPg0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbmFuZC1zcHJpbmctcG9pLXNyLTAxLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hbmFuZC1zcHJpbmctcG9pLXNyLTAxLnR4 dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1hZGh1a2FyIEFuYW5kIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWFuYW5kLXNwcmlu Zy1wb2ktc3INClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlQYWNrZXQtT3B0aWNhbCBJbnRlZ3JhdGlv biBpbiBTZWdtZW50IFJvdXRpbmcNCkRvY3VtZW50IGRhdGU6CTIwMTYtMDctMDYNCkdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE4DQpVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFuYW5kLXNwcmluZy1wb2ktc3It MDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYW5hbmQtc3ByaW5nLXBvaS1zci8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYW5hbmQtc3ByaW5nLXBvaS1zci0wMQ0KRGlmZjogICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1hbmFuZC1zcHJpbmct cG9pLXNyLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBpbGx1c3RyYXRlcyBhIHdh eSB0byBpbnRlZ3JhdGUgYSBuZXcgY2xhc3Mgb2Ygbm9kZXMgYW5kDQogICBsaW5rcyBpbiBzZWdt ZW50IHJvdXRpbmcgdG8gcmVwcmVzZW50IHRyYW5zcG9ydCBuZXR3b3JrcyBpbiBhbiBvcGFxdWUN CiAgIHdheSBpbnRvIHRoZSBzZWdtZW50IHJvdXRpbmcgZG9tYWluLiAgQW4gaW5zdGFuY2Ugb2Yg dGhpcyBjbGFzcyB3b3VsZA0KICAgYmUgb3B0aWNhbCBuZXR3b3JrcyB0aGF0IGFyZSB0eXBpY2Fs bHkgdHJhbnNwb3J0IGNlbnRyaWMuICBJbiB0aGUgSVANCiAgIGNlbnRyaWMgbmV0d29yaywgdGhp cyB3aWxsIGhlbHAgaW4gZGVmaW5pbmcgYSBjb21tb24gY29udHJvbCBwcm90b2NvbA0KICAgZm9y IHBhY2tldCBvcHRpY2FsIGludGVncmF0aW9uIHRoYXQgd2lsbCBpbmNsdWRlIG9wdGljYWwgcGF0 aHMgYXMNCiAgICd0cmFuc3BvcnQgc2VnbWVudHMnIG9yIHN1Yi1wYXRocyBhcyBhbiBhdWdtZW50 YXRpb24gdG8gdGhlIGRlZmluZWQNCiAgIGV4dGVuc2lvbnMgb2Ygc2VnbWVudCByb3V0aW5nLiBU aGUgdHJhbnNwb3J0IHNlZ21lbnQgb3B0aW9uIGFsc28NCiAgIGRlZmluZXMgYSBnZW5lcmFsIG1l Y2hhbmlzbSB0byBhbGxvdyBmb3IgZnV0dXJlIGV4dGVuc2liaWxpdHkgb2YNCiAgIHNlZ21lbnQg cm91dGluZyBpbnRvIG5vbi1wYWNrZXQgZG9tYWlucy4NCg0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg== From nobody Fri Jul 8 01:03:57 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D8C12D537 for ; Fri, 8 Jul 2016 01:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfJV86VxLbKT for ; Fri, 8 Jul 2016 01:03:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93CC12D513 for ; Fri, 8 Jul 2016 01:03:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id F06D418CA2B for ; Fri, 8 Jul 2016 10:03:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D417835C090 for ; Fri, 8 Jul 2016 10:03:51 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0301.000; Fri, 8 Jul 2016 10:03:51 +0200 From: To: "spring@ietf.org" Thread-Topic: IETF Hackathon and Codesprint webpage and poster Thread-Index: AQHR2Gs+eM6/YkLDWUC9Y4KB1nO4JaAOLNgA Date: Fri, 8 Jul 2016 08:03:50 +0000 Message-ID: <11610_1467965031_577F5E67_11610_271_1_53C29892C857584299CBF5D05346208A0F9427D0@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <2CCFAF9F-DC7C-417B-9E68-04DD1B49AB51@isoc.org> In-Reply-To: <2CCFAF9F-DC7C-417B-9E68-04DD1B49AB51@isoc.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Subject: [spring] FW: IETF Hackathon and Codesprint webpage and poster X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:03:56 -0000 RllJLCBzb21lIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gSUVURiA5NiBIYWNrYXRob24NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdHQ2hhaXJzIFttYWlsdG86d2djaGFpcnMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcgV29vZA0KU2VudDogVGh1cnNkYXks IEp1bHkgMDcsIDIwMTYgNjowNCBQTQ0KVG86IHdnY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBJ RVRGIEhhY2thdGhvbiBhbmQgQ29kZXNwcmludCB3ZWJwYWdlIGFuZCBwb3N0ZXINCg0KSGVsbG8s DQoNCkF0IEJlbm9pdCBDbGFpc2UncyBzdWdnZXN0aW9uLCBJIHdhbnRlZCB0byBzaGFyZSB3aXRo IHlvdSBhIHdlYiBwYWdlIGFuZCBwb3N0ZXIgKGF2YWlsYWJsZSB2aWEgdGhlIHdlYnBhZ2UpIGNy ZWF0ZWQgdG8gcHJvbW90ZSB0aGUgSUVURiBIYWNrYXRob24gcGFydGljaXBhdGlvbiBpbiBCZXJs aW46DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3J1bm5pbmdjb2RlLw0KDQpXZSBhcmUgYWltaW5n IHRvIGVuY291cmFnZSBwYXJ0aWNpcGF0aW9uIGJ5IGZvbGtzIHdobyBhcmVu4oCZdCBhbHJlYWR5 IElFVEYgcGFydGljaXBhbnRzLCBzdWNoIGFzIHVuaXZlcnNpdHkgc3R1ZGVudHMsIGFuZCB3aG8g bWlnaHQgYmUgaW4gdGhlIGFyZWEgYW5kIGludGVyZXN0ZWQgaW4gY29kaW5nLg0KDQpQbGVhc2Ug cGFzcyB0aGUgbGluayBhbG9uZyB0byBmb2xrcyB3aG8gbWlnaHQgYmUgaW50ZXJlc3RlZCBpbiBw YXJ0aWNpcGF0aW5nIGluIHRoZSBIYWNrYXRob24gb3IgQ29kZXNwcmludC4NCg0KSSB3ZWxjb21l IHN1Z2dlc3Rpb25zIGFib3V0IG90aGVyIGZvbGtzIHRoaXMgc2hvdWxkIGJlIHNoYXJlZCB3aXRo Lg0KDQpUaGFuayB5b3UsDQoNCi1HcmVnDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Jul 8 19:25:04 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B939012D10E; Fri, 8 Jul 2016 19:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z6VT6bIDX4H; Fri, 8 Jul 2016 19:25:01 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED7A12B02F; Fri, 8 Jul 2016 19:24:58 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id b72so51652033ywa.3; Fri, 08 Jul 2016 19:24:58 -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; bh=FKAHxtfiqiVTMujiV2o07r9rKYxo8RXXl7glh+OdZLc=; b=PpuIS/dH7m3OgrgpimOj/2bhN38xk5Pl7BSiKTEiuQRL6S/3+T9vScEgp4/mYNVgFP DJp2YP6hbpS5Zk/pAbRpcmtJ9vPbgPrCjbDEjfjmswWXbajAMVDgPW4v6gxWtAjwgBHq GDH6TRU9V92nxBPk2NYeS2wmLU20QIljuVUvQpvRgjNZyUIPVyVOKuneDskxuUpyeIUy xwBOdEVG9M9OhSXsU0mZ+wPZ06Q35KYC8rDQ5SfEU6oqJGUvD7+fuPWsYTdLZ0MUxzvS 77nidM02DKPZh321zCfAzHPrl32ee2eE4XKcYsoLnfwXaofDVuDgdP4qtqw9xQNqqxE3 r9jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=FKAHxtfiqiVTMujiV2o07r9rKYxo8RXXl7glh+OdZLc=; b=N2mmgef3Q0GGBV0PmPyvVAkNynVIxKPcgHeitUS+jDD0P+uposFo0kDRJo9xwziqvr X/U7xHWxm7rk21wSUZiMTR+PtXpqJwBBWTAb/TJwnI47nvzEuP2japaplDEV8KcxmYdH E7KhHc2fJmWsl5iCwu8yRDyHZbET7HDn/pQnlU6P0Q7YgAmdK3Lz405o7rAHRGAp2GaM Dpgkl5Ef1rBL+4WajT5NHQZ9I8PTBRheTs9dNjVmzpWwxRS340ZCG1FGtv/7m5Cu6fef IgqGiM8rDqVgQYef5tdVvJM+WTaIetb3hKZSDvAbMbtlAYLpfO2yqUHN5rSdjzZXSM6m 7cWA== X-Gm-Message-State: ALyK8tLeIKPXZ9GY31+rmzmhP/u2kzkZ8Se5wrHQnDHE46QpO/XSfK/4hQkuXUlzk48H/FcSlH2RWJmZnTE1GA== MIME-Version: 1.0 X-Received: by 10.37.15.215 with SMTP id 206mr6043925ybp.171.1468031097197; Fri, 08 Jul 2016 19:24:57 -0700 (PDT) Received: by 10.37.206.146 with HTTP; Fri, 8 Jul 2016 19:24:57 -0700 (PDT) In-Reply-To: <57358948.8060302@gmail.com> References: <57358948.8060302@gmail.com> Date: Sat, 9 Jul 2016 07:54:57 +0530 Message-ID: From: Pushpasis Sarkar To: "spring-chairs@ietf.org" , "draft-psarkar-spring-mpls-anycast-segments.authors@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary=001a113f58e41159c005372aa034 Archived-At: Subject: Re: [spring] WG Adoption for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 02:25:03 -0000 --001a113f58e41159c005372aa034 Content-Type: text/plain; charset=UTF-8 Hi Chairs, A gentle request once more to start the WG adoption call for this draft. Thanks and regards, Pushpasis On Friday, 13 May 2016, Pushpasis Sarkar wrote: > Hi Chairs, > > We have presented this draft in IETF-93 and IETF-94 and have received > quite a good amount of interests in it. Also the draft seems to be stable > for quite a time and the authors fill that it is in good shape for WG > adoption. > > Hence request you to consider initiating the WG Adoption call for the > above draft. > > Thanks and Best Regards > -Pushpasis > --001a113f58e41159c005372aa034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chairs,=C2=A0

A gentle request once more to start the= WG adoption call for this draft.

Thanks and regar= ds,
Pushpasis

On Friday, 13 May 2016, = Pushpasis Sarkar <pushpasis.= ietf@gmail.com> wrote:
=20 =20 =20
Hi Chairs,

We have presented this draft in IETF-93 and IETF-94 and have received quite a good amount of interests in it. Also the draft seems to be stable for quite a time and the authors fill that it is in good shape for WG adoption.

Hence request you to consider initiating the WG Adoption call for the above draft.

Thanks and Best Regards
-Pushpasis
--001a113f58e41159c005372aa034-- From nobody Sun Jul 10 02:07:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959F812B009; Sun, 10 Jul 2016 02:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvGG4n9zBOcB; Sun, 10 Jul 2016 02:07:10 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10108.outbound.protection.outlook.com [40.107.1.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A890C12B00B; Sun, 10 Jul 2016 02:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CJjQ5ep+gVmPmuzHscJcPqq7zFYTZIOd48I5XHLDRds=; b=IlP/jDfOkoUrPda+kgqYASvttmGq4mF2S7qkHpk6VEJAf2oW2OTHL/a3BjvfHCuEHk/kM984T6FyTHwdhjQuSh8orDvB+gfFqzAZNW4cdffdRaghE1SpfmuzuMWXqEbNTNUh147Amwev7Yu9mlWQP50vT9a9ZiIgZUR3FQ7+GnA= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2140.eurprd03.prod.outlook.com (10.168.31.17) with Microsoft SMTP Server (TLS) id 15.1.534.14; Sun, 10 Jul 2016 09:07:06 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0528.026; Sun, 10 Jul 2016 09:07:05 +0000 From: Alexander Vainshtein To: "draft-ietf-spring-resiliency-use-cases@ietf.org" Thread-Topic: Issue with path protection for SR-TE LSPs Thread-Index: AdHaiG7vxRelr/mFQMaAZB42zmpXRg== Date: Sun, 10 Jul 2016 09:07:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: 965e9e34-08c3-47ba-4d41-08d3a8a190af x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2140; 6:oN5tMn5QTPUrbbsrqSQKj758J3MGPcdmbRWBkIAl0UV4OOpF86iUbpOLn6xvXlYPiOZ5QN7HEPz0egemDH2jcP4IQBzABXMXRYr5w3AyAepWqfPYlvCoe/M0WN24YWT46qr9DOQXe/1mrUTHaxYZmYLioljmwJVqdpioTO+vsNWNqiRYKCSiaFlvAVeVY6yedBZ8013APni47B5lvaGQ2+5xMHA4NKdAlRil30JyddmzQho26Xdr4G3+hWuSNLtjRpHcXcuA1bDMnJ5X4dbrF7n+9mao01PEVcQi3CF+U93rftP8Fcfv9LM4YyGYT0R1+er87ghws3/2hPdMhVuzjg==; 5:aEv9a3tA8ETkF/2U37LqAC5hwCj19H+/gq0BrcuaOXK7bOhPGeEsGXw9RKKAZ1BNsJoxZAgAS/PWe6XF07Z3UplwPWXXcOHmVPC4iEBsPg1N8LtYphCOqVXjC2+hQ9jUWWTnKbuPo3LCGoqT0waq3A==; 24:Vtzt5hkZzxxtweXafy2pdcuv7RfJZI1LWrf+Oo/CxPX9aODA94F8pNuOErjGU2U98SIDTv6Fvegk/dc7y0aiS6NKsMWg/mH+g6m5niXa63s=; 7:3JzZIR9W3fNChWmr7Cl/gC4WfgNNRPT6QyqBzJTBBCpd3B0d/mXlGZCxjTQL3OlDufQNJ/tMPf2IlNFGrVL95xegLF1rzKyWoEVQruouEX8HiEOCA1tp3S2XwdkHSXzfvGLdg8cGUAMMST0gWS5c3QDmGLaYPr/P7pwmNMgsEgOy0F7Xx4A+yIMyIM4q0+5d9mS0HGkl9vnw1OqTxPLjXz1Ak/1eThSiFBUV9i32yKJpGDUd/kKRBO4A2Ri4b5P0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2140; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2140; x-forefront-prvs: 0999136621 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(51874003)(199003)(252514010)(189002)(53754006)(87936001)(10400500002)(2906002)(3280700002)(4326007)(86362001)(19300405004)(3660700001)(586003)(3846002)(102836003)(6116002)(790700001)(2501003)(450100001)(9686002)(77096005)(92566002)(19617315012)(68736007)(5002640100001)(8936002)(54356999)(50986999)(97736004)(7846002)(5630700001)(74316002)(106356001)(105586002)(229853001)(76576001)(110136002)(107886002)(189998001)(7906003)(5640700001)(7696003)(5003600100003)(7736002)(33656002)(66066001)(8676002)(16236675004)(2351001)(122556002)(81166006)(81156014)(101416001)(19580405001)(19625215002)(15975445007)(2900100001)(19580395003)(4001430100002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2140; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB22665D595B48C211187865CA9D3E0HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2016 09:07:05.9480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2140 Archived-At: Cc: "spring@ietf.org" , Marina Fizgeer , Michael Gorokhovsky , Shell Nakash , Rotem Cohen Subject: [spring] Issue with path protection for SR-TE LSPs X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 09:07:12 -0000 --_000_HE1PR0301MB22665D595B48C211187865CA9D3E0HE1PR0301MB2266_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have read the SR Resiliency Use Cases draft and I have an= issue with the path protection use case. The draft defines this use case with the following constrains/qualifiers (q= uoting from Section 2): * The operator configures two SPRING paths T1 and T2 from A to Z * Initially, the customer traffic (e.g., PW traffic) is sent from A= to Z via T1. When T1 fails, the traffic is sent via T2. * The two paths are made disjoint using the SPRING architecture * The two configured paths T1 and T2 MUST NOT benefit from local pr= otection The draft does not go into any detail regarding the type of segments that t= he operator uses when specifying T1 and T2, and the example given in the dr= aft can be interpreted in two ways: * T1 and T2 are specified using only adjacency SID * T1 and T2 are specified using node SIDs (or a mix of node SIDs an= d adjacency SIDs). If T1 and T2 are specified using node SIDs, there is no guarantee that thes= e paths, even if initially disjoint, will remain disjoint when the underlyi= ng network topology changes. Further, if TI FRR is enabled in the network for protection of non-TE SR LS= Ps, the fragments of T1 and T2 that are specified using node SIDs will not = be excluded from local protection. So it seems that path protection for SR LSPs as specified in the draft is o= nly applicable to paths that are specified using only adjacency SIDs. Did I miss something substantial? Regards, and lots fo thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com --_000_HE1PR0301MB22665D595B48C211187865CA9D3E0HE1PR0301MB2266_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have read the SR Resiliency Use Cases draft and I have an issue with the path protect= ion use case.

 

The draft defines this use case with the following c= onstrains/qualifiers (quoting from Section 2):

·         The operator config= ures two SPRING paths T1 and T2 from A to Z

·         Initially, the cust= omer traffic (e.g., PW traffic) is sent from A to Z via T1. When T1 fails, = the traffic is sent via T2.

·         The two paths are m= ade disjoint using the SPRING architecture

·         The two configured = paths T1 and T2 MUST NOT benefit from local protection

 

The draft does not go into any detail regarding the = type of segments that the operator uses when specifying T1 and T2, and the = example given in the draft can be interpreted in two ways:

·         T1 and T2 are speci= fied using only adjacency SID

·         T1 and T2 are speci= fied using node SIDs (or a mix of node SIDs and adjacency SIDs).=

 

If T1 and T2 are specified using node SIDs, there is= no guarantee that these paths, even if initially disjoint, will remain dis= joint when the underlying network topology changes.

Further, if TI FRR is enabled in the network for pro= tection of non-TE SR LSPs, the fragments of T1 and T2 that are specified us= ing node SIDs will not be excluded from local protection.

 

So it seems that path protection for SR LSPs as s= pecified in the draft is only applicable to paths that are specified using = only adjacency SIDs.

 

Did I miss something substantial?

 

Regards, and lots fo thanks in advance,

Sasha

 

Office: +972-39266302

Cell:      +972-5492663= 02

Email:   Alexander.Vainshtein@ecitele.com<= o:p>

 

--_000_HE1PR0301MB22665D595B48C211187865CA9D3E0HE1PR0301MB2266_-- From nobody Tue Jul 12 08:13:30 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9702F12DBDA; Tue, 12 Jul 2016 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pu6QMuCE-W6; Tue, 12 Jul 2016 08:13:24 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0106.outbound.protection.outlook.com [104.47.37.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3661712DC87; Tue, 12 Jul 2016 07:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w0Y2U4ulR6CvwVvy+f3Sp32r8pcrc2wfvfLu/CxV7pw=; b=OAB3/D+x7mvAJLQZFWmolUVdP0aQu/EM+IWkOK92syXugminj4SjZONXAHMxkynqE6p1r2uXId+Vu+fSs1PIVvbjlMcJw9iz6yo6EpPdn2ja/yOf13LaHSUtdFS3/3wby8pgdzQOcb4qenDmPVGkt0izL3iBZK9AGwzbvLfqFnw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from ssubron-sslvpn-nc.jnpr.net (66.129.241.14) by SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) with Microsoft SMTP Server (TLS) id 15.1.539.6; Tue, 12 Jul 2016 14:44:22 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2016 10:44:16 -0400 Message-ID: <8101D467-27D9-45CA-ACE6-3435D7E2A213@juniper.net> To: , MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: SN1PR17CA0048.namprd17.prod.outlook.com (10.163.3.144) To SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) X-MS-Office365-Filtering-Correlation-Id: 469acb8e-bab7-4193-fe8f-08d3aa630376 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 2:zR3+9b77ewcZWOr0irjCWw4qvfjCzK4fMaNp9YGDq21YLGa+cTcnucN5+gmqIkQUnYbrCbCDneJ8vuaVqGODwLn7XYnC1+/OaD08dXlI4UNwU0ZAoeMUx6orn/LuhhEPZk2f0iN5RQVbgqbGl0cNwLjdef7JzcA6uchng3cqi7jPnOXc3uDfPKbKLV9sOzuU; 3:BjiA4KeFSDFyU0Ohj+kIBsi0R+fU4tF5VYysF6GM9QdNDPVdbPMASPfzzGykPFfbOa3Vv5qtLVnuTlzxF+okECN7BANM36Vn/6cSeq4zFHKjQ+/1IaXasa252E2HeRoJ; 25:bmQtae+CudBWg7oA8+qsXSu+4KAopSL7bZGQW0rFBcMx4jXzRKwb7EZxEuei9T9hFAw3a7S9nVTiUSroRsUmrczfSdpvhz9YSFw9eb7VZkisdc1tUC7PqIa2fTamM0buBSXC/o4wFLXFVhhtMyyZ1W9eefcnrGfmdD01mtqfBze6RTY+8hGm5Wtb05/Zm2qjzvYx+6bAEx5/0zvKeYoKcYCVkNhnX/gkrVOps2sgAJhIcL9BNmmGnHa8Fwyb/dzhyUy92Uxz/nrXoiNXRoPZo96tzET2C9ER4aonb1+7a3oRz76SMlXPXl720VYTX6xQIFWhcXk9Fb9n8G/JSZlIJtxvVNfUXQxh1PS3ZaASQJtsvf1H6lxZHM2ScAyuKxW3cDM+lbkZ23Bw0Qi3MwUjrG6IxY7TpzKmXweRtuNX/vc=; 31:B20ODWTZ7PumJGjs5tafCBxAST2hAaRnTbl2d3key6powDH48zfCaKpQrUiscpyHPYmtg9tcxFtw3cB9iTvkh7Urd19J18KHaQORCAZHk8iG7Q8IJPSRXYqCSVraIAKVT0YKYUu3FyuvCunhdON4nV//klD4HF6+U94e2WP7n/KIOYNOo8I/USAzv5e4JNL8/N3ffdK/vXZBXLhTIf//8g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 20:a7cMJT8UNewhtBJl8p/4LsOZYx/FZzBubFOGkP9JYNrQhV85X0ne6oEyBK9hZSPuqlnSGHIHHYJuR8uWLceP1carCFPbRbqyBrGi+Ie4+ZMxQRT1GwvwA9v/zpsVEEYN6w12W/LJf2RPQbzWepuZngg3UnurspEjOrRgXiKyN6lAkQre9YjidGMP67OGxqrHoit68PgbGlClcedS5KbKZUiM4IILmm/CSsN9uWGaFfxRmETIstArhbgh4U5vSe9rRJkqtK+tGCxssSQAjH/tKlkpRIv/19jb6GmfKSxKFmWUrOnfbH49VIcOi7jCooIX8EdyyVX0/pnT1X7wqA93R4OfE+K9T94Z0oB5Qvpw+ak3BirsX9OxTVOw49ePV2stAEWkE6kGRYGmOji6tfvPcImEgF8O+gs9iEwy/YmW0tT3L1dqt/De8ZvfFnyGYY90dxTakKimFg775GjWNdOXLN1jZQa0M5Q0tRQrh+g+17o8/DTE4cC9WJNkcHywoI2S; 4:F3iK252cDepmjOxvMkuzIMQZ0Q8vH7anr2SB4hIVzXKRy8wvGdz5hxkiK5LbkWF8lAxdZ74r0naN53NzZK35y2oQovb7xl7RrstyIekkeSepX85Romj4IXjbpRLusoJgv1t9vg6JcxmIiF+HMkES5R4f5MajxFmK41KlvPcDenFsdaaeSOIkKc0Y8K2dDU7GwNsVs+j4pgha2Dot+1EI7Y/l4QUeXzB3rdIYB/GyfOkq0beYLOwoluxstUnJNeOmL6ziu9oVPFgHpK0HXpl0uEZCmWtN/R/vAmVmojTCnwgQW5ISx8yEz/6X6/enjl/TD+envB9iGQswFuAFQYMFzhNifp4YiGFRQn/P7XkWvP+F8AgBwhPJzeDkXZ9LbRnXs0RV6Zct3rMgg5gFXsYVKAQmB1bBW/7iP+BZXu6gCP6K4KGXKkNx5vJjwiigbA4a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(279101305709854); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2512; X-Forefront-PRVS: 0001227049 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(6116002)(50226002)(97736004)(3846002)(66066001)(586003)(33656002)(82746002)(36756003)(230783001)(5001770100001)(83716003)(86362001)(50986999)(450100001)(101416001)(68736007)(77096005)(229853001)(92566002)(7736002)(7846002)(23676002)(50466002)(81166006)(81156014)(53416004)(4326007)(19580395003)(42186005)(8676002)(69596002)(189998001)(19580405001)(2906002)(106356001)(105586002)(8746002)(47776003)(57306001)(305945005)(104396002)(42262002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:ssubron-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjJQUjA1TUIyNTEyOzIzOmMyQ1dQcnhaZUhMbXZDQ1FrelRabnR5Snkz?= =?utf-8?B?K1ZwdEhwZVVOSVlDekZ4ZWtKL0Qydmd3RmdaMW5LME5rL0R2My9IRUwxaVEy?= =?utf-8?B?em53SHFRZDJsOWdwanlMNWtUOERjeGRjbkxjNkd1eUJoempQYUVlckJKMXZm?= =?utf-8?B?Z3UrenBkUDd3cktzLy9nQ2hpdnZJc1l5QzA3RUt0VzVlQ0psMGRUSTIvYk03?= =?utf-8?B?aHFlZ00wNEhGTmtzQldwMzV3RGloVzZWVUltNFpWMWdVUmNmdHpGVVVvRzJE?= =?utf-8?B?Y1g0cEtvR0l2UjRKdGlkL2llaFU1V1Zia0dJZC9yRlg5ZGpLbEVXMUZVbDFz?= =?utf-8?B?QVNscjBBVXY0QkQveVZFM0x0bU1jYlRJZDZSOEVkVWNDaFlZYW5qUHI4MXJG?= =?utf-8?B?b0wrc2xlc3RpQlpVa09lTjVTSlNNVFQ5UUtkMU05dVNGV2RheTlMWU5VNkY4?= =?utf-8?B?b0FvN0EzWnhSSHRuUVRhdFlDNXhHR2J2WVZYemw5WW5UZDNtYnFXaE4yc1Jl?= =?utf-8?B?N0FLazBIMmhJSHg0c0lIUEJ1Z1pqTlZOTUlNUEFzR2pJT3BZakt4V2EwQ1BQ?= =?utf-8?B?M1pQN1pld1BjTFUvb3dtdXUxSXQ0U2pta0FndVFCejVtNGNGRkFER1pXYkgx?= =?utf-8?B?Q3AyWmZlYjlHdUt5M2YrTFd6S1ZmQUZtMXgyb3VRZkZpS2hPQ1JwQzg3bCtQ?= =?utf-8?B?M0crYm5ISHJYWHkyRnUrckU4aVFySXlEUEg0eGs1SDJmcDNoUVZLYmxWcWxY?= =?utf-8?B?WkxyL08zUkVCR2lQdmtnc3E1NWk3ZEwyVlY4QnpMQUVsUGp0eGJJR3ZXeC9u?= =?utf-8?B?TysrZmh0ZzVPaVQ2V05QZGRuN1BFOG1OSTdQTnBGVHdUQnRYVFpVYksxbEUz?= =?utf-8?B?RlE3L3padW9nNytVeW1rUC9DT1NVazhiVlFoUGI4enc1Z1hkanFocWhmL0lG?= =?utf-8?B?Z2tTM0MzMWZoVFpuODJQVmZBK3kvVm5na3dhWThZSU5lTlAzTTlCanFjT3pu?= =?utf-8?B?TElaVFptZEJSSlNmcE1UYkVBcWdySFFTVWRMN2tlTVA5RVpXTHIvcHQ3TkNB?= =?utf-8?B?bnd4enhMMnp1Y1YwOC93dlJVUVlKbGdDa2JoTUpKUUQxbmI2S3hSa0ZmNkpR?= =?utf-8?B?cWNVbTJTQ0NRM3lIY05iQnl4dzNwKzJheHNlcm1WMGZ1UnV3QmE2T2RuVjh4?= =?utf-8?B?MWYvdGFCY1JFa3Q5U1NqMDhFN3R4L2hVVkVJcTRSQ0l4Q1ZhRjNsQ0poTXZz?= =?utf-8?B?Q2Yvc2tZYzRoMXVMNG01dHdmZ1RJT2xpMFFCZVpFVnZGSDlMazlmSDZuNS9J?= =?utf-8?B?RzVxZEpkM09Za0tJTVR3aGVyQ2JETjYzajFHK3JEVlNjU3lZT1NpaFRYazl2?= =?utf-8?B?QkY1Rm0yNGplUzBZYTVsRnNtMGI3ZC9WbktwSXAwSis3QytaM1lLU3ZvTDlv?= =?utf-8?B?VjQvK3BZaVVjVFVldU5jQnBYeE1PLzNHQ09JSDZzOEFsVjZnNmltTkRMOFI2?= =?utf-8?B?bGJqTXNIWHlYSzRtN2UwWjl1WmtMYnJvYWFjUFN0Vkx1S2tMOHZqM2tFdW1U?= =?utf-8?B?MU0rVzE4cHRESjRqMjVWaHZHcjVOaGpoOWFPVDA3OHpnZXJQdHFSUC8vd0Rx?= =?utf-8?B?K3M2UlUvTld2cStySGV2ejJqMFNSdmlLMXEzdGlFUEZqNHZkdCtTaVRnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 6:uaOnDLc05yX29FcTGqrK09Kx1C0gWB9WRbe0cM5CS3+yY/qwyRf119vtZIlm/C3k7MH0RJ6htZgU9JgdrxZ1tAtEZjewTxaxPAeRKsQvtOBQJj+d7O/ygm19krGNX3Ds2D0GRjh0xcs1l2YMRjSeOMSdBzd0UsiPuHZw4qvJvCQKGLcknPRRaczBNI66ie69rKXBSQMeyyyoniKpoSNSW05fpLhaQnNRgCzkbjYgywzy0fL7FuD/qTnlVl8REH+5Fh0TwyZFoio2SpQidbSf09qfH8gZFhhtjlDkceSOu7nWzGE4Rzsi6BWOZQWYtvf+jaDP3jsFcZfx1wx5eSdkeg==; 5:jRAr8rp2x5YxNQzJyzC0BswJjDNYUugdZcshjdLtVILUp8nz3S3nynrw9Dodxwjz2VYr+9uebN1G0Rw6H+Laa+9YrF+0jd8wxDDeD0rZjcfk2DIT0F2AJTSq31FFdYEoIPLu9Ic/wK8MfdNFPHAx1A==; 24:Xwi4+082u56edQYiInlviVSTgCFK6HvTzZaoKcdjOyfob9AcUFIQKprI3dWxHfgBhLjk14LKoxodj51J1WCWvIYjroxO4QUPz/eE0qOYOsI=; 7:oj2GP0hOQytCeLRAxA43nSKQLw5zln76DQzRAOMMnxio9+EN6J+zuArhkVhHM0Zm1T6x+inu+00ZVneuYe1r9z8qI1tBMXH8xf0bPdQNaP//329wOy0PeC5GBenZfUy68jTdy0xBnRWTqUthWRcdVfctVeUhn3ebBaRNHqS+8OBNzaKDfSCCV0dPTtOGdg0oOiNkgFQhrMaLRemUiu6MudMNv/q4C3OB1NLJD0ngQ5FaQpZsljkficMr1HeCDqlm SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2016 14:44:22.1002 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512 Archived-At: Cc: rtgwg@ietf.org Subject: [spring] SPRING WGLC for draft-ietf-spring-resiliency-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:13:25 -0000 Dear SPRING WG (and I've taken the liberty of cc'ing RTGWG), The authors have indicated that draft-ietf-spring-resiliency-use-cases = is ready for WGLC. Please send your comments to spring@ietf.org. We will = plan to end the WGLC on July 31. I notice that there is an outstanding = question from Alexander Vainshtein , = sent to the list on July 10 -- authors, please consider his note to be = part of the WGLC and respond accordingly. Authors: In parallel with the WGLC, please respond to this message = (making sure you cc spring@ietf.org) and indicate if you are aware of = any relevant IPR. Please do this even if it has been previously = disclosed. Thanks. Thanks to St=C3=A9phane Litkowski for agreeing to be document shepherd.=20= Regards, --John= From nobody Tue Jul 12 08:21:11 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F1612D0AA for ; Tue, 12 Jul 2016 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMMs9A_YpMKq for ; Tue, 12 Jul 2016 08:21:02 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0122.outbound.protection.outlook.com [104.47.36.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7977012D150 for ; Tue, 12 Jul 2016 07:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RrJJxqGt+1oZAJXENhuN9DtvKEpg8EcDHksohB36uG4=; b=ODkqnFMC9XRNcExGguTe/5haX1r2l3Y6+9c7PhPR9y0TRYawLoMJrNgCtPwsk4wVEM5gucEDKFjdPNcKi3LO9FvFrRQahxJOGNnFau5Po5UaxW8LloK2PAOobpQSzUEA2JjGdAkiI1ZKQXAsqcw62BVWTAI1jyVmQdjxsXfEiEI= Received: from BN3PR05MB2706.namprd05.prod.outlook.com (10.167.2.135) by BN3PR05MB2705.namprd05.prod.outlook.com (10.167.2.134) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 12 Jul 2016 14:54:19 +0000 Received: from BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) by BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) with mapi id 15.01.0528.026; Tue, 12 Jul 2016 14:54:19 +0000 From: Shraddha Hegde To: "Les Ginsberg (ginsberg)" , "bruno.decraene@orange.com" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Policy Thread-Index: AQHR1uI/zKhLNmBpEkGXk2Rex85XEaAU6S9A Date: Tue, 12 Jul 2016 14:54:19 +0000 Message-ID: References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> <91fcbdba712143e890609f6a513f8528@XCH-ALN-001.cisco.com> <2921_1467708583_577B74A7_2921_256_5_53C29892C857584299CBF5D05346208A0F92B91D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net; x-originating-ip: [116.197.184.11] x-ms-office365-filtering-correlation-id: d0e3f4ff-9795-40e9-262a-08d3aa64671a x-microsoft-exchange-diagnostics: 1; BN3PR05MB2705; 6:5UvBfz80DPwW+iA1ezbCoFqwg9CI35Q125eX/Jf/HIIbl+c79J3cOTaTNuWv1fJyP2YYG1r5pzQpBWO81/d9lIxgZx9BgkTO/JuhYj1Fn1S+tgZIfiQbr9FxsaMwoOo6tw7MqoLIoYA9nm2DxAxlHma0nhAYVPEj9+2bxLpv29/KhR74yb6Z2lsn9tonHr4LMx5pnqY3CVpNoMQq+VRkdYGtquWKepAR5nkYC0XewfssW6jg96GYyLay6zXBxpjSGxOhfXbAkyFSYBg6t8l1NpXcD5plz/VFmDA0qjbJTVLqdCA0J0MSj3FH6aW3Be18tlz9pXeBgZ7NcRBvaEQ47w==; 5:fnUiiFXe3YDXKIjTQM/lUajXLupENcDUYaKQgrZm+oBNRxRQp4JWseoejPmQfYCbsp4D1v92p5QLNZz+UHD6Y56qyF2ry6v0rQyZhBOxEJpNqrqfnpOb/0GQtzAPcX2vWOpOQkcT8fS3e/qLk/W3/g==; 24:+P5zE2EFGyM4WW6zfJh2zHGsBwNz7Mgx0mcVrkQoSZCVf5TfD0Q3xn3usl4Jod5PBDTZDpidRPzHRQezA0hYGpwyAKVtbM8g9MkC2HE0BTI=; 7:6zDH8V/X99kcl1DX8eOwmQT26xs7vmp0/xBl4JG5f3P+XB3+8B8whtaOz1Ty0lXxKA7FPo0uKL+J9pr+1AbzKweC5BYKBVezBToxm3wujQbdBW3nTgaZwwaHd/rpBylPPcBeSWv29nmHhNZEDYH8znxngrdstDefaJjiHJtCZB8lOoBMmn2mQpFD0YE1IHeW9pihI3y1vqhRURttsAhk/S0IgkNRWjrCJo/UeTOSt3jQ6Merq+McljgiLq4d/cKh x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2705; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317)(95692535739014)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2705; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(51914003)(377454003)(8936002)(9326002)(5001770100001)(2900100001)(66066001)(11100500001)(2501003)(101416001)(9686002)(97736004)(16236675004)(68736007)(230783001)(3660700001)(7736002)(19300405004)(7696003)(5003600100003)(33656002)(3280700002)(105586002)(76176999)(76576001)(189998001)(19625215002)(2950100001)(122556002)(8676002)(561944003)(74316002)(81166006)(81156014)(19580405001)(2906002)(93886004)(4326007)(7846002)(77096005)(87936001)(19609705001)(586003)(790700001)(6116002)(102836003)(15975445007)(99286002)(19580395003)(54356999)(106116001)(3846002)(92566002)(86362001)(5890100001)(5002640100001)(106356001)(50986999)(10400500002)(579004)(559001)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2705; H:BN3PR05MB2706.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR05MB2706EC1E9B5DEB1752AFB768D5300BN3PR05MB2706namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 14:54:19.0598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2705 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:21:10 -0000 --_000_BN3PR05MB2706EC1E9B5DEB1752AFB768D5300BN3PR05MB2706namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, 1. Quarantine policy has certain disadvantages. One of the major disadvanta= ge comes from the fact that the preference rule has "smallest range wins" on top. What this would mean is that wheneve= r a there is a conflict with a smaller and bigger range Bigger range loses. If it gets quarantined, you would lose connectivity to = all the prefixes in the bigger range so the impact of the policy on operations is huge. In case of "ignore overl= ap only" policy impact would be on the conflict entries only. I am not suggesting any change to the preference rules but trying to bring = about the fact that quarantine policy has operational disadvantages. I see that this point has been brought up by other on the thread as well an= d if you agree this is a disadvantage, it should be clearly spelt out in the draft to bring it to the notice of wi= der audience. Human error is not uncommon. In fact, "human error" features in one of the = top 10 common reasons for network failures. We should have an efficient mechanism to reduce the impact of human error. = If 1000 customers loose connectivity due to one configuration error, I can only see the issue getting escalated = and operations, support staff, engineers having to respond in the middle of the night to root cause and fix the issu= e. 2. section 3.2.7 mentions "ignore-overlap-only" policy as very complex to i= mplement and also gives details of necessity to have two databases one raw and an= other derived. While I fully agree that implementing "ignore overlap only" policy is more = involved than the "quarantine" policy, I do not see it as fundamentally different than what IGPs do today. IGPs have two databases one is LSDB and other routes. LSDB is from created advertisements and routes is a derived database and th= ere are inter-linkings between them. 3. Having quarantine policy makes the SR deployment harder. In today's worl= d if there is an ip address conflict, the traffic gets affected for only that prefix. Con= sider a case of 1000 prefixes getting redistributed into IGP from an external source and a prefix range/sids gett= ing assigned on the redistributing node. If one of those 1000 prefixes get redistributed via another node as well an= d there is a mistake in SID assignment to that prefix, Quarantine policy would result in losing connectivity to al= l 1000 prefixes. If you consider similar configuration error in non-SR world with LDP in deployment, misconfigured i= p address would impact only that particular prefix. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 5, 2016 10:55 PM To: bruno.decraene@orange.com Cc: spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Bruno - Two comments: 1)As we both can come up with examples where a given preference algorithm = will result in "better" behavior than another, continuing to debate which o= ne is "best" has no end. The answer depends upon what types of errors are i= ntroduced in the configuration and that isn't predictable. If it is necessa= ry for us to agree on which algorithm is "best" I doubt that consensus will= ever be reached. It therefore is more important to me to focus on implemen= tation complexity and the importance of identifying and correcting misconfi= gurations ASAP. 2)There are two logical databases that an implementation has to support. On= e of them is the set of received advertisements which can include entries w= ith a variety of ranges. The second one is the set of mapping entries which= are in use for lookups. Your discussion of your "per FEC algorithm" below defines the second datab= ase as a set of entries all of which have a range of 1. Whether this is goo= d implementation model or not I am not commenting on here. But this does no= t eliminate the need to maintain the first database - and to be able to ass= ociate entries in the second database with the corresponding received entry= from which they may have been derived. There is work in maintaining that r= elationship which does not directly bear on the lookup for a given SID but = still has to be done if one uses "per FEC" or "Ignore Overlap Only". This w= ork is not required for the "per range" or "Quarantine" algorithm. It is th= is additional work that I refer to when I say that "per FEC" has a higher i= mplementation cost/complexity. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Tuesday, July 05, 2016 1:50 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 05, 2016 9:08 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - Consider the following simple case: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2: (SRMS, 1.1.1.1/32, 200, 10, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) There is a misconfiguration here, but we don't know what was really intende= d. A few (of many) possibilities: ERROR #1: Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !St= arting SID error ERROR #2: Entry #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Sta= rting prefix error The draft defines two candidate preference rules which could be applied: Quarantine ---------------- As we evaluate prefix conflicts first, we compare Entry #1 and Entry #2 and= choose Entry #1 the winner (source is PFX). Entry #2 is then not used (qua= rantined) and the set of active entries is: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) Ignore Conflict Only ------------------------- In this case we split Entry #2 into two derived entries: Entry #2A: (SRMS, 1.1.1.1/32, 200, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry 2A is then ignored and we then have to evaluate SID conflicts between= the derived entry 2B and Entry #3. For this we have to split Entry 3 into= two derived entries: Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Entry #3B: (SRMS, 2.2.2.3/32, 201, 9. 0, 0) Entry 2B wins over entry 3B since it has a smaller range. Active entries are then: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Note that in this example both preference rules result in 11 destinations h= aving non-conflicting SIDs. [Bruno] Yes. The important part is =AB in this example =BB. Now do we agree= that in average, Quarantine will result in dropping more destinations than= Ignore conflict only? Now, which of these maximizes delivery of traffic? The answer to that depe= nds upon the type of configuration error that was made. If Error #1 was made, there is no way to differentiate the two preference r= ules. However, if Error #2 was made, then Quarantine is clearly better because th= e destinations 1.1.1.2 - 1.1.1.10 were never intended to have assigned SIDs= and may not even exist as destinations in the network, yet "Ignore Conflic= t Only" favors those prefixes. The point I am trying to make is that it is incorrect to say "If we maximiz= e the number of advertised entries which we use we will always do a better = job of delivering traffic." This example illustrates that this isn't always= true. [Bruno] OK. Clearly, we can find an example where an algorithm is better th= an the other. After all, we all agree that there has been a configuration e= rror. There are 2 points: a) how many destination you keep using b) in case of conflict which of the entries you select I agree that "b" is more or less random and hence there are many cases wher= e we'll pick the wrong one. Yet, we try to make reasonable choices. That th= e point of discussing the preference algorithm (3.2.4). (Although it's very= easy to argue that we can make the wrong choice, I don't feel that's a rea= son not to try discussing it and make choice. e.g. "PFX source wins over SR= MS source" is one: we give preference to SR nodes rather than LDP nodes. Regarding a, I feel that maximizing the number of destinations kept, is lik= ely to give the best result in average. I don't have a proof, but it feel l= ike playing loto: even if each choice is random ("b"), the more you try ("a= ") the better your chances. A few more comments inline. From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Monday, July 04, 2016 5:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 3:12 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I don't find your representation complete as regards all of the attributes = which are proposed to be used by the conflict resolution algorithm - so it = is therefore hard for me to use/understand this representation when applyin= g the defined preference rule. This is true for me even after reading your explanations below. But it is far more important to have a common understanding of the algorith= m proposal than it is to be arguing over whose encoding is "better". If the= encoding in the draft is not clear or could use improvement, I welcome you= r feedback. As far as your "pseudo-code": - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID The fact that you can represent an algorithm in a few lines does not mean t= he implementation of the algorithm is just as simple. [Bruno] Sure. But if we want to compare implementation complexity, we'll ne= ed to agree on how much we want to go into details, in order to have meanin= gful comparison. So far this is not clear to me as you sometimes argue that= data structure is implementation specific and you don't want to go into th= is (which I agree) and sometime you detail the data structure. There is also the option to consider this as "implementation issue" and let= this to implementations. Coming back to my per FEC algo, all what is required from the data structur= e, is a way/API to get the data back, though 2 keys: get me the SID matchin= g prefix P1 (for the first line), get me the prefixes matching the SID SIDi= for the second line. That seem like a reasonable requirement on the data s= tructure, and any option in your draft also requires this to detect prefix = conflict and SID conflict (since this is all my per FEC algo is doing in th= ese 2 first lines). Going into more details, my per FEC algo only requires to detail that one p= refix or SID belong to a range (of prefix or SID) while your per range algo= requires to compute range intersection which is harder. So the API to fetc= h the data can only be easier. [Les:] Range intersection is easy to compute - the algorithm is present in = the draft at the end of Section 3.1.1. [Bruno] In order to have a meaningful discussion, we need to define the lev= el of details that we want to take into account, because you're not using t= he same one to discuss your algo and mine. 1) As a first level of comparison, using the description at the end of sect= ion 3.1.1 as a model, for range prefix conflict your algo is: 1)(T1 =3D=3D T2) && (A1 =3D=3D A2) 2)P1 <=3D P2 3)The prefixes are in the same address family. 2)L1 =3D=3D L2 3)(P1e >=3D P2) && ((S1 + (P2 - P1)) !=3D S2) So for (FEC) prefix conflict my algo is: 1)(T1 =3D=3D T2) && (A1 =3D=3D A2) 2)P1 =3D P2 3)The prefixes are in the same address family. 2)L1 =3D=3D L2 (BTW, in the draft, there is a typo in the numbering) It looks clear that FEC comparison is easier than prefix range intersection= . 2) Going deeper, at the algo complexity The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all the = algo complexity is coming from the datastructure. It seems pretty reasonabl= e to find a datastructure << o(n) (e.g. a tree, but you will be much better= than me in finding one) For the range algo, it's not clear to me that a data structure can be found= to automatically find the result. If not, the algo seems to compare all en= tries two by two, which would get o(n*(n-1)...(2)) i.e. o(n!) Consider what needs to be done to implement "Find all SIDi advertised for the prefix P1" In its simplest form, we have a list of all SID advertisements (PFX and SRM= S) that we have received. One could imagine walking all the entries, lookin= g to see if the prefix of interest is present within the advertised range. = But, of course, at large scale such an approach is extremely inefficient - = so we immediately start considering ways to improve performance. Inserting = received entries into an ordered tree of some kind is an obvious way to imp= rove performance. When one further considers that calculating conflict reso= lution only needs to be done when a change to the received database occurs = (which post startup is infrequent) it becomes very attractive to cache the = "winning entries" so that if one wants to retrieve the SID for a given pref= ix we only have to examine a subset of the total database - ignoring the lo= sers. [Bruno] I agree that the per range algo (ignore overlap only) will be able = to ignore the losers but at the cost of a more complex algo and at the cost= of creating new derived entries. It's not clear to me if the net result is= positive. Plus I would expect that the number of conflit is small compared= to the number of prefix /SID so this looks like a second order optimizatio= n. In this context, we can appreciate the difference between the three propose= d algorithms. In particular comparing "Quarantine" with "ignore overlap onl= y", a key difference is that "Quarantine" only needs to determine whether a= received entry is a winning entry or a losing entry. "Ignore overlap only"= has to be capable of breaking received entries with ranges > 1 into multip= le "derived" entries (some winning, some losing), which means we now need t= o track the "derived entries" against the original received entry so that i= f the received entry is updated/deleted we can find all the derived entries= and delete/regenerate the derived entries as needed. This is what adds com= plexity. [Bruno] and that it why the per FEC algo seems easier. So it would seem useful to add it in the draft so that we can all discuss i= t. [Les:] Ignore overlap only is the same as per FEC. We may use different wor= ds to describe it, but the end behavior is the same. [Bruno] good if this get the same result. Yet the algo is different. -- Bruno Les All proposed algorithms can be implemented, but it does seem prudent to con= sider implementation complexity as part of our decision process - and the d= iscussion/examples in Section 3 are meant to help in doing this. It is worthwhile restating that when conflicts are present we cannot guaran= tee that forwarding will work correctly no matter what algorithm is used. [Bruno] I'm not sure to see what you have in mind exactly. Can you elaborat= e? To me consistency seem enough. The more complex the implementation the more likely it is that bugs will b= e present and the more likely it is that interoperability issues will arise= . Whether these costs/risks are worth the "value add" when the outcome cann= ot be guaranteed to be correct - only guaranteed to be consistent - is an i= mportant consideration. Also important to remember that conflicts MUST be eliminated by correcting = the misconfigurations that caused them - so conflict resolution is really o= nly an interim measure until the corrections can be made. [Bruno] By "interim" we are at minimum talking about 10s of minutes, if not= more than 1 hour since identifying the root cause may not be obvious. The = impact is very significant on the network. The "Quarantine" algo has the potential to kill 100s PE and 1000s of VPN cu= stomers, so a single configuration change on a unrelated router which may n= ot even be in production (i.e. where configuration checks and operations ho= urs may be relaxed) No one should be lulled into thinking that because we have conflict resolut= ion deployed that correcting the configuration when conflicts are detected = is not a priority. [Bruno] I could not agree more that conflict needs to be identified and fix= ed. Note that I'm the one having asked for defining YANG notifications to r= eport this. You are welcomed to state in the draft that conflicts needs to be reported = to the network operator, in particular though yang notification, and other = existing means. Plus that network operator needs to fixed them ASAP (but st= ill carefully) Thanks --Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:00 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. [Bruno] I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there w= as a way to make progress by asking clarification questions on the points w= hich were not clear, or at least explicitly refusing to consider the email. I also note that what bothered you in my representation was my addition of = the type of advertisement (prefix or MS). But you finally have just added i= n the latest version of the draft "Src- PFX or SRMS" . So there was probabl= y a way to communicate. Besides the algo did not use any specification representation, just names. = So I'll copy/paste it below, please ask clarification questions for the par= ts which are not clear enough. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, for P1, we get a list of (SIDi, Pij) Get the best (SIDi, Pij) as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? [Bruno] - MS/prefix SID is the type of advertisement. In your new version, you call= it SRMS/PFX. - SID is the SID found in the Mapping Entrie - Rx is the loopback (prefix) or router Rx So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and= means: For prefix R2, we found a MS mapping entries advertising SID2 for t= his prefix, and then I found a MS mapping entries advertising prefix R2 for= SID2. Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . [Bruno] I agree that since the above algo used 2 mapping entries to provide= s the (SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted.= That being said, this is not important for this discussion. Let's just con= sidered that their exist a preference algorithm, which takes as input a lis= t of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition = of "best" is not pertinent) ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. [Bruno] Indeed, this is my expectation. But I would need someone's review t= o confirm this. But the difference is that the proposed algo is simple (2 lines of pseudo c= ode), with very modest resquirement data structure use to store the mapping= entries. Indeed, all it needs is a function returning the list of mapping = entries associated/matching a given prefix. And function returning the list= of mapping entries associated/matching a given SID. In particular, there is no need for splitting mapping entries which is the = main complexity of your proposed "Preference algorithm/ignore overlap only"= . (according to your own text). -- Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active"= : (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_BN3PR05MB2706EC1E9B5DEB1752AFB768D5300BN3PR05MB2706namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

 

1. Quarantine policy h= as certain disadvantages. One of the major disadvantage comes from the fact= that the preference

rule has "smalles= t range wins" on top. What this would mean is that whenever a there is= a conflict with a smaller and bigger range

Bigger range loses. If= it gets quarantined, you would lose connectivity to all the prefixes in th= e bigger range

so the impact of the p= olicy on operations is huge. In case of "ignore overlap only" pol= icy impact would be on the conflict entries only.

 

I am not suggesting an= y change to the preference rules but trying to bring about the fact that qu= arantine policy has operational disadvantages.

I see that this point = has been brought up by other on the thread as well and if you agree this is= a disadvantage,

it should be clearly s= pelt out in the draft to bring it to the notice of wider audience.

 

Human error is not unc= ommon. In fact, "human error" features in one of the top 10 commo= n reasons for network failures.

We should have an effi= cient mechanism to reduce the impact of human error. If 1000 customers loos= e connectivity

due to one configurati= on error, I can only see the issue getting escalated and operations, suppor= t staff, engineers

having to respond in t= he middle of the night to root cause and fix the issue.

 

 

2. section 3.2.7 menti= ons "ignore-overlap-only" policy as very complex to implement

   and also = gives details of necessity to have two databases one raw and another derive= d.

While I fully agree th= at implementing "ignore overlap only" policy is more involved tha= n the "quarantine"

policy, I do not see i= t as fundamentally different than what IGPs do today.

IGPs have two database= s one is LSDB and other routes.

LSDB is from created a= dvertisements and routes is a derived database and there are inter-linkings= between them.

 

 

3. Having quarantine p= olicy makes the SR deployment harder. In today's world if there is an<= /o:p>

   ip addres= s conflict, the traffic gets affected for only that prefix. Consider a case= of 1000 prefixes getting

redistributed into IGP= from an external source and a prefix range/sids getting assigned on the re= distributing node.

If one of those 1000 p= refixes get redistributed via another node as well and there is a mistake i= n SID assignment

to that prefix, Quaran= tine policy would result in losing connectivity to all 1000 prefixes. If yo= u consider similar

configuration error in= non-SR world with LDP in deployment, misconfigured ip address would impact= only that particular prefix.

 

 

Rgds=

Shraddha

 

From: Les Ginsberg (ginsberg) [mailto:ginsber= g@cisco.com]
Sent: Tuesday, July 5, 2016 10:55 PM
To: bruno.decraene@orange.com
Cc: spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Bruno –

 

Two comments:

 

1)As we both can come = up with examples where a given  preference algorithm will result in &#= 8220;better” behavior than another, continuing to debate which one is= “best” has no end. The answer depends upon what types of errors are introduced in the configuration and that isn’t predict= able. If it is necessary for us to agree on which algorithm is “best&= #8221; I doubt that consensus will ever be reached. It therefore is more im= portant to me to focus on implementation complexity and the importance of identifying and correcting misconfigurations ASAP.

 

2)There are two logica= l databases that an implementation has to support. One of them is the set o= f received advertisements which can include entries with a variety of range= s. The second one is the set of mapping entries which are in use for lookups.

Your discussion of you= r “per FEC algorithm”  below defines the second database a= s a set of entries all of which have a range of 1. Whether this is good imp= lementation model or not I am not commenting on here. But this does not eliminate the need to maintain the first database –= ; and to be able to associate entries in the second database with the corre= sponding received entry from which they may have been derived. There is wor= k in maintaining that relationship which does not directly bear on the lookup for a given SID but still has to be d= one if one uses “per FEC” or “Ignore Overlap Only”.= This work is not required for the “per range” or “Quaran= tine” algorithm. It is this additional work that I refer to when I sa= y that “per FEC” has a higher implementation cost/complexity.

 

   Les<= /o:p>

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Tuesday, July 05, 2016 1:50 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Please see inline [Bru= no]

 

From: Les Ginsberg (ginsberg) [= mail= to:ginsberg@cisco.com]
Sent: Tuesday, July 05, 2016 9:08 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

Consider the following= simple case:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2: (SRMS, 1.1.1= .1/32, 200, 10, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

There is a misconfigur= ation here, but we don’t know what was really intended. A few (of man= y) possibilities:

 

ERROR #1:   = Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !Starting SID e= rror

ERROR #2:  Entry = #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Starting prefix erro= r

 

The draft defines two = candidate preference rules which could be applied:

 

Quarantine<= /span>

----------------<= /o:p>

As we evaluate prefix = conflicts first, we compare Entry #1 and Entry #2 and choose Entry #1 the w= inner (source is PFX). Entry #2 is then not used (quarantined) and the set = of active entries is:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

Ignore Conflict Only

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

In this case we split = Entry #2 into two derived entries:

 

Entry #2A: (SRMS, 1.1.= 1.1/32, 200, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

 

Entry 2A is then ignor= ed and we then have to evaluate SID conflicts between the derived entry 2B = and Entry #3.  For this we have to split Entry 3 into two derived entr= ies:

 

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

Entry #3B: (SRMS, 2.2.= 2.3/32, 201, 9. 0, 0)

 

Entry 2B wins over ent= ry 3B since it has a smaller range.

 

Active entries are the= n:

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

 

Note that in this exam= ple both preference rules result in 11 destinations having non-conflicting = SIDs.

[Bruno] Yes. The impor= tant part is =AB in this example =BB. Now do we agree that in ave= rage, Quarantine will result in dropping more destinations than Ignore conf= lict only?

 

 Now, which of th= ese maximizes delivery of traffic? The answer to that depends upon the type= of configuration error that was made.

If Error #1 was made, = there is no way to differentiate the two preference rules.

However, if Error #2 w= as made, then Quarantine is clearly better because the destinations 1.1.1.2= – 1.1.1.10 were never intended to have assigned SIDs and may not eve= n exist as destinations in the network, yet “Ignore Conflict Only” favors those prefixes.

 

The point I am trying = to make is that it is incorrect to say “If we maximize the number of = advertised entries which we use we will always do a better job of deliverin= g traffic.” This example illustrates that this isn’t always true.

[Bruno] OK. Clearly, w= e can find an example where an algorithm is better than the other. After al= l, we all agree that there has been a configuration error.

There are 2 points:

a)&n= bsp;      how many desti= nation you keep using

b)&n= bsp;     in case of con= flict which of the entries you select

 

I agree that “b&= #8221; is more or less random and hence there are many cases where we’= ;ll pick the wrong one. Yet, we try to make reasonable choices. That the po= int of discussing the preference algorithm (3.2.4). (Although it’s very easy to argue that we can make the wrong choice, I donR= 17;t feel that’s a reason not to try discussing it and make choice. e= .g. “PFX source wins over SRMS s= ource” is one: we give preference to SR nodes rather than LDP nodes.

 

Regarding a, I feel th= at maximizing the number of destinations kept, is likely to give the best r= esult in average. I don’t have a proof, but it feel like playing loto= : even if each choice is random (“b”), the more you try (“a”) the better your chances.  <= /span>

 

 

A few more comments in= line.

 

 

From: bruno.decraene@orange.com [mailto:bru= no.decraene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Please see inline [Bruno]

 

 

From: Les Ginsberg (ginsberg) [= mail= to:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:12 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I don’t find you= r representation complete as regards all of the attributes which are propos= ed to be used by the conflict resolution algorithm – so it is therefo= re hard for me to use/understand this representation when applying the defined preference rule.

This is true for me ev= en after reading your explanations below.

 

But it is far more imp= ortant to have a common understanding of the algorithm proposal than it is = to be arguing over whose encoding is “better”. If the encoding = in the draft is not clear or could use improvement, I welcome your feedback.

 

As far as your “= pseudo-code”:

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

The fact that you can = represent an algorithm in a few lines does not mean the implementation of t= he algorithm is just as simple.

 

[Bruno] Sure. But if we want to compare implementati= on complexity, we’ll need to agree on how much we want to go into det= ails, in order to have meaningful comparison. So far this is not clear to m= e as you sometimes argue that data structure is implementation specific and you don’t want to go into this (which= I agree) and sometime you detail the data structure.

There is also the option to consider this as “= implementation issue” and let this to implementations.

 

Coming back to my per FEC algo, all what is required= from the data structure, is a way/API to get the data back, though 2 keys:= get me the SID matching prefix P1 (for the first line), get me the prefixe= s matching the SID SIDi for the second line. That seem like a reasonable requirement on the data structure, and a= ny option in your draft also requires this to detect prefix conflict and SI= D conflict (since this is all my per FEC algo is doing in these 2 first lin= es).

 

Going into more details, my per FEC algo only requir= es to detail that one prefix or SID belong to a range (of prefix or SID) wh= ile your per range algo requires to compute range intersection which is har= der. So the API to fetch the data can only be easier.

 

 

[Les:] Range int= ersection is easy to compute – the algorithm is present in the draft = at the end of  Section 3.1.1.

[Bruno] In order to ha= ve a meaningful discussion, we need to define the level of details that we = want to take into account, because you’re not using the same one to d= iscuss your algo and mine.

1) As a first level of= comparison, using the description at the end of section 3.1.1 as a model, = for range prefix conflict your algo is:

   1)(T1 =3D=3D T2) && (A1 =3D=3D A2)

   2)P1 <=3D P2

   3)The prefixes are in the same address family= .

   2)L1 =3D=3D L2

   3)(P1e >=3D P2) && ((S1 + (P2 = - P1)) !=3D S2)

 

So for (FEC) prefix co= nflict my algo is:

   1)(T1 =3D=3D T2) && (A1 =3D=3D A2)

   2)P1 =3D P2

   3)The prefixes are in the same address family= .

   2)L1 =3D=3D L2

 

(BTW, in the draft, th= ere is a typo in the numbering)

It looks clear that FE= C comparison is easier than prefix range intersection.

 

2) Going deeper, at th= e algo complexity

 

The FEC algo needs: ge= t_SIDs(Prefix), and all the work is done. So all the algo complexity is com= ing from the datastructure. It seems pretty reasonable to find a datastruct= ure << o(n) (e.g. a tree, but you will be much better than me in finding one)

For the range algo, it= ’s not clear to me that a data structure can be found to automaticall= y find the result. If not, the algo seems to compare all entries two by two= , which would get o(n*(n-1)…(2)) i.e. o(n!)

 

 

 

 

Consider what needs to= be done to implement

 

   “Fi= nd all SIDi advertised for the prefix P1”

 

In its simplest form, = we have a list of all SID advertisements (PFX and SRMS) that we have receiv= ed. One could imagine walking all the entries, looking to see if the prefix= of interest is present within the advertised range. But, of course, at large scale such an approach is extremely ineffi= cient – so we immediately start considering ways to improve performan= ce. Inserting received entries into an ordered tree of some kind is an obvi= ous way to improve performance. When one further considers that calculating conflict resolution only needs to be do= ne when a change to the received database occurs (which post startup is inf= requent) it becomes very attractive to cache the “winning entriesR= 21; so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database = – ignoring the losers.

[Bruno] I agree that the per range algo (ignore over= lap only) will be able to ignore the losers but at the cost of a more compl= ex algo and at the cost of creating new derived entries. It’s not cle= ar to me if the net result is positive. Plus I would expect that the number of conflit is small compared to the nu= mber of prefix /SID so this looks like a second order optimization.

 

In this context, we ca= n appreciate the difference between the three proposed algorithms. In parti= cular comparing “Quarantine” with “ignore overlap only= 221;, a key difference is that “Quarantine” only needs to deter= mine whether a received entry is a winning entry or a losing entry. “Igno= re overlap only” has to be capable of breaking received entries with = ranges > 1 into multiple “derived” entries (some winning, so= me losing), which means we now need to track the “derived entriesR= 21; against the original received entry so that if the received entry is updat= ed/deleted we can find all the derived entries and delete/regenerate the de= rived entries as needed. This is what adds complexity.

[Bruno] and that it why the per FEC algo seems easie= r.

So it would seem useful to add it in the draft so th= at we can all discuss it.

 

[Les:] Ignore ov= erlap only is the same as per FEC. We may use different words to describe i= t, but the end behavior is the same.

[Bruno] good if this g= et the same result. Yet the algo is different.

 

-- Bruno

 

   Les=

 

 

All proposed algorithm= s can be implemented, but it does seem prudent to consider implementation c= omplexity as part of our decision process – and the discussion/exampl= es in Section 3 are meant to help in doing this.

 

It is worthwhile resta= ting that when conflicts are present we cannot guarantee that forwarding wi= ll work correctly no matter what algorithm is used.

[Bruno] I’m not sure to see what you have in m= ind exactly. Can you elaborate? To me consistency seem enough.

 The more complex= the implementation the more likely it is that bugs will be present and the= more likely it is that interoperability issues will arise. Whether these c= osts/risks are worth the “value add” when the outcome cannot be guaranteed to be correct – only guaranteed to = be consistent – is an important consideration.

 

Also important to reme= mber that conflicts MUST be eliminated by correcting the misconfigurations = that caused them – so conflict resolution is really only an interim m= easure until the corrections can be made.

[Bruno] By “interim” we are at minimum t= alking about 10s of minutes, if not more than 1 hour since identifying the = root cause may not be obvious. The impact is very significant on the networ= k.

The “Quarantine” algo has the potential = to kill 100s PE and 1000s of VPN customers, so a single configuration chang= e on a unrelated router which may not even be in production (i.e. where con= figuration checks and operations hours may be relaxed)

 

 

No one should be lulle= d into thinking that because we have conflict resolution deployed that corr= ecting the configuration when conflicts are detected is not a priority.

[Bruno] I could not agree more that conflict needs t= o be identified and fixed. Note that I’m the one having asked for def= ining YANG notifications to report this.

You are welcomed to state in the draft that conflict= s needs to be reported to the network operator, in particular though yang n= otification, and other existing means. Plus that network operator needs to = fixed them ASAP (but still carefully)

 

Thanks

--Bruno

 

   Les<= /o:p>

 

 

From: bruno.decraene@orange.com [mailto:bru= no.decraene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks for the discuss= ion. Please see inline [Bruno]

 

 

From: Les Ginsberg (ginsberg) [= mail= to:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

As the thread below do= cuments, I stated that I did not understand your representation and asked f= or clarification – suggesting that you use the format defined in the = draft.

You stated that you co= uld not do that and we were at a point where no progress could be made.

[Bruno] I could _no= t_ use your format since your format did not include the information ne= ed. This is not a whim but a technical issue. So I asked you to still consi= der the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification q= uestions on the points which were not clear, or at least explicitly refusin= g to consider the email.

I also note that what bothered you in my=
 representation was my addition of the type of advertisement (prefix or MS)=
. But you finally have just added in the latest version of the draft “=
; . So there w=
as probably a way to communicate.

 

 

Besides the algo did n= ot use any specification representation, just names. So I’ll copy/pas= te it below, please ask clarification questions for the parts which are not= clear enough.

 

The problem that we ne= ed to solve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advert= ised for the prefix P1         = ;            &n= bsp;            = ;            &n= bsp;            // i= dentification of Prefix conflicts

   &nbs= p;            - For = each SIDi find all the prefix Pij associated with SIDi   &nb= sp;          // identification= of SID conflicts

 

// as a result, for P1= , we get a list of (SIDi, Pij)

 

Get the best (SIDi, Pi= j) as per the preference algorithm.

If best Pij =3D=3D P1<= o:p>

   &nbs= p;            then u= se SIDij for P1

   &nbs= p;            else r= eturn no SID          &nb= sp;            =    / no SID available for this prefix P1

 

 

 

To illustrate my confu= sion, one of your examples is:

 

For R2, the algo evaluates a conflict between the following advertismen= ts:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

 

Now, what does “= R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]

- MS/prefix SID is the= type of advertisement. In your new version, you call it SRMS/PFX.

- SID is the SID found= in the Mapping Entrie

- Rx is the loopback (= prefix) or router Rx

 

So “R2 - SID2 - R2 (MS, MS)” is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

 

Does it mean  = 220;On R2, SID2 is assigned to prefix R2 from two different mapping server = entries?” I really have no idea.

 

And you conclude the e= xample by saying

 

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID))

   =3D=3D> SID12 is selected for R2.=

 

But since there is no = representation of “range” in your examples I really have no ide= a how you came to this conclusion .

[Bruno] I agree that s= ince the above algo used 2 mapping entries to provides the (SIDi, Pij), the= preference algo (=A73.2.4) would need to be adapted. That being said, this= is not important for this discussion. Let’s just considered that their exist a preference algorithm, which= takes as input a list of (SIDi, Piij) for P1, and gives as outpout the = 220;best” one. (definition of “best” is not pertinent)

 

 

??

 

As regards “per = FEC/Prefix”, I believe this is what “ignore overlap only”= does.

[Bruno] Indeed, this i= s my expectation. But I would need someone’s review to confirm this.<= o:p>

But the difference is = that the proposed algo is simple (2 lines of pseudo code), with very modest= resquirement data structure use to store the mapping entries. Indeed, all = it needs is a function returning the list of mapping entries associated/matching a given prefix. And function r= eturning the list of mapping entries associated/matching a given SID.<= /o:p>

In particular, there i= s no need for splitting mapping entries which is the main complexity of you= r proposed “Preference algorithm/ignore overlap only”. (accordi= ng to your own text).

 

-- Bruno

 

 

    Les=

 

 

From: bruno.decraene@orange.com [mailto:bru= no.decraene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks for the updated= draft.

 

IINM, you have not ans= wered my below email/proposal. I had waited for the new version of the draf= t but it also does not touch this subject.

 

So, could you please c= onsider and answer my comment?

 

In short, in an implem= entation-independent sentence:

 

> I'm wondering if we could address the conflict = on a per FEC/Prefix basis rather than on a per IGP advertisement (range) ba= sis.

> If so, this may avoid the discussion between th= e Quarantine vs ignore policy.

 

 

Thanks

Bruno

 

 

From: spring [mailto:spring-bo= unces@ietf.org] On Behalf Of bruno.decraene@orange.com Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]

 

From: Les Ginsberg (ginsberg) [= mail= to:ginsberg@cisco.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce.

[Bruno] My text does not incorporate the source, but= the type of source IOW the type of sub-TLV.

 

So it does not matter = if R2 sends an advertisement or R12 sends advertisement or both of them do = (which could happen when an advertisement is leaked) – what matters i= s what unique entries are in the database independent of source.

[Bruno] It may not matter for your algorithm (pendin= g another thread), but it does for the one I proposed.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

[Bruno] My examples are described in plain text. The= n the examples giving intermediate steps of my algo uses the data that are = needed i.e. the type of advertisement (Prefix-SID vs MS).

Then finally, my algo runs on a per FEC/IP Prefix ba= sis, and not on a per IGP advertisement basis which your format describe.

So I’m sorry but I don’t see how to indu= lge your request.

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /i>

     Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

     Pe =3D (Pi + ((= R-1) << (Lx-L))

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

this to me specifies a= n implementation – which isn’t necessary.

[Bruno] Well, _you_ are the one talking about= implementation, and more specifically implementation complexity.

Assuming the above algo works, it looks relatively s= imple to implement, in which case, I would not buy the argument about imple= mentation complexity which is the only argument in favor or the “igno= re” or “quarantine” policy.

Bottom line, I would welcome your feedback and comme= nts on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

 

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:=

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:<= /o:p>

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [mailto:spring-bo= unces@ietf.org] On Behalf Of bruno.decraene@orange.com Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_BN3PR05MB2706EC1E9B5DEB1752AFB768D5300BN3PR05MB2706namp_-- From nobody Tue Jul 12 08:25:35 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C377412D8D4 for ; Tue, 12 Jul 2016 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCTSenl_ZRCd for ; Tue, 12 Jul 2016 08:25:31 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48E812D526 for ; Tue, 12 Jul 2016 07:59:48 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 862EBC0241 for ; Tue, 12 Jul 2016 16:59:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 6174F4009D for ; Tue, 12 Jul 2016 16:59:47 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0301.000; Tue, 12 Jul 2016 16:59:47 +0200 From: To: "spring@ietf.org" Thread-Topic: IETF 96 - SPRING agenda Thread-Index: AdHcTIe2PydrFElJR/W9qduqmYMYiA== Date: Tue, 12 Jul 2016 14:59:46 +0000 Message-ID: <13016_1468335587_578505E3_13016_2604_1_53C29892C857584299CBF5D05346208A0F94BB1B@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F94BB1BOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] IETF 96 - SPRING agenda X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:25:34 -0000 --_000_53C29892C857584299CBF5D05346208A0F94BB1BOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Agenda has been uploaded: https://www.ietf.org/proceedings/96/agenda/agenda= -96-spring We have a full agenda so we would appreciate early volunteering for jabber = and minutes taker. e.g. using the collaborative etherpad http://etherpad.tools.ietf.org:9000/p= /notes-ietf-96-spring?useMonospaceFont=3Dtrue Speakers, - please send your slides to the co-chairs no later than 24 hours in advanc= e (i.e. Sunday 18:00 local time). - you may consider the following checklist https://tools.ietf.org/wg/spring= /trac/wiki/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting See you in Berlin. Thanks, -- Bruno, John ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F94BB1BOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Agenda has been uploaded: <= span lang=3D"EN-US">https://www.ietf.org/proceedings/96/agenda/agenda-96-sp= ring

 

We have a full agenda so we wou= ld appreciate early volunteering for jabber and minutes taker.

e.g. using the collaborative et= herpad http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-spring?useMonospaceFont= =3Dtrue

 

 

Speakers,

- please send your slides to th= e co-chairs no later than 24 hours in advance (i.e. Sunday 18:00 local time= ).

- you may consider the followin= g checklist https://tools.ietf.org/wg/spring/trac/wiki/Checklist%20for%20presenting%20a= t%20a%20SPRING%20meeting

 

See you in Berlin.

 

Thanks,

-- Bruno, John

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F94BB1BOPEXCLILM21corp_-- From nobody Tue Jul 12 08:37:24 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0D12D875; Tue, 12 Jul 2016 08:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EVdNDb0HNf0; Tue, 12 Jul 2016 08:37:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A247512DA89; Tue, 12 Jul 2016 08:22:59 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id CC67E2DC088; Tue, 12 Jul 2016 17:22:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A3B5027C505; Tue, 12 Jul 2016 17:22:57 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0301.000; Tue, 12 Jul 2016 17:22:57 +0200 From: To: "John G. Scudder" Thread-Topic: SPRING WGLC for draft-ietf-spring-resiliency-use-cases Thread-Index: AQHR3E/xu/S48gdLvkO/czttULUR8qAU6KyQ Date: Tue, 12 Jul 2016 15:22:56 +0000 Message-ID: <29642_1468336977_57850B51_29642_5534_1_53C29892C857584299CBF5D05346208A0F94BC13@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <8101D467-27D9-45CA-ACE6-3435D7E2A213@juniper.net> In-Reply-To: <8101D467-27D9-45CA-ACE6-3435D7E2A213@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.12.135417 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-spring-resiliency-use-cases@ietf.org" , RTGWG Subject: Re: [spring] SPRING WGLC for draft-ietf-spring-resiliency-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:37:19 -0000 Sm9obiwNCg0KSSdtIG5vdCBhd2FyZSBvZiBub24tZGlzY2xvc2VkIElQUiBvbiB0aGlzIHVzZS1j YXNlcy9yZXF1aXJlbWVudHMgZG9jdW1lbnQuDQoNClRoYW5rcw0KLS0gQnJ1bm8NCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaG4gRy4gU2N1ZGRlciBbbWFpbHRv Ompnc0BqdW5pcGVyLm5ldF0NCj4gU2VudDogVHVlc2RheSwgSnVseSAxMiwgMjAxNiA0OjQ0IFBN DQo+IFRvOiBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc3ByaW5nLXJlc2lsaWVuY3ktdXNl LWNhc2VzQGlldGYub3JnDQo+IENjOiBydGd3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBTUFJJTkcg V0dMQyBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctcmVzaWxpZW5jeS11c2UtY2FzZXMNCj4gDQo+IERl YXIgU1BSSU5HIFdHIChhbmQgSSd2ZSB0YWtlbiB0aGUgbGliZXJ0eSBvZiBjYydpbmcgUlRHV0cp LA0KPiANCj4gVGhlIGF1dGhvcnMgaGF2ZSBpbmRpY2F0ZWQgdGhhdCBkcmFmdC1pZXRmLXNwcmlu Zy1yZXNpbGllbmN5LXVzZS1jYXNlcyBpcyByZWFkeSBmb3IgV0dMQy4NCj4gUGxlYXNlIHNlbmQg eW91ciBjb21tZW50cyB0byBzcHJpbmdAaWV0Zi5vcmcuIFdlIHdpbGwgcGxhbiB0byBlbmQgdGhl IFdHTEMgb24gSnVseSAzMS4gSQ0KPiBub3RpY2UgdGhhdCB0aGVyZSBpcyBhbiBvdXRzdGFuZGlu ZyBxdWVzdGlvbiBmcm9tIEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IDxBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbT4sIHNlbnQgdG8gdGhlIGxpc3Qgb24gSnVseSAxMCAtLSBhdXRob3Jz LCBwbGVhc2UgY29uc2lkZXINCj4gaGlzIG5vdGUgdG8gYmUgcGFydCBvZiB0aGUgV0dMQyBhbmQg cmVzcG9uZCBhY2NvcmRpbmdseS4NCj4gDQo+IEF1dGhvcnM6IEluIHBhcmFsbGVsIHdpdGggdGhl IFdHTEMsIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgbWVzc2FnZSAobWFraW5nIHN1cmUgeW91IGNj DQo+IHNwcmluZ0BpZXRmLm9yZykgYW5kIGluZGljYXRlIGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55 IHJlbGV2YW50IElQUi4gUGxlYXNlIGRvIHRoaXMgZXZlbiBpZiBpdA0KPiBoYXMgYmVlbiBwcmV2 aW91c2x5IGRpc2Nsb3NlZC4gVGhhbmtzLg0KPiANCj4gVGhhbmtzIHRvIFN0w6lwaGFuZSBMaXRr b3dza2kgZm9yIGFncmVlaW5nIHRvIGJlIGRvY3VtZW50IHNoZXBoZXJkLg0KPiANCj4gUmVnYXJk cywNCj4gDQo+IC0tSm9obg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Fri Jul 22 00:29:44 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAB12DC0F; Fri, 22 Jul 2016 00:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160722072939.12256.96268.idtracker@ietfa.amsl.com> Date: Fri, 22 Jul 2016 00:29:39 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-07.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:29:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : IPv6 SPRING Use Cases Authors : John Brzozowski John Leddy Mark Townsley Clarence Filsfils Roberta Maglione Filename : draft-ietf-spring-ipv6-use-cases-07.txt Pages : 13 Date : 2016-07-22 Abstract: Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to the SPRING node or global within the SPRING domain. SPRING allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SPRING domain. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-ipv6-use-cases-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 22 01:59:09 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716C812D9F9 for ; Fri, 22 Jul 2016 01:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny8M9FaAQlm3 for ; Fri, 22 Jul 2016 01:59:01 -0700 (PDT) Received: from owl2.lab.dtag.de (unknown [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 59D9212D7DE for ; Fri, 22 Jul 2016 01:59:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 446EECC53E; Fri, 22 Jul 2016 10:58:59 +0200 (CEST) Received: from Martins-MacBook-Air.local (o-Boggart.lab.dtag.de [62.153.176.78]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id 0503ACC4DC; Fri, 22 Jul 2016 10:58:59 +0200 (CEST) To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> From: Martin Horneffer Message-ID: <0039f4f2-e09a-f61c-6089-9a488d8bf2da@nic.dtag.de> Date: Fri, 22 Jul 2016 10:59:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Horneffer, Martin" Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Rule X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:59:03 -0000 Hi Les, this topic, and this document is in my eyes a very important one. Thanks a lot for writing and promoting it! During the Berlin WG session you proposed a new preference rule which would make the policy choice easier. You asked for a discussion on the list - more on your slides rather than the existing draft document. As an operator, and as an individual that has insight in more than just one or two IP/MPLS carrier networks, that has the main engineering responsibility for a rather large backbone, and that stays in actual contact with the operational staff and security authorities, I strongly ask you: PLEASE DO NOT CHANGE THE PREFERENCE RULE! The first two elements of the preference rule are, in my eyes, the most important ones of the whole document and must not be changed or dropped! 1) PFX source wins over SRMS soucre 2) Smaller range wins Why is this so important? I don't care so much about the _amount_ of traffic that would be affected by a conflict. No amount of traffic lost due to a network design or configuration error is permissible. But I do care about the overall _robustness_ and _security_ of the network. Of course - in terms of security a first approximation would say that segment routing plays within the IGP only, and that the IGP needs to be trusted anyways. It must be secured against the outside. While this is true, I nevertheless would like to differentiate a bit more. For the sake of robustness, and possibly also for security, I would like to apply the following guidelines: a) Effects of local misconfiguration should be as local as possible. b) The more reliable and controllable source should win over a less reliable or controllable one. As I see it, both guidelines lead to a clear preference of PFX sources over SRMS sources. Also the preference for smaller ranges seems to fit. Please do consider environments where more and more formely separate IP/MPLS networks get merged into a single IGP domain. I am seeing this a lot since a couple of years - several times within DT, but also at other carriers. Sometimes this is done as a complete merge e.g. into a single IS-IS area, sometimes different areas are used, and sometimes seperate IGP instances are maintained but connected. While redistributing from one IGP area or instance to the other you can do more or less filtering, but it definitely is being done. Thus, even within the IGP filters and policies are being applied - be it for the sake of security or scalability. While there are well-known mechanisms and tools to filter and control prefix redistribution, I am not so sure about SRMS. I'm going to also write my opinion about the policy selection, but keeping the preference rule really is my main concern. BR, Martin From nobody Fri Jul 22 02:01:35 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C1012DAAC for ; Fri, 22 Jul 2016 02:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5X_n5G-wuX9 for ; Fri, 22 Jul 2016 02:01:29 -0700 (PDT) Received: from owl2.lab.dtag.de (unknown [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id C57C012D7D8 for ; Fri, 22 Jul 2016 02:01:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 26B33CC778; Fri, 22 Jul 2016 11:01:28 +0200 (CEST) Received: from Martins-MacBook-Air.local (o-Boggart.lab.dtag.de [62.153.176.78]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id 0B841CC677; Fri, 22 Jul 2016 11:01:27 +0200 (CEST) To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> <91fcbdba712143e890609f6a513f8528@XCH-ALN-001.cisco.com> <2921_1467708583_577B74A7_2921_256_5_53C29892C857584299CBF5D05346208A0F92B91D@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Martin Horneffer Message-ID: <73326a2e-90d2-1af8-689c-0cc08f396ad6@nic.dtag.de> Date: Fri, 22 Jul 2016 11:01:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5F9094D5D2B0C3E0D7D4D6A0" Archived-At: Cc: "Horneffer, Martin" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:01:34 -0000 This is a multi-part message in MIME format. --------------5F9094D5D2B0C3E0D7D4D6A0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Les, commenting rather on your presentation at the Berlin WG session: In general I don't consider it a big deal whether the Quarantine or the Ignore Overlap policy is being used. It's mainly important that _one_ of then finally gets chosen and consistently implemented. From the operator's point of view I tend to agree with other operators that the Ignore Overlap policy looks better for most realistic cases, even though less worried about the amount of traffic lost, but more about robustness and security aspects. Complexity of implementation, however, can be a serious argument against it, as this also works against robustness and security. Nobody doubts that the Ignore Overlap policy is more complex. But how much complexity it really adds is hard to estimate for me. Is it a minor complication or a big one? So far I have seen one vendor talk against the Ignore Overlap policy and two vendors taking a position in favor of it. Sounds to me like 2:1 for Ignore Overlap so far. But we actually don't believe in voting and need more vendor input anyways! BR, Martin Am 05.07.16 um 19:25 schrieb Les Ginsberg (ginsberg): > > Bruno – > > Two comments: > > 1)As we both can come up with examples where a given preference > algorithm will result in “better” behavior than another, continuing to > debate which one is “best” has no end. The answer depends upon what > types of errors are introduced in the configuration and that isn’t > predictable. If it is necessary for us to agree on which algorithm is > “best” I doubt that consensus will ever be reached. It therefore is > more important to me to focus on implementation complexity and the > importance of identifying and correcting misconfigurations ASAP. > > 2)There are two logical databases that an implementation has to > support. One of them is the set of received advertisements which can > include entries with a variety of ranges. The second one is the set of > mapping entries which are in use for lookups. > > Your discussion of your “per FEC algorithm” below defines the second > database as a set of entries all of which have a range of 1. Whether > this is good implementation model or not I am not commenting on here. > But this does not eliminate the need to maintain the first database – > and to be able to associate entries in the second database with the > corresponding received entry from which they may have been derived. > There is work in maintaining that relationship which does not directly > bear on the lookup for a given SID but still has to be done if one > uses “per FEC” or “Ignore Overlap Only”. This work is not required for > the “per range” or “Quarantine” algorithm. It is this additional work > that I refer to when I say that “per FEC” has a higher implementation > cost/complexity. > > Les > > *From:*bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > *Sent:* Tuesday, July 05, 2016 1:50 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Les, > > Please see inline [Bruno] > > *From:*Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > *Sent:* Tuesday, July 05, 2016 9:08 AM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Bruno – > > Consider the following simple case: > > Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) > > Entry #2: (SRMS, 1.1.1.1/32, 200, 10, 0,0) > > Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) > > There is a misconfiguration here, but we don’t know what was really > intended. A few (of many) possibilities: > > ERROR #1: Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) > !Starting SID error > > ERROR #2: Entry #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) > !Starting prefix error > > The draft defines two candidate preference rules which could be applied: > > Quarantine > > ---------------- > > As we evaluate prefix conflicts first, we compare Entry #1 and Entry > #2 and choose Entry #1 the winner (source is PFX). Entry #2 is then > not used (quarantined) and the set of active entries is: > > Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) > > Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) > > Ignore Conflict Only > > ------------------------- > > In this case we split Entry #2 into two derived entries: > > Entry #2A: (SRMS, 1.1.1.1/32, 200, 1, 0,0) > > Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) > > Entry 2A is then ignored and we then have to evaluate SID conflicts > between the derived entry 2B and Entry #3. For this we have to split > Entry 3 into two derived entries: > > Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) > > Entry #3B: (SRMS, 2.2.2.3/32, 201, 9. 0, 0) > > Entry 2B wins over entry 3B since it has a smaller range. > > Active entries are then: > > Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) > > Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) > > Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) > > Note that in this example both preference rules result in 11 > destinations having non-conflicting SIDs. > > [Bruno] Yes. The important part is « in this example ». Now do we > agree that in average, Quarantine will result in dropping more > destinations than Ignore conflict only? > > Now, which of these maximizes delivery of traffic? The answer to that > depends upon the type of configuration error that was made. > > If Error #1 was made, there is no way to differentiate the two > preference rules. > > However, if Error #2 was made, then Quarantine is clearly better > because the destinations 1.1.1.2 – 1.1.1.10 were never intended to > have assigned SIDs and may not even exist as destinations in the > network, yet “Ignore Conflict Only” favors those prefixes. > > The point I am trying to make is that it is incorrect to say “If we > maximize the number of advertised entries which we use we will always > do a better job of delivering traffic.” This example illustrates that > this isn’t always true. > > [Bruno] OK. Clearly, we can find an example where an algorithm is > better than the other. After all, we all agree that there has been a > configuration error. > > There are 2 points: > > a)how many destination you keep using > > b)in case of conflict which of the entries you select > > I agree that “b” is more or less random and hence there are many cases > where we’ll pick the wrong one. Yet, we try to make reasonable > choices. That the point of discussing the preference algorithm > (3.2.4). (Although it’s very easy to argue that we can make the wrong > choice, I don’t feel that’s a reason not to try discussing it and make > choice. e.g. “PFX source wins over SRMS source” is one: we give > preference to SR nodes rather than LDP nodes. > > Regarding a, I feel that maximizing the number of destinations kept, > is likely to give the best result in average. I don’t have a proof, > but it feel like playing loto: even if each choice is random (“b”), > the more you try (“a”) the better your chances. > > A few more comments inline. > > *From:*bruno.decraene@orange.com > [mailto:bruno.decraene@orange.com] > *Sent:* Monday, July 04, 2016 5:07 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Les, > > Please see inline [Bruno] > > *From:*Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > *Sent:* Friday, July 01, 2016 3:12 AM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Bruno – > > I don’t find your representation complete as regards all of the > attributes which are proposed to be used by the conflict resolution > algorithm – so it is therefore hard for me to use/understand this > representation when applying the defined preference rule. > > This is true for me even after reading your explanations below. > > But it is far more important to have a common understanding of the > algorithm proposal than it is to be arguing over whose encoding is > “better”. If the encoding in the draft is not clear or could use > improvement, I welcome your feedback. > > As far as your “pseudo-code”: > > /- Find all SIDi advertised for the prefix P1 // identification of > Prefix conflicts/ > > / - For each SIDi find all the prefix Pij associated > with SIDi // identification of SID conflicts/ > > // > > /Get the best as per the preference algorithm./ > > /If best Pij == P1/ > > / then use SIDij for P1/ > > / else return no SID/ > > The fact that you can represent an algorithm in a few lines does not > mean the implementation of the algorithm is just as simple. > > [Bruno] Sure. But if we want to compare implementation complexity, > we’ll need to agree on how much we want to go into details, in order > to have meaningful comparison. So far this is not clear to me as you > sometimes argue that data structure is implementation specific and you > don’t want to go into this (which I agree) and sometime you detail the > data structure. > > There is also the option to consider this as “implementation issue” > and let this to implementations. > > Coming back to my per FEC algo, all what is required from the data > structure, is a way/API to get the data back, though 2 keys: get me > the SID matching prefix P1 (for the first line), get me the prefixes > matching the SID SIDi for the second line. That seem like a reasonable > requirement on the data structure, and any option in your draft also > requires this to detect prefix conflict and SID conflict (since this > is all my per FEC algo is doing in these 2 first lines). > > Going into more details, my per FEC algo only requires to detail that > one prefix or SID belong to a range (of prefix or SID) while your per > range algo requires to compute range intersection which is harder. So > the API to fetch the data can only be easier. > > */[Les:] Range intersection is easy to compute – the algorithm is > present in the draft at the end of Section 3.1.1./* > > [Bruno] In order to have a meaningful discussion, we need to define > the level of details that we want to take into account, because you’re > not using the same one to discuss your algo and mine. > > 1) As a first level of comparison, using the description at the end of > section 3.1.1 as a model, for range prefix conflict your algo is: > > 1)(T1 == T2) && (A1 == A2) > > 2)P1 <= P2 > > 3)The prefixes are in the same address family. > > 2)L1 == L2 > > 3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2) > > So for (FEC) prefix conflict my algo is: > > 1)(T1 == T2) && (A1 == A2) > > 2)P1 = P2 > > 3)The prefixes are in the same address family. > > 2)L1 == L2 > > (BTW, in the draft, there is a typo in the numbering) > > It looks clear that FEC comparison is easier than prefix range > intersection. > > 2) Going deeper, at the algo complexity > > The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all > the algo complexity is coming from the datastructure. It seems pretty > reasonable to find a datastructure << o(n) (e.g. a tree, but you will > be much better than me in finding one) > > For the range algo, it’s not clear to me that a data structure can be > found to automatically find the result. If not, the algo seems to > compare all entries two by two, which would get o(n*(n-1)…(2)) i.e. o(n!) > > Consider what needs to be done to implement > > “Find all SIDi advertised for the prefix P1” > > In its simplest form, we have a list of all SID advertisements (PFX > and SRMS) that we have received. One could imagine walking all the > entries, looking to see if the prefix of interest is present within > the advertised range. But, of course, at large scale such an approach > is extremely inefficient – so we immediately start considering ways to > improve performance. Inserting received entries into an ordered tree > of some kind is an obvious way to improve performance. When one > further considers that calculating conflict resolution only needs to > be done when a change to the received database occurs (which post > startup is infrequent) it becomes very attractive to cache the > “winning entries” so that if one wants to retrieve the SID for a given > prefix we only have to examine a subset of the total database – > ignoring the losers. > > [Bruno] I agree that the per range algo (ignore overlap only) will be > able to ignore the losers but at the cost of a more complex algo and > at the cost of creating new derived entries. It’s not clear to me if > the net result is positive. Plus I would expect that the number of > conflit is small compared to the number of prefix /SID so this looks > like a second order optimization. > > In this context, we can appreciate the difference between the three > proposed algorithms. In particular comparing “Quarantine” with “ignore > overlap only”, a key difference is that “Quarantine” only needs to > determine whether a received entry is a winning entry or a losing > entry. “Ignore overlap only” has to be capable of breaking received > entries with ranges > 1 into multiple “derived” entries (some winning, > some losing), which means we now need to track the “derived entries” > against the original received entry so that if the received entry is > updated/deleted we can find all the derived entries and > delete/regenerate the derived entries as needed. This is what adds > complexity. > > [Bruno] and that it why the per FEC algo seems easier. > > So it would seem useful to add it in the draft so that we can all > discuss it. > > */[Les:] Ignore overlap only is the same as per FEC. We may use > different words to describe it, but the end behavior is the same./* > > [Bruno] good if this get the same result. Yet the algo is different. > > -- Bruno > > */Les/* > > *//* > > All proposed algorithms can be implemented, but it does seem prudent > to consider implementation complexity as part of our decision process > – and the discussion/examples in Section 3 are meant to help in doing > this. > > It is worthwhile restating that when conflicts are present we cannot > guarantee that forwarding will work correctly no matter what algorithm > is used. > > [Bruno] I’m not sure to see what you have in mind exactly. Can you > elaborate? To me consistency seem enough. > > The more complex the implementation the more likely it is that bugs > will be present and the more likely it is that interoperability issues > will arise. Whether these costs/risks are worth the “value add” when > the outcome cannot be guaranteed to be correct – only guaranteed to be > consistent – is an important consideration. > > Also important to remember that conflicts MUST be eliminated by > correcting the misconfigurations that caused them – so conflict > resolution is really only an interim measure until the corrections can > be made. > > [Bruno] By “interim” we are at minimum talking about 10s of minutes, > if not more than 1 hour since identifying the root cause may not be > obvious. The impact is very significant on the network. > > The “Quarantine” algo has the potential to kill 100s PE and 1000s of > VPN customers, so a single configuration change on a unrelated router > which may not even be in production (i.e. where configuration checks > and operations hours may be relaxed) > > No one should be lulled into thinking that because we have conflict > resolution deployed that correcting the configuration when conflicts > are detected is not a priority. > > [Bruno] I could not agree more that conflict needs to be identified > and fixed. Note that I’m the one having asked for defining YANG > notifications to report this. > > You are welcomed to state in the draft that conflicts needs to be > reported to the network operator, in particular though yang > notification, and other existing means. Plus that network operator > needs to fixed them ASAP (but still carefully) > > Thanks > > --Bruno > > Les > > *From:*bruno.decraene@orange.com > [mailto:bruno.decraene@orange.com] > *Sent:* Thursday, June 30, 2016 5:10 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Les, > > Thanks for the discussion. Please see inline [Bruno] > > *From:*Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > *Sent:* Wednesday, June 29, 2016 6:00 PM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Bruno – > > As the thread below documents, I stated that I did not understand your > representation and asked for clarification – suggesting that you use > the format defined in the draft. > > You stated that you could not do that and we were at a point where no > progress could be made. > > [Bruno] I could _/not/_ use your format since your format did not > include the information need. This is not a whim but a technical > issue. So I asked you to still consider the message. Rather than > waiting for a time-out, there was a way to make progress by asking > clarification questions on the points which were not clear, or at > least explicitly refusing to consider the email. > > I also note that what bothered you in my representation was my > addition of the type of advertisement (prefix or MS). But you finally > have just added in the latest version of the draft “Src- PFX or SRMS”. > So there was probably a way to communicate. > > Besides the algo did not use any specification representation, just > names. So I’ll copy/paste it below, please ask clarification questions > for the parts which are not clear enough. > > The problem that we need to solve, is to find the SID for a prefix (P1). > > The algo could be: > > - Find all SIDi advertised for the prefix P1 // identification of > Prefix conflicts > > - For each SIDi find all the prefix Pij associated with > SIDi // identification of SID conflicts > > // as a result, for P1, we get a list of (SIDi, Pij) > > Get the best (SIDi, Pij) as per the preference algorithm. > > If best Pij == P1 > > then use SIDij for P1 > > else return no SID / no SID available for > this prefix P1 > > To illustrate my confusion, one of your examples is: > > /For R2, the algo evaluates a conflict between the following > advertisments:/ > > / R2 - SID2 - R2 (MS, MS)/ > > / R2 - SID12 - R12 (prefix SID, MS) / > > / R2 - SID12 - R2 (prefix SID, prefix SID)/ > > // > > Now, what does “R2 - SID2 - R2 (MS, MS)” mean? > > [Bruno] > > - MS/prefix SID is the type of advertisement. In your new version, you > call it SRMS/PFX. > > - SID is the SID found in the Mapping Entrie > > - Rx is the loopback (prefix) or router Rx > > So “R2- SID2 - R2 (MS, MS)” is the outpout of the algo described above > and means: For prefix R2, we found a MS mapping entries advertising > SID2 for this prefix, and then I found a MS mapping entries > advertising prefix R2 for SID2. > > Does it mean “On R2, SID2 is assigned to prefix R2 from two different > mapping server entries?” I really have no idea. > > And you conclude the example by saying > > /Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range > (prefix SID))/ > > / ==> SID12 is selected for R2./ > > But since there is no representation of “range” in your examples I > really have no idea how you came to this conclusion . > > [Bruno] I agree that since the above algo used 2 mapping entries to > provides the (SIDi, Pij), the preference algo (§3.2.4) would need to > be adapted. That being said, this is not important for this > discussion. Let’s just considered that their exist a preference > algorithm, which takes as input a list of (SIDi, Piij) for P1, and > gives as outpout the “best” one. (definition of “best” is not pertinent) > > ?? > > As regards “per FEC/Prefix”, I believe this is what “ignore overlap > only” does. > > [Bruno] Indeed, this is my expectation. But I would need someone’s > review to confirm this. > > But the difference is that the proposed algo is simple (2 lines of > pseudo code), with very modest resquirement data structure use to > store the mapping entries. Indeed, all it needs is a function > returning the list of mapping entries associated/matching a given > prefix. And function returning the list of mapping entries > associated/matching a given SID. > > In particular, there is no need for splitting mapping entries which is > the main complexity of your proposed “Preference algorithm/ignore > overlap only”. (according to your own text). > > -- Bruno > > Les > > *From:*bruno.decraene@orange.com > [mailto:bruno.decraene@orange.com] > *Sent:* Wednesday, June 29, 2016 7:22 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Les, > > Thanks for the updated draft. > > IINM, you have not answered my below email/proposal. I had waited for > the new version of the draft but it also does not touch this subject. > > So, could you please consider and answer my comment? > > In short, in an implementation-independent sentence: > > > I'm wondering if we could address the conflict on a per FEC/Prefix > basis rather than on a per IGP advertisement (range) basis. > > > If so, this may avoid the discussion between the Quarantine vs > ignore policy. > > Thanks > > Bruno > > *From:*spring [mailto:spring-bounces@ietf.org] *On Behalf Of > *bruno.decraene@orange.com > *Sent:* Wednesday, May 18, 2016 1:57 PM > *To:* Les Ginsberg (ginsberg); spring@ietf.org > *Subject:* Re: [spring] draft-ietf-spring-conflict-resolution - Policy > > Les, > > Please see inline [Bruno] > > *From:*Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > *Sent:* Sunday, May 15, 2016 12:41 AM > *To:* DECRAENE Bruno IMT/OLN; spring@ietf.org > *Subject:* RE: draft-ietf-spring-conflict-resolution - Policy > > Bruno – > > I am having difficulty parsing the examples you provide below as they > seem to incorporate advertisement source into the description whereas > the draft deliberately omits source. > > [Bruno] My text does not incorporate the source, but the type of > source IOW the type of sub-TLV. > > So it does not matter if R2 sends an advertisement or R12 sends > advertisement or both of them do (which could happen when an > advertisement is leaked) – what matters is what unique entries are in > the database independent of source. > > [Bruno] It may not matter for your algorithm (pending another thread), > but it does for the one I proposed. > > It would be good if you could present your examples using the format > defined in the draft i.e.: > > [Bruno] My examples are described in plain text. Then the examples > giving intermediate steps of my algo uses the data that are needed > i.e. the type of advertisement (Prefix-SID vs MS). > > Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a > per IGP advertisement basis which your format describe. > > So I’m sorry but I don’t see how to indulge your request. > > / Pi - Initial prefix/ > > / Pe - End prefix/ > > / L - Prefix length/ > > / Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)/ > > / Si - Initial SID value/ > > / Se - End SID value/ > > / R - Range value/ > > / T - Topology/ > > / A - Algorithm/ > > // > > / A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A)/ > > ///Pe = (Pi + ((R-1) << (Lx-L))/ > > / Se = Si + (R-1)/ > > // > > /Example: (192.0.2.120/32, 200, 1, 0, 0)/ > > As regards your proposal > > /- Find all SIDi advertised for the prefix P1 // identification of > Prefix conflicts/ > > / - For each SIDi find all the prefix Pij associated > with SIDi // identification of SID conflicts/ > > // > > /Get the best as per the preference algorithm./ > > /If best Pij == P1/ > > /then use SIDij for P1/ > > /else return no SID/ > > this to me specifies an implementation – which isn’t necessary. > > [Bruno] Well, _/you/_ are the one talking about implementation, and > more specifically implementation complexity. > > Assuming the above algo works, it looks relatively simple to > implement, in which case, I would not buy the argument about > implementation complexity which is the only argument in favor or the > “ignore” or “quarantine” policy. > > Bottom line, I would welcome your feedback and comments on this > proposed algo/policy. > > Thanks, > > Regards, > > -- Bruno > > However, there is one important point which has not been specified in > the draft which reading your post has brought to my attention – that > is the order in which checks are made. > > The draft states: > > “Prefix conflicts are specific to mapping entries sharing the same > topology and algorithm.” > > “SID conflicts are independent of address-family, independent of > prefix len, independent of topology, and independent of algorithm.” > > If we consider an example where a network supports two VPNs, the > significance of ordering in the evaluation of conflicts will be > highlighted: > > VPN1: > > (192.0.2.1/32, 100, 1, 1, 0) > > (192.0.2.1/32, 200, 1, 1, 0) > > VPN2: > > (192.0.2.100/32, 200, 1, 2, 0) > > If we evaluate prefix conflicts first, then the following entries are > “active”: > > (192.0.2.1/32, 100, 1, 1, 0) !VPN1 > > (192.0.2.100/32, 200, 1, 2, 0) !VPN2 > > If we evaluate SID conflicts first, then the following entries are > “active”: > > (192.0.2.1/32, 100, 1, 1, 0) !VPN1 > > The latter choice is suboptimal because it prevents use of the VPN2 > entry unnecessarily. > > This point needs to be made explicit in the draft. > > Les > > *From:*spring [mailto:spring-bounces@ietf.org] *On Behalf Of > *bruno.decraene@orange.com > *Sent:* Thursday, May 12, 2016 8:23 AM > *To:* spring@ietf.org > *Subject:* [spring] draft-ietf-spring-conflict-resolution - Policy > > Hi authors, all > > As an individual contributor, please find below some feedback on the > policy. > > I'm wondering if we could address the conflict on a per FEC/Prefix > basis rather than on a per IGP advertisement basis. > > If so, this may avoid the discussion between the Quarantine vs ignore > policy. > > The problem that we need to solve, is to find the SID for a prefix (P1). > > The algo could be: > > - Find all SIDi advertised for the prefix P1 // identification of > Prefix conflicts > > - For each SIDi find all the prefix Pij associated > with SIDi // identification of SID conflicts > > // as a result, we get a list of SIDi – Pij for P1 > > Get the best as per the preference algorithm. > > If best Pij == P1 > > then use SIDij for P1 > > else return no SID / no SID > available for this prefix P1 > > Note that it would probably be better for the preference algo to > put the SID tie-brake before the prefix tie-break as with the prefix > tie-break, we suffer from the conflict twice (Prefix - SID mapping, > then SID- prefix mapping) which increase the diversity and hence the > chance of not finding a valid entry. But for the below examples, I > used the preference algo from draft-ietf-*-00 > > Below are examples, running this policy on typical configuration error > cases. > > Examples > > 3.4.4. Network operation > > Consider the following simple network example: > > 1. 100 nodes: R1 to R100; > > 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: > > 3. SID are from 1 to 100; > > 4. R1 to R50 are SR capable and advertised their own SID using > > Prefix-SID sub-TLV; > > 5. R51 to R100 are SR non-capable, running LDP and their SID are > > advertised by two redundant Mapping Server MS1 and MS2; > > 6. As the number of nodes which are SR capable are expected to > > increase and as in real deployment their Loopback addresses would > > no the contiguous, the Mapping servers advertisement covers all > > Loopbacks: (192.0.2.1/32, 1, 100); > > Subsequent sections evaluate the consequences of a single > > configuration error, for all conflict resolution options. > > 3.4.4.1. Example 1: SID configured on 1 node conflict with SID > > configured on another node > > Following a typo during configuration, R2 is configured with a SID of > > 12. That SID conflicts with the Prefix-SID advertised by R12 and > the Mapping Server Advertisement for R12. > > Note: both MS advertisement are the same, so we only consider one > in the below analysis. > > All prefix but R2 and R12, a single SID is advertised and hence > selected. > > For R2, the algo evaluates a conflict between the following > advertisments: > > R2 - SID2 - R2 (MS, MS) > > R2 - SID12 - R12 (prefix SID, MS) > > R2 - SID12 - R2 (prefix SID, prefix SID) > > Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller > range (prefix SID)) > > ==> SID12 is selected for R2. > > For R12, the algo evaluates a conflict between the following > advertisments: > > R12 - SID12 - R12 (prefix SID, prefix SID) > > R12 - SID12 - R2 (prefix SID, prefix SID) > > R12 - SID12 - R12 (prefix SID, MS) > > R12 - SID12 - R2 (MS, prefix SID) > > R12 - SID12 - R12 (MS, MS) > > Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller > range (prefix SID), smaller starting adresse (R2)) > > R12 <> R2 ==> R12 has no SID. > > 3.4.4.2. Example 2: SID configured on 1 node conflict with SID > > configured on the Mapping Server > > Following a typo during configuration, R2 is configured with a SID of > > 52. That SID conflicts with the Mapping Server advertisements of MS1 > > and MS2 for the loopback of R52. > > Note: both MS advertisement are the same, so we only consider one > in the below analysis. > > All prefix but R2 and R52, a single SID is advertised and hence > selected. > > For R2, the algo evaluates a conflict between the following > advertisments: > > R2 - SID52 - R2 (prefix SID, prefix SID) > > R2 - SID52 - R52 (prefix SID, MS) > > R2 - SID2 - R2 (MS, MS) > > Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller > range (prefix SID)) > > ==> SID52 is selected for R2. > > For R52, the algo evaluates a conflict between the following > advertisments: > > R52 - SID52 - R52 (MS, MS) > > R52 - SID52 - R2 (MS, prefix SID) > > Best one is R52 - SID52 - R2 (smaller range (prefix SID)) > > R52 <> R2 ==> R52 has no SID. > > 3.4.4.3. Example 3: wrong configuration of a MS > > Following a typo during configuration, MS1 is configured > > (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That > > advertisement conflicts with the Mapping Server advertisements of MS2 > > and the Prefix-SID advertised by R1...R50. > > We have a conflict for all routers except R100. > > For LDP only routers R51 to R99 we have a conflict between both MS > advertisement. > > For R52, the algo evaluates a conflict between the following > advertisments: > > R52 - SID52 - R52 (MS2, MS2) > > R52 - SID52 - R51 (MS2, MS1) > > R52 - SID53 - R52 (MS1, MS1) > > R52 - SID53 - R53 (MS1, MS2) > > Best one is R52 - SID52 - R51 (smaller starting address) > > R52 <> R51 ==> R52 has no SID. > > For SR routers, R1 to 50, we have a conflict between both MS > advertisement and Prefix SID advertisements. > > For R2, the algo evaluates a conflict between the following > advertisments: > > R2 - SID 2 - R2 (Prefix SID, Prefix SID) > > R2 - SID 2 - R2 (Prefix SID, MS2) > > R2 - SID 2 - R1 (Prefix SID, MS1) > > R2 - SID 2 - R2 (MS2, MS2) > > R2 - SID 2 - R2 (MS2, Prefix SID) > > R2 - SID 2 - R1 (MS2, MS1) > > R2 - SID 3 - R2 (MS1, MS1) > > R2 - SID 3 - R3 (MS1, MS2) > > R2 - SID 3 - R3 (MS1, Prefix SID) > > Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) > > R2 == R2 hence R2 use SID2. > > Regards, > > Bruno > > _________________________________________________________________________________________________________________________ > 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. > _________________________________________________________________________________________________________________________ > 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. > _________________________________________________________________________________________________________________________ > 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. > _________________________________________________________________________________________________________________________ > 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. > _________________________________________________________________________________________________________________________ > 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. > _________________________________________________________________________________________________________________________ > 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. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------5F9094D5D2B0C3E0D7D4D6A0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Les,

commenting rather on your presentation at the Berlin WG session:

In general I don't consider it a big deal whether the Quarantine or the Ignore Overlap policy is being used. It's mainly important that _one_ of then finally gets chosen and consistently implemented.

From the operator's point of view I tend to agree with other operators that the Ignore Overlap policy looks better for most realistic cases, even though less worried about the amount of traffic lost, but more about robustness and security aspects.

Complexity of implementation, however, can be a serious argument against it, as this also works against robustness and security.

Nobody doubts that the Ignore Overlap policy is more complex. But how much complexity it really adds is hard to estimate for me. Is it a minor complication or a big one?

So far I have seen one vendor talk against the Ignore Overlap policy and two vendors taking a position in favor of it.

Sounds to me like 2:1 for Ignore Overlap so far. But we actually don't believe in voting and need more vendor input anyways!

BR,
Martin


Am 05.07.16 um 19:25 schrieb Les Ginsberg (ginsberg):

Bruno –

 

Two comments:

 

1)As we both can come up with examples where a given  preference algorithm will result in “better” behavior than another, continuing to debate which one is “best” has no end. The answer depends upon what types of errors are introduced in the configuration and that isn’t predictable. If it is necessary for us to agree on which algorithm is “best” I doubt that consensus will ever be reached. It therefore is more important to me to focus on implementation complexity and the importance of identifying and correcting misconfigurations ASAP.

 

2)There are two logical databases that an implementation has to support. One of them is the set of received advertisements which can include entries with a variety of ranges. The second one is the set of mapping entries which are in use for lookups.

Your discussion of your “per FEC algorithm”  below defines the second database as a set of entries all of which have a range of 1. Whether this is good implementation model or not I am not commenting on here. But this does not eliminate the need to maintain the first database – and to be able to associate entries in the second database with the corresponding received entry from which they may have been derived. There is work in maintaining that relationship which does not directly bear on the lookup for a given SID but still has to be done if one uses “per FEC” or “Ignore Overlap Only”. This work is not required for the “per range” or “Quarantine” algorithm. It is this additional work that I refer to when I say that “per FEC” has a higher implementation cost/complexity.

 

   Les

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Tuesday, July 05, 2016 1:50 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Please see inline [Bruno]

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 05, 2016 9:08 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

Consider the following simple case:

 

Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0)

Entry #2: (SRMS, 1.1.1.1/32, 200, 10, 0,0)

Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0)

 

There is a misconfiguration here, but we don’t know what was really intended. A few (of many) possibilities:

 

ERROR #1:   Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !Starting SID error

ERROR #2:  Entry #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Starting prefix error

 

The draft defines two candidate preference rules which could be applied:

 

Quarantine

----------------

As we evaluate prefix conflicts first, we compare Entry #1 and Entry #2 and choose Entry #1 the winner (source is PFX). Entry #2 is then not used (quarantined) and the set of active entries is:

 

Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0)

Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0)

 

Ignore Conflict Only

-------------------------

In this case we split Entry #2 into two derived entries:

 

Entry #2A: (SRMS, 1.1.1.1/32, 200, 1, 0,0)

Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0)

 

Entry 2A is then ignored and we then have to evaluate SID conflicts between the derived entry 2B and Entry #3.  For this we have to split Entry 3 into two derived entries:

 

Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0)

Entry #3B: (SRMS, 2.2.2.3/32, 201, 9. 0, 0)

 

Entry 2B wins over entry 3B since it has a smaller range.

 

Active entries are then:

Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0)

Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0)

Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0)

 

Note that in this example both preference rules result in 11 destinations having non-conflicting SIDs.

[Bruno] Yes. The important part is « in this example ». Now do we agree that in average, Quarantine will result in dropping more destinations than Ignore conflict only?

 

 Now, which of these maximizes delivery of traffic? The answer to that depends upon the type of configuration error that was made.

If Error #1 was made, there is no way to differentiate the two preference rules.

However, if Error #2 was made, then Quarantine is clearly better because the destinations 1.1.1.2 – 1.1.1.10 were never intended to have assigned SIDs and may not even exist as destinations in the network, yet “Ignore Conflict Only” favors those prefixes.

 

The point I am trying to make is that it is incorrect to say “If we maximize the number of advertised entries which we use we will always do a better job of delivering traffic.” This example illustrates that this isn’t always true.

[Bruno] OK. Clearly, we can find an example where an algorithm is better than the other. After all, we all agree that there has been a configuration error.

There are 2 points:

a)      how many destination you keep using

b)      in case of conflict which of the entries you select

 

I agree that “b” is more or less random and hence there are many cases where we’ll pick the wrong one. Yet, we try to make reasonable choices. That the point of discussing the preference algorithm (3.2.4). (Although it’s very easy to argue that we can make the wrong choice, I don’t feel that’s a reason not to try discussing it and make choice. e.g. “PFX source wins over SRMS source” is one: we give preference to SR nodes rather than LDP nodes.

 

Regarding a, I feel that maximizing the number of destinations kept, is likely to give the best result in average. I don’t have a proof, but it feel like playing loto: even if each choice is random (“b”), the more you try (“a”) the better your chances. 

 

 

A few more comments inline.

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Please see inline [Bruno]

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:12 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I don’t find your representation complete as regards all of the attributes which are proposed to be used by the conflict resolution algorithm – so it is therefore hard for me to use/understand this representation when applying the defined preference rule.

This is true for me even after reading your explanations below.

 

But it is far more important to have a common understanding of the algorithm proposal than it is to be arguing over whose encoding is “better”. If the encoding in the draft is not clear or could use improvement, I welcome your feedback.

 

As far as your “pseudo-code”:

 

- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts

                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

 

Get the best as per the preference algorithm.

If best Pij == P1

                then use SIDij for P1

                else return no SID                         

 

The fact that you can represent an algorithm in a few lines does not mean the implementation of the algorithm is just as simple.

 

[Bruno] Sure. But if we want to compare implementation complexity, we’ll need to agree on how much we want to go into details, in order to have meaningful comparison. So far this is not clear to me as you sometimes argue that data structure is implementation specific and you don’t want to go into this (which I agree) and sometime you detail the data structure.

There is also the option to consider this as “implementation issue” and let this to implementations.

 

Coming back to my per FEC algo, all what is required from the data structure, is a way/API to get the data back, though 2 keys: get me the SID matching prefix P1 (for the first line), get me the prefixes matching the SID SIDi for the second line. That seem like a reasonable requirement on the data structure, and any option in your draft also requires this to detect prefix conflict and SID conflict (since this is all my per FEC algo is doing in these 2 first lines).

 

Going into more details, my per FEC algo only requires to detail that one prefix or SID belong to a range (of prefix or SID) while your per range algo requires to compute range intersection which is harder. So the API to fetch the data can only be easier.

 

 

[Les:] Range intersection is easy to compute – the algorithm is present in the draft at the end of  Section 3.1.1.

[Bruno] In order to have a meaningful discussion, we need to define the level of details that we want to take into account, because you’re not using the same one to discuss your algo and mine.

1) As a first level of comparison, using the description at the end of section 3.1.1 as a model, for range prefix conflict your algo is:

   1)(T1 == T2) && (A1 == A2)

   2)P1 <= P2

   3)The prefixes are in the same address family.

   2)L1 == L2

   3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2)

 

So for (FEC) prefix conflict my algo is:

   1)(T1 == T2) && (A1 == A2)

   2)P1 = P2

   3)The prefixes are in the same address family.

   2)L1 == L2

 

(BTW, in the draft, there is a typo in the numbering)

It looks clear that FEC comparison is easier than prefix range intersection.

 

2) Going deeper, at the algo complexity

 

The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all the algo complexity is coming from the datastructure. It seems pretty reasonable to find a datastructure << o(n) (e.g. a tree, but you will be much better than me in finding one)

For the range algo, it’s not clear to me that a data structure can be found to automatically find the result. If not, the algo seems to compare all entries two by two, which would get o(n*(n-1)…(2)) i.e. o(n!)

 

 

 

 

Consider what needs to be done to implement

 

   “Find all SIDi advertised for the prefix P1”

 

In its simplest form, we have a list of all SID advertisements (PFX and SRMS) that we have received. One could imagine walking all the entries, looking to see if the prefix of interest is present within the advertised range. But, of course, at large scale such an approach is extremely inefficient – so we immediately start considering ways to improve performance. Inserting received entries into an ordered tree of some kind is an obvious way to improve performance. When one further considers that calculating conflict resolution only needs to be done when a change to the received database occurs (which post startup is infrequent) it becomes very attractive to cache the “winning entries” so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database – ignoring the losers.

[Bruno] I agree that the per range algo (ignore overlap only) will be able to ignore the losers but at the cost of a more complex algo and at the cost of creating new derived entries. It’s not clear to me if the net result is positive. Plus I would expect that the number of conflit is small compared to the number of prefix /SID so this looks like a second order optimization.

 

In this context, we can appreciate the difference between the three proposed algorithms. In particular comparing “Quarantine” with “ignore overlap only”, a key difference is that “Quarantine” only needs to determine whether a received entry is a winning entry or a losing entry. “Ignore overlap only” has to be capable of breaking received entries with ranges > 1 into multiple “derived” entries (some winning, some losing), which means we now need to track the “derived entries” against the original received entry so that if the received entry is updated/deleted we can find all the derived entries and delete/regenerate the derived entries as needed. This is what adds complexity.

[Bruno] and that it why the per FEC algo seems easier.

So it would seem useful to add it in the draft so that we can all discuss it.

 

[Les:] Ignore overlap only is the same as per FEC. We may use different words to describe it, but the end behavior is the same.

[Bruno] good if this get the same result. Yet the algo is different.

 

-- Bruno

 

   Les

 

 

All proposed algorithms can be implemented, but it does seem prudent to consider implementation complexity as part of our decision process – and the discussion/examples in Section 3 are meant to help in doing this.

 

It is worthwhile restating that when conflicts are present we cannot guarantee that forwarding will work correctly no matter what algorithm is used.

[Bruno] I’m not sure to see what you have in mind exactly. Can you elaborate? To me consistency seem enough.

 The more complex the implementation the more likely it is that bugs will be present and the more likely it is that interoperability issues will arise. Whether these costs/risks are worth the “value add” when the outcome cannot be guaranteed to be correct – only guaranteed to be consistent – is an important consideration.

 

Also important to remember that conflicts MUST be eliminated by correcting the misconfigurations that caused them – so conflict resolution is really only an interim measure until the corrections can be made.

[Bruno] By “interim” we are at minimum talking about 10s of minutes, if not more than 1 hour since identifying the root cause may not be obvious. The impact is very significant on the network.

The “Quarantine” algo has the potential to kill 100s PE and 1000s of VPN customers, so a single configuration change on a unrelated router which may not even be in production (i.e. where configuration checks and operations hours may be relaxed)

 

 

No one should be lulled into thinking that because we have conflict resolution deployed that correcting the configuration when conflicts are detected is not a priority.

[Bruno] I could not agree more that conflict needs to be identified and fixed. Note that I’m the one having asked for defining YANG notifications to report this.

You are welcomed to state in the draft that conflicts needs to be reported to the network operator, in particular though yang notification, and other existing means. Plus that network operator needs to fixed them ASAP (but still carefully)

 

Thanks

--Bruno

 

   Les

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Thanks for the discussion. Please see inline [Bruno]

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

As the thread below documents, I stated that I did not understand your representation and asked for clarification – suggesting that you use the format defined in the draft.

You stated that you could not do that and we were at a point where no progress could be made.

[Bruno] I could _not_ use your format since your format did not include the information need. This is not a whim but a technical issue. So I asked you to still consider the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification questions on the points which were not clear, or at least explicitly refusing to consider the email.

I also note that what bothered you in my representation was my addition of the type of advertisement (prefix or MS). But you finally have just added in the latest version of the draft “Src- PFX or SRMS” . So there was probably a way to communicate.

 

 

Besides the algo did not use any specification representation, just names. So I’ll copy/paste it below, please ask clarification questions for the parts which are not clear enough.

 

The problem that we need to solve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts

                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

 

// as a result, for P1, we get a list of (SIDi, Pij)

 

Get the best (SIDi, Pij) as per the preference algorithm.

If best Pij == P1

                then use SIDij for P1

                else return no SID                          / no SID available for this prefix P1

 

 

 

To illustrate my confusion, one of your examples is:

 

For R2, the algo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

 

Now, what does “R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]

- MS/prefix SID is the type of advertisement. In your new version, you call it SRMS/PFX.

- SID is the SID found in the Mapping Entrie

- Rx is the loopback (prefix) or router Rx

 

So “R2 - SID2 - R2 (MS, MS)” is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

 

Does it mean  “On R2, SID2 is assigned to prefix R2 from two different mapping server entries?” I really have no idea.

 

And you conclude the example by saying

 

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))

   ==> SID12 is selected for R2.

 

But since there is no representation of “range” in your examples I really have no idea how you came to this conclusion .

[Bruno] I agree that since the above algo used 2 mapping entries to provides the (SIDi, Pij), the preference algo (§3.2.4) would need to be adapted. That being said, this is not important for this discussion. Let’s just considered that their exist a preference algorithm, which takes as input a list of (SIDi, Piij) for P1, and gives as outpout the “best” one. (definition of “best” is not pertinent)

 

 

??

 

As regards “per FEC/Prefix”, I believe this is what “ignore overlap only” does.

[Bruno] Indeed, this is my expectation. But I would need someone’s review to confirm this.

But the difference is that the proposed algo is simple (2 lines of pseudo code), with very modest resquirement data structure use to store the mapping entries. Indeed, all it needs is a function returning the list of mapping entries associated/matching a given prefix. And function returning the list of mapping entries associated/matching a given SID.

In particular, there is no need for splitting mapping entries which is the main complexity of your proposed “Preference algorithm/ignore overlap only”. (according to your own text).

 

-- Bruno

 

 

    Les

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Thanks for the updated draft.

 

IINM, you have not answered my below email/proposal. I had waited for the new version of the draft but it also does not touch this subject.

 

So, could you please consider and answer my comment?

 

In short, in an implementation-independent sentence:

 

> I'm wondering if we could address the conflict on a per FEC/Prefix basis rather than on a per IGP advertisement (range) basis.

> If so, this may avoid the discussion between the Quarantine vs ignore policy.

 

 

Thanks

Bruno

 

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Please see inline [Bruno]

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I am having difficulty parsing the examples you provide below as they seem to incorporate advertisement source into the description whereas the draft deliberately omits source.

[Bruno] My text does not incorporate the source, but the type of source IOW the type of sub-TLV.

 

So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do (which could happen when an advertisement is leaked) – what matters is what unique entries are in the database independent of source.

[Bruno] It may not matter for your algorithm (pending another thread), but it does for the one I proposed.

 

It would be good if you could present your examples using the format defined in the draft i.e.:

[Bruno] My examples are described in plain text. Then the examples giving intermediate steps of my algo uses the data that are needed i.e. the type of advertisement (Prefix-SID vs MS).

Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per IGP advertisement basis which your format describe.

So I’m sorry but I don’t see how to indulge your request.

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length

     Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A)

     Pe = (Pi + ((R-1) << (Lx-L))

     Se = Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your proposal

 

- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts

                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

 

Get the best as per the preference algorithm.

If best Pij == P1

                then use SIDij for P1

                else return no SID                         

 

this to me specifies an implementation – which isn’t necessary.

[Bruno] Well, _you_ are the one talking about implementation, and more specifically implementation complexity.

Assuming the above algo works, it looks relatively simple to implement, in which case, I would not buy the argument about implementation complexity which is the only argument in favor or the “ignore” or “quarantine” policy.

Bottom line, I would welcome your feedback and comments on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

 

 

However, there is one important point which has not been specified in the draft which reading your post has brought to my attention – that is the order in which checks are made.

The draft states:

 

“Prefix conflicts are specific to mapping entries sharing  the same topology and algorithm.”

“SID conflicts are independent of address-family,  independent of prefix len, independent of topology, and independent  of algorithm.”

 

If we consider an example where a network supports two VPNs, the significance of ordering in the evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1, 1, 0)

(192.0.2.1/32, 200, 1, 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, 1, 2, 0)

 

If we evaluate prefix conflicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1, 1, 0) !VPN1

(192.0.2.100/32, 200, 1, 2, 0) !VPN2

 

If we evaluate SID conflicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1, 1, 0) !VPN1

 

The latter choice is suboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be made explicit in the draft.

 

    Les

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some feedback on the policy.

 

I'm wondering if we could address the conflict on a per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Quarantine vs ignore policy.

 

The problem that we need to solve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1                                                           // identification of Prefix conflicts

                - For each SIDi find all the prefix Pij associated with SIDi              // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij for P1

 

Get the best as per the preference algorithm.

If best Pij == P1

                then use SIDij for P1

                else return no SID                          / no SID available for this prefix P1

 

               

   Note that it would probably be better for the preference algo to put the SID tie-brake before the prefix tie-break as with the prefix tie-break, we suffer from the conflict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.   But for the below examples, I used the preference algo from draft-ietf-*-00

               

 

Below are examples, running this policy on typical configuration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network example:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and advertised their own SID using

       Prefix-SID sub-TLV;

 

   5.  R51 to R100 are SR non-capable, running LDP and their SID are

       advertised by two redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which are SR capable are expected to

       increase and as in real deployment their Loopback addresses would

       no the contiguous, the Mapping servers advertisement covers all

       Loopbacks: (192.0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the consequences of a single

   configuration error, for all conflict resolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node conflict with SID

          configured on another node

 

   Following a typo during configuration, R2 is configured with a SID of

   12.  That SID conflicts with the Prefix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the same, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a single SID is advertised and hence selected.

  

   For R2, the algo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

   

   Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))

   ==> SID12 is selected for R2.

  

   For R12, the algo evaluates a conflict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix SID)

   R12 - SID12 - R2  (prefix SID, prefix SID)

   R12 - SID12 - R12 (prefix SID, MS)

   R12 - SID12 - R2  (MS, prefix SID)

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), smaller starting adresse (R2))

   R12 <> R2 ==> R12 has no SID.

  

   3.4.4.2.  Example 2: SID configured on 1 node conflict with SID

          configured on the Mapping Server

 

   Following a typo during configuration, R2 is configured with a SID of

   52.  That SID conflicts with the Mapping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the same, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a single SID is advertised and hence selected.

  

   For R2, the algo evaluates a conflict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, prefix SID)

   R2 - SID52 - R52 (prefix SID, MS)

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))

   ==> SID52 is selected for R2.

  

   For R52, the algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)

  

   Best one is R52 - SID52 - R2 (smaller range (prefix SID))

   R52 <> R2 ==> R52 has no SID.

  

   

3.4.4.3.  Example 3: wrong configuration of a MS

 

   Following a typo during configuration, MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That

   advertisement conflicts with the Mapping Server advertisements of MS2

   and the Prefix-SID advertised by R1...R50.

  

   We have a conflict for all routers except R100.

  

   For LDP only routers R51 to R99 we have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)

   R52 - SID52 - R51 (MS2, MS1)

   R52 - SID53 - R52 (MS1, MS1)

   R52 - SID53 - R53 (MS1, MS2)

 

   Best one is R52 - SID52 - R51 (smaller starting address)

   R52 <> R51 ==> R52 has no SID.

  

   For SR routers, R1 to 50, we have a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict between the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 - SID 2 - R2 (Prefix SID, MS2)

   R2 - SID 2 - R1 (Prefix SID, MS1)

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)

  

   Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 == R2 hence R2 use SID2.

 

Regards,

Bruno

 

_________________________________________________________________________________________________________________________
 
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.
_________________________________________________________________________________________________________________________
 
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.
_________________________________________________________________________________________________________________________
 
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.
_________________________________________________________________________________________________________________________
 
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.
_________________________________________________________________________________________________________________________
 
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.
_________________________________________________________________________________________________________________________
 
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.


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


--------------5F9094D5D2B0C3E0D7D4D6A0-- From nobody Fri Jul 22 02:34:57 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4412DF3B for ; Fri, 22 Jul 2016 02:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-HdXbZ6qW7H for ; Fri, 22 Jul 2016 02:34:49 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9F312DF38 for ; Fri, 22 Jul 2016 02:34:48 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5C6F74B6DD425; Fri, 22 Jul 2016 09:34:42 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6M9YhYt032198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jul 2016 09:34:43 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6M9YdrG001491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jul 2016 11:34:43 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.82]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 22 Jul 2016 11:34:32 +0200 From: "Henderickx, Wim (Nokia - BE)" To: Martin Horneffer , "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Policy Thread-Index: AQHR4/fORUzdyeTlqUictLwe+3Z6b6AkMJAA Date: Fri, 22 Jul 2016 09:34:32 +0000 Message-ID: References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> <91fcbdba712143e890609f6a513f8528@XCH-ALN-001.cisco.com> <2921_1467708583_577B74A7_2921_256_5_53C29892C857584299CBF5D05346208A0F92B91D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <73326a2e-90d2-1af8-689c-0cc08f396ad6@nic.dtag.de> In-Reply-To: <73326a2e-90d2-1af8-689c-0cc08f396ad6@nic.dtag.de> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_B8B2C3147ACB43B08CF510588BE66062nokiacom_" MIME-Version: 1.0 Archived-At: Cc: "Horneffer, Martin" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:34:56 -0000 --_000_B8B2C3147ACB43B08CF510588BE66062nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgMSBvZiB0aGUgdmVuZG9ycyBpbXBsZW1lbnRpbmcgdGhpcywgd2UgcHJlZmVyIHRoZSBhcHBy b2FjaCBvZiBpZ25vcmUgb3ZlcmxhcCBhcyBJIHNhaWQgaW4gdGhlIG1lZXRpbmcgaW4gQmVybGlu DQpUaGUgaW1wbGljYXRpb24gZnJvbSBpbXBsZW1lbnRhdGlvbiBzIGFyZSBub3QgbWFzc2l2ZSBh bmQgZ2l2ZW4gaXQgaXMgbWF4aW1pc2luZyB0cmFmZmljIGRlbGl2ZXJ5IGluIGNhc2Ugb2YgY29u ZmxpY3QsIHdlIHByZWZlciB0aGlzIGFwcHJvYWNoLg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFs ZiBvZiBNYXJ0aW4gSG9ybmVmZmVyIDxtYWhvQG5pYy5kdGFnLmRlPG1haWx0bzptYWhvQG5pYy5k dGFnLmRlPj4NCkRhdGU6IEZyaWRheSAyMiBKdWx5IDIwMTYgYXQgMTE6MDENClRvOiAiTGVzIEdp bnNiZXJnIChnaW5zYmVyZykiIDxnaW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNiZXJnQGNp c2NvLmNvbT4+LCAic3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IiA8c3By aW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KQ2M6IE1hcnRpbiBIb3JuZWZm ZXIgPE1hcnRpbi5Ib3JuZWZmZXJAdGVsZWtvbS5kZTxtYWlsdG86TWFydGluLkhvcm5lZmZlckB0 ZWxla29tLmRlPj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1jb25m bGljdC1yZXNvbHV0aW9uIC0gUG9saWN5DQoNCkhpIExlcywNCg0KY29tbWVudGluZyByYXRoZXIg b24geW91ciBwcmVzZW50YXRpb24gYXQgdGhlIEJlcmxpbiBXRyBzZXNzaW9uOg0KDQpJbiBnZW5l cmFsIEkgZG9uJ3QgY29uc2lkZXIgaXQgYSBiaWcgZGVhbCB3aGV0aGVyIHRoZSBRdWFyYW50aW5l IG9yIHRoZSBJZ25vcmUgT3ZlcmxhcCBwb2xpY3kgaXMgYmVpbmcgdXNlZC4gSXQncyBtYWlubHkg aW1wb3J0YW50IHRoYXQgX29uZV8gb2YgdGhlbiBmaW5hbGx5IGdldHMgY2hvc2VuIGFuZCBjb25z aXN0ZW50bHkgaW1wbGVtZW50ZWQuDQoNCkZyb20gdGhlIG9wZXJhdG9yJ3MgcG9pbnQgb2Ygdmll dyBJIHRlbmQgdG8gYWdyZWUgd2l0aCBvdGhlciBvcGVyYXRvcnMgdGhhdCB0aGUgSWdub3JlIE92 ZXJsYXAgcG9saWN5IGxvb2tzIGJldHRlciBmb3IgbW9zdCByZWFsaXN0aWMgY2FzZXMsIGV2ZW4g dGhvdWdoIGxlc3Mgd29ycmllZCBhYm91dCB0aGUgYW1vdW50IG9mIHRyYWZmaWMgbG9zdCwgYnV0 IG1vcmUgYWJvdXQgcm9idXN0bmVzcyBhbmQgc2VjdXJpdHkgYXNwZWN0cy4NCg0KQ29tcGxleGl0 eSBvZiBpbXBsZW1lbnRhdGlvbiwgaG93ZXZlciwgY2FuIGJlIGEgc2VyaW91cyBhcmd1bWVudCBh Z2FpbnN0IGl0LCBhcyB0aGlzIGFsc28gd29ya3MgYWdhaW5zdCByb2J1c3RuZXNzIGFuZCBzZWN1 cml0eS4NCg0KTm9ib2R5IGRvdWJ0cyB0aGF0IHRoZSBJZ25vcmUgT3ZlcmxhcCBwb2xpY3kgaXMg bW9yZSBjb21wbGV4LiBCdXQgaG93IG11Y2ggY29tcGxleGl0eSBpdCByZWFsbHkgYWRkcyBpcyBo YXJkIHRvIGVzdGltYXRlIGZvciBtZS4gSXMgaXQgYSBtaW5vciBjb21wbGljYXRpb24gb3IgYSBi aWcgb25lPw0KDQpTbyBmYXIgSSBoYXZlIHNlZW4gb25lIHZlbmRvciB0YWxrIGFnYWluc3QgdGhl IElnbm9yZSBPdmVybGFwIHBvbGljeSBhbmQgdHdvIHZlbmRvcnMgdGFraW5nIGEgcG9zaXRpb24g aW4gZmF2b3Igb2YgaXQuDQoNClNvdW5kcyB0byBtZSBsaWtlIDI6MSBmb3IgSWdub3JlIE92ZXJs YXAgc28gZmFyLiBCdXQgd2UgYWN0dWFsbHkgZG9uJ3QgYmVsaWV2ZSBpbiB2b3RpbmcgYW5kIG5l ZWQgbW9yZSB2ZW5kb3IgaW5wdXQgYW55d2F5cyENCg0KQlIsDQpNYXJ0aW4NCg0KDQpBbSAwNS4w Ny4xNiB1bSAxOToyNSBzY2hyaWViIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOg0KQnJ1bm8g4oCT DQoNClR3byBjb21tZW50czoNCg0KMSlBcyB3ZSBib3RoIGNhbiBjb21lIHVwIHdpdGggZXhhbXBs ZXMgd2hlcmUgYSBnaXZlbiAgcHJlZmVyZW5jZSBhbGdvcml0aG0gd2lsbCByZXN1bHQgaW4g4oCc YmV0dGVy4oCdIGJlaGF2aW9yIHRoYW4gYW5vdGhlciwgY29udGludWluZyB0byBkZWJhdGUgd2hp Y2ggb25lIGlzIOKAnGJlc3TigJ0gaGFzIG5vIGVuZC4gVGhlIGFuc3dlciBkZXBlbmRzIHVwb24g d2hhdCB0eXBlcyBvZiBlcnJvcnMgYXJlIGludHJvZHVjZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24g YW5kIHRoYXQgaXNu4oCZdCBwcmVkaWN0YWJsZS4gSWYgaXQgaXMgbmVjZXNzYXJ5IGZvciB1cyB0 byBhZ3JlZSBvbiB3aGljaCBhbGdvcml0aG0gaXMg4oCcYmVzdOKAnSBJIGRvdWJ0IHRoYXQgY29u c2Vuc3VzIHdpbGwgZXZlciBiZSByZWFjaGVkLiBJdCB0aGVyZWZvcmUgaXMgbW9yZSBpbXBvcnRh bnQgdG8gbWUgdG8gZm9jdXMgb24gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSBhbmQgdGhlIGlt cG9ydGFuY2Ugb2YgaWRlbnRpZnlpbmcgYW5kIGNvcnJlY3RpbmcgbWlzY29uZmlndXJhdGlvbnMg QVNBUC4NCg0KMilUaGVyZSBhcmUgdHdvIGxvZ2ljYWwgZGF0YWJhc2VzIHRoYXQgYW4gaW1wbGVt ZW50YXRpb24gaGFzIHRvIHN1cHBvcnQuIE9uZSBvZiB0aGVtIGlzIHRoZSBzZXQgb2YgcmVjZWl2 ZWQgYWR2ZXJ0aXNlbWVudHMgd2hpY2ggY2FuIGluY2x1ZGUgZW50cmllcyB3aXRoIGEgdmFyaWV0 eSBvZiByYW5nZXMuIFRoZSBzZWNvbmQgb25lIGlzIHRoZSBzZXQgb2YgbWFwcGluZyBlbnRyaWVz IHdoaWNoIGFyZSBpbiB1c2UgZm9yIGxvb2t1cHMuDQpZb3VyIGRpc2N1c3Npb24gb2YgeW91ciDi gJxwZXIgRkVDIGFsZ29yaXRobeKAnSAgYmVsb3cgZGVmaW5lcyB0aGUgc2Vjb25kIGRhdGFiYXNl IGFzIGEgc2V0IG9mIGVudHJpZXMgYWxsIG9mIHdoaWNoIGhhdmUgYSByYW5nZSBvZiAxLiBXaGV0 aGVyIHRoaXMgaXMgZ29vZCBpbXBsZW1lbnRhdGlvbiBtb2RlbCBvciBub3QgSSBhbSBub3QgY29t bWVudGluZyBvbiBoZXJlLiBCdXQgdGhpcyBkb2VzIG5vdCBlbGltaW5hdGUgdGhlIG5lZWQgdG8g bWFpbnRhaW4gdGhlIGZpcnN0IGRhdGFiYXNlIOKAkyBhbmQgdG8gYmUgYWJsZSB0byBhc3NvY2lh dGUgZW50cmllcyBpbiB0aGUgc2Vjb25kIGRhdGFiYXNlIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcg cmVjZWl2ZWQgZW50cnkgZnJvbSB3aGljaCB0aGV5IG1heSBoYXZlIGJlZW4gZGVyaXZlZC4gVGhl cmUgaXMgd29yayBpbiBtYWludGFpbmluZyB0aGF0IHJlbGF0aW9uc2hpcCB3aGljaCBkb2VzIG5v dCBkaXJlY3RseSBiZWFyIG9uIHRoZSBsb29rdXAgZm9yIGEgZ2l2ZW4gU0lEIGJ1dCBzdGlsbCBo YXMgdG8gYmUgZG9uZSBpZiBvbmUgdXNlcyDigJxwZXIgRkVD4oCdIG9yIOKAnElnbm9yZSBPdmVy bGFwIE9ubHnigJ0uIFRoaXMgd29yayBpcyBub3QgcmVxdWlyZWQgZm9yIHRoZSDigJxwZXIgcmFu Z2XigJ0gb3Ig4oCcUXVhcmFudGluZeKAnSBhbGdvcml0aG0uIEl0IGlzIHRoaXMgYWRkaXRpb25h bCB3b3JrIHRoYXQgSSByZWZlciB0byB3aGVuIEkgc2F5IHRoYXQg4oCccGVyIEZFQ+KAnSBoYXMg YSBoaWdoZXIgaW1wbGVtZW50YXRpb24gY29zdC9jb21wbGV4aXR5Lg0KDQogICBMZXMNCg0KDQpG cm9tOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20+IFttYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbV0NClNlbnQ6IFR1ZXNkYXks IEp1bHkgMDUsIDIwMTYgMTo1MCBBTQ0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpDYzog c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogZHJh ZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGljeQ0KDQpMZXMsDQoNClBs ZWFzZSBzZWUgaW5saW5lIFtCcnVub10NCg0KRnJvbTogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykg W21haWx0bzpnaW5zYmVyZ0BjaXNjby5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA1LCAyMDE2 IDk6MDggQU0NClRvOiBERUNSQUVORSBCcnVubyBJTVQvT0xODQpDYzogc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi1zcHJpbmct Y29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGljeQ0KDQpCcnVubyDigJMNCg0KQ29uc2lkZXIgdGhl IGZvbGxvd2luZyBzaW1wbGUgY2FzZToNCg0KRW50cnkgIzE6IChQRlgsIDEuMS4xLjEvMzIsIDEw MCwgMSwgMCwwKQ0KRW50cnkgIzI6IChTUk1TLCAxLjEuMS4xLzMyLCAyMDAsIDEwLCAwLDApDQpF bnRyeSAjMzogKFNSTVMsIDIuMi4yLjIvMzIsIDIwMCwgMTAuIDAsIDApDQoNClRoZXJlIGlzIGEg bWlzY29uZmlndXJhdGlvbiBoZXJlLCBidXQgd2UgZG9u4oCZdCBrbm93IHdoYXQgd2FzIHJlYWxs eSBpbnRlbmRlZC4gQSBmZXcgKG9mIG1hbnkpIHBvc3NpYmlsaXRpZXM6DQoNCkVSUk9SICMxOiAg IEVudHJ5ICMyIHNob3VsZCBoYXZlIGJlZW46IChTUk1TLCAxLjEuMS4xLzMyLCAxMDAsIDEwLCAw LDApICFTdGFydGluZyBTSUQgZXJyb3INCkVSUk9SICMyOiAgRW50cnkgIzIgc2hvdWxkIGhhdmUg YmVlbjogKFNSTVMsIDIuMi4yLjIvMzIsIDIwMCwgMTAsIDAsMCkgIVN0YXJ0aW5nIHByZWZpeCBl cnJvcg0KDQpUaGUgZHJhZnQgZGVmaW5lcyB0d28gY2FuZGlkYXRlIHByZWZlcmVuY2UgcnVsZXMg d2hpY2ggY291bGQgYmUgYXBwbGllZDoNCg0KUXVhcmFudGluZQ0KLS0tLS0tLS0tLS0tLS0tLQ0K QXMgd2UgZXZhbHVhdGUgcHJlZml4IGNvbmZsaWN0cyBmaXJzdCwgd2UgY29tcGFyZSBFbnRyeSAj MSBhbmQgRW50cnkgIzIgYW5kIGNob29zZSBFbnRyeSAjMSB0aGUgd2lubmVyIChzb3VyY2UgaXMg UEZYKS4gRW50cnkgIzIgaXMgdGhlbiBub3QgdXNlZCAocXVhcmFudGluZWQpIGFuZCB0aGUgc2V0 IG9mIGFjdGl2ZSBlbnRyaWVzIGlzOg0KDQpFbnRyeSAjMTogKFBGWCwgMS4xLjEuMS8zMiwgMTAw LCAxLCAwLDApDQpFbnRyeSAjMzogKFNSTVMsIDIuMi4yLjIvMzIsIDIwMCwgMTAuIDAsIDApDQoN Cklnbm9yZSBDb25mbGljdCBPbmx5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJbiB0aGlz IGNhc2Ugd2Ugc3BsaXQgRW50cnkgIzIgaW50byB0d28gZGVyaXZlZCBlbnRyaWVzOg0KDQpFbnRy eSAjMkE6IChTUk1TLCAxLjEuMS4xLzMyLCAyMDAsIDEsIDAsMCkNCkVudHJ5ICMyQjogKFNSTVMs IDEuMS4xLjIvMzIsIDIwMSwgOSwgMCwwKQ0KDQpFbnRyeSAyQSBpcyB0aGVuIGlnbm9yZWQgYW5k IHdlIHRoZW4gaGF2ZSB0byBldmFsdWF0ZSBTSUQgY29uZmxpY3RzIGJldHdlZW4gdGhlIGRlcml2 ZWQgZW50cnkgMkIgYW5kIEVudHJ5ICMzLiAgRm9yIHRoaXMgd2UgaGF2ZSB0byBzcGxpdCBFbnRy eSAzIGludG8gdHdvIGRlcml2ZWQgZW50cmllczoNCg0KRW50cnkgIzNBOiAoU1JNUywgMi4yLjIu Mi8zMiwgMjAwLCAxLiAwLCAwKQ0KRW50cnkgIzNCOiAoU1JNUywgMi4yLjIuMy8zMiwgMjAxLCA5 LiAwLCAwKQ0KDQpFbnRyeSAyQiB3aW5zIG92ZXIgZW50cnkgM0Igc2luY2UgaXQgaGFzIGEgc21h bGxlciByYW5nZS4NCg0KQWN0aXZlIGVudHJpZXMgYXJlIHRoZW46DQpFbnRyeSAjMTogKFBGWCwg MS4xLjEuMS8zMiwgMTAwLCAxLCAwLDApDQpFbnRyeSAjMkI6IChTUk1TLCAxLjEuMS4yLzMyLCAy MDEsIDksIDAsMCkNCkVudHJ5ICMzQTogKFNSTVMsIDIuMi4yLjIvMzIsIDIwMCwgMS4gMCwgMCkN Cg0KTm90ZSB0aGF0IGluIHRoaXMgZXhhbXBsZSBib3RoIHByZWZlcmVuY2UgcnVsZXMgcmVzdWx0 IGluIDExIGRlc3RpbmF0aW9ucyBoYXZpbmcgbm9uLWNvbmZsaWN0aW5nIFNJRHMuDQpbQnJ1bm9d IFllcy4gVGhlIGltcG9ydGFudCBwYXJ0IGlzIMKrIGluIHRoaXMgZXhhbXBsZSDCuy4gTm93IGRv IHdlIGFncmVlIHRoYXQgaW4gYXZlcmFnZSwgUXVhcmFudGluZSB3aWxsIHJlc3VsdCBpbiBkcm9w cGluZyBtb3JlIGRlc3RpbmF0aW9ucyB0aGFuIElnbm9yZSBjb25mbGljdCBvbmx5Pw0KDQogTm93 LCB3aGljaCBvZiB0aGVzZSBtYXhpbWl6ZXMgZGVsaXZlcnkgb2YgdHJhZmZpYz8gVGhlIGFuc3dl ciB0byB0aGF0IGRlcGVuZHMgdXBvbiB0aGUgdHlwZSBvZiBjb25maWd1cmF0aW9uIGVycm9yIHRo YXQgd2FzIG1hZGUuDQpJZiBFcnJvciAjMSB3YXMgbWFkZSwgdGhlcmUgaXMgbm8gd2F5IHRvIGRp ZmZlcmVudGlhdGUgdGhlIHR3byBwcmVmZXJlbmNlIHJ1bGVzLg0KSG93ZXZlciwgaWYgRXJyb3Ig IzIgd2FzIG1hZGUsIHRoZW4gUXVhcmFudGluZSBpcyBjbGVhcmx5IGJldHRlciBiZWNhdXNlIHRo ZSBkZXN0aW5hdGlvbnMgMS4xLjEuMiDigJMgMS4xLjEuMTAgd2VyZSBuZXZlciBpbnRlbmRlZCB0 byBoYXZlIGFzc2lnbmVkIFNJRHMgYW5kIG1heSBub3QgZXZlbiBleGlzdCBhcyBkZXN0aW5hdGlv bnMgaW4gdGhlIG5ldHdvcmssIHlldCDigJxJZ25vcmUgQ29uZmxpY3QgT25seeKAnSBmYXZvcnMg dGhvc2UgcHJlZml4ZXMuDQoNClRoZSBwb2ludCBJIGFtIHRyeWluZyB0byBtYWtlIGlzIHRoYXQg aXQgaXMgaW5jb3JyZWN0IHRvIHNheSDigJxJZiB3ZSBtYXhpbWl6ZSB0aGUgbnVtYmVyIG9mIGFk dmVydGlzZWQgZW50cmllcyB3aGljaCB3ZSB1c2Ugd2Ugd2lsbCBhbHdheXMgZG8gYSBiZXR0ZXIg am9iIG9mIGRlbGl2ZXJpbmcgdHJhZmZpYy7igJ0gVGhpcyBleGFtcGxlIGlsbHVzdHJhdGVzIHRo YXQgdGhpcyBpc27igJl0IGFsd2F5cyB0cnVlLg0KW0JydW5vXSBPSy4gQ2xlYXJseSwgd2UgY2Fu IGZpbmQgYW4gZXhhbXBsZSB3aGVyZSBhbiBhbGdvcml0aG0gaXMgYmV0dGVyIHRoYW4gdGhlIG90 aGVyLiBBZnRlciBhbGwsIHdlIGFsbCBhZ3JlZSB0aGF0IHRoZXJlIGhhcyBiZWVuIGEgY29uZmln dXJhdGlvbiBlcnJvci4NClRoZXJlIGFyZSAyIHBvaW50czoNCg0KYSkgICAgICBob3cgbWFueSBk ZXN0aW5hdGlvbiB5b3Uga2VlcCB1c2luZw0KDQpiKSAgICAgIGluIGNhc2Ugb2YgY29uZmxpY3Qg d2hpY2ggb2YgdGhlIGVudHJpZXMgeW91IHNlbGVjdA0KDQpJIGFncmVlIHRoYXQg4oCcYuKAnSBp cyBtb3JlIG9yIGxlc3MgcmFuZG9tIGFuZCBoZW5jZSB0aGVyZSBhcmUgbWFueSBjYXNlcyB3aGVy ZSB3ZeKAmWxsIHBpY2sgdGhlIHdyb25nIG9uZS4gWWV0LCB3ZSB0cnkgdG8gbWFrZSByZWFzb25h YmxlIGNob2ljZXMuIFRoYXQgdGhlIHBvaW50IG9mIGRpc2N1c3NpbmcgdGhlIHByZWZlcmVuY2Ug YWxnb3JpdGhtICgzLjIuNCkuIChBbHRob3VnaCBpdOKAmXMgdmVyeSBlYXN5IHRvIGFyZ3VlIHRo YXQgd2UgY2FuIG1ha2UgdGhlIHdyb25nIGNob2ljZSwgSSBkb27igJl0IGZlZWwgdGhhdOKAmXMg YSByZWFzb24gbm90IHRvIHRyeSBkaXNjdXNzaW5nIGl0IGFuZCBtYWtlIGNob2ljZS4gZS5nLiDi gJxQRlggc291cmNlIHdpbnMgb3ZlciBTUk1TIHNvdXJjZeKAnSBpcyBvbmU6IHdlIGdpdmUgcHJl ZmVyZW5jZSB0byBTUiBub2RlcyByYXRoZXIgdGhhbiBMRFAgbm9kZXMuDQoNClJlZ2FyZGluZyBh LCBJIGZlZWwgdGhhdCBtYXhpbWl6aW5nIHRoZSBudW1iZXIgb2YgZGVzdGluYXRpb25zIGtlcHQs IGlzIGxpa2VseSB0byBnaXZlIHRoZSBiZXN0IHJlc3VsdCBpbiBhdmVyYWdlLiBJIGRvbuKAmXQg aGF2ZSBhIHByb29mLCBidXQgaXQgZmVlbCBsaWtlIHBsYXlpbmcgbG90bzogZXZlbiBpZiBlYWNo IGNob2ljZSBpcyByYW5kb20gKOKAnGLigJ0pLCB0aGUgbW9yZSB5b3UgdHJ5ICjigJxh4oCdKSB0 aGUgYmV0dGVyIHlvdXIgY2hhbmNlcy4NCg0KDQpBIGZldyBtb3JlIGNvbW1lbnRzIGlubGluZS4N Cg0KDQpGcm9tOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb20+IFttYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbV0NClNlbnQ6IE1v bmRheSwgSnVseSAwNCwgMjAxNiA1OjA3IEFNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykN CkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5DQoNCkxlcywN Cg0KUGxlYXNlIHNlZSBpbmxpbmUgW0JydW5vXQ0KDQoNCkZyb206IExlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpIFttYWlsdG86Z2luc2JlcmdAY2lzY28uY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDAx LCAyMDE2IDM6MTIgQU0NClRvOiBERUNSQUVORSBCcnVubyBJTVQvT0xODQpDYzogc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi1z cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGljeQ0KDQpCcnVubyDigJMNCg0KSSBkb27i gJl0IGZpbmQgeW91ciByZXByZXNlbnRhdGlvbiBjb21wbGV0ZSBhcyByZWdhcmRzIGFsbCBvZiB0 aGUgYXR0cmlidXRlcyB3aGljaCBhcmUgcHJvcG9zZWQgdG8gYmUgdXNlZCBieSB0aGUgY29uZmxp Y3QgcmVzb2x1dGlvbiBhbGdvcml0aG0g4oCTIHNvIGl0IGlzIHRoZXJlZm9yZSBoYXJkIGZvciBt ZSB0byB1c2UvdW5kZXJzdGFuZCB0aGlzIHJlcHJlc2VudGF0aW9uIHdoZW4gYXBwbHlpbmcgdGhl IGRlZmluZWQgcHJlZmVyZW5jZSBydWxlLg0KVGhpcyBpcyB0cnVlIGZvciBtZSBldmVuIGFmdGVy IHJlYWRpbmcgeW91ciBleHBsYW5hdGlvbnMgYmVsb3cuDQoNCkJ1dCBpdCBpcyBmYXIgbW9yZSBp bXBvcnRhbnQgdG8gaGF2ZSBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBhbGdvcml0aG0g cHJvcG9zYWwgdGhhbiBpdCBpcyB0byBiZSBhcmd1aW5nIG92ZXIgd2hvc2UgZW5jb2RpbmcgaXMg 4oCcYmV0dGVy4oCdLiBJZiB0aGUgZW5jb2RpbmcgaW4gdGhlIGRyYWZ0IGlzIG5vdCBjbGVhciBv ciBjb3VsZCB1c2UgaW1wcm92ZW1lbnQsIEkgd2VsY29tZSB5b3VyIGZlZWRiYWNrLg0KDQpBcyBm YXIgYXMgeW91ciDigJxwc2V1ZG8tY29kZeKAnToNCg0KLSBGaW5kIGFsbCBTSURpIGFkdmVydGlz ZWQgZm9yIHRoZSBwcmVmaXggUDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC8vIGlkZW50aWZpY2F0aW9uIG9mIFByZWZpeCBjb25mbGlj dHMNCiAgICAgICAgICAgICAgICAtIEZvciBlYWNoIFNJRGkgZmluZCBhbGwgdGhlIHByZWZpeCBQ aWogYXNzb2NpYXRlZCB3aXRoIFNJRGkgICAgICAgICAgICAgIC8vIGlkZW50aWZpY2F0aW9uIG9m IFNJRCBjb25mbGljdHMNCg0KR2V0IHRoZSBiZXN0IGFzIHBlciB0aGUgcHJlZmVyZW5jZSBhbGdv cml0aG0uDQpJZiBiZXN0IFBpaiA9PSBQMQ0KICAgICAgICAgICAgICAgIHRoZW4gdXNlIFNJRGlq IGZvciBQMQ0KICAgICAgICAgICAgICAgIGVsc2UgcmV0dXJuIG5vIFNJRA0KDQpUaGUgZmFjdCB0 aGF0IHlvdSBjYW4gcmVwcmVzZW50IGFuIGFsZ29yaXRobSBpbiBhIGZldyBsaW5lcyBkb2VzIG5v dCBtZWFuIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgYWxnb3JpdGhtIGlzIGp1c3QgYXMgc2lt cGxlLg0KDQpbQnJ1bm9dIFN1cmUuIEJ1dCBpZiB3ZSB3YW50IHRvIGNvbXBhcmUgaW1wbGVtZW50 YXRpb24gY29tcGxleGl0eSwgd2XigJlsbCBuZWVkIHRvIGFncmVlIG9uIGhvdyBtdWNoIHdlIHdh bnQgdG8gZ28gaW50byBkZXRhaWxzLCBpbiBvcmRlciB0byBoYXZlIG1lYW5pbmdmdWwgY29tcGFy aXNvbi4gU28gZmFyIHRoaXMgaXMgbm90IGNsZWFyIHRvIG1lIGFzIHlvdSBzb21ldGltZXMgYXJn dWUgdGhhdCBkYXRhIHN0cnVjdHVyZSBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBhbmQgeW91 IGRvbuKAmXQgd2FudCB0byBnbyBpbnRvIHRoaXMgKHdoaWNoIEkgYWdyZWUpIGFuZCBzb21ldGlt ZSB5b3UgZGV0YWlsIHRoZSBkYXRhIHN0cnVjdHVyZS4NClRoZXJlIGlzIGFsc28gdGhlIG9wdGlv biB0byBjb25zaWRlciB0aGlzIGFzIOKAnGltcGxlbWVudGF0aW9uIGlzc3Vl4oCdIGFuZCBsZXQg dGhpcyB0byBpbXBsZW1lbnRhdGlvbnMuDQoNCkNvbWluZyBiYWNrIHRvIG15IHBlciBGRUMgYWxn bywgYWxsIHdoYXQgaXMgcmVxdWlyZWQgZnJvbSB0aGUgZGF0YSBzdHJ1Y3R1cmUsIGlzIGEgd2F5 L0FQSSB0byBnZXQgdGhlIGRhdGEgYmFjaywgdGhvdWdoIDIga2V5czogZ2V0IG1lIHRoZSBTSUQg bWF0Y2hpbmcgcHJlZml4IFAxIChmb3IgdGhlIGZpcnN0IGxpbmUpLCBnZXQgbWUgdGhlIHByZWZp eGVzIG1hdGNoaW5nIHRoZSBTSUQgU0lEaSBmb3IgdGhlIHNlY29uZCBsaW5lLiBUaGF0IHNlZW0g bGlrZSBhIHJlYXNvbmFibGUgcmVxdWlyZW1lbnQgb24gdGhlIGRhdGEgc3RydWN0dXJlLCBhbmQg YW55IG9wdGlvbiBpbiB5b3VyIGRyYWZ0IGFsc28gcmVxdWlyZXMgdGhpcyB0byBkZXRlY3QgcHJl Zml4IGNvbmZsaWN0IGFuZCBTSUQgY29uZmxpY3QgKHNpbmNlIHRoaXMgaXMgYWxsIG15IHBlciBG RUMgYWxnbyBpcyBkb2luZyBpbiB0aGVzZSAyIGZpcnN0IGxpbmVzKS4NCg0KR29pbmcgaW50byBt b3JlIGRldGFpbHMsIG15IHBlciBGRUMgYWxnbyBvbmx5IHJlcXVpcmVzIHRvIGRldGFpbCB0aGF0 IG9uZSBwcmVmaXggb3IgU0lEIGJlbG9uZyB0byBhIHJhbmdlIChvZiBwcmVmaXggb3IgU0lEKSB3 aGlsZSB5b3VyIHBlciByYW5nZSBhbGdvIHJlcXVpcmVzIHRvIGNvbXB1dGUgcmFuZ2UgaW50ZXJz ZWN0aW9uIHdoaWNoIGlzIGhhcmRlci4gU28gdGhlIEFQSSB0byBmZXRjaCB0aGUgZGF0YSBjYW4g b25seSBiZSBlYXNpZXIuDQoNCg0KW0xlczpdIFJhbmdlIGludGVyc2VjdGlvbiBpcyBlYXN5IHRv IGNvbXB1dGUg4oCTIHRoZSBhbGdvcml0aG0gaXMgcHJlc2VudCBpbiB0aGUgZHJhZnQgYXQgdGhl IGVuZCBvZiAgU2VjdGlvbiAzLjEuMS4NCltCcnVub10gSW4gb3JkZXIgdG8gaGF2ZSBhIG1lYW5p bmdmdWwgZGlzY3Vzc2lvbiwgd2UgbmVlZCB0byBkZWZpbmUgdGhlIGxldmVsIG9mIGRldGFpbHMg dGhhdCB3ZSB3YW50IHRvIHRha2UgaW50byBhY2NvdW50LCBiZWNhdXNlIHlvdeKAmXJlIG5vdCB1 c2luZyB0aGUgc2FtZSBvbmUgdG8gZGlzY3VzcyB5b3VyIGFsZ28gYW5kIG1pbmUuDQoxKSBBcyBh IGZpcnN0IGxldmVsIG9mIGNvbXBhcmlzb24sIHVzaW5nIHRoZSBkZXNjcmlwdGlvbiBhdCB0aGUg ZW5kIG9mIHNlY3Rpb24gMy4xLjEgYXMgYSBtb2RlbCwgZm9yIHJhbmdlIHByZWZpeCBjb25mbGlj dCB5b3VyIGFsZ28gaXM6DQogICAxKShUMSA9PSBUMikgJiYgKEExID09IEEyKQ0KICAgMilQMSA8 PSBQMg0KICAgMylUaGUgcHJlZml4ZXMgYXJlIGluIHRoZSBzYW1lIGFkZHJlc3MgZmFtaWx5Lg0K ICAgMilMMSA9PSBMMg0KICAgMykoUDFlID49IFAyKSAmJiAoKFMxICsgKFAyIC0gUDEpKSAhPSBT MikNCg0KU28gZm9yIChGRUMpIHByZWZpeCBjb25mbGljdCBteSBhbGdvIGlzOg0KICAgMSkoVDEg PT0gVDIpICYmIChBMSA9PSBBMikNCiAgIDIpUDEgPSBQMg0KICAgMylUaGUgcHJlZml4ZXMgYXJl IGluIHRoZSBzYW1lIGFkZHJlc3MgZmFtaWx5Lg0KICAgMilMMSA9PSBMMg0KDQooQlRXLCBpbiB0 aGUgZHJhZnQsIHRoZXJlIGlzIGEgdHlwbyBpbiB0aGUgbnVtYmVyaW5nKQ0KSXQgbG9va3MgY2xl YXIgdGhhdCBGRUMgY29tcGFyaXNvbiBpcyBlYXNpZXIgdGhhbiBwcmVmaXggcmFuZ2UgaW50ZXJz ZWN0aW9uLg0KDQoyKSBHb2luZyBkZWVwZXIsIGF0IHRoZSBhbGdvIGNvbXBsZXhpdHkNCg0KVGhl IEZFQyBhbGdvIG5lZWRzOiBnZXRfU0lEcyhQcmVmaXgpLCBhbmQgYWxsIHRoZSB3b3JrIGlzIGRv bmUuIFNvIGFsbCB0aGUgYWxnbyBjb21wbGV4aXR5IGlzIGNvbWluZyBmcm9tIHRoZSBkYXRhc3Ry dWN0dXJlLiBJdCBzZWVtcyBwcmV0dHkgcmVhc29uYWJsZSB0byBmaW5kIGEgZGF0YXN0cnVjdHVy ZSA8PCBvKG4pIChlLmcuIGEgdHJlZSwgYnV0IHlvdSB3aWxsIGJlIG11Y2ggYmV0dGVyIHRoYW4g bWUgaW4gZmluZGluZyBvbmUpDQpGb3IgdGhlIHJhbmdlIGFsZ28sIGl04oCZcyBub3QgY2xlYXIg dG8gbWUgdGhhdCBhIGRhdGEgc3RydWN0dXJlIGNhbiBiZSBmb3VuZCB0byBhdXRvbWF0aWNhbGx5 IGZpbmQgdGhlIHJlc3VsdC4gSWYgbm90LCB0aGUgYWxnbyBzZWVtcyB0byBjb21wYXJlIGFsbCBl bnRyaWVzIHR3byBieSB0d28sIHdoaWNoIHdvdWxkIGdldCBvKG4qKG4tMSnigKYoMikpIGkuZS4g byhuISkNCg0KDQoNCg0KQ29uc2lkZXIgd2hhdCBuZWVkcyB0byBiZSBkb25lIHRvIGltcGxlbWVu dA0KDQogICDigJxGaW5kIGFsbCBTSURpIGFkdmVydGlzZWQgZm9yIHRoZSBwcmVmaXggUDHigJ0N Cg0KSW4gaXRzIHNpbXBsZXN0IGZvcm0sIHdlIGhhdmUgYSBsaXN0IG9mIGFsbCBTSUQgYWR2ZXJ0 aXNlbWVudHMgKFBGWCBhbmQgU1JNUykgdGhhdCB3ZSBoYXZlIHJlY2VpdmVkLiBPbmUgY291bGQg aW1hZ2luZSB3YWxraW5nIGFsbCB0aGUgZW50cmllcywgbG9va2luZyB0byBzZWUgaWYgdGhlIHBy ZWZpeCBvZiBpbnRlcmVzdCBpcyBwcmVzZW50IHdpdGhpbiB0aGUgYWR2ZXJ0aXNlZCByYW5nZS4g QnV0LCBvZiBjb3Vyc2UsIGF0IGxhcmdlIHNjYWxlIHN1Y2ggYW4gYXBwcm9hY2ggaXMgZXh0cmVt ZWx5IGluZWZmaWNpZW50IOKAkyBzbyB3ZSBpbW1lZGlhdGVseSBzdGFydCBjb25zaWRlcmluZyB3 YXlzIHRvIGltcHJvdmUgcGVyZm9ybWFuY2UuIEluc2VydGluZyByZWNlaXZlZCBlbnRyaWVzIGlu dG8gYW4gb3JkZXJlZCB0cmVlIG9mIHNvbWUga2luZCBpcyBhbiBvYnZpb3VzIHdheSB0byBpbXBy b3ZlIHBlcmZvcm1hbmNlLiBXaGVuIG9uZSBmdXJ0aGVyIGNvbnNpZGVycyB0aGF0IGNhbGN1bGF0 aW5nIGNvbmZsaWN0IHJlc29sdXRpb24gb25seSBuZWVkcyB0byBiZSBkb25lIHdoZW4gYSBjaGFu Z2UgdG8gdGhlIHJlY2VpdmVkIGRhdGFiYXNlIG9jY3VycyAod2hpY2ggcG9zdCBzdGFydHVwIGlz IGluZnJlcXVlbnQpIGl0IGJlY29tZXMgdmVyeSBhdHRyYWN0aXZlIHRvIGNhY2hlIHRoZSDigJx3 aW5uaW5nIGVudHJpZXPigJ0gc28gdGhhdCBpZiBvbmUgd2FudHMgdG8gcmV0cmlldmUgdGhlIFNJ RCBmb3IgYSBnaXZlbiBwcmVmaXggd2Ugb25seSBoYXZlIHRvIGV4YW1pbmUgYSBzdWJzZXQgb2Yg dGhlIHRvdGFsIGRhdGFiYXNlIOKAkyBpZ25vcmluZyB0aGUgbG9zZXJzLg0KW0JydW5vXSBJIGFn cmVlIHRoYXQgdGhlIHBlciByYW5nZSBhbGdvIChpZ25vcmUgb3ZlcmxhcCBvbmx5KSB3aWxsIGJl IGFibGUgdG8gaWdub3JlIHRoZSBsb3NlcnMgYnV0IGF0IHRoZSBjb3N0IG9mIGEgbW9yZSBjb21w bGV4IGFsZ28gYW5kIGF0IHRoZSBjb3N0IG9mIGNyZWF0aW5nIG5ldyBkZXJpdmVkIGVudHJpZXMu IEl04oCZcyBub3QgY2xlYXIgdG8gbWUgaWYgdGhlIG5ldCByZXN1bHQgaXMgcG9zaXRpdmUuIFBs dXMgSSB3b3VsZCBleHBlY3QgdGhhdCB0aGUgbnVtYmVyIG9mIGNvbmZsaXQgaXMgc21hbGwgY29t cGFyZWQgdG8gdGhlIG51bWJlciBvZiBwcmVmaXggL1NJRCBzbyB0aGlzIGxvb2tzIGxpa2UgYSBz ZWNvbmQgb3JkZXIgb3B0aW1pemF0aW9uLg0KDQpJbiB0aGlzIGNvbnRleHQsIHdlIGNhbiBhcHBy ZWNpYXRlIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHRocmVlIHByb3Bvc2VkIGFsZ29yaXRo bXMuIEluIHBhcnRpY3VsYXIgY29tcGFyaW5nIOKAnFF1YXJhbnRpbmXigJ0gd2l0aCDigJxpZ25v cmUgb3ZlcmxhcCBvbmx54oCdLCBhIGtleSBkaWZmZXJlbmNlIGlzIHRoYXQg4oCcUXVhcmFudGlu ZeKAnSBvbmx5IG5lZWRzIHRvIGRldGVybWluZSB3aGV0aGVyIGEgcmVjZWl2ZWQgZW50cnkgaXMg YSB3aW5uaW5nIGVudHJ5IG9yIGEgbG9zaW5nIGVudHJ5LiDigJxJZ25vcmUgb3ZlcmxhcCBvbmx5 4oCdIGhhcyB0byBiZSBjYXBhYmxlIG9mIGJyZWFraW5nIHJlY2VpdmVkIGVudHJpZXMgd2l0aCBy YW5nZXMgPiAxIGludG8gbXVsdGlwbGUg4oCcZGVyaXZlZOKAnSBlbnRyaWVzIChzb21lIHdpbm5p bmcsIHNvbWUgbG9zaW5nKSwgd2hpY2ggbWVhbnMgd2Ugbm93IG5lZWQgdG8gdHJhY2sgdGhlIOKA nGRlcml2ZWQgZW50cmllc+KAnSBhZ2FpbnN0IHRoZSBvcmlnaW5hbCByZWNlaXZlZCBlbnRyeSBz byB0aGF0IGlmIHRoZSByZWNlaXZlZCBlbnRyeSBpcyB1cGRhdGVkL2RlbGV0ZWQgd2UgY2FuIGZp bmQgYWxsIHRoZSBkZXJpdmVkIGVudHJpZXMgYW5kIGRlbGV0ZS9yZWdlbmVyYXRlIHRoZSBkZXJp dmVkIGVudHJpZXMgYXMgbmVlZGVkLiBUaGlzIGlzIHdoYXQgYWRkcyBjb21wbGV4aXR5Lg0KW0Jy dW5vXSBhbmQgdGhhdCBpdCB3aHkgdGhlIHBlciBGRUMgYWxnbyBzZWVtcyBlYXNpZXIuDQpTbyBp dCB3b3VsZCBzZWVtIHVzZWZ1bCB0byBhZGQgaXQgaW4gdGhlIGRyYWZ0IHNvIHRoYXQgd2UgY2Fu IGFsbCBkaXNjdXNzIGl0Lg0KDQpbTGVzOl0gSWdub3JlIG92ZXJsYXAgb25seSBpcyB0aGUgc2Ft ZSBhcyBwZXIgRkVDLiBXZSBtYXkgdXNlIGRpZmZlcmVudCB3b3JkcyB0byBkZXNjcmliZSBpdCwg YnV0IHRoZSBlbmQgYmVoYXZpb3IgaXMgdGhlIHNhbWUuDQpbQnJ1bm9dIGdvb2QgaWYgdGhpcyBn ZXQgdGhlIHNhbWUgcmVzdWx0LiBZZXQgdGhlIGFsZ28gaXMgZGlmZmVyZW50Lg0KDQotLSBCcnVu bw0KDQogICBMZXMNCg0KDQpBbGwgcHJvcG9zZWQgYWxnb3JpdGhtcyBjYW4gYmUgaW1wbGVtZW50 ZWQsIGJ1dCBpdCBkb2VzIHNlZW0gcHJ1ZGVudCB0byBjb25zaWRlciBpbXBsZW1lbnRhdGlvbiBj b21wbGV4aXR5IGFzIHBhcnQgb2Ygb3VyIGRlY2lzaW9uIHByb2Nlc3Mg4oCTIGFuZCB0aGUgZGlz Y3Vzc2lvbi9leGFtcGxlcyBpbiBTZWN0aW9uIDMgYXJlIG1lYW50IHRvIGhlbHAgaW4gZG9pbmcg dGhpcy4NCg0KSXQgaXMgd29ydGh3aGlsZSByZXN0YXRpbmcgdGhhdCB3aGVuIGNvbmZsaWN0cyBh cmUgcHJlc2VudCB3ZSBjYW5ub3QgZ3VhcmFudGVlIHRoYXQgZm9yd2FyZGluZyB3aWxsIHdvcmsg Y29ycmVjdGx5IG5vIG1hdHRlciB3aGF0IGFsZ29yaXRobSBpcyB1c2VkLg0KW0JydW5vXSBJ4oCZ bSBub3Qgc3VyZSB0byBzZWUgd2hhdCB5b3UgaGF2ZSBpbiBtaW5kIGV4YWN0bHkuIENhbiB5b3Ug ZWxhYm9yYXRlPyBUbyBtZSBjb25zaXN0ZW5jeSBzZWVtIGVub3VnaC4NCiBUaGUgbW9yZSBjb21w bGV4IHRoZSBpbXBsZW1lbnRhdGlvbiB0aGUgbW9yZSBsaWtlbHkgaXQgaXMgdGhhdCBidWdzIHdp bGwgYmUgcHJlc2VudCBhbmQgdGhlIG1vcmUgbGlrZWx5IGl0IGlzIHRoYXQgaW50ZXJvcGVyYWJp bGl0eSBpc3N1ZXMgd2lsbCBhcmlzZS4gV2hldGhlciB0aGVzZSBjb3N0cy9yaXNrcyBhcmUgd29y dGggdGhlIOKAnHZhbHVlIGFkZOKAnSB3aGVuIHRoZSBvdXRjb21lIGNhbm5vdCBiZSBndWFyYW50 ZWVkIHRvIGJlIGNvcnJlY3Qg4oCTIG9ubHkgZ3VhcmFudGVlZCB0byBiZSBjb25zaXN0ZW50IOKA kyBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbi4NCg0KQWxzbyBpbXBvcnRhbnQgdG8gcmVt ZW1iZXIgdGhhdCBjb25mbGljdHMgTVVTVCBiZSBlbGltaW5hdGVkIGJ5IGNvcnJlY3RpbmcgdGhl IG1pc2NvbmZpZ3VyYXRpb25zIHRoYXQgY2F1c2VkIHRoZW0g4oCTIHNvIGNvbmZsaWN0IHJlc29s dXRpb24gaXMgcmVhbGx5IG9ubHkgYW4gaW50ZXJpbSBtZWFzdXJlIHVudGlsIHRoZSBjb3JyZWN0 aW9ucyBjYW4gYmUgbWFkZS4NCltCcnVub10gQnkg4oCcaW50ZXJpbeKAnSB3ZSBhcmUgYXQgbWlu aW11bSB0YWxraW5nIGFib3V0IDEwcyBvZiBtaW51dGVzLCBpZiBub3QgbW9yZSB0aGFuIDEgaG91 ciBzaW5jZSBpZGVudGlmeWluZyB0aGUgcm9vdCBjYXVzZSBtYXkgbm90IGJlIG9idmlvdXMuIFRo ZSBpbXBhY3QgaXMgdmVyeSBzaWduaWZpY2FudCBvbiB0aGUgbmV0d29yay4NClRoZSDigJxRdWFy YW50aW5l4oCdIGFsZ28gaGFzIHRoZSBwb3RlbnRpYWwgdG8ga2lsbCAxMDBzIFBFIGFuZCAxMDAw cyBvZiBWUE4gY3VzdG9tZXJzLCBzbyBhIHNpbmdsZSBjb25maWd1cmF0aW9uIGNoYW5nZSBvbiBh IHVucmVsYXRlZCByb3V0ZXIgd2hpY2ggbWF5IG5vdCBldmVuIGJlIGluIHByb2R1Y3Rpb24gKGku ZS4gd2hlcmUgY29uZmlndXJhdGlvbiBjaGVja3MgYW5kIG9wZXJhdGlvbnMgaG91cnMgbWF5IGJl IHJlbGF4ZWQpDQoNCg0KTm8gb25lIHNob3VsZCBiZSBsdWxsZWQgaW50byB0aGlua2luZyB0aGF0 IGJlY2F1c2Ugd2UgaGF2ZSBjb25mbGljdCByZXNvbHV0aW9uIGRlcGxveWVkIHRoYXQgY29ycmVj dGluZyB0aGUgY29uZmlndXJhdGlvbiB3aGVuIGNvbmZsaWN0cyBhcmUgZGV0ZWN0ZWQgaXMgbm90 IGEgcHJpb3JpdHkuDQpbQnJ1bm9dIEkgY291bGQgbm90IGFncmVlIG1vcmUgdGhhdCBjb25mbGlj dCBuZWVkcyB0byBiZSBpZGVudGlmaWVkIGFuZCBmaXhlZC4gTm90ZSB0aGF0IEnigJltIHRoZSBv bmUgaGF2aW5nIGFza2VkIGZvciBkZWZpbmluZyBZQU5HIG5vdGlmaWNhdGlvbnMgdG8gcmVwb3J0 IHRoaXMuDQpZb3UgYXJlIHdlbGNvbWVkIHRvIHN0YXRlIGluIHRoZSBkcmFmdCB0aGF0IGNvbmZs aWN0cyBuZWVkcyB0byBiZSByZXBvcnRlZCB0byB0aGUgbmV0d29yayBvcGVyYXRvciwgaW4gcGFy dGljdWxhciB0aG91Z2ggeWFuZyBub3RpZmljYXRpb24sIGFuZCBvdGhlciBleGlzdGluZyBtZWFu cy4gUGx1cyB0aGF0IG5ldHdvcmsgb3BlcmF0b3IgbmVlZHMgdG8gZml4ZWQgdGhlbSBBU0FQIChi dXQgc3RpbGwgY2FyZWZ1bGx5KQ0KDQpUaGFua3MNCi0tQnJ1bm8NCg0KICAgTGVzDQoNCg0KRnJv bTpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tPiBbbWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwg SnVuZSAzMCwgMjAxNiA1OjEwIEFNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBkcmFm dC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5DQoNCkxlcywNCg0KVGhh bmtzIGZvciB0aGUgZGlzY3Vzc2lvbi4gUGxlYXNlIHNlZSBpbmxpbmUgW0JydW5vXQ0KDQoNCkZy b206IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIFttYWlsdG86Z2luc2JlcmdAY2lzY28uY29tXQ0K U2VudDogV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDY6MDAgUE0NClRvOiBERUNSQUVORSBCcnVu byBJTVQvT0xODQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGlj eQ0KDQpCcnVubyDigJMNCg0KQXMgdGhlIHRocmVhZCBiZWxvdyBkb2N1bWVudHMsIEkgc3RhdGVk IHRoYXQgSSBkaWQgbm90IHVuZGVyc3RhbmQgeW91ciByZXByZXNlbnRhdGlvbiBhbmQgYXNrZWQg Zm9yIGNsYXJpZmljYXRpb24g4oCTIHN1Z2dlc3RpbmcgdGhhdCB5b3UgdXNlIHRoZSBmb3JtYXQg ZGVmaW5lZCBpbiB0aGUgZHJhZnQuDQpZb3Ugc3RhdGVkIHRoYXQgeW91IGNvdWxkIG5vdCBkbyB0 aGF0IGFuZCB3ZSB3ZXJlIGF0IGEgcG9pbnQgd2hlcmUgbm8gcHJvZ3Jlc3MgY291bGQgYmUgbWFk ZS4NCltCcnVub10gSSBjb3VsZCBfbm90XyB1c2UgeW91ciBmb3JtYXQgc2luY2UgeW91ciBmb3Jt YXQgZGlkIG5vdCBpbmNsdWRlIHRoZSBpbmZvcm1hdGlvbiBuZWVkLiBUaGlzIGlzIG5vdCBhIHdo aW0gYnV0IGEgdGVjaG5pY2FsIGlzc3VlLiBTbyBJIGFza2VkIHlvdSB0byBzdGlsbCBjb25zaWRl ciB0aGUgbWVzc2FnZS4gUmF0aGVyIHRoYW4gd2FpdGluZyBmb3IgYSB0aW1lLW91dCwgdGhlcmUg d2FzIGEgd2F5IHRvIG1ha2UgcHJvZ3Jlc3MgYnkgYXNraW5nIGNsYXJpZmljYXRpb24gcXVlc3Rp b25zIG9uIHRoZSBwb2ludHMgd2hpY2ggd2VyZSBub3QgY2xlYXIsIG9yIGF0IGxlYXN0IGV4cGxp Y2l0bHkgcmVmdXNpbmcgdG8gY29uc2lkZXIgdGhlIGVtYWlsLg0KDQpJIGFsc28gbm90ZSB0aGF0 IHdoYXQgYm90aGVyZWQgeW91IGluIG15IHJlcHJlc2VudGF0aW9uIHdhcyBteSBhZGRpdGlvbiBv ZiB0aGUgdHlwZSBvZiBhZHZlcnRpc2VtZW50IChwcmVmaXggb3IgTVMpLiBCdXQgeW91IGZpbmFs bHkgaGF2ZSBqdXN0IGFkZGVkIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQg4oCc U3JjLSBQRlggb3IgU1JNU+KAnSAuIFNvIHRoZXJlIHdhcyBwcm9iYWJseSBhIHdheSB0byBjb21t dW5pY2F0ZS4NCg0KDQpCZXNpZGVzIHRoZSBhbGdvIGRpZCBub3QgdXNlIGFueSBzcGVjaWZpY2F0 aW9uIHJlcHJlc2VudGF0aW9uLCBqdXN0IG5hbWVzLiBTbyBJ4oCZbGwgY29weS9wYXN0ZSBpdCBi ZWxvdywgcGxlYXNlIGFzayBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9ucyBmb3IgdGhlIHBhcnRzIHdo aWNoIGFyZSBub3QgY2xlYXIgZW5vdWdoLg0KDQpUaGUgcHJvYmxlbSB0aGF0IHdlIG5lZWQgdG8g c29sdmUsIGlzIHRvIGZpbmQgdGhlIFNJRCBmb3IgYSBwcmVmaXggKFAxKS4NClRoZSBhbGdvIGNv dWxkIGJlOg0KLSBGaW5kIGFsbCBTSURpIGFkdmVydGlzZWQgZm9yIHRoZSBwcmVmaXggUDEgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8v IGlkZW50aWZpY2F0aW9uIG9mIFByZWZpeCBjb25mbGljdHMNCiAgICAgICAgICAgICAgICAtIEZv ciBlYWNoIFNJRGkgZmluZCBhbGwgdGhlIHByZWZpeCBQaWogYXNzb2NpYXRlZCB3aXRoIFNJRGkg ICAgICAgICAgICAgIC8vIGlkZW50aWZpY2F0aW9uIG9mIFNJRCBjb25mbGljdHMNCg0KLy8gYXMg YSByZXN1bHQsIGZvciBQMSwgd2UgZ2V0IGEgbGlzdCBvZiAoU0lEaSwgUGlqKQ0KDQpHZXQgdGhl IGJlc3QgKFNJRGksIFBpaikgYXMgcGVyIHRoZSBwcmVmZXJlbmNlIGFsZ29yaXRobS4NCklmIGJl c3QgUGlqID09IFAxDQogICAgICAgICAgICAgICAgdGhlbiB1c2UgU0lEaWogZm9yIFAxDQogICAg ICAgICAgICAgICAgZWxzZSByZXR1cm4gbm8gU0lEICAgICAgICAgICAgICAgICAgICAgICAgICAv IG5vIFNJRCBhdmFpbGFibGUgZm9yIHRoaXMgcHJlZml4IFAxDQoNCg0KDQpUbyBpbGx1c3RyYXRl IG15IGNvbmZ1c2lvbiwgb25lIG9mIHlvdXIgZXhhbXBsZXMgaXM6DQoNCkZvciBSMiwgdGhlIGFs Z28gZXZhbHVhdGVzIGEgY29uZmxpY3QgYmV0d2VlbiB0aGUgZm9sbG93aW5nIGFkdmVydGlzbWVu dHM6DQogICBSMiAtIFNJRDIgLSBSMiAoTVMsIE1TKQ0KICAgUjIgLSBTSUQxMiAtIFIxMiAocHJl Zml4IFNJRCwgTVMpDQogICBSMiAtIFNJRDEyIC0gUjIgIChwcmVmaXggU0lELCBwcmVmaXggU0lE KQ0KDQoNCk5vdywgd2hhdCBkb2VzIOKAnFIyIC0gU0lEMiAtIFIyIChNUywgTVMp4oCdIG1lYW4/ DQpbQnJ1bm9dDQotIE1TL3ByZWZpeCBTSUQgaXMgdGhlIHR5cGUgb2YgYWR2ZXJ0aXNlbWVudC4g SW4geW91ciBuZXcgdmVyc2lvbiwgeW91IGNhbGwgaXQgU1JNUy9QRlguDQotIFNJRCBpcyB0aGUg U0lEIGZvdW5kIGluIHRoZSBNYXBwaW5nIEVudHJpZQ0KLSBSeCBpcyB0aGUgbG9vcGJhY2sgKHBy ZWZpeCkgb3Igcm91dGVyIFJ4DQoNClNvIOKAnFIyIC0gU0lEMiAtIFIyIChNUywgTVMp4oCdIGlz IHRoZSBvdXRwb3V0IG9mIHRoZSBhbGdvIGRlc2NyaWJlZCBhYm92ZSBhbmQgbWVhbnM6IEZvciBw cmVmaXggUjIsIHdlIGZvdW5kIGEgTVMgbWFwcGluZyBlbnRyaWVzIGFkdmVydGlzaW5nIFNJRDIg Zm9yIHRoaXMgcHJlZml4LCBhbmQgdGhlbiBJIGZvdW5kIGEgTVMgbWFwcGluZyBlbnRyaWVzIGFk dmVydGlzaW5nIHByZWZpeCBSMiBmb3IgU0lEMi4NCg0KRG9lcyBpdCBtZWFuICDigJxPbiBSMiwg U0lEMiBpcyBhc3NpZ25lZCB0byBwcmVmaXggUjIgZnJvbSB0d28gZGlmZmVyZW50IG1hcHBpbmcg c2VydmVyIGVudHJpZXM/4oCdIEkgcmVhbGx5IGhhdmUgbm8gaWRlYS4NCg0KQW5kIHlvdSBjb25j bHVkZSB0aGUgZXhhbXBsZSBieSBzYXlpbmcNCg0KQmVzdCBvbmUgaXMgUjIgLSBTSUQxMiAtIFIy IChzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSxzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSkN CiAgID09PiBTSUQxMiBpcyBzZWxlY3RlZCBmb3IgUjIuDQoNCkJ1dCBzaW5jZSB0aGVyZSBpcyBu byByZXByZXNlbnRhdGlvbiBvZiDigJxyYW5nZeKAnSBpbiB5b3VyIGV4YW1wbGVzIEkgcmVhbGx5 IGhhdmUgbm8gaWRlYSBob3cgeW91IGNhbWUgdG8gdGhpcyBjb25jbHVzaW9uIC4NCltCcnVub10g SSBhZ3JlZSB0aGF0IHNpbmNlIHRoZSBhYm92ZSBhbGdvIHVzZWQgMiBtYXBwaW5nIGVudHJpZXMg dG8gcHJvdmlkZXMgdGhlIChTSURpLCBQaWopLCB0aGUgcHJlZmVyZW5jZSBhbGdvICjCpzMuMi40 KSB3b3VsZCBuZWVkIHRvIGJlIGFkYXB0ZWQuIFRoYXQgYmVpbmcgc2FpZCwgdGhpcyBpcyBub3Qg aW1wb3J0YW50IGZvciB0aGlzIGRpc2N1c3Npb24uIExldOKAmXMganVzdCBjb25zaWRlcmVkIHRo YXQgdGhlaXIgZXhpc3QgYSBwcmVmZXJlbmNlIGFsZ29yaXRobSwgd2hpY2ggdGFrZXMgYXMgaW5w dXQgYSBsaXN0IG9mIChTSURpLCBQaWlqKSBmb3IgUDEsIGFuZCBnaXZlcyBhcyBvdXRwb3V0IHRo ZSDigJxiZXN04oCdIG9uZS4gKGRlZmluaXRpb24gb2Yg4oCcYmVzdOKAnSBpcyBub3QgcGVydGlu ZW50KQ0KDQoNCj8/DQoNCkFzIHJlZ2FyZHMg4oCccGVyIEZFQy9QcmVmaXjigJ0sIEkgYmVsaWV2 ZSB0aGlzIGlzIHdoYXQg4oCcaWdub3JlIG92ZXJsYXAgb25seeKAnSBkb2VzLg0KW0JydW5vXSBJ bmRlZWQsIHRoaXMgaXMgbXkgZXhwZWN0YXRpb24uIEJ1dCBJIHdvdWxkIG5lZWQgc29tZW9uZeKA mXMgcmV2aWV3IHRvIGNvbmZpcm0gdGhpcy4NCkJ1dCB0aGUgZGlmZmVyZW5jZSBpcyB0aGF0IHRo ZSBwcm9wb3NlZCBhbGdvIGlzIHNpbXBsZSAoMiBsaW5lcyBvZiBwc2V1ZG8gY29kZSksIHdpdGgg dmVyeSBtb2Rlc3QgcmVzcXVpcmVtZW50IGRhdGEgc3RydWN0dXJlIHVzZSB0byBzdG9yZSB0aGUg bWFwcGluZyBlbnRyaWVzLiBJbmRlZWQsIGFsbCBpdCBuZWVkcyBpcyBhIGZ1bmN0aW9uIHJldHVy bmluZyB0aGUgbGlzdCBvZiBtYXBwaW5nIGVudHJpZXMgYXNzb2NpYXRlZC9tYXRjaGluZyBhIGdp dmVuIHByZWZpeC4gQW5kIGZ1bmN0aW9uIHJldHVybmluZyB0aGUgbGlzdCBvZiBtYXBwaW5nIGVu dHJpZXMgYXNzb2NpYXRlZC9tYXRjaGluZyBhIGdpdmVuIFNJRC4NCkluIHBhcnRpY3VsYXIsIHRo ZXJlIGlzIG5vIG5lZWQgZm9yIHNwbGl0dGluZyBtYXBwaW5nIGVudHJpZXMgd2hpY2ggaXMgdGhl IG1haW4gY29tcGxleGl0eSBvZiB5b3VyIHByb3Bvc2VkIOKAnFByZWZlcmVuY2UgYWxnb3JpdGht L2lnbm9yZSBvdmVybGFwIG9ubHnigJ0uIChhY2NvcmRpbmcgdG8geW91ciBvd24gdGV4dCkuDQoN Ci0tIEJydW5vDQoNCg0KICAgIExlcw0KDQoNCkZyb206YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4gW21haWx0bzpicnVuby5kZWNyYWVu ZUBvcmFuZ2UuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDc6MjIgQU0NClRv OiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3By aW5nQGlldGYub3JnPg0KU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJl c29sdXRpb24gLSBQb2xpY3kNCg0KTGVzLA0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGVkIGRyYWZ0 Lg0KDQpJSU5NLCB5b3UgaGF2ZSBub3QgYW5zd2VyZWQgbXkgYmVsb3cgZW1haWwvcHJvcG9zYWwu IEkgaGFkIHdhaXRlZCBmb3IgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBidXQgaXQgYWxz byBkb2VzIG5vdCB0b3VjaCB0aGlzIHN1YmplY3QuDQoNClNvLCBjb3VsZCB5b3UgcGxlYXNlIGNv bnNpZGVyIGFuZCBhbnN3ZXIgbXkgY29tbWVudD8NCg0KSW4gc2hvcnQsIGluIGFuIGltcGxlbWVu dGF0aW9uLWluZGVwZW5kZW50IHNlbnRlbmNlOg0KDQo+IEknbSB3b25kZXJpbmcgaWYgd2UgY291 bGQgYWRkcmVzcyB0aGUgY29uZmxpY3Qgb24gYSBwZXIgRkVDL1ByZWZpeCBiYXNpcyByYXRoZXIg dGhhbiBvbiBhIHBlciBJR1AgYWR2ZXJ0aXNlbWVudCAocmFuZ2UpIGJhc2lzLg0KPiBJZiBzbywg dGhpcyBtYXkgYXZvaWQgdGhlIGRpc2N1c3Npb24gYmV0d2VlbiB0aGUgUXVhcmFudGluZSB2cyBp Z25vcmUgcG9saWN5Lg0KDQoNClRoYW5rcw0KQnJ1bm8NCg0KDQpGcm9tOiBzcHJpbmcgW21haWx0 bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+DQpTZW50OiBXZWRuZXNk YXksIE1heSAxOCwgMjAxNiAxOjU3IFBNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IHNw cmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJp bmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBQb2xpY3kNCg0KTGVz LA0KDQpQbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dDQoNCkZyb206IExlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpIFttYWlsdG86Z2luc2JlcmdAY2lzY28uY29tXQ0KU2VudDogU3VuZGF5LCBNYXkgMTUs IDIwMTYgMTI6NDEgQU0NClRvOiBERUNSQUVORSBCcnVubyBJTVQvT0xOOyBzcHJpbmdAaWV0Zi5v cmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXNwcmlu Zy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5DQoNCkJydW5vIOKAkw0KDQpJIGFtIGhhdmlu ZyBkaWZmaWN1bHR5IHBhcnNpbmcgdGhlIGV4YW1wbGVzIHlvdSBwcm92aWRlIGJlbG93IGFzIHRo ZXkgc2VlbSB0byBpbmNvcnBvcmF0ZSBhZHZlcnRpc2VtZW50IHNvdXJjZSBpbnRvIHRoZSBkZXNj cmlwdGlvbiB3aGVyZWFzIHRoZSBkcmFmdCBkZWxpYmVyYXRlbHkgb21pdHMgc291cmNlLg0KW0Jy dW5vXSBNeSB0ZXh0IGRvZXMgbm90IGluY29ycG9yYXRlIHRoZSBzb3VyY2UsIGJ1dCB0aGUgdHlw ZSBvZiBzb3VyY2UgSU9XIHRoZSB0eXBlIG9mIHN1Yi1UTFYuDQoNClNvIGl0IGRvZXMgbm90IG1h dHRlciBpZiBSMiBzZW5kcyBhbiBhZHZlcnRpc2VtZW50IG9yIFIxMiBzZW5kcyBhZHZlcnRpc2Vt ZW50IG9yIGJvdGggb2YgdGhlbSBkbyAod2hpY2ggY291bGQgaGFwcGVuIHdoZW4gYW4gYWR2ZXJ0 aXNlbWVudCBpcyBsZWFrZWQpIOKAkyB3aGF0IG1hdHRlcnMgaXMgd2hhdCB1bmlxdWUgZW50cmll cyBhcmUgaW4gdGhlIGRhdGFiYXNlIGluZGVwZW5kZW50IG9mIHNvdXJjZS4NCltCcnVub10gSXQg bWF5IG5vdCBtYXR0ZXIgZm9yIHlvdXIgYWxnb3JpdGhtIChwZW5kaW5nIGFub3RoZXIgdGhyZWFk KSwgYnV0IGl0IGRvZXMgZm9yIHRoZSBvbmUgSSBwcm9wb3NlZC4NCg0KSXQgd291bGQgYmUgZ29v ZCBpZiB5b3UgY291bGQgcHJlc2VudCB5b3VyIGV4YW1wbGVzIHVzaW5nIHRoZSBmb3JtYXQgZGVm aW5lZCBpbiB0aGUgZHJhZnQgaS5lLjoNCltCcnVub10gTXkgZXhhbXBsZXMgYXJlIGRlc2NyaWJl ZCBpbiBwbGFpbiB0ZXh0LiBUaGVuIHRoZSBleGFtcGxlcyBnaXZpbmcgaW50ZXJtZWRpYXRlIHN0 ZXBzIG9mIG15IGFsZ28gdXNlcyB0aGUgZGF0YSB0aGF0IGFyZSBuZWVkZWQgaS5lLiB0aGUgdHlw ZSBvZiBhZHZlcnRpc2VtZW50IChQcmVmaXgtU0lEIHZzIE1TKS4NClRoZW4gZmluYWxseSwgbXkg YWxnbyBydW5zIG9uIGEgcGVyIEZFQy9JUCBQcmVmaXggYmFzaXMsIGFuZCBub3Qgb24gYSBwZXIg SUdQIGFkdmVydGlzZW1lbnQgYmFzaXMgd2hpY2ggeW91ciBmb3JtYXQgZGVzY3JpYmUuDQpTbyBJ 4oCZbSBzb3JyeSBidXQgSSBkb27igJl0IHNlZSBob3cgdG8gaW5kdWxnZSB5b3VyIHJlcXVlc3Qu DQoNCiAgICBQaSAtIEluaXRpYWwgcHJlZml4DQogICAgIFBlIC0gRW5kIHByZWZpeA0KICAgICBM IC0gIFByZWZpeCBsZW5ndGgNCiAgICAgTHggLSBNYXhpbXVtIHByZWZpeCBsZW5ndGggKDMyIGZv ciBJUHY0LCAxMjggZm9yIElQdjYpDQogICAgIFNpIC0gSW5pdGlhbCBTSUQgdmFsdWUNCiAgICAg U2UgLSBFbmQgU0lEIHZhbHVlDQogICAgIFIgLSAgUmFuZ2UgdmFsdWUNCiAgICAgVCAtIFRvcG9s b2d5DQogICAgIEEgLSBBbGdvcml0aG0NCg0KICAgICBBIE1hcHBpbmcgRW50cnkgaXMgdGhlbiB0 aGUgdHVwbGU6IChQaS9MLCBTaSwgUiwgVCwgQSkNCiAgICAgUGUgPSAoUGkgKyAoKFItMSkgPDwg KEx4LUwpKQ0KICAgICBTZSA9IFNpICsgKFItMSkNCg0KRXhhbXBsZTogICAgICgxOTIuMC4yLjEy MC8zMiwgMjAwLCAxLCAwLCAwKQ0KDQpBcyByZWdhcmRzIHlvdXIgcHJvcG9zYWwNCg0KLSBGaW5k IGFsbCBTSURpIGFkdmVydGlzZWQgZm9yIHRoZSBwcmVmaXggUDEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIGlkZW50aWZpY2F0aW9u IG9mIFByZWZpeCBjb25mbGljdHMNCiAgICAgICAgICAgICAgICAtIEZvciBlYWNoIFNJRGkgZmlu ZCBhbGwgdGhlIHByZWZpeCBQaWogYXNzb2NpYXRlZCB3aXRoIFNJRGkgICAgICAgICAgICAgIC8v IGlkZW50aWZpY2F0aW9uIG9mIFNJRCBjb25mbGljdHMNCg0KR2V0IHRoZSBiZXN0IGFzIHBlciB0 aGUgcHJlZmVyZW5jZSBhbGdvcml0aG0uDQpJZiBiZXN0IFBpaiA9PSBQMQ0KICAgICAgICAgICAg ICAgIHRoZW4gdXNlIFNJRGlqIGZvciBQMQ0KICAgICAgICAgICAgICAgIGVsc2UgcmV0dXJuIG5v IFNJRA0KDQp0aGlzIHRvIG1lIHNwZWNpZmllcyBhbiBpbXBsZW1lbnRhdGlvbiDigJMgd2hpY2gg aXNu4oCZdCBuZWNlc3NhcnkuDQpbQnJ1bm9dIFdlbGwsIF95b3VfIGFyZSB0aGUgb25lIHRhbGtp bmcgYWJvdXQgaW1wbGVtZW50YXRpb24sIGFuZCBtb3JlIHNwZWNpZmljYWxseSBpbXBsZW1lbnRh dGlvbiBjb21wbGV4aXR5Lg0KQXNzdW1pbmcgdGhlIGFib3ZlIGFsZ28gd29ya3MsIGl0IGxvb2tz IHJlbGF0aXZlbHkgc2ltcGxlIHRvIGltcGxlbWVudCwgaW4gd2hpY2ggY2FzZSwgSSB3b3VsZCBu b3QgYnV5IHRoZSBhcmd1bWVudCBhYm91dCBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IHdoaWNo IGlzIHRoZSBvbmx5IGFyZ3VtZW50IGluIGZhdm9yIG9yIHRoZSDigJxpZ25vcmXigJ0gb3Ig4oCc cXVhcmFudGluZeKAnSBwb2xpY3kuDQpCb3R0b20gbGluZSwgSSB3b3VsZCB3ZWxjb21lIHlvdXIg ZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoaXMgcHJvcG9zZWQgYWxnby9wb2xpY3kuDQoNClRo YW5rcywNClJlZ2FyZHMsDQotLSBCcnVubw0KDQoNCkhvd2V2ZXIsIHRoZXJlIGlzIG9uZSBpbXBv cnRhbnQgcG9pbnQgd2hpY2ggaGFzIG5vdCBiZWVuIHNwZWNpZmllZCBpbiB0aGUgZHJhZnQgd2hp Y2ggcmVhZGluZyB5b3VyIHBvc3QgaGFzIGJyb3VnaHQgdG8gbXkgYXR0ZW50aW9uIOKAkyB0aGF0 IGlzIHRoZSBvcmRlciBpbiB3aGljaCBjaGVja3MgYXJlIG1hZGUuDQpUaGUgZHJhZnQgc3RhdGVz Og0KDQrigJxQcmVmaXggY29uZmxpY3RzIGFyZSBzcGVjaWZpYyB0byBtYXBwaW5nIGVudHJpZXMg c2hhcmluZyAgdGhlIHNhbWUgdG9wb2xvZ3kgYW5kIGFsZ29yaXRobS7igJ0NCuKAnFNJRCBjb25m bGljdHMgYXJlIGluZGVwZW5kZW50IG9mIGFkZHJlc3MtZmFtaWx5LCAgaW5kZXBlbmRlbnQgb2Yg cHJlZml4IGxlbiwgaW5kZXBlbmRlbnQgb2YgdG9wb2xvZ3ksIGFuZCBpbmRlcGVuZGVudCAgb2Yg YWxnb3JpdGhtLuKAnQ0KDQpJZiB3ZSBjb25zaWRlciBhbiBleGFtcGxlIHdoZXJlIGEgbmV0d29y ayBzdXBwb3J0cyB0d28gVlBOcywgdGhlIHNpZ25pZmljYW5jZSBvZiBvcmRlcmluZyBpbiB0aGUg ZXZhbHVhdGlvbiBvZiBjb25mbGljdHMgd2lsbCBiZSBoaWdobGlnaHRlZDoNCg0KVlBOMToNCigx OTIuMC4yLjEvMzIsIDEwMCwgMSwgMSwgMCkNCigxOTIuMC4yLjEvMzIsIDIwMCwgMSwgMSwgMCkN Cg0KDQpWUE4yOg0KDQooMTkyLjAuMi4xMDAvMzIsIDIwMCwgMSwgMiwgMCkNCg0KSWYgd2UgZXZh bHVhdGUgcHJlZml4IGNvbmZsaWN0cyBmaXJzdCwgdGhlbiB0aGUgZm9sbG93aW5nIGVudHJpZXMg YXJlIOKAnGFjdGl2ZeKAnToNCigxOTIuMC4yLjEvMzIsIDEwMCwgMSwgMSwgMCkgIVZQTjENCigx OTIuMC4yLjEwMC8zMiwgMjAwLCAxLCAyLCAwKSAhVlBOMg0KDQpJZiB3ZSBldmFsdWF0ZSBTSUQg Y29uZmxpY3RzIGZpcnN0LCB0aGVuIHRoZSBmb2xsb3dpbmcgZW50cmllcyBhcmUg4oCcYWN0aXZl 4oCdOg0KKDE5Mi4wLjIuMS8zMiwgMTAwLCAxLCAxLCAwKSAhVlBOMQ0KDQpUaGUgbGF0dGVyIGNo b2ljZSBpcyBzdWJvcHRpbWFsIGJlY2F1c2UgaXQgcHJldmVudHMgdXNlIG9mIHRoZSBWUE4yIGVu dHJ5IHVubmVjZXNzYXJpbHkuDQoNClRoaXMgcG9pbnQgbmVlZHMgdG8gYmUgbWFkZSBleHBsaWNp dCBpbiB0aGUgZHJhZnQuDQoNCiAgICBMZXMNCg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t PG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KU2VudDogVGh1cnNkYXksIE1heSAx MiwgMjAxNiA4OjIzIEFNDQpUbzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0 aW9uIC0gUG9saWN5DQoNCkhpIGF1dGhvcnMsIGFsbA0KDQpBcyBhbiBpbmRpdmlkdWFsIGNvbnRy aWJ1dG9yLCBwbGVhc2UgZmluZCBiZWxvdyBzb21lIGZlZWRiYWNrIG9uIHRoZSBwb2xpY3kuDQoN CkknbSB3b25kZXJpbmcgaWYgd2UgY291bGQgYWRkcmVzcyB0aGUgY29uZmxpY3Qgb24gYSBwZXIg RkVDL1ByZWZpeCBiYXNpcyByYXRoZXIgdGhhbiBvbiBhIHBlciBJR1AgYWR2ZXJ0aXNlbWVudCBi YXNpcy4NCklmIHNvLCB0aGlzIG1heSBhdm9pZCB0aGUgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBR dWFyYW50aW5lIHZzIGlnbm9yZSBwb2xpY3kuDQoNClRoZSBwcm9ibGVtIHRoYXQgd2UgbmVlZCB0 byBzb2x2ZSwgaXMgdG8gZmluZCB0aGUgU0lEIGZvciBhIHByZWZpeCAoUDEpLg0KVGhlIGFsZ28g Y291bGQgYmU6DQotIEZpbmQgYWxsIFNJRGkgYWR2ZXJ0aXNlZCBmb3IgdGhlIHByZWZpeCBQMSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ly8gaWRlbnRpZmljYXRpb24gb2YgUHJlZml4IGNvbmZsaWN0cw0KICAgICAgICAgICAgICAgIC0g Rm9yIGVhY2ggU0lEaSBmaW5kIGFsbCB0aGUgcHJlZml4IFBpaiBhc3NvY2lhdGVkIHdpdGggU0lE aSAgICAgICAgICAgICAgLy8gaWRlbnRpZmljYXRpb24gb2YgU0lEIGNvbmZsaWN0cw0KDQovLyBh cyBhIHJlc3VsdCwgd2UgZ2V0IGEgbGlzdCBvZiBTSURpIOKAkyBQaWogZm9yIFAxDQoNCkdldCB0 aGUgYmVzdCBhcyBwZXIgdGhlIHByZWZlcmVuY2UgYWxnb3JpdGhtLg0KSWYgYmVzdCBQaWogPT0g UDENCiAgICAgICAgICAgICAgICB0aGVuIHVzZSBTSURpaiBmb3IgUDENCiAgICAgICAgICAgICAg ICBlbHNlIHJldHVybiBubyBTSUQgICAgICAgICAgICAgICAgICAgICAgICAgIC8gbm8gU0lEIGF2 YWlsYWJsZSBmb3IgdGhpcyBwcmVmaXggUDENCg0KDQogICBOb3RlIHRoYXQgaXQgd291bGQgcHJv YmFibHkgYmUgYmV0dGVyIGZvciB0aGUgcHJlZmVyZW5jZSBhbGdvIHRvIHB1dCB0aGUgU0lEIHRp ZS1icmFrZSBiZWZvcmUgdGhlIHByZWZpeCB0aWUtYnJlYWsgYXMgd2l0aCB0aGUgcHJlZml4IHRp ZS1icmVhaywgd2Ugc3VmZmVyIGZyb20gdGhlIGNvbmZsaWN0IHR3aWNlIChQcmVmaXggLSBTSUQg bWFwcGluZywgdGhlbiBTSUQtIHByZWZpeCBtYXBwaW5nKSB3aGljaCBpbmNyZWFzZSB0aGUgZGl2 ZXJzaXR5IGFuZCBoZW5jZSB0aGUgY2hhbmNlIG9mIG5vdCBmaW5kaW5nIGEgdmFsaWQgZW50cnku ICAgQnV0IGZvciB0aGUgYmVsb3cgZXhhbXBsZXMsIEkgdXNlZCB0aGUgcHJlZmVyZW5jZSBhbGdv IGZyb20gZHJhZnQtaWV0Zi0qLTAwDQoNCg0KQmVsb3cgYXJlIGV4YW1wbGVzLCBydW5uaW5nIHRo aXMgcG9saWN5IG9uIHR5cGljYWwgY29uZmlndXJhdGlvbiBlcnJvciBjYXNlcy4NCkV4YW1wbGVz DQozLjQuNC4gIE5ldHdvcmsgb3BlcmF0aW9uDQoNCiAgIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcg c2ltcGxlIG5ldHdvcmsgZXhhbXBsZToNCg0KICAgMS4gIDEwMCBub2RlczogUjEgdG8gUjEwMDsN Cg0KICAgMi4gIElQIExvb3BiYWNrcyBhcmUgZnJvbSAxOTIuMC4yLjEgdG8gMTkyLjAuMi4xMDA6 DQoNCiAgIDMuICBTSUQgYXJlIGZyb20gMSB0byAxMDA7DQoNCiAgIDQuICBSMSB0byBSNTAgYXJl IFNSIGNhcGFibGUgYW5kIGFkdmVydGlzZWQgdGhlaXIgb3duIFNJRCB1c2luZw0KICAgICAgIFBy ZWZpeC1TSUQgc3ViLVRMVjsNCg0KICAgNS4gIFI1MSB0byBSMTAwIGFyZSBTUiBub24tY2FwYWJs ZSwgcnVubmluZyBMRFAgYW5kIHRoZWlyIFNJRCBhcmUNCiAgICAgICBhZHZlcnRpc2VkIGJ5IHR3 byByZWR1bmRhbnQgTWFwcGluZyBTZXJ2ZXIgTVMxIGFuZCBNUzI7DQoNCiAgIDYuICBBcyB0aGUg bnVtYmVyIG9mIG5vZGVzIHdoaWNoIGFyZSBTUiBjYXBhYmxlIGFyZSBleHBlY3RlZCB0bw0KICAg ICAgIGluY3JlYXNlIGFuZCBhcyBpbiByZWFsIGRlcGxveW1lbnQgdGhlaXIgTG9vcGJhY2sgYWRk cmVzc2VzIHdvdWxkDQogICAgICAgbm8gdGhlIGNvbnRpZ3VvdXMsIHRoZSBNYXBwaW5nIHNlcnZl cnMgYWR2ZXJ0aXNlbWVudCBjb3ZlcnMgYWxsDQogICAgICAgTG9vcGJhY2tzOiAoMTkyLjAuMi4x LzMyLCAxLCAxMDApOw0KDQogICBTdWJzZXF1ZW50IHNlY3Rpb25zIGV2YWx1YXRlIHRoZSBjb25z ZXF1ZW5jZXMgb2YgYSBzaW5nbGUNCiAgIGNvbmZpZ3VyYXRpb24gZXJyb3IsIGZvciBhbGwgY29u ZmxpY3QgcmVzb2x1dGlvbiBvcHRpb25zLg0KDQozLjQuNC4xLiAgRXhhbXBsZSAxOiBTSUQgY29u ZmlndXJlZCBvbiAxIG5vZGUgY29uZmxpY3Qgd2l0aCBTSUQNCiAgICAgICAgICBjb25maWd1cmVk IG9uIGFub3RoZXIgbm9kZQ0KDQogICBGb2xsb3dpbmcgYSB0eXBvIGR1cmluZyBjb25maWd1cmF0 aW9uLCBSMiBpcyBjb25maWd1cmVkIHdpdGggYSBTSUQgb2YNCiAgIDEyLiAgVGhhdCBTSUQgY29u ZmxpY3RzIHdpdGggdGhlIFByZWZpeC1TSUQgYWR2ZXJ0aXNlZCBieSBSMTIgYW5kIHRoZSBNYXBw aW5nIFNlcnZlciBBZHZlcnRpc2VtZW50IGZvciBSMTIuDQogICBOb3RlOiBib3RoIE1TIGFkdmVy dGlzZW1lbnQgYXJlIHRoZSBzYW1lLCBzbyB3ZSBvbmx5IGNvbnNpZGVyIG9uZSBpbiB0aGUgYmVs b3cgYW5hbHlzaXMuDQoNCiAgIEFsbCBwcmVmaXggYnV0IFIyIGFuZCBSMTIsIGEgc2luZ2xlIFNJ RCBpcyBhZHZlcnRpc2VkIGFuZCBoZW5jZSBzZWxlY3RlZC4NCg0KICAgRm9yIFIyLCB0aGUgYWxn byBldmFsdWF0ZXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgYWR2ZXJ0aXNtZW50 czoNCiAgIFIyIC0gU0lEMiAtIFIyIChNUywgTVMpDQogICBSMiAtIFNJRDEyIC0gUjEyIChwcmVm aXggU0lELCBNUykNCiAgIFIyIC0gU0lEMTIgLSBSMiAgKHByZWZpeCBTSUQsIHByZWZpeCBTSUQp DQoNCg0KICAgQmVzdCBvbmUgaXMgUjIgLSBTSUQxMiAtIFIyIChzbWFsbGVyIHJhbmdlIChwcmVm aXggU0lEKSxzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSkNCiAgID09PiBTSUQxMiBpcyBzZWxl Y3RlZCBmb3IgUjIuDQoNCiAgIEZvciBSMTIsIHRoZSBhbGdvIGV2YWx1YXRlcyBhIGNvbmZsaWN0 IGJldHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOg0KICAgUjEyIC0gU0lEMTIgLSBS MTIgKHByZWZpeCBTSUQsIHByZWZpeCBTSUQpDQogICBSMTIgLSBTSUQxMiAtIFIyICAocHJlZml4 IFNJRCwgcHJlZml4IFNJRCkNCiAgIFIxMiAtIFNJRDEyIC0gUjEyIChwcmVmaXggU0lELCBNUykN CiAgIFIxMiAtIFNJRDEyIC0gUjIgIChNUywgcHJlZml4IFNJRCkNCiAgIFIxMiAtIFNJRDEyIC0g UjEyIChNUywgTVMpDQoNCiAgIEJlc3Qgb25lIGlzIFIxMiAtIFNJRDEyIC0gUjIgKHNtYWxsZXIg cmFuZ2UgKHByZWZpeCBTSUQpLHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpLCBzbWFsbGVyIHN0 YXJ0aW5nIGFkcmVzc2UgKFIyKSkNCiAgIFIxMiA8PiBSMiA9PT4gUjEyIGhhcyBubyBTSUQuDQoN CiAgIDMuNC40LjIuICBFeGFtcGxlIDI6IFNJRCBjb25maWd1cmVkIG9uIDEgbm9kZSBjb25mbGlj dCB3aXRoIFNJRA0KICAgICAgICAgIGNvbmZpZ3VyZWQgb24gdGhlIE1hcHBpbmcgU2VydmVyDQoN CiAgIEZvbGxvd2luZyBhIHR5cG8gZHVyaW5nIGNvbmZpZ3VyYXRpb24sIFIyIGlzIGNvbmZpZ3Vy ZWQgd2l0aCBhIFNJRCBvZg0KICAgNTIuICBUaGF0IFNJRCBjb25mbGljdHMgd2l0aCB0aGUgTWFw cGluZyBTZXJ2ZXIgYWR2ZXJ0aXNlbWVudHMgb2YgTVMxDQogICBhbmQgTVMyIGZvciB0aGUgbG9v cGJhY2sgb2YgUjUyLg0KICAgTm90ZTogYm90aCBNUyBhZHZlcnRpc2VtZW50IGFyZSB0aGUgc2Ft ZSwgc28gd2Ugb25seSBjb25zaWRlciBvbmUgaW4gdGhlIGJlbG93IGFuYWx5c2lzLg0KDQogICBB bGwgcHJlZml4IGJ1dCBSMiBhbmQgUjUyLCBhIHNpbmdsZSBTSUQgaXMgYWR2ZXJ0aXNlZCBhbmQg aGVuY2Ugc2VsZWN0ZWQuDQoNCiAgIEZvciBSMiwgdGhlIGFsZ28gZXZhbHVhdGVzIGEgY29uZmxp Y3QgYmV0d2VlbiB0aGUgZm9sbG93aW5nIGFkdmVydGlzbWVudHM6DQogICBSMiAtIFNJRDUyIC0g UjIgIChwcmVmaXggU0lELCBwcmVmaXggU0lEKQ0KICAgUjIgLSBTSUQ1MiAtIFI1MiAocHJlZml4 IFNJRCwgTVMpDQogICBSMiAtIFNJRDIgIC0gUjIgIChNUywgTVMpDQoNCiAgIEJlc3Qgb25lIGlz IFIyIC0gU0lENTIgLSBSMiAoc21hbGxlciByYW5nZSAocHJlZml4IFNJRCksc21hbGxlciByYW5n ZSAocHJlZml4IFNJRCkpDQogICA9PT4gU0lENTIgaXMgc2VsZWN0ZWQgZm9yIFIyLg0KDQogICBG b3IgUjUyLCB0aGUgYWxnbyBldmFsdWF0ZXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSBmb2xsb3dp bmcgYWR2ZXJ0aXNtZW50czoNCiAgIFI1MiAtIFNJRDUyIC0gUjUyIChNUywgTVMpDQogICBSNTIg LSBTSUQ1MiAtIFIyICAoTVMsIHByZWZpeCBTSUQpDQoNCiAgIEJlc3Qgb25lIGlzIFI1MiAtIFNJ RDUyIC0gUjIgKHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpKQ0KICAgUjUyIDw+IFIyID09PiBS NTIgaGFzIG5vIFNJRC4NCg0KDQozLjQuNC4zLiAgRXhhbXBsZSAzOiB3cm9uZyBjb25maWd1cmF0 aW9uIG9mIGEgTVMNCg0KICAgRm9sbG93aW5nIGEgdHlwbyBkdXJpbmcgY29uZmlndXJhdGlvbiwg TVMxIGlzIGNvbmZpZ3VyZWQNCiAgICgxOTIuMC4yLjAvMzIsIDEsIDEwMCkuIChpLmUuIDE5Mi4w LjIuMCBpbnN0ZWFkIG9mIDE5Mi4wLjIuMSkuICBUaGF0DQogICBhZHZlcnRpc2VtZW50IGNvbmZs aWN0cyB3aXRoIHRoZSBNYXBwaW5nIFNlcnZlciBhZHZlcnRpc2VtZW50cyBvZiBNUzINCiAgIGFu ZCB0aGUgUHJlZml4LVNJRCBhZHZlcnRpc2VkIGJ5IFIxLi4uUjUwLg0KDQogICBXZSBoYXZlIGEg Y29uZmxpY3QgZm9yIGFsbCByb3V0ZXJzIGV4Y2VwdCBSMTAwLg0KDQogICBGb3IgTERQIG9ubHkg cm91dGVycyBSNTEgdG8gUjk5IHdlIGhhdmUgYSBjb25mbGljdCBiZXR3ZWVuIGJvdGggTVMgYWR2 ZXJ0aXNlbWVudC4NCiAgIEZvciBSNTIsIHRoZSBhbGdvIGV2YWx1YXRlcyBhIGNvbmZsaWN0IGJl dHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOg0KICAgUjUyIC0gU0lENTIgLSBSNTIg KE1TMiwgTVMyKQ0KICAgUjUyIC0gU0lENTIgLSBSNTEgKE1TMiwgTVMxKQ0KICAgUjUyIC0gU0lE NTMgLSBSNTIgKE1TMSwgTVMxKQ0KICAgUjUyIC0gU0lENTMgLSBSNTMgKE1TMSwgTVMyKQ0KDQog ICBCZXN0IG9uZSBpcyBSNTIgLSBTSUQ1MiAtIFI1MSAoc21hbGxlciBzdGFydGluZyBhZGRyZXNz KQ0KICAgUjUyIDw+IFI1MSA9PT4gUjUyIGhhcyBubyBTSUQuDQoNCiAgIEZvciBTUiByb3V0ZXJz LCBSMSB0byA1MCwgd2UgaGF2ZSBhIGNvbmZsaWN0IGJldHdlZW4gYm90aCBNUyBhZHZlcnRpc2Vt ZW50IGFuZCBQcmVmaXggU0lEIGFkdmVydGlzZW1lbnRzLg0KICAgRm9yIFIyLCB0aGUgYWxnbyBl dmFsdWF0ZXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgYWR2ZXJ0aXNtZW50czoN CiAgIFIyIC0gU0lEIDIgLSBSMiAoUHJlZml4IFNJRCwgUHJlZml4IFNJRCkNCiAgIFIyIC0gU0lE IDIgLSBSMiAoUHJlZml4IFNJRCwgTVMyKQ0KICAgUjIgLSBTSUQgMiAtIFIxIChQcmVmaXggU0lE LCBNUzEpDQogICBSMiAtIFNJRCAyIC0gUjIgKE1TMiwgTVMyKQ0KICAgUjIgLSBTSUQgMiAtIFIy IChNUzIsIFByZWZpeCBTSUQpDQogICBSMiAtIFNJRCAyIC0gUjEgKE1TMiwgTVMxKQ0KICAgUjIg LSBTSUQgMyAtIFIyICAoTVMxLCBNUzEpDQogICBSMiAtIFNJRCAzIC0gUjMgIChNUzEsIE1TMikN CiAgIFIyIC0gU0lEIDMgLSBSMyAgKE1TMSwgUHJlZml4IFNJRCkNCg0KICAgQmVzdCBvbmUgaXMg UjIgLSBTSUQgMiAtIFIyIChQcmVmaXggU0lELCBQcmVmaXggU0lEKQ0KICAgUjIgPT0gUjIgaGVu Y2UgUjIgdXNlIFNJRDIuDQoNClJlZ2FyZHMsDQpCcnVubw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u Yw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku DQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN Cg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0K DQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoN CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0K DQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0K DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0K VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsN Cg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy DQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoN CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYu b3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmcNCg0K --_000_B8B2C3147ACB43B08CF510588BE66062nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <990CF04CBF2B13438D4ED5DE35AD0677@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+QXMg MSBvZiB0aGUgdmVuZG9ycyBpbXBsZW1lbnRpbmcgdGhpcywgd2UgcHJlZmVyIHRoZSBhcHByb2Fj aCBvZiBpZ25vcmUgb3ZlcmxhcCBhcyBJIHNhaWQgaW4gdGhlIG1lZXRpbmcgaW4gQmVybGluPC9k aXY+DQo8ZGl2PlRoZSBpbXBsaWNhdGlvbiBmcm9tIGltcGxlbWVudGF0aW9uIHMgYXJlIG5vdCBt YXNzaXZlIGFuZCBnaXZlbiBpdCBpcyBtYXhpbWlzaW5nIHRyYWZmaWMgZGVsaXZlcnkgaW4gY2Fz ZSBvZiBjb25mbGljdCwgd2UgcHJlZmVyIHRoaXMgYXBwcm9hY2guPC9kaXY+DQo8ZGl2Pg0KPGRp diBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBNYXJ0aW4gSG9ybmVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86bWFob0BuaWMuZHRhZy5k ZSI+bWFob0BuaWMuZHRhZy5kZTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXkgMjIgSnVseSAyMDE2IGF0IDExOjAxPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7TGVzIEdpbnNiZXJn IChnaW5zYmVyZykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20i PmdpbnNiZXJnQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPk1hcnRpbiBIb3JuZWZmZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpNYXJ0aW4uSG9ybmVmZmVyQHRlbGVrb20uZGUiPk1hcnRpbi5Ib3JuZWZmZXJA dGVsZWtvbS5kZTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1 YmplY3Q6IDwvc3Bhbj5SZTogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVz b2x1dGlvbiAtIFBvbGljeTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KPGRpdiBjbGFzcz0ibW96LWNp dGUtcHJlZml4Ij5IaSBMZXMsPGJyPg0KPGJyPg0KY29tbWVudGluZyByYXRoZXIgb24geW91ciBw cmVzZW50YXRpb24gYXQgdGhlIEJlcmxpbiBXRyBzZXNzaW9uOjxicj4NCjxicj4NCkluIGdlbmVy YWwgSSBkb24ndCBjb25zaWRlciBpdCBhIGJpZyBkZWFsIHdoZXRoZXIgdGhlIFF1YXJhbnRpbmUg b3IgdGhlIElnbm9yZSBPdmVybGFwIHBvbGljeSBpcyBiZWluZyB1c2VkLiBJdCdzIG1haW5seSBp bXBvcnRhbnQgdGhhdCBfb25lXyBvZiB0aGVuIGZpbmFsbHkgZ2V0cyBjaG9zZW4gYW5kIGNvbnNp c3RlbnRseSBpbXBsZW1lbnRlZC48YnI+DQo8YnI+DQpGcm9tIHRoZSBvcGVyYXRvcidzIHBvaW50 IG9mIHZpZXcgSSB0ZW5kIHRvIGFncmVlIHdpdGggb3RoZXIgb3BlcmF0b3JzIHRoYXQgdGhlIEln bm9yZSBPdmVybGFwIHBvbGljeSBsb29rcyBiZXR0ZXIgZm9yIG1vc3QgcmVhbGlzdGljIGNhc2Vz LCBldmVuIHRob3VnaCBsZXNzIHdvcnJpZWQgYWJvdXQgdGhlIGFtb3VudCBvZiB0cmFmZmljIGxv c3QsIGJ1dCBtb3JlIGFib3V0IHJvYnVzdG5lc3MgYW5kIHNlY3VyaXR5IGFzcGVjdHMuPGJyPg0K PGJyPg0KQ29tcGxleGl0eSBvZiBpbXBsZW1lbnRhdGlvbiwgaG93ZXZlciwgY2FuIGJlIGEgc2Vy aW91cyBhcmd1bWVudCBhZ2FpbnN0IGl0LCBhcyB0aGlzIGFsc28gd29ya3MgYWdhaW5zdCByb2J1 c3RuZXNzIGFuZCBzZWN1cml0eS48YnI+DQo8YnI+DQpOb2JvZHkgZG91YnRzIHRoYXQgdGhlIEln bm9yZSBPdmVybGFwIHBvbGljeSBpcyBtb3JlIGNvbXBsZXguIEJ1dCBob3cgbXVjaCBjb21wbGV4 aXR5IGl0IHJlYWxseSBhZGRzIGlzIGhhcmQgdG8gZXN0aW1hdGUgZm9yIG1lLiBJcyBpdCBhIG1p bm9yIGNvbXBsaWNhdGlvbiBvciBhIGJpZyBvbmU/PGJyPg0KPGJyPg0KU28gZmFyIEkgaGF2ZSBz ZWVuIG9uZSB2ZW5kb3IgdGFsayBhZ2FpbnN0IHRoZSBJZ25vcmUgT3ZlcmxhcCBwb2xpY3kgYW5k IHR3byB2ZW5kb3JzIHRha2luZyBhIHBvc2l0aW9uIGluIGZhdm9yIG9mIGl0Ljxicj4NCjxicj4N ClNvdW5kcyB0byBtZSBsaWtlIDI6MSBmb3IgSWdub3JlIE92ZXJsYXAgc28gZmFyLiBCdXQgd2Ug YWN0dWFsbHkgZG9uJ3QgYmVsaWV2ZSBpbiB2b3RpbmcgYW5kIG5lZWQgbW9yZSB2ZW5kb3IgaW5w dXQgYW55d2F5cyE8YnI+DQo8YnI+DQpCUiw8YnI+DQpNYXJ0aW48YnI+DQo8YnI+DQo8YnI+DQpB bSAwNS4wNy4xNiB1bSAxOToyNSBzY2hyaWViIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOmViMGNmNjlkYjc0NjQxNTk5ZmMxODQzYWFh YTUxNTg2QFhDSC1BTE4tMDAxLmNpc2NvLmNvbSIgdHlwZT0iY2l0ZSI+DQo8bWV0YSBuYW1lPSJH ZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZA0KICAgICAgICBt ZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLlByZm9ybWF0SFRNTCwgbGku UHJmb3JtYXRIVE1MLCBkaXYuUHJmb3JtYXRIVE1MDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9y bWF0w6kgSFRNTCI7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUHJmb3JtYXRIVE1M Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywg ZGl2LlRleHRlZGVidWxsZXMNCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJ bXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxl LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUzNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzUNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM2DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwNzg3NDU3NjU7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NTY5MTExOTAgNjc4OTUzMTkgNjc4 OTUzMjEgNjc4OTUzMjMgNjc4OTUzMTEgNjc4OTUzMjEgNjc4OTUzMjMgNjc4OTUzMTEgNjc4OTUz MjEgNjc4OTUzMjM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ QnJ1bm8g4oCTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ud28gY29tbWVu dHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4xKUFzIHdlIGJvdGggY2Fu IGNvbWUgdXAgd2l0aCBleGFtcGxlcyB3aGVyZSBhIGdpdmVuICZuYnNwO3ByZWZlcmVuY2UgYWxn b3JpdGhtIHdpbGwgcmVzdWx0IGluIOKAnGJldHRlcuKAnSBiZWhhdmlvciB0aGFuIGFub3RoZXIs IGNvbnRpbnVpbmcgdG8gZGViYXRlIHdoaWNoIG9uZSBpcyDigJxiZXN04oCdIGhhcyBubyBlbmQu IFRoZSBhbnN3ZXIgZGVwZW5kcyB1cG9uIHdoYXQgdHlwZXMNCiBvZiBlcnJvcnMgYXJlIGludHJv ZHVjZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24gYW5kIHRoYXQgaXNu4oCZdCBwcmVkaWN0YWJsZS4g SWYgaXQgaXMgbmVjZXNzYXJ5IGZvciB1cyB0byBhZ3JlZSBvbiB3aGljaCBhbGdvcml0aG0gaXMg 4oCcYmVzdOKAnSBJIGRvdWJ0IHRoYXQgY29uc2Vuc3VzIHdpbGwgZXZlciBiZSByZWFjaGVkLiBJ dCB0aGVyZWZvcmUgaXMgbW9yZSBpbXBvcnRhbnQgdG8gbWUgdG8gZm9jdXMgb24gaW1wbGVtZW50 YXRpb24gY29tcGxleGl0eQ0KIGFuZCB0aGUgaW1wb3J0YW5jZSBvZiBpZGVudGlmeWluZyBhbmQg Y29ycmVjdGluZyBtaXNjb25maWd1cmF0aW9ucyBBU0FQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+MilUaGVyZSBhcmUgdHdvIGxvZ2ljYWwgZGF0YWJhc2VzIHRoYXQgYW4g aW1wbGVtZW50YXRpb24gaGFzIHRvIHN1cHBvcnQuIE9uZSBvZiB0aGVtIGlzIHRoZSBzZXQgb2Yg cmVjZWl2ZWQgYWR2ZXJ0aXNlbWVudHMgd2hpY2ggY2FuIGluY2x1ZGUgZW50cmllcyB3aXRoIGEg dmFyaWV0eSBvZiByYW5nZXMuIFRoZSBzZWNvbmQgb25lIGlzIHRoZSBzZXQgb2YgbWFwcGluZw0K IGVudHJpZXMgd2hpY2ggYXJlIGluIHVzZSBmb3IgbG9va3Vwcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91 ciBkaXNjdXNzaW9uIG9mIHlvdXIg4oCccGVyIEZFQyBhbGdvcml0aG3igJ0gJm5ic3A7YmVsb3cg ZGVmaW5lcyB0aGUgc2Vjb25kIGRhdGFiYXNlIGFzIGEgc2V0IG9mIGVudHJpZXMgYWxsIG9mIHdo aWNoIGhhdmUgYSByYW5nZSBvZiAxLiBXaGV0aGVyIHRoaXMgaXMgZ29vZCBpbXBsZW1lbnRhdGlv biBtb2RlbCBvciBub3QgSSBhbSBub3QgY29tbWVudGluZyBvbiBoZXJlLg0KIEJ1dCB0aGlzIGRv ZXMgbm90IGVsaW1pbmF0ZSB0aGUgbmVlZCB0byBtYWludGFpbiB0aGUgZmlyc3QgZGF0YWJhc2Ug 4oCTIGFuZCB0byBiZSBhYmxlIHRvIGFzc29jaWF0ZSBlbnRyaWVzIGluIHRoZSBzZWNvbmQgZGF0 YWJhc2Ugd2l0aCB0aGUgY29ycmVzcG9uZGluZyByZWNlaXZlZCBlbnRyeSBmcm9tIHdoaWNoIHRo ZXkgbWF5IGhhdmUgYmVlbiBkZXJpdmVkLiBUaGVyZSBpcyB3b3JrIGluIG1haW50YWluaW5nIHRo YXQgcmVsYXRpb25zaGlwIHdoaWNoDQogZG9lcyBub3QgZGlyZWN0bHkgYmVhciBvbiB0aGUgbG9v a3VwIGZvciBhIGdpdmVuIFNJRCBidXQgc3RpbGwgaGFzIHRvIGJlIGRvbmUgaWYgb25lIHVzZXMg 4oCccGVyIEZFQ+KAnSBvciDigJxJZ25vcmUgT3ZlcmxhcCBPbmx54oCdLiBUaGlzIHdvcmsgaXMg bm90IHJlcXVpcmVkIGZvciB0aGUg4oCccGVyIHJhbmdl4oCdIG9yIOKAnFF1YXJhbnRpbmXigJ0g YWxnb3JpdGhtLiBJdCBpcyB0aGlzIGFkZGl0aW9uYWwgd29yayB0aGF0IEkgcmVmZXIgdG8gd2hl biBJIHNheSB0aGF0DQog4oCccGVyIEZFQ+KAnSBoYXMgYSBoaWdoZXIgaW1wbGVtZW50YXRpb24g Y29zdC9jb21wbGV4aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IExlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbg0KICAgICAgICAgIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE Rg0KICAgICAgICAgICAgICAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPjxhIGNsYXNz PSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPg0KIFs8YSBjbGFzcz0ibW96 LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bSI+bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEp1bHkgMDUsIDIwMTYgMTo1MCBBTTxicj4NCjxiPlRvOjwvYj4gTGVzIEdp bnNiZXJnIChnaW5zYmVyZyk8YnI+DQo8Yj5DYzo8L2I+IDxhIGNsYXNzPSJtb3otdHh0LWxpbmst YWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb24gLSBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+TGVzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEy Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzgwNjRBMiI+UGxlYXNlIHNlZSBpbmxpbmUgW0JydW5vXTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYNCiAgICAgICAgICAgICAgICAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fu cy1zZXJpZjsiPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSBbPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7IiBsYW5nPSJGUiI+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJt YWlsdG86Z2luc2JlcmdAY2lzY28uY29tIj48c3BhbiBsYW5nPSJFTi1VUyI+bWFpbHRvOmdpbnNi ZXJnQGNpc2NvLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw cHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgSnVseSAwNSwgMjAxNiA5OjA4IEFNPGJyPg0KPGI+VG86PC9iPiBERUNSQUVO RSBCcnVubyBJTVQvT0xOPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiIGxhbmc9IkZSIj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5zcHJpbmdAaWV0Zi5vcmc8L3Nw YW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRm LXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJy dW5vIOKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgdGhl IGZvbGxvd2luZyBzaW1wbGUgY2FzZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkVudHJ5ICMxOiAoUEZYLCAxLjEuMS4xLzMyLCAxMDAsIDEsIDAsMCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+RW50cnkgIzI6IChTUk1TLCAxLjEuMS4xLzMyLCAyMDAsIDEwLCAwLDApPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkVudHJ5ICMzOiAoU1JNUywgMi4yLjIuMi8zMiwgMjAwLCAxMC4gMCwgMCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIGEgbWlzY29uZmlndXJhdGlvbiBo ZXJlLCBidXQgd2UgZG9u4oCZdCBrbm93IHdoYXQgd2FzIHJlYWxseSBpbnRlbmRlZC4gQSBmZXcg KG9mIG1hbnkpIHBvc3NpYmlsaXRpZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5FUlJPUiAjMTombmJzcDsmbmJzcDsgRW50cnkgIzIgc2hvdWxkIGhhdmUgYmVlbjogKFNS TVMsIDEuMS4xLjEvMzIsIDEwMCwgMTAsIDAsMCkgIVN0YXJ0aW5nIFNJRCBlcnJvcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5FUlJPUiAjMjombmJzcDsgRW50cnkgIzIgc2hvdWxkIGhhdmUgYmVlbjogKFNSTVMs IDIuMi4yLjIvMzIsIDIwMCwgMTAsIDAsMCkgIVN0YXJ0aW5nIHByZWZpeCBlcnJvcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGRyYWZ0IGRlZmluZXMgdHdvIGNhbmRp ZGF0ZSBwcmVmZXJlbmNlIHJ1bGVzIHdoaWNoIGNvdWxkIGJlIGFwcGxpZWQ6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5RdWFyYW50aW5lPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgd2UgZXZhbHVhdGUgcHJlZml4IGNvbmZsaWN0 cyBmaXJzdCwgd2UgY29tcGFyZSBFbnRyeSAjMSBhbmQgRW50cnkgIzIgYW5kIGNob29zZSBFbnRy eSAjMSB0aGUgd2lubmVyIChzb3VyY2UgaXMgUEZYKS4gRW50cnkgIzIgaXMgdGhlbiBub3QgdXNl ZCAocXVhcmFudGluZWQpIGFuZCB0aGUgc2V0IG9mIGFjdGl2ZSBlbnRyaWVzIGlzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RW50cnkgIzE6IChQRlgsIDEuMS4xLjEvMzIs IDEwMCwgMSwgMCwwKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAjMzogKFNSTVMsIDIuMi4yLjIvMzIs IDIwMCwgMTAuIDAsIDApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZ25v cmUgQ29uZmxpY3QgT25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkluIHRoaXMgY2FzZSB3ZSBzcGxpdCBFbnRyeSAjMiBpbnRvIHR3byBk ZXJpdmVkIGVudHJpZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRy eSAjMkE6IChTUk1TLCAxLjEuMS4xLzMyLCAyMDAsIDEsIDAsMCk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RW50 cnkgIzJCOiAoU1JNUywgMS4xLjEuMi8zMiwgMjAxLCA5LCAwLDApPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAyQSBpcyB0aGVuIGlnbm9yZWQgYW5kIHdlIHRoZW4g aGF2ZSB0byBldmFsdWF0ZSBTSUQgY29uZmxpY3RzIGJldHdlZW4gdGhlIGRlcml2ZWQgZW50cnkg MkIgYW5kIEVudHJ5ICMzLiAmbmJzcDtGb3IgdGhpcyB3ZSBoYXZlIHRvIHNwbGl0IEVudHJ5IDMg aW50byB0d28gZGVyaXZlZCBlbnRyaWVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+RW50cnkgIzNBOiAoU1JNUywgMi4yLjIuMi8zMiwgMjAwLCAxLiAwLCAwKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5FbnRyeSAjM0I6IChTUk1TLCAyLjIuMi4zLzMyLCAyMDEsIDkuIDAsIDApPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAyQiB3aW5zIG92ZXIgZW50cnkg M0Igc2luY2UgaXQgaGFzIGEgc21hbGxlciByYW5nZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkFjdGl2ZSBlbnRyaWVzIGFyZSB0aGVuOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRy eSAjMTogKFBGWCwgMS4xLjEuMS8zMiwgMTAwLCAxLCAwLDApPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVudHJ5 ICMyQjogKFNSTVMsIDEuMS4xLjIvMzIsIDIwMSwgOSwgMCwwKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRy eSAjM0E6IChTUk1TLCAyLjIuMi4yLzMyLCAyMDAsIDEuIDAsIDApPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5Ob3RlIHRoYXQgaW4gdGhpcyBleGFtcGxlIGJvdGggcHJlZmVy ZW5jZSBydWxlcyByZXN1bHQgaW4gMTEgZGVzdGluYXRpb25zIGhhdmluZyBub24tY29uZmxpY3Rp bmcgU0lEcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzgwNjRBMiI+W0JydW5vXSBZZXMuIFRoZSBpbXBvcnRhbnQgcGFydCBp cyDCqyZuYnNwO2luIHRoaXMgZXhhbXBsZSZuYnNwO8K7LiBOb3cgZG8gd2UgYWdyZWUgdGhhdCBp biBhdmVyYWdlLCBRdWFyYW50aW5lIHdpbGwgcmVzdWx0IGluIGRyb3BwaW5nIG1vcmUgZGVzdGlu YXRpb25zIHRoYW4gSWdub3JlIGNvbmZsaWN0IG9ubHk/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDtOb3csIHdoaWNoIG9mIHRoZXNlIG1heGltaXplcyBkZWxpdmVy eSBvZiB0cmFmZmljPyBUaGUgYW5zd2VyIHRvIHRoYXQgZGVwZW5kcyB1cG9uIHRoZSB0eXBlIG9m IGNvbmZpZ3VyYXRpb24gZXJyb3IgdGhhdCB3YXMgbWFkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgRXJy b3IgIzEgd2FzIG1hZGUsIHRoZXJlIGlzIG5vIHdheSB0byBkaWZmZXJlbnRpYXRlIHRoZSB0d28g cHJlZmVyZW5jZSBydWxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYgRXJyb3IgIzIgd2Fz IG1hZGUsIHRoZW4gUXVhcmFudGluZSBpcyBjbGVhcmx5IGJldHRlciBiZWNhdXNlIHRoZSBkZXN0 aW5hdGlvbnMgMS4xLjEuMiDigJMgMS4xLjEuMTAgd2VyZSBuZXZlciBpbnRlbmRlZCB0byBoYXZl IGFzc2lnbmVkIFNJRHMgYW5kIG1heSBub3QgZXZlbiBleGlzdCBhcyBkZXN0aW5hdGlvbnMgaW4g dGhlIG5ldHdvcmssIHlldA0KIOKAnElnbm9yZSBDb25mbGljdCBPbmx54oCdIGZhdm9ycyB0aG9z ZSBwcmVmaXhlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBwb2lu dCBJIGFtIHRyeWluZyB0byBtYWtlIGlzIHRoYXQgaXQgaXMgaW5jb3JyZWN0IHRvIHNheSDigJxJ ZiB3ZSBtYXhpbWl6ZSB0aGUgbnVtYmVyIG9mIGFkdmVydGlzZWQgZW50cmllcyB3aGljaCB3ZSB1 c2Ugd2Ugd2lsbCBhbHdheXMgZG8gYSBiZXR0ZXIgam9iIG9mIGRlbGl2ZXJpbmcgdHJhZmZpYy7i gJ0gVGhpcyBleGFtcGxlIGlsbHVzdHJhdGVzIHRoYXQNCiB0aGlzIGlzbuKAmXQgYWx3YXlzIHRy dWUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODA2NEEyIj5bQnJ1bm9dIE9LLiBDbGVhcmx5LCB3ZSBjYW4gZmluZCBhbiBl eGFtcGxlIHdoZXJlIGFuIGFsZ29yaXRobSBpcyBiZXR0ZXIgdGhhbiB0aGUgb3RoZXIuIEFmdGVy IGFsbCwgd2UgYWxsIGFncmVlIHRoYXQgdGhlcmUgaGFzIGJlZW4gYSBjb25maWd1cmF0aW9uIGVy cm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODA2NEEyIj5UaGVyZSBhcmUgMiBwb2ludHM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3Bh biBzdHlsZT0iY29sb3I6IzgwNjRBMiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YSk8 c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxl PSJjb2xvcjojODA2NEEyIj5ob3cgbWFueSBkZXN0aW5hdGlvbiB5b3Uga2VlcCB1c2luZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IS0tW2lmICFzdXBwb3J0 TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPmIpPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0t LT48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+aW4gY2FzZSBvZiBjb25mbGljdCB3aGljaCBv ZiB0aGUgZW50cmllcyB5b3Ugc2VsZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2 NEEyIj5JIGFncmVlIHRoYXQg4oCcYuKAnSBpcyBtb3JlIG9yIGxlc3MgcmFuZG9tIGFuZCBoZW5j ZSB0aGVyZSBhcmUgbWFueSBjYXNlcyB3aGVyZSB3ZeKAmWxsIHBpY2sgdGhlIHdyb25nIG9uZS4g WWV0LCB3ZSB0cnkgdG8gbWFrZSByZWFzb25hYmxlIGNob2ljZXMuIFRoYXQgdGhlIHBvaW50IG9m IGRpc2N1c3NpbmcgdGhlIHByZWZlcmVuY2UgYWxnb3JpdGhtICgzLjIuNCkuIChBbHRob3VnaA0K IGl04oCZcyB2ZXJ5IGVhc3kgdG8gYXJndWUgdGhhdCB3ZSBjYW4gbWFrZSB0aGUgd3JvbmcgY2hv aWNlLCBJIGRvbuKAmXQgZmVlbCB0aGF04oCZcyBhIHJlYXNvbiBub3QgdG8gdHJ5IGRpc2N1c3Np bmcgaXQgYW5kIG1ha2UgY2hvaWNlLiBlLmcuPC9zcGFuPiDigJw8c3BhbiBzdHlsZT0iY29sb3I6 IzgwNjRBMiI+UEZYIHNvdXJjZSB3aW5zIG92ZXIgU1JNUyBzb3VyY2XigJ0gaXMgb25lOiB3ZSBn aXZlIHByZWZlcmVuY2UgdG8gU1Igbm9kZXMgcmF0aGVyIHRoYW4NCiBMRFAgbm9kZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4MDY0QTIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5SZWdhcmRpbmcgYSwgSSBmZWVsIHRoYXQg bWF4aW1pemluZyB0aGUgbnVtYmVyIG9mIGRlc3RpbmF0aW9ucyBrZXB0LCBpcyBsaWtlbHkgdG8g Z2l2ZSB0aGUgYmVzdCByZXN1bHQgaW4gYXZlcmFnZS4gSSBkb27igJl0IGhhdmUgYSBwcm9vZiwg YnV0IGl0IGZlZWwgbGlrZSBwbGF5aW5nIGxvdG86IGV2ZW4gaWYgZWFjaCBjaG9pY2UgaXMgcmFu ZG9tICjigJxi4oCdKSwgdGhlDQogbW9yZSB5b3UgdHJ5ICjigJxh4oCdKSB0aGUgYmV0dGVyIHlv dXIgY2hhbmNlcy4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+QSBmZXcgbW9yZSBjb21tZW50cyBpbmxpbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAg ICAgICAgIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERg0KICAgICAgICAgICAgICAg ICAgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBz YW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij48L3NwYW4+PHNwYW4gbGFuZz0iRlIi PjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhv bWEsIHNhbnMtc2VyaWY7IiBsYW5nPSJFTi1VUyI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwv c3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4NCiBbPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5z LXNlcmlmOyIgbGFuZz0iRU4tVVMiPm1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkg MDQsIDIwMTYgNTowNyBBTTxicj4NCjxiPlRvOjwvYj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk8 YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIiBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgbGFuZz0iRU4tVVMi PnNwcmluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBQb2xpY3k8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXMsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBzZWUgaW5saW5lIFtCcnVub108bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZQ0KICAgICAgICAgICAgICAgIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERg0KICAgICAgICAgICAgICAgICAgICAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSBbPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0 bzpnaW5zYmVyZ0BjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBsYW5nPSJFTi1VUyI+bWFpbHRvOmdpbnNiZXJn QGNpc2NvLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBKdWx5IDAxLCAyMDE2IDM6MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IERFQ1JBRU5FIEJy dW5vIElNVC9PTE48YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIg bGFuZz0iRU4tVVMiPnNwcmluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b24gLSBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnJ1bm8g4oCTPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgZmluZCB5b3VyIHJlcHJlc2VudGF0aW9uIGNv bXBsZXRlIGFzIHJlZ2FyZHMgYWxsIG9mIHRoZSBhdHRyaWJ1dGVzIHdoaWNoIGFyZSBwcm9wb3Nl ZCB0byBiZSB1c2VkIGJ5IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIGFsZ29yaXRobSDigJMgc28g aXQgaXMgdGhlcmVmb3JlIGhhcmQgZm9yIG1lIHRvIHVzZS91bmRlcnN0YW5kIHRoaXMgcmVwcmVz ZW50YXRpb24NCiB3aGVuIGFwcGx5aW5nIHRoZSBkZWZpbmVkIHByZWZlcmVuY2UgcnVsZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhpcyBpcyB0cnVlIGZvciBtZSBldmVuIGFmdGVyIHJlYWRpbmcgeW91ciBl eHBsYW5hdGlvbnMgYmVsb3cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkJ1dCBpdCBpcyBmYXIgbW9yZSBpbXBvcnRhbnQgdG8gaGF2ZSBhIGNvbW1vbiB1bmRlcnN0YW5k aW5nIG9mIHRoZSBhbGdvcml0aG0gcHJvcG9zYWwgdGhhbiBpdCBpcyB0byBiZSBhcmd1aW5nIG92 ZXIgd2hvc2UgZW5jb2RpbmcgaXMg4oCcYmV0dGVy4oCdLiBJZiB0aGUgZW5jb2RpbmcgaW4gdGhl IGRyYWZ0IGlzIG5vdCBjbGVhciBvciBjb3VsZCB1c2UgaW1wcm92ZW1lbnQsDQogSSB3ZWxjb21l IHlvdXIgZmVlZGJhY2suIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMg ZmFyIGFzIHlvdXIg4oCccHNldWRvLWNvZGXigJ06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6I0MwMDAwMCI+LSBGaW5kIGFsbCBTSURpIGFk dmVydGlzZWQgZm9yIHRoZSBwcmVmaXggUDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gaWRlbnRpZmljYXRpb24gb2YgUHJl Zml4IGNvbmZsaWN0czxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAw MDAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEZvciBlYWNoIFNJRGkgZmlu ZCBhbGwgdGhlIHByZWZpeCBQaWogYXNzb2NpYXRlZCB3aXRoIFNJRGkmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Ly8gaWRlbnRpZmljYXRpb24gb2YgU0lEIGNvbmZsaWN0czxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPkdldCB0aGUgYmVzdCBhcyBwZXIgdGhlIHByZWZl cmVuY2UgYWxnb3JpdGhtLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiND MDAwMDAiPklmIGJlc3QgUGlqID09IFAxPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0i Y29sb3I6I0MwMDAwMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gdXNl IFNJRGlqIGZvciBQMTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAw MDAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbHNlIHJldHVybiBubyBTSUQ8 L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojQzAwMDAwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgZmFjdCB0aGF0IHlvdSBjYW4g cmVwcmVzZW50IGFuIGFsZ29yaXRobSBpbiBhIGZldyBsaW5lcyBkb2VzIG5vdCBtZWFuIHRoZSBp bXBsZW1lbnRhdGlvbiBvZiB0aGUgYWxnb3JpdGhtIGlzIGp1c3QgYXMgc2ltcGxlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5bQnJ1bm9dIFN1cmUuIEJ1dCBpZiB3ZSB3YW50IHRvIGNvbXBhcmUgaW1wbGVtZW50YXRpb24g Y29tcGxleGl0eSwgd2XigJlsbCBuZWVkIHRvIGFncmVlIG9uIGhvdyBtdWNoIHdlIHdhbnQgdG8g Z28gaW50byBkZXRhaWxzLCBpbiBvcmRlciB0byBoYXZlIG1lYW5pbmdmdWwgY29tcGFyaXNvbi4g U28gZmFyIHRoaXMgaXMgbm90IGNsZWFyIHRvIG1lIGFzIHlvdSBzb21ldGltZXMgYXJndWUgdGhh dCBkYXRhIHN0cnVjdHVyZQ0KIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCB5b3UgZG9u 4oCZdCB3YW50IHRvIGdvIGludG8gdGhpcyAod2hpY2ggSSBhZ3JlZSkgYW5kIHNvbWV0aW1lIHlv dSBkZXRhaWwgdGhlIGRhdGEgc3RydWN0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlcmUgaXMgYWxzbyB0aGUgb3B0aW9uIHRvIGNvbnNpZGVyIHRoaXMgYXMg4oCc aW1wbGVtZW50YXRpb24gaXNzdWXigJ0gYW5kIGxldCB0aGlzIHRvIGltcGxlbWVudGF0aW9ucy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29taW5nIGJhY2sgdG8gbXkgcGVyIEZFQyBhbGdvLCBh bGwgd2hhdCBpcyByZXF1aXJlZCBmcm9tIHRoZSBkYXRhIHN0cnVjdHVyZSwgaXMgYSB3YXkvQVBJ IHRvIGdldCB0aGUgZGF0YSBiYWNrLCB0aG91Z2ggMiBrZXlzOiBnZXQgbWUgdGhlIFNJRCBtYXRj aGluZyBwcmVmaXggUDEgKGZvciB0aGUgZmlyc3QgbGluZSksIGdldCBtZSB0aGUgcHJlZml4ZXMg bWF0Y2hpbmcgdGhlIFNJRCBTSURpIGZvciB0aGUgc2Vjb25kDQogbGluZS4gVGhhdCBzZWVtIGxp a2UgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50IG9uIHRoZSBkYXRhIHN0cnVjdHVyZSwgYW5kIGFu eSBvcHRpb24gaW4geW91ciBkcmFmdCBhbHNvIHJlcXVpcmVzIHRoaXMgdG8gZGV0ZWN0IHByZWZp eCBjb25mbGljdCBhbmQgU0lEIGNvbmZsaWN0IChzaW5jZSB0aGlzIGlzIGFsbCBteSBwZXIgRkVD IGFsZ28gaXMgZG9pbmcgaW4gdGhlc2UgMiBmaXJzdCBsaW5lcykuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkdvaW5nIGludG8gbW9yZSBkZXRhaWxzLCBteSBwZXIgRkVDIGFsZ28gb25seSByZXF1 aXJlcyB0byBkZXRhaWwgdGhhdCBvbmUgcHJlZml4IG9yIFNJRCBiZWxvbmcgdG8gYSByYW5nZSAo b2YgcHJlZml4IG9yIFNJRCkgd2hpbGUgeW91ciBwZXIgcmFuZ2UgYWxnbyByZXF1aXJlcyB0byBj b21wdXRlIHJhbmdlIGludGVyc2VjdGlvbiB3aGljaCBpcyBoYXJkZXIuIFNvIHRoZSBBUEkgdG8g ZmV0Y2ggdGhlIGRhdGENCiBjYW4gb25seSBiZSBlYXNpZXIuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bTGVzOl0gUmFuZ2UgaW50ZXJz ZWN0aW9uIGlzIGVhc3kgdG8gY29tcHV0ZSDigJMgdGhlIGFsZ29yaXRobSBpcyBwcmVzZW50IGlu IHRoZSBkcmFmdCBhdCB0aGUgZW5kIG9mICZuYnNwO1NlY3Rpb24gMy4xLjEuPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzgwNjRBMiI+W0JydW5vXSBJbiBvcmRlciB0byBoYXZlIGEgbWVhbmluZ2Z1bCBkaXNjdXNz aW9uLCB3ZSBuZWVkIHRvIGRlZmluZSB0aGUgbGV2ZWwgb2YgZGV0YWlscyB0aGF0IHdlIHdhbnQg dG8gdGFrZSBpbnRvIGFjY291bnQsIGJlY2F1c2UgeW914oCZcmUgbm90IHVzaW5nIHRoZSBzYW1l IG9uZSB0byBkaXNjdXNzIHlvdXIgYWxnbyBhbmQgbWluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4xKSBB cyBhIGZpcnN0IGxldmVsIG9mIGNvbXBhcmlzb24sIHVzaW5nIHRoZSBkZXNjcmlwdGlvbiBhdCB0 aGUgZW5kIG9mIHNlY3Rpb24gMy4xLjEgYXMgYSBtb2RlbCwgZm9yIHJhbmdlIHByZWZpeCBjb25m bGljdCB5b3VyIGFsZ28gaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllcg0KICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAxKShUMSA9 PSBUMikgJmFtcDsmYW1wOyAoQTEgPT0gQTIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyAyKVAxICZsdDs9IFAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll cg0KICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAzKVRoZSBwcmVm aXhlcyBhcmUgaW4gdGhlIHNhbWUgYWRkcmVzcyBmYW1pbHkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyAyKUwxID09IEwyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllcg0KICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAzKShQ MWUgJmd0Oz0gUDIpICZhbXA7JmFtcDsgKChTMSAmIzQzOyAoUDIgLSBQMSkpICE9IFMyKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojODA2NEEyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+U28gZm9yIChGRUMpIHByZWZpeCBjb25m bGljdCBteSBhbGdvIGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXINCiAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgMSkoVDEgPT0g VDIpICZhbXA7JmFtcDsgKEExID09IEEyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg MilQMSA9IFAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAg ICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAzKVRoZSBwcmVmaXhlcyBh cmUgaW4gdGhlIHNhbWUgYWRkcmVzcyBmYW1pbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyAyKUwxID09IEwyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4oQlRX LCBpbiB0aGUgZHJhZnQsIHRoZXJlIGlzIGEgdHlwbyBpbiB0aGUgbnVtYmVyaW5nKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODA2NEEyIj5JdCBsb29rcyBjbGVhciB0aGF0IEZFQyBjb21wYXJpc29uIGlzIGVhc2llciB0aGFu IHByZWZpeCByYW5nZSBpbnRlcnNlY3Rpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4MDY0QTIiPjIpIEdvaW5nIGRlZXBlciwgYXQgdGhlIGFsZ28gY29tcGxleGl0eTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODA2NEEyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+VGhlIEZFQyBhbGdvIG5lZWRzOiBnZXRfU0lE cyhQcmVmaXgpLCBhbmQgYWxsIHRoZSB3b3JrIGlzIGRvbmUuIFNvIGFsbCB0aGUgYWxnbyBjb21w bGV4aXR5IGlzIGNvbWluZyBmcm9tIHRoZSBkYXRhc3RydWN0dXJlLiBJdCBzZWVtcyBwcmV0dHkg cmVhc29uYWJsZSB0byBmaW5kIGEgZGF0YXN0cnVjdHVyZSAmbHQ7Jmx0OyBvKG4pIChlLmcuIGEg dHJlZSwgYnV0IHlvdSB3aWxsDQogYmUgbXVjaCBiZXR0ZXIgdGhhbiBtZSBpbiBmaW5kaW5nIG9u ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzgwNjRBMiI+Rm9yIHRoZSByYW5nZSBhbGdvLCBpdOKAmXMgbm90IGNsZWFyIHRv IG1lIHRoYXQgYSBkYXRhIHN0cnVjdHVyZSBjYW4gYmUgZm91bmQgdG8gYXV0b21hdGljYWxseSBm aW5kIHRoZSByZXN1bHQuIElmIG5vdCwgdGhlIGFsZ28gc2VlbXMgdG8gY29tcGFyZSBhbGwgZW50 cmllcyB0d28gYnkgdHdvLCB3aGljaCB3b3VsZCBnZXQgbyhuKihuLTEp4oCmKDIpKSBpLmUuIG8o biEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4MDY0QTIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Db25zaWRl ciB3aGF0IG5lZWRzIHRvIGJlIGRvbmUgdG8gaW1wbGVtZW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg4oCcRmluZCBhbGwgU0lEaSBhZHZlcnRpc2Vk IGZvciB0aGUgcHJlZml4IFAx4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5JbiBpdHMgc2ltcGxlc3QgZm9ybSwgd2UgaGF2ZSBhIGxpc3Qgb2YgYWxsIFNJRCBhZHZlcnRp c2VtZW50cyAoUEZYIGFuZCBTUk1TKSB0aGF0IHdlIGhhdmUgcmVjZWl2ZWQuIE9uZSBjb3VsZCBp bWFnaW5lIHdhbGtpbmcgYWxsIHRoZSBlbnRyaWVzLCBsb29raW5nIHRvIHNlZSBpZiB0aGUgcHJl Zml4IG9mIGludGVyZXN0IGlzIHByZXNlbnQgd2l0aGluIHRoZSBhZHZlcnRpc2VkDQogcmFuZ2Uu IEJ1dCwgb2YgY291cnNlLCBhdCBsYXJnZSBzY2FsZSBzdWNoIGFuIGFwcHJvYWNoIGlzIGV4dHJl bWVseSBpbmVmZmljaWVudCDigJMgc28gd2UgaW1tZWRpYXRlbHkgc3RhcnQgY29uc2lkZXJpbmcg d2F5cyB0byBpbXByb3ZlIHBlcmZvcm1hbmNlLiBJbnNlcnRpbmcgcmVjZWl2ZWQgZW50cmllcyBp bnRvIGFuIG9yZGVyZWQgdHJlZSBvZiBzb21lIGtpbmQgaXMgYW4gb2J2aW91cyB3YXkgdG8gaW1w cm92ZSBwZXJmb3JtYW5jZS4gV2hlbiBvbmUNCiBmdXJ0aGVyIGNvbnNpZGVycyB0aGF0IGNhbGN1 bGF0aW5nIGNvbmZsaWN0IHJlc29sdXRpb24gb25seSBuZWVkcyB0byBiZSBkb25lIHdoZW4gYSBj aGFuZ2UgdG8gdGhlIHJlY2VpdmVkIGRhdGFiYXNlIG9jY3VycyAod2hpY2ggcG9zdCBzdGFydHVw IGlzIGluZnJlcXVlbnQpIGl0IGJlY29tZXMgdmVyeSBhdHRyYWN0aXZlIHRvIGNhY2hlIHRoZSDi gJx3aW5uaW5nIGVudHJpZXPigJ0gc28gdGhhdCBpZiBvbmUgd2FudHMgdG8gcmV0cmlldmUgdGhl IFNJRA0KIGZvciBhIGdpdmVuIHByZWZpeCB3ZSBvbmx5IGhhdmUgdG8gZXhhbWluZSBhIHN1YnNl dCBvZiB0aGUgdG90YWwgZGF0YWJhc2Ug4oCTIGlnbm9yaW5nIHRoZSBsb3NlcnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JydW5vXSBJIGFncmVlIHRoYXQg dGhlIHBlciByYW5nZSBhbGdvIChpZ25vcmUgb3ZlcmxhcCBvbmx5KSB3aWxsIGJlIGFibGUgdG8g aWdub3JlIHRoZSBsb3NlcnMgYnV0IGF0IHRoZSBjb3N0IG9mIGEgbW9yZSBjb21wbGV4IGFsZ28g YW5kIGF0IHRoZSBjb3N0IG9mIGNyZWF0aW5nIG5ldyBkZXJpdmVkIGVudHJpZXMuIEl04oCZcyBu b3QgY2xlYXIgdG8gbWUgaWYgdGhlIG5ldCByZXN1bHQgaXMgcG9zaXRpdmUuDQogUGx1cyBJIHdv dWxkIGV4cGVjdCB0aGF0IHRoZSBudW1iZXIgb2YgY29uZmxpdCBpcyBzbWFsbCBjb21wYXJlZCB0 byB0aGUgbnVtYmVyIG9mIHByZWZpeCAvU0lEIHNvIHRoaXMgbG9va3MgbGlrZSBhIHNlY29uZCBv cmRlciBvcHRpbWl6YXRpb24uPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gdGhpcyBjb250ZXh0LCB3ZSBjYW4gYXBwcmVj aWF0ZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0aHJlZSBwcm9wb3NlZCBhbGdvcml0aG1z LiBJbiBwYXJ0aWN1bGFyIGNvbXBhcmluZyDigJxRdWFyYW50aW5l4oCdIHdpdGgg4oCcaWdub3Jl IG92ZXJsYXAgb25seeKAnSwgYSBrZXkgZGlmZmVyZW5jZSBpcyB0aGF0IOKAnFF1YXJhbnRpbmXi gJ0gb25seSBuZWVkcyB0byBkZXRlcm1pbmUNCiB3aGV0aGVyIGEgcmVjZWl2ZWQgZW50cnkgaXMg YSB3aW5uaW5nIGVudHJ5IG9yIGEgbG9zaW5nIGVudHJ5LiDigJxJZ25vcmUgb3ZlcmxhcCBvbmx5 4oCdIGhhcyB0byBiZSBjYXBhYmxlIG9mIGJyZWFraW5nIHJlY2VpdmVkIGVudHJpZXMgd2l0aCBy YW5nZXMgJmd0OyAxIGludG8gbXVsdGlwbGUg4oCcZGVyaXZlZOKAnSBlbnRyaWVzIChzb21lIHdp bm5pbmcsIHNvbWUgbG9zaW5nKSwgd2hpY2ggbWVhbnMgd2Ugbm93IG5lZWQgdG8gdHJhY2sgdGhl IOKAnGRlcml2ZWQgZW50cmllc+KAnQ0KIGFnYWluc3QgdGhlIG9yaWdpbmFsIHJlY2VpdmVkIGVu dHJ5IHNvIHRoYXQgaWYgdGhlIHJlY2VpdmVkIGVudHJ5IGlzIHVwZGF0ZWQvZGVsZXRlZCB3ZSBj YW4gZmluZCBhbGwgdGhlIGRlcml2ZWQgZW50cmllcyBhbmQgZGVsZXRlL3JlZ2VuZXJhdGUgdGhl IGRlcml2ZWQgZW50cmllcyBhcyBuZWVkZWQuIFRoaXMgaXMgd2hhdCBhZGRzIGNvbXBsZXhpdHku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JydW5vXSBhbmQg dGhhdCBpdCB3aHkgdGhlIHBlciBGRUMgYWxnbyBzZWVtcyBlYXNpZXIuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpdCB3b3VsZCBzZWVtIHVzZWZ1bCB0byBhZGQgaXQg aW4gdGhlIGRyYWZ0IHNvIHRoYXQgd2UgY2FuIGFsbCBkaXNjdXNzIGl0LjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PltMZXM6XSBJZ25vcmUgb3ZlcmxhcCBvbmx5IGlzIHRoZSBzYW1lIGFzIHBlciBGRUMuIFdlIG1h eSB1c2UgZGlmZmVyZW50IHdvcmRzIHRvIGRlc2NyaWJlIGl0LCBidXQgdGhlIGVuZCBiZWhhdmlv ciBpcyB0aGUgc2FtZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5bQnJ1bm9dIGdvb2QgaWYgdGhp cyBnZXQgdGhlIHNhbWUgcmVzdWx0LiBZZXQgdGhlIGFsZ28gaXMgZGlmZmVyZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODA2NEEyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+LS0gQnJ1bm88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+QWxsIHByb3Bvc2VkIGFsZ29yaXRobXMgY2FuIGJlIGltcGxlbWVudGVkLCBidXQg aXQgZG9lcyBzZWVtIHBydWRlbnQgdG8gY29uc2lkZXIgaW1wbGVtZW50YXRpb24gY29tcGxleGl0 eSBhcyBwYXJ0IG9mIG91ciBkZWNpc2lvbiBwcm9jZXNzIOKAkyBhbmQgdGhlIGRpc2N1c3Npb24v ZXhhbXBsZXMgaW4gU2VjdGlvbiAzIGFyZSBtZWFudCB0byBoZWxwIGluIGRvaW5nDQogdGhpcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IGlzIHdvcnRod2hpbGUgcmVz dGF0aW5nIHRoYXQgd2hlbiBjb25mbGljdHMgYXJlIHByZXNlbnQgd2UgY2Fubm90IGd1YXJhbnRl ZSB0aGF0IGZvcndhcmRpbmcgd2lsbCB3b3JrIGNvcnJlY3RseSBubyBtYXR0ZXIgd2hhdCBhbGdv cml0aG0gaXMgdXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5bQnJ1bm9dIEnigJltIG5vdCBzdXJlIHRvIHNlZSB3aGF0IHlvdSBoYXZlIGluIG1pbmQgZXhh Y3RseS4gQ2FuIHlvdSBlbGFib3JhdGU/IFRvIG1lIGNvbnNpc3RlbmN5IHNlZW0gZW5vdWdoLjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7VGhlIG1vcmUg Y29tcGxleCB0aGUgaW1wbGVtZW50YXRpb24gdGhlIG1vcmUgbGlrZWx5IGl0IGlzIHRoYXQgYnVn cyB3aWxsIGJlIHByZXNlbnQgYW5kIHRoZSBtb3JlIGxpa2VseSBpdCBpcyB0aGF0IGludGVyb3Bl cmFiaWxpdHkgaXNzdWVzIHdpbGwgYXJpc2UuIFdoZXRoZXIgdGhlc2UgY29zdHMvcmlza3MgYXJl IHdvcnRoIHRoZSDigJx2YWx1ZSBhZGTigJ0gd2hlbg0KIHRoZSBvdXRjb21lIGNhbm5vdCBiZSBn dWFyYW50ZWVkIHRvIGJlIGNvcnJlY3Qg4oCTIG9ubHkgZ3VhcmFudGVlZCB0byBiZSBjb25zaXN0 ZW50IOKAkyBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkFsc28gaW1wb3J0YW50IHRvIHJlbWVtYmVyIHRoYXQgY29uZmxp Y3RzIE1VU1QgYmUgZWxpbWluYXRlZCBieSBjb3JyZWN0aW5nIHRoZSBtaXNjb25maWd1cmF0aW9u cyB0aGF0IGNhdXNlZCB0aGVtIOKAkyBzbyBjb25mbGljdCByZXNvbHV0aW9uIGlzIHJlYWxseSBv bmx5IGFuIGludGVyaW0gbWVhc3VyZSB1bnRpbCB0aGUgY29ycmVjdGlvbnMgY2FuIGJlIG1hZGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JydW5vXSBCeSDi gJxpbnRlcmlt4oCdIHdlIGFyZSBhdCBtaW5pbXVtIHRhbGtpbmcgYWJvdXQgMTBzIG9mIG1pbnV0 ZXMsIGlmIG5vdCBtb3JlIHRoYW4gMSBob3VyIHNpbmNlIGlkZW50aWZ5aW5nIHRoZSByb290IGNh dXNlIG1heSBub3QgYmUgb2J2aW91cy4gVGhlIGltcGFjdCBpcyB2ZXJ5IHNpZ25pZmljYW50IG9u IHRoZSBuZXR3b3JrLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg 4oCcUXVhcmFudGluZeKAnSBhbGdvIGhhcyB0aGUgcG90ZW50aWFsIHRvIGtpbGwgMTAwcyBQRSBh bmQgMTAwMHMgb2YgVlBOIGN1c3RvbWVycywgc28gYSBzaW5nbGUgY29uZmlndXJhdGlvbiBjaGFu Z2Ugb24gYSB1bnJlbGF0ZWQgcm91dGVyIHdoaWNoIG1heSBub3QgZXZlbiBiZSBpbiBwcm9kdWN0 aW9uIChpLmUuIHdoZXJlIGNvbmZpZ3VyYXRpb24gY2hlY2tzIGFuZCBvcGVyYXRpb25zIGhvdXJz IG1heSBiZQ0KIHJlbGF4ZWQpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5ObyBvbmUgc2hvdWxkIGJlIGx1bGxlZCBpbnRvIHRoaW5raW5nIHRoYXQg YmVjYXVzZSB3ZSBoYXZlIGNvbmZsaWN0IHJlc29sdXRpb24gZGVwbG95ZWQgdGhhdCBjb3JyZWN0 aW5nIHRoZSBjb25maWd1cmF0aW9uIHdoZW4gY29uZmxpY3RzIGFyZSBkZXRlY3RlZCBpcyBub3Qg YSBwcmlvcml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b QnJ1bm9dIEkgY291bGQgbm90IGFncmVlIG1vcmUgdGhhdCBjb25mbGljdCBuZWVkcyB0byBiZSBp ZGVudGlmaWVkIGFuZCBmaXhlZC4gTm90ZSB0aGF0IEnigJltIHRoZSBvbmUgaGF2aW5nIGFza2Vk IGZvciBkZWZpbmluZyBZQU5HIG5vdGlmaWNhdGlvbnMgdG8gcmVwb3J0IHRoaXMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgYXJlIHdlbGNvbWVkIHRvIHN0YXRlIGlu IHRoZSBkcmFmdCB0aGF0IGNvbmZsaWN0cyBuZWVkcyB0byBiZSByZXBvcnRlZCB0byB0aGUgbmV0 d29yayBvcGVyYXRvciwgaW4gcGFydGljdWxhciB0aG91Z2ggeWFuZyBub3RpZmljYXRpb24sIGFu ZCBvdGhlciBleGlzdGluZyBtZWFucy4gUGx1cyB0aGF0IG5ldHdvcmsgb3BlcmF0b3IgbmVlZHMg dG8gZml4ZWQgdGhlbSBBU0FQIChidXQgc3RpbGwgY2FyZWZ1bGx5KTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tQnJ1 bm88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZQ0KICAgICAg ICAgICAgICAgICAgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGDQogICAgICAgICAg ICAgICAgICAgICAgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij48L3NwYW4+PHNwYW4g bGFuZz0iRlIiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBsYW5nPSJFTi1VUyI+YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4NCiBbPC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFo b21hLCBzYW5zLXNlcmlmOyIgbGFuZz0iRU4tVVMiPm1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFu Z2UuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVuZSAzMCwgMjAxNiA1OjEwIEFNPGJyPg0KPGI+VG86PC9iPiBMZXMgR2luc2Jlcmcg KGdpbnNiZXJnKTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBs YW5nPSJFTi1VUyI+c3ByaW5nQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlv biAtIFBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5MZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojODA2NEEyIj5UaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLiBQbGVhc2Ugc2VlIGlubGlu ZSBbQnJ1bm9dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlDQogICAgICAgICAgICAgICAgICAgIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERg0KICAgICAgICAgICAgICAgICAgICAgICAgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMt c2VyaWY7Ij4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29t Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5z LXNlcmlmOyIgbGFuZz0iRU4tVVMiPm1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb208L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21h LCBzYW5zLXNlcmlmOyI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVuZSAyOSwg MjAxNiA2OjAwIFBNPGJyPg0KPGI+VG86PC9iPiBERUNSQUVORSBCcnVubyBJTVQvT0xOPGJyPg0K PGI+Q2M6PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGxhbmc9IkVOLVVTIj5zcHJp bmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkJydW5vIOKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+QXMgdGhlIHRocmVhZCBiZWxvdyBkb2N1bWVudHMsIEkgc3RhdGVkIHRoYXQgSSBkaWQgbm90 IHVuZGVyc3RhbmQgeW91ciByZXByZXNlbnRhdGlvbiBhbmQgYXNrZWQgZm9yIGNsYXJpZmljYXRp b24g4oCTIHN1Z2dlc3RpbmcgdGhhdCB5b3UgdXNlIHRoZSBmb3JtYXQgZGVmaW5lZCBpbiB0aGUg ZHJhZnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91IHN0YXRlZCB0aGF0IHlvdSBjb3VsZCBub3QgZG8g dGhhdCBhbmQgd2Ugd2VyZSBhdCBhIHBvaW50IHdoZXJlIG5vIHByb2dyZXNzIGNvdWxkIGJlIG1h ZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub10gSSBjb3VsZCBfPGk+bm90PC9pPl8gdXNlIHlvdXIg Zm9ybWF0IHNpbmNlIHlvdXIgZm9ybWF0IGRpZCBub3QgaW5jbHVkZSB0aGUgaW5mb3JtYXRpb24g bmVlZC4gVGhpcyBpcyBub3QgYSB3aGltIGJ1dCBhIHRlY2huaWNhbCBpc3N1ZS4gU28gSSBhc2tl ZCB5b3UgdG8gc3RpbGwgY29uc2lkZXIgdGhlIG1lc3NhZ2UuIFJhdGhlciB0aGFuIHdhaXRpbmcN CiBmb3IgYSB0aW1lLW91dCwgdGhlcmUgd2FzIGEgd2F5IHRvIG1ha2UgcHJvZ3Jlc3MgYnkgYXNr aW5nIGNsYXJpZmljYXRpb24gcXVlc3Rpb25zIG9uIHRoZSBwb2ludHMgd2hpY2ggd2VyZSBub3Qg Y2xlYXIsIG9yIGF0IGxlYXN0IGV4cGxpY2l0bHkgcmVmdXNpbmcgdG8gY29uc2lkZXIgdGhlIGVt YWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0 QTIiPkkgYWxzbyBub3RlIHRoYXQgd2hhdCBib3RoZXJlZCB5b3UgaW4gbXkgcmVwcmVzZW50YXRp b24gd2FzIG15IGFkZGl0aW9uIG9mIHRoZSB0eXBlIG9mIGFkdmVydGlzZW1lbnQgKHByZWZpeCBv ciBNUykuIEJ1dCB5b3UgZmluYWxseSBoYXZlIGp1c3QgYWRkZWQgaW4gdGhlIGxhdGVzdCB2ZXJz aW9uIG9mIHRoZSBkcmFmdCDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNyYy0gUEZYIG9yIFNSTVPigJ08 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiAuIFNvIHRoZXJlIHdhcyBwcm9iYWJs eSBhIHdheSB0byBjb21tdW5pY2F0ZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODA2NEEyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+QmVzaWRlcyB0aGUg YWxnbyBkaWQgbm90IHVzZSBhbnkgc3BlY2lmaWNhdGlvbiByZXByZXNlbnRhdGlvbiwganVzdCBu YW1lcy4gU28gSeKAmWxsIGNvcHkvcGFzdGUgaXQgYmVsb3csIHBsZWFzZSBhc2sgY2xhcmlmaWNh dGlvbiBxdWVzdGlvbnMgZm9yIHRoZSBwYXJ0cyB3aGljaCBhcmUgbm90IGNsZWFyIGVub3VnaC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzgwNjRBMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPlRoZSBwcm9ibGVtIHRoYXQgd2Ug bmVlZCB0byBzb2x2ZSwgaXMgdG8gZmluZCB0aGUgU0lEIGZvciBhIHByZWZpeCAoUDEpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojODA2NEEyIj5UaGUgYWxnbyBjb3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+LSBGaW5kIGFsbCBT SURpIGFkdmVydGlzZWQgZm9yIHRoZSBwcmVmaXggUDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gaWRlbnRpZmljYXRpb24g b2YgUHJlZml4IGNvbmZsaWN0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLSBGb3IgZWFjaCBTSURpIGZpbmQgYWxsIHRoZSBwcmVmaXggUGlqIGFzc29j aWF0ZWQgd2l0aCBTSURpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIGlkZW50aWZpY2F0aW9uIG9m IFNJRCBjb25mbGljdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPi8vIGFz IGEgcmVzdWx0LCBmb3IgUDEsIHdlIGdldCBhIGxpc3Qgb2YgKFNJRGksIFBpaik8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izgw NjRBMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPkdldCB0aGUgYmVzdCAoU0lEaSwgUGlqKSBhcyBw ZXIgdGhlIHByZWZlcmVuY2UgYWxnb3JpdGhtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5JZiBiZXN0IFBpaiA9 PSBQMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhl biB1c2UgU0lEaWogZm9yIFAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBlbHNlIHJldHVybiBubyBTSUQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLyBubyBTSUQgYXZhaWxhYmxlIGZvciB0aGlzIHByZWZpeCBQMTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2 NEEyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5UbyBpbGx1c3RyYXRlIG15IGNvbmZ1c2lvbiwgb25lIG9mIHlvdXIgZXhh bXBsZXMgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBzdHls ZT0iY29sb3I6cmVkIj5Gb3IgUjIsIHRoZSBhbGdvIGV2YWx1YXRlcyBhIGNvbmZsaWN0IGJldHdl ZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IFIyIC0gU0lEMiAtIFIyIChNUywgTVMpPG86 cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgUjIg LSBTSUQxMiAtIFIxMiAocHJlZml4IFNJRCwgTVMpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFu IHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwO1IyIC0gU0lEMTIgLSBSMiZuYnNw OyAocHJlZml4IFNJRCwgcHJlZml4IFNJRCk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPk5vdywgd2hhdCBkb2VzIOKAnFIyIC0gU0lEMiAtIFIyIChNUywgTVMp4oCd IG1lYW4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+LSBNUy9wcmVmaXgg U0lEIGlzIHRoZSB0eXBlIG9mIGFkdmVydGlzZW1lbnQuIEluIHlvdXIgbmV3IHZlcnNpb24sIHlv dSBjYWxsIGl0IFNSTVMvUEZYLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4tIFNJRCBpcyB0aGUgU0lEIGZvdW5k IGluIHRoZSBNYXBwaW5nIEVudHJpZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4tIFJ4IGlzIHRoZSBsb29wYmFj ayAocHJlZml4KSBvciByb3V0ZXIgUng8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0 QTIiPlNvIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6I0MwNTA0RCI+UjI8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiAtIFNJRDIgLQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMDBCMDUwIj5SMiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPig8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDUwNEQiPk1TPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjojODA2NEEyIj4sDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1TPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4p4oCdIGlzIHRoZSBvdXRwb3V0IG9mIHRoZSBh bGdvIGRlc2NyaWJlZCBhYm92ZSBhbmQgbWVhbnM6IEZvciBwcmVmaXgNCjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6I0MwNTA0RCI+UjI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIi Piwgd2UgZm91bmQgYQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojQzA1MDREIj5NUyA8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPm1hcHBpbmcgZW50cmllcyBhZHZlcnRpc2lu ZyBTSUQyIGZvciB0aGlzIHByZWZpeCwgYW5kIHRoZW4gSSBmb3VuZCBhDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1TIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRB MiI+bWFwcGluZyBlbnRyaWVzIGFkdmVydGlzaW5nIHByZWZpeA0KPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj5SMiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPmZv ciBTSUQyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG9lcyBpdCBtZWFu Jm5ic3A7IOKAnE9uIFIyLCBTSUQyIGlzIGFzc2lnbmVkIHRvIHByZWZpeCBSMiBmcm9tIHR3byBk aWZmZXJlbnQgbWFwcGluZyBzZXJ2ZXIgZW50cmllcz/igJ0gSSByZWFsbHkgaGF2ZSBubyBpZGVh LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QW5kIHlvdSBjb25jbHVkZSB0 aGUgZXhhbXBsZSBieSBzYXlpbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+QmVzdCBvbmUgaXMgUjIgLSBTSUQxMiAtIFIyIChz bWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSxzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSk8bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyA9PSZn dDsgU0lEMTIgaXMgc2VsZWN0ZWQgZm9yIFIyLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkJ1dCBzaW5jZSB0aGVyZSBpcyBubyByZXByZXNlbnRhdGlvbiBvZiDigJxy YW5nZeKAnSBpbiB5b3VyIGV4YW1wbGVzIEkgcmVhbGx5IGhhdmUgbm8gaWRlYSBob3cgeW91IGNh bWUgdG8gdGhpcyBjb25jbHVzaW9uIC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+W0JydW5vXSBJIGFncmVlIHRo YXQgc2luY2UgdGhlIGFib3ZlIGFsZ28gdXNlZCAyIG1hcHBpbmcgZW50cmllcyB0byBwcm92aWRl cyB0aGUgKFNJRGksIFBpaiksIHRoZSBwcmVmZXJlbmNlIGFsZ28gKMKnMy4yLjQpIHdvdWxkIG5l ZWQgdG8gYmUgYWRhcHRlZC4gVGhhdCBiZWluZyBzYWlkLCB0aGlzIGlzIG5vdCBpbXBvcnRhbnQg Zm9yIHRoaXMgZGlzY3Vzc2lvbi4NCiBMZXTigJlzIGp1c3QgY29uc2lkZXJlZCB0aGF0IHRoZWly IGV4aXN0IGEgcHJlZmVyZW5jZSBhbGdvcml0aG0sIHdoaWNoIHRha2VzIGFzIGlucHV0IGEgbGlz dCBvZiAoU0lEaSwgUGlpaikgZm9yIFAxLCBhbmQgZ2l2ZXMgYXMgb3V0cG91dCB0aGUg4oCcYmVz dOKAnSBvbmUuIChkZWZpbml0aW9uIG9mIOKAnGJlc3TigJ0gaXMgbm90IHBlcnRpbmVudCk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4/ PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgcmVnYXJkcyDigJxwZXIg RkVDL1ByZWZpeOKAnSwgSSBiZWxpZXZlIHRoaXMgaXMgd2hhdCDigJxpZ25vcmUgb3ZlcmxhcCBv bmx54oCdIGRvZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub10gSW5kZWVkLCB0aGlzIGlzIG15IGV4 cGVjdGF0aW9uLiBCdXQgSSB3b3VsZCBuZWVkIHNvbWVvbmXigJlzIHJldmlldyB0byBjb25maXJt IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4MDY0QTIiPkJ1dCB0aGUgZGlmZmVyZW5jZSBpcyB0aGF0IHRoZSBwcm9w b3NlZCBhbGdvIGlzIHNpbXBsZSAoMiBsaW5lcyBvZiBwc2V1ZG8gY29kZSksIHdpdGggdmVyeSBt b2Rlc3QgcmVzcXVpcmVtZW50IGRhdGEgc3RydWN0dXJlIHVzZSB0byBzdG9yZSB0aGUgbWFwcGlu ZyBlbnRyaWVzLiBJbmRlZWQsIGFsbCBpdCBuZWVkcyBpcyBhIGZ1bmN0aW9uIHJldHVybmluZyB0 aGUNCiBsaXN0IG9mIG1hcHBpbmcgZW50cmllcyBhc3NvY2lhdGVkL21hdGNoaW5nIGEgZ2l2ZW4g cHJlZml4LiBBbmQgZnVuY3Rpb24gcmV0dXJuaW5nIHRoZSBsaXN0IG9mIG1hcHBpbmcgZW50cmll cyBhc3NvY2lhdGVkL21hdGNoaW5nIGEgZ2l2ZW4gU0lELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5JbiBwYXJ0 aWN1bGFyLCB0aGVyZSBpcyBubyBuZWVkIGZvciBzcGxpdHRpbmcgbWFwcGluZyBlbnRyaWVzIHdo aWNoIGlzIHRoZSBtYWluIGNvbXBsZXhpdHkgb2YgeW91ciBwcm9wb3NlZCDigJxQcmVmZXJlbmNl IGFsZ29yaXRobS9pZ25vcmUgb3ZlcmxhcCBvbmx54oCdLiAoYWNjb3JkaW5nIHRvIHlvdXIgb3du IHRleHQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODA2NEEyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+LS0gQnJ1bm88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsgTGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAgICAgICAgICAgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGDQogICAgICAgICAgICAgICAgICAgICAgICAgIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogVGFob21hLCBzYW5zLXNlcmlmOyI+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48YSBtb3otZG8t bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyIgbGFuZz0iRU4tVVMiPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBz YW5zLXNlcmlmOyI+DQogWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIiBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGxh bmc9IkVOLVVTIj5tYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNh bnMtc2VyaWY7Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2 IDc6MjIgQU08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpPGJyPg0KPGI+ Q2M6PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGxhbmc9IkVOLVVTIj5zcHJpbmdA aWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkxlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5r cyBmb3IgdGhlIHVwZGF0ZWQgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JSU5NLCB5b3UgaGF2ZSBub3QgYW5zd2VyZWQgbXkgYmVsb3cgZW1haWwvcHJvcG9zYWwu IEkgaGFkIHdhaXRlZCBmb3IgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBidXQgaXQgYWxz byBkb2VzIG5vdCB0b3VjaCB0aGlzIHN1YmplY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5TbywgY291bGQgeW91IHBsZWFzZSBjb25zaWRlciBhbmQgYW5zd2VyIG15IGNv bW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JbiBzaG9ydCwgaW4g YW4gaW1wbGVtZW50YXRpb24taW5kZXBlbmRlbnQgc2VudGVuY2U6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSdt IHdvbmRlcmluZyBpZiB3ZSBjb3VsZCBhZGRyZXNzIHRoZSBjb25mbGljdCBvbiBhIHBlciBGRUMv UHJlZml4IGJhc2lzIHJhdGhlciB0aGFuIG9uIGEgcGVyIElHUCBhZHZlcnRpc2VtZW50IChyYW5n ZSkgYmFzaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IElmIHNv LCB0aGlzIG1heSBhdm9pZCB0aGUgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBRdWFyYW50aW5lIHZz IGlnbm9yZSBwb2xpY3kuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnJ1bm88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUNCiAgICAgICAgICAgICAgICAg ICAgICAgIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+IHNwcmluZyBbPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0 bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGxhbmc9IkVOLVVTIj5tYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBsYW5nPSJF Ti1VUyI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij48 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTgsIDIwMTYgMTo1NyBQTTxicj4NCjxi PlRvOjwvYj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyIgbGFuZz0iRU4tVVMiPnNwcmluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7 Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNv bmZsaWN0LXJlc29sdXRpb24gLSBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5MZXMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBzZWUg aW5saW5lIFtCcnVub108bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAg ICAgICAgICAgICAgIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4gTGVz IEdpbnNiZXJnIChnaW5zYmVyZykgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgbGFu Zz0iRU4tVVMiPm1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlm OyI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDE1LCAyMDE2IDEyOjQxIEFNPGJy Pg0KPGI+VG86PC9iPiBERUNSQUVORSBCcnVubyBJTVQvT0xOOyA8L3NwYW4+PHNwYW4gbGFuZz0i RlIiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fu cy1zZXJpZjsiIGxhbmc9IkVOLVVTIj5zcHJpbmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGlj dC1yZXNvbHV0aW9uIC0gUG9saWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJydW5vIOKAkzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhbSBoYXZpbmcgZGlmZmljdWx0eSBwYXJz aW5nIHRoZSBleGFtcGxlcyB5b3UgcHJvdmlkZSBiZWxvdyBhcyB0aGV5IHNlZW0gdG8gaW5jb3Jw b3JhdGUgYWR2ZXJ0aXNlbWVudCBzb3VyY2UgaW50byB0aGUgZGVzY3JpcHRpb24gd2hlcmVhcyB0 aGUgZHJhZnQgZGVsaWJlcmF0ZWx5IG9taXRzIHNvdXJjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQnJ1bm9dIE15IHRleHQgZG9lcyBub3QgaW5jb3Jwb3Jh dGUgdGhlIHNvdXJjZSwgYnV0IHRoZSB0eXBlIG9mIHNvdXJjZSBJT1cgdGhlIHR5cGUgb2Ygc3Vi LVRMVi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U28gaXQgZG9lcyBub3QgbWF0dGVy IGlmIFIyIHNlbmRzIGFuIGFkdmVydGlzZW1lbnQgb3IgUjEyIHNlbmRzIGFkdmVydGlzZW1lbnQg b3IgYm90aCBvZiB0aGVtIGRvICh3aGljaCBjb3VsZCBoYXBwZW4gd2hlbiBhbiBhZHZlcnRpc2Vt ZW50IGlzIGxlYWtlZCkg4oCTIHdoYXQgbWF0dGVycyBpcyB3aGF0IHVuaXF1ZSBlbnRyaWVzIGFy ZSBpbiB0aGUgZGF0YWJhc2UNCiBpbmRlcGVuZGVudCBvZiBzb3VyY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JydW5vXSBJdCBtYXkgbm90IG1hdHRlciBm b3IgeW91ciBhbGdvcml0aG0gKHBlbmRpbmcgYW5vdGhlciB0aHJlYWQpLCBidXQgaXQgZG9lcyBm b3IgdGhlIG9uZSBJIHByb3Bvc2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JdCB3 b3VsZCBiZSBnb29kIGlmIHlvdSBjb3VsZCBwcmVzZW50IHlvdXIgZXhhbXBsZXMgdXNpbmcgdGhl IGZvcm1hdCBkZWZpbmVkIGluIHRoZSBkcmFmdCBpLmUuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCcnVub10gTXkgZXhhbXBsZXMgYXJlIGRlc2NyaWJlZCBp biBwbGFpbiB0ZXh0LiBUaGVuIHRoZSBleGFtcGxlcyBnaXZpbmcgaW50ZXJtZWRpYXRlIHN0ZXBz IG9mIG15IGFsZ28gdXNlcyB0aGUgZGF0YSB0aGF0IGFyZSBuZWVkZWQgaS5lLiB0aGUgdHlwZSBv ZiBhZHZlcnRpc2VtZW50IChQcmVmaXgtU0lEIHZzIE1TKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZW4gZmluYWxseSwgbXkgYWxnbyBydW5zIG9uIGEgcGVyIEZFQy9J UCBQcmVmaXggYmFzaXMsIGFuZCBub3Qgb24gYSBwZXIgSUdQIGFkdmVydGlzZW1lbnQgYmFzaXMg d2hpY2ggeW91ciBmb3JtYXQgZGVzY3JpYmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TbyBJ4oCZbSBzb3JyeSBidXQgSSBkb27igJl0IHNlZSBob3cgdG8gaW5kdWxnZSB5 b3VyIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgUGkgLSBJbml0aWFsIHByZWZpeDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBQZSAtIEVuZCBwcmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTCAtJm5ic3A7IFByZWZp eCBsZW5ndGg8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTHggLSBNYXhpbXVtIHByZWZpeCBsZW5ndGggKDMyIGZv ciBJUHY0LCAxMjggZm9yIElQdjYpPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNpIC0gSW5pdGlhbCBTSUQgdmFs dWU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU2UgLSBFbmQgU0lEIHZhbHVlPG86cD48L286cD48L3NwYW4+PC9p PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFIgLSZu YnNwOyBSYW5nZSB2YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUIC0gVG9wb2xvZ3k8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQSAtIEFsZ29yaXRobTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIE1hcHBpbmcgRW50cnkgaXMgdGhlbiB0aGUg dHVwbGU6IChQaS9MLCBTaSwgUiwgVCwgQSk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2k+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkZSIj5QZSA9IChQaSAmIzQzOyAoKFIt MSkgJmx0OyZsdDsgKEx4LUwpKTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2UgPSBTaSAmIzQz OyAoUi0xKTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxh bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5FeGFtcGxlOiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsoMTkyLjAuMi4xMjAvMzIsIDIw MCwgMSwgMCwgMCk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BcyBy ZWdhcmRzIHlvdXIgcHJvcG9zYWwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LSBGaW5kIGFsbCBTSURpIGFkdmVydGlzZWQg Zm9yIHRoZSBwcmVmaXggUDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gaWRlbnRpZmljYXRpb24gb2YgUHJlZml4IGNvbmZs aWN0czxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEZvciBlYWNoIFNJRGkgZmluZCBhbGwgdGhl IHByZWZpeCBQaWogYXNzb2NpYXRlZCB3aXRoIFNJRGkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ly8g aWRlbnRpZmljYXRpb24gb2YgU0lEIGNvbmZsaWN0czxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkdldCB0aGUgYmVzdCBhcyBwZXIgdGhlIHByZWZlcmVuY2UgYWxn b3JpdGhtLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklm IGJlc3QgUGlqID09IFAxPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gdXNlIFNJRGlqIGZv ciBQMTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbHNlIHJldHVybiBubyBTSUQ8L3NwYW4+PC9p PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+dGhpcyB0byBt ZSBzcGVjaWZpZXMgYW4gaW1wbGVtZW50YXRpb24g4oCTIHdoaWNoIGlzbuKAmXQgbmVjZXNzYXJ5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCcnVub10gV2Vs bCwgXzxpPnlvdTwvaT5fIGFyZSB0aGUgb25lIHRhbGtpbmcgYWJvdXQgaW1wbGVtZW50YXRpb24s IGFuZCBtb3JlIHNwZWNpZmljYWxseSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXNzdW1pbmcgdGhlIGFib3ZlIGFsZ28gd29y a3MsIGl0IGxvb2tzIHJlbGF0aXZlbHkgc2ltcGxlIHRvIGltcGxlbWVudCwgaW4gd2hpY2ggY2Fz ZSwgSSB3b3VsZCBub3QgYnV5IHRoZSBhcmd1bWVudCBhYm91dCBpbXBsZW1lbnRhdGlvbiBjb21w bGV4aXR5IHdoaWNoIGlzIHRoZSBvbmx5IGFyZ3VtZW50IGluIGZhdm9yIG9yIHRoZSDigJxpZ25v cmXigJ0gb3Ig4oCccXVhcmFudGluZeKAnSBwb2xpY3kuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Cb3R0b20gbGluZSwgSSB3b3VsZCB3ZWxjb21lIHlvdXIgZmVlZGJhY2sg YW5kIGNvbW1lbnRzIG9uIHRoaXMgcHJvcG9zZWQgYWxnby9wb2xpY3kuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBCcnVubzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SG93ZXZlciwg dGhlcmUgaXMgb25lIGltcG9ydGFudCBwb2ludCB3aGljaCBoYXMgbm90IGJlZW4gc3BlY2lmaWVk IGluIHRoZSBkcmFmdCB3aGljaCByZWFkaW5nIHlvdXIgcG9zdCBoYXMgYnJvdWdodCB0byBteSBh dHRlbnRpb24g4oCTIHRoYXQgaXMgdGhlIG9yZGVyIGluIHdoaWNoIGNoZWNrcyBhcmUgbWFkZS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgc3RhdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+4oCcUHJlZml4IGNvbmZsaWN0cyBhcmUgc3BlY2lmaWMgdG8gbWFwcGlu ZyBlbnRyaWVzIHNoYXJpbmcmbmJzcDsgdGhlIHNhbWUgdG9wb2xvZ3kgYW5kIGFsZ29yaXRobS7i gJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+4oCcU0lEIGNvbmZsaWN0cyBhcmUgaW5kZXBlbmRlbnQgb2YgYWRk cmVzcy1mYW1pbHksJm5ic3A7IGluZGVwZW5kZW50IG9mIHByZWZpeCBsZW4sIGluZGVwZW5kZW50 IG9mIHRvcG9sb2d5LCBhbmQgaW5kZXBlbmRlbnQmbmJzcDsgb2YgYWxnb3JpdGhtLuKAnTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgd2UgY29uc2lkZXIgYW4gZXhhbXBs ZSB3aGVyZSBhIG5ldHdvcmsgc3VwcG9ydHMgdHdvIFZQTnMsIHRoZSBzaWduaWZpY2FuY2Ugb2Yg b3JkZXJpbmcgaW4gdGhlIGV2YWx1YXRpb24gb2YgY29uZmxpY3RzIHdpbGwgYmUgaGlnaGxpZ2h0 ZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5WUE4xOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4oMTkyLjAuMi4xLzMyLCAxMDAsIDEsIDEsIDApPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPigxOTIuMC4y LjEvMzIsIDIwMCwgMSwgMSwgMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5WUE4yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+KDE5Mi4wLjIuMTAwLzMyLCAyMDAsIDEsIDIsIDApPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JZiB3ZSBldmFsdWF0ZSBwcmVmaXggY29uZmxpY3RzIGZpcnN0 LCB0aGVuIHRoZSBmb2xsb3dpbmcgZW50cmllcyBhcmUg4oCcYWN0aXZl4oCdOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4oMTkyLjAuMi4xLzMyLCAxMDAsIDEsIDEsIDApICFWUE4xPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPigx OTIuMC4yLjEwMC8zMiwgMjAwLCAxLCAyLCAwKSAhVlBOMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SWYgd2UgZXZhbHVhdGUgU0lEIGNvbmZsaWN0cyBmaXJzdCwgdGhlbiB0 aGUgZm9sbG93aW5nIGVudHJpZXMgYXJlIOKAnGFjdGl2ZeKAnTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+KDE5 Mi4wLjIuMS8zMiwgMTAwLCAxLCAxLCAwKSAhVlBOMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhlIGxhdHRlciBjaG9pY2UgaXMgc3Vib3B0aW1hbCBiZWNhdXNlIGl0IHBy ZXZlbnRzIHVzZSBvZiB0aGUgVlBOMiBlbnRyeSB1bm5lY2Vzc2FyaWx5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBwb2ludCBuZWVkcyB0byBiZSBtYWRlIGV4cGxp Y2l0IGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwg c2Fucy1zZXJpZjsiPiBzcHJpbmcgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7 IiBsYW5nPSJFTi1VUyI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwg c2Fucy1zZXJpZjsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFo b21hLCBzYW5zLXNlcmlmOyIgbGFuZz0iRU4tVVMiPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208 L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogVGFob21hLCBzYW5zLXNlcmlmOyI+PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkg MTIsIDIwMTYgODoyMyBBTTxicj4NCjxiPlRvOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48 YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7IiBsYW5nPSJFTi1VUyI+c3ByaW5nQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsi Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGlj dC1yZXNvbHV0aW9uIC0gUG9saWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgYXV0aG9ycywgYWxsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGFu IGluZGl2aWR1YWwgY29udHJpYnV0b3IsIHBsZWFzZSBmaW5kIGJlbG93IHNvbWUgZmVlZGJhY2sg b24gdGhlIHBvbGljeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHdvbmRlcmluZyBpZiB3 ZSBjb3VsZCBhZGRyZXNzIHRoZSBjb25mbGljdCBvbiBhIHBlciBGRUMvUHJlZml4IGJhc2lzIHJh dGhlciB0aGFuIG9uIGEgcGVyIElHUCBhZHZlcnRpc2VtZW50IGJhc2lzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc28sIHRoaXMgbWF5IGF2b2lkIHRoZSBkaXNjdXNz aW9uIGJldHdlZW4gdGhlIFF1YXJhbnRpbmUgdnMgaWdub3JlIHBvbGljeS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0gdGhhdCB3ZSBuZWVkIHRvIHNvbHZlLCBpcyB0byBmaW5k IHRoZSBTSUQgZm9yIGEgcHJlZml4IChQMSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgYWxnbyBjb3VsZCBiZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0gRmluZCBhbGwgU0lEaSBhZHZlcnRpc2VkIGZvciB0aGUgcHJlZml4IFAxJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC8vIGlkZW50aWZpY2F0aW9uIG9mIFByZWZpeCBjb25mbGljdHM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEZv ciBlYWNoIFNJRGkgZmluZCBhbGwgdGhlIHByZWZpeCBQaWogYXNzb2NpYXRlZCB3aXRoIFNJRGkm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gaWRlbnRpZmljYXRpb24gb2YgU0lEIGNvbmZsaWN0czxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vLyBhcyBhIHJlc3VsdCwgd2UgZ2V0IGEgbGlzdCBvZiBT SURpIOKAkyBQaWogZm9yIFAxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdldCB0aGUgYmVzdCBh cyBwZXIgdGhlIHByZWZlcmVuY2UgYWxnb3JpdGhtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgYmVzdCBQaWogPT0gUDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVuIHVzZSBTSURp aiBmb3IgUDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbHNlIHJldHVybiBubyBTSUQmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLyBubyBTSUQgYXZhaWxhYmxlIGZvciB0aGlzIHByZWZpeCBQ MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgTm90 ZSB0aGF0IGl0IHdvdWxkIHByb2JhYmx5IGJlIGJldHRlciBmb3IgdGhlIHByZWZlcmVuY2UgYWxn byB0byBwdXQgdGhlIFNJRCB0aWUtYnJha2UgYmVmb3JlIHRoZSBwcmVmaXggdGllLWJyZWFrIGFz IHdpdGggdGhlIHByZWZpeCB0aWUtYnJlYWssIHdlIHN1ZmZlciBmcm9tIHRoZSBjb25mbGljdCB0 d2ljZSAoUHJlZml4IC0gU0lEIG1hcHBpbmcsIHRoZW4gU0lELSBwcmVmaXggbWFwcGluZykgd2hp Y2gNCiBpbmNyZWFzZSB0aGUgZGl2ZXJzaXR5IGFuZCBoZW5jZSB0aGUgY2hhbmNlIG9mIG5vdCBm aW5kaW5nIGEgdmFsaWQgZW50cnkuJm5ic3A7Jm5ic3A7IEJ1dCBmb3IgdGhlIGJlbG93IGV4YW1w bGVzLCBJIHVzZWQgdGhlIHByZWZlcmVuY2UgYWxnbyBmcm9tIGRyYWZ0LWlldGYtKi0wMDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWxvdyBhcmUgZXhhbXBsZXMsIHJ1 bm5pbmcgdGhpcyBwb2xpY3kgb24gdHlwaWNhbCBjb25maWd1cmF0aW9uIGVycm9yIGNhc2VzLiZu YnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5F eGFtcGxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My40LjQuJm5ic3A7 IE5ldHdvcmsgb3BlcmF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBD b25zaWRlciB0aGUgZm9sbG93aW5nIHNpbXBsZSBuZXR3b3JrIGV4YW1wbGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAxLiZuYnNwOyAxMDAgbm9kZXM6IFIxIHRvIFIxMDA7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAyLiZuYnNwOyBJUCBMb29wYmFj a3MgYXJlIGZyb20gMTkyLjAuMi4xIHRvIDE5Mi4wLjIuMTAwOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgMy4mbmJzcDsgU0lEIGFyZSBmcm9tIDEgdG8gMTAwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgNC4mbmJzcDsgUjEgdG8gUjUwIGFyZSBTUiBj YXBhYmxlIGFuZCBhZHZlcnRpc2VkIHRoZWlyIG93biBTSUQgdXNpbmc8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBQcmVmaXgtU0lEIHN1Yi1UTFY7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyA1LiZuYnNwOyBSNTEgdG8gUjEwMCBhcmUgU1Igbm9uLWNhcGFibGUsIHJ1bm5pbmcgTERQIGFu ZCB0aGVpciBTSUQgYXJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7YWR2ZXJ0aXNlZCBieSB0d28gcmVkdW5k YW50IE1hcHBpbmcgU2VydmVyIE1TMSBhbmQgTVMyOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsgNi4mbmJzcDsgQXMgdGhlIG51bWJlciBvZiBub2RlcyB3aGljaCBhcmUgU1Ig Y2FwYWJsZSBhcmUgZXhwZWN0ZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmNyZWFzZSBhbmQgYXMg aW4gcmVhbCBkZXBsb3ltZW50IHRoZWlyIExvb3BiYWNrIGFkZHJlc3NlcyB3b3VsZDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG5vIHRoZSBjb250aWd1b3VzLCB0aGUgTWFwcGluZyBzZXJ2ZXJzIGFkdmVydGlz ZW1lbnQgY292ZXJzIGFsbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExvb3BiYWNrczogKDE5Mi4wLjIuMS8z MiwgMSwgMTAwKTs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFN1YnNlcXVl bnQgc2VjdGlvbnMgZXZhbHVhdGUgdGhlIGNvbnNlcXVlbmNlcyBvZiBhIHNpbmdsZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24g ZXJyb3IsIGZvciBhbGwgY29uZmxpY3QgcmVzb2x1dGlvbiBvcHRpb25zLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4zLjQuNC4xLiZuYnNwOyBFeGFtcGxlIDE6IFNJRCBjb25maWd1cmVkIG9uIDEg bm9kZSBjb25mbGljdCB3aXRoIFNJRDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbmZpZ3VyZWQgb24gYW5vdGhlciBub2RlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBGb2xsb3dpbmcgYSB0eXBvIGR1cmluZyBjb25maWd1cmF0aW9uLCBSMiBpcyBjb25m aWd1cmVkIHdpdGggYSBTSUQgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyAxMi4mbmJzcDsgVGhhdCBTSUQgY29uZmxpY3RzIHdpdGggdGhlIFByZWZp eC1TSUQgYWR2ZXJ0aXNlZCBieSBSMTIgYW5kIHRoZSBNYXBwaW5nIFNlcnZlciBBZHZlcnRpc2Vt ZW50IGZvciBSMTIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgTm90ZTogYm90aCBNUyBhZHZlcnRpc2VtZW50IGFyZSB0aGUgc2FtZSwgc28gd2Ugb25s eSBjb25zaWRlciBvbmUgaW4gdGhlIGJlbG93IGFuYWx5c2lzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QWxsIHByZWZpeCBidXQgUjIgYW5kIFIxMiwg YSBzaW5nbGUgU0lEIGlzIGFkdmVydGlzZWQgYW5kIGhlbmNlIHNlbGVjdGVkLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIFIyLCB0aGUgYWxnbyBl dmFsdWF0ZXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgYWR2ZXJ0aXNtZW50czo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSMiAtIFNJ RDIgLSBSMiAoTVMsIE1TKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7IFIyIC0gU0lEMTIgLSBSMTIgKHByZWZpeCBTSUQsIE1TKSA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO1IyIC0gU0lEMTIgLSBS MiZuYnNwOyAocHJlZml4IFNJRCwgcHJlZml4IFNJRCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QmVzdCBvbmUgaXMgUjIgLSBTSUQxMiAtIFIyIChzbWFs bGVyIHJhbmdlIChwcmVmaXggU0lEKSxzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyA9PSZndDsgU0lEMTIg aXMgc2VsZWN0ZWQgZm9yIFIyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Rm9yIFIxMiwgdGhlIGFsZ28gZXZhbHVhdGVzIGEgY29uZmxpY3QgYmV0d2Vl biB0aGUgZm9sbG93aW5nIGFkdmVydGlzbWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgUjEyIC0gU0lEMTIgLSBSMTIgKHByZWZpeCBTSUQsIHBy ZWZpeCBTSUQpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsgUjEyIC0gU0lEMTIgLSBSMiZuYnNwOyAocHJlZml4IFNJRCwgcHJlZml4IFNJRCk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSMTIgLSBTSUQxMiAt IFIxMiAocHJlZml4IFNJRCwgTVMpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgUjEyIC0gU0lEMTIgLSBSMiZuYnNwOyAoTVMsIHByZWZpeCBTSUQpPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgUjEyIC0gU0lE MTIgLSBSMTIgKE1TLCBNUyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwO0Jlc3Qgb25lIGlzIFIxMiAtIFNJRDEyIC0gUjIgKHNtYWxsZXIgcmFuZ2UgKHBy ZWZpeCBTSUQpLHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpLCBzbWFsbGVyIHN0YXJ0aW5nIGFk cmVzc2UgKFIyKSkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7UjEyICZsdDsmZ3Q7IFIyID09Jmd0OyBSMTIgaGFzIG5vIFNJRC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOzMuNC40LjIuJm5ic3A7 IEV4YW1wbGUgMjogU0lEIGNvbmZpZ3VyZWQgb24gMSBub2RlIGNvbmZsaWN0IHdpdGggU0lEPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZmlndXJlZCBvbiB0aGUgTWFwcGlu ZyBTZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEZvbGxvd2luZyBh IHR5cG8gZHVyaW5nIGNvbmZpZ3VyYXRpb24sIFIyIGlzIGNvbmZpZ3VyZWQgd2l0aCBhIFNJRCBv ZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDUyLiZu YnNwOyBUaGF0IFNJRCBjb25mbGljdHMgd2l0aCB0aGUgTWFwcGluZyBTZXJ2ZXIgYWR2ZXJ0aXNl bWVudHMgb2YgTVMxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgYW5kIE1TMiBmb3IgdGhlIGxvb3BiYWNrIG9mIFI1Mi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBOb3RlOiBib3RoIE1TIGFkdmVydGlzZW1l bnQgYXJlIHRoZSBzYW1lLCBzbyB3ZSBvbmx5IGNvbnNpZGVyIG9uZSBpbiB0aGUgYmVsb3cgYW5h bHlzaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtB bGwgcHJlZml4IGJ1dCBSMiBhbmQgUjUyLCBhIHNpbmdsZSBTSUQgaXMgYWR2ZXJ0aXNlZCBhbmQg aGVuY2Ugc2VsZWN0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDtGb3IgUjIsIHRoZSBhbGdvIGV2YWx1YXRlcyBhIGNvbmZsaWN0IGJldHdlZW4gdGhl IGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IFIyIC0gU0lENTIgLSBSMiZuYnNwOyAocHJlZml4IFNJRCwgcHJl Zml4IFNJRCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyBSMiAtIFNJRDUyIC0gUjUyIChwcmVmaXggU0lELCBNUyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSMiAtIFNJRDImbmJzcDsgLSBSMiZuYnNwOyAo TVMsIE1TKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 QmVzdCBvbmUgaXMgUjIgLSBTSUQ1MiAtIFIyIChzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSxz bWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyA9PSZndDsgU0lENTIgaXMgc2VsZWN0ZWQgZm9yIFIyLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIFI1MiwgdGhl IGFsZ28gZXZhbHVhdGVzIGEgY29uZmxpY3QgYmV0d2VlbiB0aGUgZm9sbG93aW5nIGFkdmVydGlz bWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg UjUyIC0gU0lENTIgLSBSNTIgKE1TLCBNUyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyBSNTIgLSBTSUQ1MiAtIFIyJm5ic3A7IChNUywgcHJlZml4IFNJ RCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO0Jlc3Qg b25lIGlzIFI1MiAtIFNJRDUyIC0gUjIgKHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFI1MiAmbHQ7Jmd0 OyBSMiA9PSZndDsgUjUyIGhhcyBubyBTSUQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMuNC40LjMuJm5ic3A7IEV4YW1wbGUgMzogd3JvbmcgY29uZmlndXJhdGlvbiBvZiBhIE1TPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBGb2xsb3dpbmcgYSB0eXBvIGR1cmlu ZyBjb25maWd1cmF0aW9uLCBNUzEgaXMgY29uZmlndXJlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICgxOTIuMC4yLjAvMzIsIDEsIDEwMCkuIChpLmUu IDE5Mi4wLjIuMCBpbnN0ZWFkIG9mIDE5Mi4wLjIuMSkuJm5ic3A7IFRoYXQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBhZHZlcnRpc2VtZW50IGNvbmZs aWN0cyB3aXRoIHRoZSBNYXBwaW5nIFNlcnZlciBhZHZlcnRpc2VtZW50cyBvZiBNUzI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBhbmQgdGhlIFByZWZp eC1TSUQgYWR2ZXJ0aXNlZCBieSBSMS4uLlI1MC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwO1dlIGhhdmUgYSBjb25mbGljdCBmb3IgYWxsIHJvdXRlcnMg ZXhjZXB0IFIxMDAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsm bmJzcDtGb3IgTERQIG9ubHkgcm91dGVycyBSNTEgdG8gUjk5IHdlIGhhdmUgYSBjb25mbGljdCBi ZXR3ZWVuIGJvdGggTVMgYWR2ZXJ0aXNlbWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBGb3IgUjUyLCB0aGUgYWxnbyBldmFsdWF0ZXMgYSBjb25m bGljdCBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgYWR2ZXJ0aXNtZW50czo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSNTIgLSBTSUQ1MiAtIFI1MiAoTVMy LCBNUzIpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg UjUyIC0gU0lENTIgLSBSNTEgKE1TMiwgTVMxKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFI1MiAtIFNJRDUzIC0gUjUyIChNUzEsIE1TMSk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSNTIgLSBTSUQ1MyAt IFI1MyAoTVMxLCBNUzIpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBCZXN0 IG9uZSBpcyBSNTIgLSBTSUQ1MiAtIFI1MSAoc21hbGxlciBzdGFydGluZyBhZGRyZXNzKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFI1MiAmbHQ7Jmd0 OyBSNTEgPT0mZ3Q7IFI1MiBoYXMgbm8gU0lELjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIFNSIHJvdXRlcnMsIFIxIHRvIDUwLCB3ZSBoYXZlIGEg Y29uZmxpY3QgYmV0d2VlbiBib3RoIE1TIGFkdmVydGlzZW1lbnQgYW5kIFByZWZpeCBTSUQgYWR2 ZXJ0aXNlbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgRm9yIFIyLCB0aGUgYWxnbyBldmFsdWF0ZXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSBm b2xsb3dpbmcgYWR2ZXJ0aXNtZW50czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyBSMiAtIFNJRCAyIC0gUjIgKFByZWZpeCBTSUQsIFByZWZpeCBTSUQp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgUjIgLSBT SUQgMiAtIFIyIChQcmVmaXggU0lELCBNUzIpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsgUjIgLSBTSUQgMiAtIFIxIChQcmVmaXggU0lELCBNUzEpPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgUjIgLSBTSUQg MiAtIFIyIChNUzIsIE1TMik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBSMiAtIFNJRCAyIC0gUjIgKE1TMiwgUHJlZml4IFNJRCk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSMiAtIFNJRCAyIC0gUjEgKE1T MiwgTVMxKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IFIyIC0gU0lEIDMgLSBSMiZuYnNwOyAoTVMxLCBNUzEpPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgUjIgLSBTSUQgMyAtIFIzJm5ic3A7IChNUzEsIE1T Mik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSMiAt IFNJRCAzIC0gUjMmbmJzcDsgKE1TMSwgUHJlZml4IFNJRCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO0Jlc3Qgb25lIGlzIFIyIC0gU0lEIDIgLSBSMiAo UHJlZml4IFNJRCwgUHJlZml4IFNJRCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyBSMiA9PSBSMiBoZW5jZSBSMiB1c2UgU0lEMi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPkJydW5vPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiIGxhbmc9IkZSIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7IiBsYW5nPSJGUiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7IiBsYW5nPSJGUiI+Q2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7IiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiIGxhbmc9IkZSIj5hIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyIgbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4N CjwvZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyIgbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyIgbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7IiBsYW5nPSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+TWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyIgbGFuZz0iRlIi PlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyIgbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi IGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyIg bGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7IiBs YW5nPSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TWVy Y2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyIgbGFuZz0iRlIiPlRoYW5rIHlvdS48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g PC9zcGFuPk1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48 L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkZSIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+ T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIDwvc3Bhbj5NZXJjaS48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJyPg0KPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNl dD4gPGJyPg0KPHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5r LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5v cmc8L2E+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+PGJyPg0K PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8B2C3147ACB43B08CF510588BE66062nokiacom_-- From nobody Sun Jul 24 05:39:50 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DAD12D134; Sun, 24 Jul 2016 05:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kgghba2rjlt; Sun, 24 Jul 2016 05:39:41 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0126.outbound.protection.outlook.com [104.47.37.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C56012D105; Sun, 24 Jul 2016 05:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NbQj9yUzBEIr7K4t2ytpgGQSDTSsgpMHdvh1s94vpyM=; b=V/RoOEkNj3dUztxgwhaFJ6j1V8edIxeQgSZfv06BLhc2W5OWKU4CxurC8nQPxwBNr1paE9BL+u+dh4CuADWWTsJZvCSJOHXRavC3viV3XmM7f3BnSh0s3dcc3nuM68jXODqBy6Y415Pe+ONqQwTvp7muV1iuTp7ksaqP2mObqII= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:39:37 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2016 14:39:26 +0200 Message-ID: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: AM2PR07CA0025.eurprd07.prod.outlook.com (10.163.24.163) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) X-MS-Office365-Filtering-Correlation-Id: ef92708c-b401-40f5-4bcf-08d3b3bf93b2 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 2:jgZNOUZq/xgmnY0XnqFbMP7onLgYHyKvdiBHpYF5loaMMHKyJRcFfg+2YFGcap7nGjC4kAqjlVmwvUMWl2mLX6igFha96HDFcelUcGhlQPZoKPUFFbuAPPgeZX7jD+XiXt3hXB1/P5I553jnxTmRQMMFkxsy3uOxQz+IVUT9KqC5LMKFvQOZWsRZutFA1Co9; 3:jd+lqTa6tMI9M0+KsHk9nwiSyPQQaADRQi3UhKb5c5YUzFUJNJwnvu0NONEFlbuSgIBGrEpjtx31gXbH6/gKPzoKumIACF5VuBRn2RaS6bKRYRQH75mefrCRUfXhWpVy; 25:4s2eA7UNkouAI0uiNs+CNfY9tfpgAlSTKo3cLEP6VanLW1MXHvZX6eghZ7GkOYLYC8huNBNKiR66ocxbYOayHXpRwdVtZ4KA5vQP026+H3T6Dw+7wp0BIkFW+5SL/Jm+ZtJGPtms4B0H7+sDhnYvdaD6ES1Xqh44LUir3BmnHCUhvUgan6W5gHpY/85mi+7JmABsuRSGUvK7mMyLwgnGvX3jeATm408slg7cjP81mSKrfYK+qbYQZiGqf39Y9Zqz/JinZt8i7E/2R5017XyiI3RzJKHnZeF4RC89sufuSPMXRRWv9AA4SITUWjnqKdtAlCLRZJ667eqm2wqH5YkTAi3fVjOolNOqAzXQTgGimwWsB3sZZIf+VUqAI8okWted8fnzBFivmrgsKD1y+DKZzzOmyvJKVotIXqBg+r8NeaU=; 31:qXUsVStRbibkyBX8PbXe6igr5bHn/4vd3u21YvKOWHPHG6ubi93bQ/JfoJw7WlYd2ydXFserYe3TfbthOnVIWTrPYXZ7AzjTQh29qnNB8WGOJTiH0fV4Ev4elrKEWvEOVcGJRpPBu3ufRpP7dLefTnUKpU1MFmSU3EbcedZZ9sSQAgGHhKk7cYWhkz6ibrm+6y/DabkqykN/EgqcwPc0wQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 20:czuyhd4D6WlbCsIb0ctPv0zXvG9VjdwoTFqtbBWBYVVuYYR5IcT9+fGMBGbP+oMh1uNC64q+dnYIg0BsZahmRzdm9w1FXv7sdeW05vLXW35AZXo534K/JmfGQBFHszwO7K5L9wgrsSfJ9dRgtFbd2Xea2T5UTpQiZ/1rkUNehTuZocq2n8YOJNRzIvRoscZSisBi5ArEMzQw8WH19IeVy4yGSRyzrBebIhpoRVe4x7WcP19R5oXp+GM2tkoyAF84ORXe1Iq8TQwfRHpT0EezNBJwxRK3uQ5ghnJNnQ7hL9W1PaWg5XFzH3Sdscae3UJIVlgdfwrgNqdaK6sLNiFVwLvuEnDC6Ia+Z8fIxNczl90N962+hQkQJfelfHLt7cQmQbQoy7KzjGjpXh36wY3vstokQ32SL1GccEJCgyR6IZeQbsiW3scQa5/v7oR74Bpzqhewn8AvWoaBhlE6Wa/4/BeIVBeFFELAGeVIW1v8L/pzRFsI91lIw2xVx7mDtBjf; 4:RMwFWFnFD7DRsDA8xp7qEmiY9OC+zVmR7gY5mFyfXDlveNNxFMN7qJ4udhCB51Yx0nH0A2qI5wbdDV9ThFBIo6bKsIuGfjJkbFAc4+B1qfXD6tlKhjlQFwksADCJlh8l6RDDQZyGvSL3VkRyrMeW/Iq++rYUEh2oB01BDnxABFQ++zlR/GUohZBpWr9+mlw01SoTg0cUBxfDlBS3ODb14xaTzqEoZXS4b+FR+GSPKqSNMPMktkfFsBS1fVJ6gbZacPUlgjJl73IpC1Kq/5PrH51jwwtE45pY9Gk5l5MDwILzg7S4sgWgivKob5QMO0FSiVteyA5PIaVSq6ALOg93kSfStqUrawwo6CYrIksgk6ZWv/57UU9LJL0p09fOPkSR2D30+9qHKv30mgk1wBtTLw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(105586002)(6116002)(50466002)(50226002)(2906002)(97736004)(68736007)(36756003)(46406003)(77096005)(586003)(92566002)(3846002)(86362001)(8676002)(23726003)(66066001)(4326007)(81166006)(50986999)(229853001)(81156014)(230783001)(7846002)(83716003)(101416001)(305945005)(42186005)(82746002)(189998001)(7736002)(8746002)(97756001)(57306001)(47776003)(106356001)(2351001)(110136002)(33656002)(450100001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2508; 23:6nkpULlgKS7XKC0F549Qj6yKizOF53uk31uWobhaH?= =?us-ascii?Q?1zGH3lwdwoWIgLh1P7NnqhZ7DJdXRcZcxdvBSCX9+G/Vb34pCI+8Id120pxb?= =?us-ascii?Q?ybaigWiWVJ8bYsK1TWkBARHtCyb+HDKY5TMXBfDNSal+Noz3pMFGVSiAvKsZ?= =?us-ascii?Q?Z9ZWOqGIqW05CG1tOtdpYf5z3xwX6SNIPyTkGQHdqIwzNgkEDC3iEgdRs2Dn?= =?us-ascii?Q?MzkZMg6kSsoMtonNUfk/dLZBBWEMuAT5FAJHannK1ZSIUs1WeG6GN7Zm086u?= =?us-ascii?Q?Omf4I9EGxIQQkLo8U1TWPvWQJNE4I/dGCEjhZNlfxQ6gS5s8uBQBj76j+Fo5?= =?us-ascii?Q?b7pB71YrMw7Y6QDBC8ZBcZLi2Rue5SX3DzFa/gBOtdBX0MjQya6U39JuRoi2?= =?us-ascii?Q?8b6OklfBN+NMyccIcz91cY1g+bgBUY52lcxdUGS3ngfiW0TtLY4Ss5b4jYvb?= =?us-ascii?Q?bO9Y2wg5JP/WUKBIilXENZBa3BZmEvM/YIeDX6G2LwXb4N+sN/haWNhgJ6NL?= =?us-ascii?Q?a4zoqucHgNQGs7AFNSwHvNzpAbTUK/NeQj0t+f3On5aOlmLDGVVmd80/pNUY?= =?us-ascii?Q?6FXADXr/82oFFkv6i/uvFsqEDRLsEiDUQX71fWJr3AInjOU7ZCsdEqUctIkD?= =?us-ascii?Q?JmWRC7UxEpCiJuI7TVBZCtC/nl65yTV5ZQyX7FX28FsAI9SJwWECmELeOgCW?= =?us-ascii?Q?BP/G2INQhB+kAzApJRCoGsXdQQJjFyjnzBtTPWgwM0U8QHFOVqQn5z5vUVUB?= =?us-ascii?Q?FnIeDeMah42aVpjIV93lLo1OGZ8apXSpKETJ383SLHPC2LtBWPUuGsRi0WO9?= =?us-ascii?Q?HkJmUZiv5b49d9lRl+z331w4PXvf6wEzV7KKMgvdYwr9IE4Aq0zlbGDYBGV/?= =?us-ascii?Q?TokTNvYPV2u9mp2K9vz+r2My04NXdBULNKSuNjR07Twr5gpktYzlmpaLKJA/?= =?us-ascii?Q?xnhRgFjZQwwO+RPtqZSH6Z/97e6Jzijcd+aJ9mFylaIY5Bg64QqGyQVJTomb?= =?us-ascii?Q?FkWaT8qvL2G125m8++rQa1pp4P1BmeVfwpZBnAK0ojdDTUtV8bhL4DqUgFgP?= =?us-ascii?Q?cv9J3siu4UWJ8a4p+npUTWSqQarmYEpOxrVTQnJZITEELcC6eBOi1aH/HedT?= =?us-ascii?Q?4wckUvss2wRsIZwyaORXwST+Jqy+Yu43Lh0dncAwiqhY7u7/Y/z/w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:AW/f/lG8GH0QyxmRMs4ub+UWoVossoIpri18z70Js2dlLPJfB4jKr4EOuTbo5eFMSLK/xQLHleCDwtR0aFTq8AL93vIx7l87bw/AI7Ja+pk7/y4vih29XemiNF95ZQtu56le4vdneZH6/ebpQI7z7V4csZsQgdYJ2Jlr2+Ryw/3/hJYOEQhQiqUDtqt9Reqw/6vWwb0VkFPiXJghRYhUdkFdna4xHteIcoVZjtbQcVDrzDnPHmASB7G8LRVfycbcxvnfS0xwgCOqdd09M/z849ziJOyTVas+hsP1DTvpT4RGmaH23BavwT/t8jRgN3KPqOWs1x5vHYI++i3DnDPxhQ==; 5:wF3mNGBG48ixriK+1BQxpavnd/HvYBPQBN8WXiHdTQSVETpvnCASGsP8RuqSUhz15RPz9M3MrBs7rM7FvI9eC41ax6j0sKPXYevKjfiUdCerzLza+ufvlExTkEFuTf4PjabdVNEGIe4Kq7PB/UYGOA==; 24:d8dGXJ/Ty7aFlDpHqjqu5sJt47G7WKBeZQR41omItg3SWs/Na/pys20XtOrwlE8O6PCC0fLV2xfR4EkISRsek/Ab9ZcwqYKiJw5wmV9PEKg=; 7:AZAbwOjjdwqgfG8Gc1PkrqvaRsVe/vi1cSYR8tk099/EW/qRypp1i+BFmz5DAb/HEP9BKiZAnY1CJeJS8K9QEz5Yy+yNQEtjToI3gTD9hFpg1LmQgfZtcMD/67q4H4AzSwZL+qYSoM7ssyzdQOjMrufYZmDji+PbnFhiwKChZXNqVE5NePZMWGYfdh8o6JFpEjooMkZsgv3PeMsBuQbvoG+koMJV0PHA+5MiE2KfW90T/+TFSOztDg9iQ0H3WTQf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:39:37.7434 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508 Archived-At: Cc: mpls@ietf.org Subject: [spring] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:39:43 -0000 Dear WG (and cc MPLS, please include SPRING in replies), As we discussed at our meeting, working group adoption has been = requested for draft-psarkar-spring-mpls-anycast-segments. Please reply = to the list with your comments, including although not limited to = whether or not you support adoption. Non-authors are especially = encouraged to comment. We will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author = list for this document exceeds the maximum recommended. Assuming the = document is adopted, the authors should be prepared to correct this when = submitting as a WG document, ideally by reducing the list to simply the = active editor(s) and making use of the "contributors" section for the = full list. Thanks, --Bruno and John From nobody Sun Jul 24 05:43:39 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9C012D0F8 for ; Sun, 24 Jul 2016 05:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWDsKB0tnEqb for ; Sun, 24 Jul 2016 05:43:36 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0111.outbound.protection.outlook.com [104.47.33.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DE812D0AF for ; Sun, 24 Jul 2016 05:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ToKoxN7Ztiyg9mxBGEKGlQI99DCTDbBkdh3v9IiWvUE=; b=Vktwt4US1DcAspLnRcXYDagaAKn/Bo6FYhjZ4pQ2T728awA7UH/RwlgHVo762UFHt8QUTaXLNaApMp2L9/l7J9ecp/6uBytBsmNX7Dxv8SxBAr5I2YB9hEgB+fslH9pmj6ru0BrjNLJ4SGs4IMaunclqrjPclMXq3HfjY8ZbS60= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:43:29 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <1746B421-B74D-42C8-BCB8-9B5DD8CB4316@juniper.net> Date: Sun, 24 Jul 2016 14:43:18 +0200 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: AM2PR07CA0039.eurprd07.prod.outlook.com (10.163.24.177) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-Office365-Filtering-Correlation-Id: 9a42ede0-955c-459f-1dcc-08d3b3c01f05 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 2:0lxZxitZMcxRrJjBOTz2HEufdlqV9lFkeeX611auMXnJP/OgIjl+G+ZCsdEo0vPHB9CvEmShqw+gCv6JhDLn6CgC1Hap1EkpoLA4xXvA7dYYwEpDi7RE7Q43MlwR4cS9PS1+Kwebg4zQ8h4vcN7oRjfLLLr+4va2RbAgOVA/QeQYYpzUIvnTn1yQq3k7WHQO; 3:hQmuapOnSFOKkck2cG1O74/bNnWmg4y3n3OksWMiOgp/BOjsGkfZk+H0alNvuwhrFsOuEyxh/Qs8itIpUGmXmcmYuEx5e0xgVgXg5b1+NdxHbYsKHt58LzWaNyvcTBEW; 25:J/JSY/L9hjAQno3QgWusR7j7xo80cKvvPVGs1XM22K0suZJyYHIeqf6U9kGCvs06VAEDEca/2U+LilMVUsTY+2y5cxHAheXsYoHqHHL9mknkcUXrOExUaA+tGyrz6OOZrIrX73Fwl3oBLMgNixCBrHXHmsHxADidTyAs1ywLbvk1Koj2EUOealy0gwMRplAE1RIRvzHNEjGjpS7R0qoIazJoudAinEWlcu5rrmbp3Zu0nowfi6gkHG0AMmIXuz08MxSjG8GttE3WSKbVbpOocmBXJpqHBPqME+sSmbMOHZaxnY8KypJ/Dko0D1CrGdUqzogu+Pd75RGp7EREBAg2p5CE8gvDLpVoPkfUVYwN1KAOuNL0ZBjpJBVIRbHtHXz3tL1nLuqojIxDCwnvoq05EMWP4RxStwE/MM8Wkm39bhE=; 31:PDmzXGUo63bkURhaSaore5Z12bdoXSTcNCn5t+MliHhbl+oWZWK+FUxR9OJWKjkvVAwUBr/gWYUMFRfc5bbdMq+7RYYuwA4JpjwNK9R+3ax/EDxSNutZpInXfqtbtzR6L9k52114ymaE/j77UtiOhYb98vuHdB3QaosSfHswLnTD0HmrHdQwYoLp7YNKLK81bv4b3z4APIUcXy5KrTUfVA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 20:88bCdh/8euCi8DcWM2bTPgySXREY4WiSQ8+/VaTbwssaP0b/NCpRukXlUvkli1ZoiSMuewL1/BIWddhV/7aA2ARV6QEQNZZGLiTAFStlyCtd0wVmi6X5WleqoH9uUMkWTmIgib791CZGA3Ht6bvMh4ahXppIFt8KsrsWP+3SGqzhJ/xKfYkdC+c2A+tQaysw9lB2w7FmL6gH/j01hOZdScv4UkcHXK0H60ITFV3e9m8gBxoOMQ7VA5egRoRYSI+gso4zrq6oXIPTtieE0p6J6392JtjFd8PUAnGF/2b4budm/iFgCuX4gtcClvPs6aXRx3f6N5OQZFccmU/QyFRx2ybkKltLk/uoOuZ6Meu76Vcd2s2lZpPEe9hK7MdEsTQ1rPR7gKF7u7pPZ5yNcf9gHZiwmEg7AMpm5MdxKdiL/VWm0vWsxFYFn8mvldDZJb+i5Ym71mBiOGkmZjqZaU+iUjQy3N8P02K9Q7LTLwb2Dnjs4hsmm4yHK1CAmlm9kSvq; 4:EMu4JRf6DUZXGbIwuVrpRIYnhZ23b8b0Evu+n1P29ZZrJznYPv0Z3FaYVS4/FUUBhrnUr6rGctLU7NZiexWujFUphhNYdHyYOjMfQ57vrnG6DJZpV1JRMkVptTocvOzGk0FmwdLCmyDOFX+gvo54PP2Jx9IejNErIGz6Mbc37s9HANUVbouUvbez8HZydM1QXQLa5R/5ZMDDP9EXdKGTsGIoQF4U0aklvqgwSFfG7syLOg6nNUHbWFNeg67bKPvVX1i9JEw+JQcosqXFwpxGXGHID1vUFqWH2D8+l3YXpXMtVstird79OBEOYbI+XM/p6L7jxq0YRBNsk+1lnEEn8l7kgFq+g2EP+LbEXko6RobuixcMpQ1xeQvkSIL0DBSpnHMfvvgLhM7VRKo1U53up95e+dQ1wLaOPMmyCa9wZBptpEdJgitrgsEQa0+Q9olj X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(54014002)(199003)(86362001)(97756001)(57306001)(8746002)(50466002)(7736002)(92566002)(7846002)(81166006)(106356001)(81156014)(2351001)(8676002)(229853001)(50226002)(101416001)(33656002)(305945005)(450100001)(50986999)(189998001)(82746002)(42186005)(68736007)(83716003)(47776003)(105586002)(23726003)(107886002)(6116002)(3846002)(586003)(97736004)(36756003)(110136002)(2906002)(66066001)(77096005)(46406003)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 23:kbUGDFC5V92MhTKg0ettGjT6GZks0Uz8NkdtJjXLU?= =?us-ascii?Q?oARdPSYYhneIMvFcBT7xIUvoPE8DEJzjbypIL4XiSfLxkrFBpf9h0ZHItZ15?= =?us-ascii?Q?p581czhH+5aahBtWPBsTNov9OZ5pToy0fKHWG9/guszAyyPNMkz/CmeTgOtc?= =?us-ascii?Q?xOyX1IxClOXNlsdxuJN+fzZ4/nebOjk0IzaOKUFQEYaAp9ihtN4F5f4shvcl?= =?us-ascii?Q?i6gBTk/3W67W9ao7jmCa+jqtU0eNS2QWRp4UFzr40Dpzeysie1DepRI8s6Mn?= =?us-ascii?Q?EybJDndheUi5G9xK1P1acDr+acVmO8dQwfiCVzqs8sRtUmMFTHoulVntrJ3U?= =?us-ascii?Q?5mo+aFt4zTt+CYeTnuBLf0FGASexSRaIS6Lh8znfWxFUxOl02A4gFTRDSFok?= =?us-ascii?Q?ZylVkyxH8GzMhC9FK6uqLh/EGnEJpOmhnzp6CiAfNUzRq/mxAScSpVrv9uYE?= =?us-ascii?Q?n8uhISVtwrjzw5D4sG+lBCilH9dXOGfo1SnVHtTf8ev6zxLqWe/SFbej7Y+w?= =?us-ascii?Q?tecgnrvG6Aqx0OrdV/UYFnRfPX+HuoL+tRourtf5v5LBI+z41Wh13253KcTb?= =?us-ascii?Q?K0+92FQOxjFFR66JUoNjOa5GXubyJiseJkRfTpIjdtwbOFZGF9zqJi3Ty9n5?= =?us-ascii?Q?cCWZkErpuMEycDkvXgvMJLSOq4kV4r9S+yzJcW1boznjdmR1p/IwqQMjEIbC?= =?us-ascii?Q?DJKyYguUk/vsWUJrAC7TYAES/76pp6OEyeK7ee6qJI21A84NRbTMEoSduI3l?= =?us-ascii?Q?zygJBOQnQAK2x+zLmDa1IKO2ET5i6NhOncFkcWWNgMkMcpf6zO1iG7Rjq8cc?= =?us-ascii?Q?nUeu+4dD9SPMKY622l5G/CTItZ/uG8PNoVVlWBnE279QRDmJcCFK9aMLbwnb?= =?us-ascii?Q?+QRap+x7+pl7OHtbSvn8OIXW6v5F+VJ0hBtw5Fgn1sh6l9XHzCcDoXZ4BT1E?= =?us-ascii?Q?3MsQtFMt7FdjWjRimPY9CVi/Hzhhe8/TYiapua2rcfogzGVM3YS84lM1hPER?= =?us-ascii?Q?f5QhVq+HxNU5zw1qQZOK0rnaykrp1gb02doJKsvNYGQ+xFaYhLpsdV3gqXaZ?= =?us-ascii?Q?n6C4ZohEc+mvClttJgTPf91vD/3DUB9T0yyianc9llmwxnEJs95lP3R8LtYM?= =?us-ascii?Q?3lJ3QcGfYBR62bfLSDPEEgnZBjjU75UJNsWsjTPTwCObRtx6bxbnKISkPoU4?= =?us-ascii?Q?gMK5WsNf1ZW+A4=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 6:Fi32/DVW6bWvSL1/66heOBy4A7jmxnP2o76j7qWGmPnssQHBURTuplerlaNqw56e/0mtE7V5qRQdCi+DZhUBn4V+mG1wFrnp0ryhfufiHwf/Y+Lr0SP0UOfmcLK6eTLIBDjaxQNgEbX0iI7HVIYyn2HFkIKNO/bx2sEjK/EMPIye/4xWuD5r/f0hD/w89O3idEGDmcimgIX8Dd79z3MDFRBhPrtVi5tghjRKAdpb/SEf9qrzTc74jaF8f569lC13b0FUAt3lc2HPOXHeseUAUnYOR/ZJvBkpTbltZK+YiGmIozOJz4jLsdY7YHj7TkPDY3SN3VIpW5xGVHeIeSM1Sw==; 5:2sK78GVBeAM0ooaOQaDYTi+C8yc/KUAy75Ms5pcCEu0a4kALgV0BwgDSzMafzY810i9Tbu2ikn7AfsvqtdqUIZchCjI86zwqlEskGmHwf/XkUI/jjkuTxMVMosWdRByhqm0dSTioqVwX5jby8fLaoA==; 24:aphSlInQ98IVUoVGjlooHUhf4fuxq6OqFp1Yd1pJYGyOgVT/IkP/6LALC1f1U31UFlQ3Twp7bOGGbrTVJVs7/PcAPR9l89QAHJULyMjTehE=; 7:kdqi54eyzmJIcGpf3Hq12Z3HvNGfRbgqHd1iMQ4UD3lnOVnl1Pibj8zy3R+UHLs8YZcO6ZQ1h5YSXPAUBNnqwmqQRcrVYDq/cAQjoHZ21u2AXO+Oyin3A5jZQw0wZTWBdddBpOwD0sAvhGYKtoSLLpwGuYxi8G4+znrUBvAETmw75FoKHfhEgv6PDG09zeAYEwTMLpavR87nHZU37sSkDWzbfyppIA3JUejRIouRA+Lt9XuYzHT1JVnC3R65LfFw SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:43:29.9282 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Subject: [spring] WGLC and Adoption calls incoming X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:43:38 -0000 Dear WG, As we mentioned in the meeting, there is a large number of WGLC and = Adoption requests incoming. (6 WGLC and 3 adoption, if I've counted = right). Similar to last year, we will try to address the workload of = reviewing all these documents by extending the comment period. Other things to keep in mind -- - Before we start the WGLCs, we will ask authors for IPR statements. It = would be great if authors responded promptly so that we can proceed. - Several of the drafts have an excessive number of front-page authors. = The drafts will not be advanced until it's corrected. Authors, please = consider updating the documents promptly so we can move forward when the = WGLC concludes. - Everyone, please consider volunteering as a document shepherd.=20 Finally, please keep in mind that the chairs can't read your minds so if = you support advancement, please do say so. Likewise, if you don't = support it, say that. Silence indicates neither assent nor its opposite. = We need a positive indication of WG consensus and support to move = forward. Thanks! --John and Bruno= From nobody Sun Jul 24 05:47:02 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD912D12D; Sun, 24 Jul 2016 05:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBu1Ep6AvORS; Sun, 24 Jul 2016 05:47:00 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0115.outbound.protection.outlook.com [104.47.34.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F8612D0F8; Sun, 24 Jul 2016 05:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lQEO5HHWgCmBEpfrN2/p6TQhuKktBDFJADg4huW0P+U=; b=ApCUFcFbqLuraPKfABuNVremgDCRD7G8dbpVaxMydCt7O4QfIFo/iQXYuEfOPORcx/ugAnKlz7a9M4itn10xtL2jDeGX9eWP+UBqpfMZBS4uAiKnxiE95ttsdLqreTqDW2gdF5P+cR9neuAYeeGxebwa38YZMtCI3wttK55+of0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Sun, 24 Jul 2016 12:46:57 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2016 14:46:53 +0200 Message-ID: To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: BLUPR18CA0035.namprd18.prod.outlook.com (10.162.230.45) To BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) X-MS-Office365-Filtering-Correlation-Id: d5950c9a-d66f-4a9a-e626-08d3b3c099d2 X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 2:THV1ZkJV9KwzMbheBICrOGuirtgYiwGAxSUV3poBphjAwtHgeIj/WrDdMImYgX5odGX3Yy2Gxxgsm2sCauxRtI9I8NPZzCctBiz2OdzmRg4ucFZtMqVhq/bs28J6XDLn0mmmsrlA587sLEuLTzJyl5/v1BeKsTNLSbfELNZ9IdpRWn4ODyYaC1PhA5gA4gWI; 3:7sqnxIdjqnVdv45Rc04OTItA7w554y59PA/q4Ki+2bbfHDqYyfqD9gfVdSKYiKBOP/n5FvAN4brLmrI2pDjF6mmalw1VOhqHbWwucG4UTaYJEmwT8grWzMQWvKnwbivI X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2499; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 25:6hPo+9FB2zDtIuTPlOb9im+E+Gp/qZB0SYKfDl9oeg/7tvcmb2b73AUP7xIHuj+7kY0dKZVO9VIdkjJH1feIsKoLHdYcPf/Y4Ui6zcu8ZDMeVdvrs1+TJj7EsMNTP88xCrp1toXABoDeZw7VcCm+tyGUO+DUBc7hA0q16pMS6nTFIr4vmD+D040imfTYIJYngvu241v338qPfoimdUZ3uDJuOqAe+E0kI1G2Y2nyoP5WQVi2vPjDzn92ebHB4iGOfTv+K4XSClvsXpE1WZaGx1A9FuNl/g+MDdvpg9jbxNAw+BXgE0h0NhUgXyKeUmuhHXIfSguCDqRAV478punlMCxjOLKVPEqUoaZvM9SUeUt2mqOhEm97eNB8n74WwgEih/iyMse2POGEpaIjSXuJclM/Ghx9XFKWnU1CYN8izcCKJbOVjXpshK/3+siCWQYAexfdTIW9/y6z3JLiNh3qIPyCItwt3HmPG3t4GWasKFiqfP3pT94EIA3jt+vT422xnICP2EfpiMzPOhHdtNf67ITaIr8K455LHORLK/28/1oa/R2SZSfPOjrCsD7ZlsqmxCvXAcyZq7XgROLM2ablxx2S9Da/ZqB8qlI35lTzQOOO5Sw+mA/Q5cXvfQEWoRYDVYsMHueYqGoDKgCDzBtJz5B5dPablopO4Sikc/3wfyD+G9Rkd54GsrPo1/b7k5+fMENck92sMLvszTWIW/kU9fkL/E+gnVlEKq6hz3649TE=; 31:m7uRtfkONU95sh7VwGv1EqWyEBhd2liKWSVJZac2C1EdINmL00xiicEaruyloSm3bh+6t7G084j0XEOaJx1SkIMPPLKGqKy6r8cGZptnka0vUmuKpAeyS2FmPVohhANAoXG/cD/vERs+mwhO/gm7lQQMDYREUEy5kg0bEmTuGQlitsD/7lkxagkvDzwbRTZUdet5QfD3cwdne+5A65gmHA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 20:yS3XcykciW0YGIt+34c9XY+9/mQdsZHfhnv36O4IJ+kUsUM5Ha+nqJZgXgnYok7WziujuY+oQOn2jHLvMWsYzGC/Id/5S09wyXNvkxHgXROg9DYg+6fP8thelO6UZJSq5nU+/zHqu6GYvmQfDe4hS7MeX9elQMV0XtotqY63sonSIV8Vtzn8qqVwhYvGFLebdAMg47O0Oxj1iw/SoAtMhHoSEmJAopGtZRPp8kHTKsUX/PacoRlXviOmby0eakhS/O+cuKDdm3tIgT2yu5fid/fhIW3BN2r0xg9syWtiZtLMMCUMLT22w8uY3SDjF5KVy670tRxEMLwYvvP37FaJBjVYrLmbMxuB2Hp6X99EFVijd3RpQ4dBRxTFXMpY2YREUVJ18alvGoogaawEu+Cqyr4PnYEoRsUkN8jkXOgkxzsESEeixfSTSQiaMjLiw8Sys5BmpQDtBDw/PM7oBni3lndARSIQoqNQ1xTMJt09+M/jlh9IECom/oo8vNrK8UKx; 4:NfRSTpHPN5OuHcagxKyzSRJl/+iMPLmNU5gtLjkOC4Sj4JHh3aQNF2t+SDGfIveGvXzS+Qv+2LZBUvaiE1Q+TOIogAa0QngqjjuoEdKphGJtXDOtibNJJhsnHn+PH7u7/YEjvvCrPN6QnV2l1wyoX4WkVhRu1bkueXRjLLPWWvX4rtHvHOKorKobD/hWTKow5oLKdbPZs2Qysxr7mh0VUq+q2sE2se24kHDLxR3ZWAwdNfKAP/lmhXnmwFgfLDLSp7SPx75RmKRkN0drloOGAHrHnZhG8vfwu4VmuwsNerWzhf5ByikFr71yi5CBW7+a1LAOFhSx9UtCW0jBamiqdNZNMMUhfBS1ivdVLOj4CIkllLbWnRCLg6Ylr8FEVhtjsEYU2YnpjON9HT7AN2puXA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2499; BCL:0; PCL:0; RULEID:(304825044); SRVR:BN3PR05MB2499; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(40764003)(199003)(50466002)(6116002)(92566002)(230783001)(586003)(36756003)(3846002)(23726003)(97736004)(4326007)(81166006)(82746002)(50226002)(68736007)(8746002)(66066001)(83716003)(8676002)(47776003)(57306001)(81156014)(77096005)(450100001)(305945005)(46406003)(86362001)(7846002)(110136002)(189998001)(7736002)(50986999)(42186005)(105586002)(33656002)(2351001)(106356001)(2906002)(229853001)(97756001)(101416001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2499; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2499; 23:eTAfFI4Jb9qyP9uDcUZkY7j1CfZay5Z9MOc4UuV1j?= =?us-ascii?Q?wslf2PGZp83HMUo+hNplumSCJ8pv7hjYhfGO/ZpbyynH+th5GGHf5Tt6ceEN?= =?us-ascii?Q?kFXgt7SQ1W3vk0c6/WEZF/29o8WAy+gKGy1f9CC+to2zHFc9BdXtSWqDRvj9?= =?us-ascii?Q?93/Mecaddcn70yUBrr2JuYynr9y+BsNVYL/XzMiqacz0+kmG39wFZCJKVxtJ?= =?us-ascii?Q?N7UVgzsfr1jeTyPREA7o4Tp3TAMVqCz1oB/hmm+GkuWGn0AOMWbCXhtZQRuV?= =?us-ascii?Q?+xtI7sCtXS87ukWjgbS0V/7j7sgAUVkpeKuyPtPFQybAhBju9zflaarsTl23?= =?us-ascii?Q?c+6g3MV0YRIjV1sU5A4oyVpqFIpPevM5/oXWQwCsjV9m97XMkNHr/MPTwf8l?= =?us-ascii?Q?AncP/GVMHONZGc5muZFgivsxQlhM2T4G4kt7iUkfarOY2IPwr+JeKschQTm6?= =?us-ascii?Q?/aKLgj3/drZ7RKCVT+PlQfcCZnNyc2B3yLr0W1DoAtXw3miJqL0vrcel1Oiw?= =?us-ascii?Q?72cjk2fMfwyHdzp8d+bSASX8VfuXMEiBDeof+4m3Kgdz8FktA3MAOYJC2dDK?= =?us-ascii?Q?Sn0E8KxCOsSo9pO9eEpkmoC0KaBDfy4Id7VXTXIXckHmCyeAnqO9S8ivbWha?= =?us-ascii?Q?1npyQMcYeHbWbkgTn3RiiMhKMpwMt8hRUKU4zQviEx3tLb4EZczGAjNJUEkq?= =?us-ascii?Q?2xA2W8StiSpAcOLokHkvs3821yBHEmkUrmELv91AszgqtgWSw+jLBGuP7qOL?= =?us-ascii?Q?YECQWqH5d26b/nLHA2uNaAdyqmqkTE2ozSpejcg2Zj82dvEuS3rEmG8rY3oN?= =?us-ascii?Q?bXwNzcthBGGOJfEevHoMn2A3qUfq84iV9Ssf/+E63NSgSTfN8xchERFPdN4t?= =?us-ascii?Q?1Tw3Xexb7R2zOa1kqLIGSQi+exhAgzh8DSyKQaBmXiXCc/arXdGOTHN34nTG?= =?us-ascii?Q?C+cSkk9IbKIgzqn04TMSUarsyltA3C2NKbtxJbVxPBVGm14qaTFnbq4mLgLj?= =?us-ascii?Q?jIOCZsyICCEssNOPoEIpb5PR26QRzx0ySnCLulvJZ8MxMhIlogmuk8JOcszu?= =?us-ascii?Q?rj2Klytl1F4Ldigjcl0XWJe1xzYI6Bm7HE9Ov/pxlWYXeu/goiIM7qkAAhFi?= =?us-ascii?Q?TLU/KdsL+k8a0dlOU9uwAae2W5Rr6cWklYX+pxijWsFS9MIALTX+0N+bAnDQ?= =?us-ascii?Q?eOwI54hQWY6pKk=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 6:Yex5miL9QAnaxhB8pnDvCAnAPNLXfDTgIgwyEKrE6kHiIP4sgReoSisbSSp/LlG/wuxdIMvfiaWSVcO/RhwNhPV3+CoVSuVWD9QopAFxzawGi+aRRrR+m2CdBBCB9eTgikQICYF7gAaFIdnY9HSsKeZWAdVU5sBcT9wrk1oO2CiiFF8DmfRs5kDxJNv0lZEwRaywNPfX50/ftBAZPGIfcAUlhJx2fLygpFSOZZSyJ7UFCIekgEJl85VVNCs66oqYFwdWPbPX7Mo9Ue+KEwp+QkBlydjXyzfPapXmSpA6f4hirAjPex4NOxqWAATzYBKuYI7jWXuWSiKb0Znls93LzA==; 5:wp3LY6KXjzfQcbuF+UIF/9nh9ywq8Y/I0GoKM/xBvfNHuaq+c4y4WUPIcoNu1DPJ8FNpKmnCoE/bOLokQJIv9W4M9H3AQAjy2mpGfeRAc+HLv0zKA7cpoLZPwoFqy3lrLGVgSLK2Spd6FtG2tUrGmkd6xzHymyLKfY4aJFSoIMg=; 24:w1sE+VC4HkjqdSJ8wtfFLlG5bhVyjOPX6AdCifl09MtKqUBb4mtgMhiiEz/5xS3kqnF/BlO2VBMqei+eOBlaveWLWYJS1tT+ISyvnDH16xE=; 7:2drqIU5iZK5Et3rBYTt1GlPGcVnjTH8Z3mAK9iNyQyGaoNIW6BuO7D22yRQwKTrBS8WjE2YXAg+pc8LnEVrScNh9+zkX31MU4daXunKSq+Y4rhWsL0J2sKa1txMXLIstGmo15rczFasoswrelW/jVPi9TPIS8zlTL9N1tolZ4hW+v0F3Y448xUSs8QKiflQmpxCJ6h4b4VHKtYWE7fCkTNYnUr0ZfSP3GO1xaLUO1aLtXd/qa6qP3gq5RfGh46T2 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:46:57.7333 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2499 Archived-At: Cc: spring@ietf.org Subject: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:47:01 -0000 [re-sending with WG in cc. Please cc WG on your replies, thanks and = sorry for the dup.] Dear Authors: As we discussed at the SPRING meeting, working group last call has been = requested for draft-ietf-spring-oam-usecase. Before we begin the WGLC, = please indicate whether you are aware of any relevant IPR and if so, = whether it has been disclosed. (Please do this even if you've done it = before, thanks for your help.) As soon as this has been collected from all authors, we'll start the = WGLC. Thanks, --Bruno and John From nobody Sun Jul 24 05:47:56 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582CC12D190; Sun, 24 Jul 2016 05:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VExIEkg8wgtP; Sun, 24 Jul 2016 05:47:54 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0136.outbound.protection.outlook.com [104.47.34.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C9812D185; Sun, 24 Jul 2016 05:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rp1AG67s+ZOO4MnHFRQYKm21pS4d3rhKFcpl5JvkmsE=; b=d5kCDU4fyyjJnts/+RIlc5ivQGFbTpjD/DoNsLVR+W/XxSbin46UG/9Fqy8IG4e7gpyP5NxYw9ebA5HZI9Xmf/xhc39p24bCXbUAD0x8Bq8vxwlz1jAkmUzHM0w4M4ek5QjDAZDMabbz7wwT+URq4hCXSI62IrOu2C01Tufrjh4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Sun, 24 Jul 2016 12:47:51 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2016 14:47:47 +0200 Message-ID: To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: BLUPR18CA0035.namprd18.prod.outlook.com (10.162.230.45) To BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) X-MS-Office365-Filtering-Correlation-Id: 7b95db53-59c7-45f8-42ea-08d3b3c0ba16 X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 2:JiEHQ5ZTpQusnmqNa3gBOaQfhfhFyEtGO626Pi570wOENPXt1IOavYCRJWB33VIzuE8gBn1Etuk0gigMpEqk+LGyS74kIpExQDvujez40IoAgIx5h05otfLG/l62PpBAOT9advZHJUVKn78DsPK7rlNBSgTk2VssRouyZ2giqi5wTdCxTIk5AvSLEsqVskDH; 3:q1MOGJbmCV99P74BYf3tTHq0v77FoYnbpH6qUT0mgIxRWhXqiIyADMkrllt/TD9deevu7genmFd2vmLM/ihaedH7MzS43q4uELfnaRsedw6nrcPGxCyjx0eaghKlB4ek; 25:cdK8Ev3sdD2wUQR+1xjOEOgDFG5lr70dD4DqFMnslgnFJPjd6KSYI5TbdxiOvjjTz7KTy1+Ew/On9+ODZ6lFzBS1rNfT3VkeyxfFW4gmncefHMkqeaUKJ8OraeJFK2VDq4RoqLG/0V8Tmxltsq4BuSdZpREy/CVqvFzka7k8xc+RNZ152FW5W8/CLdoo6q9tfGXzDCLWDLZWSJBaSquAHwxCcCTy0Nb0OE/b5hOci5OJ2xwc45hRDnGJ9z/csalac++4WaWF5XbgIi33zINUpRJJb6A/vMZJXlQFXqNz34WULUQg94QzLDOzExj73KeepTwmssSo/j+TjlY/L4zEV+FcEhbRxhgjInfijlYktbucUtrUh1XeXclPncoDAPeUpemg69DolBbrlR+0erWAJLDFlWJofKX4RDkoJ9QSsag=; 31:C0ihZEI3DrlyPDh8Pnzcc9/TJjfknSdiivRzVA1gxCZC3bRPyAERFDXOGR/KE7CM39jPGWff1ixBL3FRPTUjxycYyYFId/DPuP/i6UtYpJhPAiZYKpOD0s3LD9cBS7YJWPZRpnSvHQMMHRP1ld75k5Ahuh7Tt6Fyv7A52ncFi4yJh2DMegKmordjwNBiEu207IBvUxWoH3OP43LUAcywAQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2499; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 20:vXrB2W1+tMiQQeqi3V+zMMaFlKT7w3aRZ4hb2mRAiIiMWCuC1RyYnYNGWq0HipOOAxMSR8jruts4x/nE83byBrEjjPD4viUzblW3T4LTRdhUU5IB1uhjIJV9sKXoml0O2D8HSbcZFDcU+UOdXdjwOizZRd3q5U5wSYJ6Og01uZl8fqadnQMRTwwZ18eUVVjvJRj0dHs3JlZnRiyitbW1A3AvmNPZVRjaqwybh2L2xPHEW6CyaCjX4Ai8qYZ0lGYqXwbdWwBLVMoRS3R3BSRjrzcYSSEP9AIBUYXaEmiUVBnjTv/oiroM5tIvFQ7YuHjLPxU1dC+660lMPjA/15+6laIKUM/cD62vhIMscoXbuGx5r8bp34lVdzKhqkrudxUFPJT3qzb2iH99NUx61EeDgaIM/CmHpJw0OGrZ3Uxn/hVpKPHqFO9lN7h3YVj4aQzb/mnMecH4AyldezKOOUd+kZ/uGwuMnkbq1UK1VyRq9lxhXxgW43CTBshFBZF8aCC6; 4:XRHUFcxHFbBe5lt7zAYGWI2IYFMCY/2ww3kUm1SkrD2L2wn+A3lrn80AAhhQEKJWYDbB1J6iMFyZeCjRIwlDQrqPM9QrC6P7+D5ef3CCrYMAYZwzRp+KNQmrOnCCVxvx3vuNjHpjWpdZRmDvwdXjl10TZk2r1hrYlBW60B71IDsOPTVJYgyyyITjrcVeqmjr/GryVfo84LcGnbJkM9lcy38zDpmobibPsVf8XoD1T4A0ePjm4LvTJut7wF9gcKYljEqgcqV36v0MtboU1KbdDCZQpLAmt1v20C9O0QpncdaRqlCelJ/dxpP3DBv9uDuZhT7qpuC8oJx1Iycl2twukknFiXfnXjXTM2R3il8TjbcecvXFjUpbNRFgyPC76v9TXmTZHh+zI8QXYsDq793YEg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2499; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2499; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(40764003)(199003)(50466002)(6116002)(92566002)(230783001)(586003)(36756003)(3846002)(23726003)(97736004)(4326007)(81166006)(82746002)(50226002)(68736007)(8746002)(66066001)(83716003)(8676002)(47776003)(57306001)(81156014)(77096005)(450100001)(305945005)(46406003)(86362001)(7846002)(110136002)(189998001)(7736002)(50986999)(42186005)(105586002)(33656002)(2351001)(106356001)(2906002)(229853001)(97756001)(101416001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2499; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2499; 23:9DHyq83V2Mem8tf5AQYXO7pWfNt09S+v7wTZuboCC?= =?us-ascii?Q?FUn3EMX5ZM2n0g7odd09bT9z28zdfWoucHwXSybN39sXFo/hGroBdHtLdjf2?= =?us-ascii?Q?frLbUL/3loxIo977uODSTgO+IzEFsfEdZfD+2z9abR6DBywt1/yzthchEwkz?= =?us-ascii?Q?GLclIOA18R/D3qpbs7NeEfky4g4nvJlCr7z4oD8+6teqN5tQjWe0gqECoqkM?= =?us-ascii?Q?fOsGKrgDeV28sWCg/QhVIJWjdXTvLhTykTbptQJVBJNtvzG4/pH4OB2BIdKS?= =?us-ascii?Q?3OAk8Z2L4PEfp7QjHtEKQwY9b4PHF4mELLXFs1QR6Yg5ViLsZlaDyYAoiiUK?= =?us-ascii?Q?FMBMZWXDZA3LvLuWU8x3vrNCn8sBFuXkfObE1Icdt36FcBd7uxrtJBxRuDsH?= =?us-ascii?Q?G2eAGWdL7ai+945s9K3dXmZcuyRlCEbQp7RG2q9wzHv5lr4fN0sQ3h5MvEot?= =?us-ascii?Q?nTcv+u00QhgKyW0fcCGYNNE5GDnYAo484Bb72LaCxu6wpvpZpW6o67lbCnbl?= =?us-ascii?Q?x7xy1pVybVQ6FQjoiygE2lBowxmffIsmACcZxoTP1zdZuCdkRB+jyAbzlX0O?= =?us-ascii?Q?IiUX7r408vzRg8cqkb8vfN3rAW8raG0nJ0jsagKeqxSzim6GlTOGt5yUA/zD?= =?us-ascii?Q?mEES9WXSamcKk32GjcExS/UQrRhQDxN8DcIpycaQxeELr6uSRDpl6P2Dg9I+?= =?us-ascii?Q?TsW+7aKAE5h1U72rNpwCNqNRbzMEd7sxcW9/eeOyoJRXEuxE+5VIXPHtb1bV?= =?us-ascii?Q?odWRyJKi2PbnAnpusjsV7f14VP6cE5e93pWLsZRCDgJvGwCmR9SwBOZ/pjgs?= =?us-ascii?Q?N3c5t7tgPRW4IwCOyBkYuc/XN23FAL4S7SPRgM5H/X4lkd6Zz3MCVZQ9yREd?= =?us-ascii?Q?BWiZDYwZ5r7RIp4jiuDTHEwEuw0uc78nUczb0P7pP9EOvtbMHvX/aiyjT8Oj?= =?us-ascii?Q?GPW01TUB8PJv7mHtKMtiHShkKZhBxYO7xPhUUSyf8153v6HcJ6QQlCY23T8B?= =?us-ascii?Q?Cnkcv9e/FmA6svbai53bR78uNQ7GH7di3f9Il8nWo9UplgZKgE4fn4TePXE0?= =?us-ascii?Q?rpxKfwfGBUUHzoMLTXm4jWuxyBu9n/Vss3E7k0Qxb13GZ3IEzCM2Fz7bgkJ8?= =?us-ascii?Q?DpThXdW/IKPKS8gVIZNoJE5r1NesvGMOoqspuCvdX/9yAX3j9a/7LgxodmI0?= =?us-ascii?Q?/oLPP/Cq0o/WvY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 6:RkdC3jH8OSB6dHFdGrwg+/sSJOkPm+dXhS49Atj0GlnRAB9ycxkB9n+tM6oXWMmEP6UODDLr/MayCFLT7KimDhzhVCnr6DF/jsbgYx0ZoD+80lnb0NdSdXjeRX1mTRkqt4oiZ8XJTSCiSAxuPt+OCG0p7kvZHI/TaGt47GvkZ6OFofZNzfPhJJhtqLC+0r0D0/qJEA/nDSmpV7F4sijHq6v3xKbpdAQ9M8HT6pIF2MLMA/TFQPD8l7AOk3qsaKbSpkGnqZeHoe7WyhhXwWWIFQ1kwD5Yo0it8zv6ijOvidCdRmu7HBDqcQb1oDpIKz8Qju8Wy+W2JVtIqK/rZshFWQ==; 5:OFb3sq92rs4hlchsB9KGC33sY+BbW+9yLKSGrJaB9HoY3qO/gv1RQAYTmgFAZeDYv06ZplzbwDb5Y37voK2rrwphhGNeYkVeb7wyAjSVxmuhLUfaVQVoRb016Kd7FPsbo2qSWvR/QdG6skavkhGiGA==; 24:uRA5IFdVLsZ4qn8Fg6TwltIXtxJQbxeLcJo/8qpQqPtGvtQ2sZligFYHXHdqJBMqc6A/+8ozP82RMuHn/zqsVJUefcEYLjG09Jt4hS7bveU=; 7:kXtrcFWe2pgSLy6vSJuCYZt7jf8sIbtueeMytH1tiRbZwqN86I5vaDG5EU6USXqQh6n6RHqNYiNLw+58I5vj+Pbls80NgVmXEXsu+oOzIzihFWzy/9ONc62u9r65KTG3L2Al8lywZxZCW4rbxH2aLiwWg1FlJFCIWfjBJau0zaMVgRFzTJQTW83edtFKgvKjJFFqqRFFh5TLKhUO6xrLvU8QhUr65L0FR+32kWkkpi9NtacpNoD8uxkQeJdkYCuS SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:47:51.8569 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2499 Archived-At: Cc: spring@ietf.org Subject: [spring] IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:47:55 -0000 Dear Authors: As we discussed at the SPRING meeting, working group last call has been = requested for draft-ietf-spring-ipv6-use-cases. Before we begin the = WGLC, please indicate whether you are aware of any relevant IPR and if = so, whether it has been disclosed. (Please do this even if you've done = it before, thanks for your help.) Please cc the WG in your reply. As soon as this has been collected from all authors, we'll start the = WGLC. Thanks, --Bruno and John From nobody Sun Jul 24 05:49:47 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532FC12D105; Sun, 24 Jul 2016 05:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_OvJvXmv5QF; Sun, 24 Jul 2016 05:49:45 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0121.outbound.protection.outlook.com [104.47.40.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0364A12B053; Sun, 24 Jul 2016 05:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9gqW2ifVFtdPO61oADkAnXIoDVV+j4abGEhX7xir11E=; b=NglxAIWTJGsEP9uidfyRIdN2eANeWTYWmyi+xhsH7d901QW8UO2h/Crd9f0rc0ziFVCJqSaI6cVm/TN/HcaVd0ONnXz4MRyq+8UrA64dL2ri4rKUZwFPxL/DM9RtQ0ETGAas1iMiYe+2EtpRnHuEDETl5jVtm6AFSIkjL8OIjJU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:49:38 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2016 14:49:27 +0200 Message-ID: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: AM3PR06CA029.eurprd06.prod.outlook.com (10.141.192.147) To SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) X-MS-Office365-Filtering-Correlation-Id: 2c19d0f3-d17e-4aca-9084-08d3b3c0f9f6 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 2:y3fDttNvmZF+BmtJjVw058XO8iW4QhSqVK+0owPArGNi+6UpnS+K4UNSixmNBXl1IG2POdxASD9KwixntDQpSQvZZvDa8PMlQaIMY4+w2+/ittWHP7f2RYuQNPqQHbAO2HBTcrimNrbNYsKwoHcFOuWSsKbhxuXTldhvmTx614Jq8mC/G4AUtr9Cp/u5ESCm; 3:8YF+lkz28QQR0kFOJLjP4TR/XLM9JOFm2mslLSyuf5cyv4mhFYhlCJYBHFQe9rb+CxlCGTYJAF8Eu07h8mAGENjCsIhLY19jC425z3ALqJYrjBMvnF/ASffM8OLYSdPU; 25:yd9a0Qty2fvzt+h0R8UscFFcZ1nHxo4MMmAfiTjFrP4ui7czFldJIewiShEV0jEnvENzRSryZr/xG1oJHnif4udYI0/nY+JdXHp0ScDz1iEp46yqwvtx+gG8APEw5HZbjRSYDSJmMRJQD3y7+d6Rj2UYQ+7YsNgL6iQloDImhQL2IJ7gAArm6jWYD1DqSHoB5edicpxz2c9Z+1x11nxv4DRIKsvTrpcdbccKLBXqbp3LQWRSQQuh5e2areC/EzCBY0DJXnMnIL80WltL57hScXf0KPn75q2RLyUWFV70gcWoxrL7TRiLmUei6GOEGldDgHKVQRKVhkClTS+xAg2129J/4m1Yr7e4xcY3c1MzPGqjLRn5EO6qmgACVCNvN80IB+ufS1BpOI1aO9KdO9I+o5oXT78WK5wGaUkNnT+EWSA=; 31:HdQG0SIopmBB+rvO8Jiy3F3yDZwlCi9r7DjnDcOE5QqLPo5KeTMgesVKL5Vt6uOX3OyUZvHoC8ot9RYpTr9u0Yj1V/cSCKHMp9Ahp7sCGzMzXJgPZSelM9VJEEpzeee8SuQSv4sDkZ+tSLYD0mtbTZGKvv+XS/Am8ntgLQDQlp2dv/MUHNsZiIN6GB8Gve5e9XZ45a5kaE+7sJxwacFCSw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 20:ItoU364m+Q/Gdo02DrdNFcZUyWl79dTQEMQ9bMdHrcYbG/6SLJyVZzffSlsyy6Agx8yfI4kT4Tj2ho64wxso9z95L26KjL70wgBC3s7gJMIxYg0MA++Vi+U8tn088n5N9lum1PHCPv0VMUeo5N8IT99NYuZrENLKAl+JKNJUA2biaaZchbemWlnj2XnEbFnDWOJGzVYJsTygce6ao0WmJwClMdNcJ8R1kYO83LRbjDa7WDUPRA5zcgQwa7GE2Neeoarev/3w1DzHLtYLkrL54rUN4Tye6XLTNJhP5uGX+i+aFJUswB9HSu4Q50ADjU38f1qOcNvVM2nDFzaZ+DIX/T6MMmF8vtSdvUSHuLIpEZI/LlXoWQFOglggCTx1WQQNpdQXzVJ8p7mWruon1iYHjA4DvXLTWy/TJwu+wZkc8Z6xfuJynlUYr1fk6G9LLyLrO58lDAFoCSSLXHZJMldB74ILuiUJGvSdEgY77UL7AnerLcfbUg414PS6G4bNsk29; 4:lc3v70VBdtY2OOwMOc07RVSYAUaXiCMMjvUrjEwENd/vfzP/RatJTVMFNDB5uZyy6C8Mi3Os21p1pRyNJtlwsWt4c+uVhiD+5Ge0qRpkJEMvRtGYVEM8YjbNhuEaCXY1ZuRLS1PXqSxfjgen8I9FNqZthE7top6Ss9//Nz6mqC3WB7HK/YsfvwCzWPvmWUB6wfcvg5dp/oyY2IYgH4ktAtQOIePLimbKRjUqD0u2NlpEj18Bs4+RzHw1Y5KosBeCWcr5ti0kl3SIRMCkD7rc6/y0qiToL9SxI4Qi8eMo4P6XB4kHk/bOKYmg6uhuqinaIUQqKwfCtFFrYJmEnYwEj35exiJ+bnz7Waaz6tSBbyJCgfKIvP7/O5UIo0ZoeJqPX0uhWc1RbDw6l8FMJiROOg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2512; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(40764003)(110136002)(82746002)(7846002)(7736002)(42186005)(8746002)(305945005)(36756003)(81156014)(8676002)(97736004)(50226002)(81166006)(450100001)(23726003)(101416001)(230783001)(47776003)(68736007)(50986999)(586003)(6116002)(3846002)(83716003)(189998001)(4326007)(33656002)(57306001)(86362001)(50466002)(106356001)(46406003)(2906002)(229853001)(2351001)(92566002)(77096005)(97756001)(105586002)(66066001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 23:WzvHHJ+SXkHiAA4gHnpnrmpCQtyHC9/RVcRMTQexG?= =?us-ascii?Q?gj6jPqdELwsU+1luH9yrGLjg+8XqUrF4Xp+aWBb9Sn1lh2sQk+m8/Lz44/gN?= =?us-ascii?Q?h1uu6T6xIKPSRC9BaE/X8d1iWHQWKpS0k+BLIGeMQV9rVirvqJZRbv7anYYM?= =?us-ascii?Q?5WyDxOfgZw+d7MPgqz48n7yp8RkcApuuR2fOgsoTMYtBvdqG6hx0qzSEZo+k?= =?us-ascii?Q?znaC5BLoEIAiFJiZJNsUKys7dXe2xAm7v/rwki1+WOl21I9GG8ivmw/PRpKw?= =?us-ascii?Q?z5rkXuxdWC3vu14yqQ9l1BGvV2auTtQFB8KWiwJXnUelu+Ept9kMtFN0j07c?= =?us-ascii?Q?5ArHH+FLvVRYRHpLOPOymAb4WEnYXFL/ZN7QUFZMtLqapBsXWdablnz3THm8?= =?us-ascii?Q?sXeprdgtfyZpuUH5RHwHmOiLV7Hi0xujzzw0+5c7x3kh8ooD7Puom9rUJ2ay?= =?us-ascii?Q?B12dB2yP+7fYrt1TDvA3WiG47rcJNrRdWaaDisYf4MKpYB2F0dNXXuIHE1MC?= =?us-ascii?Q?eKh+kh/xdhhOmBtxZwF8x9TNhK5fNYRqxBBx9bdyKGTkfYOB/DoHjvrhfvdo?= =?us-ascii?Q?m05rXMc6YWgRjzgXUEZRau+Be2fh63kV0A3Yj/TG/jeA4+1Yt8qxvABTh6P3?= =?us-ascii?Q?go99Mw3OBSPio9O4afSQGgWXP/m57Nxx702sqyb/oCluDE1rMMK8TQJh3hZP?= =?us-ascii?Q?6QYamA+plLyNC7ACCRPHIf6OJ9qdzNXYhYHe7Nif09L8bUMAsn16PiFRVXL7?= =?us-ascii?Q?8URQpq6Ty/lxZAFlkfEN6Avy6DvXdsegB6MdDATk5twwNTwV1zZfLTsThovc?= =?us-ascii?Q?tfmWVrMGWCLJJhJOCP+gzZMM/A0guW5Pr2Vl3qZruKKELKABZB0JyjOV0Rop?= =?us-ascii?Q?f2ZBLyJB0VldZj2QXzWmLNmr6UM3IAkozUEpSWHrkCWBTYl4rg5MJBtfZAqk?= =?us-ascii?Q?JhlmBqGiHczZc9LZKiJm54NkHeVRG2T3cHJ5u1f872fw/c58Ecex7lKhXnkJ?= =?us-ascii?Q?2SXcXtsCkYtAyxFyVHY5ZYjkTVCPjiJdUkwbgcfptL+g7x6GosjGfrJVCPap?= =?us-ascii?Q?Aj/CW7ofiiDm/M4qWu/aYlgOfnOOoGmlgbW5RkIyscT0ZdjHDN71+qAFw2CE?= =?us-ascii?Q?PZEZMywrXiVEdBW5x3ABgTcbSHFwlydQwcTz2/PEumqI/AqXhRqhRvSJbkou?= =?us-ascii?Q?XgcR8W6zZUQr3E=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 6:O2VjdGjCJrMq4SI+WIN0UZfEWGpFr6UZSW7PbhjSWv/Dl0G+D4L7yDANtJEuc2Snvlzcw1p2y4nOZ0Rq3UwIjkhKlfAHdTqlpCFjGUo6d6tcDnRkk5gZjgvGFi3mKB75XWDbFzSkyh1Nkyzm9ZpPw+GDiRwF6/fROLjPAwM+w1oJ2/uLxy0xTTrczprZx9JwRPfQJ89YldtbCAEKt0wR6mWnHNkLS2pCbWdtj7cv06/Ktv4q996cbqttS60BZIXYu8VXdLEWU20SYUbMP1ePDzXQmeK5HiKZ+byfQlnYe7cEjyAHDY+hv0j+0eYCqayshWKvIJhdqWPZeRHS0uI74Q==; 5:BV2tW8fG7NqYJSoEZe3L5yKiz2UhjinHu0gWMJpJmThQcX8EQEVWg0Qyw8tQc0GHJ80bndVgFM5ZG/grvqdf6S+qlNaKM2nWs7YPAPTbVI+QJCjpo1vGYez91CQgAWHTWg3QOHmXXCHVPheCo1XoTw==; 24:0/j7doRV4nnGr5B3zOQyDkNkBKFsMAcy60GJiB2rHuBnOM+B550V33p9Cn08V3G7oq1BgfRscURD1uqEVw4BKLV04/BbDrHsW2cGuZmkLWI=; 7:03YFzeOpqVLZS9/8po8G0U1cx789WMUn2UbJhHsDuCcQSFh+toiDGbvwW21SsLXAcsvHyYVu5bIN9O6COuXrZmrxPWuOl8jcOMQ5JkNtiGiFM1+eC83wevZsAMow1nkqdgnqhygIWsn5/yEbAT1DrK7VpyjtgeZ4L/bML7Wb++hrxD0UMJsu+srfko9nHOGR6ozu8mQaYeFhULFM3SkREzhAnM/4yvpQPA1EnDUCcxQmZLD5guobu1dr0tx1vgUd SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:49:38.8362 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512 Archived-At: Cc: spring@ietf.org Subject: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:49:46 -0000 Dear Authors: As we discussed at the SPRING meeting, a second working group last call = has been requested for draft-ietf-spring-segment-routing. Before we = begin the WGLC, please indicate whether you are aware of any relevant = IPR and if so, whether it has been disclosed. (Please do this even if = you've done it before, thanks for your help.) Please cc the WG in your = reply. As soon as this has been collected from all authors, we'll start the = WGLC. Thanks, --Bruno and John From nobody Sun Jul 24 05:50:32 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A4512D105; Sun, 24 Jul 2016 05:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1DTC61VOwG5; Sun, 24 Jul 2016 05:50:31 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0137.outbound.protection.outlook.com [104.47.37.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0051112B053; Sun, 24 Jul 2016 05:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=55LkwK+lTw/F4/XFAwrCQ3D3uuQAivF0nA/QtlQkG4U=; b=g1xd3xbe1jp/2cXw/TsnpUVYP8/evG8nqInOsx5lu8mJXE1RcLvWLraOKIf4MsTBGZ65le2PWwLVBq++pBOcZdCaSpDQGXWF6vqLHoNSewJ2XGvzSOVkqYgX6mLIp/QFd9U+NqywznChdJn/aY+7atSvjCuwCpTS6Yun8DHQXIY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:50:25 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2016 14:50:20 +0200 Message-ID: <5E9BF5C9-9E90-4243-8CD8-DEF19164954E@juniper.net> To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: AM3PR06CA029.eurprd06.prod.outlook.com (10.141.192.147) To SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) X-MS-Office365-Filtering-Correlation-Id: d682537a-a28d-4c41-05c4-08d3b3c115b2 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 2:cL0wBxsO4t+9Dj4KYqNGSJyTmBuNodQN3J7RLP2lRGP2qsFzT1M/ubKjcwRQW86+piH/zgQrUkmGAw6TNnGjZlZNVmg2EzfutZEK8eLzYNFXbmpGia0Q9knMotB9hzUFktqSppJMNKsDNDTcXJTkU1JQ/T3SeL4qf3yIcSgjgQABtrZyU7HjUZygei5DqGDv; 3:UhR16GE61moDRk4bcr5tK6frUyjItwNRF3s7d4AyPHCIV807z136UM47AbRhxzrYBUqLmiaH+SdIATeZF/TnshRfQVrWdX5L4sVobVOfO02KLSwfi6C3F2Dcx+UVPkuT; 25:Sy/W7xsSSn+QUdw64SKzWNoL9+KjhQKo0teyG98iwI94603pEg6P9oOpG68/asMnhssB/sfw2vlpel5wKZ+sE61tMUdq8wYEBO4FZXAIJMrmAl78mXzNhT66czyHwZg5yl2Bp6JuUBhehiUBhk5UEZks4HJVEJ0nkn3VY6qNYiOIrShfArEeOGy0/rVbESkfnrRpA/hzjtKgtGDplh3bBGqHE6qS4GiMjIgC4WwEtLan2KuqaLUT6GEoXtTjgB/Qqu6jsoyoD/wTp4it2IoFq08x0BtIfCZHG3h3NPAYcX6eih6WsAiDSGt1b284ziHH7iJ1vHtgS3R2TuAX9oJbIFPFS+8kxGvG6Q9c74WCsa+iGR4GsNmE0BzWQY4WmbXEUCDgxDB0Lm37eTZ8Rk22thbgyGTyeCE4cRDyATUtXXA=; 31:AXM+Z94mp7a13NzfimWvRFL1wSyYbZllHwQmFiDFVPU6Q84dFrddUsGTHaH9SdSji6fPySpfPPxQrTWKzLjSvdSTdZ8xOTZNhtv309pdo7FnpioDCKfjJ8nQiNd4jffMkkyBCz/ondH9+Y9eZAXW3IEVxrXlfRSBZj7wbun/6bOULHvR2Ucx7/MsqR1ps1M436JmMSkLK8sVIMxp5LTS8g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 20:jlNWaZw0rH4iyvpzOD8DeFX9Z37Tq0vSGG2il0R3KhU1nxRVW5UypumwBD1oZiMxCqJg79T6qZ5Ym+nFf4cF+vNTPZ/iu+GPNhGno9DWhzD4LFimEGioDV21++DKPjQ6nIsokOteJwvXS+OZc5V++yXJrOmlSYn9koc4AuZv9lAQzZ96j7nwikG1TcePiDu7gVSyVZhTOcVWBYHEe1MgO+A7Xlch4zYbfjvxZtTWuo+vX6MmORdk8N9EfGK5r17PIYCMbcicqrFCLsqZP4pzO0HMe0q9iTGVQHeR1YILH33yxJMujUjaHHxrD3j15IVEGuD647jzo8SVpCw3w2GNqhPNWLJvwlb4yX2XhJ6IcUc9GXhAqUud0AQkZPREul50VSFljM4LZ5GtKiY9mpUvQf9HDgEg1KaHGiDHypZMJ8jbui8v0UhwKAMI0AWRIU+bW9+r1XcYVfYaTSiLNbfCvL7OE3BR5uHyA4ZO0wVCUzobXm52XLvKsT18TNcK1Knh; 4:dFiQlnpYU8G9rd1vGVoyZrP1wN4vCvlN55DqNSTXmHpCeNRBrIfNOeq4ar4ilvU86t0DFvfK123tePWxhoQp6Oz5dS0AaMIdrC5BMGYA1AnA+l3TZiDHeqHtzAXnG8C62RFjmc/zmgv9dKcNi2okLClPCaoVMGtqGWZ8t9Gm4knbGYaCFwBbBaeclIaE1NBGHk5sqFxatUDo7SAjAvM8Lk367+6VtjrCFa48Y9A+agCcw4T0td63ldYHz6/4ccQdUh4g9Bx0WGwL0zLW2IkOijJHL9HkbS5/ZpOqJTdHmZwBi98jEH1omSebgmb9lDMn8DmIYxVs89zigrFcWU8Uz0rZc0HyhZFH0TSJoWf+vq1rBACvU0nDrEvSoZ1zY4vTm0ZQyTpp82NFIrCe6aOscA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2512; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(40764003)(110136002)(82746002)(7846002)(7736002)(42186005)(8746002)(305945005)(36756003)(81156014)(8676002)(97736004)(50226002)(81166006)(450100001)(23726003)(101416001)(230783001)(47776003)(68736007)(50986999)(586003)(6116002)(3846002)(83716003)(189998001)(4326007)(33656002)(57306001)(86362001)(50466002)(106356001)(46406003)(2906002)(229853001)(2351001)(92566002)(77096005)(97756001)(105586002)(66066001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 23:HzMQ3B+PvVZF380dU5AKDd74iTuRnMqqJDXkCicIT?= =?us-ascii?Q?j0n5CI0sydyOanLWY82YCMAqISAg5tZFC7qNN8lT6+Ed7ocF9c994WYsNVow?= =?us-ascii?Q?WvBYVSFf7vKC8HM43VLT6RrK5otcb1l0wdPYGHbmQm+HcL2KnHFjsaiCH4RW?= =?us-ascii?Q?1AZnkaQ4g17K7JsfRvc0kGZy6adN//IbOgb9fBbITD+i2QPp+ums84+i11Uv?= =?us-ascii?Q?3FZV4NiG8QmUtEyy7Bp3zuS4rBnSygIMwDH5LPfPV/Ilh2UdoDeiKDi/Coxd?= =?us-ascii?Q?1wb0DVsiM5L+6+WVSUt6JFdRwq7z5UiD/yG4qCiZB1htwepyrO9VJnBxXSYH?= =?us-ascii?Q?iOgqygehqEAazF375IrnkZFt1vBSVrsUj7jHYcuvYNIk9yzxoYPQj7LM6XS5?= =?us-ascii?Q?Yw3l3Om3MsHuPYCZy8Q+9xw42oSIN+AJ3fsksPiyi/oJArmseFD72Ws7a7n6?= =?us-ascii?Q?Su8aWD2cDqR9XoMAzgDKHS/VLAAW/WxNSBoBR+uJtRnZSdafQSD1qgLvGY5L?= =?us-ascii?Q?pDBfAx7L4x5vLtegX8Q3mN4a6+SSuD342/s89zJap29v6YhCWu6yFJjcq2Ih?= =?us-ascii?Q?WBSF2hn8HnHk5gA3wA2r+ysMAvuKiBE2M7w5+ucW0Hvfy1sVFq1gZxMR//pR?= =?us-ascii?Q?2PqFU512miqYoHbUmf+W4N6VxWHONs6iiH7dl6ZyNyWmytng6rdqcvbKtqib?= =?us-ascii?Q?7Ydvr81y811HzbFueeSf8EckakmzurF8Hf6SddRo4I+W9PgD75pRM89WJEuZ?= =?us-ascii?Q?5qlJqWX+lvjpUEpY4RCYSABNZWDrlGy+w+hBALHeQmRgNuhiRSpSWbLFaQ2o?= =?us-ascii?Q?NoXV5rEDNjuJO5BGP4zZl1lo3YjWg2PTqgqXfrmEDJZRIZiCmYldsDmq9urI?= =?us-ascii?Q?qwHsVcOG2qTtxISTPS/LEprT6yWV1uQCqcLzXkpfWt6wYEUPikeaGgrJiFXv?= =?us-ascii?Q?pLfygJQxx2GvS8ZUSfI8O3MfzFZPY5jznNK1kVGTiaNxw44Y0tg3gzpDm/aX?= =?us-ascii?Q?E6b/In8Sqt9hicMRkFtxBGtaGZf6rLrAr3c2uhoROyiDEc0Fbh65eC5yx4n/?= =?us-ascii?Q?2LACDqjtPU8n+sX5/m6mRpt05OX4Qi78+mmxXnROrIS4fAUIlczoGF0RJGss?= =?us-ascii?Q?SKkb2M/ZKdCUY/91kT4JnExnBJMOrkRkRdnmsygbQ3wicdfZ1NypQ5Y31vaC?= =?us-ascii?Q?rrqbeDyLb7V7sQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 6:wlDKHgPAS6yELs6kF7HY+gBW/mDjphgRmU38RH8iV/74M6c8HLRm7V7sS+HpWexhH0n9bbFBvQlZ6tgR6N2+QKpfw621qixI3sYKDvh6AxipaU+G7dwmhtQuiww09Z8WgM7WsOv5bxmdliElMhG7r48HRJNktFQGDkRr3A7TMo1xFDBRk/RiK+3UlKM+4VRRA9Sx9HFCxlvLAmbvP2nzSJyRLsDPcL/wgjuiyUGAznhaDUXO493TBrFQpCODImRL2O/wVunwhem0y7d+MUHryzqMb8VAx7cYqLN5GDo+ebf+VKOV8YfUTuQgD0V9oziJaWMFVbM3KZZTIPtsrScUQg==; 5:h2Ve4CiiJYO55IP6ZyodBlKDnxamO3YXc084aMvnYayVGA5rjjy3ydyQNzPQI7J1Qtwglk/MdsG9Spwo1/y5/HfaOj2FWfkEaBc9v1O4Wwbg87SUPCEsXdE+LWkE0DGFiPQ/SDc0rfvsIkbp3EoRtg==; 24:lISRCZ8vP3Dc1Rln+dJAQYcVnDmqcT5zCTrihpjCR4MI42kKgThakZdxuVQKgPgJbVS1ui5Zn2ZJI4wMWF2ttOboi1Wwp6pLOWlealX2gz4=; 7:uD1hIQdBGMOZtwum/OQC64ZBBo2gVCwGCFpbx6haN0dgHiR34VSCMIwURn5ialxGliPmFyu1hrmC/qE6jvd4MyRxhl2n4FNeDJap/IB/Zf549fAH1DhUk6dcziB8WbDXVrgjBVpy3ezg7Xz40Os2+unscWgTZoKuCgFOoho4GDXiev8Ea6yNHG/xrBLBnz++EVPigpKbIy99XLeseG+6ppMqIWfIF83GomHbc70smu8wc7dMr0E+1s01LxB63xUr SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:50:25.4142 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512 Archived-At: Cc: spring@ietf.org Subject: [spring] IPR for draft-ietf-spring-segment-routing-msdc prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:50:32 -0000 Dear Authors: As we discussed at the SPRING meeting, working group last call has been = requested for draft-ietf-spring-segment-routing-msdc. Before we begin = the WGLC, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. (Please do this even if you've = done it before, thanks for your help.) Please cc the WG in your reply. As soon as this has been collected from all authors, we'll start the = WGLC. Thanks, --Bruno and John From nobody Sun Jul 24 05:50:56 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5D212D105; Sun, 24 Jul 2016 05:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiYQUXMmF5vK; Sun, 24 Jul 2016 05:50:53 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0107.outbound.protection.outlook.com [104.47.37.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0D812B053; Sun, 24 Jul 2016 05:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8zk+GQg8JVkuwsmp8tkuKqumSaehbJxPLJKpW4GQDJs=; b=dzBwIGH1Qc7heRWC4EDQj5C3eG3wObkQk+vBrjyPZcJBITpiMdaeed9XryreaPZ83DTdidkgSH9CJemTsQwoBQAFXac1BhcaO+y2DEmU/Qsaq72unYk5D6/uXXvTxCOwrxHaFoHSb53P4PJ9RexXLyUxjzfxwGzdI07I81oDURk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:50:51 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2016 14:50:51 +0200 Message-ID: <3CCBF587-3720-4051-BCF4-3597E587E575@juniper.net> To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: AM3PR06CA029.eurprd06.prod.outlook.com (10.141.192.147) To SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) X-MS-Office365-Filtering-Correlation-Id: c42ad44c-5099-434c-f068-08d3b3c124f5 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 2:uEo+1i+mULjzKHAHq0bdCGLNy2g5MzsQSd2WZiM0bF2dqLKHMD7rKrqGCc8DAic7ahef60lNyUsDa6kvpAWUC9L4+JgMYEJDgKG9Xy/KapGVs/GQbQdPeLwk1AZZKE7F5Euo1XOJZXiuobnAXolYmTJX2HbX8L14U4LMlcLg4Lbm/6NexzsJdimAmn0rFmWt; 3:MUbYKjadyDrfsFqBdfcNzhBsa8HqkBXXUEPLtcqyl3MQRlFiueDuAs3zvohuSdVAIrXZrJUsfksryyTrEpz8nuMTkfs9gVXu+N4iIKx27Cftibxrm4o5NQ65ei6qEK2H X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 25:3FWTMPvKkfxtofVRoAgL9VYWw997vJMZJ4/+jn9EXAEymcxV6xLw1muvQx0RgSSohnjByjwVz29yoy24UoUf4yn5DWVa8DQlp9iQtvmKwUaB5tvWIr5yoG084EFsmlfb2EtKp8PuKGBWtWiGU5yDNtosgbUc9MBQ0UTBFHF3+h+3AFM1JHJ+jUm9jQ+UpVylM1X6UcI2YKlRy5ByQRYvBS+22ZaL3A1MSjQc17ak3cP6lqjKkZf6E0XVPtqeM54QnWkpOTaPFGJqbZk6wDgj/QGnHNaHTiQ3bxCvDOJUXKfI9HXtu5sC4eDNDaXsKaETsTeApVHd3bSj3POEQxTVHeR7PNmWTHsEeEuLMwokNhToVpcN6lMkCmXxbs6imV/2Vjrvow044v2YUND9lwObIfFgBZwpFNqF+QONKO3Yn6HHzjEn0fAZLVsR/+e+xK6c/Ncp9nyxfBljgUCuca1O7LgTQFqCLfQM+Iw95KD0732+/4696vjkIRc/riWUtHv3M674B+Z5K2AKyRv4ZV7lMexMf9yOo4EWpBEwT06uIsTMY04bs8FQjvHZRYl2xcFjX8XRVDTzZzKmdgeL+8PdPExLcHxeEQZ8hbEQUw7jPEtHV79Sy+CSdooFpg/e0F7OL/lSc3t5NkXYjUTRGiww4PJ/qVSU1chdq/0+h6lljM/htJuMZPByt0J1lKZG6H/EHp5eXvhJ/Jx46JMthaAwQw==; 31:3SwjbcktdhNaIanHWOn11Pz9knPzWDmjw+E6b2WXAfd0j5R1tlGvEVn97OBhhi++53JuMYcabali/LoiFdOsieNUIs93I+lbXj3OyAFkauMxzVXgh8TTGgiceUh3xjwy/B4Rx0Lsruc2EY4EwRJk2N8C5KtHDYdoUy1Jtjt9zdiqSHyQE/VQlDan89MSDccg1/hbdAAhQx40hiX6nq+1eA== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 20:Y82rSkQRgAKScu2ElPPfGJvEEINcuXKStagRTjlPdlX1gNqq0a+ZntAVkWiNpILl/XXVYjvct0jJeVHG6ya4pRvad3V5H6N6/UHy/g8Y+vvL9or+xtBy97TtIwt0Ixr/etykL2al+xutQ8RE9SjIdTlRXM2lbEUW3ZESUASraHH0vre52xHv9MNXzLTjP9vaCZQDXgZnH0GHU1YgpukM5ETZcTUFxdV1sL5AcnKEzppY8F37Yur7JXKuQOsftWEXGJCx8pDBCBUmHjsUqpxvY4drLzzluJLRx4I90AhV3ndt5tMi1OCCou6pQQUKrwrUMk4zyNNG3AhKog7pbAycYekAdhFx+U4GlojCqZrIGSC1uBxoUDHNbqJ0Ur52mebFNpccp/58jUb/PYvfd5g6s/TrHSTxOVzzCL/PdITHaL5Pt6C/5eCzeIKSGkjlZDn/7nxVygwtCoQ+AcHGGMZVSdmcXwsQvOPVGuxVGNWzJOKDwW7CJ0eZDOE0rEqKIsDp; 4:mouMmA4kHtCjp1sSAduiMKKQlInPpErFev0pXWKQXJXZtQZfAXE+CYl3n01KxYbU2GRP1wx3y3kIdX+BC+rLZp1JzeAfY7Vdr5AmGAwELPaUrjsc1GFgLps0oQ0RuCp73CZPRCY7nTs3+6w8g7g+bz1Ulbl5Ll98U/4yapntrtOaqwoMpS1IrqJYudYgkoZmqCHLeSk5ZqB2Ddv33p9iKlLnXMT2iqcetc18q2m8FWwb7BS3ZFmJJrGPEsGf+1/b1E9NtFa+RgiW9mwf+/pme35vymJe4bXR4YAiGFq9+0+j6rEVJTw5a30wGO9EQwwj8oy/nCfqao4fo8+/Rx1yVFGpvxt2Rmmaw2ccW4KiE+8YyFYQFXixpFPfQSVJWk00hbV3Ieb2IjSp+EhplDIrbQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2512; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(40764003)(110136002)(82746002)(7846002)(7736002)(42186005)(8746002)(305945005)(36756003)(81156014)(8676002)(97736004)(50226002)(81166006)(450100001)(23726003)(101416001)(230783001)(47776003)(68736007)(50986999)(586003)(6116002)(3846002)(83716003)(189998001)(4326007)(33656002)(57306001)(86362001)(50466002)(106356001)(46406003)(2906002)(229853001)(2351001)(92566002)(77096005)(97756001)(105586002)(66066001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 23:8DVFaLp5/f5kmGPzAbnPmuoDgec+KUMEilSKUuDQE?= =?us-ascii?Q?WkXGf5T0qAyayWOCv9BGO55EuSAOFu0M3yvKx2DufaYo26gO35ybUozoPNhc?= =?us-ascii?Q?uB3RNV1Rrg8V4MLhv2Fy9xY4oTD4k90TlTHqq6Phk5i4Iq5NcNIYAXsN6ac8?= =?us-ascii?Q?zzDhGojo/4k/P0z3/e0mozliiE1rGJOh3MWHWygH2DlWRKR3VwBsfvnjtB5p?= =?us-ascii?Q?xMuHTPA7CZ+DblqxEQR39DNXBV21zPwiE20b83KlnV+CweuEttlsOgqEJVLt?= =?us-ascii?Q?fyTSlrH+m42W+xkr9ExEnrGYovXta2jGHnTINMjNWFgVznww1gd2qJEjtDQ9?= =?us-ascii?Q?706ZKtLZ91glND3U6weBEKKmt0jAat/LrS9whOzSBXa1vOPX9pRLHyf0wiFU?= =?us-ascii?Q?pkWmhw2m6alUeZ8fbKDUvdLmdMvY5TH4SMNvIWrYIUHQ0C/8gz7j66+sMv3D?= =?us-ascii?Q?TJDHOJc8yq5D5RMGgNg9vVJ/q7xjrZ8xE/K8QaguMAKFY0TOTOy2kpUGDvog?= =?us-ascii?Q?6Cy/ejTNSDNerHMDz9/I6JMrGvEiBx83OueMJtWG2ZPeKJBCokcrx+gVn/AG?= =?us-ascii?Q?zcPdSnNiVIuFDxjd2fx7sbVJysmYjnLmhavITkuWYPrcAHUMeLvBeLdyQExs?= =?us-ascii?Q?mQdAeDZah/LYuepWAtAHY3Ao2F5rQCjDCmhwpu8QUP3KMle4Wpie4DUhDyso?= =?us-ascii?Q?dveSI9LRIAntoe33w/No/wul4gj8EM/Z2OwidGbUDr8o2lj+1+wk7m+vTWqs?= =?us-ascii?Q?VFvFk/3m1yF80u+a0EqvhMneZSLNIi7iAD4zq/oP0ebVeKaaqdILMsawLOkK?= =?us-ascii?Q?3MprRcgCeYcPpmYdN1S3VN8ukH5LF+I+4K/m4nq9uRM5nIZ9i7xSiW1Ekr9s?= =?us-ascii?Q?oJd0HPRRKqkKs33flawTRDljbyVR5zAmOvwpo/5/Gn1yOIKuEyFfY6ctCpD6?= =?us-ascii?Q?l9WP9AYTnnQz8ZY6917Cm9IT1QUyBbbg4gi701OkEY/xPs1XOmKT2x2zFArM?= =?us-ascii?Q?6a4VVF0lNPksWtI3oQVPp+1ZGnaJVgGY5JvN55AD7s6vW5DGBgK9DTkn8WLi?= =?us-ascii?Q?tXv1GaLXuMRgybnoqjrnFW5tAh9QWG+rXpplNH4YMwoglGyL9A80DjvtxRdM?= =?us-ascii?Q?U2Pn+3MersuiFsRbth/l5G4FO1Fk4S3J/Fa3Do0vrECTpSDNaunr1J9Jam2s?= =?us-ascii?Q?Uk1+VmjFrna9hY=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 6:ssrToueIkpeY+58vJMuIvQbUEW3QB9zpzfLnbAh6Hy72zYY1GBC/cCzDqCBFMyKM9+wiCW8JBWDsgRaHkx4/dRVU/bmhdDPT+j0FzPUXqFRkqiqfnGYmz54RcCz3KrWwYiJk1Cs91B6QHe54m8IEyQqfzmnfjtnaRz+WjanZse4ubGxcV4JyyiCZDcv3y3tO7bvNzf2dI0WDpHAp3nqgHk/JXSpxF84qpfjqrYUWQ6jHG8rBupv2OUNe5oOhI19f7iDk7y6+mY/CNkk2qLvXRAx+qjYztFWLDuZNtiQuaFPxgENPJzhOV0M2LDTsOJrde1Lnm3o+nwcNLHQRgWpI1Q==; 5:awY0ftFHtKnBIg1RmWPV+2eWC+s9bqqvBYZFYAvBS6NBfqkyxjS7Vxd3DyPy/VHMNHwM2hx1EeYbpUaZV/Qv5uzRBwMKz1CK7nhfBiwIFJescmbPDSvQ30d9LQgWViXAlKLBHLBWBt0fSEObew0NYg==; 24:BAOY9SqTvl+POUqfroH/E2nvm1wMUgjY3rJ6UTsCpX4Q6V22SI0R5wfS+izLRoWbXH7R7//giwPjFY+9LsIXXdCc4qcKiqYjAwO9rCzxebM=; 7:J9YUAbX6/BaGHF21yMMBAqDX2zWZhFJy/dGcfUsDRgyDjxp9eNZvF94jmK36mvhlt2wMnB1UKCW9eklEwmmdb4O+U/eQb+AbtonpKNf4Nn5h+jBezWKJElGl6RvD60+hKPFV0vQpwvkKYjp4HXQlee3CC81DS7cHD68RtFN40IvuBNeiy4tMIE2d+F92Iu782A20mXp5hA/9oFH2mxLyVG8wDKVSt2hCEZ+MZV9XaIj2sGLFSCT9Y/w7xar4p6mZ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:50:51.0332 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512 Archived-At: Cc: spring@ietf.org Subject: [spring] IPR for draft-ietf-spring-segment-routing-central-epe prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:50:55 -0000 Dear Authors: As we discussed at the SPRING meeting, working group last call has been = requested for draft-ietf-spring-segment-routing-central-epe. Before we = begin the WGLC, please indicate whether you are aware of any relevant = IPR and if so, whether it has been disclosed. (Please do this even if = you've done it before, thanks for your help.) Please cc the WG in your = reply. As soon as this has been collected from all authors, we'll start the = WGLC. Thanks, --Bruno and John From nobody Sun Jul 24 05:52:34 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A58412D12D; Sun, 24 Jul 2016 05:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxBiOT2aDR68; Sun, 24 Jul 2016 05:52:31 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0090.outbound.protection.outlook.com [104.47.38.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778F712D105; Sun, 24 Jul 2016 05:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aAIvNUMD+gdpv+H6wUtyk0qBDBn/HTtJOaIE4gMFxeU=; b=VrEOK8KTBiunTzVQUEy0p2fJDOGIYlpfZnlRBOxc9JNoJldDKIdujLZ2zdoYHPqocGOO0d3HMgU27VPjyOcPXqJWstfaUMWxzIOZZ4dgk+/DoH+Gj+90dKu/fDgJVV2vpBB5jhAQ+Av9AEuEW/5kx39q1QljwvdropXEJgXZYzY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:52:27 +0000 From: John G.Scudder Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2016 14:52:16 +0200 Message-ID: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: AM3PR06CA024.eurprd06.prod.outlook.com (10.141.192.142) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) X-MS-Office365-Filtering-Correlation-Id: 6fa3a9f2-e604-4ab7-009d-08d3b3c15ead X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 2:WLyxLgUcfi7mC3aFDuWtNTZ81qFaMl/brUpFv8DK6DfaIbRXtNWIuGxXUD5BAtnFiv6n22v9JAAqOJr1Y0ii7hWnzgcFdKkE6HTotwZCMDYaF1R9160AygP7io2KL+f2f0+kHpgQ+aIoKDL2hypb3RB41ztYlvB5jfYrloTm9qBCWNHonfmTGKgeiTUG/lK5; 3:dSqHI/jiKW9FutRqvERnUu2ory9zgu6j1XEi0+ARMxdzLnZtB9sHH/WjTMUZ5wxe+vC3nWeS5VFME1pTw/iAV3kFmAUkgwB0N41YNe3uYJ5VKxSQCIsIcW+ei3NT+v3J X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 25:82ZO7E8Pk+Oy1nVJWjBfYKbF0C0YckQOPVQoLczi6aQluV1npDFiejA9LmshdjJnKZj+5wJ8gOODpXNuj4vUE0h7lu2OjzAupKNp5t8TfbkqkUdIJMAHPY9MadxiYi61hRNI1RLdYogIL0zmUMP9B2/5PKFaXUJPIDntKuoCPHepjfPJrb0eq1NlW4+27NJgS8ySYieaAAo8Iy6OK3jwcFMmv2YCvAlfzSzv3K83d+giAST4S1+287BcWIZ+1Gb05DQROiiX1IZIXFTQn8m0URhT3QNuY50R+L5AYmux5nX+thTv71Z3wJFtckR5vOJ1e1v0oQLg/FiBABtCLZeHm7tv9omt/kMIe6lS5pDYrb0MUkvoAES9Xif04h//q+I72fQCKaKeHv/kQvAWe8+4MvHlbxIAW40Mk+p5t1Lg34ki3NRtix7dGqyN1Edno0JteaFrt+FVtedRnjOccbwM5XEI0VRx8ZAnaoy5APXXD/cKU45s7bgnrT0vbAiA1QwvNKJdupGxbv96ng2N8+WCCXiMv4scyZf2Vly9gDiroaz4V4ldg6pkNBdzKn0fI79l0ri4bMxAd6rN5OTP8qMLvHEa392Wb4oe8JhgSRjJwmZN8kTabwA9O7g2X6jaDxCw4SwFbwqXom/u+O3GiLOf0191Eu0XOaG52szkmd1ddYVTxFfNcOXhQ1ozHDqZ8eO6; 31:SuVYlQTVJTBgAXFXoZ1qvAoQESgf+QPuxvtGB6kfCK1DymyUEcLc9KiYApIE8sZaq2yZ54BNdb24pVtGGAeyE3Gd0anAQfjxQFtFGc3HhEaOcWIQ9NDisBIN8Rnm0J4NgM/Ag3QmYCUrvVI9/XFt2QZ9z7yQdtq1hY74WxJnbE3aFTF3kjPGBCoHL0wW3cuGdk/9uoBfVsETbmrIRl8VHg== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 20:OaDFr/It4dsPa9e0KBP9A9yzt7HxaxeeodO0ooD1ROuV+YBnY/9B/oTgqUwZbLZAOY5y4g08TCi+Nmy9sNOPumALEKJp8OqAepG9uYbusbbgQhHiGXLg3EF3bfQGKdge/uK2a0K+PWjNB8p227FRUR3JpDu8Atst9/lPMkj8oY1x22HB7PzpXuwK50vRN/ckNxu9ROOl2hRd1LgzMOSk99fRJwlL/EECwcnoReDUsaCzoVUeppnmTeD432cJqV9dSVUvcx54habMAC1jtoJ7tYgY0zZrfXv5KVwJLaJ0coiRQETGNzO54yepIAVM47vAEJP0btDkLLvWfNaj6NcpSvTAIQj9LwVjycDdFXXj3GUb+t45l2ZhXnDqKBrZzHPeOWEy0MJUBylsbOicajwKS5n50SQlJLAA30WOv5DyNRbQ2nXbaH0A15GEzQ15SLaan41X8e8K6Eoz5y3uyoRBddbJAW9XiV5FVG42W7q8qmtBUEb0OO9Pybi6GbtnCRDH; 4:PhMw1cjRvY+30K8ZZ/PNzWmCJtPGxuon/AcbdI0mv6Ag+0eEZ5sgtbp37lP/9C0m6OE4hiGAqt2POdZaAlZBYB8HHH94aNVFXMbM0TahVT5r2V9DPsr2uxLPbIlmtHIXVMysiweJUxxnvVAish6YDspPYzg3FTvHcj/aDEqEV/5c1qvTz1N/NoZGi+xrGqs9HJ4pWICAHFg/byfV4f7ZIHrjp49HxF7AxnI6qAyYUTMXl6x/GiwWMdnTyDHLz15qH7dfPFLoSIWQF7ji+eFfdUuIYTt+vx+Oy98RwU6aEFvAgjHNl1cGOsz7MpC0HPWT5/GtF6ZrCkRRatQHv7IQ2eAipw1EzOnRfiGCoa4EALcdnXprlTj+UIWkL1TFA4FgeqBNSqvU1BrAcRTDeDr1pg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(40764003)(199003)(92566002)(110136002)(77096005)(36756003)(50226002)(68736007)(4326007)(47776003)(81156014)(66066001)(189998001)(33656002)(97736004)(450100001)(3846002)(23676002)(2906002)(586003)(6116002)(81166006)(7846002)(50986999)(50466002)(82746002)(42186005)(83716003)(305945005)(229853001)(105586002)(2351001)(7736002)(57306001)(8746002)(86362001)(230783001)(106356001)(101416001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA1OzIzOmtVeU0wNUk1NzNXdFR6clFoMnZLY2xzRnh3?= =?utf-8?B?ZWtGSmJYcDZmVysxaTNsODZnVFRRTGx2eEJ6RWlTUTJZZ01Ta2hpVTJQYi9r?= =?utf-8?B?TW9Fa1pHUzdqMkE3VGNhbmNyUVFtRnREdzZGdmtyVHV1aHlQdTJsZjgrU3VY?= =?utf-8?B?dU5DQkI0R2JOL1doK2pGaTJtbU1lUlQzNGZWNFhycEVGRXhSZEx0VDVEMnY4?= =?utf-8?B?Q3d3aHh0OUhwcUdhUzlxOCtHU1hmUk16OVNLNmJJUlhxN0Ftd1RSbEFXVnpE?= =?utf-8?B?Ti9IbnNRZjB2aHo3MlF5enllcHBjWWhSaVI1UjZENVdqODYxeU14WThYNFVS?= =?utf-8?B?V1VmZlFjVnpxdnI3NTBRckgwTHNIYmhVY1F5bmVPbHcrZlV6ZUthMWg3eDBX?= =?utf-8?B?aTc2SUxNVnVwZTBYcXVoQ1B4MGxBUlF5NWJ0a0JCelhoTlg5b2xtS01ZdDFY?= =?utf-8?B?MGE3UnJzTDRTVER6ZFF0SEkwYmVkWVZudTBFOTR5TlhXV0d2RWZRMEd3Zk9M?= =?utf-8?B?NU1wUmVtZE1rRHZoTUtGQ3RublhiUytHZXk5bmRJZkhlbDVrbEVveHNZaTlk?= =?utf-8?B?R2Y1TTdZZ1lNbE5Zei9lLzJPaExrNG1oWkZwTlBwR3plZWJ6RzlhUU9ZblVN?= =?utf-8?B?bnNGQWJ1SjlyZGtDQUNkMEF5bWF2aXVTcTBmQjRSMHAwcUdsQzl1RW9kUG04?= =?utf-8?B?NlJYWEJCT0JqU2owU3gvVXlWUnhNMDJrbWVpT1o4OERSWlc5dHdueGZ6OGtO?= =?utf-8?B?LzBndkFTWVMyT2kzNHp1SEp3K2g0MDJqWEJSUEVCbVZaNTdkcXJGUVFjdmxJ?= =?utf-8?B?VEdiT0owTUx3eGZRTHlhVTF0U0xMWkF5MWEwbk5XczNwOERndXVHOHJOYks1?= =?utf-8?B?QVVBQ09CYzE2U0Q0TmdWZWlzbm1yRURxMzVCUktHSjQzSUxPY0pFdE1Xd2lI?= =?utf-8?B?T0l4bTJSM1BKeVB3TWwxd0E5bUVUVlh4cmE5allncDQrYVNzZ2NVMHFvSzF4?= =?utf-8?B?emNzUVdpUzllcjJNYS9KdFFXYnRtQjhUTEt3NlQ3K2pNS1pMV2JqVEM0djZE?= =?utf-8?B?TWJtalVmM3BaMHdXa0VUYW5aU0NsMUV5ak9QeWdjaWpMUWhFYTQvYnE4Ykpu?= =?utf-8?B?YldzWEwwYUJLNW9lTDE4YnFFZnZrd0RxRlpHQzhweFhJcWdQRDFPTlFoVmpi?= =?utf-8?B?cXdVTXovN3hqektVemZLTnNESnFnbDN6ZGkzdFFmNXFCNFZ6c29wc2RJdWRJ?= =?utf-8?B?eEtzUDU1em5jNGg3c0ZYbVkrZmRENzdhQlo0SXZIMDltTHptNDVYTUNMWGZS?= =?utf-8?B?Qk44UDJHYndpcE1TNDdVZ0E0bGtob3htQjhyejhxYUYxanNFZHIzUktGUUE3?= =?utf-8?B?WUVkbTNabXBNckMzVXVjM1JJWW1rSlArajczaDJjYVVkY25XcTNxaW01K3ZK?= =?utf-8?B?MWliSW5GSmxESW5lN3NlZGZRLzFsUHVkOUtzOXg5bTZNM0V1cFZzb1pNbjZU?= =?utf-8?Q?5jhuz64zRpSs3M9Z3gI9qeujo=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 6:ragy8RsQxgKImcRM3ECc9ldZ5/DKDWKW0zaHU67Pboc/zI9IxXv6jAwgcae2KMswGhYXc7WMPWfOG1dYQ3BjfBpVgPhFro5i3wrrCM96AL1oyHoFAlhwVTPHjV7s4PzynJY13tp7G/arFOhExgZcbZ3mo8SzPQF8aPAZrpOhG218SfhZf+jjLrGbE7mpdaew9E2c2eaPKLtcbONMbXaUsBKyAu41Obyl3mEiNaVXcgxG0Vpp5d2Au77nh7UUE/L0eSyt0ikSxJUle4srl+enSrIGU4XDYNS1+sqGZ1OlK3L2MYFdla5p5pow4MPcmidk29gPY/O+UhqGcHFpTjEo/Q==; 5:CfmZRsg4Td/Jy9QeN3Fufu+hDPQS3QowqxS5fXj1sFOBcBnVM95dy9thw0LcBf1ztB3m4RaHY4w1Qab9JqKDFTzptSxVrg/5oUCYrr9J3EZGAmqF/n/KCqPN+jXAwXZFu8e/uW5n3i358wjytnvwZw==; 24:D588muzDHhsuwkfdq7xfvvDyV06uzPsEh1J1TdiSzagL5KDcBXdgtIvPlXAYuVfV5xhbJivNrryRqEdtR1u1gJi6funD4gHrU3VPM2wAdqY=; 7:JbTR5h8ioTaxGp0ULT20uy+deFTS9RHEOAxvBI3f6OKXeBEoVK580VXur0c0fGeWMm0aBuMLWdI8j47y347TNPrUFJ8Ub5WDugw7L02ugZjrm2Hqo+wZLHvP3vYWQgHZzEwAuJrjmCwBwSyCKelTVFNBKrOIv9pIjrDK8GPE42KnBNRdmY+1j1bZTxndIERu9Be9LMRZZz0RlFrva4pFJPnSM80iHPmGmsbEn5eRXOKJvXoaj+OFUPzfDwpxLXlH SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:52:27.7939 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Cc: spring@ietf.org Subject: [spring] =?utf-8?q?IPR_for_draft=E2=80=90ietf-spring-segment?= =?utf-8?q?=E2=80=90routing-mpls_prior_to_WGLC?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:52:33 -0000 Dear Authors: As we discussed at the SPRING meeting, working group last call has been = requested for draft=E2=80=90ietf-spring-segment=E2=80=90routing-mpls. = Before we begin the WGLC, please indicate whether you are aware of any = relevant IPR and if so, whether it has been disclosed. (Please do this = even if you've done it before, thanks for your help.) Please cc the WG = in your reply. As soon as this has been collected from all authors, we'll start the = WGLC. Thanks, --Bruno and John From nobody Sun Jul 24 05:54:37 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E0312D12D for ; Sun, 24 Jul 2016 05:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4Ly4rXmlK4v for ; Sun, 24 Jul 2016 05:54:34 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0093.outbound.protection.outlook.com [104.47.32.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10EB12D0AF for ; Sun, 24 Jul 2016 05:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ui69oSHsJM+R0h/BNctzbg+epF/UUl8Vnsdz6g+0/hM=; b=S3NicCkD8ar4n6UEiiKc+xhAbPoZlhFoWmYcedqMao2vb03WQ924g4mAoFCqfs71mCX9noplMEXr2JdIGEbmHZmD70r73wY3yAMWAJHJNxEAjpFJQ1eke1H10sV93b7eThAag/HSzvxlx4uPrzajq3GnAckGdnJRWoQyM+hpgPk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:54:31 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> Date: Sun, 24 Jul 2016 14:54:18 +0200 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: AM3PR06CA025.eurprd06.prod.outlook.com (10.141.192.143) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) X-MS-Office365-Filtering-Correlation-Id: 267a48cd-0137-403f-1aa2-08d3b3c1a82e X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 2:E0AoqdAcZhfKX5As7r3Zu5H1r30R9XmEV8Njo9gj29lUMWqpA/zeo3CGWQGE0bDousadojlLkxTyuCDe2+XqISzEToJPZxUxcA/Af1KR5HMRxGheDz+mW0s4a9olci9CWu3Hnt/kuEgKOi34tUziWwWJw32io4YEdYiKXM6+585n4kSqUc1QKUrcmedJUgrk; 3:ydwJLbZXaV++6xJFRNAbVHLCGCS/6U2/nSOex2GdoZHG4YsgP39gx7NdGumKvoOgGT+1k/Va0f922YMJmAya0kmc/+oPR3PAMTMJK0RujqtqAXWsJYHnyIumeMFmA/KO X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 25:3xfjaHxkMNrCbZLoyFnY8NtI4R9NhcoZUyWyU49N2+n5lp/9tvHkuXMRZ39KE4FJgsjS/sswaLKyD4Ge8pdrlUk5Lw6Sca4iwFZ1fhVUzWhnwL2gcZ6e7/fMGKW1ROvry2tJWChs85iZuDQiI/uerZaPn/neUrjW2IoG2ePDVLi+YRTK3yI3EjUKhmk8QmNtYJk5cUfrcbet0HQXBNKv3kIK46grPtOb/MvZj8LVvULs9E1zwNVYzKaAx7s25XaiCscoV5YtTVuJk0hi8e0IgHiUJIHvpfURkyM3hl/esZ1vz7a9oid7AVNXRRcUrLt3Xh7f8jVWBUZIzx+6Gjh2UeLIFxwICNmu7/rwcC5I4PdIEBcH8iZViCJVDWlBnS+jQ1oSSBMFsNyyoC51PsrQHyMb8XPsZcVKvj/66hz+qyyDlyCMrBukVZ00UNhsn0vHTK17NUqv9KHk2pnWKXP4XODKUpmQ735yDSHNAf6BMNIFULk280mXWk8hdudz+yNVjE2MFOLCIQR2kA4ZxACfftD9ltE3te0m9VHLrt4unB7J/6rhh6M6uEK0/AbfajP7OL65JBR3UZVTzf/rQfbU4BoRaB+OpVWupDE7nRzQpgHXfsXExtccI0TxHNI7XZDWAR1xpPT1Bh0cV1RcJIyQ6DIpUps9SSIkGgGuIsUF7A3brDY4BW1Gm5u1MvL6fFJZrzMakH9oObr7i0nQ+mMCug==; 31:vevhLg18O8eSj8YVVgKNJIIjE+NCjH1zZYcrLyaitzt+1FY/bUdfgOQJQs15crSfEHQ/P+K6Vkcqp+23fJhVXcEoUSXfBS7z47r3SdNU1lIwudyxRk8aGkKCHzzcD9lwmTSQM5X5IqVkWOrLSst+K5ctpHIJhzOERPnKovtLk9n5fqceK8mYyoGHPBsFov3YH1RveqNXbLCSHphnA/UUtA== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 20:iZqj/PVHg4APMCPVj3zRxFwQxz6gNpDTjbJUqmulbyXRyg2dvEyILUyHH4nOoiTcvxQ2wsMl1CVV7JPtVCYGV5jo/7n3go2wScO6RcFs7Gp38eQbCppF2rkmlijLrd36RP+sRPyT+j7AKWHh1tTG5/MuvReHPFvqUL4B8PFtjxCba8PAbCy3zEU2T6u/lYuv6qwv7Tma8NRHSBgLtuO7Ne0cptphp7uuDNAuGC8jpVEFav+xQhv0+hdkDPb3vGDH5jghzksCCsIAct3PpIH4h8L9T4oXfW16eZpWlgSAAacymfg2DX+KkizK1E9+ihqHq+/dhxVPnJaKZInrKOBEsoG2rH3CekFAFhdXdJxkZUIXE5UOLuDpNyb9ua5Lw6pMkgSFMI5sUXGjejRW1AXwqLsdOMSqzvgHfua0x4S/FnRQ2bGmlsqsK+w/hi0fw2wS4Nu2MUAD+dLNV+yaW3u3VHxAC7DNMgM4Iiy69frZLs8zIkRpPufUtHtlEC9MPFN3; 4:XJsnr94boE5d5K0TPFoPB/G/P35xGbkExydIg5fmJ8OdwYiha5cYQubn8ETLe0p0BCKnj6godWdvprMRtjyq0+X9ZRqb8bCsz6CjJAFszZHIv0AjOFnXKwvp5q/icw9726N/80whFhJDm4J81c5bV2seO2jyCTCvvT7QKDrYmpHT6vzlIaBQOZLWc/W+v8Twh0v0TFZm3YHNsub6IfOmjntoB6S4uqGoF0PDaPa2Qf8N+O5z4NvsXjj7VN7O6nH7ZziN0AEEh3PvCBkqfG6WW9+dNG4EHnSWMJTpwmfIvJfkFYXdIsX70qk2JKOVW4yNNPMywPTnp7tb8mUzK3upzMfLcPOtjUb96SYNiPj2BnzhMg32DpU4YFgViiyXVDmxLj5OwtAJtW+R4Y9nJ+TAHQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(36756003)(3846002)(50226002)(101416001)(23726003)(42186005)(7736002)(2351001)(77096005)(92566002)(229853001)(6116002)(586003)(97756001)(230783001)(305945005)(105586002)(82746002)(7846002)(106356001)(83716003)(86362001)(97736004)(50466002)(2906002)(450100001)(8746002)(47776003)(57306001)(189998001)(50986999)(110136002)(107886002)(33656002)(66066001)(68736007)(8676002)(81156014)(46406003)(81166006)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:10njgL8Y4aAJy0rCobhbyyWf7fiyLs1V1ongPB2I2?= =?us-ascii?Q?0sOjqW6LMln6HmTMQeRCguXK0d0xmVCoM0YpwQ/QwFwA2xRUOyX4/0oi9JBA?= =?us-ascii?Q?lEf/p2kQ5XDtc1ebQxv7dPyQOluEBdbf6YK+RKBlKAycIrBRC1wFd92lpBOV?= =?us-ascii?Q?XCjQyRFKJz8WFN6doB4UMo5Z1DRd6esOmfyN2oFfJCXxu0iCl44uey+J1tHs?= =?us-ascii?Q?jgyam5GDt9cgKNYWmjVt9AWwQH1zJ6OYrAe/cQAOD7IdCf5/XtRAN7m2C6aq?= =?us-ascii?Q?gOnhENEK5rYr5JzKpjX3F2nbBy/VNp/ohSq25R8G8QFyM8oA3jeMuDWN3LlE?= =?us-ascii?Q?vNeQ8LNXeloT0G6D57X/IPOzhJZyL0dK68dJn4pc07X8kbGcySFbBpFDwe05?= =?us-ascii?Q?bTMQmCZ4vvc464Rk7GFN2NBDcGJRMwCryiKx4EFsG3UwDoDuepm8ebgJrE12?= =?us-ascii?Q?Iff5FYikVhI7bUoprWPZCcy3FXoSKpFmV5sPrvLePfEcrPAI1wxzHhh4Smzx?= =?us-ascii?Q?AaGX61k14O0wMxj89UX+FlMUdRJIGYmnBzYo6T7uGQ/2MimWDMV+UIm8/8LU?= =?us-ascii?Q?YBsIZldsOW8JFQXY3bNRgftQFQUqVg9FxUJdqy6Trd2lBueBslGLRpuodLDH?= =?us-ascii?Q?2fPgZIzG2IutbYN7w/rZ3QLkwFLKxQov8rpJPjo7nr1o3x/SWb3IvDINSiUf?= =?us-ascii?Q?mVbKrDYF3TQ9P7viUHw2uZpeFbhPvCWFMbT9j611K2WU+gRCdwc/zWNTb1fO?= =?us-ascii?Q?xrSPmQcdxfPWDdna/a46/j0VrgpCaA1bLJbbYm3AVEFheXc4N5yE7c/LC2U3?= =?us-ascii?Q?/vdoKwa9gsMl/cNvnaph7vA0KZDQC41SUUL1caupBh2wbEuxjvC4eajDZR2H?= =?us-ascii?Q?wlhspDCOrFrVpsGshG8iS6rvnXYWTlNaXtWX77U19o4Pgirf3lvAXEjuXEnk?= =?us-ascii?Q?hVldnNYoZUcyOhLKr8sNzf9Wp0OSn5w+3saTLG3yL3reswUHCbX65VboBuMU?= =?us-ascii?Q?QTlDARqhOiyXiMCzHi5V7KirSUsVYKaXn9/qisWrh3j9QN3OFqUqlbBmvnAm?= =?us-ascii?Q?jGx4vtxLqiOBa3lMcT3OBE54HoDs8k1Pp8hOrhhRkFnMyf+C3SiJFkpL7l4h?= =?us-ascii?Q?H3Wc4efrvVL1eRfq8GY/Qx/u2U9S6Lr0dVXvI8olq9QnNAv2CdR4g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:MqopVQ8+q7PKJWfuhkIgsCGpQzzvTE13HtGC+IqvfnxNg30BI+9W4cn+fI1kQGImref2i7LFsfoQLmw0KnoUyU198HsXjb3a/OMTwEWmILLt++ao5Ca7BLEPjVerOCh5lY54mnscueOXHc6Bj8AUqOqJuz0F4ujLYq64X1ji8sAYrqGHg0uuVmSdWr10dsyUvl6XDmTbPu+o4FeP497F7gjjBLldOdHG/QHiAiORYB/zSWdZrsDeUpgeD7SD1fC6YUqvOlFHS1g+MJgLAe8jxk4een5RZ/idlOINxjTbVr0tfqm+K0v5h6zpPlQXrxQn6aW7tFY/zs41JNyrOo307Q==; 5:Tl/cggora57Q5LqY2sBFyGyiAYm3GwkTzcL3+a6pVAF+EKc1IzqE0RGB2w9AnBghgfEXdoPmx3dqRZ1yNUDlCRPiw5XQ+//2vCVUjjCjHhdGYfxgjETVQRkpUx+sZwQABlH0zQIZ7GmYt45yDrLGLA==; 24:IkmjGy1+rr99NiiQfa/4jXWpDUmnc23BjVDv/srsU/Rs+s1c8lnCAiJnt38JEM6uAoA1VE71FeLmGeUUFBE+hwZtSHiIWKfZvKKampz9Krs=; 7:S0UyTw0X4IZ8MZH5dRi/OImSWccEC42COkvI4BcNolTuiXw1P9IrFIGiFXAehhVvG61lpBuL+FByWHkO6FZgyoxkSWq+rIUOo/IKkYoDxYXzribqwSgecz9fstd050AlBfGDFQxFSirFIBDld1rXZRtq2rJ4n+Hko7CPWU0PwYHnTYu7SaZLKcKJHH12C42jqPmg2VDoJYAADO7FaZnSUoU/MQ7J9d9Gl4bD8wq5gokpdNi0r6Ofq6U29+fbN8FX SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:54:31.3509 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: Subject: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:54:36 -0000 Dear WG, As we discussed at our meeting, working group adoption has been = requested for draft-filsfils-spring-sr-recursing-info. Please reply to = the list with your comments, including although not limited to whether = or not you support adoption. Non-authors are especially encouraged to = comment. We will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Thanks, --Bruno and John From nobody Sun Jul 24 05:56:05 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ED812D14B for ; Sun, 24 Jul 2016 05:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtUPADMVPj9q for ; Sun, 24 Jul 2016 05:56:02 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0095.outbound.protection.outlook.com [104.47.34.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CB412D12D for ; Sun, 24 Jul 2016 05:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S62ebibPEtOz4bJyxOVcTEYqq/ODLKWWQ3PfvZc2vIY=; b=Cpwlctd497GKZFnLDWnXPHdYagIKLUQhhlUBbSjx1SQGS+DQ0UHB+mGSHZoHq5MyWoPuK21OvoMBvgZ+IX7rGOhwZeaYrPCY3PNy9WY1IuvHXc0cR9VkmBFL/f1Tim54uV4B2kHTIkoz35hhGb4bbXYIfomOtGn9p+1z26X348I= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 12:55:59 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Sun, 24 Jul 2016 14:55:52 +0200 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: BL2PR01CA0018.prod.exchangelabs.com (10.141.66.18) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) X-MS-Office365-Filtering-Correlation-Id: 9819f10b-b31d-4da4-3c59-08d3b3c1dcdf X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 2:NxMMVD6E924kyv4fXnf41YmOq53h/butW/WPmj7mYfsupE5Bkl6pMFlYC4OelPxUcFXLhZsA/hk6rryoKruHgvsg83nTHX4gfL7yyhHTqBYordPiT/2z8YIYI3+SqWDJOR0FvIsm8D07x2+XIruXG6xalfwE5CE8bAI5WluChtkWCkQmuLzywp1Aqi2bUULl; 3:a8Gt0AoFFMkEXzgYgruaL73O7TLN/V9mPwKKUIP9YrV/wijBR9J86g3pkZoCWOa3sPHRPOEKfpftE9SD7SWgQqiG+qVKre8579xL6Wac7fk1P3042G+5AQh7G+cn4xdm X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 25:mwrMyGF4+n01EaXaEb/cP75WeWZtNj2EhbyXtwt0r/nNMd28+Pn7CpHYbsgZyG9H7YDo3sbMUyaeuGW+JFTjbYgbdf28cRflSg5olVonkUNUU47+543UpyRArME+my6q2Q85EC3Q+mUheszAC3AnJmJ8kKDV08PwN0lvVdnmdz7ZSKJ6rmpez/LcC3GxwCSOp4t92V724KijoBdyQLRYIIcpkZR8wIE0q7K2YnqCwG5mUMhvGkxbQ+n4/45dkM+f6lnRxbKOpsBEfEECWQjP5WJwLE3qyDcwJHDbQx63L/IOhEQ2pv3RO8hXFiwZdYvlfNka0XoLrpxfM3R1/SfiNc0nmDsC917wBBPJOZRGs37E0iaLn1uAqtLIl0GWZCyrpOA3fzd/D20O/N5iNCDbwuIlN13Lc2EJzgD0S5y4NSe7b09PmRgjIvon6IVNDNjjskCBMXQkVHQJAoaAPUCpVGfikInWnWF0GeYvfN5ZhtJy02SVtVZxK+yAr4D3fJVfAI24x03/nvk4BkqpanAzXQfPjVD9++IojCFQA0kYzWWwGEBQAaxNavqAB6RW6aWahc8PAWXdbSS9/dqroAqTEZ8+mYZPHm5OJ7tlelDZzjxehIWR8JiFJl13EzEDPNfpDJBujWYDOQqB1GcvFFXdOlIfmv/NnBPm7DXdUWoGEjI9KlUzoySM+nFHWq5dDbMPK9fqq+kkhLJiDigm7YDPvA==; 31:AysuroDFRKPgiqBRYmdACzyO2p6NGePHEJWFiJNvxsn7jkx0vt9PBX7OuPq3b6RWXWW+A+wYYuHBTzMCbtDiSvezCPDVuC26MYKQFNpsgbKbDK5QE9UBqAt7mkHUXgSmOf8uem2ous3x57o0NW0jp0zYfiCPXzDVRnQvRW9Qm43VDxxtlLSlIblfvqspGLyk7qlBUioPV1ebrN8dxQN9gw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 20:f1yY4TwM4zJ4KSECOSgT99wqvMLQ94JY8LdT4Qtcg3dCvJP7wI/P08u1alj8XvhN/wS674RZdwDBqTKEx/ut6e6alnguvVUVV6A/nPxqzuXgRVWlnqUPupMVTS0q11kfiSVDoOv8d3yaJT2CjADYAjdCOxKmfZqgm3fiSpxsVPg5VnckjG4DTzFfJyV7YGUSKwLmI8DjdZSkCOHmLjtsVTJla+ZU6Su4NpOv3AQD9nNePHoSf2XECw5ZZb1Zz061pqzU6J+1ysWelvSyUSppIJfL7um1Ghnxps7eWBjcMFD9LxoDVx4Eo4wvewu0KYEvCF4wzlS9ZEE4A5SpIJBqopJE6YxLtd4OnL3jvmkBt8u9iwbcKUJh2uyykFRdWdckh9xVgp6ei0kODfHb7EPIJ9E4xQrdCz1H+6y7HeDfTtK6hs3XIAEb8GNUNo4GsRDQkmdSyGgFy4jCd0QMCGV1caqda5W1ys/vcg7IBdwhqY0Nx44K9YMuJJSOIKyKWZvF; 4:8yG2mUQLJssxu36KadfOfpjCnm7Ldy07z02T0hU9R08Fo2irHPhgtlBeF77JI22W/ver5bkH+pnIn2rmMQjpb0/WzHyADRjVKZ4EEz2/vVCMCo0SMDO7O2cutoKZG5lB7cjrsj8hJ5dvpT8AdyB9044tfrWXujvnTlKBOKGKG5K/6l56MnVMwjtPhKX/8DEKfMLtUQ7KExu7n08TLbFSjfGbfCKrNmD3AgGikv9b8lfVnl5eK/MNgbU5JIgEE4IeNDvm/5kBAxOh1QXqjfR5cDlzgBBO2W8AD5XEbr/leu6MmVSa32qZ5cMdJzVNa/yxAKy4XcwQxs8QVuZAfDNaJ4GZ2605/zavNZ7lSitPypaJmRkxhfuQOpc/9U15IMVDbSxRW4/uvoaH+T/0IQWWoA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; X-Forefront-PRVS: 0013079544 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(92566002)(110136002)(77096005)(36756003)(50226002)(68736007)(47776003)(81156014)(66066001)(189998001)(33656002)(97736004)(450100001)(107886002)(3846002)(23676002)(2906002)(586003)(6116002)(81166006)(7846002)(50986999)(50466002)(82746002)(42186005)(83716003)(305945005)(229853001)(105586002)(2351001)(7736002)(57306001)(8746002)(86362001)(230783001)(106356001)(101416001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA1OzIzOnpSMzJFK0lPVzVlWGtpVGpJWEt1ODlLSFhC?= =?utf-8?B?UUN3emR1b1NDbjBRcEJxQ2U5NHhSWEF4YVh0K3JHYWxuNy9WKzdIcHU5WVdJ?= =?utf-8?B?Z0ZmR2NVbzdmcEJmTWdiRnhwczRiVFBWWkhlWTRlTSs2RGJKZHBPYk1vYjR4?= =?utf-8?B?eUh2WDIzRVJVU05oYm56OFE0SjNTNnBydHRIdVZKZmVRcG05WjJLYU5Nb245?= =?utf-8?B?WlZPOXRJcEFyYkg3QW1nanp2UjZqK0k3RXNXRHZ6SmdxMEgySVZzOVo4dzQ0?= =?utf-8?B?bk5lbnpMOGlHSzMzT2I3Ymg0VjV0T3RjWk9zQXE5TEIya2VKcmw1SkJXUGhl?= =?utf-8?B?bDZuRldKNFN0NFBhSFNiT3pmQzdKOGo4NjdFRk5hNXkxMDYvb3hNZ0xsamJa?= =?utf-8?B?M1RPK2JqTXBWeXBVM0FYcnhGSEJYb09HbzQ2M3E1SG0zZzRzN1hlcHNQcGVI?= =?utf-8?B?R2pMTzgvSlA1bzVsNWFSaFJKeGdmSmk3aHJLbW83QWdGWC8zMHBoT0lPbDA4?= =?utf-8?B?WExLcjg1WUJqcXRaaWZ3ZXRyalpVSllwS2FxaUNxSmtHaSs0Wko5OTRFdWJt?= =?utf-8?B?TkZXekxTNWpUVHAyRi9mM1dxNzhYVTB4KzVKdDJoV0hROERISzY2TGI2MUpQ?= =?utf-8?B?dzRoK0FyMGxOVytKV1JNaW82aGpSQ3lOT2MwOU1ZZkZXakJLa0tFWFE3eUxs?= =?utf-8?B?VTRGeS92M280QVhvVVBYaFdWTlJoczE1YXV0elp0czl1K0J6SHpGQVZ4L0pp?= =?utf-8?B?RTkyRzZqRGR5Lzc3MnlUTXBJMlNEVlUwdStyWDJ1bXp5SWlMRnNVcDBqYjdD?= =?utf-8?B?VXN0RFd4SkhpN2ZkZmFsWVZBZlY5WFFXSDdKWEJZTklMS0NpVE1aREh1STRi?= =?utf-8?B?K2pISzBSVnl2UW9PVUVwUytML2xpSFdEKzUvWDlLQnp4UlA4WEtNZnFiT2o1?= =?utf-8?B?aEpxdmVkTmxMLzZoOC85QWRKd3pCWHJmOWVMTHY5VWNkcGJLcG5ONUx6WjRi?= =?utf-8?B?SHMrRDdnRWNBc2Qyd2dKNGVtTUMrOHM3SkxBWHFPNXUwSEZvdGk0Z2FTMjVK?= =?utf-8?B?T3ZtN0JlYmdMdWN5cVlBQ1QyQ29qUFlWek8vb3dBM2w3R2craUdjSlBDMGNr?= =?utf-8?B?ZFUwTFM3L0RuTmM0ekhpdkhPcCt4QmdJMGhBeXNPdEtXamNRREpEUkM2SEhy?= =?utf-8?B?OGpnNkR0Uk4vNjRzWG5GM3daejhoZG9RRWpiZWJQTDVoL0FhbWtJaG5ZQlkw?= =?utf-8?B?S1dBWGNJM1lRWE1GbnlmOTBNanJsZXBNVHBYTTRCNDh0Vm9uMVdlMURsM1pi?= =?utf-8?B?ZSs0OS81N3UwMGY5TzJVUjZWcFp2eUJhUzZmZHVrU0NZcUtpK2Q1SDY0dFV2?= =?utf-8?B?aGJ6VVhTMUtOUnB2ZWxBZm1wcU9lVW5NejFtdWprOWFteEJhQzlscnZtOHFE?= =?utf-8?B?RXpjaStoWWRYQmR0WFFyNlBpQ3BsWUxpMWFPaDZvZm5EL0JYRCtWalRRMDJR?= =?utf-8?Q?XCX04icxjYk9n3gdA3OmLM4D4=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 6:ajVN78n1HXjXu/RqRUnLeByxeH+zJ+R5Ux93HvYGwOY+3Xx7hgHH19XvLGVhks4dYgZhoDibpizeKi4E+pw85rOR/GYVZSmSKkKlsRe4tYZ4V2KMnZbSggJ471zG4/j+9h/tQ+d/3BNMuGB8AuxAgZoHI2ARfz5Z+wI8A9Yq54s1yyAOTdroFDf30lKsdQ9wI1/jxYGncOyMfptX46lLZcUqGi0jAOAG14vksPxOYkMUxXRRZ+BevxaL0EFlDv4GIs6rnPM6+jDE+59OSI23SsfKO+xOR9zjWK3mA3eYnd9a6itCXZIGh6E9FDZVUSGLWeIESpj+DDdeuGhjmGaMRA==; 5:O0AzSx2GvOkFsndrrGkrB5o2AYvFZbcyFG2P7zv5rXTOhCGAa5x1RzHgg61bdUw30Oie4PmqfGyJ0i+fp8iI4iHwMlrmgdm8z1HdmiQYRBK4kvgV2W8svmHkEUGR73vNpi5ACSDZff58siJ03pt0Cg==; 24:g+UC0PMauA6Y5Q1maBhr3tAB7tMk3jdGzQHKsze0aPmbGovu8604t0C3JgwZxAd8cZZG5iBQ7HXmEtSylK1OUmwYZhz5QrlOZxJKiktYM4Q=; 7:eNqDgkgcAblc7HKCxYYS2i/ZAGC3Lyj8f1ZU/RMT/7tBXYtqurfjNXyRPZGOnsx0TbXGP8WXgDT3Oxb7yJXu0yf5ZpVv74ftDxuuQGMPP4dzgatpJr7//vaqa1Wnaho5DthVz3EOGD1q6DRfXjtz9sMK0Tka3zzNNu25qUg62c2KKZ6oaG0AJnFf/VE2CNqTFheTy2zSqNlh71gq7cklw633pzdBTGCnRMHDT9Zs0sdU3GJ7Bzf+kuV3tpz+tl8N SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2016 12:55:59.7813 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Subject: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:56:03 -0000 Dear WG, As we discussed at our meeting, working group adoption has been = requested for draft=E2=80=90filsfils=E2=80=90spring=E2=80=90large-scale-in= terconnect. Please reply to the list with your comments, including = although not limited to whether or not you support adoption. Non-authors = are especially encouraged to comment. We will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author = list for this document greatly exceeds the maximum recommended. Assuming = the document is adopted, the authors should be prepared to correct this = when submitting as a WG document, ideally by reducing the list to simply = the active editor(s) and making use of the "contributors" section for = the full list. Thanks, --Bruno and John From nobody Sun Jul 24 06:10:26 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2709612D1A3 for ; Sun, 24 Jul 2016 06:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItSEmFoWueUC for ; Sun, 24 Jul 2016 06:10:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156DE12D18C for ; Sun, 24 Jul 2016 06:10:23 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 7F2ED68DBAA7C; Sun, 24 Jul 2016 13:10:18 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6ODAKXh004828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jul 2016 13:10:20 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6ODAKbi005400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Jul 2016 15:10:20 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.82]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 24 Jul 2016 15:10:20 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "John G. Scudder" , "spring@ietf.org" Thread-Topic: =?utf-8?B?W3NwcmluZ10gV0cgYWRvcHRpb24gcmVxdWVzdGVkIGZvciBkcmFmdOKAkGZp?= =?utf-8?B?bHNmaWxz4oCQc3ByaW5n4oCQbGFyZ2Utc2NhbGUtaW50ZXJjb25uZWN0?= Thread-Index: AQHR5arCm/85Ix9sKkKnc5w+xfWOFKAnjh6A Date: Sun, 24 Jul 2016 13:10:19 +0000 Message-ID: <2CCF3EAE-8D9F-4AB1-8647-CF5FD4432209@nokia.com> References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <3F90685EC236C0449013ECF263719A01@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 13:10:25 -0000 QXMgYSBjby1hdXRob3IgaXMgc3VwcG9ydCBXRyBhZG9wdGlvbi4NCk5vdCBhd2FyZSBvZiBJUFIg cmVsYXRlZCB0byB0aGlzIGRyYWZ0DQoNCg0KDQoNCk9uIDI0LzA3LzE2IDE0OjU1LCAic3ByaW5n IG9uIGJlaGFsZiBvZiBKb2huIEcuIFNjdWRkZXIiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgamdzQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkRlYXIgV0csDQo+DQo+QXMg d2UgZGlzY3Vzc2VkIGF0IG91ciBtZWV0aW5nLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcyBi ZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnTigJBmaWxzZmlsc+KAkHNwcmluZ+KAkGxhcmdlLXNjYWxl LWludGVyY29ubmVjdC4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50 cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IHlvdSBz dXBwb3J0IGFkb3B0aW9uLiBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxseSBlbmNvdXJhZ2VkIHRv IGNvbW1lbnQuDQo+DQo+V2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24gQXVndXN0IDMxLCAyMDE1LiAN Cj4NCj5BdXRob3JzLCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFu eSByZWxldmFudCBJUFIgYW5kIGlmIHNvLCB3aGV0aGVyIGl0IGhhcyBiZWVuIGRpc2Nsb3NlZC4g QWxzbywgdGhlIGxlbmd0aCBvZiB0aGUgYXV0aG9yIGxpc3QgZm9yIHRoaXMgZG9jdW1lbnQgZ3Jl YXRseSBleGNlZWRzIHRoZSBtYXhpbXVtIHJlY29tbWVuZGVkLiBBc3N1bWluZyB0aGUgZG9jdW1l bnQgaXMgYWRvcHRlZCwgdGhlIGF1dGhvcnMgc2hvdWxkIGJlIHByZXBhcmVkIHRvIGNvcnJlY3Qg dGhpcyB3aGVuIHN1Ym1pdHRpbmcgYXMgYSBXRyBkb2N1bWVudCwgaWRlYWxseSBieSByZWR1Y2lu ZyB0aGUgbGlzdCB0byBzaW1wbHkgdGhlIGFjdGl2ZSBlZGl0b3IocykgYW5kIG1ha2luZyB1c2Ug b2YgdGhlICJjb250cmlidXRvcnMiIHNlY3Rpb24gZm9yIHRoZSBmdWxsIGxpc3QuDQo+DQo+VGhh bmtzLA0KPg0KPi0tQnJ1bm8gYW5kIEpvaG4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPnNwcmluZyBtYWlsaW5nIGxpc3QNCj5zcHJpbmdAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K From nobody Sun Jul 24 06:12:37 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3A112D1A3; Sun, 24 Jul 2016 06:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGD5y7JXl36V; Sun, 24 Jul 2016 06:12:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131A512D18C; Sun, 24 Jul 2016 06:12:35 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 016019C359AAA; Sun, 24 Jul 2016 13:12:31 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6ODCX8I007333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jul 2016 13:12:33 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6ODCXTl006162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Jul 2016 15:12:33 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.82]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 24 Jul 2016 15:12:32 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "John G.Scudder" , "draft-ietf-spring-segment-routing-mpls@ietf.org" Thread-Topic: =?utf-8?B?W3NwcmluZ10gSVBSIGZvciBkcmFmdOKAkGlldGYtc3ByaW5nLXNlZ21lbnQ=?= =?utf-8?B?4oCQcm91dGluZy1tcGxzIHByaW9yIHRvIFdHTEM=?= Thread-Index: AQHR5apGCyQEv17Z+028IXq/oatMF6Anjr2A Date: Sun, 24 Jul 2016 13:12:32 +0000 Message-ID: References: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> In-Reply-To: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] =?utf-8?q?IPR_for_draft=E2=80=90ietf-spring-segment?= =?utf-8?q?=E2=80=90routing-mpls_prior_to_WGLC?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 13:12:37 -0000 QXMgYSBjb250cmlidXRvciBub3QgYXdhcmUgb2YgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdA0K DQoNCg0KDQpPbiAyNC8wNy8xNiAxNDo1MiwgInNwcmluZyBvbiBiZWhhbGYgb2YgSm9obiBHLlNj dWRkZXIiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamdzQGp1bmlwZXIu bmV0PiB3cm90ZToNCg0KPkRlYXIgQXV0aG9yczoNCj4NCj5BcyB3ZSBkaXNjdXNzZWQgYXQgdGhl IFNQUklORyBtZWV0aW5nLCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0 ZWQgZm9yIGRyYWZ04oCQaWV0Zi1zcHJpbmctc2VnbWVudOKAkHJvdXRpbmctbXBscy4gQmVmb3Jl IHdlIGJlZ2luIHRoZSBXR0xDLCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJl IG9mIGFueSByZWxldmFudCBJUFIgYW5kIGlmIHNvLCB3aGV0aGVyIGl0IGhhcyBiZWVuIGRpc2Ns b3NlZC4gKFBsZWFzZSBkbyB0aGlzIGV2ZW4gaWYgeW91J3ZlIGRvbmUgaXQgYmVmb3JlLCB0aGFu a3MgZm9yIHlvdXIgaGVscC4pIFBsZWFzZSBjYyB0aGUgV0cgaW4geW91ciByZXBseS4NCj4NCj5B cyBzb29uIGFzIHRoaXMgaGFzIGJlZW4gY29sbGVjdGVkIGZyb20gYWxsIGF1dGhvcnMsIHdlJ2xs IHN0YXJ0IHRoZSBXR0xDLg0KPg0KPlRoYW5rcywNCj4NCj4tLUJydW5vIGFuZCBKb2huDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zcHJpbmcg bWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Sun Jul 24 06:15:22 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285EF12D1A3; Sun, 24 Jul 2016 06:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXF2-U_9C0u4; Sun, 24 Jul 2016 06:15:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC1F12D18C; Sun, 24 Jul 2016 06:15:19 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 45201E8BE8653; Sun, 24 Jul 2016 13:15:15 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6ODFHO7011011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jul 2016 13:15:17 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6ODFHTW007358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Jul 2016 15:15:17 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.82]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 24 Jul 2016 15:15:17 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "John G.Scudder" , "draft-ietf-spring-segment-routing@ietf.org" Thread-Topic: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC Thread-Index: AQHR5a1rNLM2ky+pykqS+zJeWnQOHA== Date: Sun, 24 Jul 2016 13:15:16 +0000 Message-ID: References: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> In-Reply-To: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 13:15:21 -0000 QXMgYSBjb250cmlidXRvciBub3QgYXdhcmUgb2YgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdA0K DQoNCg0KDQpPbiAyNC8wNy8xNiAxNDo0OSwgInNwcmluZyBvbiBiZWhhbGYgb2YgSm9obiBHLlNj dWRkZXIiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamdzQGp1bmlwZXIu bmV0PiB3cm90ZToNCg0KPkRlYXIgQXV0aG9yczoNCj4NCj5BcyB3ZSBkaXNjdXNzZWQgYXQgdGhl IFNQUklORyBtZWV0aW5nLCBhIHNlY29uZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVl biByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy4gQmVmb3Jl IHdlIGJlZ2luIHRoZSBXR0xDLCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJl IG9mIGFueSByZWxldmFudCBJUFIgYW5kIGlmIHNvLCB3aGV0aGVyIGl0IGhhcyBiZWVuIGRpc2Ns b3NlZC4gKFBsZWFzZSBkbyB0aGlzIGV2ZW4gaWYgeW91J3ZlIGRvbmUgaXQgYmVmb3JlLCB0aGFu a3MgZm9yIHlvdXIgaGVscC4pIFBsZWFzZSBjYyB0aGUgV0cgaW4geW91ciByZXBseS4NCj4NCj5B cyBzb29uIGFzIHRoaXMgaGFzIGJlZW4gY29sbGVjdGVkIGZyb20gYWxsIGF1dGhvcnMsIHdlJ2xs IHN0YXJ0IHRoZSBXR0xDLg0KPg0KPlRoYW5rcywNCj4NCj4tLUJydW5vIGFuZCBKb2huDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zcHJpbmcg bWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Sun Jul 24 06:16:43 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A341A12D1A3; Sun, 24 Jul 2016 06:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znYfWtCbwbHJ; Sun, 24 Jul 2016 06:16:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119AF12D18C; Sun, 24 Jul 2016 06:16:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id F1E1215736B9F; Sun, 24 Jul 2016 13:16:32 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6ODGZOF017313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jul 2016 13:16:35 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6ODGWAg004397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Jul 2016 15:16:34 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.82]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 24 Jul 2016 15:16:34 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "John G. Scudder" , "spring@ietf.org" Thread-Topic: [mpls] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments Thread-Index: AQHR5a2ZhiZbvzzK2UKu/Q/GF3xj8A== Date: Sun, 24 Jul 2016 13:16:33 +0000 Message-ID: <0CC2618F-717F-4F1A-A9E5-C37DCD5523C6@nokia.com> References: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> In-Reply-To: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 13:16:39 -0000 SSBzdXBwb3J0IFdHIGFkb3B0aW9uDQoNCg0KDQoNCk9uIDI0LzA3LzE2IDE0OjM5LCAibXBscyBv biBiZWhhbGYgb2YgSm9obiBHLiBTY3VkZGVyIiA8bXBscy1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiBqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+RGVhciBXRyAoYW5kIGNjIE1QTFMs IHBsZWFzZSBpbmNsdWRlIFNQUklORyBpbiByZXBsaWVzKSwNCj4NCj5BcyB3ZSBkaXNjdXNzZWQg YXQgb3VyIG1lZXRpbmcsIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVk IGZvciBkcmFmdC1wc2Fya2FyLXNwcmluZy1tcGxzLWFueWNhc3Qtc2VnbWVudHMuIFBsZWFzZSBy ZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBu b3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1 dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KPg0KPldlIHdpbGwg ZW5kIHRoZSBjYWxsIG9uIEF1Z3VzdCAzMSwgMjAxNS4gDQo+DQo+QXV0aG9ycywgcGxlYXNlIGlu ZGljYXRlIHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIGFuZCBpZiBz bywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuIEFsc28sIHRoZSBsZW5ndGggb2YgdGhl IGF1dGhvciBsaXN0IGZvciB0aGlzIGRvY3VtZW50IGV4Y2VlZHMgdGhlIG1heGltdW0gcmVjb21t ZW5kZWQuIEFzc3VtaW5nIHRoZSBkb2N1bWVudCBpcyBhZG9wdGVkLCB0aGUgYXV0aG9ycyBzaG91 bGQgYmUgcHJlcGFyZWQgdG8gY29ycmVjdCB0aGlzIHdoZW4gc3VibWl0dGluZyBhcyBhIFdHIGRv Y3VtZW50LCBpZGVhbGx5IGJ5IHJlZHVjaW5nIHRoZSBsaXN0IHRvIHNpbXBseSB0aGUgYWN0aXZl IGVkaXRvcihzKSBhbmQgbWFraW5nIHVzZSBvZiB0aGUgImNvbnRyaWJ1dG9ycyIgc2VjdGlvbiBm b3IgdGhlIGZ1bGwgbGlzdC4NCj4NCj5UaGFua3MsDQo+DQo+LS1CcnVubyBhbmQgSm9obg0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBt YWlsaW5nIGxpc3QNCj5tcGxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQo= From nobody Sun Jul 24 08:27:47 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1F12D885; Sun, 24 Jul 2016 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T4TCwVWo9IC; Sun, 24 Jul 2016 08:27:39 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D18C12D882; Sun, 24 Jul 2016 08:27:39 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id ks6so53346391pab.0; Sun, 24 Jul 2016 08:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZKI/lqOdwOw/YIJj0LaeVFKgDgJND52bia7FzkJtPVw=; b=ii7dQ/Qxe6mPSwEHv6nWoqyoHiEXcgbh0z8ehmyf0Sb402FLJVyErVdc2XEOvWKC/x WYAaIU3icj/ctBvNPPvFwRJPhcvvLbOzn7l1nK+/vNcxi9a+d3Z2xneoMsvm8851R9lq pQ4o9zWxrw5T+zi6AQjHUuA8eGBQsjrGexP+VsgeoumkxcgYDbHmirU/Zf52NKVb6HTB xyMD5clOo1YA3kT1EufvO7cnx8iWq4ObkR5lpnQKwRzF+SFVr2jrWD1y2sy6tWYMzZoc sPrf0kyxUiO9vJ8qR/rVlyvmAABBE3ssCbLDftJqG54DybUAovxxa5lg25/37qmBUgML xyIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZKI/lqOdwOw/YIJj0LaeVFKgDgJND52bia7FzkJtPVw=; b=eQ/nHYvUgMCeSsMq6IpeMyNXGrzf09i6/MnaGROoJxjH7iR+Gur+t2QOvLBXDR+EUe V2j9y42prNdCxuQnPg1y9MEXO1aFdJlH4JYC8uVKP/5ge8m/A4GBaU74oCBgGbyj6S4z uCpxvJ1wtvXD8AF8Ch/FMkmG42r/cDXmnr1GISFP61oz3loTUyG6n4HUq8vOD8X8pVRS LG2VIMIseUX9coEm8BJkdkawdpgxEeSvy96rxAwq6vYmfObRg8kygavMlsNdm5E+dnqD vQZWgcPgrSehK5Da8d8eq6ISH3411UqnzQguTIsh0UuCY15UE9u0kWGw8qo7SZVuPCXg sVZw== X-Gm-Message-State: AEkoouujewk8c1HZx1V/WP+lkU6Kv7zeLsdmbgWQDcwubmBX1H4kiK4Wi1hjrPhluXkgTg== X-Received: by 10.66.62.226 with SMTP id b2mr22215757pas.119.1469374055250; Sun, 24 Jul 2016 08:27:35 -0700 (PDT) Received: from Pushpasiss-MacBook-Pro.local ([122.171.57.246]) by smtp.gmail.com with ESMTPSA id y184sm33438598pfg.94.2016.07.24.08.27.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jul 2016 08:27:34 -0700 (PDT) To: "John G. Scudder" , spring@ietf.org References: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> From: Pushpasis Sarkar Message-ID: <8fec46ac-42c8-2ced-3664-bbbcfa1a15c2@gmail.com> Date: Sun, 24 Jul 2016 21:00:16 +0530 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org Subject: Re: [spring] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 15:27:43 -0000 Hi John, I support WG adoption as an author. Personally I know a couple of operators who are looking forward to some interesting applications of anycast segments with SPRING. Hence adopting this document certainly makes sense. On IPR front, I am not aware of any IPR so far. Thanks and Regards, -Pushpasis On 7/24/16 6:09 PM, John G. Scudder wrote: > Dear WG (and cc MPLS, please include SPRING in replies), > > As we discussed at our meeting, working group adoption has been requested for draft-psarkar-spring-mpls-anycast-segments. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > We will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Also, the length of the author list for this document exceeds the maximum recommended. Assuming the document is adopted, the authors should be prepared to correct this when submitting as a WG document, ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Sun Jul 24 12:37:54 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A69712D575; Sun, 24 Jul 2016 12:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QOLowSzzen8; Sun, 24 Jul 2016 12:37:51 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2B112D18A; Sun, 24 Jul 2016 12:37:50 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id o80so129728276wme.1; Sun, 24 Jul 2016 12:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ZnPQ18koV2JIFNW2xD8PpvwtRNYz3cooC6Y6k021vg=; b=UXNDYB0a6tGDy1vvbJWVNsDoZghx0o2hx6p8jEE2lsEu5Dj5YV4HDo2zhwYORBGWVo YeGhvEHmblfvzvwDFeOO87uQUyrPAo8zFUYwlSkCu7cEY9L3bdMGU6PtXa41+o0LSHKQ 68f8jwECRsRgaTNMtVIQKwhJ96anQUY3m31ScAk6MppCTZ70RPXOEM3RD02GvKpf45Ur DCGLveiWkSLNGg84HuFFV8eYtC3rPujGhgXS3ztNnwRT3Vz+fzycGS6kiYKU7NNCqD1n 7nKnVGhzzKSucChO1SfRWip2XzuFmOX0f/Y74GCtbyEzSFMQ6MMAn6sgJZeu3+y4jWpY AuqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ZnPQ18koV2JIFNW2xD8PpvwtRNYz3cooC6Y6k021vg=; b=Z8HUn6DloZIJeTfkG1Hh4rrrvcyetL7Iys63Abkzv7UWUIP12aOty58yNmD3oScElG BZfU8Iy9FjhMsyIyXgspDixvL7DhRpVfr8NSObURXbD3TIfEyUEYcLV8cUceA59khRSZ zKo11FPOO1xURYnT9r7E3UUep9ehE1hDhVXUEYbb/njub5Fyb5U7wvu7k+i6wxo2aqCN 7Ji9g5NtP4oNtaPMmS21ouEayS0q58hvvgH5902x15YEWQv5LIfhWPFFu1FE4flevKDX jKd2jK4qqd7KlqvS6e5JEpdqlGO7Q7JE9jDd99stRsm6xXv+X+59HyVvff2SyG7txaQv 8M2g== X-Gm-Message-State: AEkoouvO74DT1TayslcbSUi9dXZxT3NwCpxs1GLqxmJqcOzuJqsyE+LZnM4o1+1ebPVmIg== X-Received: by 10.194.80.104 with SMTP id q8mr12719970wjx.151.1469389069073; Sun, 24 Jul 2016 12:37:49 -0700 (PDT) Received: from [172.17.1.115] (132-110.80-90.static-ip.oleane.fr. [90.80.110.132]) by smtp.gmail.com with ESMTPSA id a2sm12006816wjg.46.2016.07.24.12.37.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 24 Jul 2016 12:37:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jeff Tantsura In-Reply-To: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> Date: Sun, 24 Jul 2016 12:37:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> To: "John G.Scudder" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org, spring@ietf.org Subject: Re: [spring] =?utf-8?q?IPR_for_draft=E2=80=90ietf-spring-segment?= =?utf-8?q?=E2=80=90routing-mpls_prior_to_WGLC?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 19:37:52 -0000 John, I=E2=80=99m not aware go any relevant IPR that has not been previously = disclosed. =20 Cheers, Jeff > On Jul 24, 2016, at 05:52, John G.Scudder wrote: >=20 > Dear Authors: >=20 > As we discussed at the SPRING meeting, working group last call has = been requested for draft=E2=80=90ietf-spring-segment=E2=80=90routing-mpls.= Before we begin the WGLC, please indicate whether you are aware of any = relevant IPR and if so, whether it has been disclosed. (Please do this = even if you've done it before, thanks for your help.) Please cc the WG = in your reply. >=20 > As soon as this has been collected from all authors, we'll start the = WGLC. >=20 > Thanks, >=20 > --Bruno and John From nobody Sun Jul 24 15:40:52 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94312B01F; Sun, 24 Jul 2016 15:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JsX3wIfuMG0; Sun, 24 Jul 2016 15:40:49 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71E912B018; Sun, 24 Jul 2016 15:40:48 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id f65so115088362wmi.0; Sun, 24 Jul 2016 15:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mcgdIuht5/POSiS0WSxjbVScFeegHIjZnVA0P7+aGr4=; b=T+puNJPSbHybF8B3w9OQ55BcGJRROXsl8qXXWSrYXouOE9SFzJsSL7KwSsu5mNFiti nydnUxlyRb7YqgVTiybUdY/l2zdSsCePcdFe+8tlw7PdCbyMuxj+TttmkTzjv7gmASm8 lIAPgYy2LANjpGeHObb1uW02XrSHKd5pDtaFKoRKVetk8scvwBpeWw/ge6NeeqoIet4n 50R+976sciFFY/1kg76opz7nGz6W1cXaB+/bWoAuKRLs7X4SkfRU3x8sbDtF+Nr4IwH5 LxLbgY1nmn0Fv0PkujnuUmKxLNok5C4rMuNeBCQfD814AdbXn4Bdlmxi/z0qQmlXQxf6 11NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mcgdIuht5/POSiS0WSxjbVScFeegHIjZnVA0P7+aGr4=; b=Od9Xtzn31OwnQ1FtMaqeCVBICukPDLkU8IjM7X81H2Plcvq+dFwP7XKJce7MAaqUmg FiFxKZMnxgDQtfVUzZO4B0zv/Jrqi66LE2/QVOiaSvzX/r02txM2+Xl6iwNib4nAgHcJ aUC8Aiyh2bjKR7djld7QmvLfMmZoUBHP0pM/2o8hqo9kHagjZFG/VjJmAodhxqxtxjAL TXwmNa2/RQ5L8TwWjkPuKYIObhKM9CTT2cwz5tcN+0GOAze3ZjeljcXlbidgs+vvNrET eAx0x8laz9bU0IeI6fTfWDJ7NmoZVOmwiDAulmushQg9TfWMSEcoMszQtoj/5k3jXCaR QR+w== X-Gm-Message-State: ALyK8tJdP0niSQXytATFVC+MObatyIGV5VCPuNxwiSjLBZf8+/qDH1e9lIPAT+Su6C/WiuYlzU8RYrk5p+bIaw== X-Received: by 10.28.26.69 with SMTP id a66mr35131675wma.8.1469400047323; Sun, 24 Jul 2016 15:40:47 -0700 (PDT) MIME-Version: 1.0 References: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> In-Reply-To: From: Jeff Tantsura Date: Sun, 24 Jul 2016 22:40:38 +0000 Message-ID: To: "Henderickx, Wim (Nokia - BE)" , "John G.Scudder" , "draft-ietf-spring-segment-routing@ietf.org" Content-Type: multipart/alternative; boundary=001a114cdea2da90470538695b5a Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 22:40:51 -0000 --001a114cdea2da90470538695b5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, I=E2=80=99m not aware of any relevant IPR that has not been previously disc= losed. Cheers, Jeff On Sun, Jul 24, 2016 at 6:15 AM Henderickx, Wim (Nokia - BE) < wim.henderickx@nokia.com> wrote: > As a contributor not aware of IPR related to this draft > > > > > On 24/07/16 14:49, "spring on behalf of John G.Scudder" < > spring-bounces@ietf.org on behalf of jgs@juniper.net> wrote: > > >Dear Authors: > > > >As we discussed at the SPRING meeting, a second working group last call > has been requested for draft-ietf-spring-segment-routing. Before we begin > the WGLC, please indicate whether you are aware of any relevant IPR and i= f > so, whether it has been disclosed. (Please do this even if you've done it > before, thanks for your help.) Please cc the WG in your reply. > > > >As soon as this has been collected from all authors, we'll start the WGL= C. > > > >Thanks, > > > >--Bruno and John > > > >_______________________________________________ > >spring mailing list > >spring@ietf.org > >https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a114cdea2da90470538695b5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John,

I=E2=80=99m not aware of any relevant IPR that has not been pr= eviously disclosed.

Cheers,
Jeff
On Sun, Jul 24, 2016 at 6:15 AM Henderickx, Wim (Nokia - BE)= <wim.henderickx@nokia.com> wrote:
As a contributor not = aware of IPR related to this draft




On 24/07/16 14:49, "spring on behalf of John G.Scudder" <spring-bounces@ietf= .org on behalf of = jgs@juniper.net> wrote:

>Dear Authors:
>
>As we discussed at the SPRING meeting, a second working group last call= has been requested for draft-ietf-spring-segment-routing. Before we begin = the WGLC, please indicate whether you are aware of any relevant IPR and if = so, whether it has been disclosed. (Please do this even if you've done = it before, thanks for your help.) Please cc the WG in your reply.
>
>As soon as this has been collected from all authors, we'll start th= e WGLC.
>
>Thanks,
>
>--Bruno and John
>
>_______________________________________________
>spring mailing list
>spring@ietf.org
>https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
As you may h= ave noticed use of indexes even complicates your draft :)=C2=A0
<= br>
- - -=C2=A0

Speaking of which how ar= e you going to decide on which algorithm is to be chosen in section 3.2 ? I= have similar observation as Stephane that it is very confusing at this poi= nt to provide many different ways in the document which is going to go for = RFC.=C2=A0

It is clearly not going to be easy to s= ee a "rough=C2=A0consensus" - that can be used to gather forum fe= edback to progress the doc or not .. but I think it will rather be hard to = judge as far as algorithm selection. Or are you going to run doodle ?=C2=A0=

Cheers,
Robert.


On Tue, Jul 5, 2016 at 6:54 PM, Les Ginsberg (ginsberg) <ginsberg@cis= co.com> wrote:

Robert =E2=80=93

=C2=A0

Use of RFC 5331 would require that we have a= way to advertise the context label associated with a prefix-SID advertisem= ent (whether in prefix reachability or SRMS). This capability does not currently exist.

=C2=A0

So I believe my answer is correct based on e= xisting definition of SR-MPLS support.

=C2=A0

I am also not aware that RFC 5331 has been p= roposed as a generic solution to RFC 5120 style MT even outside of SR =E2= =80=93 and likely for the same reason =E2=80=93 because there is no existing mechanism for advertising the context labels associat= ed with a prefix/MT pair.

=C2=A0

=C2=A0=C2=A0 Les

=C2=A0

=C2=A0

From: rrasz= uk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 05, 2016 12:30 AM
To: Les Ginsberg (ginsberg)
Cc: b= runo.decraene@orange.com; spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

=C2=A0

Hi Les,=

= =C2=A0

> However, this is not existing MPLS forw= arding behavior and since SR=C2=A0

> explicitly utilizes the existing MPLS f= orwarding behavior we not propose=C2=A0

> any extensions.

= =C2=A0

I am af= raid the above assertion is not correct. Existing MPLS forwarding already= =C2=A0

for a l= ong time uses context-labels to set required topology for forwarding.=C2=A0=

= =C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

On Tue, Jul 5, 2016 at 9:19 AM, Les Ginsberg (ginsbe= rg) <ginsberg@ci= sco.com> wrote:

Bruno =E2=80=93=

=C2=A0

SR-MPLS utilize= s existing MPLS forwarding behavior without change. In this model, the rece= ived label serves as the forwarding instruction for the packet. This means that if two packets are received for the same destination but w= e want the packet to follow two different forwarding =E2=80=9Ctopologies=E2= =80=9D, then we need to have two different labels.

=C2=A0

One can imagine= a different model, where the forwarding instruction is derived from the la= bel AND some other attribute of the packet =E2=80=93 and the latter could be used to select a forwarding topology. However, this is not existi= ng MPLS forwarding behavior and since SR explicitly utilizes the existing M= PLS forwarding behavior we not propose any extensions.=

=C2=A0

This is why dif= ferent SIDs are required for the same destination in different topologies.<= /span>

=C2=A0

=C2=A0=C2=A0=C2= =A0 Les

=C2=A0

=C2=A0

From: bruno.decrae= ne@orange.com [mailto:bruno.decraene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM


To: Les Ginsberg (ginsberg)
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution

=C2=A0

Les= ,

=C2= =A0

Ple= ase see inline [Bruno3]

=C2= =A0

From: Les Ginsberg (ginsberg) [mailto= :ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:36 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution<= /u>

=C2=A0

Bruno =E2=80=93=

=C2=A0

Inline.<= u>

=C2=A0

From: bruno.decrae= ne@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution<= /u>

=C2=A0

Hi = Les,

=C2= =A0

Thanks for the = discussion. Please see inline [Bruno]

=C2=A0

From: Les Ginsberg (ginsberg) [mailto= :ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution<= /u>

=C2=A0

Bruno =E2=80=93=

=C2=A0

=C2=A0

From: bruno.decrae= ne@orange.com [mailto:bruno.decraene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf= .org
Subject: RE: draft-ietf-spring-conflict-resolution<= /u>

=C2=A0

Hi = Les,

=C2= =A0

IINM, I=E2=80= =99ve not seen the follow up on one of my below questions.

So let me resta= te a comment:

=C2=A0

The SR-MPLS SID= conflicts algo requires that all nodes consider the same mapping advertise= ments.

How is this ens= ured, if it indifferently considers advertisements from all protocols, whil= e some nodes could participate only in a subset of the protocols? e.g. OSPF only routers would consider a different set of information compa= red to OSPF+IS-IS routers.

=C2=A0

[Les:] If= you run multiple protocol instances (whether multiple instances of the sam= e protocol or instances of different protocols) then you need to insure that at least one of the two conditions below is true:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 All routers receive the equival= ent set of advertisements

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 There are no conflicts <= span style=3D"font-family:Wingdings;color:rgb(31,73,125)">J

=C2=A0

[Bruno] IOW, = the draft does not resolve SID conflict if all routers do not receive exact= ly the same set of advertisement from all routing protocols.<= u>

That=E2=80=99= s indeed can be a valid simplification if the WG choose to, but this should= clearly be indicated in the document, in a section targeting network operator since this point will need to be read and enforced by network ope= rator rather than protocol implementors. =C2=A73.2.8 already partly address= this, but IMO a text clearly expressing the requirements on network operat= or would be useful.

=C2=A0

[Les2:] No = policy can guarantee consistent results network wide if the databases on di= fferent nodes are inconsistent. This isn=E2=80=99t a =E2=80=9Csimplificatio= n=E2=80=9D =E2=80=93 it is a fact. As you point out, Section 3.2.8 already states:

=C2=A0

=E2=80=9CIn order to obtain consis= tent active entries all nodes in a network

=C2=A0=C2= =A0 MUST have the same mapping entry database.=E2=80=9D

=C2=A0

If you believe= this is not explicit enough please suggest some text.=

[Br= uno3]

Section 4 Manag= eability Considerations

Detecting and r= esolving conflicts in a consistent way requires that all nodes consider the= same set of SIDs advertisements. Network operations should be aware that the conflict resolution algorithm defined in this document w= ill not succeed in selecting a consistent resolution across all nodes, if a= ll nodes do not receive the exact same set of SIDs advertisements. This may= be in particular the case when multiple IGP instances are used and all routers do not participate in the = same set of IGP instances. This may occurs for example if one network trans= ition from one IGP protocol to another IGP (e.g. from OSPFv2 to IS-IS). Thi= s may also happen if IGP areas/level are used and SIDs are not flooded in all areas/levels.

=C2=A0

=C2=A0

One way of i= nsuring the first point is to exclusively use a mapping server to advertise= SIDs, configure your SRMS entries in a protocol independent manner, and insure that the SRMS advertisements are sent in all of the pro= tocol instance specific sub-domains.

[Bruno] IOW, = don=E2=80=99t make configuration errors ;-)

Are you imply= ing that the SRMS configuration (hence yang model) should be per node rathe= r than per protocol? or at least should be configurable by node (and possibly also by protocols)

=C2=A0

[Les2:] My = point is (humorous ideas aside=E2=80=A6) that if a deployment uses multiple= protocols, the easiest way to guarantee that the SID mapping database on all nodes in the network is consistent is to restrict SID advertisement= s to SRMS advertisements.

[Bruno3] Clearl= y, the fewer the number of advertisements for a given prefix, the less chan= ge of conflict.

But I fail to s= ee why only using SRMS guarantee anything. e.g. if different nodes use a di= fferent set of routing protocols, you have conflicts. Idem if the misconfiguration consist in adding a SID to a IGP prefix (PFX adver= tisement)

=C2=A0

=C2=A0

A small num= ber of nodes (as few as 1 =E2=80=93 more if redundancy is desired) are setu= p as mapping servers and all SIDs which are required network-wide are configured on these nodes and advertised by the protocol instance(s) o= n that node. In this way it is not necessary to guarantee that all prefix r= eachability from all of the protocol instances running in the network are p= resent in all the protocol instance sub-domains which exist =E2=80=93 it is only necessary to insure that all = protocol instances advertise the same set of SRMS entries.

[Bruno3] In the= end, this gets back to requiring no configuration mistakes.<= u>

It isn=E2= =80=99t the only way to support this =E2=80=93 but it is likely to be the s= implest and least error prone. In any case this isn=E2=80=99t a requirement= =E2=80=93 it was a response to your question as to how it might be possible to get consiste= nt SID mapping databases on all nodes in such a case. This is no way change= s how the YANG model is defined. SRMS config is always node specific.

=C2=A0

=C2=A0

If the inten= t is to deliberately use different labels in the forwarding plane for the s= ame destination depending upon which protocol advertised the prefix, this introduces a number of new requirements =E2=80=93 not the lea= st of which is duplicate entries for the same prefix in the forwarding plan= e.=C2=A0 As has been discussed publicly in a different thread, there are ca= ses (e.g. merging two networks) were such a requirement may exist =E2=80=93 but it is the exception rather than the rule and as it= consumes more resources in the forwarding plane and introduces implementat= ion complexity independent of conflict resolution it is not the primary cas= e the draft focuses on. Nevertheless, this is a case which the draft will address in the next revision.=

[Bruno]There = is also the point of configuring different SRGB space in different IGP prot= ocols. In which case, SIDs may conflict but this is not an issue as label will not conflict.

We stopped s= hort of that in this revision because we felt there were enough substantive= changes and points on which consensus is still a work in progress that it would not be the optimal way forward.

[Bruno] +1 an= d thanks. Releasing an updated version has been useful to re-initiate the d= iscussion.

=C2=A0

Thinking more a= bout this, I guess that this is only important for the entries which are in= serted in the forwarding plane. Hence, in case of conflict between protocols, I think that the preference algorithm should take into = account the protocol preference (aka administrative distance).

=C2=A0

[Les:] As= admin distance is neither an attribute of SRMS entries nor guaranteed to b= e consistent on all routers for all prefixes this is not a desirable approach.

[Bruno] Well,= the some prefix/routing consistency is also required for IP prefixes. When= then same IP prefix is advertised in different IGPs, admin distance is a common existing way to define which routing protocol takes precedence= . I=E2=80=99m not sure why it should not also be taken into consideration f= or SR Prefix conflits

=C2=A0

[Les2:] Ple= ase see my response to Stephane on the same point.=

=C2=A0

I=E2=80=99m als= o not sure to see why is the problem different compared to Multi-Topology. = Could you please elaborate?

[Les:] I = am unclear what your question is. Are you asking why we need different SIDs= in different topologies? Please clarify.

[Bruno] Quest= ion was that, at a very/too high level, the issue of conflict across topolo= gy seems close to the issue of conflict across routing protocols: =C2=A0we have different topologies. Hence a na=C3=AFve question: how exact= ly is this different.

One part of t= he answer, is the simplification proposed when multiple protocols is used (= i.e. your first answer above).

Another part = is that for multi-topology, compared to multi-protocols, all information fr= om all topologies are flooded to all nodes.

Another part = is the forwarding model used for Multi-Topology. In general, https://tools.ietf.org/html/rfc5120#section-8 seems to assume that each top= ology has one dedicated RIB/FIB. In such condition, there is no conflict (p= refix or SID) so no need to detect and resolve conflict. So here there may = be different models and eventually, we don=E2=80=99t =E2=80=98have the same one in mind.

In a lesser e= xtend, even for multi-protocols, we may have those multiple forwarding mode= ls. To some extent, this seems related to the definition of =E2=80=9CSR domain=E2=80=9D. e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May= be this is something that needs to be configurable

=C2=A0=

=C2=A0

[Les2:] Ple= ase reread Section 3.1.2. While there are no =E2=80=9CPrefix-conflicts=E2= =80=9D across topologies, there are =E2=80=9CSID Conflicts=E2=80=9D. This i= s important to understand.

[Bruno3] Confli= cts are related to a forwarding context i.e. FIB. This is equally important= to understand. Please read https://tools.ietf.org/h= tml/rfc5120#section-8.2.2 and 8.2.1 to see that topologie= s may not share the same forwarding context hence do not conflict in term o= f prefix & SID.

--Bruno<= u>

=C2=A0

As regards = multiple protocols operating in the same topology, from a forwarding perspe= ctive we do not care what protocol is the winning route. What we care about is that our nexthop has chosen the same SID for a given= prefix. This is why =E2=80=9Csource=E2=80=9D is deliberately excluded from= consideration by the conflict resolution algorithm.<= u>

=C2=A0

=C2=A0=C2= =A0=C2=A0 Les

=C2=A0

=C2=A0=C2= =A0=C2=A0 Les

=C2=A0

=C2=A0

Thanks,<= u>

Bruno=

=C2=A0

From: spring [mailto:sprin= g-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

=C2=A0

Les,<= /u>

=C2=A0

Thanks for your= reply.

Please see inli= ne [Bruno]

=C2=A0

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution<= /u>

=C2=A0

Bruno =E2=80=93=

=C2=A0

Inline.<= u>

=C2=A0

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

=C2=A0

Hi,

=C2=A0

As an individual contributor, please find below some= comments:

=C2=A0

--

Isn=E2=80=99t this document specific to the MPLS dat= aplane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

=C2=A0

[Les:] Cu= rrently all discussion is regarding SR-MPLS. The draft leaves open the poss= ibility that if there is some SRv6 conflict resolution that needs to be specified it could be added into this document =E2=80=93 which= is why the Introduction is dataplane agnostic, but each section states spe= cifically that it is relevant to SR-MPLS.

=C2=A0

I am not = aware of any SRv6 conflict resolution that is required at this point, but I= prefer to leave the possibility open if that is OK with you.

[Bruno] ok, gre= at.

--

=C2=A73

=E2=80=9CMapping entries have an explicit context which incl= udes the topology and the SR algorithm.=E2=80=9C

A priori you could add =E2=80=9Cthe routing protocol=E2=80= =9D.

=C2=A0

[Les:] No= =E2=80=93 the source of advertisements is deliberately left out. It matter= s not whether the source of the advertisement is a protocol or an SRMS =E2=80=93 nor does it matter which protocol provides the advertisement. Yo= u see that =E2=80=9Cadmin distance=E2=80=9D is not mentioned at all and tha= t is quite deliberate. This insures that consistent choices are made on nod= es regardless of which protocol might have the best route on a given node.

[Bruno] Well, t= he fact is that mapping entries do have, as explicit context, the routing p= rotocol used to advertise them. After, you can should to use that information, or not.

--

=C2=A73

=E2=80=9CWhen conflicts occur, it is not
=C2=A0=C2=A0 possible for routers to know which of the conflicting adv=
ertisements
=C2=A0=C2=A0 is "correct".=C2=A0 If a router chooses to use =
one of the conflicting
=C2=A0=C2=A0 entries forwarding loops and/or blackholes may result unl=
ess it can
=C2=A0=C2=A0 be guaranteed that all other routers in the network make =
the same
=C2=A0=C2=A0 choice.=C2=A0 Making the same choice requires that all ro=
uters have
=C2=A0=C2=A0 identical sets of advertisements and that they all use th=
e same
=C2=A0=C2=A0 selection algorithm.=C2=A0=C2=BB
=C2=A0
I think we agree on the technical part, but I found the formulation sl=
ightly biased. I would propose
=E2=80=9CWhen conflicts occur, it is not
=C2=A0=C2=A0 possible for routers to know which of the conflicting adv=
ertisements
=C2=A0=C2=A0 is "correct".=C2=A0 In order to avoid forwardin=
g loops and/or blackholes, there is a need for all nodes to make the same c=
hoice.
=C2=A0 Making the same choice requires that all routers have=

=C2=A0=C2=A0 identical sets of advertisements and that they all use th=
e same
=C2=A0=C2=A0 selection algorithm. This is the purpose of this document=
.=C2=A0=C2=BB

--

[Les:] I = am fine with this change.

[Bruno] Thanks<= /span>

=C2=A0

=C2=A73.1

=E2=80=9CVarious types of conflicts may occur=E2=80=9D

What about :s/Various/Two


=C2=A0


[Les:] =
=E2=80=9CTwo=E2=80=9D is fine. Just means we will have to change it if we c=
ome up with a third type of conflict.
J


[Bruno] Indeed,=
 but in this case the change may be much larger (e.g. the whole algo)


--


I agree with Robert=E2=80=99s =C2=A0and Uma=E2=80=99=
s comment with regards to making this conflict resolution an inter- protoco=
l/routing_table issue. In particular, between SR domains, there is not
 requirement to have unique SIDs. Hence between PE and CE, between ASes (bo=
th within and across organization), the same SID could be reused independen=
tly).



=C2=A0


[Les:] Th=
ere is more to be said on this topic =E2=80=93 co-authors are actively disc=
ussing this point and we=E2=80=99ll respond more fully to Robert=E2=80=99s =
post in
 time. But, the draft is NOT trying to define conflict resolution across =
=E2=80=9CSR domains=E2=80=9D. Perhaps we need language to make that more ex=
plicit.


[Bruno] ok. Reg=
arding inter-protocol, in order to have consistency of the prefix-SID mappi=
ng across the domain we need:



a) all nodes use the same algo =




b) all nodes using this algo have the =
same data



=C2=A0



=E2=80=9Ca=E2=80=9D requires this draf=
t



=E2=80=9Cb=E2=80=9D requires that all =
nodes have the same set of SR=C2=A0 info. This forbid that some node are co=
nsidering IS-IS + OSPF SR data, while some node are only considering IS-IS =
data. Otherwise, all IS-IS routers would not take the same decision.
 So, unless we can guarantee that the flooding area is the same for IS-IS a=
nd OSPF, we can't have the algo using the SR data from multiple routing=
 protocols. I don't think that we can guarantee this (nor that implemen=
tation will check this) e.g. when some nodes
 are part of multiple routing domain or when gradually transitioning from o=
ne IGP to another.



=C2=A0


So in short, th=
is SR-conflict algo should probably be restricted to SR information from a =
single protocol


=C2=A0


> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
 > Sent: Sunday, May 01, 2016 7:11 AM


>=C2=A0


>
We are indeed defining conflict resoluti=
on across all the SID advertisements regardless of source (protocol or SRMS=
)


> Why? Because we nee=
d consistent use of SIDs in the forwarding plane


=C2=A0


No: in the forwarding plane, we need a consistent us=
e of MPLS label.


[Les:] As=
 you know, SRGB range can be different for different nodes, so the actual l=
abel that is used to send a packet for a given destination
 via Node A may be different than the label used to send the same packet vi=
a Node B. It is the SID that needs to be the same =E2=80=93 not the label.



It is tru=
e that SIDs are not installed in the forwarding plane =E2=80=93 the labels =
derived from the SID/SRGB are what is actually installed in the forwarding
 plane =E2=80=93 but I think my use of the word SID in this context is corr=
ect.


[Bruno] My poin=
t was that the formulation assumes that a single SRGB is used per nodes. In=
 which case, we have a bijection between SID and labels. But
 if we have a SRGB per protocol, we don=E2=80=99t have a bijection any more=
 and we can have the same SID in IS-IS and OSPF (including for different pr=
efix), which will be mapped to different labels in the forwarding plane.


=C2=A0


Plus only within an SR domain. Actually, even within=
 a domain, this is dependent on whether SRGB is configured on a per node or=
 a per protocol basis. I=E2=80=99m not sure how much the agreement
 has been reached on that one.


=C2=A0


[Les:] Th=
e draft currently addresses deployments where a single (set of) SRGB ranges=
 applies to the box. This is by far the most common use case.
 There is a much more limited use case where protocol specific SRGBs and pr=
otocol specific SIDs may be required. The draft will address that in a futu=
re revision


[Bruno] ok, may=
 be this should be stated in the draft, as otherwise you=E2=80=99ll keep ge=
tting comments, or we may forget this point.


Thanks


--Bruno<=
u>


=E2=80=93=
 but in spirit the same rules will apply =E2=80=93 they will just have to t=
ake into account =E2=80=9Cduplicate forwarding domains=E2=80=9D. Note that =
this will also require
 multiple incoming label entries/prefix be supported by the routers in such=
 a network.


=C2=A0


--


Typo:


=C2=A72


O=
LD=C2=A0: Range 3: (500, 5990


N=
EW=C2=A0: Range 3: (500, 599)


=
=C2=A0


(=
somewhat significant as otherwise range 3 conflict with range 2)<=
/u>


=C2=A0


[Les:] Ag=
reed =E2=80=93 thanx for spotting this.


=C2=A0


=C2=A0=C2=
=A0
Les


=C2=
=A0


Thanks,


Regards,


Bruno


____________________________________________________=
_____________________________________________________________________


=C2=A0


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=



pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>


a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=



Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


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.


____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.
____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.
____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.
____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.


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

=C2=A0


Hi Les,

> However, this is not existing MPLS = forwarding behavior and since SR=C2=A0
> explicitly utilizes the existing MPLS forwarding behavior we n= ot propose=C2=A0
> any exten= sions.

I am= afraid the above assertion is not correct. Existing MPLS forwarding alread= y=C2=A0
for a long time uses context-labels to set = required topology for forwarding.=C2=A0

<= div class=3D"gmail_default">https://tools.ietf.org/html/rf= c5331

Thx,
R.

--001a114cdea2da90470538695b5a-- From nobody Sun Jul 24 15:43:03 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD02A12B01F for ; Sun, 24 Jul 2016 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrJUXqZ7lXTu for ; Sun, 24 Jul 2016 15:42:59 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD99312B05B for ; Sun, 24 Jul 2016 15:42:58 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id q128so114635865wma.1 for ; Sun, 24 Jul 2016 15:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=t7zZ5oIyG/9HeyI54+9nOIuI7cKzphUYkqghZdb1nL4=; b=REJOlzAj7WwqTvcM6c+9COPZyjlyg4UnkKPR8HE4v/TamNK26BfmMPsZtcKBsjJVFz p9bbRv5PEjqqwH4pYE9nPhnZll9ReEPvVK3mJFI0fPGZDXGq/FAoPu8w1P7NLQSlCzBa bYkgqibkPfLvNsZJ2ShNYuhbJSyN3oW1DiQhtOE5xlFIJ9veTpRn2Z4hX0xOPktjeCSo k+dNVXjVuvaxEa/cfGUUX3Gk7KQlZgAuPwVRDGve+LrJkrV09R4y5uzVpruHhiTptO4i jMam980rhoDDAKbs31nIwGmw5VthySun9LYpwWzOmamb3ZSo1yTx+8dx2PGSL0npJmvk 6Olw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=t7zZ5oIyG/9HeyI54+9nOIuI7cKzphUYkqghZdb1nL4=; b=kbc8IKks+iSzHIdaZ02APC+e9DNXN+TfhnUPIry2wD/kKHWahgKpujANvW3bT7g5dF m3RWfYFtQ0yez5BQhcO23i1xkoAaoXfK955R7YZpYcSc3VMEAcBAVeRekOTkdvW61G7t 0VjnIoKSmcBkDCDT5B+L5XyBPFLVIeeVlijhKjjCQgZeLwtjDzzvjzxtwbjQHMcr96u/ zZu4jMsxjV7O5tQseBhIXdSbtxQHMgmuIPxJ17uVWu7ZSItBG3IrMZQLTQopwUqtNJpb 58ZfjEtnqLkfDutGb1w41SH1bujYe3T5R9CDJlnv1CXyoMrHBj2hEVAfTv0zqGfIH4gu Od5g== X-Gm-Message-State: AEkoouvC/qWPvOKX+XCEuIkZIE3SIxHcHw9A5l4GwQtXJ7klKLYr8dEJkhKE7CciRPWB5cplo5YLrpeeIHo3+w== X-Received: by 10.194.89.73 with SMTP id bm9mr1856278wjb.76.1469400177431; Sun, 24 Jul 2016 15:42:57 -0700 (PDT) MIME-Version: 1.0 References: <2CCF3EAE-8D9F-4AB1-8647-CF5FD4432209@nokia.com> In-Reply-To: <2CCF3EAE-8D9F-4AB1-8647-CF5FD4432209@nokia.com> From: Jeff Tantsura Date: Sun, 24 Jul 2016 22:42:48 +0000 Message-ID: To: "Henderickx, Wim (Nokia - BE)" , "John G. Scudder" , "spring@ietf.org" Content-Type: multipart/alternative; boundary=089e0102dc5e9bd9ba05386963de Archived-At: Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 22:43:01 -0000 --089e0102dc5e9bd9ba05386963de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support as co-author not aware of any relevant IPR that has not been previously disclosed. Cheers, Jeff On Sun, Jul 24, 2016 at 6:10 AM Henderickx, Wim (Nokia - BE) < wim.henderickx@nokia.com> wrote: > As a co-author is support WG adoption. > Not aware of IPR related to this draft > > > > > On 24/07/16 14:55, "spring on behalf of John G. Scudder" < > spring-bounces@ietf.org on behalf of jgs@juniper.net> wrote: > > >Dear WG, > > > >As we discussed at our meeting, working group adoption has been requeste= d > for draft=E2=80=90filsfils=E2=80=90spring=E2=80=90large-scale-interconnec= t. Please reply to the > list with your comments, including although not limited to whether or not > you support adoption. Non-authors are especially encouraged to comment. > > > >We will end the call on August 31, 2015. > > > >Authors, please indicate whether you are aware of any relevant IPR and i= f > so, whether it has been disclosed. Also, the length of the author list fo= r > this document greatly exceeds the maximum recommended. Assuming the > document is adopted, the authors should be prepared to correct this when > submitting as a WG document, ideally by reducing the list to simply the > active editor(s) and making use of the "contributors" section for the ful= l > list. > > > >Thanks, > > > >--Bruno and John > > > >_______________________________________________ > >spring mailing list > >spring@ietf.org > >https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --089e0102dc5e9bd9ba05386963de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support as co-author
not aware of any relevant IPR that has not been pre= viously disclosed.

Cheers,
Jeff
On Sun, Jul 24, 2016 at 6:10 AM Henderickx, Wim (Nokia - BE) = <wim.henderickx@nokia.com> wrote:
As a co-author is supp= ort WG adoption.
Not aware of IPR related to this draft




On 24/07/16 14:55, "spring on behalf of John G. Scudder" <spring-bounces@iet= f.org on behalf of jgs@juniper.net> wrote:

>Dear WG,
>
>As we discussed at our meeting, working group adoption has been request= ed for draft=E2=80=90filsfils=E2=80=90spring=E2=80=90large-scale-interconne= ct. Please reply to the list with your comments, including although not lim= ited to whether or not you support adoption. Non-authors are especially enc= ouraged to comment.
>
>We will end the call on August 31, 2015.
>
>Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author list f= or this document greatly exceeds the maximum recommended. Assuming the docu= ment is adopted, the authors should be prepared to correct this when submit= ting as a WG document, ideally by reducing the list to simply the active ed= itor(s) and making use of the "contributors" section for the full= list.
>
>Thanks,
>
>--Bruno and John
>
>_______________________________________________
>spring mailing list
>spring@ietf.org
>https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--089e0102dc5e9bd9ba05386963de-- From nobody Sun Jul 24 15:46:17 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF3112B01F for ; Sun, 24 Jul 2016 15:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwolxs0TVLT4 for ; Sun, 24 Jul 2016 15:46:14 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4309F12B018 for ; Sun, 24 Jul 2016 15:46:14 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id q128so114674838wma.1 for ; Sun, 24 Jul 2016 15:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=67sNc2C7mXMSUeIP462zJdS52hZQbYGXTaFZPNWJkIE=; b=VeBIKydFXtJxpQjm956QPslm3eU0tUFYcKS7Hm1XRcMezv5RFl0ZPC7lXZx/eY0is3 E65nUB6tIibeX9QJmj1f/FtsnThZ2nvIel1nnbdAnzzaAPZXH81+4lSwDwas9H5tsq+b 8ANxmz8qOdUA1mioj9tPI3lYNYF7uzT1uhLs3AW4kIqI2gBRhFKqJ3FDHyvLGanQCY7s C87a060EcGexYF2yCHtjTOZhIc0V7ZOvwkk9Ir9a4u4+tLsDZlZAxXMS8Tc9e/LmHcrK +Kv1PPek4OYC5Ve9NCo9rH/aDtsH6+dE/qd69ZwlaJtr9UYRigyVcDs+kpmcwdgDkMQI 04+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=67sNc2C7mXMSUeIP462zJdS52hZQbYGXTaFZPNWJkIE=; b=kUNcqno1CAqDoenNZTS3ud05MvOWDsTohpgT2YPlLWa7zbId3bDkG833uWFTLClHTN 5WzxXwkVSNonu9lesSdP/6wxd/oa8LqnZB7HNOpr8LTX3lrdcBmckgIMIiuBydJE2eDc IYmvGSkRN6lo0ODiRCDEbz43eGNYC5FJHyOMMdn3sv48lu8s6hjNHT719wn81Iwron2B yyxtKcsYxhMHzCBQzhNXNAooFK3lg1r6sij77hQrY8ndKYntnmojnJZKv/OB2mQjMEdX gG/lpur7keDA7X/N7rR0+hxNixdRnYrX67G4UQigSAY2kCley/paTGQr8iXWqt02tiZ6 WDiQ== X-Gm-Message-State: AEkoouuFhSl4cn27ZFNdJBUedgOh9SZn/ZdrYiuzopPQVtlNgRw97ec+JUAvfPln5ui1lkK7Cj/Uhh9CLw4hDw== X-Received: by 10.28.229.1 with SMTP id c1mr17944457wmh.0.1469400372743; Sun, 24 Jul 2016 15:46:12 -0700 (PDT) MIME-Version: 1.0 References: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> In-Reply-To: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> From: Jeff Tantsura Date: Sun, 24 Jul 2016 22:46:03 +0000 Message-ID: To: "John G. Scudder" , spring@ietf.org Content-Type: multipart/alternative; boundary=001a114694d64014160538696f1b Archived-At: Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 22:46:16 -0000 --001a114694d64014160538696f1b Content-Type: text/plain; charset=UTF-8 Yes/support On Sun, Jul 24, 2016 at 5:54 AM John G. Scudder wrote: > Dear WG, > > As we discussed at our meeting, working group adoption has been requested > for draft-filsfils-spring-sr-recursing-info. Please reply to the list with > your comments, including although not limited to whether or not you support > adoption. Non-authors are especially encouraged to comment. > > We will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if > so, whether it has been disclosed. > > Thanks, > > --Bruno and John > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a114694d64014160538696f1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes/support
On Sun, Jul 24, = 2016 at 5:54 AM John G. Scudder <jgs@= juniper.net> wrote:
Dear WG,=

As we discussed at our meeting, working group adoption has been requested f= or draft-filsfils-spring-sr-recursing-info. Please reply to the list with y= our comments, including although not limited to whether or not you support = adoption. Non-authors are especially encouraged to comment.

We will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed.

Thanks,

--Bruno and John

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--001a114694d64014160538696f1b-- From nobody Mon Jul 25 00:03:16 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5D712B028; Mon, 25 Jul 2016 00:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTZUjOCgjeTG; Mon, 25 Jul 2016 00:03:14 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE46112D1BD; Sun, 24 Jul 2016 23:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1469429674; x=1500965674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bSDqTYXWblKsl1W3qgYF6LdSo2qXrLwl+722c38VbOg=; b=15kp3OT8ciwFXkN36pf6vXRweqqvyDH7Wwzhn4w7+EEgxiXePyEXegTM 314dpsOqlfaol76wgGTw1Byb5Ejcwc4zWgAEmY3jiw2j7ryVvnPRRVzjR OxKQZ3Kf+3pKNZu6NRP5XMLTkYoQS/PJ85/8lc7VhcaIFjv8vg1KS0w2Z p5hng9VtQmd8gmGtG/bhPAFoLn8koPa7szic0I/AB4TCDhv8VMpDmjbNO fdVwNqcTEfqKWsO8bmiHtbZtHtqExx97y4up/s1M26pm54b3EkrToYIEt DoZBr2UqBx1XJlreMM9+gGAxlLvQFdt0fCsFs7E9bysRD5eA4Yl8YKREX A==; Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Jul 2016 08:54:30 +0200 X-IronPort-AV: E=Sophos;i="5.28,418,1464645600"; d="scan'208";a="924345432" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2016 08:55:36 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 25 Jul 2016 08:55:35 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Mon, 25 Jul 2016 08:55:35 +0200 From: To: Thread-Topic: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC Thread-Index: AQHR5al8Akys7TfZpkagHjAWsbCS8qAotiPw Date: Mon, 25 Jul 2016 06:55:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.171.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: spring@ietf.org, draft-ietf-spring-oam-usecase@ietf.org Subject: Re: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 07:03:15 -0000 Hi John, I'm aware of the following IPR: IPR disclosure to "A Scalable and Topology-Aware MPLS Dataplane Monitoring = System"=20 (draft-ietf-spring-oam-usecase): https://datatracker.ietf.org/ipr/2314/ I'm not aware of another IPR related to draft-ietf-spring-oam-usecase. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: spring [mailto:spring-bounces@ietf.org] Im Auftrag von John G.Scudder Gesendet: Sonntag, 24. Juli 2016 14:47 An: draft-ietf-spring-oam-usecase@ietf.org Cc: spring@ietf.org Betreff: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC [re-sending with WG in cc. Please cc WG on your replies, thanks and sorry f= or the dup.] Dear Authors: As we discussed at the SPRING meeting, working group last call has been req= uested for draft-ietf-spring-oam-usecase. Before we begin the WGLC, please = indicate whether you are aware of any relevant IPR and if so, whether it ha= s been disclosed. (Please do this even if you've done it before, thanks for= your help.) As soon as this has been collected from all authors, we'll start the WGLC. Thanks, --Bruno and John _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jul 25 01:26:59 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58F12D09B; Mon, 25 Jul 2016 01:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9kALFNyXy_Z; Mon, 25 Jul 2016 01:26:51 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F865127058; Mon, 25 Jul 2016 01:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1664; q=dns/txt; s=iport; t=1469435211; x=1470644811; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EME1gRlCT22bF+Th/GLTTo+SJhDg8m9opLskc+3e09I=; b=hFtv5UdLG//o1xNtGgwYR87uLgcOIz8m0b1LY0lI+l3kt73a1l2/I9do 1Y+59/wS2muENrGVTqNNpkKBpV+LRfLelI6akY5z3zsWwTY36LIf+KgkM KM1x7hAV6DYYV21jgj1j+q0gmXctSJZmznCWxh4SwBru6aH0n0jkHnN7K E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgA7zJVX/4ENJK1egz9WfAa4XIF8J?= =?us-ascii?q?IUvSgIcgRg4FAEBAQEBAQFdJ4RcAQEEAQEBIRE6CwULAgEIGAICJgICAiULFRA?= =?us-ascii?q?CBA4FiCgIDqcgjSkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSmBeAiCTYQcJ?= =?us-ascii?q?IMBK4IvBZkoAY5ugWyEWoh5kCABHjaCPoE1bocERX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,418,1464652800"; d="scan'208";a="301961682" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2016 08:26:50 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6P8QoRx014652 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 08:26:50 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 04:26:49 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 25 Jul 2016 04:26:49 -0400 From: "Stefano Previdi (sprevidi)" To: "John G. Scudder" Thread-Topic: [spring] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments Thread-Index: AQHR5aiIq4RwYdoLXkCf5Pc06B+VfqApFGIA Date: Mon, 25 Jul 2016 08:26:49 +0000 Message-ID: <56EC4478-9407-4A73-9F8D-D838F22F92FD@cisco.com> References: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> In-Reply-To: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.207.56] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [spring] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:26:53 -0000 YXMgY28tYXV0aG9yLCBJIHN1cHBvcnQgdGhlIFdHIGFkb3B0aW9uIGFuZCBJ4oCZbSBub3QgYXdh cmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNCnMuDQoNCg0KPiBPbiBKdWwg MjQsIDIwMTYsIGF0IDI6MzkgUE0sIEpvaG4gRy4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3 cm90ZToNCj4gDQo+IERlYXIgV0cgKGFuZCBjYyBNUExTLCBwbGVhc2UgaW5jbHVkZSBTUFJJTkcg aW4gcmVwbGllcyksDQo+IA0KPiBBcyB3ZSBkaXNjdXNzZWQgYXQgb3VyIG1lZXRpbmcsIHdvcmtp bmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1wc2Fya2FyLXNw cmluZy1tcGxzLWFueWNhc3Qtc2VnbWVudHMuIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRo IHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVy IG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkg ZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KPiANCj4gV2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24gQXVn dXN0IDMxLCAyMDE1LiANCj4gDQo+IEF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlv dSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiBhbmQgaWYgc28sIHdoZXRoZXIgaXQgaGFz IGJlZW4gZGlzY2xvc2VkLiBBbHNvLCB0aGUgbGVuZ3RoIG9mIHRoZSBhdXRob3IgbGlzdCBmb3Ig dGhpcyBkb2N1bWVudCBleGNlZWRzIHRoZSBtYXhpbXVtIHJlY29tbWVuZGVkLiBBc3N1bWluZyB0 aGUgZG9jdW1lbnQgaXMgYWRvcHRlZCwgdGhlIGF1dGhvcnMgc2hvdWxkIGJlIHByZXBhcmVkIHRv IGNvcnJlY3QgdGhpcyB3aGVuIHN1Ym1pdHRpbmcgYXMgYSBXRyBkb2N1bWVudCwgaWRlYWxseSBi eSByZWR1Y2luZyB0aGUgbGlzdCB0byBzaW1wbHkgdGhlIGFjdGl2ZSBlZGl0b3IocykgYW5kIG1h a2luZyB1c2Ugb2YgdGhlICJjb250cmlidXRvcnMiIHNlY3Rpb24gZm9yIHRoZSBmdWxsIGxpc3Qu DQo+IA0KPiBUaGFua3MsDQo+IA0KPiAtLUJydW5vIGFuZCBKb2huDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBs aXN0DQo+IHNwcmluZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwcmluZw0KDQo= From nobody Mon Jul 25 01:29:12 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7886D127058; Mon, 25 Jul 2016 01:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hazqBlu0fvCU; Mon, 25 Jul 2016 01:29:10 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE96120727; Mon, 25 Jul 2016 01:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=900; q=dns/txt; s=iport; t=1469435350; x=1470644950; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nsVtQUVaoez2pl6wN/jWhl8UZOMdmrcl1+3vFnhfLXw=; b=OmXO2OpZxBYrBAaDNp+eJBYdAlSNh/3XBhHyJIsLozG8xRdZmjhg/SAU XHK9BaxQ7dhF4x46M3HRly+SgU/Pc2tG+w1hGhpeL8cj8ccjZVUw3CCMj 4ohkBIeqVbxYhTnPsb+STYWFy+zJCXKqBgbbgvrnnWpJjdyRLb02Hlttv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgCozZVX/5NdJa1egz+BUga2TYIPg?= =?us-ascii?q?XyGHQIcgRg4FAEBAQEBAQFdJ4RcAQEEASMRRQULAgEIGAICJgICAjAVEAIEDgW?= =?us-ascii?q?IKAinMI0rAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSmBeIJVh0Ergi8BBJkoA?= =?us-ascii?q?Y5ugWyEWoh5kCABHjaDc26HSX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,418,1464652800"; d="scan'208";a="301866570" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2016 08:29:05 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6P8T4Nx009284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 08:29:05 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 04:29:03 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 25 Jul 2016 04:29:03 -0400 From: "Stefano Previdi (sprevidi)" To: "John G.Scudder" Thread-Topic: IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC Thread-Index: AQHR5anjgHW4EBt3Zk+QBXJjHSZe8aApFQEA Date: Mon, 25 Jul 2016 08:29:03 +0000 Message-ID: <13FB4B20-BA69-41E0-A273-5880BB49A0C9@cisco.com> References: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> In-Reply-To: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.207.56] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:29:11 -0000 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXNu4oCZdCBiZWVuIGRpc2Nsb3NlZCBh bHJlYWR5Lg0KDQpzLg0KDQoNCj4gT24gSnVsIDI0LCAyMDE2LCBhdCAyOjQ5IFBNLCBKb2huIEcu U2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IERlYXIgQXV0aG9yczoNCj4g DQo+IEFzIHdlIGRpc2N1c3NlZCBhdCB0aGUgU1BSSU5HIG1lZXRpbmcsIGEgc2Vjb25kIHdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLiBCZWZvcmUgd2UgYmVnaW4gdGhlIFdHTEMsIHBsZWFzZSBpbmRp Y2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiBhbmQgaWYgc28s IHdoZXRoZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkLiAoUGxlYXNlIGRvIHRoaXMgZXZlbiBpZiB5 b3UndmUgZG9uZSBpdCBiZWZvcmUsIHRoYW5rcyBmb3IgeW91ciBoZWxwLikgUGxlYXNlIGNjIHRo ZSBXRyBpbiB5b3VyIHJlcGx5Lg0KPiANCj4gQXMgc29vbiBhcyB0aGlzIGhhcyBiZWVuIGNvbGxl Y3RlZCBmcm9tIGFsbCBhdXRob3JzLCB3ZSdsbCBzdGFydCB0aGUgV0dMQy4NCj4gDQo+IFRoYW5r cywNCj4gDQo+IC0tQnJ1bm8gYW5kIEpvaG4NCg0K From nobody Mon Jul 25 01:33:35 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F3912B018; Mon, 25 Jul 2016 01:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfQ9mh_jdbF9; Mon, 25 Jul 2016 01:33:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2957120727; Mon, 25 Jul 2016 01:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=896; q=dns/txt; s=iport; t=1469435612; x=1470645212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Dy5F60OyEFRsjC01Xemuwx6RGmILe/7KHcEE/mpb5Y0=; b=lT2c9b2zGJrI1sg+kCjBkt8YPhlGGp3fqZkd/yet2jM321ItjU6EAr4R kFXu9G5bLUh7VUTOa4En8Eql/5ewlLXwO1sAYeJCW0kxJ2Q6GTa9xG1Fl nhxbJIgZl3vpB0gwPJ3kFqHSYsTvkjsDNzOPUU319OP9t8HxHztkxi4DV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgDuzZVX/4oNJK1egz+BUga2TYIPg?= =?us-ascii?q?XyGHQIcgRg4FAEBAQEBAQFdJ4RcAQEEASMRRQULAgEIGAICJgICAjAVEAIEDgW?= =?us-ascii?q?IKAinMI0rAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSmBeAiCTYRAgwErgi8BB?= =?us-ascii?q?JkoAY5ugVYWhFqIeZAgAR42g3Nuh0l/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,418,1464652800"; d="scan'208";a="133231404" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2016 08:33:32 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6P8XVk3026506 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 08:33:32 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 04:33:30 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 25 Jul 2016 04:33:31 -0400 From: "Stefano Previdi (sprevidi)" To: "John G.Scudder" Thread-Topic: IPR for draft-ietf-spring-segment-routing-msdc prior to WGLC Thread-Index: AQHR5an4lHxDPnmzBUSRiywn60MUIKApFj2A Date: Mon, 25 Jul 2016 08:33:30 +0000 Message-ID: References: <5E9BF5C9-9E90-4243-8CD8-DEF19164954E@juniper.net> In-Reply-To: <5E9BF5C9-9E90-4243-8CD8-DEF19164954E@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.207.56] Content-Type: text/plain; charset="utf-8" Content-ID: <5245C1B3802AA847929AF168BF4D5B69@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-msdc@ietf.org" , "spring@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing-msdc prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:33:34 -0000 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXNu4oCZdCBiZWVuIGRpc2Nsb3NlZCBh bHJlYWR5Lg0KDQpzLg0KDQoNCj4gT24gSnVsIDI0LCAyMDE2LCBhdCAyOjUwIFBNLCBKb2huIEcu U2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IERlYXIgQXV0aG9yczoNCj4g DQo+IEFzIHdlIGRpc2N1c3NlZCBhdCB0aGUgU1BSSU5HIG1lZXRpbmcsIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLW1zZGMuIEJlZm9yZSB3ZSBiZWdpbiB0aGUgV0dMQywgcGxlYXNlIGluZGljYXRl IHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIGFuZCBpZiBzbywgd2hl dGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuIChQbGVhc2UgZG8gdGhpcyBldmVuIGlmIHlvdSd2 ZSBkb25lIGl0IGJlZm9yZSwgdGhhbmtzIGZvciB5b3VyIGhlbHAuKSBQbGVhc2UgY2MgdGhlIFdH IGluIHlvdXIgcmVwbHkuDQo+IA0KPiBBcyBzb29uIGFzIHRoaXMgaGFzIGJlZW4gY29sbGVjdGVk IGZyb20gYWxsIGF1dGhvcnMsIHdlJ2xsIHN0YXJ0IHRoZSBXR0xDLg0KPiANCj4gVGhhbmtzLA0K PiANCj4gLS1CcnVubyBhbmQgSm9obg0KDQo= From nobody Mon Jul 25 01:34:14 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A67912B018; Mon, 25 Jul 2016 01:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5KAfpeL9-yo; Mon, 25 Jul 2016 01:34:11 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A0F120727; Mon, 25 Jul 2016 01:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=904; q=dns/txt; s=iport; t=1469435651; x=1470645251; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=10nR/QcmGvY6nxgfisjIrmOVmftSSrswlWDVRQvw8IE=; b=c9HxV+ODDXoHBJc/IY0j+zgs4PiQxi4LtvDB9AALRAiuVyuDOfxr08Qg pVZpHsrOUxsWLJKDsoLMSTFjJB3TZh5iraiFjYQ0xaF6LLys1cIDJip8V 6+rJ+lWQx9lN5SX581pi0cqT5qpr4uQ4nmgCQ1JW2a7OjQTf9EDeDtoLJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgCozZVX/4cNJK1egz+BUga2TYIPg?= =?us-ascii?q?XyGHQIcgRg4FAEBAQEBAQFdJ4RcAQEEASMRRQULAgEIGAICJgICAjAVEAIEDgW?= =?us-ascii?q?IKAinMI0rAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSmBeAiCTYdBK4IvAQSZK?= =?us-ascii?q?AGOboFshFqIeZAgAR42g3Nuh0l/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,418,1464652800"; d="scan'208";a="301245459" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2016 08:34:10 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6P8YA9Z032120 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 08:34:10 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 04:34:08 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 25 Jul 2016 04:34:08 -0400 From: "Stefano Previdi (sprevidi)" To: "John G.Scudder" Thread-Topic: IPR for draft-ietf-spring-segment-routing-central-epe prior to WGLC Thread-Index: AQHR5aoG6LSz08q1ZkizCaNUvkHPpKApFm2A Date: Mon, 25 Jul 2016 08:34:08 +0000 Message-ID: <91014328-6DAD-4B46-AF14-B6923525BAEB@cisco.com> References: <3CCBF587-3720-4051-BCF4-3597E587E575@juniper.net> In-Reply-To: <3CCBF587-3720-4051-BCF4-3597E587E575@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.207.56] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-central-epe@ietf.org" , "spring@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing-central-epe prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:34:12 -0000 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXNu4oCZdCBiZWVuIGRpc2Nsb3NlZCBh bHJlYWR5Lg0KDQpzLg0KDQoNCj4gT24gSnVsIDI0LCAyMDE2LCBhdCAyOjUwIFBNLCBKb2huIEcu U2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IERlYXIgQXV0aG9yczoNCj4g DQo+IEFzIHdlIGRpc2N1c3NlZCBhdCB0aGUgU1BSSU5HIG1lZXRpbmcsIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLWNlbnRyYWwtZXBlLiBCZWZvcmUgd2UgYmVnaW4gdGhlIFdHTEMsIHBsZWFzZSBp bmRpY2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiBhbmQgaWYg c28sIHdoZXRoZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkLiAoUGxlYXNlIGRvIHRoaXMgZXZlbiBp ZiB5b3UndmUgZG9uZSBpdCBiZWZvcmUsIHRoYW5rcyBmb3IgeW91ciBoZWxwLikgUGxlYXNlIGNj IHRoZSBXRyBpbiB5b3VyIHJlcGx5Lg0KPiANCj4gQXMgc29vbiBhcyB0aGlzIGhhcyBiZWVuIGNv bGxlY3RlZCBmcm9tIGFsbCBhdXRob3JzLCB3ZSdsbCBzdGFydCB0aGUgV0dMQy4NCj4gDQo+IFRo YW5rcywNCj4gDQo+IC0tQnJ1bm8gYW5kIEpvaG4NCg0K From nobody Mon Jul 25 01:34:58 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CCB12D09C; Mon, 25 Jul 2016 01:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGfTt8lETX11; Mon, 25 Jul 2016 01:34:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B54512B018; Mon, 25 Jul 2016 01:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=900; q=dns/txt; s=iport; t=1469435695; x=1470645295; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WQky2lhyiiS7ZXS82SUnGY0nCWwGJsCOdut/ak7T8r4=; b=U6W+V9Upybr9IkfXU0T6kJdSWKf3RGvamvf/kvI4UzM6aKFY/HEXxWVW X6VSpC5b9LDqXAeyx+32YP8fMAnMNuYkQU6V6laU9q/wBQmQbCiQzuTSj FFkDC+AljEiaDyaH3OiOI6s/TwoeixFM3sOa9n8Y9+sZOFWW1qTsxIHFu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAwDuzZVX/4ENJK1egz+BUga0H4Iug?= =?us-ascii?q?g+BfIYdAhyBGDgUAQEBAQEBAV0nhFwBAQQBIxFFBQsCAQgYAgImAgICMBUFCwI?= =?us-ascii?q?EDgWIKAinMI0rAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSmBeIJVh0Ergi8BB?= =?us-ascii?q?JkoAY5ugVYWhFqIeZAgAR42g3Nuh0l/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,418,1464652800"; d="scan'208";a="133231658" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2016 08:34:54 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6P8Ys9Z019452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 08:34:54 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 04:34:53 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 25 Jul 2016 04:34:53 -0400 From: "Stefano Previdi (sprevidi)" To: "John G.Scudder" Thread-Topic: =?utf-8?B?SVBSIGZvciBkcmFmdOKAkGlldGYtc3ByaW5nLXNlZ21lbnTigJByb3V0aW5n?= =?utf-8?Q?-mpls_prior_to_WGLC?= Thread-Index: AQHR5apAgYxNbkcIX0qnrqUhNfSIxaApFqIA Date: Mon, 25 Jul 2016 08:34:53 +0000 Message-ID: <19DE2AB0-F84D-43C8-B259-BBE78C10EEED@cisco.com> References: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> In-Reply-To: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.207.56] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "spring@ietf.org" Subject: Re: [spring] =?utf-8?q?IPR_for_draft=E2=80=90ietf-spring-segment?= =?utf-8?q?=E2=80=90routing-mpls_prior_to_WGLC?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:34:57 -0000 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXNu4oCZdCBiZWVuIGRpc2Nsb3NlZCBh bHJlYWR5Lg0KDQpzLg0KDQoNCj4gT24gSnVsIDI0LCAyMDE2LCBhdCAyOjUyIFBNLCBKb2huIEcu U2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IERlYXIgQXV0aG9yczoNCj4g DQo+IEFzIHdlIGRpc2N1c3NlZCBhdCB0aGUgU1BSSU5HIG1lZXRpbmcsIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnTigJBpZXRmLXNwcmluZy1zZWdt ZW504oCQcm91dGluZy1tcGxzLiBCZWZvcmUgd2UgYmVnaW4gdGhlIFdHTEMsIHBsZWFzZSBpbmRp Y2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiBhbmQgaWYgc28s IHdoZXRoZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkLiAoUGxlYXNlIGRvIHRoaXMgZXZlbiBpZiB5 b3UndmUgZG9uZSBpdCBiZWZvcmUsIHRoYW5rcyBmb3IgeW91ciBoZWxwLikgUGxlYXNlIGNjIHRo ZSBXRyBpbiB5b3VyIHJlcGx5Lg0KPiANCj4gQXMgc29vbiBhcyB0aGlzIGhhcyBiZWVuIGNvbGxl Y3RlZCBmcm9tIGFsbCBhdXRob3JzLCB3ZSdsbCBzdGFydCB0aGUgV0dMQy4NCj4gDQo+IFRoYW5r cywNCj4gDQo+IC0tQnJ1bm8gYW5kIEpvaG4NCg0K From nobody Mon Jul 25 01:36:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97B312D09C for ; Mon, 25 Jul 2016 01:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MGujIhoY2G7 for ; Mon, 25 Jul 2016 01:36:46 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5285E12D09B for ; Mon, 25 Jul 2016 01:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1469435806; x=1470645406; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ba4RTkcmXMRI5FXu5UlyICCJBs3HbxdkEFrkQgBsr5E=; b=j6rua0cWCFlRDeCqCy60Ca8eC+frOr0I5ilOL1DRX9jI5s492vPUivHS snECwaCAnVp9qqdR8kltUJG4bEIJ0r6jLEIcCmc55mtLv9VZVJfeW9Gr1 fePK6c991oSQZzQ7EpeEpVbUQZi/e5iVTCUmw8mCQtKiA8HAtHVAyKSsI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAwDuzZVX/4kNJK1egz9WfAa0H4Q9g?= =?us-ascii?q?XwkhS9KAhyBGDgUAQEBAQEBAV0nhFwBAQQBAQEhEToLBQsCAQgYAgImAgICJQs?= =?us-ascii?q?VBQsCBA4FiCgIDqcijSsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSmBeIJVh?= =?us-ascii?q?ByDJSuCLwWZKAGOboFshFqIeZAgAR42gj6BNW6HBEV/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,418,1464652800"; d="scan'208";a="301091344" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2016 08:35:46 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6P8Zk5p007766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 08:35:46 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 04:35:45 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 25 Jul 2016 04:35:45 -0400 From: "Stefano Previdi (sprevidi)" To: "John G. Scudder" Thread-Topic: =?utf-8?B?W3NwcmluZ10gV0cgYWRvcHRpb24gcmVxdWVzdGVkIGZvciBkcmFmdOKAkGZp?= =?utf-8?B?bHNmaWxz4oCQc3ByaW5n4oCQbGFyZ2Utc2NhbGUtaW50ZXJjb25uZWN0?= Thread-Index: AQHR5arAlWenfzZabk2Pau88lDMwKqApFt6A Date: Mon, 25 Jul 2016 08:35:45 +0000 Message-ID: <786FCBA9-A59A-4A32-97AD-E58A32576910@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.207.56] Content-Type: text/plain; charset="utf-8" Content-ID: <586B457C64F2F14D80595CFC564FAB9A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:36:48 -0000 QXMgY28tYXV0aG9yLCBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgdG8g V0cgaXRlbS4NCg0KSeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXNu4oCZdCBiZWVu IGRpc2Nsb3NlZCBhbHJlYWR5Lg0KDQpzLg0KDQoNCj4gT24gSnVsIDI0LCAyMDE2LCBhdCAyOjU1 IFBNLCBKb2huIEcuIFNjdWRkZXIgPGpnc0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0KPiBEZWFy IFdHLA0KPiANCj4gQXMgd2UgZGlzY3Vzc2VkIGF0IG91ciBtZWV0aW5nLCB3b3JraW5nIGdyb3Vw IGFkb3B0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnTigJBmaWxzZmlsc+KAkHNwcmlu Z+KAkGxhcmdlLXNjYWxlLWludGVyY29ubmVjdC4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdp dGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRo ZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLiBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxs eSBlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQo+IA0KPiBXZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBB dWd1c3QgMzEsIDIwMTUuIA0KPiANCj4gQXV0aG9ycywgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIg eW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIGFuZCBpZiBzbywgd2hldGhlciBpdCBo YXMgYmVlbiBkaXNjbG9zZWQuIEFsc28sIHRoZSBsZW5ndGggb2YgdGhlIGF1dGhvciBsaXN0IGZv ciB0aGlzIGRvY3VtZW50IGdyZWF0bHkgZXhjZWVkcyB0aGUgbWF4aW11bSByZWNvbW1lbmRlZC4g QXNzdW1pbmcgdGhlIGRvY3VtZW50IGlzIGFkb3B0ZWQsIHRoZSBhdXRob3JzIHNob3VsZCBiZSBw cmVwYXJlZCB0byBjb3JyZWN0IHRoaXMgd2hlbiBzdWJtaXR0aW5nIGFzIGEgV0cgZG9jdW1lbnQs IGlkZWFsbHkgYnkgcmVkdWNpbmcgdGhlIGxpc3QgdG8gc2ltcGx5IHRoZSBhY3RpdmUgZWRpdG9y KHMpIGFuZCBtYWtpbmcgdXNlIG9mIHRoZSAiY29udHJpYnV0b3JzIiBzZWN0aW9uIGZvciB0aGUg ZnVsbCBsaXN0Lg0KPiANCj4gVGhhbmtzLA0KPiANCj4gLS1CcnVubyBhbmQgSm9obg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3ByaW5n IG1haWxpbmcgbGlzdA0KPiBzcHJpbmdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Mon Jul 25 10:40:36 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43C312D54B for ; Mon, 25 Jul 2016 10:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3VWDXM_kiGC for ; Mon, 25 Jul 2016 10:40:33 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0130.outbound.protection.outlook.com [104.47.40.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A5212D548 for ; Mon, 25 Jul 2016 10:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=URqOAPlo2ARk1KSDoLjbjiROmc3c1bIgcpA3jJ3/OAA=; b=faZoF/onWlpWmR+X6n8MfT1mlDN77GqL/G0ftSGwn6zV7RzKgrWmlQeKohGa4c6Iz5JDTYSnCa3C9b3eq9UoiuzBCXeRiRUHx/BRpwBUxA53QJRXMXywjSyDx0qtLzMpHg5ZEGrPI8GTmbin/VusaBwrgWUG1kXMgINmt3m5OIw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.104] (193.110.55.14) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Mon, 25 Jul 2016 17:40:30 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Mon, 25 Jul 2016 19:40:27 +0200 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: DB4PR06CA0057.eurprd06.prod.outlook.com (10.162.49.25) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: c1c6b368-5cb6-45f6-d939-08d3b4b2c642 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 2:iNDjj/YKYic57FCEQD/+y25vsWvVxNS+ZgmCHBAz+k1cMlpivLNbKLbg0CHZF2/dNMAY0WbcjU29fl7L77Qt7O8kecinn4RNymApo9vhDFPKs4QiBOpAviFDSCDBghLnwpGfitWQOC8m2TmC722RLGDUczccflmuIw+rk3NdyToy4capDpeCQER4NQkRVYiO; 3:3lMWJj+0x4JK8o8Oq+cN8tW3Hbro8xC3EL0Zkrs1IAZJK5meB+HkU+4/P+z6MurdWTzisFLs7s/8Ib0c43HNjerlZPQvi5pE4NGVfC+vuywe1/QSbIdJDHzCnTkryDeJ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 25:TAuqteJHKuVsq1gC8FTP1N3IUbCZ6p8wsecLrnqskFGjmjnfQpu8YcduwpZzJBy+/TZu1DvJi8RqMDz6g6sM0vIW0PuFltxpP1qkdOU3N5Ehc7f9ETVJir9DWMni+2/XClIN2hro0ThJjzjwqLwhPpZd3R1b8UoV4NQlTFMolkyyLDtqaPOcT6FQs+h11XlL+0DjVLKkrMDcBUmHdlWJs5mVWcvJ+HWbiYX1UMOqR0JO6cr4qqMUE7vusof0wdfmg8bIBp/5vbeWvevAy1gYvImge43UzQ55RZW8AIhMhJ0g6LwzhlenOwQ+qACIgGrqlb1wJTDy+BkXIL/62jQvI9WuXY17oP4FAcfyBSYhuFvZcxd+dPWuySNucfp54yYi1FzUE1eJkoTrnBDhGQDtSJkECjU0G/ZLJF8CE1mvY2tYtsvYyyaAoEyM+rGAomsos4ioMLmT9F9ORg2cQBILjQdU0IJhggjlxDCItDFU8SgFGvw4IBuRNLWL28FKr9pA3k7zw9jXWe6RtRhOjdTKlnrdTab23aUc91Ihwy+zL728KaMd25IUUacWmPoECN5xDp1MJFdG2w2lQ3rxW1+5/DBOQy3YEBcwb6w3KJk93dK32L8HKWEhG8FBGk2jGZUgLvTBVMC10S+3iAEfy5R1ZkG3pcqsBwKSbqPuBFST7SGJv3K+528n+4gH1NkXRpgCPAHASVTY4UMcoE78kTMtTclayw776bS0j2FE7uDXxqc/V13jlQiRzGP5mXpBhZKcAzXqPXDTthP8GuKAVb32RjHY9TtN4f7IHlNG2EvV0HDGDe75tJkChCsq6cY08DFN X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:AK/V9l0SGlrAXOhOTFwJ6yfbcFaL8GFq0UxxtEtW2jMf6DKvY1JZOJRZ2u0CChK00/pNMIwxpqLtxdBKlNQGzUdu3TrHCcnyZj7Fx7GQL44//q9zvSHMVeGI1m43L6fTa8dFGkPrNe6GbwRUwx2/woYS/ZfvlaMVELY4y2BiVhrA5O+4lu9UvtuisMbVp3w9ZBzAXY8VWqa95V9A1dfYcQ==; 20:+ma9ixPqFHujj4xgNKfGkfRb0SdpmwRPNko6ZpBTHnCDk+4BCzfblp8z9NRL0IAd401s5xx51S2lkAEdrVt32nLD8kBK5auBJLYSffi0+AHhlI+46hLBvKUlIpPwQKgj6vRzbfM8XtZPwGdaAEHtQoh8SiuKRj9rOyC/mpB2PYkVww0p3ikv6B/3Lu80czsMST7wa/UPMvkVxYqNpoYQ4sqmcCX+xNYi++4cuQixc7drrU7Q2okMNoYMrdChbxx9a+moKAtyeaFLwJlN03w3Y3GkHiGyoivDDC0eeHJPu3unc7Rf7KQlt8nZiKNItCnzD0FlfamqJcIaTi72ttlqXdMu2oPEx0MT+PL8qBEU13YuMP3rv9xksNSYF2COtx7pe+RNddMiGhQj3y9q8XcAjdclNjxFoMjcNFqqHhGUacn34rG2vfRaPIotISUosgRDWHV9jXaPGjLscNNBvx6EImEs5ecT6fA8e7q7wb7WXAqMIfqVMZvlIboJ0ZW7EQ/V X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:bxB8QDVIdOq64Q7O4uqcpZoXAgh6+PAGw0Kg8O7KgzJb15tx7TnwdtshkNmWfanih/rpo7/l+bEnTsP3PRP5+pXRl+YqYGcpGO7H4KDRz/jI31fWmzZptYUPyRCp86x+0SnXdeAIdx/lmEN4kZMAhwqU6DQOIlrxx0jb4YGrjqlhHEjNWrWdY5RiojfXr0L85ZHEB5t9F5pix0b49hqeX1J8MX78QqFCG+Dr6jmRGr/l+ndJnjiItRny5HUJSHZEofmNIH9eC7Xtk2yrAw2GtvLhurxmSMqrbw/TsP+0LB8wrjH0Uvk3utJ8kb2UE/mUprrTTtwdNlUhtLgXFucSznx6DlK7ryBewsJ1YZl1fmAYdFMZEmQD7C46XrRVRQJh X-Forefront-PRVS: 0014E2CF50 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(53754006)(189002)(19580395003)(229853001)(66066001)(2351001)(105586002)(558084003)(97756001)(57306001)(42186005)(101416001)(83716003)(47776003)(106356001)(50466002)(33656002)(86362001)(450100001)(82746002)(6116002)(46406003)(110136002)(50226002)(107886002)(189998001)(81156014)(92566002)(97736004)(77096005)(23726003)(2906002)(81166006)(586003)(7846002)(7736002)(50986999)(305945005)(8746002)(8676002)(36756003)(68736007)(3846002)(15975445007)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.64.104]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:yUDDn+lFw01AU0a2LC6BaX/7WHOxZOjD7OBvInpnF?= =?us-ascii?Q?h7lROeDuRHaLnYskiaGq0k5tvFafPjmGPnqrvdEC8XNA1wqG1wbW8vnnRGZL?= =?us-ascii?Q?omocd+Ktn174W7gwoEGLeNO4JP4bjdVFOWDvdUJe+5muwqZ9XcE2dyF4BCm4?= =?us-ascii?Q?nPnl+Wcsj3CgdrMxf1C223MLhDYMEjbLBkcds3srbXbqtqVeDg2xb0GGX62l?= =?us-ascii?Q?vAl0q2nUHxMQyeBogKKPnmYdDkV2vRo6mabuW8YK0JyEkbONMv+wqTEOTBHD?= =?us-ascii?Q?icGZ3k1XI6fxdxAIspUzIkpHaVbatxjccj+5HwV+jY469m61L3dSjDCVg3DA?= =?us-ascii?Q?IsSWm1crTnezFToaEVhf8XPT0joE4JFqv2S1Lw/lRiClS0zxy+LppW+8lZp8?= =?us-ascii?Q?S78dgsh5bbBeWO17kcFIWGg3Bxkha2/q29al+Mu13iDRPgnpyQ44Y4RCHQH+?= =?us-ascii?Q?hEgawtTYICKikDWgKjqJ5DqQ4XrT+Mdsw9sF3FAhN4TLn4FDSfOFcgEjjZ3u?= =?us-ascii?Q?4N0jnjj+BKSb/unOZujHDAIRooQ/h9a+qxQ3NdgNhaVDfU3/WIc+lurTwtYu?= =?us-ascii?Q?YSyuMH/gJJy+hAtbBVhX/PoBEJOmjP3HK0I7Lh7Q4ZNyO8rgAREYdDvJgMXV?= =?us-ascii?Q?80MPxDX3YCZrvcBkgxoZt9JiT10kpydGJhmrFrcH3xzO3nHCogXfQGzK0BRS?= =?us-ascii?Q?AJMhzSYISowwo6YlUDj3wcJ2nxI5cdS3n5dz1Kxvravb6Dl1lpV3Dk/aKfAI?= =?us-ascii?Q?8VUPM6I6RTZwOlwof7zohirCvwQ6e3CObUG5nwuhLiMlKo5Sn6oi8QYHT7VX?= =?us-ascii?Q?oUNSdKDhGglck7U1zMkVBkmjzTBioySAFroMDFtkFSuMKVtfyz3VgRnN3p2s?= =?us-ascii?Q?Vr0kpCDiCunIZsI4TAYqkYOdqi5CoHntnIhvbvf7eYXZJ7c9uS/WK4LWh1nI?= =?us-ascii?Q?dryL9hFfhXXZXX1QVyXb7LA/omiYenWBnBUPp2L1Xh5IQcNA4yUvK/SpJjpf?= =?us-ascii?Q?9RPBXrLc0kMWfU/q0FaTINZzTeTYoD6rNf8NzQYYr7thYJ93UWaSINzOJLMr?= =?us-ascii?Q?QQ0IeGm2To9IYsAqp7qgI3scrjOmgYTFJnTCChIDEV30cITMM6wR8SvYLD11?= =?us-ascii?Q?eyDiygs0VN9epVD/6S5zsQae446BVNlY4kTqnD8e81ZC7KcvrPB8AMD+QMPn?= =?us-ascii?Q?an+i3n0XsFAqxqjVwNYNPMedpZtS3n1lITbsh9x5W7/tYSdCgFqDjkLTnPFk?= =?us-ascii?Q?g7bVDNRX27XRpg4RYg=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:PSXo9zb6HxDXjx/hc3t8xXLDq1YC4RygGUJNDbno4h830cMA139gZLNxn5AmGVTRzPdsYu6/5kBbkqw8AgvgcMApshfdc6dByAFFT7paUqBL+1CeLtKWB0+IdjGkwCJ8xN8/1nLVuIU57BUScoKOA9e9Q0C5DU0UTdQuAc2b9mewVSpSRo4F8NE7N+PDzQJxK21DQNyXT2uWV//qQ9ZUiLBwOhdiWUmf4yn+ShgyYY/lQGdD+LKb9NTOwKX83uxs++xzIiuBEcVxwlzYH4gbAq09O+76UZpxHugzY5RR9ELnLP/iT/VLdLtFCiMSF/QlDFt44Rr1/GE2KomNAKDTUw==; 5:EltGqSdR0HgLHGNm3WfL2Ov+8odK81jk614rD0D+sQabmpp8bmqPNDzJyQ6Ys4E59tsqOYOUd0Brh4aI1oqamTfXaHE9u2ttF9PTNNJ6mArrOEOsQIuGDE90sZ9ruUnpWH6KbBMSNT8QHq9JvdGJMg==; 24:BEjUKyHExgNIHhCASGAndAdD/hoSRXqbFQTiABqI3eG6qUvgAhm26zPKt7RfENWZknmrfNtjIGZyvZxgBUxBF8G0oUMeiXsnadATbF2tKOk=; 7:3rxmoIr6vv44nd6UZFU/3KRRYbu4xhkl5DHdu5rAt5/hIIocOuO5q6nGX2TYpCsoGtVwdZhOA3TjSRMHgfsNE38VhTUwIaQOIvEEp5b2Zqig7jJpro1oNpoqb8xdKyVgjtiq9/Wl35W5VYYuSVrqKnkr0pJ/EILAxFjbd1yYB7xdBwnLtSCHPBJc/YmNdevwMfoO3xGJFIBvfcH0UB5BFDkUOuAOzKCx5ekK+aAdCaoMkDMaLJcWJ2MUktcxRd8P SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jul 2016 17:40:30.5493 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: [spring] Minutes of IETF-96 SPRING posted X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 17:40:36 -0000 Hi Everyone, Minutes are now available at = https://www.ietf.org/proceedings/96/minutes/minutes-96-spring. Please = send any corrections or comments to the list. Thanks to Wim for the = notes! --John= From nobody Mon Jul 25 12:19:11 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A0A12D94A for ; Mon, 25 Jul 2016 12:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoincNYRl0GI for ; Mon, 25 Jul 2016 12:19:06 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3D912D5C8 for ; Mon, 25 Jul 2016 12:19:05 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 535BEF85374CA; Mon, 25 Jul 2016 19:19:01 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6PJJ3JA004347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jul 2016 19:19:03 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6PJJ2OT027296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jul 2016 19:19:03 GMT Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.7]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 25 Jul 2016 15:19:02 -0400 From: "Aissaoui, Mustapha (Nokia - CA)" To: "Henderickx, Wim (Nokia - BE)" , "Martin Horneffer" , "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwAAFyNVQACk7FpAAGrmsQACp0a4wACubJnAAAvwWgAAUDtkgA05pB4AAASYAAAAEtIbg Date: Mon, 25 Jul 2016 19:19:01 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340DD49C6D94@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> <91fcbdba712143e890609f6a513f8528@XCH-ALN-001.cisco.com> <2921_1467708583_577B74A7_2921_256_5_53C29892C857584299CBF5D05346208A0F92B91D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <73326a2e-90d2-1af8-689c-0cc08f396ad6@nic.dtag.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340DD49C6D94US70UWXCHMBA01z_" MIME-Version: 1.0 Archived-At: Cc: "Horneffer, Martin" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 19:19:10 -0000 --_000_4A79394211F1AF4EB57D998426C9340DD49C6D94US70UWXCHMBA01z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2ltIGFuZCBhbGwsDQpvbmUgb3BlcmF0aW9uYWwgYXNwZWN0IGluIGZhdm9yIG9mIGlnbm9y aW5nIG9ubHkgdGhlIGxlc3MgcHJlZmVycmVkIGVudHJ5IHdoaWNoIGFjdHVhbGx5IGNvbmZsaWN0 cyBpcyB0aGF0IGZvciBhIGdpdmVuIHByZWZpeCwgYSBTSUQgdmFsdWUgcmVjZWl2ZWQgaW4gYSBw cmVmaXggVExWIGlzIGFsd2F5cyBwcmVmZXJyZWQgb3ZlciBhIFNJRCB2YWx1ZSByZWNlaXZlZCBp biBhIG1hcHBpbmcgc2VydmVyIHByZWZpeCByYW5nZSBUTFYuIFdpdGggdGhlIHF1YXJhbnRpbmUg bWV0aG9kLCB5b3Ugd2lsbCBtb3JlIG9mdGVuIHB1dCB0aGUgZW50aXJlIG1hcHBpbmcgc2VydmVy IHJhbmdlIFRMViBpbiBxdWFyYW50aW5lIHdoaWNoIHdpbGwgYmUgdG9vIGRpc3J1cHRpdmUuDQoN Ck11c3RhcGhhLg0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEhlbmRlcmlja3gsIFdpbSAoTm9raWEgLSBCRSkNClNlbnQ6IEZyaWRh eSwgSnVseSAyMiwgMjAxNiA1OjM1IEFNDQpUbzogTWFydGluIEhvcm5lZmZlcjsgTGVzIEdpbnNi ZXJnIChnaW5zYmVyZyk7IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K Q2M6IEhvcm5lZmZlciwgTWFydGluDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtaWV0Zi1z cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGljeQ0KDQpBcyAxIG9mIHRoZSB2ZW5kb3Jz IGltcGxlbWVudGluZyB0aGlzLCB3ZSBwcmVmZXIgdGhlIGFwcHJvYWNoIG9mIGlnbm9yZSBvdmVy bGFwIGFzIEkgc2FpZCBpbiB0aGUgbWVldGluZyBpbiBCZXJsaW4NClRoZSBpbXBsaWNhdGlvbiBm cm9tIGltcGxlbWVudGF0aW9uIHMgYXJlIG5vdCBtYXNzaXZlIGFuZCBnaXZlbiBpdCBpcyBtYXhp bWlzaW5nIHRyYWZmaWMgZGVsaXZlcnkgaW4gY2FzZSBvZiBjb25mbGljdCwgd2UgcHJlZmVyIHRo aXMgYXBwcm9hY2guDQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hcnRpbiBIb3JuZWZm ZXIgPG1haG9AbmljLmR0YWcuZGU8bWFpbHRvOm1haG9AbmljLmR0YWcuZGU+Pg0KRGF0ZTogRnJp ZGF5IDIyIEp1bHkgMjAxNiBhdCAxMTowMQ0KVG86ICJMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSIg PGdpbnNiZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tPj4sICJzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4iIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4+DQpDYzogTWFydGluIEhvcm5lZmZlciA8TWFydGluLkhvcm5lZmZl ckB0ZWxla29tLmRlPG1haWx0bzpNYXJ0aW4uSG9ybmVmZmVyQHRlbGVrb20uZGU+Pg0KU3ViamVj dDogUmU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBQ b2xpY3kNCg0KSGkgTGVzLA0KDQpjb21tZW50aW5nIHJhdGhlciBvbiB5b3VyIHByZXNlbnRhdGlv biBhdCB0aGUgQmVybGluIFdHIHNlc3Npb246DQoNCkluIGdlbmVyYWwgSSBkb24ndCBjb25zaWRl ciBpdCBhIGJpZyBkZWFsIHdoZXRoZXIgdGhlIFF1YXJhbnRpbmUgb3IgdGhlIElnbm9yZSBPdmVy bGFwIHBvbGljeSBpcyBiZWluZyB1c2VkLiBJdCdzIG1haW5seSBpbXBvcnRhbnQgdGhhdCBfb25l XyBvZiB0aGVuIGZpbmFsbHkgZ2V0cyBjaG9zZW4gYW5kIGNvbnNpc3RlbnRseSBpbXBsZW1lbnRl ZC4NCg0KRnJvbSB0aGUgb3BlcmF0b3IncyBwb2ludCBvZiB2aWV3IEkgdGVuZCB0byBhZ3JlZSB3 aXRoIG90aGVyIG9wZXJhdG9ycyB0aGF0IHRoZSBJZ25vcmUgT3ZlcmxhcCBwb2xpY3kgbG9va3Mg YmV0dGVyIGZvciBtb3N0IHJlYWxpc3RpYyBjYXNlcywgZXZlbiB0aG91Z2ggbGVzcyB3b3JyaWVk IGFib3V0IHRoZSBhbW91bnQgb2YgdHJhZmZpYyBsb3N0LCBidXQgbW9yZSBhYm91dCByb2J1c3Ru ZXNzIGFuZCBzZWN1cml0eSBhc3BlY3RzLg0KDQpDb21wbGV4aXR5IG9mIGltcGxlbWVudGF0aW9u LCBob3dldmVyLCBjYW4gYmUgYSBzZXJpb3VzIGFyZ3VtZW50IGFnYWluc3QgaXQsIGFzIHRoaXMg YWxzbyB3b3JrcyBhZ2FpbnN0IHJvYnVzdG5lc3MgYW5kIHNlY3VyaXR5Lg0KDQpOb2JvZHkgZG91 YnRzIHRoYXQgdGhlIElnbm9yZSBPdmVybGFwIHBvbGljeSBpcyBtb3JlIGNvbXBsZXguIEJ1dCBo b3cgbXVjaCBjb21wbGV4aXR5IGl0IHJlYWxseSBhZGRzIGlzIGhhcmQgdG8gZXN0aW1hdGUgZm9y IG1lLiBJcyBpdCBhIG1pbm9yIGNvbXBsaWNhdGlvbiBvciBhIGJpZyBvbmU/DQoNClNvIGZhciBJ IGhhdmUgc2VlbiBvbmUgdmVuZG9yIHRhbGsgYWdhaW5zdCB0aGUgSWdub3JlIE92ZXJsYXAgcG9s aWN5IGFuZCB0d28gdmVuZG9ycyB0YWtpbmcgYSBwb3NpdGlvbiBpbiBmYXZvciBvZiBpdC4NCg0K U291bmRzIHRvIG1lIGxpa2UgMjoxIGZvciBJZ25vcmUgT3ZlcmxhcCBzbyBmYXIuIEJ1dCB3ZSBh Y3R1YWxseSBkb24ndCBiZWxpZXZlIGluIHZvdGluZyBhbmQgbmVlZCBtb3JlIHZlbmRvciBpbnB1 dCBhbnl3YXlzIQ0KDQpCUiwNCk1hcnRpbg0KDQoNCkFtIDA1LjA3LjE2IHVtIDE5OjI1IHNjaHJp ZWIgTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk6DQpCcnVubyDigJMNCg0KVHdvIGNvbW1lbnRzOg0K DQoxKUFzIHdlIGJvdGggY2FuIGNvbWUgdXAgd2l0aCBleGFtcGxlcyB3aGVyZSBhIGdpdmVuICBw cmVmZXJlbmNlIGFsZ29yaXRobSB3aWxsIHJlc3VsdCBpbiDigJxiZXR0ZXLigJ0gYmVoYXZpb3Ig dGhhbiBhbm90aGVyLCBjb250aW51aW5nIHRvIGRlYmF0ZSB3aGljaCBvbmUgaXMg4oCcYmVzdOKA nSBoYXMgbm8gZW5kLiBUaGUgYW5zd2VyIGRlcGVuZHMgdXBvbiB3aGF0IHR5cGVzIG9mIGVycm9y cyBhcmUgaW50cm9kdWNlZCBpbiB0aGUgY29uZmlndXJhdGlvbiBhbmQgdGhhdCBpc27igJl0IHBy ZWRpY3RhYmxlLiBJZiBpdCBpcyBuZWNlc3NhcnkgZm9yIHVzIHRvIGFncmVlIG9uIHdoaWNoIGFs Z29yaXRobSBpcyDigJxiZXN04oCdIEkgZG91YnQgdGhhdCBjb25zZW5zdXMgd2lsbCBldmVyIGJl IHJlYWNoZWQuIEl0IHRoZXJlZm9yZSBpcyBtb3JlIGltcG9ydGFudCB0byBtZSB0byBmb2N1cyBv biBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IGFuZCB0aGUgaW1wb3J0YW5jZSBvZiBpZGVudGlm eWluZyBhbmQgY29ycmVjdGluZyBtaXNjb25maWd1cmF0aW9ucyBBU0FQLg0KDQoyKVRoZXJlIGFy ZSB0d28gbG9naWNhbCBkYXRhYmFzZXMgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgdG8gc3Vw cG9ydC4gT25lIG9mIHRoZW0gaXMgdGhlIHNldCBvZiByZWNlaXZlZCBhZHZlcnRpc2VtZW50cyB3 aGljaCBjYW4gaW5jbHVkZSBlbnRyaWVzIHdpdGggYSB2YXJpZXR5IG9mIHJhbmdlcy4gVGhlIHNl Y29uZCBvbmUgaXMgdGhlIHNldCBvZiBtYXBwaW5nIGVudHJpZXMgd2hpY2ggYXJlIGluIHVzZSBm b3IgbG9va3Vwcy4NCllvdXIgZGlzY3Vzc2lvbiBvZiB5b3VyIOKAnHBlciBGRUMgYWxnb3JpdGht 4oCdICBiZWxvdyBkZWZpbmVzIHRoZSBzZWNvbmQgZGF0YWJhc2UgYXMgYSBzZXQgb2YgZW50cmll cyBhbGwgb2Ygd2hpY2ggaGF2ZSBhIHJhbmdlIG9mIDEuIFdoZXRoZXIgdGhpcyBpcyBnb29kIGlt cGxlbWVudGF0aW9uIG1vZGVsIG9yIG5vdCBJIGFtIG5vdCBjb21tZW50aW5nIG9uIGhlcmUuIEJ1 dCB0aGlzIGRvZXMgbm90IGVsaW1pbmF0ZSB0aGUgbmVlZCB0byBtYWludGFpbiB0aGUgZmlyc3Qg ZGF0YWJhc2Ug4oCTIGFuZCB0byBiZSBhYmxlIHRvIGFzc29jaWF0ZSBlbnRyaWVzIGluIHRoZSBz ZWNvbmQgZGF0YWJhc2Ugd2l0aCB0aGUgY29ycmVzcG9uZGluZyByZWNlaXZlZCBlbnRyeSBmcm9t IHdoaWNoIHRoZXkgbWF5IGhhdmUgYmVlbiBkZXJpdmVkLiBUaGVyZSBpcyB3b3JrIGluIG1haW50 YWluaW5nIHRoYXQgcmVsYXRpb25zaGlwIHdoaWNoIGRvZXMgbm90IGRpcmVjdGx5IGJlYXIgb24g dGhlIGxvb2t1cCBmb3IgYSBnaXZlbiBTSUQgYnV0IHN0aWxsIGhhcyB0byBiZSBkb25lIGlmIG9u ZSB1c2VzIOKAnHBlciBGRUPigJ0gb3Ig4oCcSWdub3JlIE92ZXJsYXAgT25seeKAnS4gVGhpcyB3 b3JrIGlzIG5vdCByZXF1aXJlZCBmb3IgdGhlIOKAnHBlciByYW5nZeKAnSBvciDigJxRdWFyYW50 aW5l4oCdIGFsZ29yaXRobS4gSXQgaXMgdGhpcyBhZGRpdGlvbmFsIHdvcmsgdGhhdCBJIHJlZmVy IHRvIHdoZW4gSSBzYXkgdGhhdCDigJxwZXIgRkVD4oCdIGhhcyBhIGhpZ2hlciBpbXBsZW1lbnRh dGlvbiBjb3N0L2NvbXBsZXhpdHkuDQoNCiAgIExlcw0KDQoNCkZyb206YnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4gW21haWx0bzpicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAwNSwgMjAxNiAxOjUw IEFNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25m bGljdC1yZXNvbHV0aW9uIC0gUG9saWN5DQoNCkxlcywNCg0KUGxlYXNlIHNlZSBpbmxpbmUgW0Jy dW5vXQ0KDQpGcm9tOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSBbbWFpbHRvOmdpbnNiZXJnQGNp c2NvLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDUsIDIwMTYgOTowOCBBTQ0KVG86IERFQ1JB RU5FIEJydW5vIElNVC9PTE4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u IC0gUG9saWN5DQoNCkJydW5vIOKAkw0KDQpDb25zaWRlciB0aGUgZm9sbG93aW5nIHNpbXBsZSBj YXNlOg0KDQpFbnRyeSAjMTogKFBGWCwgMS4xLjEuMS8zMiwgMTAwLCAxLCAwLDApDQpFbnRyeSAj MjogKFNSTVMsIDEuMS4xLjEvMzIsIDIwMCwgMTAsIDAsMCkNCkVudHJ5ICMzOiAoU1JNUywgMi4y LjIuMi8zMiwgMjAwLCAxMC4gMCwgMCkNCg0KVGhlcmUgaXMgYSBtaXNjb25maWd1cmF0aW9uIGhl cmUsIGJ1dCB3ZSBkb27igJl0IGtub3cgd2hhdCB3YXMgcmVhbGx5IGludGVuZGVkLiBBIGZldyAo b2YgbWFueSkgcG9zc2liaWxpdGllczoNCg0KRVJST1IgIzE6ICAgRW50cnkgIzIgc2hvdWxkIGhh dmUgYmVlbjogKFNSTVMsIDEuMS4xLjEvMzIsIDEwMCwgMTAsIDAsMCkgIVN0YXJ0aW5nIFNJRCBl cnJvcg0KRVJST1IgIzI6ICBFbnRyeSAjMiBzaG91bGQgaGF2ZSBiZWVuOiAoU1JNUywgMi4yLjIu Mi8zMiwgMjAwLCAxMCwgMCwwKSAhU3RhcnRpbmcgcHJlZml4IGVycm9yDQoNClRoZSBkcmFmdCBk ZWZpbmVzIHR3byBjYW5kaWRhdGUgcHJlZmVyZW5jZSBydWxlcyB3aGljaCBjb3VsZCBiZSBhcHBs aWVkOg0KDQpRdWFyYW50aW5lDQotLS0tLS0tLS0tLS0tLS0tDQpBcyB3ZSBldmFsdWF0ZSBwcmVm aXggY29uZmxpY3RzIGZpcnN0LCB3ZSBjb21wYXJlIEVudHJ5ICMxIGFuZCBFbnRyeSAjMiBhbmQg Y2hvb3NlIEVudHJ5ICMxIHRoZSB3aW5uZXIgKHNvdXJjZSBpcyBQRlgpLiBFbnRyeSAjMiBpcyB0 aGVuIG5vdCB1c2VkIChxdWFyYW50aW5lZCkgYW5kIHRoZSBzZXQgb2YgYWN0aXZlIGVudHJpZXMg aXM6DQoNCkVudHJ5ICMxOiAoUEZYLCAxLjEuMS4xLzMyLCAxMDAsIDEsIDAsMCkNCkVudHJ5ICMz OiAoU1JNUywgMi4yLjIuMi8zMiwgMjAwLCAxMC4gMCwgMCkNCg0KSWdub3JlIENvbmZsaWN0IE9u bHkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkluIHRoaXMgY2FzZSB3ZSBzcGxpdCBFbnRy eSAjMiBpbnRvIHR3byBkZXJpdmVkIGVudHJpZXM6DQoNCkVudHJ5ICMyQTogKFNSTVMsIDEuMS4x LjEvMzIsIDIwMCwgMSwgMCwwKQ0KRW50cnkgIzJCOiAoU1JNUywgMS4xLjEuMi8zMiwgMjAxLCA5 LCAwLDApDQoNCkVudHJ5IDJBIGlzIHRoZW4gaWdub3JlZCBhbmQgd2UgdGhlbiBoYXZlIHRvIGV2 YWx1YXRlIFNJRCBjb25mbGljdHMgYmV0d2VlbiB0aGUgZGVyaXZlZCBlbnRyeSAyQiBhbmQgRW50 cnkgIzMuICBGb3IgdGhpcyB3ZSBoYXZlIHRvIHNwbGl0IEVudHJ5IDMgaW50byB0d28gZGVyaXZl ZCBlbnRyaWVzOg0KDQpFbnRyeSAjM0E6IChTUk1TLCAyLjIuMi4yLzMyLCAyMDAsIDEuIDAsIDAp DQpFbnRyeSAjM0I6IChTUk1TLCAyLjIuMi4zLzMyLCAyMDEsIDkuIDAsIDApDQoNCkVudHJ5IDJC IHdpbnMgb3ZlciBlbnRyeSAzQiBzaW5jZSBpdCBoYXMgYSBzbWFsbGVyIHJhbmdlLg0KDQpBY3Rp dmUgZW50cmllcyBhcmUgdGhlbjoNCkVudHJ5ICMxOiAoUEZYLCAxLjEuMS4xLzMyLCAxMDAsIDEs IDAsMCkNCkVudHJ5ICMyQjogKFNSTVMsIDEuMS4xLjIvMzIsIDIwMSwgOSwgMCwwKQ0KRW50cnkg IzNBOiAoU1JNUywgMi4yLjIuMi8zMiwgMjAwLCAxLiAwLCAwKQ0KDQpOb3RlIHRoYXQgaW4gdGhp cyBleGFtcGxlIGJvdGggcHJlZmVyZW5jZSBydWxlcyByZXN1bHQgaW4gMTEgZGVzdGluYXRpb25z IGhhdmluZyBub24tY29uZmxpY3RpbmcgU0lEcy4NCltCcnVub10gWWVzLiBUaGUgaW1wb3J0YW50 IHBhcnQgaXMgwqsgaW4gdGhpcyBleGFtcGxlIMK7LiBOb3cgZG8gd2UgYWdyZWUgdGhhdCBpbiBh dmVyYWdlLCBRdWFyYW50aW5lIHdpbGwgcmVzdWx0IGluIGRyb3BwaW5nIG1vcmUgZGVzdGluYXRp b25zIHRoYW4gSWdub3JlIGNvbmZsaWN0IG9ubHk/DQoNCiBOb3csIHdoaWNoIG9mIHRoZXNlIG1h eGltaXplcyBkZWxpdmVyeSBvZiB0cmFmZmljPyBUaGUgYW5zd2VyIHRvIHRoYXQgZGVwZW5kcyB1 cG9uIHRoZSB0eXBlIG9mIGNvbmZpZ3VyYXRpb24gZXJyb3IgdGhhdCB3YXMgbWFkZS4NCklmIEVy cm9yICMxIHdhcyBtYWRlLCB0aGVyZSBpcyBubyB3YXkgdG8gZGlmZmVyZW50aWF0ZSB0aGUgdHdv IHByZWZlcmVuY2UgcnVsZXMuDQpIb3dldmVyLCBpZiBFcnJvciAjMiB3YXMgbWFkZSwgdGhlbiBR dWFyYW50aW5lIGlzIGNsZWFybHkgYmV0dGVyIGJlY2F1c2UgdGhlIGRlc3RpbmF0aW9ucyAxLjEu MS4yIOKAkyAxLjEuMS4xMCB3ZXJlIG5ldmVyIGludGVuZGVkIHRvIGhhdmUgYXNzaWduZWQgU0lE cyBhbmQgbWF5IG5vdCBldmVuIGV4aXN0IGFzIGRlc3RpbmF0aW9ucyBpbiB0aGUgbmV0d29yaywg eWV0IOKAnElnbm9yZSBDb25mbGljdCBPbmx54oCdIGZhdm9ycyB0aG9zZSBwcmVmaXhlcy4NCg0K VGhlIHBvaW50IEkgYW0gdHJ5aW5nIHRvIG1ha2UgaXMgdGhhdCBpdCBpcyBpbmNvcnJlY3QgdG8g c2F5IOKAnElmIHdlIG1heGltaXplIHRoZSBudW1iZXIgb2YgYWR2ZXJ0aXNlZCBlbnRyaWVzIHdo aWNoIHdlIHVzZSB3ZSB3aWxsIGFsd2F5cyBkbyBhIGJldHRlciBqb2Igb2YgZGVsaXZlcmluZyB0 cmFmZmljLuKAnSBUaGlzIGV4YW1wbGUgaWxsdXN0cmF0ZXMgdGhhdCB0aGlzIGlzbuKAmXQgYWx3 YXlzIHRydWUuDQpbQnJ1bm9dIE9LLiBDbGVhcmx5LCB3ZSBjYW4gZmluZCBhbiBleGFtcGxlIHdo ZXJlIGFuIGFsZ29yaXRobSBpcyBiZXR0ZXIgdGhhbiB0aGUgb3RoZXIuIEFmdGVyIGFsbCwgd2Ug YWxsIGFncmVlIHRoYXQgdGhlcmUgaGFzIGJlZW4gYSBjb25maWd1cmF0aW9uIGVycm9yLg0KVGhl cmUgYXJlIDIgcG9pbnRzOg0KDQphKSAgICAgIGhvdyBtYW55IGRlc3RpbmF0aW9uIHlvdSBrZWVw IHVzaW5nDQoNCmIpICAgICAgaW4gY2FzZSBvZiBjb25mbGljdCB3aGljaCBvZiB0aGUgZW50cmll cyB5b3Ugc2VsZWN0DQoNCkkgYWdyZWUgdGhhdCDigJxi4oCdIGlzIG1vcmUgb3IgbGVzcyByYW5k b20gYW5kIGhlbmNlIHRoZXJlIGFyZSBtYW55IGNhc2VzIHdoZXJlIHdl4oCZbGwgcGljayB0aGUg d3Jvbmcgb25lLiBZZXQsIHdlIHRyeSB0byBtYWtlIHJlYXNvbmFibGUgY2hvaWNlcy4gVGhhdCB0 aGUgcG9pbnQgb2YgZGlzY3Vzc2luZyB0aGUgcHJlZmVyZW5jZSBhbGdvcml0aG0gKDMuMi40KS4g KEFsdGhvdWdoIGl04oCZcyB2ZXJ5IGVhc3kgdG8gYXJndWUgdGhhdCB3ZSBjYW4gbWFrZSB0aGUg d3JvbmcgY2hvaWNlLCBJIGRvbuKAmXQgZmVlbCB0aGF04oCZcyBhIHJlYXNvbiBub3QgdG8gdHJ5 IGRpc2N1c3NpbmcgaXQgYW5kIG1ha2UgY2hvaWNlLiBlLmcuIOKAnFBGWCBzb3VyY2Ugd2lucyBv dmVyIFNSTVMgc291cmNl4oCdIGlzIG9uZTogd2UgZ2l2ZSBwcmVmZXJlbmNlIHRvIFNSIG5vZGVz IHJhdGhlciB0aGFuIExEUCBub2Rlcy4NCg0KUmVnYXJkaW5nIGEsIEkgZmVlbCB0aGF0IG1heGlt aXppbmcgdGhlIG51bWJlciBvZiBkZXN0aW5hdGlvbnMga2VwdCwgaXMgbGlrZWx5IHRvIGdpdmUg dGhlIGJlc3QgcmVzdWx0IGluIGF2ZXJhZ2UuIEkgZG9u4oCZdCBoYXZlIGEgcHJvb2YsIGJ1dCBp dCBmZWVsIGxpa2UgcGxheWluZyBsb3RvOiBldmVuIGlmIGVhY2ggY2hvaWNlIGlzIHJhbmRvbSAo 4oCcYuKAnSksIHRoZSBtb3JlIHlvdSB0cnkgKOKAnGHigJ0pIHRoZSBiZXR0ZXIgeW91ciBjaGFu Y2VzLg0KDQoNCkEgZmV3IG1vcmUgY29tbWVudHMgaW5saW5lLg0KDQoNCkZyb206YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4gW21haWx0 bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tXQ0KU2VudDogTW9uZGF5LCBKdWx5IDA0LCAyMDE2 IDU6MDcgQU0NClRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KQ2M6IHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtc3ByaW5n LWNvbmZsaWN0LXJlc29sdXRpb24gLSBQb2xpY3kNCg0KTGVzLA0KDQpQbGVhc2Ugc2VlIGlubGlu ZSBbQnJ1bm9dDQoNCg0KRnJvbTogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgW21haWx0bzpnaW5z YmVyZ0BjaXNjby5jb21dDQpTZW50OiBGcmlkYXksIEp1bHkgMDEsIDIwMTYgMzoxMiBBTQ0KVG86 IERFQ1JBRU5FIEJydW5vIElNVC9PTE4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNv bHV0aW9uIC0gUG9saWN5DQoNCkJydW5vIOKAkw0KDQpJIGRvbuKAmXQgZmluZCB5b3VyIHJlcHJl c2VudGF0aW9uIGNvbXBsZXRlIGFzIHJlZ2FyZHMgYWxsIG9mIHRoZSBhdHRyaWJ1dGVzIHdoaWNo IGFyZSBwcm9wb3NlZCB0byBiZSB1c2VkIGJ5IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIGFsZ29y aXRobSDigJMgc28gaXQgaXMgdGhlcmVmb3JlIGhhcmQgZm9yIG1lIHRvIHVzZS91bmRlcnN0YW5k IHRoaXMgcmVwcmVzZW50YXRpb24gd2hlbiBhcHBseWluZyB0aGUgZGVmaW5lZCBwcmVmZXJlbmNl IHJ1bGUuDQpUaGlzIGlzIHRydWUgZm9yIG1lIGV2ZW4gYWZ0ZXIgcmVhZGluZyB5b3VyIGV4cGxh bmF0aW9ucyBiZWxvdy4NCg0KQnV0IGl0IGlzIGZhciBtb3JlIGltcG9ydGFudCB0byBoYXZlIGEg Y29tbW9uIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGFsZ29yaXRobSBwcm9wb3NhbCB0aGFuIGl0IGlz IHRvIGJlIGFyZ3Vpbmcgb3ZlciB3aG9zZSBlbmNvZGluZyBpcyDigJxiZXR0ZXLigJ0uIElmIHRo ZSBlbmNvZGluZyBpbiB0aGUgZHJhZnQgaXMgbm90IGNsZWFyIG9yIGNvdWxkIHVzZSBpbXByb3Zl bWVudCwgSSB3ZWxjb21lIHlvdXIgZmVlZGJhY2suDQoNCkFzIGZhciBhcyB5b3VyIOKAnHBzZXVk by1jb2Rl4oCdOg0KDQotIEZpbmQgYWxsIFNJRGkgYWR2ZXJ0aXNlZCBmb3IgdGhlIHByZWZpeCBQ MSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLy8gaWRlbnRpZmljYXRpb24gb2YgUHJlZml4IGNvbmZsaWN0cw0KICAgICAgICAgICAgICAg IC0gRm9yIGVhY2ggU0lEaSBmaW5kIGFsbCB0aGUgcHJlZml4IFBpaiBhc3NvY2lhdGVkIHdpdGgg U0lEaSAgICAgICAgICAgICAgLy8gaWRlbnRpZmljYXRpb24gb2YgU0lEIGNvbmZsaWN0cw0KDQpH ZXQgdGhlIGJlc3QgYXMgcGVyIHRoZSBwcmVmZXJlbmNlIGFsZ29yaXRobS4NCklmIGJlc3QgUGlq ID09IFAxDQogICAgICAgICAgICAgICAgdGhlbiB1c2UgU0lEaWogZm9yIFAxDQogICAgICAgICAg ICAgICAgZWxzZSByZXR1cm4gbm8gU0lEDQoNClRoZSBmYWN0IHRoYXQgeW91IGNhbiByZXByZXNl bnQgYW4gYWxnb3JpdGhtIGluIGEgZmV3IGxpbmVzIGRvZXMgbm90IG1lYW4gdGhlIGltcGxlbWVu dGF0aW9uIG9mIHRoZSBhbGdvcml0aG0gaXMganVzdCBhcyBzaW1wbGUuDQoNCltCcnVub10gU3Vy ZS4gQnV0IGlmIHdlIHdhbnQgdG8gY29tcGFyZSBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LCB3 ZeKAmWxsIG5lZWQgdG8gYWdyZWUgb24gaG93IG11Y2ggd2Ugd2FudCB0byBnbyBpbnRvIGRldGFp bHMsIGluIG9yZGVyIHRvIGhhdmUgbWVhbmluZ2Z1bCBjb21wYXJpc29uLiBTbyBmYXIgdGhpcyBp cyBub3QgY2xlYXIgdG8gbWUgYXMgeW91IHNvbWV0aW1lcyBhcmd1ZSB0aGF0IGRhdGEgc3RydWN0 dXJlIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRvIGdv IGludG8gdGhpcyAod2hpY2ggSSBhZ3JlZSkgYW5kIHNvbWV0aW1lIHlvdSBkZXRhaWwgdGhlIGRh dGEgc3RydWN0dXJlLg0KVGhlcmUgaXMgYWxzbyB0aGUgb3B0aW9uIHRvIGNvbnNpZGVyIHRoaXMg YXMg4oCcaW1wbGVtZW50YXRpb24gaXNzdWXigJ0gYW5kIGxldCB0aGlzIHRvIGltcGxlbWVudGF0 aW9ucy4NCg0KQ29taW5nIGJhY2sgdG8gbXkgcGVyIEZFQyBhbGdvLCBhbGwgd2hhdCBpcyByZXF1 aXJlZCBmcm9tIHRoZSBkYXRhIHN0cnVjdHVyZSwgaXMgYSB3YXkvQVBJIHRvIGdldCB0aGUgZGF0 YSBiYWNrLCB0aG91Z2ggMiBrZXlzOiBnZXQgbWUgdGhlIFNJRCBtYXRjaGluZyBwcmVmaXggUDEg KGZvciB0aGUgZmlyc3QgbGluZSksIGdldCBtZSB0aGUgcHJlZml4ZXMgbWF0Y2hpbmcgdGhlIFNJ RCBTSURpIGZvciB0aGUgc2Vjb25kIGxpbmUuIFRoYXQgc2VlbSBsaWtlIGEgcmVhc29uYWJsZSBy ZXF1aXJlbWVudCBvbiB0aGUgZGF0YSBzdHJ1Y3R1cmUsIGFuZCBhbnkgb3B0aW9uIGluIHlvdXIg ZHJhZnQgYWxzbyByZXF1aXJlcyB0aGlzIHRvIGRldGVjdCBwcmVmaXggY29uZmxpY3QgYW5kIFNJ RCBjb25mbGljdCAoc2luY2UgdGhpcyBpcyBhbGwgbXkgcGVyIEZFQyBhbGdvIGlzIGRvaW5nIGlu IHRoZXNlIDIgZmlyc3QgbGluZXMpLg0KDQpHb2luZyBpbnRvIG1vcmUgZGV0YWlscywgbXkgcGVy IEZFQyBhbGdvIG9ubHkgcmVxdWlyZXMgdG8gZGV0YWlsIHRoYXQgb25lIHByZWZpeCBvciBTSUQg YmVsb25nIHRvIGEgcmFuZ2UgKG9mIHByZWZpeCBvciBTSUQpIHdoaWxlIHlvdXIgcGVyIHJhbmdl IGFsZ28gcmVxdWlyZXMgdG8gY29tcHV0ZSByYW5nZSBpbnRlcnNlY3Rpb24gd2hpY2ggaXMgaGFy ZGVyLiBTbyB0aGUgQVBJIHRvIGZldGNoIHRoZSBkYXRhIGNhbiBvbmx5IGJlIGVhc2llci4NCg0K DQpbTGVzOl0gUmFuZ2UgaW50ZXJzZWN0aW9uIGlzIGVhc3kgdG8gY29tcHV0ZSDigJMgdGhlIGFs Z29yaXRobSBpcyBwcmVzZW50IGluIHRoZSBkcmFmdCBhdCB0aGUgZW5kIG9mICBTZWN0aW9uIDMu MS4xLg0KW0JydW5vXSBJbiBvcmRlciB0byBoYXZlIGEgbWVhbmluZ2Z1bCBkaXNjdXNzaW9uLCB3 ZSBuZWVkIHRvIGRlZmluZSB0aGUgbGV2ZWwgb2YgZGV0YWlscyB0aGF0IHdlIHdhbnQgdG8gdGFr ZSBpbnRvIGFjY291bnQsIGJlY2F1c2UgeW914oCZcmUgbm90IHVzaW5nIHRoZSBzYW1lIG9uZSB0 byBkaXNjdXNzIHlvdXIgYWxnbyBhbmQgbWluZS4NCjEpIEFzIGEgZmlyc3QgbGV2ZWwgb2YgY29t cGFyaXNvbiwgdXNpbmcgdGhlIGRlc2NyaXB0aW9uIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiAzLjEu MSBhcyBhIG1vZGVsLCBmb3IgcmFuZ2UgcHJlZml4IGNvbmZsaWN0IHlvdXIgYWxnbyBpczoNCiAg IDEpKFQxID09IFQyKSAmJiAoQTEgPT0gQTIpDQogICAyKVAxIDw9IFAyDQogICAzKVRoZSBwcmVm aXhlcyBhcmUgaW4gdGhlIHNhbWUgYWRkcmVzcyBmYW1pbHkuDQogICAyKUwxID09IEwyDQogICAz KShQMWUgPj0gUDIpICYmICgoUzEgKyAoUDIgLSBQMSkpICE9IFMyKQ0KDQpTbyBmb3IgKEZFQykg cHJlZml4IGNvbmZsaWN0IG15IGFsZ28gaXM6DQogICAxKShUMSA9PSBUMikgJiYgKEExID09IEEy KQ0KICAgMilQMSA9IFAyDQogICAzKVRoZSBwcmVmaXhlcyBhcmUgaW4gdGhlIHNhbWUgYWRkcmVz cyBmYW1pbHkuDQogICAyKUwxID09IEwyDQoNCihCVFcsIGluIHRoZSBkcmFmdCwgdGhlcmUgaXMg YSB0eXBvIGluIHRoZSBudW1iZXJpbmcpDQpJdCBsb29rcyBjbGVhciB0aGF0IEZFQyBjb21wYXJp c29uIGlzIGVhc2llciB0aGFuIHByZWZpeCByYW5nZSBpbnRlcnNlY3Rpb24uDQoNCjIpIEdvaW5n IGRlZXBlciwgYXQgdGhlIGFsZ28gY29tcGxleGl0eQ0KDQpUaGUgRkVDIGFsZ28gbmVlZHM6IGdl dF9TSURzKFByZWZpeCksIGFuZCBhbGwgdGhlIHdvcmsgaXMgZG9uZS4gU28gYWxsIHRoZSBhbGdv IGNvbXBsZXhpdHkgaXMgY29taW5nIGZyb20gdGhlIGRhdGFzdHJ1Y3R1cmUuIEl0IHNlZW1zIHBy ZXR0eSByZWFzb25hYmxlIHRvIGZpbmQgYSBkYXRhc3RydWN0dXJlIDw8IG8obikgKGUuZy4gYSB0 cmVlLCBidXQgeW91IHdpbGwgYmUgbXVjaCBiZXR0ZXIgdGhhbiBtZSBpbiBmaW5kaW5nIG9uZSkN CkZvciB0aGUgcmFuZ2UgYWxnbywgaXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGEgZGF0YSBz dHJ1Y3R1cmUgY2FuIGJlIGZvdW5kIHRvIGF1dG9tYXRpY2FsbHkgZmluZCB0aGUgcmVzdWx0LiBJ ZiBub3QsIHRoZSBhbGdvIHNlZW1zIHRvIGNvbXBhcmUgYWxsIGVudHJpZXMgdHdvIGJ5IHR3bywg d2hpY2ggd291bGQgZ2V0IG8obioobi0xKeKApigyKSkgaS5lLiBvKG4hKQ0KDQoNCg0KDQpDb25z aWRlciB3aGF0IG5lZWRzIHRvIGJlIGRvbmUgdG8gaW1wbGVtZW50DQoNCiAgIOKAnEZpbmQgYWxs IFNJRGkgYWR2ZXJ0aXNlZCBmb3IgdGhlIHByZWZpeCBQMeKAnQ0KDQpJbiBpdHMgc2ltcGxlc3Qg Zm9ybSwgd2UgaGF2ZSBhIGxpc3Qgb2YgYWxsIFNJRCBhZHZlcnRpc2VtZW50cyAoUEZYIGFuZCBT Uk1TKSB0aGF0IHdlIGhhdmUgcmVjZWl2ZWQuIE9uZSBjb3VsZCBpbWFnaW5lIHdhbGtpbmcgYWxs IHRoZSBlbnRyaWVzLCBsb29raW5nIHRvIHNlZSBpZiB0aGUgcHJlZml4IG9mIGludGVyZXN0IGlz IHByZXNlbnQgd2l0aGluIHRoZSBhZHZlcnRpc2VkIHJhbmdlLiBCdXQsIG9mIGNvdXJzZSwgYXQg bGFyZ2Ugc2NhbGUgc3VjaCBhbiBhcHByb2FjaCBpcyBleHRyZW1lbHkgaW5lZmZpY2llbnQg4oCT IHNvIHdlIGltbWVkaWF0ZWx5IHN0YXJ0IGNvbnNpZGVyaW5nIHdheXMgdG8gaW1wcm92ZSBwZXJm b3JtYW5jZS4gSW5zZXJ0aW5nIHJlY2VpdmVkIGVudHJpZXMgaW50byBhbiBvcmRlcmVkIHRyZWUg b2Ygc29tZSBraW5kIGlzIGFuIG9idmlvdXMgd2F5IHRvIGltcHJvdmUgcGVyZm9ybWFuY2UuIFdo ZW4gb25lIGZ1cnRoZXIgY29uc2lkZXJzIHRoYXQgY2FsY3VsYXRpbmcgY29uZmxpY3QgcmVzb2x1 dGlvbiBvbmx5IG5lZWRzIHRvIGJlIGRvbmUgd2hlbiBhIGNoYW5nZSB0byB0aGUgcmVjZWl2ZWQg ZGF0YWJhc2Ugb2NjdXJzICh3aGljaCBwb3N0IHN0YXJ0dXAgaXMgaW5mcmVxdWVudCkgaXQgYmVj b21lcyB2ZXJ5IGF0dHJhY3RpdmUgdG8gY2FjaGUgdGhlIOKAnHdpbm5pbmcgZW50cmllc+KAnSBz byB0aGF0IGlmIG9uZSB3YW50cyB0byByZXRyaWV2ZSB0aGUgU0lEIGZvciBhIGdpdmVuIHByZWZp eCB3ZSBvbmx5IGhhdmUgdG8gZXhhbWluZSBhIHN1YnNldCBvZiB0aGUgdG90YWwgZGF0YWJhc2Ug 4oCTIGlnbm9yaW5nIHRoZSBsb3NlcnMuDQpbQnJ1bm9dIEkgYWdyZWUgdGhhdCB0aGUgcGVyIHJh bmdlIGFsZ28gKGlnbm9yZSBvdmVybGFwIG9ubHkpIHdpbGwgYmUgYWJsZSB0byBpZ25vcmUgdGhl IGxvc2VycyBidXQgYXQgdGhlIGNvc3Qgb2YgYSBtb3JlIGNvbXBsZXggYWxnbyBhbmQgYXQgdGhl IGNvc3Qgb2YgY3JlYXRpbmcgbmV3IGRlcml2ZWQgZW50cmllcy4gSXTigJlzIG5vdCBjbGVhciB0 byBtZSBpZiB0aGUgbmV0IHJlc3VsdCBpcyBwb3NpdGl2ZS4gUGx1cyBJIHdvdWxkIGV4cGVjdCB0 aGF0IHRoZSBudW1iZXIgb2YgY29uZmxpdCBpcyBzbWFsbCBjb21wYXJlZCB0byB0aGUgbnVtYmVy IG9mIHByZWZpeCAvU0lEIHNvIHRoaXMgbG9va3MgbGlrZSBhIHNlY29uZCBvcmRlciBvcHRpbWl6 YXRpb24uDQoNCkluIHRoaXMgY29udGV4dCwgd2UgY2FuIGFwcHJlY2lhdGUgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGUgdGhyZWUgcHJvcG9zZWQgYWxnb3JpdGhtcy4gSW4gcGFydGljdWxhciBj b21wYXJpbmcg4oCcUXVhcmFudGluZeKAnSB3aXRoIOKAnGlnbm9yZSBvdmVybGFwIG9ubHnigJ0s IGEga2V5IGRpZmZlcmVuY2UgaXMgdGhhdCDigJxRdWFyYW50aW5l4oCdIG9ubHkgbmVlZHMgdG8g ZGV0ZXJtaW5lIHdoZXRoZXIgYSByZWNlaXZlZCBlbnRyeSBpcyBhIHdpbm5pbmcgZW50cnkgb3Ig YSBsb3NpbmcgZW50cnkuIOKAnElnbm9yZSBvdmVybGFwIG9ubHnigJ0gaGFzIHRvIGJlIGNhcGFi bGUgb2YgYnJlYWtpbmcgcmVjZWl2ZWQgZW50cmllcyB3aXRoIHJhbmdlcyA+IDEgaW50byBtdWx0 aXBsZSDigJxkZXJpdmVk4oCdIGVudHJpZXMgKHNvbWUgd2lubmluZywgc29tZSBsb3NpbmcpLCB3 aGljaCBtZWFucyB3ZSBub3cgbmVlZCB0byB0cmFjayB0aGUg4oCcZGVyaXZlZCBlbnRyaWVz4oCd IGFnYWluc3QgdGhlIG9yaWdpbmFsIHJlY2VpdmVkIGVudHJ5IHNvIHRoYXQgaWYgdGhlIHJlY2Vp dmVkIGVudHJ5IGlzIHVwZGF0ZWQvZGVsZXRlZCB3ZSBjYW4gZmluZCBhbGwgdGhlIGRlcml2ZWQg ZW50cmllcyBhbmQgZGVsZXRlL3JlZ2VuZXJhdGUgdGhlIGRlcml2ZWQgZW50cmllcyBhcyBuZWVk ZWQuIFRoaXMgaXMgd2hhdCBhZGRzIGNvbXBsZXhpdHkuDQpbQnJ1bm9dIGFuZCB0aGF0IGl0IHdo eSB0aGUgcGVyIEZFQyBhbGdvIHNlZW1zIGVhc2llci4NClNvIGl0IHdvdWxkIHNlZW0gdXNlZnVs IHRvIGFkZCBpdCBpbiB0aGUgZHJhZnQgc28gdGhhdCB3ZSBjYW4gYWxsIGRpc2N1c3MgaXQuDQoN CltMZXM6XSBJZ25vcmUgb3ZlcmxhcCBvbmx5IGlzIHRoZSBzYW1lIGFzIHBlciBGRUMuIFdlIG1h eSB1c2UgZGlmZmVyZW50IHdvcmRzIHRvIGRlc2NyaWJlIGl0LCBidXQgdGhlIGVuZCBiZWhhdmlv ciBpcyB0aGUgc2FtZS4NCltCcnVub10gZ29vZCBpZiB0aGlzIGdldCB0aGUgc2FtZSByZXN1bHQu IFlldCB0aGUgYWxnbyBpcyBkaWZmZXJlbnQuDQoNCi0tIEJydW5vDQoNCiAgIExlcw0KDQoNCkFs bCBwcm9wb3NlZCBhbGdvcml0aG1zIGNhbiBiZSBpbXBsZW1lbnRlZCwgYnV0IGl0IGRvZXMgc2Vl bSBwcnVkZW50IHRvIGNvbnNpZGVyIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgYXMgcGFydCBv ZiBvdXIgZGVjaXNpb24gcHJvY2VzcyDigJMgYW5kIHRoZSBkaXNjdXNzaW9uL2V4YW1wbGVzIGlu IFNlY3Rpb24gMyBhcmUgbWVhbnQgdG8gaGVscCBpbiBkb2luZyB0aGlzLg0KDQpJdCBpcyB3b3J0 aHdoaWxlIHJlc3RhdGluZyB0aGF0IHdoZW4gY29uZmxpY3RzIGFyZSBwcmVzZW50IHdlIGNhbm5v dCBndWFyYW50ZWUgdGhhdCBmb3J3YXJkaW5nIHdpbGwgd29yayBjb3JyZWN0bHkgbm8gbWF0dGVy IHdoYXQgYWxnb3JpdGhtIGlzIHVzZWQuDQpbQnJ1bm9dIEnigJltIG5vdCBzdXJlIHRvIHNlZSB3 aGF0IHlvdSBoYXZlIGluIG1pbmQgZXhhY3RseS4gQ2FuIHlvdSBlbGFib3JhdGU/IFRvIG1lIGNv bnNpc3RlbmN5IHNlZW0gZW5vdWdoLg0KIFRoZSBtb3JlIGNvbXBsZXggdGhlIGltcGxlbWVudGF0 aW9uIHRoZSBtb3JlIGxpa2VseSBpdCBpcyB0aGF0IGJ1Z3Mgd2lsbCBiZSBwcmVzZW50IGFuZCB0 aGUgbW9yZSBsaWtlbHkgaXQgaXMgdGhhdCBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyB3aWxsIGFy aXNlLiBXaGV0aGVyIHRoZXNlIGNvc3RzL3Jpc2tzIGFyZSB3b3J0aCB0aGUg4oCcdmFsdWUgYWRk 4oCdIHdoZW4gdGhlIG91dGNvbWUgY2Fubm90IGJlIGd1YXJhbnRlZWQgdG8gYmUgY29ycmVjdCDi gJMgb25seSBndWFyYW50ZWVkIHRvIGJlIGNvbnNpc3RlbnQg4oCTIGlzIGFuIGltcG9ydGFudCBj b25zaWRlcmF0aW9uLg0KDQpBbHNvIGltcG9ydGFudCB0byByZW1lbWJlciB0aGF0IGNvbmZsaWN0 cyBNVVNUIGJlIGVsaW1pbmF0ZWQgYnkgY29ycmVjdGluZyB0aGUgbWlzY29uZmlndXJhdGlvbnMg dGhhdCBjYXVzZWQgdGhlbSDigJMgc28gY29uZmxpY3QgcmVzb2x1dGlvbiBpcyByZWFsbHkgb25s eSBhbiBpbnRlcmltIG1lYXN1cmUgdW50aWwgdGhlIGNvcnJlY3Rpb25zIGNhbiBiZSBtYWRlLg0K W0JydW5vXSBCeSDigJxpbnRlcmlt4oCdIHdlIGFyZSBhdCBtaW5pbXVtIHRhbGtpbmcgYWJvdXQg MTBzIG9mIG1pbnV0ZXMsIGlmIG5vdCBtb3JlIHRoYW4gMSBob3VyIHNpbmNlIGlkZW50aWZ5aW5n IHRoZSByb290IGNhdXNlIG1heSBub3QgYmUgb2J2aW91cy4gVGhlIGltcGFjdCBpcyB2ZXJ5IHNp Z25pZmljYW50IG9uIHRoZSBuZXR3b3JrLg0KVGhlIOKAnFF1YXJhbnRpbmXigJ0gYWxnbyBoYXMg dGhlIHBvdGVudGlhbCB0byBraWxsIDEwMHMgUEUgYW5kIDEwMDBzIG9mIFZQTiBjdXN0b21lcnMs IHNvIGEgc2luZ2xlIGNvbmZpZ3VyYXRpb24gY2hhbmdlIG9uIGEgdW5yZWxhdGVkIHJvdXRlciB3 aGljaCBtYXkgbm90IGV2ZW4gYmUgaW4gcHJvZHVjdGlvbiAoaS5lLiB3aGVyZSBjb25maWd1cmF0 aW9uIGNoZWNrcyBhbmQgb3BlcmF0aW9ucyBob3VycyBtYXkgYmUgcmVsYXhlZCkNCg0KDQpObyBv bmUgc2hvdWxkIGJlIGx1bGxlZCBpbnRvIHRoaW5raW5nIHRoYXQgYmVjYXVzZSB3ZSBoYXZlIGNv bmZsaWN0IHJlc29sdXRpb24gZGVwbG95ZWQgdGhhdCBjb3JyZWN0aW5nIHRoZSBjb25maWd1cmF0 aW9uIHdoZW4gY29uZmxpY3RzIGFyZSBkZXRlY3RlZCBpcyBub3QgYSBwcmlvcml0eS4NCltCcnVu b10gSSBjb3VsZCBub3QgYWdyZWUgbW9yZSB0aGF0IGNvbmZsaWN0IG5lZWRzIHRvIGJlIGlkZW50 aWZpZWQgYW5kIGZpeGVkLiBOb3RlIHRoYXQgSeKAmW0gdGhlIG9uZSBoYXZpbmcgYXNrZWQgZm9y IGRlZmluaW5nIFlBTkcgbm90aWZpY2F0aW9ucyB0byByZXBvcnQgdGhpcy4NCllvdSBhcmUgd2Vs Y29tZWQgdG8gc3RhdGUgaW4gdGhlIGRyYWZ0IHRoYXQgY29uZmxpY3RzIG5lZWRzIHRvIGJlIHJl cG9ydGVkIHRvIHRoZSBuZXR3b3JrIG9wZXJhdG9yLCBpbiBwYXJ0aWN1bGFyIHRob3VnaCB5YW5n IG5vdGlmaWNhdGlvbiwgYW5kIG90aGVyIGV4aXN0aW5nIG1lYW5zLiBQbHVzIHRoYXQgbmV0d29y ayBvcGVyYXRvciBuZWVkcyB0byBmaXhlZCB0aGVtIEFTQVAgKGJ1dCBzdGlsbCBjYXJlZnVsbHkp DQoNClRoYW5rcw0KLS1CcnVubw0KDQogICBMZXMNCg0KDQpGcm9tOmJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+IFttYWlsdG86YnJ1bm8u ZGVjcmFlbmVAb3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDMwLCAyMDE2IDU6MTAg QU0NClRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZs aWN0LXJlc29sdXRpb24gLSBQb2xpY3kNCg0KTGVzLA0KDQpUaGFua3MgZm9yIHRoZSBkaXNjdXNz aW9uLiBQbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dDQoNCg0KRnJvbTogTGVzIEdpbnNiZXJnIChn aW5zYmVyZykgW21haWx0bzpnaW5zYmVyZ0BjaXNjby5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1 bmUgMjksIDIwMTYgNjowMCBQTQ0KVG86IERFQ1JBRU5FIEJydW5vIElNVC9PTE4NCkNjOiBzcHJp bmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBkcmFmdC1p ZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5DQoNCkJydW5vIOKAkw0KDQpB cyB0aGUgdGhyZWFkIGJlbG93IGRvY3VtZW50cywgSSBzdGF0ZWQgdGhhdCBJIGRpZCBub3QgdW5k ZXJzdGFuZCB5b3VyIHJlcHJlc2VudGF0aW9uIGFuZCBhc2tlZCBmb3IgY2xhcmlmaWNhdGlvbiDi gJMgc3VnZ2VzdGluZyB0aGF0IHlvdSB1c2UgdGhlIGZvcm1hdCBkZWZpbmVkIGluIHRoZSBkcmFm dC4NCllvdSBzdGF0ZWQgdGhhdCB5b3UgY291bGQgbm90IGRvIHRoYXQgYW5kIHdlIHdlcmUgYXQg YSBwb2ludCB3aGVyZSBubyBwcm9ncmVzcyBjb3VsZCBiZSBtYWRlLg0KW0JydW5vXSBJIGNvdWxk IF9ub3RfIHVzZSB5b3VyIGZvcm1hdCBzaW5jZSB5b3VyIGZvcm1hdCBkaWQgbm90IGluY2x1ZGUg dGhlIGluZm9ybWF0aW9uIG5lZWQuIFRoaXMgaXMgbm90IGEgd2hpbSBidXQgYSB0ZWNobmljYWwg aXNzdWUuIFNvIEkgYXNrZWQgeW91IHRvIHN0aWxsIGNvbnNpZGVyIHRoZSBtZXNzYWdlLiBSYXRo ZXIgdGhhbiB3YWl0aW5nIGZvciBhIHRpbWUtb3V0LCB0aGVyZSB3YXMgYSB3YXkgdG8gbWFrZSBw cm9ncmVzcyBieSBhc2tpbmcgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbnMgb24gdGhlIHBvaW50cyB3 aGljaCB3ZXJlIG5vdCBjbGVhciwgb3IgYXQgbGVhc3QgZXhwbGljaXRseSByZWZ1c2luZyB0byBj b25zaWRlciB0aGUgZW1haWwuDQoNCkkgYWxzbyBub3RlIHRoYXQgd2hhdCBib3RoZXJlZCB5b3Ug aW4gbXkgcmVwcmVzZW50YXRpb24gd2FzIG15IGFkZGl0aW9uIG9mIHRoZSB0eXBlIG9mIGFkdmVy dGlzZW1lbnQgKHByZWZpeCBvciBNUykuIEJ1dCB5b3UgZmluYWxseSBoYXZlIGp1c3QgYWRkZWQg aW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCDigJxTcmMtIFBGWCBvciBTUk1T4oCd IC4gU28gdGhlcmUgd2FzIHByb2JhYmx5IGEgd2F5IHRvIGNvbW11bmljYXRlLg0KDQoNCkJlc2lk ZXMgdGhlIGFsZ28gZGlkIG5vdCB1c2UgYW55IHNwZWNpZmljYXRpb24gcmVwcmVzZW50YXRpb24s IGp1c3QgbmFtZXMuIFNvIEnigJlsbCBjb3B5L3Bhc3RlIGl0IGJlbG93LCBwbGVhc2UgYXNrIGNs YXJpZmljYXRpb24gcXVlc3Rpb25zIGZvciB0aGUgcGFydHMgd2hpY2ggYXJlIG5vdCBjbGVhciBl bm91Z2guDQoNClRoZSBwcm9ibGVtIHRoYXQgd2UgbmVlZCB0byBzb2x2ZSwgaXMgdG8gZmluZCB0 aGUgU0lEIGZvciBhIHByZWZpeCAoUDEpLg0KVGhlIGFsZ28gY291bGQgYmU6DQotIEZpbmQgYWxs IFNJRGkgYWR2ZXJ0aXNlZCBmb3IgdGhlIHByZWZpeCBQMSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gaWRlbnRpZmljYXRpb24gb2Yg UHJlZml4IGNvbmZsaWN0cw0KICAgICAgICAgICAgICAgIC0gRm9yIGVhY2ggU0lEaSBmaW5kIGFs bCB0aGUgcHJlZml4IFBpaiBhc3NvY2lhdGVkIHdpdGggU0lEaSAgICAgICAgICAgICAgLy8gaWRl bnRpZmljYXRpb24gb2YgU0lEIGNvbmZsaWN0cw0KDQovLyBhcyBhIHJlc3VsdCwgZm9yIFAxLCB3 ZSBnZXQgYSBsaXN0IG9mIChTSURpLCBQaWopDQoNCkdldCB0aGUgYmVzdCAoU0lEaSwgUGlqKSBh cyBwZXIgdGhlIHByZWZlcmVuY2UgYWxnb3JpdGhtLg0KSWYgYmVzdCBQaWogPT0gUDENCiAgICAg ICAgICAgICAgICB0aGVuIHVzZSBTSURpaiBmb3IgUDENCiAgICAgICAgICAgICAgICBlbHNlIHJl dHVybiBubyBTSUQgICAgICAgICAgICAgICAgICAgICAgICAgIC8gbm8gU0lEIGF2YWlsYWJsZSBm b3IgdGhpcyBwcmVmaXggUDENCg0KDQoNClRvIGlsbHVzdHJhdGUgbXkgY29uZnVzaW9uLCBvbmUg b2YgeW91ciBleGFtcGxlcyBpczoNCg0KRm9yIFIyLCB0aGUgYWxnbyBldmFsdWF0ZXMgYSBjb25m bGljdCBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgYWR2ZXJ0aXNtZW50czoNCiAgIFIyIC0gU0lEMiAt IFIyIChNUywgTVMpDQogICBSMiAtIFNJRDEyIC0gUjEyIChwcmVmaXggU0lELCBNUykNCiAgIFIy IC0gU0lEMTIgLSBSMiAgKHByZWZpeCBTSUQsIHByZWZpeCBTSUQpDQoNCg0KTm93LCB3aGF0IGRv ZXMg4oCcUjIgLSBTSUQyIC0gUjIgKE1TLCBNUynigJ0gbWVhbj8NCltCcnVub10NCi0gTVMvcHJl Zml4IFNJRCBpcyB0aGUgdHlwZSBvZiBhZHZlcnRpc2VtZW50LiBJbiB5b3VyIG5ldyB2ZXJzaW9u LCB5b3UgY2FsbCBpdCBTUk1TL1BGWC4NCi0gU0lEIGlzIHRoZSBTSUQgZm91bmQgaW4gdGhlIE1h cHBpbmcgRW50cmllDQotIFJ4IGlzIHRoZSBsb29wYmFjayAocHJlZml4KSBvciByb3V0ZXIgUngN Cg0KU28g4oCcUjIgLSBTSUQyIC0gUjIgKE1TLCBNUynigJ0gaXMgdGhlIG91dHBvdXQgb2YgdGhl IGFsZ28gZGVzY3JpYmVkIGFib3ZlIGFuZCBtZWFuczogRm9yIHByZWZpeCBSMiwgd2UgZm91bmQg YSBNUyBtYXBwaW5nIGVudHJpZXMgYWR2ZXJ0aXNpbmcgU0lEMiBmb3IgdGhpcyBwcmVmaXgsIGFu ZCB0aGVuIEkgZm91bmQgYSBNUyBtYXBwaW5nIGVudHJpZXMgYWR2ZXJ0aXNpbmcgcHJlZml4IFIy IGZvciBTSUQyLg0KDQpEb2VzIGl0IG1lYW4gIOKAnE9uIFIyLCBTSUQyIGlzIGFzc2lnbmVkIHRv IHByZWZpeCBSMiBmcm9tIHR3byBkaWZmZXJlbnQgbWFwcGluZyBzZXJ2ZXIgZW50cmllcz/igJ0g SSByZWFsbHkgaGF2ZSBubyBpZGVhLg0KDQpBbmQgeW91IGNvbmNsdWRlIHRoZSBleGFtcGxlIGJ5 IHNheWluZw0KDQpCZXN0IG9uZSBpcyBSMiAtIFNJRDEyIC0gUjIgKHNtYWxsZXIgcmFuZ2UgKHBy ZWZpeCBTSUQpLHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpKQ0KICAgPT0+IFNJRDEyIGlzIHNl bGVjdGVkIGZvciBSMi4NCg0KQnV0IHNpbmNlIHRoZXJlIGlzIG5vIHJlcHJlc2VudGF0aW9uIG9m IOKAnHJhbmdl4oCdIGluIHlvdXIgZXhhbXBsZXMgSSByZWFsbHkgaGF2ZSBubyBpZGVhIGhvdyB5 b3UgY2FtZSB0byB0aGlzIGNvbmNsdXNpb24gLg0KW0JydW5vXSBJIGFncmVlIHRoYXQgc2luY2Ug dGhlIGFib3ZlIGFsZ28gdXNlZCAyIG1hcHBpbmcgZW50cmllcyB0byBwcm92aWRlcyB0aGUgKFNJ RGksIFBpaiksIHRoZSBwcmVmZXJlbmNlIGFsZ28gKMKnMy4yLjQpIHdvdWxkIG5lZWQgdG8gYmUg YWRhcHRlZC4gVGhhdCBiZWluZyBzYWlkLCB0aGlzIGlzIG5vdCBpbXBvcnRhbnQgZm9yIHRoaXMg ZGlzY3Vzc2lvbi4gTGV04oCZcyBqdXN0IGNvbnNpZGVyZWQgdGhhdCB0aGVpciBleGlzdCBhIHBy ZWZlcmVuY2UgYWxnb3JpdGhtLCB3aGljaCB0YWtlcyBhcyBpbnB1dCBhIGxpc3Qgb2YgKFNJRGks IFBpaWopIGZvciBQMSwgYW5kIGdpdmVzIGFzIG91dHBvdXQgdGhlIOKAnGJlc3TigJ0gb25lLiAo ZGVmaW5pdGlvbiBvZiDigJxiZXN04oCdIGlzIG5vdCBwZXJ0aW5lbnQpDQoNCg0KPz8NCg0KQXMg cmVnYXJkcyDigJxwZXIgRkVDL1ByZWZpeOKAnSwgSSBiZWxpZXZlIHRoaXMgaXMgd2hhdCDigJxp Z25vcmUgb3ZlcmxhcCBvbmx54oCdIGRvZXMuDQpbQnJ1bm9dIEluZGVlZCwgdGhpcyBpcyBteSBl eHBlY3RhdGlvbi4gQnV0IEkgd291bGQgbmVlZCBzb21lb25l4oCZcyByZXZpZXcgdG8gY29uZmly bSB0aGlzLg0KQnV0IHRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIHByb3Bvc2VkIGFsZ28gaXMg c2ltcGxlICgyIGxpbmVzIG9mIHBzZXVkbyBjb2RlKSwgd2l0aCB2ZXJ5IG1vZGVzdCByZXNxdWly ZW1lbnQgZGF0YSBzdHJ1Y3R1cmUgdXNlIHRvIHN0b3JlIHRoZSBtYXBwaW5nIGVudHJpZXMuIElu ZGVlZCwgYWxsIGl0IG5lZWRzIGlzIGEgZnVuY3Rpb24gcmV0dXJuaW5nIHRoZSBsaXN0IG9mIG1h cHBpbmcgZW50cmllcyBhc3NvY2lhdGVkL21hdGNoaW5nIGEgZ2l2ZW4gcHJlZml4LiBBbmQgZnVu Y3Rpb24gcmV0dXJuaW5nIHRoZSBsaXN0IG9mIG1hcHBpbmcgZW50cmllcyBhc3NvY2lhdGVkL21h dGNoaW5nIGEgZ2l2ZW4gU0lELg0KSW4gcGFydGljdWxhciwgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig c3BsaXR0aW5nIG1hcHBpbmcgZW50cmllcyB3aGljaCBpcyB0aGUgbWFpbiBjb21wbGV4aXR5IG9m IHlvdXIgcHJvcG9zZWQg4oCcUHJlZmVyZW5jZSBhbGdvcml0aG0vaWdub3JlIG92ZXJsYXAgb25s eeKAnS4gKGFjY29yZGluZyB0byB5b3VyIG93biB0ZXh0KS4NCg0KLS0gQnJ1bm8NCg0KDQogICAg TGVzDQoNCg0KRnJvbTpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPiBbbWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dDQpTZW50 OiBXZWRuZXNkYXksIEp1bmUgMjksIDIwMTYgNzoyMiBBTQ0KVG86IExlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpDQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGljeQ0K DQpMZXMsDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZWQgZHJhZnQuDQoNCklJTk0sIHlvdSBoYXZl IG5vdCBhbnN3ZXJlZCBteSBiZWxvdyBlbWFpbC9wcm9wb3NhbC4gSSBoYWQgd2FpdGVkIGZvciB0 aGUgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGJ1dCBpdCBhbHNvIGRvZXMgbm90IHRvdWNoIHRo aXMgc3ViamVjdC4NCg0KU28sIGNvdWxkIHlvdSBwbGVhc2UgY29uc2lkZXIgYW5kIGFuc3dlciBt eSBjb21tZW50Pw0KDQpJbiBzaG9ydCwgaW4gYW4gaW1wbGVtZW50YXRpb24taW5kZXBlbmRlbnQg c2VudGVuY2U6DQoNCj4gSSdtIHdvbmRlcmluZyBpZiB3ZSBjb3VsZCBhZGRyZXNzIHRoZSBjb25m bGljdCBvbiBhIHBlciBGRUMvUHJlZml4IGJhc2lzIHJhdGhlciB0aGFuIG9uIGEgcGVyIElHUCBh ZHZlcnRpc2VtZW50IChyYW5nZSkgYmFzaXMuDQo+IElmIHNvLCB0aGlzIG1heSBhdm9pZCB0aGUg ZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBRdWFyYW50aW5lIHZzIGlnbm9yZSBwb2xpY3kuDQoNCg0K VGhhbmtzDQpCcnVubw0KDQoNCkZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE4LCAyMDE2IDE6 NTcgUE0NClRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgc3ByaW5nQGlldGYub3JnPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGljeQ0KDQpMZXMsDQoNClBsZWFzZSBzZWUgaW5s aW5lIFtCcnVub10NCg0KRnJvbTogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgW21haWx0bzpnaW5z YmVyZ0BjaXNjby5jb21dDQpTZW50OiBTdW5kYXksIE1heSAxNSwgMjAxNiAxMjo0MSBBTQ0KVG86 IERFQ1JBRU5FIEJydW5vIElNVC9PTE47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPg0KU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b24gLSBQb2xpY3kNCg0KQnJ1bm8g4oCTDQoNCkkgYW0gaGF2aW5nIGRpZmZpY3VsdHkgcGFyc2lu ZyB0aGUgZXhhbXBsZXMgeW91IHByb3ZpZGUgYmVsb3cgYXMgdGhleSBzZWVtIHRvIGluY29ycG9y YXRlIGFkdmVydGlzZW1lbnQgc291cmNlIGludG8gdGhlIGRlc2NyaXB0aW9uIHdoZXJlYXMgdGhl IGRyYWZ0IGRlbGliZXJhdGVseSBvbWl0cyBzb3VyY2UuDQpbQnJ1bm9dIE15IHRleHQgZG9lcyBu b3QgaW5jb3Jwb3JhdGUgdGhlIHNvdXJjZSwgYnV0IHRoZSB0eXBlIG9mIHNvdXJjZSBJT1cgdGhl IHR5cGUgb2Ygc3ViLVRMVi4NCg0KU28gaXQgZG9lcyBub3QgbWF0dGVyIGlmIFIyIHNlbmRzIGFu IGFkdmVydGlzZW1lbnQgb3IgUjEyIHNlbmRzIGFkdmVydGlzZW1lbnQgb3IgYm90aCBvZiB0aGVt IGRvICh3aGljaCBjb3VsZCBoYXBwZW4gd2hlbiBhbiBhZHZlcnRpc2VtZW50IGlzIGxlYWtlZCkg 4oCTIHdoYXQgbWF0dGVycyBpcyB3aGF0IHVuaXF1ZSBlbnRyaWVzIGFyZSBpbiB0aGUgZGF0YWJh c2UgaW5kZXBlbmRlbnQgb2Ygc291cmNlLg0KW0JydW5vXSBJdCBtYXkgbm90IG1hdHRlciBmb3Ig eW91ciBhbGdvcml0aG0gKHBlbmRpbmcgYW5vdGhlciB0aHJlYWQpLCBidXQgaXQgZG9lcyBmb3Ig dGhlIG9uZSBJIHByb3Bvc2VkLg0KDQpJdCB3b3VsZCBiZSBnb29kIGlmIHlvdSBjb3VsZCBwcmVz ZW50IHlvdXIgZXhhbXBsZXMgdXNpbmcgdGhlIGZvcm1hdCBkZWZpbmVkIGluIHRoZSBkcmFmdCBp LmUuOg0KW0JydW5vXSBNeSBleGFtcGxlcyBhcmUgZGVzY3JpYmVkIGluIHBsYWluIHRleHQuIFRo ZW4gdGhlIGV4YW1wbGVzIGdpdmluZyBpbnRlcm1lZGlhdGUgc3RlcHMgb2YgbXkgYWxnbyB1c2Vz IHRoZSBkYXRhIHRoYXQgYXJlIG5lZWRlZCBpLmUuIHRoZSB0eXBlIG9mIGFkdmVydGlzZW1lbnQg KFByZWZpeC1TSUQgdnMgTVMpLg0KVGhlbiBmaW5hbGx5LCBteSBhbGdvIHJ1bnMgb24gYSBwZXIg RkVDL0lQIFByZWZpeCBiYXNpcywgYW5kIG5vdCBvbiBhIHBlciBJR1AgYWR2ZXJ0aXNlbWVudCBi YXNpcyB3aGljaCB5b3VyIGZvcm1hdCBkZXNjcmliZS4NClNvIEnigJltIHNvcnJ5IGJ1dCBJIGRv buKAmXQgc2VlIGhvdyB0byBpbmR1bGdlIHlvdXIgcmVxdWVzdC4NCg0KICAgIFBpIC0gSW5pdGlh bCBwcmVmaXgNCiAgICAgUGUgLSBFbmQgcHJlZml4DQogICAgIEwgLSAgUHJlZml4IGxlbmd0aA0K ICAgICBMeCAtIE1heGltdW0gcHJlZml4IGxlbmd0aCAoMzIgZm9yIElQdjQsIDEyOCBmb3IgSVB2 NikNCiAgICAgU2kgLSBJbml0aWFsIFNJRCB2YWx1ZQ0KICAgICBTZSAtIEVuZCBTSUQgdmFsdWUN CiAgICAgUiAtICBSYW5nZSB2YWx1ZQ0KICAgICBUIC0gVG9wb2xvZ3kNCiAgICAgQSAtIEFsZ29y aXRobQ0KDQogICAgIEEgTWFwcGluZyBFbnRyeSBpcyB0aGVuIHRoZSB0dXBsZTogKFBpL0wsIFNp LCBSLCBULCBBKQ0KICAgICBQZSA9IChQaSArICgoUi0xKSA8PCAoTHgtTCkpDQogICAgIFNlID0g U2kgKyAoUi0xKQ0KDQpFeGFtcGxlOiAgICAgKDE5Mi4wLjIuMTIwLzMyLCAyMDAsIDEsIDAsIDAp DQoNCkFzIHJlZ2FyZHMgeW91ciBwcm9wb3NhbA0KDQotIEZpbmQgYWxsIFNJRGkgYWR2ZXJ0aXNl ZCBmb3IgdGhlIHByZWZpeCBQMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLy8gaWRlbnRpZmljYXRpb24gb2YgUHJlZml4IGNvbmZsaWN0 cw0KICAgICAgICAgICAgICAgIC0gRm9yIGVhY2ggU0lEaSBmaW5kIGFsbCB0aGUgcHJlZml4IFBp aiBhc3NvY2lhdGVkIHdpdGggU0lEaSAgICAgICAgICAgICAgLy8gaWRlbnRpZmljYXRpb24gb2Yg U0lEIGNvbmZsaWN0cw0KDQpHZXQgdGhlIGJlc3QgYXMgcGVyIHRoZSBwcmVmZXJlbmNlIGFsZ29y aXRobS4NCklmIGJlc3QgUGlqID09IFAxDQogICAgICAgICAgICAgICAgdGhlbiB1c2UgU0lEaWog Zm9yIFAxDQogICAgICAgICAgICAgICAgZWxzZSByZXR1cm4gbm8gU0lEDQoNCnRoaXMgdG8gbWUg c3BlY2lmaWVzIGFuIGltcGxlbWVudGF0aW9uIOKAkyB3aGljaCBpc27igJl0IG5lY2Vzc2FyeS4N CltCcnVub10gV2VsbCwgX3lvdV8gYXJlIHRoZSBvbmUgdGFsa2luZyBhYm91dCBpbXBsZW1lbnRh dGlvbiwgYW5kIG1vcmUgc3BlY2lmaWNhbGx5IGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuDQpB c3N1bWluZyB0aGUgYWJvdmUgYWxnbyB3b3JrcywgaXQgbG9va3MgcmVsYXRpdmVseSBzaW1wbGUg dG8gaW1wbGVtZW50LCBpbiB3aGljaCBjYXNlLCBJIHdvdWxkIG5vdCBidXkgdGhlIGFyZ3VtZW50 IGFib3V0IGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgd2hpY2ggaXMgdGhlIG9ubHkgYXJndW1l bnQgaW4gZmF2b3Igb3IgdGhlIOKAnGlnbm9yZeKAnSBvciDigJxxdWFyYW50aW5l4oCdIHBvbGlj eS4NCkJvdHRvbSBsaW5lLCBJIHdvdWxkIHdlbGNvbWUgeW91ciBmZWVkYmFjayBhbmQgY29tbWVu dHMgb24gdGhpcyBwcm9wb3NlZCBhbGdvL3BvbGljeS4NCg0KVGhhbmtzLA0KUmVnYXJkcywNCi0t IEJydW5vDQoNCg0KSG93ZXZlciwgdGhlcmUgaXMgb25lIGltcG9ydGFudCBwb2ludCB3aGljaCBo YXMgbm90IGJlZW4gc3BlY2lmaWVkIGluIHRoZSBkcmFmdCB3aGljaCByZWFkaW5nIHlvdXIgcG9z dCBoYXMgYnJvdWdodCB0byBteSBhdHRlbnRpb24g4oCTIHRoYXQgaXMgdGhlIG9yZGVyIGluIHdo aWNoIGNoZWNrcyBhcmUgbWFkZS4NClRoZSBkcmFmdCBzdGF0ZXM6DQoNCuKAnFByZWZpeCBjb25m bGljdHMgYXJlIHNwZWNpZmljIHRvIG1hcHBpbmcgZW50cmllcyBzaGFyaW5nICB0aGUgc2FtZSB0 b3BvbG9neSBhbmQgYWxnb3JpdGhtLuKAnQ0K4oCcU0lEIGNvbmZsaWN0cyBhcmUgaW5kZXBlbmRl bnQgb2YgYWRkcmVzcy1mYW1pbHksICBpbmRlcGVuZGVudCBvZiBwcmVmaXggbGVuLCBpbmRlcGVu ZGVudCBvZiB0b3BvbG9neSwgYW5kIGluZGVwZW5kZW50ICBvZiBhbGdvcml0aG0u4oCdDQoNCklm IHdlIGNvbnNpZGVyIGFuIGV4YW1wbGUgd2hlcmUgYSBuZXR3b3JrIHN1cHBvcnRzIHR3byBWUE5z LCB0aGUgc2lnbmlmaWNhbmNlIG9mIG9yZGVyaW5nIGluIHRoZSBldmFsdWF0aW9uIG9mIGNvbmZs aWN0cyB3aWxsIGJlIGhpZ2hsaWdodGVkOg0KDQpWUE4xOg0KKDE5Mi4wLjIuMS8zMiwgMTAwLCAx LCAxLCAwKQ0KKDE5Mi4wLjIuMS8zMiwgMjAwLCAxLCAxLCAwKQ0KDQoNClZQTjI6DQoNCigxOTIu MC4yLjEwMC8zMiwgMjAwLCAxLCAyLCAwKQ0KDQpJZiB3ZSBldmFsdWF0ZSBwcmVmaXggY29uZmxp Y3RzIGZpcnN0LCB0aGVuIHRoZSBmb2xsb3dpbmcgZW50cmllcyBhcmUg4oCcYWN0aXZl4oCdOg0K KDE5Mi4wLjIuMS8zMiwgMTAwLCAxLCAxLCAwKSAhVlBOMQ0KKDE5Mi4wLjIuMTAwLzMyLCAyMDAs IDEsIDIsIDApICFWUE4yDQoNCklmIHdlIGV2YWx1YXRlIFNJRCBjb25mbGljdHMgZmlyc3QsIHRo ZW4gdGhlIGZvbGxvd2luZyBlbnRyaWVzIGFyZSDigJxhY3RpdmXigJ06DQooMTkyLjAuMi4xLzMy LCAxMDAsIDEsIDEsIDApICFWUE4xDQoNClRoZSBsYXR0ZXIgY2hvaWNlIGlzIHN1Ym9wdGltYWwg YmVjYXVzZSBpdCBwcmV2ZW50cyB1c2Ugb2YgdGhlIFZQTjIgZW50cnkgdW5uZWNlc3NhcmlseS4N Cg0KVGhpcyBwb2ludCBuZWVkcyB0byBiZSBtYWRlIGV4cGxpY2l0IGluIHRoZSBkcmFmdC4NCg0K ICAgIExlcw0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20+DQpTZW50OiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IDg6MjMgQU0NClRv OiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJp bmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBQb2xpY3kNCg0KSGkg YXV0aG9ycywgYWxsDQoNCkFzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3IsIHBsZWFzZSBmaW5k IGJlbG93IHNvbWUgZmVlZGJhY2sgb24gdGhlIHBvbGljeS4NCg0KSSdtIHdvbmRlcmluZyBpZiB3 ZSBjb3VsZCBhZGRyZXNzIHRoZSBjb25mbGljdCBvbiBhIHBlciBGRUMvUHJlZml4IGJhc2lzIHJh dGhlciB0aGFuIG9uIGEgcGVyIElHUCBhZHZlcnRpc2VtZW50IGJhc2lzLg0KSWYgc28sIHRoaXMg bWF5IGF2b2lkIHRoZSBkaXNjdXNzaW9uIGJldHdlZW4gdGhlIFF1YXJhbnRpbmUgdnMgaWdub3Jl IHBvbGljeS4NCg0KVGhlIHByb2JsZW0gdGhhdCB3ZSBuZWVkIHRvIHNvbHZlLCBpcyB0byBmaW5k IHRoZSBTSUQgZm9yIGEgcHJlZml4IChQMSkuDQpUaGUgYWxnbyBjb3VsZCBiZToNCi0gRmluZCBh bGwgU0lEaSBhZHZlcnRpc2VkIGZvciB0aGUgcHJlZml4IFAxICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvLyBpZGVudGlmaWNhdGlvbiBv ZiBQcmVmaXggY29uZmxpY3RzDQogICAgICAgICAgICAgICAgLSBGb3IgZWFjaCBTSURpIGZpbmQg YWxsIHRoZSBwcmVmaXggUGlqIGFzc29jaWF0ZWQgd2l0aCBTSURpICAgICAgICAgICAgICAvLyBp ZGVudGlmaWNhdGlvbiBvZiBTSUQgY29uZmxpY3RzDQoNCi8vIGFzIGEgcmVzdWx0LCB3ZSBnZXQg YSBsaXN0IG9mIFNJRGkg4oCTIFBpaiBmb3IgUDENCg0KR2V0IHRoZSBiZXN0IGFzIHBlciB0aGUg cHJlZmVyZW5jZSBhbGdvcml0aG0uDQpJZiBiZXN0IFBpaiA9PSBQMQ0KICAgICAgICAgICAgICAg IHRoZW4gdXNlIFNJRGlqIGZvciBQMQ0KICAgICAgICAgICAgICAgIGVsc2UgcmV0dXJuIG5vIFNJ RCAgICAgICAgICAgICAgICAgICAgICAgICAgLyBubyBTSUQgYXZhaWxhYmxlIGZvciB0aGlzIHBy ZWZpeCBQMQ0KDQoNCiAgIE5vdGUgdGhhdCBpdCB3b3VsZCBwcm9iYWJseSBiZSBiZXR0ZXIgZm9y IHRoZSBwcmVmZXJlbmNlIGFsZ28gdG8gcHV0IHRoZSBTSUQgdGllLWJyYWtlIGJlZm9yZSB0aGUg cHJlZml4IHRpZS1icmVhayBhcyB3aXRoIHRoZSBwcmVmaXggdGllLWJyZWFrLCB3ZSBzdWZmZXIg ZnJvbSB0aGUgY29uZmxpY3QgdHdpY2UgKFByZWZpeCAtIFNJRCBtYXBwaW5nLCB0aGVuIFNJRC0g cHJlZml4IG1hcHBpbmcpIHdoaWNoIGluY3JlYXNlIHRoZSBkaXZlcnNpdHkgYW5kIGhlbmNlIHRo ZSBjaGFuY2Ugb2Ygbm90IGZpbmRpbmcgYSB2YWxpZCBlbnRyeS4gICBCdXQgZm9yIHRoZSBiZWxv dyBleGFtcGxlcywgSSB1c2VkIHRoZSBwcmVmZXJlbmNlIGFsZ28gZnJvbSBkcmFmdC1pZXRmLSot MDANCg0KDQpCZWxvdyBhcmUgZXhhbXBsZXMsIHJ1bm5pbmcgdGhpcyBwb2xpY3kgb24gdHlwaWNh bCBjb25maWd1cmF0aW9uIGVycm9yIGNhc2VzLg0KRXhhbXBsZXMNCjMuNC40LiAgTmV0d29yayBv cGVyYXRpb24NCg0KICAgQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBzaW1wbGUgbmV0d29yayBleGFt cGxlOg0KDQogICAxLiAgMTAwIG5vZGVzOiBSMSB0byBSMTAwOw0KDQogICAyLiAgSVAgTG9vcGJh Y2tzIGFyZSBmcm9tIDE5Mi4wLjIuMSB0byAxOTIuMC4yLjEwMDoNCg0KICAgMy4gIFNJRCBhcmUg ZnJvbSAxIHRvIDEwMDsNCg0KICAgNC4gIFIxIHRvIFI1MCBhcmUgU1IgY2FwYWJsZSBhbmQgYWR2 ZXJ0aXNlZCB0aGVpciBvd24gU0lEIHVzaW5nDQogICAgICAgUHJlZml4LVNJRCBzdWItVExWOw0K DQogICA1LiAgUjUxIHRvIFIxMDAgYXJlIFNSIG5vbi1jYXBhYmxlLCBydW5uaW5nIExEUCBhbmQg dGhlaXIgU0lEIGFyZQ0KICAgICAgIGFkdmVydGlzZWQgYnkgdHdvIHJlZHVuZGFudCBNYXBwaW5n IFNlcnZlciBNUzEgYW5kIE1TMjsNCg0KICAgNi4gIEFzIHRoZSBudW1iZXIgb2Ygbm9kZXMgd2hp Y2ggYXJlIFNSIGNhcGFibGUgYXJlIGV4cGVjdGVkIHRvDQogICAgICAgaW5jcmVhc2UgYW5kIGFz IGluIHJlYWwgZGVwbG95bWVudCB0aGVpciBMb29wYmFjayBhZGRyZXNzZXMgd291bGQNCiAgICAg ICBubyB0aGUgY29udGlndW91cywgdGhlIE1hcHBpbmcgc2VydmVycyBhZHZlcnRpc2VtZW50IGNv dmVycyBhbGwNCiAgICAgICBMb29wYmFja3M6ICgxOTIuMC4yLjEvMzIsIDEsIDEwMCk7DQoNCiAg IFN1YnNlcXVlbnQgc2VjdGlvbnMgZXZhbHVhdGUgdGhlIGNvbnNlcXVlbmNlcyBvZiBhIHNpbmds ZQ0KICAgY29uZmlndXJhdGlvbiBlcnJvciwgZm9yIGFsbCBjb25mbGljdCByZXNvbHV0aW9uIG9w dGlvbnMuDQoNCjMuNC40LjEuICBFeGFtcGxlIDE6IFNJRCBjb25maWd1cmVkIG9uIDEgbm9kZSBj b25mbGljdCB3aXRoIFNJRA0KICAgICAgICAgIGNvbmZpZ3VyZWQgb24gYW5vdGhlciBub2RlDQoN CiAgIEZvbGxvd2luZyBhIHR5cG8gZHVyaW5nIGNvbmZpZ3VyYXRpb24sIFIyIGlzIGNvbmZpZ3Vy ZWQgd2l0aCBhIFNJRCBvZg0KICAgMTIuICBUaGF0IFNJRCBjb25mbGljdHMgd2l0aCB0aGUgUHJl Zml4LVNJRCBhZHZlcnRpc2VkIGJ5IFIxMiBhbmQgdGhlIE1hcHBpbmcgU2VydmVyIEFkdmVydGlz ZW1lbnQgZm9yIFIxMi4NCiAgIE5vdGU6IGJvdGggTVMgYWR2ZXJ0aXNlbWVudCBhcmUgdGhlIHNh bWUsIHNvIHdlIG9ubHkgY29uc2lkZXIgb25lIGluIHRoZSBiZWxvdyBhbmFseXNpcy4NCg0KICAg QWxsIHByZWZpeCBidXQgUjIgYW5kIFIxMiwgYSBzaW5nbGUgU0lEIGlzIGFkdmVydGlzZWQgYW5k IGhlbmNlIHNlbGVjdGVkLg0KDQogICBGb3IgUjIsIHRoZSBhbGdvIGV2YWx1YXRlcyBhIGNvbmZs aWN0IGJldHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOg0KICAgUjIgLSBTSUQyIC0g UjIgKE1TLCBNUykNCiAgIFIyIC0gU0lEMTIgLSBSMTIgKHByZWZpeCBTSUQsIE1TKQ0KICAgUjIg LSBTSUQxMiAtIFIyICAocHJlZml4IFNJRCwgcHJlZml4IFNJRCkNCg0KDQogICBCZXN0IG9uZSBp cyBSMiAtIFNJRDEyIC0gUjIgKHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpLHNtYWxsZXIgcmFu Z2UgKHByZWZpeCBTSUQpKQ0KICAgPT0+IFNJRDEyIGlzIHNlbGVjdGVkIGZvciBSMi4NCg0KICAg Rm9yIFIxMiwgdGhlIGFsZ28gZXZhbHVhdGVzIGEgY29uZmxpY3QgYmV0d2VlbiB0aGUgZm9sbG93 aW5nIGFkdmVydGlzbWVudHM6DQogICBSMTIgLSBTSUQxMiAtIFIxMiAocHJlZml4IFNJRCwgcHJl Zml4IFNJRCkNCiAgIFIxMiAtIFNJRDEyIC0gUjIgIChwcmVmaXggU0lELCBwcmVmaXggU0lEKQ0K ICAgUjEyIC0gU0lEMTIgLSBSMTIgKHByZWZpeCBTSUQsIE1TKQ0KICAgUjEyIC0gU0lEMTIgLSBS MiAgKE1TLCBwcmVmaXggU0lEKQ0KICAgUjEyIC0gU0lEMTIgLSBSMTIgKE1TLCBNUykNCg0KICAg QmVzdCBvbmUgaXMgUjEyIC0gU0lEMTIgLSBSMiAoc21hbGxlciByYW5nZSAocHJlZml4IFNJRCks c21hbGxlciByYW5nZSAocHJlZml4IFNJRCksIHNtYWxsZXIgc3RhcnRpbmcgYWRyZXNzZSAoUjIp KQ0KICAgUjEyIDw+IFIyID09PiBSMTIgaGFzIG5vIFNJRC4NCg0KICAgMy40LjQuMi4gIEV4YW1w bGUgMjogU0lEIGNvbmZpZ3VyZWQgb24gMSBub2RlIGNvbmZsaWN0IHdpdGggU0lEDQogICAgICAg ICAgY29uZmlndXJlZCBvbiB0aGUgTWFwcGluZyBTZXJ2ZXINCg0KICAgRm9sbG93aW5nIGEgdHlw byBkdXJpbmcgY29uZmlndXJhdGlvbiwgUjIgaXMgY29uZmlndXJlZCB3aXRoIGEgU0lEIG9mDQog ICA1Mi4gIFRoYXQgU0lEIGNvbmZsaWN0cyB3aXRoIHRoZSBNYXBwaW5nIFNlcnZlciBhZHZlcnRp c2VtZW50cyBvZiBNUzENCiAgIGFuZCBNUzIgZm9yIHRoZSBsb29wYmFjayBvZiBSNTIuDQogICBO b3RlOiBib3RoIE1TIGFkdmVydGlzZW1lbnQgYXJlIHRoZSBzYW1lLCBzbyB3ZSBvbmx5IGNvbnNp ZGVyIG9uZSBpbiB0aGUgYmVsb3cgYW5hbHlzaXMuDQoNCiAgIEFsbCBwcmVmaXggYnV0IFIyIGFu ZCBSNTIsIGEgc2luZ2xlIFNJRCBpcyBhZHZlcnRpc2VkIGFuZCBoZW5jZSBzZWxlY3RlZC4NCg0K ICAgRm9yIFIyLCB0aGUgYWxnbyBldmFsdWF0ZXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSBmb2xs b3dpbmcgYWR2ZXJ0aXNtZW50czoNCiAgIFIyIC0gU0lENTIgLSBSMiAgKHByZWZpeCBTSUQsIHBy ZWZpeCBTSUQpDQogICBSMiAtIFNJRDUyIC0gUjUyIChwcmVmaXggU0lELCBNUykNCiAgIFIyIC0g U0lEMiAgLSBSMiAgKE1TLCBNUykNCg0KICAgQmVzdCBvbmUgaXMgUjIgLSBTSUQ1MiAtIFIyIChz bWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSxzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSkNCiAg ID09PiBTSUQ1MiBpcyBzZWxlY3RlZCBmb3IgUjIuDQoNCiAgIEZvciBSNTIsIHRoZSBhbGdvIGV2 YWx1YXRlcyBhIGNvbmZsaWN0IGJldHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOg0K ICAgUjUyIC0gU0lENTIgLSBSNTIgKE1TLCBNUykNCiAgIFI1MiAtIFNJRDUyIC0gUjIgIChNUywg cHJlZml4IFNJRCkNCg0KICAgQmVzdCBvbmUgaXMgUjUyIC0gU0lENTIgLSBSMiAoc21hbGxlciBy YW5nZSAocHJlZml4IFNJRCkpDQogICBSNTIgPD4gUjIgPT0+IFI1MiBoYXMgbm8gU0lELg0KDQoN CjMuNC40LjMuICBFeGFtcGxlIDM6IHdyb25nIGNvbmZpZ3VyYXRpb24gb2YgYSBNUw0KDQogICBG b2xsb3dpbmcgYSB0eXBvIGR1cmluZyBjb25maWd1cmF0aW9uLCBNUzEgaXMgY29uZmlndXJlZA0K ICAgKDE5Mi4wLjIuMC8zMiwgMSwgMTAwKS4gKGkuZS4gMTkyLjAuMi4wIGluc3RlYWQgb2YgMTky LjAuMi4xKS4gIFRoYXQNCiAgIGFkdmVydGlzZW1lbnQgY29uZmxpY3RzIHdpdGggdGhlIE1hcHBp bmcgU2VydmVyIGFkdmVydGlzZW1lbnRzIG9mIE1TMg0KICAgYW5kIHRoZSBQcmVmaXgtU0lEIGFk dmVydGlzZWQgYnkgUjEuLi5SNTAuDQoNCiAgIFdlIGhhdmUgYSBjb25mbGljdCBmb3IgYWxsIHJv dXRlcnMgZXhjZXB0IFIxMDAuDQoNCiAgIEZvciBMRFAgb25seSByb3V0ZXJzIFI1MSB0byBSOTkg d2UgaGF2ZSBhIGNvbmZsaWN0IGJldHdlZW4gYm90aCBNUyBhZHZlcnRpc2VtZW50Lg0KICAgRm9y IFI1MiwgdGhlIGFsZ28gZXZhbHVhdGVzIGEgY29uZmxpY3QgYmV0d2VlbiB0aGUgZm9sbG93aW5n IGFkdmVydGlzbWVudHM6DQogICBSNTIgLSBTSUQ1MiAtIFI1MiAoTVMyLCBNUzIpDQogICBSNTIg LSBTSUQ1MiAtIFI1MSAoTVMyLCBNUzEpDQogICBSNTIgLSBTSUQ1MyAtIFI1MiAoTVMxLCBNUzEp DQogICBSNTIgLSBTSUQ1MyAtIFI1MyAoTVMxLCBNUzIpDQoNCiAgIEJlc3Qgb25lIGlzIFI1MiAt IFNJRDUyIC0gUjUxIChzbWFsbGVyIHN0YXJ0aW5nIGFkZHJlc3MpDQogICBSNTIgPD4gUjUxID09 PiBSNTIgaGFzIG5vIFNJRC4NCg0KICAgRm9yIFNSIHJvdXRlcnMsIFIxIHRvIDUwLCB3ZSBoYXZl IGEgY29uZmxpY3QgYmV0d2VlbiBib3RoIE1TIGFkdmVydGlzZW1lbnQgYW5kIFByZWZpeCBTSUQg YWR2ZXJ0aXNlbWVudHMuDQogICBGb3IgUjIsIHRoZSBhbGdvIGV2YWx1YXRlcyBhIGNvbmZsaWN0 IGJldHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOg0KICAgUjIgLSBTSUQgMiAtIFIy IChQcmVmaXggU0lELCBQcmVmaXggU0lEKQ0KICAgUjIgLSBTSUQgMiAtIFIyIChQcmVmaXggU0lE LCBNUzIpDQogICBSMiAtIFNJRCAyIC0gUjEgKFByZWZpeCBTSUQsIE1TMSkNCiAgIFIyIC0gU0lE IDIgLSBSMiAoTVMyLCBNUzIpDQogICBSMiAtIFNJRCAyIC0gUjIgKE1TMiwgUHJlZml4IFNJRCkN CiAgIFIyIC0gU0lEIDIgLSBSMSAoTVMyLCBNUzEpDQogICBSMiAtIFNJRCAzIC0gUjIgIChNUzEs IE1TMSkNCiAgIFIyIC0gU0lEIDMgLSBSMyAgKE1TMSwgTVMyKQ0KICAgUjIgLSBTSUQgMyAtIFIz ICAoTVMxLCBQcmVmaXggU0lEKQ0KDQogICBCZXN0IG9uZSBpcyBSMiAtIFNJRCAyIC0gUjIgKFBy ZWZpeCBTSUQsIFByZWZpeCBTSUQpDQogICBSMiA9PSBSMiBoZW5jZSBSMiB1c2UgU0lEMi4NCg0K UmVnYXJkcywNCkJydW5vDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s DQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0K DQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N Cg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0K T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u DQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz Lg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoN ClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0K DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4N Cg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpU aGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoN CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhh bmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5r IHlvdS4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0Kc3ByaW5nIG1haWxpbmcgbGlzdA0KDQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu Zw0KDQoNCg== --_000_4A79394211F1AF4EB57D998426C9340DD49C6D94US70UWXCHMBA01z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUHJm b3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhU TUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuUHJmb3JtYXRIVE1MLCBsaS5QcmZvcm1h dEhUTUwsIGRpdi5QcmZvcm1hdEhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBI VE1MIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3Jt YXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVz IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBk ZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLlRleHRl ZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHls ZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUzNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM2DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwNzg3NDU3NjU7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NTY5MTExOTAgNjc4OTUzMTkgNjc4OTUzMjEg Njc4OTUzMjMgNjc4OTUzMTEgNjc4OTUzMjEgNjc4OTUzMjMgNjc4OTUzMTEgNjc4OTUzMjEgNjc4 OTUzMjM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBXaW0g YW5kIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5vbmUgb3BlcmF0aW9uYWwgYXNwZWN0IGluIGZhdm9yIG9m IGlnbm9yaW5nIG9ubHkgdGhlIGxlc3MgcHJlZmVycmVkIGVudHJ5IHdoaWNoIGFjdHVhbGx5IGNv bmZsaWN0cyBpcyB0aGF0IGZvciBhIGdpdmVuIHByZWZpeCwgYSBTSUQgdmFsdWUgcmVjZWl2ZWQg aW4gYSBwcmVmaXggVExWIGlzIGFsd2F5cw0KIHByZWZlcnJlZCBvdmVyIGEgU0lEIHZhbHVlIHJl Y2VpdmVkIGluIGEgbWFwcGluZyBzZXJ2ZXIgcHJlZml4IHJhbmdlIFRMVi4gV2l0aCB0aGUgcXVh cmFudGluZSBtZXRob2QsIHlvdSB3aWxsIG1vcmUgb2Z0ZW4gcHV0IHRoZSBlbnRpcmUgbWFwcGlu ZyBzZXJ2ZXIgcmFuZ2UgVExWIGluIHF1YXJhbnRpbmUgd2hpY2ggd2lsbCBiZSB0b28gZGlzcnVw dGl2ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11c3RhcGhhLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNwcmluZyBbPGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5IZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0gQkUpPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgSnVseSAyMiwgMjAxNiA1OjM1IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0 aW4gSG9ybmVmZmVyOyBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgPGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyI+DQpzcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiBIb3Ju ZWZmZXIsIE1hcnRpbjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gZHJhZnQtaWV0 Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkFzIDEgb2YgdGhlIHZlbmRvcnMgaW1wbGVtZW50 aW5nIHRoaXMsIHdlIHByZWZlciB0aGUgYXBwcm9hY2ggb2YgaWdub3JlIG92ZXJsYXAgYXMgSSBz YWlkIGluIHRoZSBtZWV0aW5nIGluIEJlcmxpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj5UaGUgaW1wbGljYXRpb24gZnJvbSBpbXBsZW1lbnRhdGlvbiBzIGFy ZSBub3QgbWFzc2l2ZSBhbmQgZ2l2ZW4gaXQgaXMgbWF4aW1pc2luZyB0cmFmZmljIGRlbGl2ZXJ5 IGluIGNhc2Ugb2YgY29uZmxpY3QsIHdlIHByZWZlciB0aGlzIGFwcHJvYWNoLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24gYmVoYWxmIG9mIE1hcnRpbiBIb3JuZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzptYWhvQG5p Yy5kdGFnLmRlIj5tYWhvQG5pYy5kdGFnLmRlPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJp ZGF5IDIyIEp1bHkgMjAxNiBhdCAxMTowMTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7TGVzIEdpbnNi ZXJnIChnaW5zYmVyZykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5j b20iPmdpbnNiZXJnQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c3By aW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8 L2I+TWFydGluIEhvcm5lZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcnRpbi5Ib3JuZWZmZXJA dGVsZWtvbS5kZSI+TWFydGluLkhvcm5lZmZlckB0ZWxla29tLmRlPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24gLSBQb2xpY3k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj5IaSBMZXMsPGJyPg0KPGJyPg0KY29tbWVudGluZyByYXRoZXIgb24geW91ciBwcmVzZW50 YXRpb24gYXQgdGhlIEJlcmxpbiBXRyBzZXNzaW9uOjxicj4NCjxicj4NCkluIGdlbmVyYWwgSSBk b24ndCBjb25zaWRlciBpdCBhIGJpZyBkZWFsIHdoZXRoZXIgdGhlIFF1YXJhbnRpbmUgb3IgdGhl IElnbm9yZSBPdmVybGFwIHBvbGljeSBpcyBiZWluZyB1c2VkLiBJdCdzIG1haW5seSBpbXBvcnRh bnQgdGhhdCBfb25lXyBvZiB0aGVuIGZpbmFsbHkgZ2V0cyBjaG9zZW4gYW5kIGNvbnNpc3RlbnRs eSBpbXBsZW1lbnRlZC48YnI+DQo8YnI+DQpGcm9tIHRoZSBvcGVyYXRvcidzIHBvaW50IG9mIHZp ZXcgSSB0ZW5kIHRvIGFncmVlIHdpdGggb3RoZXIgb3BlcmF0b3JzIHRoYXQgdGhlIElnbm9yZSBP dmVybGFwIHBvbGljeSBsb29rcyBiZXR0ZXIgZm9yIG1vc3QgcmVhbGlzdGljIGNhc2VzLCBldmVu IHRob3VnaCBsZXNzIHdvcnJpZWQgYWJvdXQgdGhlIGFtb3VudCBvZiB0cmFmZmljIGxvc3QsIGJ1 dCBtb3JlIGFib3V0IHJvYnVzdG5lc3MgYW5kIHNlY3VyaXR5IGFzcGVjdHMuPGJyPg0KPGJyPg0K Q29tcGxleGl0eSBvZiBpbXBsZW1lbnRhdGlvbiwgaG93ZXZlciwgY2FuIGJlIGEgc2VyaW91cyBh cmd1bWVudCBhZ2FpbnN0IGl0LCBhcyB0aGlzIGFsc28gd29ya3MgYWdhaW5zdCByb2J1c3RuZXNz IGFuZCBzZWN1cml0eS48YnI+DQo8YnI+DQpOb2JvZHkgZG91YnRzIHRoYXQgdGhlIElnbm9yZSBP dmVybGFwIHBvbGljeSBpcyBtb3JlIGNvbXBsZXguIEJ1dCBob3cgbXVjaCBjb21wbGV4aXR5IGl0 IHJlYWxseSBhZGRzIGlzIGhhcmQgdG8gZXN0aW1hdGUgZm9yIG1lLiBJcyBpdCBhIG1pbm9yIGNv bXBsaWNhdGlvbiBvciBhIGJpZyBvbmU/PGJyPg0KPGJyPg0KU28gZmFyIEkgaGF2ZSBzZWVuIG9u ZSB2ZW5kb3IgdGFsayBhZ2FpbnN0IHRoZSBJZ25vcmUgT3ZlcmxhcCBwb2xpY3kgYW5kIHR3byB2 ZW5kb3JzIHRha2luZyBhIHBvc2l0aW9uIGluIGZhdm9yIG9mIGl0Ljxicj4NCjxicj4NClNvdW5k cyB0byBtZSBsaWtlIDI6MSBmb3IgSWdub3JlIE92ZXJsYXAgc28gZmFyLiBCdXQgd2UgYWN0dWFs bHkgZG9uJ3QgYmVsaWV2ZSBpbiB2b3RpbmcgYW5kIG5lZWQgbW9yZSB2ZW5kb3IgaW5wdXQgYW55 d2F5cyE8YnI+DQo8YnI+DQpCUiw8YnI+DQpNYXJ0aW48YnI+DQo8YnI+DQo8YnI+DQpBbSAwNS4w Ny4xNiB1bSAxOToyNSBzY2hyaWViIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+QnJ1bm8g4oCTPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5Ud28gY29tbWVudHM6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4xKUFzIHdlIGJvdGggY2FuIGNvbWUgdXAgd2l0aCBleGFtcGxlcyB3 aGVyZSBhIGdpdmVuICZuYnNwO3ByZWZlcmVuY2UgYWxnb3JpdGhtIHdpbGwgcmVzdWx0IGluIOKA nGJldHRlcuKAnSBiZWhhdmlvciB0aGFuIGFub3RoZXIsIGNvbnRpbnVpbmcgdG8gZGViYXRlIHdo aWNoIG9uZSBpcyDigJxiZXN04oCdIGhhcyBubyBlbmQuIFRoZSBhbnN3ZXIgZGVwZW5kcyB1cG9u IHdoYXQgdHlwZXMNCiBvZiBlcnJvcnMgYXJlIGludHJvZHVjZWQgaW4gdGhlIGNvbmZpZ3VyYXRp b24gYW5kIHRoYXQgaXNu4oCZdCBwcmVkaWN0YWJsZS4gSWYgaXQgaXMgbmVjZXNzYXJ5IGZvciB1 cyB0byBhZ3JlZSBvbiB3aGljaCBhbGdvcml0aG0gaXMg4oCcYmVzdOKAnSBJIGRvdWJ0IHRoYXQg Y29uc2Vuc3VzIHdpbGwgZXZlciBiZSByZWFjaGVkLiBJdCB0aGVyZWZvcmUgaXMgbW9yZSBpbXBv cnRhbnQgdG8gbWUgdG8gZm9jdXMgb24gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eQ0KIGFuZCB0 aGUgaW1wb3J0YW5jZSBvZiBpZGVudGlmeWluZyBhbmQgY29ycmVjdGluZyBtaXNjb25maWd1cmF0 aW9ucyBBU0FQLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ MilUaGVyZSBhcmUgdHdvIGxvZ2ljYWwgZGF0YWJhc2VzIHRoYXQgYW4gaW1wbGVtZW50YXRpb24g aGFzIHRvIHN1cHBvcnQuIE9uZSBvZiB0aGVtIGlzIHRoZSBzZXQgb2YgcmVjZWl2ZWQgYWR2ZXJ0 aXNlbWVudHMgd2hpY2ggY2FuIGluY2x1ZGUgZW50cmllcyB3aXRoIGEgdmFyaWV0eSBvZiByYW5n ZXMuIFRoZSBzZWNvbmQgb25lIGlzIHRoZSBzZXQgb2YgbWFwcGluZw0KIGVudHJpZXMgd2hpY2gg YXJlIGluIHVzZSBmb3IgbG9va3Vwcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+WW91ciBkaXNjdXNzaW9uIG9mIHlvdXIg4oCccGVyIEZFQyBhbGdvcml0 aG3igJ0gJm5ic3A7YmVsb3cgZGVmaW5lcyB0aGUgc2Vjb25kIGRhdGFiYXNlIGFzIGEgc2V0IG9m IGVudHJpZXMgYWxsIG9mIHdoaWNoIGhhdmUgYSByYW5nZSBvZiAxLiBXaGV0aGVyIHRoaXMgaXMg Z29vZCBpbXBsZW1lbnRhdGlvbiBtb2RlbCBvciBub3QgSSBhbSBub3QgY29tbWVudGluZyBvbiBo ZXJlLg0KIEJ1dCB0aGlzIGRvZXMgbm90IGVsaW1pbmF0ZSB0aGUgbmVlZCB0byBtYWludGFpbiB0 aGUgZmlyc3QgZGF0YWJhc2Ug4oCTIGFuZCB0byBiZSBhYmxlIHRvIGFzc29jaWF0ZSBlbnRyaWVz IGluIHRoZSBzZWNvbmQgZGF0YWJhc2Ugd2l0aCB0aGUgY29ycmVzcG9uZGluZyByZWNlaXZlZCBl bnRyeSBmcm9tIHdoaWNoIHRoZXkgbWF5IGhhdmUgYmVlbiBkZXJpdmVkLiBUaGVyZSBpcyB3b3Jr IGluIG1haW50YWluaW5nIHRoYXQgcmVsYXRpb25zaGlwIHdoaWNoDQogZG9lcyBub3QgZGlyZWN0 bHkgYmVhciBvbiB0aGUgbG9va3VwIGZvciBhIGdpdmVuIFNJRCBidXQgc3RpbGwgaGFzIHRvIGJl IGRvbmUgaWYgb25lIHVzZXMg4oCccGVyIEZFQ+KAnSBvciDigJxJZ25vcmUgT3ZlcmxhcCBPbmx5 4oCdLiBUaGlzIHdvcmsgaXMgbm90IHJlcXVpcmVkIGZvciB0aGUg4oCccGVyIHJhbmdl4oCdIG9y IOKAnFF1YXJhbnRpbmXigJ0gYWxnb3JpdGhtLiBJdCBpcyB0aGlzIGFkZGl0aW9uYWwgd29yayB0 aGF0IEkgcmVmZXIgdG8gd2hlbiBJIHNheSB0aGF0DQog4oCccGVyIEZFQ+KAnSBoYXMgYSBoaWdo ZXIgaW1wbGVtZW50YXRpb24gY29zdC9jb21wbGV4aXR5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWls dG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwv YT4NCiBbPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPm1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBKdWx5IDA1LCAyMDE2IDE6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5z cHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRmLXNw cmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0 QTIiPkxlcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPlBs ZWFzZSBzZWUgaW5saW5lIFtCcnVub108L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgWzwv c3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxh IGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj5tYWls dG86Z2luc2JlcmdAY2lzY28uY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5 IDA1LCAyMDE2IDk6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IERFQ1JBRU5FIEJydW5vIElNVC9PTE48 YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPjxzcGFuIGxh bmc9IkVOLVVTIj5zcHJpbmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFm dC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkJydW5vIOKAkzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Q29uc2lkZXIgdGhlIGZvbGxvd2luZyBzaW1wbGUgY2FzZTo8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVudHJ5ICMxOiAoUEZYLCAxLjEu MS4xLzMyLCAxMDAsIDEsIDAsMCk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+RW50cnkgIzI6IChTUk1TLCAxLjEuMS4xLzMyLCAyMDAsIDEwLCAwLDApPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVudHJ5ICMzOiAo U1JNUywgMi4yLjIuMi8zMiwgMjAwLCAxMC4gMCwgMCk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIGEgbWlzY29uZmlndXJhdGlvbiBoZXJlLCBi dXQgd2UgZG9u4oCZdCBrbm93IHdoYXQgd2FzIHJlYWxseSBpbnRlbmRlZC4gQSBmZXcgKG9mIG1h bnkpIHBvc3NpYmlsaXRpZXM6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5FUlJPUiAjMTombmJzcDsmbmJzcDsgRW50cnkgIzIgc2hvdWxkIGhhdmUgYmVlbjog KFNSTVMsIDEuMS4xLjEvMzIsIDEwMCwgMTAsIDAsMCkgIVN0YXJ0aW5nIFNJRCBlcnJvcjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FUlJPUiAjMjombmJz cDsgRW50cnkgIzIgc2hvdWxkIGhhdmUgYmVlbjogKFNSTVMsIDIuMi4yLjIvMzIsIDIwMCwgMTAs IDAsMCkgIVN0YXJ0aW5nIHByZWZpeCBlcnJvcjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+VGhlIGRyYWZ0IGRlZmluZXMgdHdvIGNhbmRpZGF0ZSBwcmVmZXJl bmNlIHJ1bGVzIHdoaWNoIGNvdWxkIGJlIGFwcGxpZWQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5RdWFyYW50aW5lPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgd2UgZXZhbHVhdGUgcHJlZml4IGNv bmZsaWN0cyBmaXJzdCwgd2UgY29tcGFyZSBFbnRyeSAjMSBhbmQgRW50cnkgIzIgYW5kIGNob29z ZSBFbnRyeSAjMSB0aGUgd2lubmVyIChzb3VyY2UgaXMgUEZYKS4gRW50cnkgIzIgaXMgdGhlbiBu b3QgdXNlZCAocXVhcmFudGluZWQpIGFuZCB0aGUgc2V0IG9mIGFjdGl2ZSBlbnRyaWVzIGlzOjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RW50cnkgIzE6IChQ RlgsIDEuMS4xLjEvMzIsIDEwMCwgMSwgMCwwKTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAjMzogKFNSTVMsIDIuMi4yLjIvMzIsIDIwMCwgMTAu IDAsIDApPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZ25v cmUgQ29uZmxpY3QgT25seTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIHRoaXMgY2FzZSB3ZSBzcGxpdCBFbnRyeSAjMiBp bnRvIHR3byBkZXJpdmVkIGVudHJpZXM6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5FbnRyeSAjMkE6IChTUk1TLCAxLjEuMS4xLzMyLCAyMDAsIDEsIDAsMCk8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RW50cnkgIzJC OiAoU1JNUywgMS4xLjEuMi8zMiwgMjAxLCA5LCAwLDApPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAyQSBpcyB0aGVuIGlnbm9yZWQgYW5kIHdlIHRo ZW4gaGF2ZSB0byBldmFsdWF0ZSBTSUQgY29uZmxpY3RzIGJldHdlZW4gdGhlIGRlcml2ZWQgZW50 cnkgMkIgYW5kIEVudHJ5ICMzLiAmbmJzcDtGb3IgdGhpcyB3ZSBoYXZlIHRvIHNwbGl0IEVudHJ5 IDMgaW50byB0d28gZGVyaXZlZCBlbnRyaWVzOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+RW50cnkgIzNBOiAoU1JNUywgMi4yLjIuMi8zMiwgMjAwLCAxLiAw LCAwKTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRy eSAjM0I6IChTUk1TLCAyLjIuMi4zLzMyLCAyMDEsIDkuIDAsIDApPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAyQiB3aW5zIG92ZXIgZW50cnkgM0Ig c2luY2UgaXQgaGFzIGEgc21hbGxlciByYW5nZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkFjdGl2ZSBlbnRyaWVzIGFyZSB0aGVuOjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAjMTogKFBGWCwgMS4xLjEu MS8zMiwgMTAwLCAxLCAwLDApPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkVudHJ5ICMyQjogKFNSTVMsIDEuMS4xLjIvMzIsIDIwMSwgOSwgMCwwKTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbnRyeSAjM0E6IChT Uk1TLCAyLjIuMi4yLzMyLCAyMDAsIDEuIDAsIDApPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5Ob3RlIHRoYXQgaW4gdGhpcyBleGFtcGxlIGJvdGggcHJlZmVy ZW5jZSBydWxlcyByZXN1bHQgaW4gMTEgZGVzdGluYXRpb25zIGhhdmluZyBub24tY29uZmxpY3Rp bmcgU0lEcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+ W0JydW5vXSBZZXMuIFRoZSBpbXBvcnRhbnQgcGFydCBpcyDCqyZuYnNwO2luIHRoaXMgZXhhbXBs ZSZuYnNwO8K7LiBOb3cgZG8gd2UgYWdyZWUgdGhhdCBpbiBhdmVyYWdlLCBRdWFyYW50aW5lIHdp bGwgcmVzdWx0IGluIGRyb3BwaW5nIG1vcmUgZGVzdGluYXRpb25zIHRoYW4gSWdub3JlIGNvbmZs aWN0IG9ubHk/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDtOb3csIHdoaWNoIG9mIHRoZXNlIG1heGltaXplcyBkZWxpdmVyeSBvZiB0cmFmZmljPyBU aGUgYW5zd2VyIHRvIHRoYXQgZGVwZW5kcyB1cG9uIHRoZSB0eXBlIG9mIGNvbmZpZ3VyYXRpb24g ZXJyb3IgdGhhdCB3YXMgbWFkZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SWYgRXJyb3IgIzEgd2FzIG1hZGUsIHRoZXJlIGlzIG5vIHdheSB0byBkaWZm ZXJlbnRpYXRlIHRoZSB0d28gcHJlZmVyZW5jZSBydWxlcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYgRXJyb3IgIzIgd2FzIG1hZGUs IHRoZW4gUXVhcmFudGluZSBpcyBjbGVhcmx5IGJldHRlciBiZWNhdXNlIHRoZSBkZXN0aW5hdGlv bnMgMS4xLjEuMiDigJMgMS4xLjEuMTAgd2VyZSBuZXZlciBpbnRlbmRlZCB0byBoYXZlIGFzc2ln bmVkIFNJRHMgYW5kIG1heSBub3QgZXZlbiBleGlzdCBhcyBkZXN0aW5hdGlvbnMgaW4gdGhlIG5l dHdvcmssIHlldA0KIOKAnElnbm9yZSBDb25mbGljdCBPbmx54oCdIGZhdm9ycyB0aG9zZSBwcmVm aXhlcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBw b2ludCBJIGFtIHRyeWluZyB0byBtYWtlIGlzIHRoYXQgaXQgaXMgaW5jb3JyZWN0IHRvIHNheSDi gJxJZiB3ZSBtYXhpbWl6ZSB0aGUgbnVtYmVyIG9mIGFkdmVydGlzZWQgZW50cmllcyB3aGljaCB3 ZSB1c2Ugd2Ugd2lsbCBhbHdheXMgZG8gYSBiZXR0ZXIgam9iIG9mIGRlbGl2ZXJpbmcgdHJhZmZp Yy7igJ0gVGhpcyBleGFtcGxlIGlsbHVzdHJhdGVzIHRoYXQNCiB0aGlzIGlzbuKAmXQgYWx3YXlz IHRydWUuIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5b QnJ1bm9dIE9LLiBDbGVhcmx5LCB3ZSBjYW4gZmluZCBhbiBleGFtcGxlIHdoZXJlIGFuIGFsZ29y aXRobSBpcyBiZXR0ZXIgdGhhbiB0aGUgb3RoZXIuIEFmdGVyIGFsbCwgd2UgYWxsIGFncmVlIHRo YXQgdGhlcmUgaGFzIGJlZW4gYSBjb25maWd1cmF0aW9uIGVycm9yLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5UaGVyZSBhcmUgMiBwb2ludHM6PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YSk8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xv cjojODA2NEEyIj5ob3cgbWFueSBkZXN0aW5hdGlvbiB5b3Uga2VlcCB1c2luZzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6Izgw NjRBMiI+aW4gY2FzZSBvZiBjb25mbGljdCB3aGljaCBvZiB0aGUgZW50cmllcyB5b3Ugc2VsZWN0 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5JIGFncmVlIHRo YXQg4oCcYuKAnSBpcyBtb3JlIG9yIGxlc3MgcmFuZG9tIGFuZCBoZW5jZSB0aGVyZSBhcmUgbWFu eSBjYXNlcyB3aGVyZSB3ZeKAmWxsIHBpY2sgdGhlIHdyb25nIG9uZS4gWWV0LCB3ZSB0cnkgdG8g bWFrZSByZWFzb25hYmxlIGNob2ljZXMuIFRoYXQgdGhlIHBvaW50IG9mIGRpc2N1c3NpbmcgdGhl IHByZWZlcmVuY2UgYWxnb3JpdGhtICgzLjIuNCkuIChBbHRob3VnaA0KIGl04oCZcyB2ZXJ5IGVh c3kgdG8gYXJndWUgdGhhdCB3ZSBjYW4gbWFrZSB0aGUgd3JvbmcgY2hvaWNlLCBJIGRvbuKAmXQg ZmVlbCB0aGF04oCZcyBhIHJlYXNvbiBub3QgdG8gdHJ5IGRpc2N1c3NpbmcgaXQgYW5kIG1ha2Ug Y2hvaWNlLiBlLmcuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IOKAnDwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+UEZYIHNvdXJjZSB3aW5zIG92ZXIgU1JNUyBzb3Vy Y2XigJ0gaXMgb25lOiB3ZSBnaXZlIHByZWZlcmVuY2UNCiB0byBTUiBub2RlcyByYXRoZXIgdGhh biBMRFAgbm9kZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0 QTIiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEy Ij5SZWdhcmRpbmcgYSwgSSBmZWVsIHRoYXQgbWF4aW1pemluZyB0aGUgbnVtYmVyIG9mIGRlc3Rp bmF0aW9ucyBrZXB0LCBpcyBsaWtlbHkgdG8gZ2l2ZSB0aGUgYmVzdCByZXN1bHQgaW4gYXZlcmFn ZS4gSSBkb27igJl0IGhhdmUgYSBwcm9vZiwgYnV0IGl0IGZlZWwgbGlrZSBwbGF5aW5nIGxvdG86 IGV2ZW4gaWYgZWFjaCBjaG9pY2UgaXMgcmFuZG9tICjigJxi4oCdKSwgdGhlDQogbW9yZSB5b3Ug dHJ5ICjigJxh4oCdKSB0aGUgYmV0dGVyIHlvdXIgY2hhbmNlcy4mbmJzcDsgPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QSBmZXcgbW9yZSBjb21tZW50cyBpbmxp bmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFj ayI+PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwv c3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pls8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFp bHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAwNCwgMjAxNiA1OjA3IEFNPGJyPg0KPGI+VG86PC9i PiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c3ByaW5nQGlldGYu b3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3Qt cmVzb2x1dGlvbiAtIFBvbGljeTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TGVzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSBbPC9zcGFuPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpnaW5zYmVy Z0BjaXNjby5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFp bHRvOmdpbnNiZXJnQGNpc2NvLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5 IDAxLCAyMDE2IDM6MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IERFQ1JBRU5FIEJydW5vIElNVC9PTE48 YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPnNwcmluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBQb2xpY3k8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+QnJ1bm8g4oCTPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgZmluZCB5b3VyIHJlcHJlc2VudGF0aW9uIGNv bXBsZXRlIGFzIHJlZ2FyZHMgYWxsIG9mIHRoZSBhdHRyaWJ1dGVzIHdoaWNoIGFyZSBwcm9wb3Nl ZCB0byBiZSB1c2VkIGJ5IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIGFsZ29yaXRobSDigJMgc28g aXQgaXMgdGhlcmVmb3JlIGhhcmQgZm9yIG1lIHRvIHVzZS91bmRlcnN0YW5kIHRoaXMgcmVwcmVz ZW50YXRpb24NCiB3aGVuIGFwcGx5aW5nIHRoZSBkZWZpbmVkIHByZWZlcmVuY2UgcnVsZS48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBpcyB0cnVl IGZvciBtZSBldmVuIGFmdGVyIHJlYWRpbmcgeW91ciBleHBsYW5hdGlvbnMgYmVsb3cuDQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCBpdCBpcyBmYXIg bW9yZSBpbXBvcnRhbnQgdG8gaGF2ZSBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBhbGdv cml0aG0gcHJvcG9zYWwgdGhhbiBpdCBpcyB0byBiZSBhcmd1aW5nIG92ZXIgd2hvc2UgZW5jb2Rp bmcgaXMg4oCcYmV0dGVy4oCdLiBJZiB0aGUgZW5jb2RpbmcgaW4gdGhlIGRyYWZ0IGlzIG5vdCBj bGVhciBvciBjb3VsZCB1c2UgaW1wcm92ZW1lbnQsDQogSSB3ZWxjb21lIHlvdXIgZmVlZGJhY2su IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgZmFyIGFz IHlvdXIg4oCccHNldWRvLWNvZGXigJ06PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6I0MwMDAwMCI+LSBGaW5kIGFsbCBTSURp IGFkdmVydGlzZWQgZm9yIHRoZSBwcmVmaXggUDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gaWRlbnRpZmljYXRpb24gb2Yg UHJlZml4IGNvbmZsaWN0czwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtIEZvciBlYWNoIFNJRGkgZmluZCBhbGwgdGhlIHByZWZpeCBQaWog YXNzb2NpYXRlZCB3aXRoIFNJRGkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ly8gaWRlbnRpZmljYXRp b24gb2YgU0lEIGNvbmZsaWN0czwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZuYnNwOzwvc3Bhbj48 L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiNDMDAwMDAiPkdldCB0aGUgYmVzdCBhcyBwZXIgdGhlIHByZWZlcmVuY2UgYWxnb3Jp dGhtLjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPklmIGJlc3QgUGlqID09IFAxPC9zcGFuPjwvaT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29s b3I6I0MwMDAwMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gdXNlIFNJ RGlqIGZvciBQMTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDAwMDAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBlbHNlIHJldHVybiBubyBTSUQ8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xv cjojQzAwMDAwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGZhY3QgdGhhdCB5b3Ug Y2FuIHJlcHJlc2VudCBhbiBhbGdvcml0aG0gaW4gYSBmZXcgbGluZXMgZG9lcyBub3QgbWVhbiB0 aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGFsZ29yaXRobSBpcyBqdXN0IGFzIHNpbXBsZS48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bQnJ1bm9dIFN1cmUuIEJ1 dCBpZiB3ZSB3YW50IHRvIGNvbXBhcmUgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSwgd2XigJls bCBuZWVkIHRvIGFncmVlIG9uIGhvdyBtdWNoIHdlIHdhbnQgdG8gZ28gaW50byBkZXRhaWxzLCBp biBvcmRlciB0byBoYXZlIG1lYW5pbmdmdWwgY29tcGFyaXNvbi4gU28gZmFyIHRoaXMgaXMgbm90 IGNsZWFyIHRvIG1lIGFzIHlvdSBzb21ldGltZXMNCiBhcmd1ZSB0aGF0IGRhdGEgc3RydWN0dXJl IGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRvIGdvIGlu dG8gdGhpcyAod2hpY2ggSSBhZ3JlZSkgYW5kIHNvbWV0aW1lIHlvdSBkZXRhaWwgdGhlIGRhdGEg c3RydWN0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlcmUgaXMgYWxzbyB0aGUgb3B0aW9uIHRvIGNvbnNp ZGVyIHRoaXMgYXMg4oCcaW1wbGVtZW50YXRpb24gaXNzdWXigJ0gYW5kIGxldCB0aGlzIHRvIGlt cGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q29taW5nIGJh Y2sgdG8gbXkgcGVyIEZFQyBhbGdvLCBhbGwgd2hhdCBpcyByZXF1aXJlZCBmcm9tIHRoZSBkYXRh IHN0cnVjdHVyZSwgaXMgYSB3YXkvQVBJIHRvIGdldCB0aGUgZGF0YSBiYWNrLCB0aG91Z2ggMiBr ZXlzOiBnZXQgbWUgdGhlIFNJRCBtYXRjaGluZyBwcmVmaXggUDEgKGZvciB0aGUgZmlyc3QgbGlu ZSksIGdldCBtZSB0aGUgcHJlZml4ZXMgbWF0Y2hpbmcNCiB0aGUgU0lEIFNJRGkgZm9yIHRoZSBz ZWNvbmQgbGluZS4gVGhhdCBzZWVtIGxpa2UgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50IG9uIHRo ZSBkYXRhIHN0cnVjdHVyZSwgYW5kIGFueSBvcHRpb24gaW4geW91ciBkcmFmdCBhbHNvIHJlcXVp cmVzIHRoaXMgdG8gZGV0ZWN0IHByZWZpeCBjb25mbGljdCBhbmQgU0lEIGNvbmZsaWN0IChzaW5j ZSB0aGlzIGlzIGFsbCBteSBwZXIgRkVDIGFsZ28gaXMgZG9pbmcgaW4gdGhlc2UgMiBmaXJzdCBs aW5lcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdvaW5nIGludG8gbW9yZSBk ZXRhaWxzLCBteSBwZXIgRkVDIGFsZ28gb25seSByZXF1aXJlcyB0byBkZXRhaWwgdGhhdCBvbmUg cHJlZml4IG9yIFNJRCBiZWxvbmcgdG8gYSByYW5nZSAob2YgcHJlZml4IG9yIFNJRCkgd2hpbGUg eW91ciBwZXIgcmFuZ2UgYWxnbyByZXF1aXJlcyB0byBjb21wdXRlIHJhbmdlIGludGVyc2VjdGlv biB3aGljaCBpcyBoYXJkZXIuIFNvDQogdGhlIEFQSSB0byBmZXRjaCB0aGUgZGF0YSBjYW4gb25s eSBiZSBlYXNpZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0xlczpdIFJhbmdlIGludGVyc2VjdGlvbiBp cyBlYXN5IHRvIGNvbXB1dGUg4oCTIHRoZSBhbGdvcml0aG0gaXMgcHJlc2VudCBpbiB0aGUgZHJh ZnQgYXQgdGhlIGVuZCBvZiAmbmJzcDtTZWN0aW9uIDMuMS4xLjwvc3Bhbj48L2k+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub10gSW4gb3JkZXIgdG8g aGF2ZSBhIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbiwgd2UgbmVlZCB0byBkZWZpbmUgdGhlIGxldmVs IG9mIGRldGFpbHMgdGhhdCB3ZSB3YW50IHRvIHRha2UgaW50byBhY2NvdW50LCBiZWNhdXNlIHlv deKAmXJlIG5vdCB1c2luZyB0aGUgc2FtZSBvbmUgdG8gZGlzY3VzcyB5b3VyIGFsZ28gYW5kIG1p bmUuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+MSkg QXMgYSBmaXJzdCBsZXZlbCBvZiBjb21wYXJpc29uLCB1c2luZyB0aGUgZGVzY3JpcHRpb24gYXQg dGhlIGVuZCBvZiBzZWN0aW9uIDMuMS4xIGFzIGEgbW9kZWwsIGZvciByYW5nZSBwcmVmaXggY29u ZmxpY3QgeW91ciBhbGdvIGlzOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgMSkoVDEgPT0gVDIpICZhbXA7JmFtcDsgKEExID09IEEyKTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgMilQMSAm bHQ7PSBQMjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgMylUaGUgcHJlZml4ZXMgYXJlIGluIHRoZSBzYW1lIGFkZHJlc3MgZmFtaWx5Ljwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgMilMMSA9 PSBMMjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgMykoUDFlICZndDs9IFAyKSAmYW1wOyZhbXA7ICgoUzEgJiM0MzsgKFAyIC0gUDEpKSAhPSBT Mik8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPlNvIGZvciAo RkVDKSBwcmVmaXggY29uZmxpY3QgbXkgYWxnbyBpczo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDEpKFQxID09IFQyKSAmYW1wOyZhbXA7IChB MSA9PSBBMik8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IDIpUDEgPSBQMjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgMylUaGUgcHJlZml4ZXMgYXJlIGluIHRoZSBzYW1lIGFkZHJlc3MgZmFt aWx5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgMilMMSA9PSBMMjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2 NEEyIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRB MiI+KEJUVywgaW4gdGhlIGRyYWZ0LCB0aGVyZSBpcyBhIHR5cG8gaW4gdGhlIG51bWJlcmluZyk8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+SXQgbG9va3Mg Y2xlYXIgdGhhdCBGRUMgY29tcGFyaXNvbiBpcyBlYXNpZXIgdGhhbiBwcmVmaXggcmFuZ2UgaW50 ZXJzZWN0aW9uLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0 QTIiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEy Ij4yKSBHb2luZyBkZWVwZXIsIGF0IHRoZSBhbGdvIGNvbXBsZXhpdHk8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPlRoZSBGRUMgYWxnbyBuZWVkczogZ2V0X1NJ RHMoUHJlZml4KSwgYW5kIGFsbCB0aGUgd29yayBpcyBkb25lLiBTbyBhbGwgdGhlIGFsZ28gY29t cGxleGl0eSBpcyBjb21pbmcgZnJvbSB0aGUgZGF0YXN0cnVjdHVyZS4gSXQgc2VlbXMgcHJldHR5 IHJlYXNvbmFibGUgdG8gZmluZCBhIGRhdGFzdHJ1Y3R1cmUgJmx0OyZsdDsgbyhuKSAoZS5nLiBh IHRyZWUsIGJ1dCB5b3Ugd2lsbA0KIGJlIG11Y2ggYmV0dGVyIHRoYW4gbWUgaW4gZmluZGluZyBv bmUpPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPkZvciB0 aGUgcmFuZ2UgYWxnbywgaXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGEgZGF0YSBzdHJ1Y3R1 cmUgY2FuIGJlIGZvdW5kIHRvIGF1dG9tYXRpY2FsbHkgZmluZCB0aGUgcmVzdWx0LiBJZiBub3Qs IHRoZSBhbGdvIHNlZW1zIHRvIGNvbXBhcmUgYWxsIGVudHJpZXMgdHdvIGJ5IHR3bywgd2hpY2gg d291bGQgZ2V0IG8obioobi0xKeKApigyKSkgaS5lLiBvKG4hKTwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgd2hhdCBuZWVkcyB0byBiZSBkb25lIHRvIGlt cGxlbWVudDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IOKAnEZpbmQgYWxsIFNJRGkgYWR2ZXJ0aXNlZCBmb3IgdGhlIHByZWZpeCBQMeKA nTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gaXRzIHNp bXBsZXN0IGZvcm0sIHdlIGhhdmUgYSBsaXN0IG9mIGFsbCBTSUQgYWR2ZXJ0aXNlbWVudHMgKFBG WCBhbmQgU1JNUykgdGhhdCB3ZSBoYXZlIHJlY2VpdmVkLiBPbmUgY291bGQgaW1hZ2luZSB3YWxr aW5nIGFsbCB0aGUgZW50cmllcywgbG9va2luZyB0byBzZWUgaWYgdGhlIHByZWZpeCBvZiBpbnRl cmVzdCBpcyBwcmVzZW50IHdpdGhpbiB0aGUgYWR2ZXJ0aXNlZA0KIHJhbmdlLiBCdXQsIG9mIGNv dXJzZSwgYXQgbGFyZ2Ugc2NhbGUgc3VjaCBhbiBhcHByb2FjaCBpcyBleHRyZW1lbHkgaW5lZmZp Y2llbnQg4oCTIHNvIHdlIGltbWVkaWF0ZWx5IHN0YXJ0IGNvbnNpZGVyaW5nIHdheXMgdG8gaW1w cm92ZSBwZXJmb3JtYW5jZS4gSW5zZXJ0aW5nIHJlY2VpdmVkIGVudHJpZXMgaW50byBhbiBvcmRl cmVkIHRyZWUgb2Ygc29tZSBraW5kIGlzIGFuIG9idmlvdXMgd2F5IHRvIGltcHJvdmUgcGVyZm9y bWFuY2UuIFdoZW4gb25lDQogZnVydGhlciBjb25zaWRlcnMgdGhhdCBjYWxjdWxhdGluZyBjb25m bGljdCByZXNvbHV0aW9uIG9ubHkgbmVlZHMgdG8gYmUgZG9uZSB3aGVuIGEgY2hhbmdlIHRvIHRo ZSByZWNlaXZlZCBkYXRhYmFzZSBvY2N1cnMgKHdoaWNoIHBvc3Qgc3RhcnR1cCBpcyBpbmZyZXF1 ZW50KSBpdCBiZWNvbWVzIHZlcnkgYXR0cmFjdGl2ZSB0byBjYWNoZSB0aGUg4oCcd2lubmluZyBl bnRyaWVz4oCdIHNvIHRoYXQgaWYgb25lIHdhbnRzIHRvIHJldHJpZXZlIHRoZSBTSUQNCiBmb3Ig YSBnaXZlbiBwcmVmaXggd2Ugb25seSBoYXZlIHRvIGV4YW1pbmUgYSBzdWJzZXQgb2YgdGhlIHRv dGFsIGRhdGFiYXNlIOKAkyBpZ25vcmluZyB0aGUgbG9zZXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0JydW5vXSBJIGFncmVlIHRoYXQgdGhlIHBlciBy YW5nZSBhbGdvIChpZ25vcmUgb3ZlcmxhcCBvbmx5KSB3aWxsIGJlIGFibGUgdG8gaWdub3JlIHRo ZSBsb3NlcnMgYnV0IGF0IHRoZSBjb3N0IG9mIGEgbW9yZSBjb21wbGV4IGFsZ28gYW5kIGF0IHRo ZSBjb3N0IG9mIGNyZWF0aW5nIG5ldyBkZXJpdmVkIGVudHJpZXMuIEl04oCZcyBub3QgY2xlYXIg dG8gbWUgaWYgdGhlDQogbmV0IHJlc3VsdCBpcyBwb3NpdGl2ZS4gUGx1cyBJIHdvdWxkIGV4cGVj dCB0aGF0IHRoZSBudW1iZXIgb2YgY29uZmxpdCBpcyBzbWFsbCBjb21wYXJlZCB0byB0aGUgbnVt YmVyIG9mIHByZWZpeCAvU0lEIHNvIHRoaXMgbG9va3MgbGlrZSBhIHNlY29uZCBvcmRlciBvcHRp bWl6YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JbiB0aGlzIGNvbnRleHQsIHdlIGNhbiBhcHByZWNpYXRl IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHRocmVlIHByb3Bvc2VkIGFsZ29yaXRobXMuIElu IHBhcnRpY3VsYXIgY29tcGFyaW5nIOKAnFF1YXJhbnRpbmXigJ0gd2l0aCDigJxpZ25vcmUgb3Zl cmxhcCBvbmx54oCdLCBhIGtleSBkaWZmZXJlbmNlIGlzIHRoYXQg4oCcUXVhcmFudGluZeKAnSBv bmx5IG5lZWRzIHRvIGRldGVybWluZQ0KIHdoZXRoZXIgYSByZWNlaXZlZCBlbnRyeSBpcyBhIHdp bm5pbmcgZW50cnkgb3IgYSBsb3NpbmcgZW50cnkuIOKAnElnbm9yZSBvdmVybGFwIG9ubHnigJ0g aGFzIHRvIGJlIGNhcGFibGUgb2YgYnJlYWtpbmcgcmVjZWl2ZWQgZW50cmllcyB3aXRoIHJhbmdl cyAmZ3Q7IDEgaW50byBtdWx0aXBsZSDigJxkZXJpdmVk4oCdIGVudHJpZXMgKHNvbWUgd2lubmlu Zywgc29tZSBsb3NpbmcpLCB3aGljaCBtZWFucyB3ZSBub3cgbmVlZCB0byB0cmFjayB0aGUg4oCc ZGVyaXZlZCBlbnRyaWVz4oCdDQogYWdhaW5zdCB0aGUgb3JpZ2luYWwgcmVjZWl2ZWQgZW50cnkg c28gdGhhdCBpZiB0aGUgcmVjZWl2ZWQgZW50cnkgaXMgdXBkYXRlZC9kZWxldGVkIHdlIGNhbiBm aW5kIGFsbCB0aGUgZGVyaXZlZCBlbnRyaWVzIGFuZCBkZWxldGUvcmVnZW5lcmF0ZSB0aGUgZGVy aXZlZCBlbnRyaWVzIGFzIG5lZWRlZC4gVGhpcyBpcyB3aGF0IGFkZHMgY29tcGxleGl0eS48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPltCcnVub10gYW5kIHRo YXQgaXQgd2h5IHRoZSBwZXIgRkVDIGFsZ28gc2VlbXMgZWFzaWVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U28g aXQgd291bGQgc2VlbSB1c2VmdWwgdG8gYWRkIGl0IGluIHRoZSBkcmFmdCBzbyB0aGF0IHdlIGNh biBhbGwgZGlzY3VzcyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMZXM6XSBJZ25vcmUgb3Zlcmxh cCBvbmx5IGlzIHRoZSBzYW1lIGFzIHBlciBGRUMuIFdlIG1heSB1c2UgZGlmZmVyZW50IHdvcmRz IHRvIGRlc2NyaWJlIGl0LCBidXQgdGhlIGVuZCBiZWhhdmlvciBpcyB0aGUgc2FtZS48L3NwYW4+ PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5bQnJ1bm9d IGdvb2QgaWYgdGhpcyBnZXQgdGhlIHNhbWUgcmVzdWx0LiBZZXQgdGhlIGFsZ28gaXMgZGlmZmVy ZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+LS0gQnJ1 bm88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBMZXM8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QWxsIHByb3Bvc2VkIGFsZ29yaXRobXMgY2FuIGJlIGlt cGxlbWVudGVkLCBidXQgaXQgZG9lcyBzZWVtIHBydWRlbnQgdG8gY29uc2lkZXIgaW1wbGVtZW50 YXRpb24gY29tcGxleGl0eSBhcyBwYXJ0IG9mIG91ciBkZWNpc2lvbiBwcm9jZXNzIOKAkyBhbmQg dGhlIGRpc2N1c3Npb24vZXhhbXBsZXMgaW4gU2VjdGlvbiAzIGFyZSBtZWFudCB0byBoZWxwIGlu IGRvaW5nDQogdGhpcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkl0IGlzIHdvcnRod2hpbGUgcmVzdGF0aW5nIHRoYXQgd2hlbiBjb25mbGljdHMgYXJlIHBy ZXNlbnQgd2UgY2Fubm90IGd1YXJhbnRlZSB0aGF0IGZvcndhcmRpbmcgd2lsbCB3b3JrIGNvcnJl Y3RseSBubyBtYXR0ZXIgd2hhdCBhbGdvcml0aG0gaXMgdXNlZC48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPltCcnVub10gSeKAmW0gbm90IHN1cmUgdG8gc2Vl IHdoYXQgeW91IGhhdmUgaW4gbWluZCBleGFjdGx5LiBDYW4geW91IGVsYWJvcmF0ZT8gVG8gbWUg Y29uc2lzdGVuY3kgc2VlbSBlbm91Z2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwO1RoZSBtb3JlIGNv bXBsZXggdGhlIGltcGxlbWVudGF0aW9uIHRoZSBtb3JlIGxpa2VseSBpdCBpcyB0aGF0IGJ1Z3Mg d2lsbCBiZSBwcmVzZW50IGFuZCB0aGUgbW9yZSBsaWtlbHkgaXQgaXMgdGhhdCBpbnRlcm9wZXJh YmlsaXR5IGlzc3VlcyB3aWxsIGFyaXNlLiBXaGV0aGVyIHRoZXNlIGNvc3RzL3Jpc2tzIGFyZSB3 b3J0aCB0aGUg4oCcdmFsdWUgYWRk4oCdIHdoZW4NCiB0aGUgb3V0Y29tZSBjYW5ub3QgYmUgZ3Vh cmFudGVlZCB0byBiZSBjb3JyZWN0IOKAkyBvbmx5IGd1YXJhbnRlZWQgdG8gYmUgY29uc2lzdGVu dCDigJMgaXMgYW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BbHNvIGltcG9ydGFudCB0byByZW1lbWJlciB0aGF0 IGNvbmZsaWN0cyBNVVNUIGJlIGVsaW1pbmF0ZWQgYnkgY29ycmVjdGluZyB0aGUgbWlzY29uZmln dXJhdGlvbnMgdGhhdCBjYXVzZWQgdGhlbSDigJMgc28gY29uZmxpY3QgcmVzb2x1dGlvbiBpcyBy ZWFsbHkgb25seSBhbiBpbnRlcmltIG1lYXN1cmUgdW50aWwgdGhlIGNvcnJlY3Rpb25zIGNhbiBi ZSBtYWRlLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0Jy dW5vXSBCeSDigJxpbnRlcmlt4oCdIHdlIGFyZSBhdCBtaW5pbXVtIHRhbGtpbmcgYWJvdXQgMTBz IG9mIG1pbnV0ZXMsIGlmIG5vdCBtb3JlIHRoYW4gMSBob3VyIHNpbmNlIGlkZW50aWZ5aW5nIHRo ZSByb290IGNhdXNlIG1heSBub3QgYmUgb2J2aW91cy4gVGhlIGltcGFjdCBpcyB2ZXJ5IHNpZ25p ZmljYW50IG9uIHRoZSBuZXR3b3JrLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg4oCcUXVhcmFudGluZeKA nSBhbGdvIGhhcyB0aGUgcG90ZW50aWFsIHRvIGtpbGwgMTAwcyBQRSBhbmQgMTAwMHMgb2YgVlBO IGN1c3RvbWVycywgc28gYSBzaW5nbGUgY29uZmlndXJhdGlvbiBjaGFuZ2Ugb24gYSB1bnJlbGF0 ZWQgcm91dGVyIHdoaWNoIG1heSBub3QgZXZlbiBiZSBpbiBwcm9kdWN0aW9uIChpLmUuIHdoZXJl IGNvbmZpZ3VyYXRpb24gY2hlY2tzIGFuZA0KIG9wZXJhdGlvbnMgaG91cnMgbWF5IGJlIHJlbGF4 ZWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Tm8gb25lIHNob3VsZCBiZSBsdWxsZWQgaW50byB0aGlua2luZyB0aGF0 IGJlY2F1c2Ugd2UgaGF2ZSBjb25mbGljdCByZXNvbHV0aW9uIGRlcGxveWVkIHRoYXQgY29ycmVj dGluZyB0aGUgY29uZmlndXJhdGlvbiB3aGVuIGNvbmZsaWN0cyBhcmUgZGV0ZWN0ZWQgaXMgbm90 IGEgcHJpb3JpdHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5bQnJ1bm9dIEkgY291bGQgbm90IGFncmVlIG1vcmUgdGhhdCBjb25mbGljdCBuZWVkcyB0byBi ZSBpZGVudGlmaWVkIGFuZCBmaXhlZC4gTm90ZSB0aGF0IEnigJltIHRoZSBvbmUgaGF2aW5nIGFz a2VkIGZvciBkZWZpbmluZyBZQU5HIG5vdGlmaWNhdGlvbnMgdG8gcmVwb3J0IHRoaXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5Zb3UgYXJlIHdlbGNvbWVkIHRvIHN0YXRlIGluIHRoZSBkcmFmdCB0aGF0IGNvbmZs aWN0cyBuZWVkcyB0byBiZSByZXBvcnRlZCB0byB0aGUgbmV0d29yayBvcGVyYXRvciwgaW4gcGFy dGljdWxhciB0aG91Z2ggeWFuZyBub3RpZmljYXRpb24sIGFuZCBvdGhlciBleGlzdGluZyBtZWFu cy4gUGx1cyB0aGF0IG5ldHdvcmsgb3BlcmF0b3IgbmVlZHMgdG8gZml4ZWQgdGhlbQ0KIEFTQVAg KGJ1dCBzdGlsbCBjYXJlZnVsbHkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo YW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+LS1CcnVubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxh IGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bPC9z cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPm1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAzMCwgMjAxNiA1OjEwIEFNPGJyPg0KPGI+VG86PC9iPiBM ZXMgR2luc2JlcmcgKGdpbnNiZXJnKTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmci PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c3ByaW5nQGlldGYub3Jn PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVz b2x1dGlvbiAtIFBvbGljeTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5MZXMsPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5UaGFua3MgZm9yIHRoZSBkaXNj dXNzaW9uLiBQbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKSBbPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9 Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDY6MDAgUE08YnI+DQo8Yj5Ubzo8L2I+IERFQ1JB RU5FIEJydW5vIElNVC9PTE48YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNwcmluZ0BpZXRmLm9yZzwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b24gLSBQb2xpY3k8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnJ1bm8g4oCTPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BcyB0aGUgdGhyZWFkIGJlbG93 IGRvY3VtZW50cywgSSBzdGF0ZWQgdGhhdCBJIGRpZCBub3QgdW5kZXJzdGFuZCB5b3VyIHJlcHJl c2VudGF0aW9uIGFuZCBhc2tlZCBmb3IgY2xhcmlmaWNhdGlvbiDigJMgc3VnZ2VzdGluZyB0aGF0 IHlvdSB1c2UgdGhlIGZvcm1hdCBkZWZpbmVkIGluIHRoZSBkcmFmdC4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Zb3Ugc3RhdGVkIHRoYXQgeW91IGNv dWxkIG5vdCBkbyB0aGF0IGFuZCB3ZSB3ZXJlIGF0IGEgcG9pbnQgd2hlcmUgbm8gcHJvZ3Jlc3Mg Y291bGQgYmUgbWFkZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izgw NjRBMiI+W0JydW5vXSBJIGNvdWxkIF88aT5ub3Q8L2k+XyB1c2UgeW91ciBmb3JtYXQgc2luY2Ug eW91ciBmb3JtYXQgZGlkIG5vdCBpbmNsdWRlIHRoZSBpbmZvcm1hdGlvbiBuZWVkLiBUaGlzIGlz IG5vdCBhIHdoaW0gYnV0IGEgdGVjaG5pY2FsIGlzc3VlLiBTbyBJIGFza2VkIHlvdSB0byBzdGls bCBjb25zaWRlciB0aGUgbWVzc2FnZS4gUmF0aGVyIHRoYW4gd2FpdGluZw0KIGZvciBhIHRpbWUt b3V0LCB0aGVyZSB3YXMgYSB3YXkgdG8gbWFrZSBwcm9ncmVzcyBieSBhc2tpbmcgY2xhcmlmaWNh dGlvbiBxdWVzdGlvbnMgb24gdGhlIHBvaW50cyB3aGljaCB3ZXJlIG5vdCBjbGVhciwgb3IgYXQg bGVhc3QgZXhwbGljaXRseSByZWZ1c2luZyB0byBjb25zaWRlciB0aGUgZW1haWwuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6IzgwNjRBMiI+SSBhbHNvIG5vdGUgdGhhdCB3aGF0IGJvdGhlcmVkIHlv dSBpbiBteSByZXByZXNlbnRhdGlvbiB3YXMgbXkgYWRkaXRpb24gb2YgdGhlIHR5cGUgb2YgYWR2 ZXJ0aXNlbWVudCAocHJlZml4IG9yIE1TKS4gQnV0IHlvdSBmaW5hbGx5IGhhdmUganVzdCBhZGRl ZCBpbiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IOKAnDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+U3JjLSBQRlggb3IgU1JNU+KAnTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IzgwNjRBMiI+IC4gU28gdGhlcmUgd2FzIHByb2JhYmx5IGEgd2F5IHRvIGNvbW11bmljYXRlLjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+QmVzaWRlcyB0aGUg YWxnbyBkaWQgbm90IHVzZSBhbnkgc3BlY2lmaWNhdGlvbiByZXByZXNlbnRhdGlvbiwganVzdCBu YW1lcy4gU28gSeKAmWxsIGNvcHkvcGFzdGUgaXQgYmVsb3csIHBsZWFzZSBhc2sgY2xhcmlmaWNh dGlvbiBxdWVzdGlvbnMgZm9yIHRoZSBwYXJ0cyB3aGljaCBhcmUgbm90IGNsZWFyIGVub3VnaC48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPlRoZSBwcm9ibGVt IHRoYXQgd2UgbmVlZCB0byBzb2x2ZSwgaXMgdG8gZmluZCB0aGUgU0lEIGZvciBhIHByZWZpeCAo UDEpLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5UaGUg YWxnbyBjb3VsZCBiZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izgw NjRBMiI+LSBGaW5kIGFsbCBTSURpIGFkdmVydGlzZWQgZm9yIHRoZSBwcmVmaXggUDEmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Ly8gaWRlbnRpZmljYXRpb24gb2YgUHJlZml4IGNvbmZsaWN0czwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLSBGb3IgZWFjaCBTSURpIGZpbmQgYWxsIHRoZSBwcmVmaXggUGlqIGFzc29jaWF0ZWQg d2l0aCBTSURpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIGlkZW50aWZpY2F0aW9uIG9mIFNJRCBj b25mbGljdHM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPi8v IGFzIGEgcmVzdWx0LCBmb3IgUDEsIHdlIGdldCBhIGxpc3Qgb2YgKFNJRGksIFBpaik8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPkdldCB0aGUgYmVzdCAoU0lE aSwgUGlqKSBhcyBwZXIgdGhlIHByZWZlcmVuY2UgYWxnb3JpdGhtLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5JZiBiZXN0IFBpaiA9PSBQMTwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhlbiB1c2UgU0lEaWogZm9yIFAxPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBlbHNlIHJldHVybiBubyBTSUQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLyBubyBTSUQgYXZhaWxhYmxlIGZvciB0aGlzIHByZWZpeCBQMTwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UbyBpbGx1c3RyYXRlIG15IGNvbmZ1c2lvbiwg b25lIG9mIHlvdXIgZXhhbXBsZXMgaXM6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5Gb3IgUjIsIHRoZSBhbGdvIGV2 YWx1YXRlcyBhIGNvbmZsaWN0IGJldHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOjwv c3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IFIyIC0gU0lEMiAtIFIyIChNUywgTVMpPC9z cGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBz dHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgUjIgLSBTSUQxMiAtIFIxMiAocHJlZml4IFNJ RCwgTVMpDQo8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwO1IyIC0gU0lEMTIg LSBSMiZuYnNwOyAocHJlZml4IFNJRCwgcHJlZml4IFNJRCk8L3NwYW4+PC9pPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZu YnNwOyZuYnNwOyA8L3NwYW4+DQo8L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPk5vdywgd2hhdCBkb2VzIOKAnFIyIC0gU0lEMiAtIFIyIChNUywgTVMp4oCdIG1lYW4/ PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPltCcnVub108 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+LSBNUy9wcmVm aXggU0lEIGlzIHRoZSB0eXBlIG9mIGFkdmVydGlzZW1lbnQuIEluIHlvdXIgbmV3IHZlcnNpb24s IHlvdSBjYWxsIGl0IFNSTVMvUEZYLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojODA2NEEyIj4tIFNJRCBpcyB0aGUgU0lEIGZvdW5kIGluIHRoZSBNYXBwaW5nIEVudHJp ZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4tIFJ4IGlz IHRoZSBsb29wYmFjayAocHJlZml4KSBvciByb3V0ZXIgUng8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPlNvIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 I0MwNTA0RCI+UjI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPiAtIFNJRDIgLQ0K PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5SMiA8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM4MDY0QTIiPig8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDUwNEQiPk1TPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4sDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMEIwNTAiPk1TPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4p4oCdIGlz IHRoZSBvdXRwb3V0IG9mIHRoZSBhbGdvIGRlc2NyaWJlZCBhYm92ZSBhbmQgbWVhbnM6IEZvciBw cmVmaXgNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6I0MwNTA0RCI+UjI8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM4MDY0QTIiPiwgd2UgZm91bmQgYQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojQzA1MDREIj5NUyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPm1hcHBp bmcgZW50cmllcyBhZHZlcnRpc2luZyBTSUQyIGZvciB0aGlzIHByZWZpeCwgYW5kIHRoZW4gSSBm b3VuZCBhDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1TIDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6IzgwNjRBMiI+bWFwcGluZyBlbnRyaWVzIGFkdmVydGlzaW5nIHByZWZp eA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5SMiA8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4MDY0QTIiPmZvciBTSUQyLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+RG9lcyBpdCBtZWFuJm5ic3A7IOKAnE9uIFIyLCBTSUQyIGlzIGFz c2lnbmVkIHRvIHByZWZpeCBSMiBmcm9tIHR3byBkaWZmZXJlbnQgbWFwcGluZyBzZXJ2ZXIgZW50 cmllcz/igJ0gSSByZWFsbHkgaGF2ZSBubyBpZGVhLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+QW5kIHlvdSBjb25jbHVkZSB0aGUgZXhhbXBsZSBieSBzYXlp bmcNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+QmVzdCBvbmUgaXMgUjIgLSBTSUQxMiAtIFIyIChzbWFsbGVyIHJh bmdlIChwcmVmaXggU0lEKSxzbWFsbGVyIHJhbmdlIChwcmVmaXggU0lEKSk8L3NwYW4+PC9pPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPiZuYnNwOyZuYnNwOyA9PSZndDsgU0lEMTIgaXMgc2VsZWN0ZWQgZm9yIFIyLjwvc3Bh bj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCBzaW5jZSB0 aGVyZSBpcyBubyByZXByZXNlbnRhdGlvbiBvZiDigJxyYW5nZeKAnSBpbiB5b3VyIGV4YW1wbGVz IEkgcmVhbGx5IGhhdmUgbm8gaWRlYSBob3cgeW91IGNhbWUgdG8gdGhpcyBjb25jbHVzaW9uIC48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+W0JydW5vXSBJ IGFncmVlIHRoYXQgc2luY2UgdGhlIGFib3ZlIGFsZ28gdXNlZCAyIG1hcHBpbmcgZW50cmllcyB0 byBwcm92aWRlcyB0aGUgKFNJRGksIFBpaiksIHRoZSBwcmVmZXJlbmNlIGFsZ28gKMKnMy4yLjQp IHdvdWxkIG5lZWQgdG8gYmUgYWRhcHRlZC4gVGhhdCBiZWluZyBzYWlkLCB0aGlzIGlzIG5vdCBp bXBvcnRhbnQgZm9yIHRoaXMgZGlzY3Vzc2lvbi4NCiBMZXTigJlzIGp1c3QgY29uc2lkZXJlZCB0 aGF0IHRoZWlyIGV4aXN0IGEgcHJlZmVyZW5jZSBhbGdvcml0aG0sIHdoaWNoIHRha2VzIGFzIGlu cHV0IGEgbGlzdCBvZiAoU0lEaSwgUGlpaikgZm9yIFAxLCBhbmQgZ2l2ZXMgYXMgb3V0cG91dCB0 aGUg4oCcYmVzdOKAnSBvbmUuIChkZWZpbml0aW9uIG9mIOKAnGJlc3TigJ0gaXMgbm90IHBlcnRp bmVudCk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4/Pzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgcmVnYXJkcyDigJxw ZXIgRkVDL1ByZWZpeOKAnSwgSSBiZWxpZXZlIHRoaXMgaXMgd2hhdCDigJxpZ25vcmUgb3Zlcmxh cCBvbmx54oCdIGRvZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 MDY0QTIiPltCcnVub10gSW5kZWVkLCB0aGlzIGlzIG15IGV4cGVjdGF0aW9uLiBCdXQgSSB3b3Vs ZCBuZWVkIHNvbWVvbmXigJlzIHJldmlldyB0byBjb25maXJtIHRoaXMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDY0QTIiPkJ1dCB0aGUgZGlmZmVyZW5jZSBpcyB0 aGF0IHRoZSBwcm9wb3NlZCBhbGdvIGlzIHNpbXBsZSAoMiBsaW5lcyBvZiBwc2V1ZG8gY29kZSks IHdpdGggdmVyeSBtb2Rlc3QgcmVzcXVpcmVtZW50IGRhdGEgc3RydWN0dXJlIHVzZSB0byBzdG9y ZSB0aGUgbWFwcGluZyBlbnRyaWVzLiBJbmRlZWQsIGFsbCBpdCBuZWVkcyBpcyBhIGZ1bmN0aW9u IHJldHVybmluZyB0aGUNCiBsaXN0IG9mIG1hcHBpbmcgZW50cmllcyBhc3NvY2lhdGVkL21hdGNo aW5nIGEgZ2l2ZW4gcHJlZml4LiBBbmQgZnVuY3Rpb24gcmV0dXJuaW5nIHRoZSBsaXN0IG9mIG1h cHBpbmcgZW50cmllcyBhc3NvY2lhdGVkL21hdGNoaW5nIGEgZ2l2ZW4gU0lELjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj5JbiBwYXJ0aWN1bGFyLCB0aGVy ZSBpcyBubyBuZWVkIGZvciBzcGxpdHRpbmcgbWFwcGluZyBlbnRyaWVzIHdoaWNoIGlzIHRoZSBt YWluIGNvbXBsZXhpdHkgb2YgeW91ciBwcm9wb3NlZCDigJxQcmVmZXJlbmNlIGFsZ29yaXRobS9p Z25vcmUgb3ZlcmxhcCBvbmx54oCdLiAoYWNjb3JkaW5nIHRvIHlvdXIgb3duIHRleHQpLjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODA2NEEyIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzgwNjRBMiI+LS0gQnJ1bm88L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsg TGVzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFj ayI+PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwv c3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pls8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFp bHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVuZSAyOSwgMjAxNiA3OjIyIEFNPGJyPg0KPGI+VG86 PC9iPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c3ByaW5nQGll dGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxp Y3QtcmVzb2x1dGlvbiAtIFBvbGljeTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MZXMsPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRo ZSB1cGRhdGVkIGRyYWZ0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SUlOTSwgeW91IGhhdmUgbm90IGFuc3dlcmVkIG15IGJlbG93IGVtYWlsL3Byb3Bvc2Fs LiBJIGhhZCB3YWl0ZWQgZm9yIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgYnV0IGl0IGFs c28gZG9lcyBub3QgdG91Y2ggdGhpcyBzdWJqZWN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+U28sIGNvdWxkIHlvdSBwbGVhc2UgY29uc2lkZXIgYW5kIGFu c3dlciBteSBjb21tZW50Pzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SW4gc2hvcnQsIGluIGFuIGltcGxlbWVudGF0aW9uLWluZGVwZW5kZW50IHNlbnRlbmNl Ojwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsgSSdtIHdv bmRlcmluZyBpZiB3ZSBjb3VsZCBhZGRyZXNzIHRoZSBjb25mbGljdCBvbiBhIHBlciBGRUMvUHJl Zml4IGJhc2lzIHJhdGhlciB0aGFuIG9uIGEgcGVyIElHUCBhZHZlcnRpc2VtZW50IChyYW5nZSkg YmFzaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IElmIHNvLCB0aGlzIG1heSBhdm9pZCB0aGUgZGlzY3Vz c2lvbiBiZXR3ZWVuIHRoZSBRdWFyYW50aW5lIHZzIGlnbm9yZSBwb2xpY3kuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhhbmtzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJy dW5vPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiBzcHJpbmcgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29s b3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDE4LCAyMDE2IDE6NTcgUE08 YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOyA8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zcHJpbmdAaWV0Zi5v cmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1j b25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5MZXMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lIFtCcnVu b108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZykg Wzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWls dG86Z2luc2JlcmdAY2lzY28uY29tIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPm1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1 bmRheSwgTWF5IDE1LCAyMDE2IDEyOjQxIEFNPGJyPg0KPGI+VG86PC9iPiBERUNSQUVORSBCcnVu byBJTVQvT0xOOyA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+PGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5zcHJpbmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBk cmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gUG9saWN5PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkJydW5vIOKAkzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SSBhbSBoYXZpbmcgZGlmZmljdWx0eSBwYXJzaW5nIHRoZSBleGFtcGxl cyB5b3UgcHJvdmlkZSBiZWxvdyBhcyB0aGV5IHNlZW0gdG8gaW5jb3Jwb3JhdGUgYWR2ZXJ0aXNl bWVudCBzb3VyY2UgaW50byB0aGUgZGVzY3JpcHRpb24gd2hlcmVhcyB0aGUgZHJhZnQgZGVsaWJl cmF0ZWx5IG9taXRzIHNvdXJjZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPltCcnVub10gTXkgdGV4dCBkb2VzIG5vdCBpbmNvcnBvcmF0ZSB0aGUgc291cmNl LCBidXQgdGhlIHR5cGUgb2Ygc291cmNlIElPVyB0aGUgdHlwZSBvZiBzdWItVExWLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+U28gaXQgZG9lcyBub3QgbWF0dGVyIGlmIFIyIHNlbmRzIGFuIGFkdmVydGlzZW1lbnQg b3IgUjEyIHNlbmRzIGFkdmVydGlzZW1lbnQgb3IgYm90aCBvZiB0aGVtIGRvICh3aGljaCBjb3Vs ZCBoYXBwZW4gd2hlbiBhbiBhZHZlcnRpc2VtZW50IGlzIGxlYWtlZCkg4oCTIHdoYXQgbWF0dGVy cyBpcyB3aGF0IHVuaXF1ZSBlbnRyaWVzIGFyZSBpbiB0aGUgZGF0YWJhc2UNCiBpbmRlcGVuZGVu dCBvZiBzb3VyY2UuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5bQnJ1bm9dIEl0IG1heSBub3QgbWF0dGVyIGZvciB5b3VyIGFsZ29yaXRobSAocGVuZGluZyBh bm90aGVyIHRocmVhZCksIGJ1dCBpdCBkb2VzIGZvciB0aGUgb25lIEkgcHJvcG9zZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5JdCB3b3VsZCBiZSBnb29kIGlmIHlvdSBjb3VsZCBwcmVzZW50IHlvdXIgZXhhbXBs ZXMgdXNpbmcgdGhlIGZvcm1hdCBkZWZpbmVkIGluIHRoZSBkcmFmdCBpLmUuOjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0JydW5vXSBNeSBleGFtcGxlcyBh cmUgZGVzY3JpYmVkIGluIHBsYWluIHRleHQuIFRoZW4gdGhlIGV4YW1wbGVzIGdpdmluZyBpbnRl cm1lZGlhdGUgc3RlcHMgb2YgbXkgYWxnbyB1c2VzIHRoZSBkYXRhIHRoYXQgYXJlIG5lZWRlZCBp LmUuIHRoZSB0eXBlIG9mIGFkdmVydGlzZW1lbnQgKFByZWZpeC1TSUQgdnMgTVMpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhlbiBmaW5hbGx5LCBteSBhbGdvIHJ1bnMgb24gYSBwZXIgRkVDL0lQIFByZWZpeCBi YXNpcywgYW5kIG5vdCBvbiBhIHBlciBJR1AgYWR2ZXJ0aXNlbWVudCBiYXNpcyB3aGljaCB5b3Vy IGZvcm1hdCBkZXNjcmliZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNvIEnigJltIHNvcnJ5IGJ1dCBJIGRvbuKA mXQgc2VlIGhvdyB0byBpbmR1bGdlIHlvdXIgcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgUGkgLSBJbml0aWFsIHByZWZp eDwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQZSAtIEVu ZCBwcmVmaXg8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TCAtJm5ic3A7IFByZWZpeCBsZW5ndGg8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTHggLSBNYXhpbXVtIHByZWZpeCBsZW5ndGggKDMyIGZvciBJUHY0LCAx MjggZm9yIElQdjYpPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNpIC0gSW5pdGlhbCBTSUQgdmFsdWU8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU2UgLSBFbmQgU0lEIHZhbHVlPC9zcGFuPjwvaT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFIgLSZuYnNwOyBSYW5nZSB2YWx1ZTwvc3Bhbj48 L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUIC0gVG9wb2xvZ3k8L3Nw YW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSAtIEFsZ29yaXRo bTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIE1hcHBpbmcgRW50cnkgaXMgdGhlbiB0aGUgdHVwbGU6 IChQaS9MLCBTaSwgUiwgVCwgQSk8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5QZSA9IChQaSAmIzQzOyAoKFItMSkgJmx0OyZsdDsgKEx4LUwpKTwvc3Bhbj48L2k+ PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNlID0gU2kgJiM0MzsgKFItMSk8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5F eGFtcGxlOiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsoMTkyLjAuMi4xMjAvMzIsIDIwMCwgMSwg MCwgMCk8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5B cyByZWdhcmRzIHlvdXIgcHJvcG9zYWwgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tIEZpbmQgYWxsIFNJ RGkgYWR2ZXJ0aXNlZCBmb3IgdGhlIHByZWZpeCBQMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBpZGVudGlmaWNhdGlvbiBv ZiBQcmVmaXggY29uZmxpY3RzPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gRm9yIGVhY2ggU0lEaSBmaW5kIGFsbCB0aGUgcHJlZml4IFBp aiBhc3NvY2lhdGVkIHdpdGggU0lEaSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvLyBpZGVudGlmaWNh dGlvbiBvZiBTSUQgY29uZmxpY3RzPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+R2V0IHRoZSBiZXN0IGFzIHBlciB0aGUgcHJlZmVyZW5jZSBhbGdv cml0aG0uPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgYmVzdCBQaWogPT0gUDE8L3NwYW4+PC9p PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiB1c2Ug U0lEaWogZm9yIFAxPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGVsc2UgcmV0dXJuIG5vIFNJRDwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj50aGlzIHRvIG1lIHNwZWNp ZmllcyBhbiBpbXBsZW1lbnRhdGlvbiDigJMgd2hpY2ggaXNu4oCZdCBuZWNlc3NhcnkuPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bQnJ1bm9dIFdlbGwsIF88 aT55b3U8L2k+XyBhcmUgdGhlIG9uZSB0YWxraW5nIGFib3V0IGltcGxlbWVudGF0aW9uLCBhbmQg bW9yZSBzcGVjaWZpY2FsbHkgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkFzc3VtaW5nIHRoZSBhYm92ZSBhbGdvIHdvcmtzLCBpdCBsb29rcyByZWxhdGl2ZWx5IHNpbXBs ZSB0byBpbXBsZW1lbnQsIGluIHdoaWNoIGNhc2UsIEkgd291bGQgbm90IGJ1eSB0aGUgYXJndW1l bnQgYWJvdXQgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSB3aGljaCBpcyB0aGUgb25seSBhcmd1 bWVudCBpbiBmYXZvciBvciB0aGUg4oCcaWdub3Jl4oCdIG9yIOKAnHF1YXJhbnRpbmXigJ0NCiBw b2xpY3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5Cb3R0b20gbGluZSwgSSB3b3VsZCB3ZWxjb21lIHlvdXIgZmVl ZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoaXMgcHJvcG9zZWQgYWxnby9wb2xpY3kuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4tLSBCcnVubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHRoZXJlIGlzIG9uZSBpbXBv cnRhbnQgcG9pbnQgd2hpY2ggaGFzIG5vdCBiZWVuIHNwZWNpZmllZCBpbiB0aGUgZHJhZnQgd2hp Y2ggcmVhZGluZyB5b3VyIHBvc3QgaGFzIGJyb3VnaHQgdG8gbXkgYXR0ZW50aW9uIOKAkyB0aGF0 IGlzIHRoZSBvcmRlciBpbiB3aGljaCBjaGVja3MgYXJlIG1hZGUuDQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGRyYWZ0IHN0YXRlczo8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPuKAnFByZWZpeCBjb25mbGlj dHMgYXJlIHNwZWNpZmljIHRvIG1hcHBpbmcgZW50cmllcyBzaGFyaW5nJm5ic3A7IHRoZSBzYW1l IHRvcG9sb2d5IGFuZCBhbGdvcml0aG0u4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPuKAnFNJRCBjb25mbGljdHMgYXJlIGluZGVwZW5kZW50IG9mIGFk ZHJlc3MtZmFtaWx5LCZuYnNwOyBpbmRlcGVuZGVudCBvZiBwcmVmaXggbGVuLCBpbmRlcGVuZGVu dCBvZiB0b3BvbG9neSwgYW5kIGluZGVwZW5kZW50Jm5ic3A7IG9mIGFsZ29yaXRobS7igJ08L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklmIHdlIGNvbnNpZGVy IGFuIGV4YW1wbGUgd2hlcmUgYSBuZXR3b3JrIHN1cHBvcnRzIHR3byBWUE5zLCB0aGUgc2lnbmlm aWNhbmNlIG9mIG9yZGVyaW5nIGluIHRoZSBldmFsdWF0aW9uIG9mIGNvbmZsaWN0cyB3aWxsIGJl IGhpZ2hsaWdodGVkOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+VlBOMTo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ KDE5Mi4wLjIuMS8zMiwgMTAwLCAxLCAxLCAwKTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4oMTkyLjAuMi4xLzMyLCAyMDAsIDEsIDEsIDApPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VlBOMjo8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPigxOTIuMC4yLjEwMC8zMiwgMjAwLCAxLCAy LCAwKTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgd2Ug ZXZhbHVhdGUgcHJlZml4IGNvbmZsaWN0cyBmaXJzdCwgdGhlbiB0aGUgZm9sbG93aW5nIGVudHJp ZXMgYXJlIOKAnGFjdGl2ZeKAnTo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+KDE5Mi4wLjIuMS8zMiwgMTAwLCAxLCAxLCAwKSAhVlBOMTwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4oMTkyLjAuMi4xMDAvMzIsIDIw MCwgMSwgMiwgMCkgIVZQTjI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPklmIHdlIGV2YWx1YXRlIFNJRCBjb25mbGljdHMgZmlyc3QsIHRoZW4gdGhlIGZvbGxv d2luZyBlbnRyaWVzIGFyZSDigJxhY3RpdmXigJ06PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPigxOTIuMC4yLjEvMzIsIDEwMCwgMSwgMSwgMCkgIVZQTjE8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBsYXR0ZXIg Y2hvaWNlIGlzIHN1Ym9wdGltYWwgYmVjYXVzZSBpdCBwcmV2ZW50cyB1c2Ugb2YgdGhlIFZQTjIg ZW50cnkgdW5uZWNlc3NhcmlseS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoaXMgcG9pbnQgbmVlZHMgdG8gYmUgbWFkZSBleHBsaWNpdCBpbiB0aGUgZHJh ZnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsgTGVzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+IHNwcmluZyBbPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj48L3NwYW4+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YnJ1bm8u ZGVjcmFlbmVAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAxMiwg MjAxNiA4OjIzIEFNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zcHJpbmdAaWV0Zi5vcmc8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b24gLSBQb2xpY3k8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhpIGF1dGhvcnMsIGFsbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9y LCBwbGVhc2UgZmluZCBiZWxvdyBzb21lIGZlZWRiYWNrIG9uIHRoZSBwb2xpY3kuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkknbSB3b25kZXJpbmcgaWYgd2UgY291bGQgYWRkcmVz cyB0aGUgY29uZmxpY3Qgb24gYSBwZXIgRkVDL1ByZWZpeCBiYXNpcyByYXRoZXIgdGhhbiBvbiBh IHBlciBJR1AgYWR2ZXJ0aXNlbWVudCBiYXNpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIHNvLCB0aGlzIG1h eSBhdm9pZCB0aGUgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBRdWFyYW50aW5lIHZzIGlnbm9yZSBw b2xpY3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBwcm9ibGVtIHRoYXQg d2UgbmVlZCB0byBzb2x2ZSwgaXMgdG8gZmluZCB0aGUgU0lEIGZvciBhIHByZWZpeCAoUDEpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+VGhlIGFsZ28gY291bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIEZpbmQgYWxsIFNJ RGkgYWR2ZXJ0aXNlZCBmb3IgdGhlIHByZWZpeCBQMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBpZGVudGlmaWNhdGlvbiBv ZiBQcmVmaXggY29uZmxpY3RzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLSBGb3IgZWFjaCBTSURpIGZpbmQgYWxsIHRoZSBwcmVmaXggUGlqIGFzc29jaWF0 ZWQgd2l0aCBTSURpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIGlkZW50aWZpY2F0aW9uIG9mIFNJ RCBjb25mbGljdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ly8gYXMgYSByZXN1 bHQsIHdlIGdldCBhIGxpc3Qgb2YgU0lEaSDigJMgUGlqIGZvciBQMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5HZXQgdGhlIGJlc3QgYXMgcGVyIHRoZSBwcmVmZXJlbmNlIGFsZ29y aXRobS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPklmIGJlc3QgUGlqID09IFAxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiB1c2UgU0lEaWogZm9yIFAxPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZWxzZSByZXR1cm4gbm8gU0lE Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8gbm8gU0lEIGF2YWlsYWJsZSBm b3IgdGhpcyBwcmVmaXggUDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE5v dGUgdGhhdCBpdCB3b3VsZCBwcm9iYWJseSBiZSBiZXR0ZXIgZm9yIHRoZSBwcmVmZXJlbmNlIGFs Z28gdG8gcHV0IHRoZSBTSUQgdGllLWJyYWtlIGJlZm9yZSB0aGUgcHJlZml4IHRpZS1icmVhayBh cyB3aXRoIHRoZSBwcmVmaXggdGllLWJyZWFrLCB3ZSBzdWZmZXIgZnJvbSB0aGUgY29uZmxpY3Qg dHdpY2UgKFByZWZpeCAtIFNJRCBtYXBwaW5nLCB0aGVuDQogU0lELSBwcmVmaXggbWFwcGluZykg d2hpY2ggaW5jcmVhc2UgdGhlIGRpdmVyc2l0eSBhbmQgaGVuY2UgdGhlIGNoYW5jZSBvZiBub3Qg ZmluZGluZyBhIHZhbGlkIGVudHJ5LiZuYnNwOyZuYnNwOyBCdXQgZm9yIHRoZSBiZWxvdyBleGFt cGxlcywgSSB1c2VkIHRoZSBwcmVmZXJlbmNlIGFsZ28gZnJvbSBkcmFmdC1pZXRmLSotMDA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+QmVsb3cgYXJlIGV4YW1wbGVzLCBydW5uaW5nIHRoaXMgcG9s aWN5IG9uIHR5cGljYWwgY29uZmlndXJhdGlvbiBlcnJvciBjYXNlcy4mbmJzcDsmbmJzcDsmbmJz cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+RXhhbXBsZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMuNC40LiZuYnNwOyBOZXR3 b3JrIG9wZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBzaW1wbGUgbmV0d29yayBleGFtcGxlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgMS4mbmJzcDsgMTAwIG5vZGVz OiBSMSB0byBSMTAwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgMi4mbmJzcDsgSVAgTG9vcGJhY2tzIGFyZSBmcm9tIDE5Mi4wLjIuMSB0byAxOTIuMC4yLjEw MDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7 IFNJRCBhcmUgZnJvbSAxIHRvIDEwMDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IDQuJm5ic3A7IFIxIHRvIFI1MCBhcmUgU1IgY2FwYWJsZSBhbmQgYWR2ZXJ0 aXNlZCB0aGVpciBvd24gU0lEIHVzaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUHJlZml4LVNJRCBzdWItVExWOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgNS4mbmJzcDsgUjUxIHRvIFIxMDAgYXJlIFNSIG5v bi1jYXBhYmxlLCBydW5uaW5nIExEUCBhbmQgdGhlaXIgU0lEIGFyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO2FkdmVydGlzZWQgYnkgdHdvIHJlZHVu ZGFudCBNYXBwaW5nIFNlcnZlciBNUzEgYW5kIE1TMjs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IDYuJm5ic3A7IEFzIHRoZSBudW1iZXIgb2Ygbm9kZXMgd2hp Y2ggYXJlIFNSIGNhcGFibGUgYXJlIGV4cGVjdGVkIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5jcmVhc2UgYW5kIGFzIGluIHJlYWwgZGVwbG95 bWVudCB0aGVpciBMb29wYmFjayBhZGRyZXNzZXMgd291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyB0aGUgY29udGlndW91cywgdGhlIE1hcHBp bmcgc2VydmVycyBhZHZlcnRpc2VtZW50IGNvdmVycyBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMb29wYmFja3M6ICgxOTIuMC4yLjEvMzIsIDEs IDEwMCk7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBTdWJz ZXF1ZW50IHNlY3Rpb25zIGV2YWx1YXRlIHRoZSBjb25zZXF1ZW5jZXMgb2YgYSBzaW5nbGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjb25maWd1cmF0aW9uIGVycm9yLCBmb3IgYWxsIGNvbmZs aWN0IHJlc29sdXRpb24gb3B0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ My40LjQuMS4mbmJzcDsgRXhhbXBsZSAxOiBTSUQgY29uZmlndXJlZCBvbiAxIG5vZGUgY29uZmxp Y3Qgd2l0aCBTSUQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25maWd1cmVkIG9uIGFub3RoZXIgbm9kZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRm9sbG93aW5nIGEgdHlwbyBk dXJpbmcgY29uZmlndXJhdGlvbiwgUjIgaXMgY29uZmlndXJlZCB3aXRoIGEgU0lEIG9mPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgMTIuJm5ic3A7IFRoYXQgU0lEIGNvbmZsaWN0cyB3aXRoIHRo ZSBQcmVmaXgtU0lEIGFkdmVydGlzZWQgYnkgUjEyIGFuZCB0aGUgTWFwcGluZyBTZXJ2ZXIgQWR2 ZXJ0aXNlbWVudCBmb3IgUjEyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE5vdGU6IGJvdGgg TVMgYWR2ZXJ0aXNlbWVudCBhcmUgdGhlIHNhbWUsIHNvIHdlIG9ubHkgY29uc2lkZXIgb25lIGlu IHRoZSBiZWxvdyBhbmFseXNpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwO0FsbCBwcmVmaXggYnV0IFIyIGFuZCBSMTIsIGEgc2luZ2xl IFNJRCBpcyBhZHZlcnRpc2VkIGFuZCBoZW5jZSBzZWxlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0ZvciBSMiwgdGhlIGFsZ28g ZXZhbHVhdGVzIGEgY29uZmxpY3QgYmV0d2VlbiB0aGUgZm9sbG93aW5nIGFkdmVydGlzbWVudHM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgUjIgLSBTSUQyIC0gUjIgKE1TLCBNUyk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBSMiAtIFNJRDEyIC0gUjEyIChwcmVmaXggU0lELCBNUykNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7UjIgLSBTSUQxMiAtIFIyJm5ic3A7IChwcmVm aXggU0lELCBwcmVmaXggU0lEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtCZXN0 IG9uZSBpcyBSMiAtIFNJRDEyIC0gUjIgKHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpLHNtYWxs ZXIgcmFuZ2UgKHByZWZpeCBTSUQpKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ID09Jmd0OyBT SUQxMiBpcyBzZWxlY3RlZCBmb3IgUjIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtGb3IgUjEyLCB0aGUgYWxnbyBldmFsdWF0ZXMgYSBj b25mbGljdCBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgYWR2ZXJ0aXNtZW50czo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBSMTIgLSBTSUQxMiAtIFIxMiAocHJlZml4IFNJRCwgcHJlZml4IFNJRCk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBSMTIgLSBTSUQxMiAtIFIyJm5ic3A7IChwcmVmaXgg U0lELCBwcmVmaXggU0lEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFIxMiAtIFNJRDEyIC0g UjEyIChwcmVmaXggU0lELCBNUyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBSMTIgLSBTSUQx MiAtIFIyJm5ic3A7IChNUywgcHJlZml4IFNJRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBS MTIgLSBTSUQxMiAtIFIxMiAoTVMsIE1TKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QmVzdCBvbmUgaXMgUjEyIC0gU0lEMTIgLSBSMiAo c21hbGxlciByYW5nZSAocHJlZml4IFNJRCksc21hbGxlciByYW5nZSAocHJlZml4IFNJRCksIHNt YWxsZXIgc3RhcnRpbmcgYWRyZXNzZSAoUjIpKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDtSMTIgJmx0OyZndDsgUjIgPT0mZ3Q7IFIxMiBoYXMgbm8gU0lELjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7My40LjQuMi4mbmJz cDsgRXhhbXBsZSAyOiBTSUQgY29uZmlndXJlZCBvbiAxIG5vZGUgY29uZmxpY3Qgd2l0aCBTSUQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb25maWd1cmVkIG9uIHRoZSBNYXBwaW5nIFNlcnZlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRm9sbG93aW5nIGEgdHlwbyBkdXJpbmcg Y29uZmlndXJhdGlvbiwgUjIgaXMgY29uZmlndXJlZCB3aXRoIGEgU0lEIG9mPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgNTIuJm5ic3A7IFRoYXQgU0lEIGNvbmZsaWN0cyB3aXRoIHRoZSBNYXBw aW5nIFNlcnZlciBhZHZlcnRpc2VtZW50cyBvZiBNUzE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBhbmQgTVMyIGZvciB0aGUgbG9vcGJhY2sgb2YgUjUyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IE5vdGU6IGJvdGggTVMgYWR2ZXJ0aXNlbWVudCBhcmUgdGhlIHNhbWUsIHNvIHdlIG9ubHkg Y29uc2lkZXIgb25lIGluIHRoZSBiZWxvdyBhbmFseXNpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0FsbCBwcmVmaXggYnV0IFIyIGFu ZCBSNTIsIGEgc2luZ2xlIFNJRCBpcyBhZHZlcnRpc2VkIGFuZCBoZW5jZSBzZWxlY3RlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0Zv ciBSMiwgdGhlIGFsZ28gZXZhbHVhdGVzIGEgY29uZmxpY3QgYmV0d2VlbiB0aGUgZm9sbG93aW5n IGFkdmVydGlzbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgUjIgLSBTSUQ1MiAtIFIy Jm5ic3A7IChwcmVmaXggU0lELCBwcmVmaXggU0lEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IFIyIC0gU0lENTIgLSBSNTIgKHByZWZpeCBTSUQsIE1TKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IFIyIC0gU0lEMiZuYnNwOyAtIFIyJm5ic3A7IChNUywgTVMpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtCZXN0IG9uZSBpcyBSMiAt IFNJRDUyIC0gUjIgKHNtYWxsZXIgcmFuZ2UgKHByZWZpeCBTSUQpLHNtYWxsZXIgcmFuZ2UgKHBy ZWZpeCBTSUQpKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ID09Jmd0OyBTSUQ1MiBpcyBzZWxl Y3RlZCBmb3IgUjIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDtGb3IgUjUyLCB0aGUgYWxnbyBldmFsdWF0ZXMgYSBjb25mbGljdCBiZXR3 ZWVuIHRoZSBmb2xsb3dpbmcgYWR2ZXJ0aXNtZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBSNTIgLSBTSUQ1MiAtIFI1MiAoTVMsIE1TKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFI1 MiAtIFNJRDUyIC0gUjImbmJzcDsgKE1TLCBwcmVmaXggU0lEKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QmVzdCBvbmUgaXMgUjUyIC0g U0lENTIgLSBSMiAoc21hbGxlciByYW5nZSAocHJlZml4IFNJRCkpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgUjUyICZsdDsmZ3Q7IFIyID09Jmd0OyBSNTIgaGFzIG5vIFNJRC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+My40LjQuMy4mbmJzcDsgRXhhbXBsZSAzOiB3cm9uZyBjb25maWd1cmF0aW9uIG9mIGEg TVM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEZvbGxvd2lu ZyBhIHR5cG8gZHVyaW5nIGNvbmZpZ3VyYXRpb24sIE1TMSBpcyBjb25maWd1cmVkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgKDE5Mi4wLjIuMC8zMiwgMSwgMTAwKS4gKGkuZS4gMTkyLjAuMi4w IGluc3RlYWQgb2YgMTkyLjAuMi4xKS4mbmJzcDsgVGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGFkdmVydGlzZW1lbnQgY29uZmxpY3RzIHdpdGggdGhlIE1hcHBpbmcgU2VydmVyIGFkdmVy dGlzZW1lbnRzIG9mIE1TMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFuZCB0aGUgUHJlZml4 LVNJRCBhZHZlcnRpc2VkIGJ5IFIxLi4uUjUwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7V2UgaGF2ZSBhIGNvbmZsaWN0IGZvciBhbGwg cm91dGVycyBleGNlcHQgUjEwMC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwO0ZvciBMRFAgb25seSByb3V0ZXJzIFI1MSB0byBSOTkgd2Ug aGF2ZSBhIGNvbmZsaWN0IGJldHdlZW4gYm90aCBNUyBhZHZlcnRpc2VtZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IEZvciBSNTIsIHRoZSBhbGdvIGV2YWx1YXRlcyBhIGNvbmZsaWN0IGJl dHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IFI1MiAtIFNJRDUyIC0gUjUyIChNUzIsIE1TMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBSNTIgLSBTSUQ1MiAtIFI1MSAoTVMyLCBNUzEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg UjUyIC0gU0lENTMgLSBSNTIgKE1TMSwgTVMxKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFI1 MiAtIFNJRDUzIC0gUjUzIChNUzEsIE1TMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IEJlc3Qgb25lIGlzIFI1MiAtIFNJRDUyIC0gUjUxIChzbWFsbGVyIHN0 YXJ0aW5nIGFkZHJlc3MpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgUjUyICZsdDsmZ3Q7IFI1 MSA9PSZndDsgUjUyIGhhcyBubyBTSUQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtGb3IgU1Igcm91dGVycywgUjEgdG8gNTAsIHdlIGhh dmUgYSBjb25mbGljdCBiZXR3ZWVuIGJvdGggTVMgYWR2ZXJ0aXNlbWVudCBhbmQgUHJlZml4IFNJ RCBhZHZlcnRpc2VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBGb3IgUjIsIHRoZSBh bGdvIGV2YWx1YXRlcyBhIGNvbmZsaWN0IGJldHdlZW4gdGhlIGZvbGxvd2luZyBhZHZlcnRpc21l bnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFIyIC0gU0lEIDIgLSBSMiAoUHJlZml4IFNJ RCwgUHJlZml4IFNJRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBSMiAtIFNJRCAyIC0gUjIg KFByZWZpeCBTSUQsIE1TMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBSMiAtIFNJRCAyIC0g UjEgKFByZWZpeCBTSUQsIE1TMSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBSMiAtIFNJRCAy IC0gUjIgKE1TMiwgTVMyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFIyIC0gU0lEIDIgLSBS MiAoTVMyLCBQcmVmaXggU0lEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFIyIC0gU0lEIDIg LSBSMSAoTVMyLCBNUzEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgUjIgLSBTSUQgMyAtIFIy Jm5ic3A7IChNUzEsIE1TMSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBSMiAtIFNJRCAzIC0g UjMmbmJzcDsgKE1TMSwgTVMyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFIyIC0gU0lEIDMg LSBSMyZuYnNwOyAoTVMxLCBQcmVmaXggU0lEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QmVzdCBvbmUgaXMgUjIgLSBTSUQgMiAtIFIy IChQcmVmaXggU0lELCBQcmVmaXggU0lEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFIyID09 IFIyIGhlbmNlIFIyIHVzZSBTSUQyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xv cjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+QnJ1bm88L3NwYW4+PHNwYW4gbGFuZz0iRlIt Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9z cGFuPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8L3Nw YW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+cGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8L3Nw YW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+YSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3Nw YW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+T3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVyY2kuPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlRoYW5rIHlvdS48L3NwYW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0K PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4g bGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkZSLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvc3Bhbj48c3BhbiBs YW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5wYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48c3BhbiBs YW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5hIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvc3Bhbj48c3BhbiBs YW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5PcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZXJjaS48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+VGhhbmsgeW91Ljwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZXJjaS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91Ljwv c3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJjb2xvcjpibGFjayI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+PHNwYW4gbGFuZz0iRlIt Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NZXJjaS48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFj ayI+VGhhbmsgeW91Ljwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gbGFuZz0iRlIt Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+Q2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPjxzcGFuIGxh bmc9IkZSLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5wYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48c3Bh biBsYW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+YSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+ PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NZXJj aS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJjb2xvcjpibGFjayI+VGhhbmsgeW91Ljwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+ PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+Q2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j PC9zcGFuPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5w YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcjwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFj ayI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiw8L3NwYW4+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6 YmxhY2siPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5NZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zcHJpbmcgbWFpbGluZyBsaXN0PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A79394211F1AF4EB57D998426C9340DD49C6D94US70UWXCHMBA01z_-- From nobody Mon Jul 25 12:39:45 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFB412B044; Mon, 25 Jul 2016 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK92s1vDDNeo; Mon, 25 Jul 2016 12:39:43 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153BB12D5B5; Mon, 25 Jul 2016 12:39:42 -0700 (PDT) Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bRlij-00037h-UP; Mon, 25 Jul 2016 20:39:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> Date: Mon, 25 Jul 2016 13:39:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <46F3A55E-2689-4661-9D31-FA7754D2CBD4@rob.sh> References: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> To: "John G.Scudder" , spring@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: Re: [spring] =?utf-8?q?IPR_for_draft=E2=80=90ietf-spring-segment?= =?utf-8?q?=E2=80=90routing-mpls_prior_to_WGLC?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 19:39:45 -0000 Hi John, SPRING WG, > On 24 Jul, 2016, at 6:52 AM, John G.Scudder wrote: >=20 > As we discussed at the SPRING meeting, working group last call has = been requested for draft=E2=80=90ietf-spring-segment=E2=80=90routing-mpls.= Before we begin the WGLC, please indicate whether you are aware of any = relevant IPR and if so, whether it has been disclosed. (Please do this = even if you've done it before, thanks for your help.) Please cc the WG = in your reply. I am not aware of any IPR over and above that which has already been = disclosed. Kind regards, r.= From nobody Mon Jul 25 12:42:48 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5084B12D5CA; Mon, 25 Jul 2016 12:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLk-IJrWrKE0; Mon, 25 Jul 2016 12:42:45 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D53712D5B5; Mon, 25 Jul 2016 12:42:44 -0700 (PDT) Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bRllh-00038U-6x; Mon, 25 Jul 2016 20:42:25 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> Date: Mon, 25 Jul 2016 13:42:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> To: "John G.Scudder" , spring@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-spring-segment-routing@ietf.org Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 19:42:47 -0000 Hi John, Bruno, SPRING WG, > On 24 Jul, 2016, at 6:49 AM, John G.Scudder wrote: >=20 > As we discussed at the SPRING meeting, a second working group last = call has been requested for draft-ietf-spring-segment-routing. Before we = begin the WGLC, please indicate whether you are aware of any relevant = IPR and if so, whether it has been disclosed. (Please do this even if = you've done it before, thanks for your help.) Please cc the WG in your = reply. I am not aware of any IPR over and above that which has already been = disclosed which is relevant to this draft. Kind regards, r. From nobody Tue Jul 26 00:12:14 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B875512B071; Tue, 26 Jul 2016 00:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcjKcYiI23jD; Tue, 26 Jul 2016 00:12:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D4112B024; Tue, 26 Jul 2016 00:12:11 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 076CC18C651; Tue, 26 Jul 2016 09:12:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DD2B335C060; Tue, 26 Jul 2016 09:12:09 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 09:12:09 +0200 From: To: John G.Scudder , "draft-ietf-spring-segment-routing-mpls@ietf.org" Thread-Topic: =?utf-8?B?SVBSIGZvciBkcmFmdOKAkGlldGYtc3ByaW5nLXNlZ21lbnTigJByb3V0aW5n?= =?utf-8?Q?-mpls_prior_to_WGLC?= Thread-Index: AQHR5apArbiCfb7qe0uY7ZX337Mw26AqTnbQ Date: Tue, 26 Jul 2016 07:12:08 +0000 Message-ID: <8550_1469517129_57970D49_8550_4062_1_53C29892C857584299CBF5D05346208A0F968ACC@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> In-Reply-To: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.25.183617 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] =?utf-8?q?IPR_for_draft=E2=80=90ietf-spring-segment?= =?utf-8?q?=E2=80=90routing-mpls_prior_to_WGLC?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 07:12:13 -0000 Sm9obiwgYWxsDQoNCkknbSBub3QgYXdhcmUgb2Ygbm9uLWRpc2Nsb3NlZCBJUFIuDQoNCi0tQnJ1 bm8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIEcuU2N1ZGRl ciBbbWFpbHRvOmpnc0BqdW5pcGVyLm5ldF0NCj4gU2VudDogU3VuZGF5LCBKdWx5IDI0LCAyMDE2 IDI6NTIgUE0NCj4gVG86IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzQGll dGYub3JnDQo+IENjOiBzcHJpbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogSVBSIGZvciBkcmFmdOKA kGlldGYtc3ByaW5nLXNlZ21lbnTigJByb3V0aW5nLW1wbHMgcHJpb3IgdG8gV0dMQw0KPiANCj4g RGVhciBBdXRob3JzOg0KPiANCj4gQXMgd2UgZGlzY3Vzc2VkIGF0IHRoZSBTUFJJTkcgbWVldGlu Zywgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVkIGZvcg0KPiBkcmFm dOKAkGlldGYtc3ByaW5nLXNlZ21lbnTigJByb3V0aW5nLW1wbHMuIEJlZm9yZSB3ZSBiZWdpbiB0 aGUgV0dMQywgcGxlYXNlIGluZGljYXRlDQo+IHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkg cmVsZXZhbnQgSVBSIGFuZCBpZiBzbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuIChQ bGVhc2UNCj4gZG8gdGhpcyBldmVuIGlmIHlvdSd2ZSBkb25lIGl0IGJlZm9yZSwgdGhhbmtzIGZv ciB5b3VyIGhlbHAuKSBQbGVhc2UgY2MgdGhlIFdHIGluIHlvdXIgcmVwbHkuDQo+IA0KPiBBcyBz b29uIGFzIHRoaXMgaGFzIGJlZW4gY29sbGVjdGVkIGZyb20gYWxsIGF1dGhvcnMsIHdlJ2xsIHN0 YXJ0IHRoZSBXR0xDLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gLS1CcnVubyBhbmQgSm9obg0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Jul 26 00:13:03 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F11312B014; Tue, 26 Jul 2016 00:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryGa_p5lVJsn; Tue, 26 Jul 2016 00:13:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328B012B05B; Tue, 26 Jul 2016 00:13:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id BBB893246C9; Tue, 26 Jul 2016 09:12:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.3]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 94BEA4C086; Tue, 26 Jul 2016 09:12:59 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 09:12:59 +0200 From: To: John G.Scudder , "draft-ietf-spring-segment-routing@ietf.org" Thread-Topic: IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC Thread-Index: AQHR5andwgiAz5q2q0mSIhzBAz7I/KAqTtYg Date: Tue, 26 Jul 2016 07:12:59 +0000 Message-ID: <1989_1469517179_57970D7B_1989_10132_3_53C29892C857584299CBF5D05346208A0F968B03@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> In-Reply-To: <13C3A727-447A-4C96-ACDC-641EF4A4ECB4@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.26.62717 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 07:13:02 -0000 John, all I'm not aware of non-disclosed IPR. --Bruno > -----Original Message----- > From: John G.Scudder [mailto:jgs@juniper.net] > Sent: Sunday, July 24, 2016 2:49 PM > To: draft-ietf-spring-segment-routing@ietf.org > Cc: spring@ietf.org > Subject: IPR for draft-ietf-spring-segment-routing prior to (additional) = WGLC >=20 > Dear Authors: >=20 > As we discussed at the SPRING meeting, a second working group last call h= as been > requested for draft-ietf-spring-segment-routing. Before we begin the WGLC= , please > indicate whether you are aware of any relevant IPR and if so, whether it = has been > disclosed. (Please do this even if you've done it before, thanks for your= help.) Please cc the > WG in your reply. >=20 > As soon as this has been collected from all authors, we'll start the WGLC. >=20 > Thanks, >=20 > --Bruno and John ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Jul 26 00:24:04 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F047712D0AD for ; Tue, 26 Jul 2016 00:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcxyYG83cmwH for ; Tue, 26 Jul 2016 00:24:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BE012B05B for ; Tue, 26 Jul 2016 00:24:01 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 6AAF3404B6; Tue, 26 Jul 2016 09:23:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 06A051C0077; Tue, 26 Jul 2016 09:23:59 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 09:23:58 +0200 From: To: "John G. Scudder" , "spring@ietf.org" Thread-Topic: [spring] WG adoption requested for draft-filsfils-spring-large-scale-interconnect Thread-Index: AQHR5aq/RKfM2Z6vyEWLHgPr8bhzgKAqUYqg Date: Tue, 26 Jul 2016 07:23:57 +0000 Message-ID: <15490_1469517839_5797100F_15490_5747_7_53C29892C857584299CBF5D05346208A0F968B6B@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-large-scale-interconnect X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 07:24:03 -0000 Sm9obiwgYWxsDQoNCkknbSBub3QgYXdhcmUgb2Ygbm9uLWRpc2Nsb3NlZCBJUFIuDQoNCi0tQnJ1 bm8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcHJpbmcgW21haWx0 bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gRy4gU2N1ZGRlcg0K PiBTZW50OiBTdW5kYXksIEp1bHkgMjQsIDIwMTYgMjo1NiBQTQ0KPiBUbzogc3ByaW5nQGlldGYu b3JnDQo+IFN1YmplY3Q6IFtzcHJpbmddIFdHIGFkb3B0aW9uIHJlcXVlc3RlZCBmb3IgZHJhZnQt Zmlsc2ZpbHMtc3ByaW5nLWxhcmdlLXNjYWxlLWludGVyY29ubmVjdA0KPiANCj4gRGVhciBXRywN Cj4gDQo+IEFzIHdlIGRpc2N1c3NlZCBhdCBvdXIgbWVldGluZywgd29ya2luZyBncm91cCBhZG9w dGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ04oCQDQo+IGZpbHNmaWxz4oCQc3ByaW5n 4oCQbGFyZ2Utc2NhbGUtaW50ZXJjb25uZWN0LiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0 aCB5b3VyIGNvbW1lbnRzLA0KPiBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQgdG8gd2hl dGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZQ0KPiBlc3Bl Y2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCj4gDQo+IFdlIHdpbGwgZW5kIHRoZSBjYWxs IG9uIEF1Z3VzdCAzMSwgMjAxNS4NCj4gDQo+IEF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0 aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiBhbmQgaWYgc28sIHdoZXRoZXIg aXQNCj4gaGFzIGJlZW4gZGlzY2xvc2VkLiBBbHNvLCB0aGUgbGVuZ3RoIG9mIHRoZSBhdXRob3Ig bGlzdCBmb3IgdGhpcyBkb2N1bWVudCBncmVhdGx5IGV4Y2VlZHMgdGhlDQo+IG1heGltdW0gcmVj b21tZW5kZWQuIEFzc3VtaW5nIHRoZSBkb2N1bWVudCBpcyBhZG9wdGVkLCB0aGUgYXV0aG9ycyBz aG91bGQgYmUNCj4gcHJlcGFyZWQgdG8gY29ycmVjdCB0aGlzIHdoZW4gc3VibWl0dGluZyBhcyBh IFdHIGRvY3VtZW50LCBpZGVhbGx5IGJ5IHJlZHVjaW5nIHRoZSBsaXN0IHRvDQo+IHNpbXBseSB0 aGUgYWN0aXZlIGVkaXRvcihzKSBhbmQgbWFraW5nIHVzZSBvZiB0aGUgImNvbnRyaWJ1dG9ycyIg c2VjdGlvbiBmb3IgdGhlIGZ1bGwgbGlzdC4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IC0tQnJ1bm8g YW5kIEpvaG4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gc3ByaW5nQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCgo= From nobody Tue Jul 26 01:43:36 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E212D698; Tue, 26 Jul 2016 01:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdmF2lwKv6iJ; Tue, 26 Jul 2016 01:43:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A62612B039; Tue, 26 Jul 2016 01:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=933; q=dns/txt; s=iport; t=1469522613; x=1470732213; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MRLc3tuvvEAWZ02eXMuIR9we7ucnWEDIO6oSNJHLGKw=; b=CaFFZwD4a9avZSFbS3LhHaQFbej+3IHxTc2RT9qbQ/1hCwaLy0YIqkWH Yw838mE8Hg6i6c11lbBUMA856/aLUp5vnEYfGh1Gf0KX+KwSKiYopvzej 3LJkurROr4ox1capD37PeiRig/fmvisNdgQEeTvOgHzS7vVDm397TGiU0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAwBAIZdX/4MNJK1egz+BUrZpgg+Bf?= =?us-ascii?q?YYdAoExOBQBAQEBAQEBXSeEXAEBBAE6PwULAgEIGB4QMiUCBA4FiCkItnsBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEchiqBeIJVhECDLIIvAQSTb4VCAY56gWyEWoh5j?= =?us-ascii?q?C2DdwEeNoN4bohCAQEB?= X-IronPort-AV: E=Sophos;i="5.28,423,1464652800"; d="scan'208";a="128192184" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jul 2016 08:43:32 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6Q8hWg0032375 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jul 2016 08:43:32 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 26 Jul 2016 04:43:31 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 26 Jul 2016 04:43:31 -0400 From: "Carlos Pignataro (cpignata)" To: "John G.Scudder" Thread-Topic: IPR for draft-ietf-spring-oam-usecase prior to WGLC Thread-Index: AQHR5al7bd/7oH0jHEaRgqtTxOHpTqAqaECV Date: Tue, 26 Jul 2016 08:43:31 +0000 Message-ID: <21F65233-2D17-490D-853A-9385AF18B57E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 08:43:35 -0000 Hi, The datatracker shows two IPR disclosures against this document, with IDs 2= 314 and 2406.=20 I am not aware of any additional and undisclosed IPR directly applicable to= this I-D.=20 Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Jul 24, 2016, at 13:47, John G.Scudder wrote: >=20 > [re-sending with WG in cc. Please cc WG on your replies, thanks and sorry= for the dup.] >=20 > Dear Authors: >=20 > As we discussed at the SPRING meeting, working group last call has been r= equested for draft-ietf-spring-oam-usecase. Before we begin the WGLC, pleas= e indicate whether you are aware of any relevant IPR and if so, whether it = has been disclosed. (Please do this even if you've done it before, thanks f= or your help.) >=20 > As soon as this has been collected from all authors, we'll start the WGLC= . >=20 > Thanks, >=20 > --Bruno and John From nobody Tue Jul 26 05:01:19 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08A612D732 for ; Tue, 26 Jul 2016 05:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD4-13GKExQ1 for ; Tue, 26 Jul 2016 05:01:11 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5BB12D6AA for ; Tue, 26 Jul 2016 05:01:10 -0700 (PDT) Received: from [2602:4b:a27f:3000:d1c5:1dbb:8246:bddc] by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bS12Y-0004I9-68; Tue, 26 Jul 2016 13:00:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: Date: Tue, 26 Jul 2016 06:01:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "John G. Scudder" , spring@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 12:01:18 -0000 Hi, Apologies, this document uses my old e-mail address on it. > On Jul 24, 2016, at 06:55, John G. Scudder wrote: >=20 > Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author = list for this document greatly exceeds the maximum recommended. Assuming = the document is adopted, the authors should be prepared to correct this = when submitting as a WG document, ideally by reducing the list to simply = the active editor(s) and making use of the "contributors" section for = the full list. I=E2=80=99m not aware of any undisclosed IPR. Thanks, r. From nobody Tue Jul 26 07:06:50 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3437F12DD1D; Tue, 26 Jul 2016 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.788 X-Spam-Level: X-Spam-Status: No, score=-15.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVXcI3vA6UBE; Tue, 26 Jul 2016 07:06:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC8A12DD18; Tue, 26 Jul 2016 06:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1076; q=dns/txt; s=iport; t=1469541222; x=1470750822; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OWfpTiY76o0/Jb0CUrkeYUa8Wn0uvEbMpIdSen45zbQ=; b=e4ni3hQ0l/ejFlQbgZKuBpDmdzq+EUrzYcJwdIK063YLrpR4K4OFHk6F cdmG75P5HjYPLcDXnBlTn6kgpWObfgRsh/FsSDv4uDVvpGqzvHlWUvC5o D28iDSJ2t//EQWKTdMBS9X85me2iTBuGoOP8iPXco83q4AWcZmMG5gEYx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfCAAHa5dX/4sNJK1egz+BUga2ZIIPg?= =?us-ascii?q?X2GHQKBNzkTAQEBAQEBAV0nhF0BBTo/EAIBCBgeEDIlAgQBDQWIMbg1AQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBHIp3ihsBBJkxAY56gWyEWoh5jC2DdwEgATODeG6HS?= =?us-ascii?q?n8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,425,1464652800"; d="scan'208";a="133756875" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jul 2016 13:53:41 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u6QDrfi2025367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jul 2016 13:53:41 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 26 Jul 2016 08:53:40 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Tue, 26 Jul 2016 08:53:41 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Carlos Pignataro (cpignata)" , "John G.Scudder" Thread-Topic: IPR for draft-ietf-spring-oam-usecase prior to WGLC Thread-Index: AQHR5al63cNxMu+81UeHL7OGbH5Q2aAqvBGAgAATlIA= Date: Tue, 26 Jul 2016 13:53:40 +0000 Message-ID: References: <21F65233-2D17-490D-853A-9385AF18B57E@cisco.com> In-Reply-To: <21F65233-2D17-490D-853A-9385AF18B57E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.241.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 14:06:48 -0000 Hi, I am not aware of any other IPR that is not disclosed. Thanks, Nagendra On 7/26/16, 4:43 AM, "Carlos Pignataro (cpignata)" wrote: >Hi, > >The datatracker shows two IPR disclosures against this document, with IDs >2314 and 2406.=20 > >I am not aware of any additional and undisclosed IPR directly applicable >to this I-D.=20 > >Thanks! > >Thumb typed by Carlos Pignataro. >Excuze typofraphicak errows > >> On Jul 24, 2016, at 13:47, John G.Scudder wrote: >>=20 >> [re-sending with WG in cc. Please cc WG on your replies, thanks and >>sorry for the dup.] >>=20 >> Dear Authors: >>=20 >> As we discussed at the SPRING meeting, working group last call has been >>requested for draft-ietf-spring-oam-usecase. Before we begin the WGLC, >>please indicate whether you are aware of any relevant IPR and if so, >>whether it has been disclosed. (Please do this even if you've done it >>before, thanks for your help.) >>=20 >> As soon as this has been collected from all authors, we'll start the >>WGLC From nobody Tue Jul 26 07:08:04 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C319612DEA5 for ; Tue, 26 Jul 2016 07:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGV-NjWuVoKU for ; Tue, 26 Jul 2016 07:07:59 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64EC12D829 for ; Tue, 26 Jul 2016 06:54:19 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id A125CC061B; Tue, 26 Jul 2016 15:54:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 774A520066; Tue, 26 Jul 2016 15:54:18 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 15:54:18 +0200 From: To: John G.Scudder , "spring@ietf.org" Thread-Topic: [spring] Minutes of IETF-96 SPRING posted Thread-Index: AQHR5pupyIFyX94jC0WNyucWMTAyBKAqt8Yg Date: Tue, 26 Jul 2016 13:54:17 +0000 Message-ID: <5865_1469541258_57976B8A_5865_950_1_53C29892C857584299CBF5D05346208A0F969053@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Minutes of IETF-96 SPRING posted X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 14:08:04 -0000 Hi all, FYI, I've slightly updated the minutes, after reviewing the audio. I've also added direct URL to the audio for each presentation & QA. As a re= minder, once on the URL, you also need to click on the "Play" button to ini= tiate the playback. --Bruno > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of John G.Scudder > Sent: Monday, July 25, 2016 7:40 PM > To: spring@ietf.org > Subject: [spring] Minutes of IETF-96 SPRING posted >=20 > Hi Everyone, >=20 > Minutes are now available at https://www.ietf.org/proceedings/96/minutes/= minutes-96- > spring. Please send any corrections or comments to the list. Thanks to Wi= m for the notes! >=20 > --John > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Jul 26 09:08:46 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9781E12D898 for ; Tue, 26 Jul 2016 09:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHgQYaqX-EtV for ; Tue, 26 Jul 2016 09:08:44 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D5412D1B1 for ; Tue, 26 Jul 2016 08:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2461; q=dns/txt; s=iport; t=1469548665; x=1470758265; h=from:to:cc:subject:date:message-id:mime-version; bh=8DJZS7W5ryasME1QThSU1W0gv0Ya0Ujja6GkxRn+hQI=; b=IvBbTX0ExxXGWIyxOtmiV99j+Qix5G6dhjy+Gzs67AT+ewP9wFemhiDz GElSFRpeqR+BNXGPddu8NcMI71X8ICvm9F9BES6wcNS3ll5W20DMRPqkd CBUVIqEk/lDQL3E8NoN3ziI0cj4dWgLb02vkJvxWnog9RezTH7PofIq2C Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AwA6h5dX/5hdJa1egnFOgVIGs3OFB?= =?us-ascii?q?YF9hh2BOjgUAQEBAQEBAV0cC4RjeRIBDAFzJwQOBYgxuRkBAQEBAQEEAQEBAQE?= =?us-ascii?q?BAQEfhiqETYobBZNvhUIBgTWNRY8/kCQBHjaDeG6HSn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,425,1464652800"; d="scan'208,217";a="301738570" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2016 15:57:44 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6QFvieE023251 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jul 2016 15:57:44 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 26 Jul 2016 10:57:43 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 26 Jul 2016 10:57:43 -0500 From: "Alvaro Retana (aretana)" To: "spring@ietf.org" Thread-Topic: New spring WG Co-Chair Thread-Index: AQHR51ZxxQXCjmgvAUSvp9CEwwhggA== Date: Tue, 26 Jul 2016 15:57:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D3BD00B2136888aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: John Scudder , Martin Vigoureux , "bruno.decraene@orange.com" Subject: [spring] New spring WG Co-Chair X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 16:08:45 -0000 --_000_D3BD00B2136888aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear spring WG: Due to the demands of his job John has decided to step down as spring Co-Ch= air, a position he has held since the formation of the WG almost 3 years ag= o. John has been instrumental in driving the collaboration with other grou= ps working on spring-related extensions. Thank you!! In consultation with Bruno and the other RTG ADs, we have asked Martin Vigo= ureux to take on the role of spring Co-Chair. Martin is an experienced Cha= ir (he is also the Co-Chair of bess) and will work with Bruno on driving th= e current work items to completion and publication. We expect the transiti= on to be seamless as the WG moves through a period of adoption and WGLCs. = Welcome Martin! Martin can be reached at martin.vigoureux@nokia.com. Thanks! Alvaro. --_000_D3BD00B2136888aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear spring WG:

Due to the demands of his job John has decided to step down as spring = Co-Chair, a position he has held since the formation of the WG almost 3 yea= rs ago.  John has been instrumental in driving the collaboration with = other groups working on spring-related extensions.  Thank you!!

In consultation with Bruno and the other RTG ADs, we have asked Martin= Vigoureux to take on the role of spring Co-Chair.  Martin is an exper= ienced Chair (he is also the Co-Chair of bess) and will work with Bruno on = driving the current work items to completion and publication.  We expect the transition to be seamless as the WG m= oves through a period of adoption and WGLCs.  Welcome Martin!

Martin can be reached at martin.vigoureux@nokia.com.

Thanks!

Alvaro.
--_000_D3BD00B2136888aretanaciscocom_-- From nobody Wed Jul 27 01:02:40 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC5312D5C2 for ; Wed, 27 Jul 2016 01:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bht3oFNoCdFK for ; Wed, 27 Jul 2016 01:02:37 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0103.outbound.protection.outlook.com [104.47.34.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376CC12B024 for ; Wed, 27 Jul 2016 01:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TbuP3RkY7LJLKYLfBI3jq1MVtaZvPqjC3dDMJ1VLd/c=; b=TMkvGyqI4WcWuSdKj5SgpYuXe2mQ0B7A1HIuQPDsFXT8yvMe6eoRxtSvlsTvuKuMErkEyRSC+QmMCB857fXP7ZSan+A0ssSTuOM17qAq8YS+wTGjzH4xPcyizGQAzHpIg56WVc80qUo6ShFjJbuGN9R4LJVDdy4FYjrrvJe5190= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.64.168] (193.110.55.18) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Wed, 27 Jul 2016 08:02:34 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_269FDD2D-6714-4E6D-946C-EA50AFEB126F" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Wed, 27 Jul 2016 10:02:20 +0200 Message-ID: References: To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.110.55.18] X-ClientProxiedBy: DB3PR01CA0077.eurprd01.prod.exchangelabs.com (10.242.133.180) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-Office365-Filtering-Correlation-Id: 01eba28d-222b-4ef4-1d4c-08d3b5f45f21 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 2:L53ScTHidN0BLoNfwWVRUAR7Zy3dZvR0OHNX2tzb3UokEZj9I3UKzJ/pnVdgQewOhikD5WShsH/c36sBTk+hfzlBuAhgutnGZCzjDr7PEoqRO5orHaZTY+ZHURUcnEa/wZXLe0yRr9VZAUqjX8bNEBexa3CXvdAvsn4WOFsMWb9etF49NZgAV4PB9QbotZTg; 3:MUG5eDJAG4p3LMCac0feJo3p1KuPySCaXjgs10Zn2195iOcCfBQtONJw+v7uIN0EaomufD0mHfdLiYbGdyOjnfMrldU6DAM/aQ7dUdrY/PXSZxKNa3frEEFV/5EsLxz+; 25:rhcKtmIJVJP3tUiAoeew82W1vVYc/40sasidYDcYawcb/l8EscU08vGYPdJttHxUY5YU63M5y/rXXmeP/+S5sJrghaJXCGmu+3uR89xGutwAdrzzbWLzw7m4lGi/iayXK69uqTO/dnOCgifr211ggjaMXhyO37W9iCHduCsHGQgxA+C05VvghuWN1JxLWo8EQZccRXmv1wQ88rvqgpNk+tGP5qw3DUs5f48zMPPKK61Bk5PkzxOXPlXBdB8Pdyw43y/pyajZTMPiOumDJiz3tJrSPwoncUbeoLHZQXLP9e9oEe3HXFXd9wZ8Sj93RDJCjWmmHlHaNBy0fcRJVJB5fpzInVAcqYuDIBYAMVbMBiBK1PmzJpJC9NcQp4PSJZ0E437IUXFhSK5LzS6Z9HBMgdH1kDs1oOyw95Rhnhb+6bc=; 31:A50GQbn+hi1NP3raOrjqGm3ibsrxNvtbRbcyASvyd9kYAUDD6qaoe/4Z2E1JJBU9AklWF8YfP7VmI3qRl06kbRZuq6Z7oIAFzu/5vRfN6h8jU61R2arvL5JdAWr9wLFjCJPcDl/11mtW984mwIsmRqtiCvA0lQjiXswdiEvr6CM6BAQbBCZ8DCvM40mewPvKohrsnrmKO+Vr6HqtFSc7rA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 20:w+7P3X+SAokvT47S8v54Ghb1SSoO3W/1dH2toyjkgF4YhfyamyAP5MOUPufMqHANnb+0ZlLS4EOgYka71sSAuE+COMyDN7hXaB3caLyY9a650Pd+whC28F5VpxZ8EU5AVOyvvmYBcSX1Ujw3DNnF89ClR47Qt6E7eQ8cO9YtQB7NPSpq4hKIXDLvz8pXYSL8aOYQBbOEjfYCG6FE68X8hUZnK0SexCWM/YvGw+V4WfZQCyCqu61zzLWk2yJL28ApxkOSdUjdEuZc6VwMQDD67h3MjlpnVEjoNgT/pv7O9KsCLhbakWjoemmb55NF/JVB3kwmvm5aq+s3D5Z//Fhv1l9uUYG9CUZpn5QPcCKdfcJ6DMVMDfAvOb+g9MLvOMk5Vo5NRyWvNId/Pf/vO7X5RtrVKvImog0ZEoWVxoYjDWVeSfkN6OJ+4zS2Ve1ENQ+PHCq9nZF5QrgQO7q5bYU8F8WVn+B11gTnmjwDYV2glCbRohzzPs39EPDdF3haaFcl X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597)(95692535739014)(231250463719595); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 4:6kP+MZiDZTS+zXHu/PcgT9AXimlakq/c8is7KwF7/Hv2UXBRARO+AvJhmO9FC+PufGmeAPqUDuDB9OBMEdeSZSHmbPnNYlZ/RTTIdqLVoBqkNOHeBTcvdl0jTlUly856SiyAqaHs41Fp4EeBdYAB0MmMeeJE67kl8F53MBt9Yf7qp/sj4iigRjcuDbAeK8KIGwWt+KKHlqa9p2OCEBVFu7sCUunwfOi+d25SCNWG0b5gUQNTwhs8oi5BfW5c/ydP0+OpNU5i3UtdFHylyoA40P2eg6XgZEcSNVQegkPZC60LskNrQCi09Qof524bVv9HlIFGr9A3ry21kXMxdzxjdrLV3G9ziZ6tBHf2QaYBMJVo1EdOrTVamBk5ZxGM7J8m6zDP724H0fZwwcx5qUrPQoft4+ItKKkcGMQ6vt5XcdJx0Ih/M2I6dslalUSip+cHKmcCNaV9SZmlwutHJaZgFdCls/R56CCgcqb0lWa5bcScTGvLnFaEIzn7t6HW8boq X-Forefront-PRVS: 0016DEFF96 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(24454002)(199003)(377454003)(53754006)(189002)(260700001)(270700001)(2950100001)(3846002)(4326007)(84326002)(83716003)(76176999)(110136002)(512954002)(105586002)(77096005)(66066001)(2906002)(97736004)(36756003)(69556001)(586003)(6116002)(57306001)(7846002)(92566002)(81166006)(106356001)(19580405001)(19580395003)(7736002)(101416001)(33656002)(189998001)(82746002)(50986999)(8676002)(81156014)(68736007)(42186005)(50226002)(86362001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:[172.29.64.168]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 23:HDFwAATs+Pa6Vrkg2rn0WdQJ2QHRwunfj04KJlXIB?= =?us-ascii?Q?O67AjaXoxr3+6AeqJ4cueLtSkv1MFabbTLKARzWz4aN+w7ew8AysiduP7Vhl?= =?us-ascii?Q?XuusOzumZAZfuizmUlWv/TAUlPPAI8fx+6GynQLtEKV7iYmQOvoQW/IUZhjZ?= =?us-ascii?Q?yur+isy4XpamNrfuNp4qUz6pNIU/DZNXfqzCnb3HZ2fw5Z9t9AcrR3NkLASE?= =?us-ascii?Q?0VaDHzgXz+Uyi2Knap5s1TlhxsO064IHHT5v8i1JRZLbeVPekGHKv9Z6yqc7?= =?us-ascii?Q?WtYYeUfdZd3Njz7nepBKebCE+WzHRSpVAvsYyTLdj4kbaHP9GhYdNRcm9VYE?= =?us-ascii?Q?frGkHJKH1vqjC4h4dmB4ZKNnUDNQifO7ZsoFwoKzn0DW9rSgXnsUWXhvjjQG?= =?us-ascii?Q?QO6w1L+YFVyvk3VwXacw36E7j72buTQ/jo1rCWM/hLYCid4d+Y89ay9VMFys?= =?us-ascii?Q?15RXQWzmGUa1nmXtmw3oszo3kuK9feKhWweWiv3c84HuGi5go6vkIkJobddq?= =?us-ascii?Q?34etpEpGbf8vlse/ecbD5owk3RI4J1GRjEYiFUu+pi4vXiqgAAqXuFGKo7Tu?= =?us-ascii?Q?jjFTBAp2k+4USMnTpPuj+6CdcFiTGhvBIdTCnkOW9mXHw2dd/k9107UOJ2La?= =?us-ascii?Q?84Q0XRUTx/02o4jT43svPrz285f6xjlKsOLT63YE83HsJLxLhTubk4NK8eM1?= =?us-ascii?Q?EThYRQ29aMFofbpwIKONr4hOPh0CW9Tes9GN61vpVnHuy5asWBl8SySAPRiw?= =?us-ascii?Q?TBeYF+07/+CvkIVBL9b0UfQEmReiVnK0LJHyB4ohs+7x4h4f8a3WX8Y/QZPe?= =?us-ascii?Q?/kufa4ynOoSExKzcH4RDVmLyHxn12GNEuht2D96LbEbo0viZbj95E4VDiTK6?= =?us-ascii?Q?u7qAa2v0Kw8BC63QvfSFOHlKCL6cZMVTtacj+SgkBbdZKFZQoWvLCIfj6WCG?= =?us-ascii?Q?0Wu+96dp0LB06+5woOGGIVwqH8BoB8yRERKtGZoy0MvuplDyHGbnRVxQ1gpZ?= =?us-ascii?Q?rRDuV6xBHA4mJvcSHmrxcWZpbp2BNqYQ7f4DEiBxTK2k2q18X8u5wbVqVLwS?= =?us-ascii?Q?L7k/qkJ0J72q28z/f7WZH6fgolV2489fMgY9sJn6WeV+2ZqVUjdaQ4uj+gA+?= =?us-ascii?Q?8Rz8hfzOB8N8iIEpB3+mxsUidPsTKgAP4uh0WLtmS7ie43wfbz2PC3mzhYtK?= =?us-ascii?Q?k2nxLOLyJlPaQ1kLY0snhcwf1dn6wlujnBV?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 6:XfA4g7dbTuVNQR3XuKgsP9V9sb5W6Mv8+yXmb9maODt+z8Qq7hKBaJoPvgEhrLK34BTOBfjfoB6B3KHNIUAYa4fPVubsLYgUDVuCQW9KKOIwxUMwF2iL1JowKcfro8ZLVcCRWQ+bY1pHGJoxJ6eJdu8gbt02hMw7biHYcJ7mlg6ZbRAf0WUL12YPd6+Vjztekh9ZhBoBSgpjaBRE+5cO4+Of8/lAWBiR3p1RAGSBb3MfVJhbs9c7Plp8TbC4Q5V4s+DSMI2hJEjNRwuWqH618jXDyUWMs/DAZq0hXd8MLfa9NJC9r3NyKihgYwdnOF5cLIfJd0fWcksa7fuwHA6/tw==; 5:EK/8GCZaX01kbQ+R6X34DloEn5/1Mc+ejyNo6vJRm67NL1PFFl9o5Dj0vvN06tMprZlsyzD4zsYXpj6kqJffgbG8QCIpARc3quetLV7nZjx0w9La4dxnjrCcINbPUlDlCT+3iCCsw61TldJFJDQBFA==; 24:6NNzgLpzfgbcWBHu19zFCAjSW07W4Wf2V+03zUAzH4o0ixjTsLku0dIm35RJHaxm0K5yK7Q6sPO/rtlZBeYo/CsttC3dMgRy4AvIIUXnFLA=; 7:FmPFaN6LM1YmDXoud/tMbdiozGJjT73yHFxfP8o5/HlHZaJUbWZR9rn629Xe1MO6zDf1fcsaUdWFn29N0yuQ979XDTerJvZ1jXBJoA41LR0ekv7hmpjgLkulvxp1xryU3dimvg6RQS+X/FjAuc64P24zioxyP1DGSdZnfMVC/zTktHh0uDT0fV6b63KRjVa/xmqEod650wHM2TdRMC0iWWzZZmsFHcXbGtK/21cYfdEb9UMYklmJ1jAc15u1yknT SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2016 08:02:34.4430 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" , Martin Vigoureux Subject: Re: [spring] New spring WG Co-Chair X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 08:02:39 -0000 --Apple-Mail=_269FDD2D-6714-4E6D-946C-EA50AFEB126F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Everybody, I'd like to thank everyone for an interesting three years. I'd = particularly like to thank Bruno for being such an outstanding co-chair, = it has been an absolute pleasure to work with him. Martin, welcome and = thanks for your willingness to step up. Regards, --John > On Jul 26, 2016, at 5:57 PM, Alvaro Retana (aretana) = wrote: >=20 > Dear spring WG: >=20 > Due to the demands of his job John has decided to step down as spring = Co-Chair, a position he has held since the formation of the WG almost 3 = years ago. John has been instrumental in driving the collaboration with = other groups working on spring-related extensions. Thank you!! >=20 > In consultation with Bruno and the other RTG ADs, we have asked Martin = Vigoureux to take on the role of spring Co-Chair. Martin is an = experienced Chair (he is also the Co-Chair of bess) and will work with = Bruno on driving the current work items to completion and publication. = We expect the transition to be seamless as the WG moves through a period = of adoption and WGLCs. Welcome Martin! >=20 > Martin can be reached at martin.vigoureux@nokia.com. >=20 > Thanks! >=20 > Alvaro. --Apple-Mail=_269FDD2D-6714-4E6D-946C-EA50AFEB126F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" Hi Everybody,

I'd like to thank everyone for an interesting three years. I'd particularly like to thank Bruno for being such an outstanding co-chair, it has been an absolute pleasure to work with him. Martin, welcome and thanks for your willingness to step up.

Regards,

--John

On Jul 26, 2016, at 5:57 PM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

Dear spring WG:

Due to the demands of his job John has decided to step down as spring Co-Chair, a position he has held since the formation of the WG almost 3 years ago.  John has been instrumental in driving the collaboration with other groups working on spring-related extensions.  Thank you!!

In consultation with Bruno and the other RTG ADs, we have asked Martin Vigoureux to take on the role of spring Co-Chair.  Martin is an experienced Chair (he is also the Co-Chair of bess) and will work with Bruno on driving the current work items to completion and publication.  We expect the transition to be seamless as the WG moves through a period of adoption and WGLCs.  Welcome Martin!

Martin can be reached at martin.vigoureux@nokia.com.

Thanks!

Alvaro.

--Apple-Mail=_269FDD2D-6714-4E6D-946C-EA50AFEB126F-- From nobody Wed Jul 27 01:04:52 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6012D5C2 for ; Wed, 27 Jul 2016 01:04:51 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuT33y0ElvhB for ; Wed, 27 Jul 2016 01:04:50 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C544C12B024 for ; Wed, 27 Jul 2016 01:04:49 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id q128so29441627wma.1 for ; Wed, 27 Jul 2016 01:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=frVbvNfIxsPuVnJgbziy+ufvNLLakwGFzgF9k5RdMKo=; b=iE5sCR3aXkIeGkghNW9nbjw7R4VE4NA0BWr0z16qi8vOzSZOd3BtZjmkSLCDFIGkLx 7hfgaFGbNsYhdneewgD2SEyf3L7ITEe1a3AtkC1+OOl+olv+APCVWSEaZFpkHDpnOEmt fDgZ1sPMv8Ah2Ltd5ZyPSKRfog1ZCQHt57vOPRDhkF9NApcasNzavNAkVg0A/QjIl7+g ziJKnfg/RZMccnzqNtSromTKhaFO1HwQJ1pSxxLEFtEjlhLThCuWNy0yX9Kv8pcEHRBl XwHyvnvJQnAYga0lnH18m4VC2qDLkOFFr3GgpcKovogQRxQ3jfho79i5HVTqo2Cg1fbF BxBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=frVbvNfIxsPuVnJgbziy+ufvNLLakwGFzgF9k5RdMKo=; b=GF9raP5xyOsD1xyb3s1m4YytKhVAOHzyoPI9qBdPk/g3xkWvS6pZT4W29QFBytD1Qx NEhs1f9OTnquZExlsdPS0+DBZN6bH1Pe7tt6THrgp47OeRmEl7hdMW/le1VGr7jIaqFY k4SQmSCli005Btjg2pmaVWyB1zSuhlY5ZhZSpFcyYoEdc953B3ASz8NG0HHmVAna7Z98 GV8KZ4CQpdLxKxVwso4+FSV6DqrggCdoVwdM+DTMGmlZsxKoo26qEP591Zs1f3x2dvrs /5ZJE64JXLQjHF+61I3UxR8FS3tGLxOM3M4cOEOf71bxQUF0R+EtlfDrG5o588AEZGb6 oK2A== X-Gm-Message-State: AEkoouvVdqYZhqXuGu/P4k41SfaG7GkPpu+bsM7ndNhNlgKxP+YlPkazrSSNSodtRG8OOQ== X-Received: by 10.194.149.176 with SMTP id ub16mr25704877wjb.54.1469606688202; Wed, 27 Jul 2016 01:04:48 -0700 (PDT) Received: from [172.28.5.93] ([195.238.226.2]) by smtp.gmail.com with ESMTPSA id g67sm5770817wme.5.2016.07.27.01.04.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jul 2016 01:04:47 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.17.0.160611 Date: Wed, 27 Jul 2016 01:04:46 -0700 From: Jeff Tantsura To: "Alvaro Retana (aretana)" , "spring@ietf.org" Message-ID: Thread-Topic: [spring] New spring WG Co-Chair Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3552426287_776390057" Archived-At: Cc: John Scudder , Martin Vigoureux , "bruno.decraene@orange.com" Subject: Re: [spring] New spring WG Co-Chair X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 08:04:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3552426287_776390057 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Thanks John Welcome Martin Cheers, Jeff From: spring on behalf of Alvaro Retana Date: Tuesday, July 26, 2016 at 08:57 To: "spring@ietf.org" Cc: John Scudder , Martin Vigoureux , "bruno.decraene@orange.com" Subject: [spring] New spring WG Co-Chair Dear spring WG: Due to the demands of his job John has decided to step down as spring Co-Chair, a position he has held since the formation of the WG almost 3 years ago. John has been instrumental in driving the collaboration with other groups working on spring-related extensions. Thank you!! In consultation with Bruno and the other RTG ADs, we have asked Martin Vigoureux to take on the role of spring Co-Chair. Martin is an experienced Chair (he is also the Co-Chair of bess) and will work with Bruno on driving the current work items to completion and publication. We expect the transition to be seamless as the WG moves through a period of adoption and WGLCs. Welcome Martin! Martin can be reached at martin.vigoureux@nokia.com. Thanks! Alvaro. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --B_3552426287_776390057 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Thanks John

<= span style=3D'font-size:11.0pt;font-family:Calibri'>Welcome Martin<= /span>

 

Cheers,

Jeff

 

 

From: s= pring <spring-bounces@ietf.org> on behalf of Alvaro Retana <aretana= @cisco.com>
Date: Tuesday, July 26, 2016 at 08:57
To: "spring@ietf.org" <spring@ietf.org>
Cc: John Scud= der <jgs@juniper.net>, Martin Vigoureux <martin.vigoureux@nokia.com= >, "bruno.decraene@orange.com" <bruno.decraene@orange.com>= ;
Subject: [spring] New spring WG Co-Chair

 

<= p class=3DMsoNormal>Dear spring WG:

 =

Due to the demands of his job John has decided t= o step down as spring Co-Chair, a position he has held since the formation o= f the WG almost 3 years ago.  John has been instrumental in driving the= collaboration with other groups working on spring-related extensions.  = ;Thank you!!

 <= /p>

In consultation with Bruno and the other RTG ADs, we hav= e asked Martin Vigoureux to take on the role of spring Co-Chair.  Marti= n is an experienced Chair (he is also the Co-Chair of bess) and will work wi= th Bruno on driving the current work items to completion and publication. &n= bsp;We expect the transition to be seamless as the WG moves through a period= of adoption and WGLCs.  Welcome Martin!

 

Martin can be reached a= t martin.vigoureux@nokia.com.

 

Thanks!

 

Alvaro.=

____________________________= ___________________ spring mailing list spring@ietf.org https://www.ietf.org= /mailman/listinfo/spring

--B_3552426287_776390057-- From nobody Wed Jul 27 01:49:48 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5917912D675 for ; Wed, 27 Jul 2016 01:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-uvfFjdNnmX for ; Wed, 27 Jul 2016 01:49:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098F212D674 for ; Wed, 27 Jul 2016 01:49:44 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9419026446E; Wed, 27 Jul 2016 10:49:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 68D6E35C045; Wed, 27 Jul 2016 10:49:42 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0301.000; Wed, 27 Jul 2016 10:49:42 +0200 From: To: "spring@ietf.org" , John Scudder Thread-Topic: New spring WG Co-Chair Thread-Index: AQHR51ZxxQXCjmgvAUSvp9CEwwhggKAr7etQ Date: Wed, 27 Jul 2016 08:49:41 +0000 Message-ID: <26881_1469609382_579875A6_26881_308_1_53C29892C857584299CBF5D05346208A0F96A063@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F96A063OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "Alvaro Retana \(aretana\)" , Martin Vigoureux Subject: Re: [spring] New spring WG Co-Chair X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 08:49:46 -0000 --_000_53C29892C857584299CBF5D05346208A0F96A063OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had the opportunity to work with John for a little more than a year now a= nd that has been a great pleasure for me. I'd like to thank John for this. Thanks also for the welcoming and mentorin= g me on this new role. And welcome Martin. --Bruno From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Tuesday, July 26, 2016 5:58 PM To: spring@ietf.org Cc: John Scudder; Martin Vigoureux; DECRAENE Bruno IMT/OLN Subject: New spring WG Co-Chair Dear spring WG: Due to the demands of his job John has decided to step down as spring Co-Ch= air, a position he has held since the formation of the WG almost 3 years ag= o. John has been instrumental in driving the collaboration with other grou= ps working on spring-related extensions. Thank you!! In consultation with Bruno and the other RTG ADs, we have asked Martin Vigo= ureux to take on the role of spring Co-Chair. Martin is an experienced Cha= ir (he is also the Co-Chair of bess) and will work with Bruno on driving th= e current work items to completion and publication. We expect the transiti= on to be seamless as the WG moves through a period of adoption and WGLCs. = Welcome Martin! Martin can be reached at martin.vigoureux@nokia.com. Thanks! Alvaro. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F96A063OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I had the = opportunity to work with John for a little more than a year now and that ha= s been a great pleasure for me.

I’d = like to thank John for this. Thanks also for the welcoming and mentoring me= on this new role.

 = ;

And welcom= e Martin.

 = ;

--Bruno

 = ;

From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]
Sent: Tuesday, July 26, 2016 5:58 PM
To: spring@ietf.org
Cc: John Scudder; Martin Vigoureux; DECRAENE Bruno IMT/OLN
Subject: New spring WG Co-Chair

 

Dear spring WG:<= /span>

 

Due to the demands of his j= ob John has decided to step down as spring Co-Chair, a position he has held= since the formation of the WG almost 3 years ago.  John has been instrumental in driving the collaboration with other groups worki= ng on spring-related extensions.  Thank you!!

 

In consultation with Bruno = and the other RTG ADs, we have asked Martin Vigoureux to take on the role o= f spring Co-Chair.  Martin is an experienced Chair (he is also the Co-Chair of bess) and will work with Bruno on driving the current= work items to completion and publication.  We expect the transition t= o be seamless as the WG moves through a period of adoption and WGLCs.  = ;Welcome Martin!

 

Martin can b= e reached at martin.vigoureux@nokia.com.

 <= /o:p>

Thanks!

 

Alvaro. 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F96A063OPEXCLILM21corp_-- From nobody Thu Jul 28 05:32:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D987412DFA9 for ; Thu, 28 Jul 2016 05:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.905 X-Spam-Level: X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kSoBDGGF8sJ for ; Thu, 28 Jul 2016 05:32:40 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC1812D875 for ; Thu, 28 Jul 2016 05:32:39 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id AEC97C0369 for ; Thu, 28 Jul 2016 14:32:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 8A3C71A0057 for ; Thu, 28 Jul 2016 14:32:37 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0301.000; Thu, 28 Jul 2016 14:32:37 +0200 From: To: "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution-01 Thread-Index: AdHot+ZF4nnsg2p6SaWRxTCBzjp3Yw== Date: Thu, 28 Jul 2016 12:32:36 +0000 Message-ID: <7486_1469709157_5799FB65_7486_4559_1_53C29892C857584299CBF5D05346208A0F96DE85@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F96DE85OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] draft-ietf-spring-conflict-resolution-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 12:32:42 -0000 --_000_53C29892C857584299CBF5D05346208A0F96DE85OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Les, authors, As an individual contributor. Many thanks for the good slides presented in Berlin. Please find below some proposed comments. My email object may be misleading as I'm actually commenting on the slides,= as the draft doesn't reflect the slides https://www.ietf.org/proceedings/96/slides/slides-96-spring-4.pdf S16, Ignore Overlap only, :s/(192.0.2.51/32,52,48)/(192.0.2.51/32,52,49) :s/(192.0.2.0/32,1,52)/(192.0.2.0/32,1,51) :s/Active Policy (98)/Active Policy (99) :s/Excluded Entries (2)/Excluded Entries (1) S17, Ignore Overlap only, Excluded entries :s/(192.0.2.1/32, 101, 51)/(192.0.2.1/32, 101, 50) S18, Quarantine, Excluded entries :s/(192.0.2.0/32, 1, 100)/(192.0.2.0/32, 101, 100) S21, Quarantine & Ignore Overlap Only :s/Active Policy (100)/Active Policy (99) :s/Excluded Entries (0)/Excluded Entries (1) (because 192.0.2.100 has no SID) S23, Quarantine, Excluded entries :s/(192.0.2.0/32, 1, 100)/(192.0.2.0/32, 101, 100) S23, Ignore overlap only, Advertisements "(SRMS, 192.0.2.1/32, 101,100)" 101 was meant to be in red. S24, Summary to be updated as per above. Thanks, Regards, --Bruno ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F96DE85OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Les, authors,

 

As an individual contributor.

 

Many thanks for the good slides= presented in Berlin.

 

Please find below some proposed= comments.

 

My email object may be misleadi= ng as I’m actually commenting on the slides, as the draft doesn’= ;t reflect the slides

https://www.ietf.org/proceed= ings/96/slides/slides-96-spring-4.pdf

 

 

S16, Ignore Overlap only,<= /o:p>

:s/(192.0.2.51/32,52,48)/(192.0= .2.51/32,52,49)

:s/(192.0.2.0/32,1,52)/(192.0.2= .0/32,1,51)

:s/Active Policy (98)/Active Po= licy (99)

:s/Excluded Entries (2)/Exclude= d Entries (1)

 

S17, Ignore Overlap only, Exclu= ded entries

:s/(192.0.2.1/32, 101, 51)/(192= .0.2.1/32, 101, 50)

 

S18, Quarantine, Excluded entri= es

:s/(192.0.2.0/32, 1, 100)/(192.= 0.2.0/32, 101, 100)

 

S21, Quarantine & Ignore Ov= erlap Only

:s/Active Policy (100)/Active P= olicy (99)

:s/Excluded Entries (0)/Exclude= d Entries (1)

 

(because 192.0.2.100 has no SID= )

 

S23, Quarantine, Excluded entri= es

:s/(192.0.2.0/32, 1, 100)/(192.= 0.2.0/32, 101, 100)

 

S23, Ignore overlap only, Adver= tisements

"(SRMS, 192.0.2.1/32, 101,= 100)"

101 was meant to be in red.

 

S24,

Summary to be updated as per ab= ove.

 

Thanks,

Regards,

--Bruno

 

 

 

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F96DE85OPEXCLILM21corp_-- From nobody Thu Jul 28 05:36:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26C712DFAE for ; Thu, 28 Jul 2016 05:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSzxw6Z6fkW4 for ; Thu, 28 Jul 2016 05:36:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659A312DFAD for ; Thu, 28 Jul 2016 05:36:04 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9D7C9324776; Thu, 28 Jul 2016 14:36:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.59]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 62DBC238095; Thu, 28 Jul 2016 14:36:02 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0301.000; Thu, 28 Jul 2016 14:36:02 +0200 From: To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Preference Rule Thread-Index: AQHR4/dRo2CSgzyhlUO9c2QH7vwVRaAtxJ2A Date: Thu, 28 Jul 2016 12:36:01 +0000 Message-ID: <30779_1469709362_5799FC32_30779_217_1_53C29892C857584299CBF5D05346208A0F96DEB2@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> <0039f4f2-e09a-f61c-6089-9a488d8bf2da@nic.dtag.de> In-Reply-To: <0039f4f2-e09a-f61c-6089-9a488d8bf2da@nic.dtag.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: Martin Horneffer , "Horneffer, Martin" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Preference Rule X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 12:36:07 -0000 Hi Les, all As an individual contributor. As a network operator, I have a slight preference for the older preference = rule, and more specifically for the following preference rule: 1) PFX source wins over SRMS source 2) Between redundant SRMS, operator defined preference (aka weight) Note however, that for me, this is a lighter preference compared to the cho= ice of the policy. Besides, my above preference assumes that the policy "Pe= r FEC/Ignore overlap only" be selected. If "Quarantine" were selected, I wo= uld have a strong preference for the revised preference rule (Larger range = wins) in order to limit the consequences on the network availability. Regarding 1, I would assume that before the conflicting advertisement, the network was r= unning fine. i.e. conflict entries is not the nominal behavior in the netwo= rk, and conflict are detected and reported to the network operator for corr= ection. (e.g. via the yang model, syslog, error message on the terminal (he= nce in particular the one configuring the conflicting entry...). With such assumption, the conflict is likely the result of a misconfigurati= on on one node. Preferring PFX source over SRMS give preference to diversit= y/the majority of the nodes rather than the individual (mapping server). In= this assumption where a single node is misconfigured, preference many adve= rtisement over a single one, maximize the number of valid advertisement kep= t. I agree that this is dependent on the assumption, and another scenario c= ould be that one had mis-program the script configuring the prefix SID on N= routers, which would results in N simultaneous misconfigurations. Additionally, following the principle that the one speaking for himself is = probably the best source, I'd be inclined to trust the originator of the IP= prefix, as the reference for the SID to be used. Regarding 2, Some network operation people have expressed a need to control which advert= isement is preferred, especially to control SID renumbering (e.g. in case = of network merge). cf St=E9phane email. Putting this preference lower (e.g.= after preferring the larger range) would somewhat defeat the goal or make = it less predictable for people. Regards, --Bruno > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Horneff= er > Sent: Friday, July 22, 2016 10:59 AM > To: Les Ginsberg (ginsberg); spring@ietf.org > Cc: Horneffer, Martin > Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Rule >=20 > Hi Les, >=20 > this topic, and this document is in my eyes a very important one. Thanks > a lot for writing and promoting it! >=20 > During the Berlin WG session you proposed a new preference rule which > would make the policy choice easier. You asked for a discussion on the > list - more on your slides rather than the existing draft document. >=20 > As an operator, and as an individual that has insight in more than just > one or two IP/MPLS carrier networks, that has the main engineering > responsibility for a rather large backbone, and that stays in actual > contact with the operational staff and security authorities, I strongly > ask you: PLEASE DO NOT CHANGE THE PREFERENCE RULE! >=20 > The first two elements of the preference rule are, in my eyes, the most > important ones of the whole document and must not be changed or dropped! > 1) PFX source wins over SRMS soucre > 2) Smaller range wins >=20 > Why is this so important? >=20 > I don't care so much about the _amount_ of traffic that would be > affected by a conflict. No amount of traffic lost due to a network > design or configuration error is permissible. But I do care about the > overall _robustness_ and _security_ of the network. >=20 > Of course - in terms of security a first approximation would say that > segment routing plays within the IGP only, and that the IGP needs to be > trusted anyways. It must be secured against the outside. While this is > true, I nevertheless would like to differentiate a bit more. >=20 > For the sake of robustness, and possibly also for security, I would like > to apply the following guidelines: > a) Effects of local misconfiguration should be as local as possible. > b) The more reliable and controllable source should win over a less > reliable or controllable one. >=20 > As I see it, both guidelines lead to a clear preference of PFX sources > over SRMS sources. Also the preference for smaller ranges seems to fit. >=20 > Please do consider environments where more and more formely separate > IP/MPLS networks get merged into a single IGP domain. I am seeing this a > lot since a couple of years - several times within DT, but also at other > carriers. Sometimes this is done as a complete merge e.g. into a single > IS-IS area, sometimes different areas are used, and sometimes seperate > IGP instances are maintained but connected. While redistributing from > one IGP area or instance to the other you can do more or less filtering, > but it definitely is being done. Thus, even within the IGP filters and > policies are being applied - be it for the sake of security or > scalability. While there are well-known mechanisms and tools to filter > and control prefix redistribution, I am not so sure about SRMS. >=20 >=20 > I'm going to also write my opinion about the policy selection, but > keeping the preference rule really is my main concern. >=20 >=20 > BR, > Martin >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ 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. From nobody Thu Jul 28 05:36:25 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6216812DFB2 for ; Thu, 28 Jul 2016 05:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P6VnpELAduQ for ; Thu, 28 Jul 2016 05:36:04 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6492712D825 for ; Thu, 28 Jul 2016 05:36:03 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id CE16F20507; Thu, 28 Jul 2016 14:36:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7A9F91C0088; Thu, 28 Jul 2016 14:36:01 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0301.000; Thu, 28 Jul 2016 14:36:01 +0200 From: To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Policy Thread-Index: AQHR4/ep1y4Cq3qarkqMhY6b0lS9waAtvyWw Date: Thu, 28 Jul 2016 12:36:00 +0000 Message-ID: <10229_1469709361_5799FC31_10229_1397_4_53C29892C857584299CBF5D05346208A0F96DEAA@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6031_1467634025_577A5168_6031_4091_1_53C29892C857584299CBF5D05346208A0F92A129@OPEXCLILM21.corporate.adroot.infra.ftgroup> <91fcbdba712143e890609f6a513f8528@XCH-ALN-001.cisco.com> <2921_1467708583_577B74A7_2921_256_5_53C29892C857584299CBF5D05346208A0F92B91D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <73326a2e-90d2-1af8-689c-0cc08f396ad6@nic.dtag.de> In-Reply-To: <73326a2e-90d2-1af8-689c-0cc08f396ad6@nic.dtag.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F96DEAAOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: Martin Horneffer , "Horneffer, Martin" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 12:36:10 -0000 --_000_53C29892C857584299CBF5D05346208A0F96DEAAOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, all As an individual contributor. As a network operator, I have a significant preference for the per FEC/Igno= re overlap only policy as it constrains the conflict (resolution) to only t= he prefix/SID in conflict; compared to the per advertisement/quarantine pol= icy which increase it to a full advertisement. As a consequence, the quaran= tine policy starts the conflict resolution procedure by increasing (the sco= pe of) the problem, which is not the right direction. More specifically, with per FEC, the conflict is constrained to the interse= ction of both mapping entries, while with quarantine the conflict is increa= sed to one full mapping entry. (quantitative difference will be example spe= cific, and typically dependent on the size of the mapping server advertisem= ent) Additionally, but much less importantly to me, the quarantine policy has pr= obably a high risk of constraining the Preference rule to the revised prefe= rence rule (i.e. selecting the winning entry based on its larger range). Mo= re on this in the next email. (as Martin (*) has initiated 2 threads on tho= se 2 subjects). Thanks, Regards --Bruno (*) Looks like we'll also have to handle conflict on names. Here I meant Ma= rtin Horneffer. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Horneffer Sent: Friday, July 22, 2016 11:02 AM To: Les Ginsberg (ginsberg); spring@ietf.org Cc: Horneffer, Martin Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Hi Les, commenting rather on your presentation at the Berlin WG session: In general I don't consider it a big deal whether the Quarantine or the Ign= ore Overlap policy is being used. It's mainly important that _one_ of then = finally gets chosen and consistently implemented. >From the operator's point of view I tend to agree with other operators that= the Ignore Overlap policy looks better for most realistic cases, even thou= gh less worried about the amount of traffic lost, but more about robustness= and security aspects. Complexity of implementation, however, can be a serious argument against it= , as this also works against robustness and security. Nobody doubts that the Ignore Overlap policy is more complex. But how much = complexity it really adds is hard to estimate for me. Is it a minor complic= ation or a big one? So far I have seen one vendor talk against the Ignore Overlap policy and tw= o vendors taking a position in favor of it. Sounds to me like 2:1 for Ignore Overlap so far. But we actually don't beli= eve in voting and need more vendor input anyways! BR, Martin Am 05.07.16 um 19:25 schrieb Les Ginsberg (ginsberg): Bruno - Two comments: 1)As we both can come up with examples where a given preference algorithm = will result in "better" behavior than another, continuing to debate which o= ne is "best" has no end. The answer depends upon what types of errors are i= ntroduced in the configuration and that isn't predictable. If it is necessa= ry for us to agree on which algorithm is "best" I doubt that consensus will= ever be reached. It therefore is more important to me to focus on implemen= tation complexity and the importance of identifying and correcting misconfi= gurations ASAP. 2)There are two logical databases that an implementation has to support. On= e of them is the set of received advertisements which can include entries w= ith a variety of ranges. The second one is the set of mapping entries which= are in use for lookups. Your discussion of your "per FEC algorithm" below defines the second datab= ase as a set of entries all of which have a range of 1. Whether this is goo= d implementation model or not I am not commenting on here. But this does no= t eliminate the need to maintain the first database - and to be able to ass= ociate entries in the second database with the corresponding received entry= from which they may have been derived. There is work in maintaining that r= elationship which does not directly bear on the lookup for a given SID but = still has to be done if one uses "per FEC" or "Ignore Overlap Only". This w= ork is not required for the "per range" or "Quarantine" algorithm. It is th= is additional work that I refer to when I say that "per FEC" has a higher i= mplementation cost/complexity. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Tuesday, July 05, 2016 1:50 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 05, 2016 9:08 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - Consider the following simple case: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2: (SRMS, 1.1.1.1/32, 200, 10, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) There is a misconfiguration here, but we don't know what was really intende= d. A few (of many) possibilities: ERROR #1: Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !St= arting SID error ERROR #2: Entry #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Sta= rting prefix error The draft defines two candidate preference rules which could be applied: Quarantine ---------------- As we evaluate prefix conflicts first, we compare Entry #1 and Entry #2 and= choose Entry #1 the winner (source is PFX). Entry #2 is then not used (qua= rantined) and the set of active entries is: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #3: (SRMS, 2.2.2.2/32, 200, 10. 0, 0) Ignore Conflict Only ------------------------- In this case we split Entry #2 into two derived entries: Entry #2A: (SRMS, 1.1.1.1/32, 200, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry 2A is then ignored and we then have to evaluate SID conflicts between= the derived entry 2B and Entry #3. For this we have to split Entry 3 into= two derived entries: Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Entry #3B: (SRMS, 2.2.2.3/32, 201, 9. 0, 0) Entry 2B wins over entry 3B since it has a smaller range. Active entries are then: Entry #1: (PFX, 1.1.1.1/32, 100, 1, 0,0) Entry #2B: (SRMS, 1.1.1.2/32, 201, 9, 0,0) Entry #3A: (SRMS, 2.2.2.2/32, 200, 1. 0, 0) Note that in this example both preference rules result in 11 destinations h= aving non-conflicting SIDs. [Bruno] Yes. The important part is =AB in this example =BB. Now do we agree= that in average, Quarantine will result in dropping more destinations than= Ignore conflict only? Now, which of these maximizes delivery of traffic? The answer to that depe= nds upon the type of configuration error that was made. If Error #1 was made, there is no way to differentiate the two preference r= ules. However, if Error #2 was made, then Quarantine is clearly better because th= e destinations 1.1.1.2 - 1.1.1.10 were never intended to have assigned SIDs= and may not even exist as destinations in the network, yet "Ignore Conflic= t Only" favors those prefixes. The point I am trying to make is that it is incorrect to say "If we maximiz= e the number of advertised entries which we use we will always do a better = job of delivering traffic." This example illustrates that this isn't always= true. [Bruno] OK. Clearly, we can find an example where an algorithm is better th= an the other. After all, we all agree that there has been a configuration e= rror. There are 2 points: a) how many destination you keep using b) in case of conflict which of the entries you select I agree that "b" is more or less random and hence there are many cases wher= e we'll pick the wrong one. Yet, we try to make reasonable choices. That th= e point of discussing the preference algorithm (3.2.4). (Although it's very= easy to argue that we can make the wrong choice, I don't feel that's a rea= son not to try discussing it and make choice. e.g. "PFX source wins over SR= MS source" is one: we give preference to SR nodes rather than LDP nodes. Regarding a, I feel that maximizing the number of destinations kept, is lik= ely to give the best result in average. I don't have a proof, but it feel l= ike playing loto: even if each choice is random ("b"), the more you try ("a= ") the better your chances. A few more comments inline. From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Monday, July 04, 2016 5:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, July 01, 2016 3:12 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I don't find your representation complete as regards all of the attributes = which are proposed to be used by the conflict resolution algorithm - so it = is therefore hard for me to use/understand this representation when applyin= g the defined preference rule. This is true for me even after reading your explanations below. But it is far more important to have a common understanding of the algorith= m proposal than it is to be arguing over whose encoding is "better". If the= encoding in the draft is not clear or could use improvement, I welcome you= r feedback. As far as your "pseudo-code": - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID The fact that you can represent an algorithm in a few lines does not mean t= he implementation of the algorithm is just as simple. [Bruno] Sure. But if we want to compare implementation complexity, we'll ne= ed to agree on how much we want to go into details, in order to have meanin= gful comparison. So far this is not clear to me as you sometimes argue that= data structure is implementation specific and you don't want to go into th= is (which I agree) and sometime you detail the data structure. There is also the option to consider this as "implementation issue" and let= this to implementations. Coming back to my per FEC algo, all what is required from the data structur= e, is a way/API to get the data back, though 2 keys: get me the SID matchin= g prefix P1 (for the first line), get me the prefixes matching the SID SIDi= for the second line. That seem like a reasonable requirement on the data s= tructure, and any option in your draft also requires this to detect prefix = conflict and SID conflict (since this is all my per FEC algo is doing in th= ese 2 first lines). Going into more details, my per FEC algo only requires to detail that one p= refix or SID belong to a range (of prefix or SID) while your per range algo= requires to compute range intersection which is harder. So the API to fetc= h the data can only be easier. [Les:] Range intersection is easy to compute - the algorithm is present in = the draft at the end of Section 3.1.1. [Bruno] In order to have a meaningful discussion, we need to define the lev= el of details that we want to take into account, because you're not using t= he same one to discuss your algo and mine. 1) As a first level of comparison, using the description at the end of sect= ion 3.1.1 as a model, for range prefix conflict your algo is: 1)(T1 =3D=3D T2) && (A1 =3D=3D A2) 2)P1 <=3D P2 3)The prefixes are in the same address family. 2)L1 =3D=3D L2 3)(P1e >=3D P2) && ((S1 + (P2 - P1)) !=3D S2) So for (FEC) prefix conflict my algo is: 1)(T1 =3D=3D T2) && (A1 =3D=3D A2) 2)P1 =3D P2 3)The prefixes are in the same address family. 2)L1 =3D=3D L2 (BTW, in the draft, there is a typo in the numbering) It looks clear that FEC comparison is easier than prefix range intersection. 2) Going deeper, at the algo complexity The FEC algo needs: get_SIDs(Prefix), and all the work is done. So all the = algo complexity is coming from the datastructure. It seems pretty reasonabl= e to find a datastructure << o(n) (e.g. a tree, but you will be much better= than me in finding one) For the range algo, it's not clear to me that a data structure can be found= to automatically find the result. If not, the algo seems to compare all en= tries two by two, which would get o(n*(n-1)...(2)) i.e. o(n!) Consider what needs to be done to implement "Find all SIDi advertised for the prefix P1" In its simplest form, we have a list of all SID advertisements (PFX and SRM= S) that we have received. One could imagine walking all the entries, lookin= g to see if the prefix of interest is present within the advertised range. = But, of course, at large scale such an approach is extremely inefficient - = so we immediately start considering ways to improve performance. Inserting = received entries into an ordered tree of some kind is an obvious way to imp= rove performance. When one further considers that calculating conflict reso= lution only needs to be done when a change to the received database occurs = (which post startup is infrequent) it becomes very attractive to cache the = "winning entries" so that if one wants to retrieve the SID for a given pref= ix we only have to examine a subset of the total database - ignoring the lo= sers. [Bruno] I agree that the per range algo (ignore overlap only) will be able = to ignore the losers but at the cost of a more complex algo and at the cost= of creating new derived entries. It's not clear to me if the net result is= positive. Plus I would expect that the number of conflit is small compared= to the number of prefix /SID so this looks like a second order optimizatio= n. In this context, we can appreciate the difference between the three propose= d algorithms. In particular comparing "Quarantine" with "ignore overlap onl= y", a key difference is that "Quarantine" only needs to determine whether a= received entry is a winning entry or a losing entry. "Ignore overlap only"= has to be capable of breaking received entries with ranges > 1 into multip= le "derived" entries (some winning, some losing), which means we now need t= o track the "derived entries" against the original received entry so that i= f the received entry is updated/deleted we can find all the derived entries= and delete/regenerate the derived entries as needed. This is what adds com= plexity. [Bruno] and that it why the per FEC algo seems easier. So it would seem useful to add it in the draft so that we can all discuss i= t. [Les:] Ignore overlap only is the same as per FEC. We may use different wor= ds to describe it, but the end behavior is the same. [Bruno] good if this get the same result. Yet the algo is different. -- Bruno Les All proposed algorithms can be implemented, but it does seem prudent to con= sider implementation complexity as part of our decision process - and the d= iscussion/examples in Section 3 are meant to help in doing this. It is worthwhile restating that when conflicts are present we cannot guaran= tee that forwarding will work correctly no matter what algorithm is used. [Bruno] I'm not sure to see what you have in mind exactly. Can you elaborat= e? To me consistency seem enough. The more complex the implementation the more likely it is that bugs will b= e present and the more likely it is that interoperability issues will arise= . Whether these costs/risks are worth the "value add" when the outcome cann= ot be guaranteed to be correct - only guaranteed to be consistent - is an i= mportant consideration. Also important to remember that conflicts MUST be eliminated by correcting = the misconfigurations that caused them - so conflict resolution is really o= nly an interim measure until the corrections can be made. [Bruno] By "interim" we are at minimum talking about 10s of minutes, if not= more than 1 hour since identifying the root cause may not be obvious. The = impact is very significant on the network. The "Quarantine" algo has the potential to kill 100s PE and 1000s of VPN cu= stomers, so a single configuration change on a unrelated router which may n= ot even be in production (i.e. where configuration checks and operations ho= urs may be relaxed) No one should be lulled into thinking that because we have conflict resolut= ion deployed that correcting the configuration when conflicts are detected = is not a priority. [Bruno] I could not agree more that conflict needs to be identified and fix= ed. Note that I'm the one having asked for defining YANG notifications to r= eport this. You are welcomed to state in the draft that conflicts needs to be reported = to the network operator, in particular though yang notification, and other = existing means. Plus that network operator needs to fixed them ASAP (but st= ill carefully) Thanks --Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:00 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. [Bruno] I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there w= as a way to make progress by asking clarification questions on the points w= hich were not clear, or at least explicitly refusing to consider the email. I also note that what bothered you in my representation was my addition of = the type of advertisement (prefix or MS). But you finally have just added i= n the latest version of the draft "Src- PFX or SRMS" . So there was probabl= y a way to communicate. Besides the algo did not use any specification representation, just names. = So I'll copy/paste it below, please ask clarification questions for the par= ts which are not clear enough. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, for P1, we get a list of (SIDi, Pij) Get the best (SIDi, Pij) as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? [Bruno] - MS/prefix SID is the type of advertisement. In your new version, you call= it SRMS/PFX. - SID is the SID found in the Mapping Entrie - Rx is the loopback (prefix) or router Rx So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and= means: For prefix R2, we found a MS mapping entries advertising SID2 for t= his prefix, and then I found a MS mapping entries advertising prefix R2 for= SID2. Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . [Bruno] I agree that since the above algo used 2 mapping entries to provide= s the (SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted.= That being said, this is not important for this discussion. Let's just con= sidered that their exist a preference algorithm, which takes as input a lis= t of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition = of "best" is not pertinent) ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. [Bruno] Indeed, this is my expectation. But I would need someone's review t= o confirm this. But the difference is that the proposed algo is simple (2 lines of pseudo c= ode), with very modest resquirement data structure use to store the mapping= entries. Indeed, all it needs is a function returning the list of mapping = entries associated/matching a given prefix. And function returning the list= of mapping entries associated/matching a given SID. In particular, there is no need for splitting mapping entries which is the = main complexity of your proposed "Preference algorithm/ignore overlap only"= . (according to your own text). -- Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy. I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F96DEAAOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,= all

&n= bsp;

As an i= ndividual contributor.

&n= bsp;

As a ne= twork operator, I have a significant preference for the per FEC/Ignore over= lap only policy as it constrains the conflict (resolution) to only the pref= ix/SID in conflict; compared to the per advertisement/quarantine policy which increase it to a full advertisement.= As a consequence, the quarantine policy starts the conflict resolution pro= cedure by increasing (the scope of) the problem, which is not the right dir= ection.

More sp= ecifically, with per FEC, the conflict is constrained to the intersection o= f both mapping entries, while with quarantine the conflict is increased to = one full mapping entry. (quantitative difference will be example specific, and typically dependent on the size o= f the mapping server advertisement)

&n= bsp;

Additio= nally, but much less importantly to me, the quarantine policy has probably = a high risk of constraining the Preference rule to the revised preference r= ule (i.e. selecting the winning entry based on its larger range). More on this in the next email. (as Martin (*)= has initiated 2 threads on those 2 subjects).

&n= bsp;

Thanks,=

Regards=

--Bruno=

&n= bsp;

(*) Loo= ks like we’ll also have to handle conflict on names. Here I meant Mar= tin Horneffer.

&n= bsp;

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Horneffer
Sent: Friday, July 22, 2016 11:02 AM
To: Les Ginsberg (ginsberg); spring@ietf.org
Cc: Horneffer, Martin
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Hi Les,

commenting rather on your presentation at the Berlin WG session:

In general I don't consider it a big deal whether the Quarantine or the Ign= ore Overlap policy is being used. It's mainly important that _one_ of then = finally gets chosen and consistently implemented.

>From the operator's point of view I tend to agree with other operators that= the Ignore Overlap policy looks better for most realistic cases, even thou= gh less worried about the amount of traffic lost, but more about robustness= and security aspects.

Complexity of implementation, however, can be a serious argument against it= , as this also works against robustness and security.

Nobody doubts that the Ignore Overlap policy is more complex. But how much = complexity it really adds is hard to estimate for me. Is it a minor complic= ation or a big one?

So far I have seen one vendor talk against the Ignore Overlap policy and tw= o vendors taking a position in favor of it.

Sounds to me like 2:1 for Ignore Overlap so far. But we actually don't beli= eve in voting and need more vendor input anyways!

BR,
Martin


Am 05.07.16 um 19:25 schrieb Les Ginsberg (ginsberg):

Bruno –

 

Two comments:

 

1)As we both can come = up with examples where a given  preference algorithm will result in &#= 8220;better” behavior than another, continuing to debate which one is= “best” has no end. The answer depends upon what types of errors are introduced in the configuration and that isn’t predict= able. If it is necessary for us to agree on which algorithm is “best&= #8221; I doubt that consensus will ever be reached. It therefore is more im= portant to me to focus on implementation complexity and the importance of identifying and correcting misconfigurations ASAP.

 

2)There are two logica= l databases that an implementation has to support. One of them is the set o= f received advertisements which can include entries with a variety of range= s. The second one is the set of mapping entries which are in use for lookups.

Your discussion of you= r “per FEC algorithm”  below defines the second database a= s a set of entries all of which have a range of 1. Whether this is good imp= lementation model or not I am not commenting on here. But this does not eliminate the need to maintain the first database –= ; and to be able to associate entries in the second database with the corre= sponding received entry from which they may have been derived. There is wor= k in maintaining that relationship which does not directly bear on the lookup for a given SID but still has to be d= one if one uses “per FEC” or “Ignore Overlap Only”.= This work is not required for the “per range” or “Quaran= tine” algorithm. It is this additional work that I refer to when I sa= y that “per FEC” has a higher implementation cost/complexity.<= o:p>

 

   Les

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Tuesday, July 05, 2016 1:50 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 05, 2016 9:08 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@i= etf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

Consider the following= simple case:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2: (SRMS, 1.1.1= .1/32, 200, 10, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

There is a misconfigur= ation here, but we don’t know what was really intended. A few (of man= y) possibilities:

 

ERROR #1:   = Entry #2 should have been: (SRMS, 1.1.1.1/32, 100, 10, 0,0) !Starting SID e= rror

ERROR #2:  Entry = #2 should have been: (SRMS, 2.2.2.2/32, 200, 10, 0,0) !Starting prefix erro= r

 

The draft defines two = candidate preference rules which could be applied:

 

Quarantine=

----------------

As we evaluate prefix = conflicts first, we compare Entry #1 and Entry #2 and choose Entry #1 the w= inner (source is PFX). Entry #2 is then not used (quarantined) and the set = of active entries is:

 

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #3: (SRMS, 2.2.2= .2/32, 200, 10. 0, 0)

 

Ignore Conflict Only

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

In this case we split = Entry #2 into two derived entries:

 

Entry #2A: (SRMS, 1.1.= 1.1/32, 200, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

 

Entry 2A is then ignor= ed and we then have to evaluate SID conflicts between the derived entry 2B = and Entry #3.  For this we have to split Entry 3 into two derived entr= ies:

 

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

Entry #3B: (SRMS, 2.2.= 2.3/32, 201, 9. 0, 0)

 

Entry 2B wins over ent= ry 3B since it has a smaller range.

 

Active entries are the= n:

Entry #1: (PFX, 1.1.1.= 1/32, 100, 1, 0,0)

Entry #2B: (SRMS, 1.1.= 1.2/32, 201, 9, 0,0)

Entry #3A: (SRMS, 2.2.= 2.2/32, 200, 1. 0, 0)

 

Note that in this exam= ple both preference rules result in 11 destinations having non-conflicting = SIDs.

[Bruno] Yes. The impor= tant part is =AB in this example =BB. Now do we agree that in ave= rage, Quarantine will result in dropping more destinations than Ignore conf= lict only?

 

 Now, which of th= ese maximizes delivery of traffic? The answer to that depends upon the type= of configuration error that was made.

If Error #1 was made, = there is no way to differentiate the two preference rules.

However, if Error #2 w= as made, then Quarantine is clearly better because the destinations 1.1.1.2= – 1.1.1.10 were never intended to have assigned SIDs and may not eve= n exist as destinations in the network, yet “Ignore Conflict Only” favors those prefixes.

 

The point I am trying = to make is that it is incorrect to say “If we maximize the number of = advertised entries which we use we will always do a better job of deliverin= g traffic.” This example illustrates that this isn’t always true.

[Bruno] OK. Clearly, w= e can find an example where an algorithm is better than the other. After al= l, we all agree that there has been a configuration error.

There are 2 points:

a)      how many destination = you keep using

b)      in case of conflict w= hich of the entries you select

 

I agree that “b&= #8221; is more or less random and hence there are many cases where we’= ;ll pick the wrong one. Yet, we try to make reasonable choices. That the po= int of discussing the preference algorithm (3.2.4). (Although it’s very easy to argue that we can make the wrong choice, I donR= 17;t feel that’s a reason not to try discussing it and make choice. e= .g. “PFX source wins over SRMS s= ource” is one: we give preference to SR nodes rather than LDP nodes.

 

Regarding a, I feel th= at maximizing the number of destinations kept, is likely to give the best r= esult in average. I don’t have a proof, but it feel like playing loto= : even if each choice is random (“b”), the more you try (“a”) the better your chances.  =

 

 

A few more comments in= line.

 

 

From: bruno.decraene@orange.com [mailto:bruno.decr= aene@orange.com]
Sent: Monday, July 04, 2016 5:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,

 

Please see inline [Bruno]

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, July 01, 2016 3:12 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I don’t find you= r representation complete as regards all of the attributes which are propos= ed to be used by the conflict resolution algorithm – so it is therefo= re hard for me to use/understand this representation when applying the defined preference rule.

This is true for me ev= en after reading your explanations below.

 

But it is far more imp= ortant to have a common understanding of the algorithm proposal than it is = to be arguing over whose encoding is “better”. If the encoding = in the draft is not clear or could use improvement, I welcome your feedback.

 

As far as your “= pseudo-code”:

 

- Find all SIDi advertised for the prefix P1   &nb= sp;            =             &nb= sp;            =             &nb= sp;     // identification of Prefix conflicts

           = ;     - For each SIDi find all the prefix Pij associate= d with SIDi           &nb= sp;  // identification of SID conflicts

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

           = ;     then use SIDij for P1

           = ;     else return no SID           = ;            &n= bsp; 

 

The fact that you can = represent an algorithm in a few lines does not mean the implementation of t= he algorithm is just as simple.

 

[Bruno] Sure. But if we want to compare implementati= on complexity, we’ll need to agree on how much we want to go into det= ails, in order to have meaningful comparison. So far this is not clear to m= e as you sometimes argue that data structure is implementation specific and you don’t want to go into this (which= I agree) and sometime you detail the data structure.

There is also the option to consider this as “= implementation issue” and let this to implementations.

 

Coming back to my per FEC algo, all what is required= from the data structure, is a way/API to get the data back, though 2 keys:= get me the SID matching prefix P1 (for the first line), get me the prefixe= s matching the SID SIDi for the second line. That seem like a reasonable requirement on the data structure, and a= ny option in your draft also requires this to detect prefix conflict and SI= D conflict (since this is all my per FEC algo is doing in these 2 first lin= es).

 

Going into more details, my per FEC algo only requir= es to detail that one prefix or SID belong to a range (of prefix or SID) wh= ile your per range algo requires to compute range intersection which is har= der. So the API to fetch the data can only be easier.

 

 

[Les:] Range int= ersection is easy to compute – the algorithm is present in the draft = at the end of  Section 3.1.1.

[Bruno] In order to ha= ve a meaningful discussion, we need to define the level of details that we = want to take into account, because you’re not using the same one to d= iscuss your algo and mine.

1) As a first level of= comparison, using the description at the end of section 3.1.1 as a model, = for range prefix conflict your algo is:

   1)(T1 =3D=3D T2) &&= (A1 =3D=3D A2)

   2)P1 <=3D P2=

   3)The prefixes are in the s= ame address family.

   2)L1 =3D=3D L2<= /o:p>

   3)(P1e >=3D P2) &&am= p; ((S1 + (P2 - P1)) !=3D S2)

 

So for (FEC) prefix co= nflict my algo is:

   1)(T1 =3D=3D T2) &&= (A1 =3D=3D A2)

   2)P1 =3D P2

   3)The prefixes are in the s= ame address family.

   2)L1 =3D=3D L2<= /o:p>

 

(BTW, in the draft, th= ere is a typo in the numbering)

It looks clear that FE= C comparison is easier than prefix range intersection.

 

2) Going deeper, at th= e algo complexity

 

The FEC algo needs: ge= t_SIDs(Prefix), and all the work is done. So all the algo complexity is com= ing from the datastructure. It seems pretty reasonable to find a datastruct= ure << o(n) (e.g. a tree, but you will be much better than me in finding one)

For the range algo, it= ’s not clear to me that a data structure can be found to automaticall= y find the result. If not, the algo seems to compare all entries two by two= , which would get o(n*(n-1)…(2)) i.e. o(n!)

 

 

 

 

Consider what needs to= be done to implement

 

   “Fi= nd all SIDi advertised for the prefix P1”

 

In its simplest form, = we have a list of all SID advertisements (PFX and SRMS) that we have receiv= ed. One could imagine walking all the entries, looking to see if the prefix= of interest is present within the advertised range. But, of course, at large scale such an approach is extremely ineffi= cient – so we immediately start considering ways to improve performan= ce. Inserting received entries into an ordered tree of some kind is an obvi= ous way to improve performance. When one further considers that calculating conflict resolution only needs to be do= ne when a change to the received database occurs (which post startup is inf= requent) it becomes very attractive to cache the “winning entriesR= 21; so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database = – ignoring the losers.

[Bruno] I agree that the per range algo (ignore over= lap only) will be able to ignore the losers but at the cost of a more compl= ex algo and at the cost of creating new derived entries. It’s not cle= ar to me if the net result is positive. Plus I would expect that the number of conflit is small compared to the nu= mber of prefix /SID so this looks like a second order optimization.

 

In this context, we ca= n appreciate the difference between the three proposed algorithms. In parti= cular comparing “Quarantine” with “ignore overlap only= 221;, a key difference is that “Quarantine” only needs to deter= mine whether a received entry is a winning entry or a losing entry. “Igno= re overlap only” has to be capable of breaking received entries with = ranges > 1 into multiple “derived” entries (some winning, so= me losing), which means we now need to track the “derived entriesR= 21; against the original received entry so that if the received entry is updat= ed/deleted we can find all the derived entries and delete/regenerate the de= rived entries as needed. This is what adds complexity.

[Bruno] and that it why the per FEC algo seems easie= r.

So it would seem useful to add it in the draft so th= at we can all discuss it.

 

[Les:] Ignore ov= erlap only is the same as per FEC. We may use different words to describe i= t, but the end behavior is the same.

[Bruno] good if this g= et the same result. Yet the algo is different.

 

-- Bruno

 

   Les=

 

 

All proposed algorithm= s can be implemented, but it does seem prudent to consider implementation c= omplexity as part of our decision process – and the discussion/exampl= es in Section 3 are meant to help in doing this.

 

It is worthwhile resta= ting that when conflicts are present we cannot guarantee that forwarding wi= ll work correctly no matter what algorithm is used.

[Bruno] I’m not sure to see what you have in m= ind exactly. Can you elaborate? To me consistency seem enough.

 The more complex= the implementation the more likely it is that bugs will be present and the= more likely it is that interoperability issues will arise. Whether these c= osts/risks are worth the “value add” when the outcome cannot be guaranteed to be correct – only guaranteed to = be consistent – is an important consideration.

 

Also important to reme= mber that conflicts MUST be eliminated by correcting the misconfigurations = that caused them – so conflict resolution is really only an interim m= easure until the corrections can be made.

[Bruno] By “interim” we are at minimum t= alking about 10s of minutes, if not more than 1 hour since identifying the = root cause may not be obvious. The impact is very significant on the networ= k.

The “Quarantine” algo has the potential = to kill 100s PE and 1000s of VPN customers, so a single configuration chang= e on a unrelated router which may not even be in production (i.e. where con= figuration checks and operations hours may be relaxed)

 

 

No one should be lulle= d into thinking that because we have conflict resolution deployed that corr= ecting the configuration when conflicts are detected is not a priority.

[Bruno] I could not agree more that conflict needs t= o be identified and fixed. Note that I’m the one having asked for def= ining YANG notifications to report this.

You are welcomed to state in the draft that conflict= s needs to be reported to the network operator, in particular though yang n= otification, and other existing means. Plus that network operator needs to = fixed them ASAP (but still carefully)

 

Thanks

--Bruno

 

   Les

 

 

From: bruno.decraene@orange.com [mailto:bruno.decr= aene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks for the discuss= ion. Please see inline [Bruno]

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

As the thread below do= cuments, I stated that I did not understand your representation and asked f= or clarification – suggesting that you use the format defined in the = draft.

You stated that you co= uld not do that and we were at a point where no progress could be made.

[Bruno] I could _no= t_ use your format since your format did not include the information ne= ed. This is not a whim but a technical issue. So I asked you to still consi= der the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification q= uestions on the points which were not clear, or at least explicitly refusin= g to consider the email.

I also note that what bothered you in my=
 representation was my addition of the type of advertisement (prefix or MS)=
. But you finally have just added in the latest version of the draft “=
;Src- PFX or SRMS” . So there was probably a way to communicate.

 

 

Besides the algo did n= ot use any specification representation, just names. So I’ll copy/pas= te it below, please ask clarification questions for the parts which are not= clear enough.

 

The problem that we ne= ed to solve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advert= ised for the prefix P1         = ;            &n= bsp;            = ;            &n= bsp;            // i= dentification of Prefix conflicts

   &nbs= p;            - For = each SIDi find all the prefix Pij associated with SIDi   &nb= sp;          // identification= of SID conflicts

 

// as a result, for P1= , we get a list of (SIDi, Pij)

 

Get the best (SIDi, Pi= j) as per the preference algorithm.

If best Pij =3D=3D P1<= /span>

   &nbs= p;            then u= se SIDij for P1

   &nbs= p;            else r= eturn no SID          &nb= sp;            =    / no SID available for this prefix P1

 

 

 

To illustrate my confu= sion, one of your examples is:

 

For R2, the algo evaluates a conflict between the following advertism= ents:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

 

Now, what does “= R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]

- MS/prefix SID is the= type of advertisement. In your new version, you call it SRMS/PFX.

- SID is the SID found= in the Mapping Entrie

- Rx is the loopback (= prefix) or router Rx

 

So “R2 - SID2 - R2 (MS, MS)” is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

 

Does it mean  = 220;On R2, SID2 is assigned to prefix R2 from two different mapping server = entries?” I really have no idea.

 

And you conclude the e= xample by saying

 

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range= (prefix SID))

   =3D=3D> SID12 is selected for R2.

 

But since there is no = representation of “range” in your examples I really have no ide= a how you came to this conclusion .

[Bruno] I agree that s= ince the above algo used 2 mapping entries to provides the (SIDi, Pij), the= preference algo (=A73.2.4) would need to be adapted. That being said, this= is not important for this discussion. Let’s just considered that their exist a preference algorithm, which= takes as input a list of (SIDi, Piij) for P1, and gives as outpout the = 220;best” one. (definition of “best” is not pertinent)

 

 

??

 

As regards “per = FEC/Prefix”, I believe this is what “ignore overlap only”= does.

[Bruno] Indeed, this i= s my expectation. But I would need someone’s review to confirm this.<= /span>

But the difference is = that the proposed algo is simple (2 lines of pseudo code), with very modest= resquirement data structure use to store the mapping entries. Indeed, all = it needs is a function returning the list of mapping entries associated/matching a given prefix. And function r= eturning the list of mapping entries associated/matching a given SID.

In particular, there i= s no need for splitting mapping entries which is the main complexity of you= r proposed “Preference algorithm/ignore overlap only”. (accordi= ng to your own text).

 

-- Bruno

 

 

    Les=

 

 

From: bruno.decraene@orange.com [mailto:bruno.decr= aene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks for the updated= draft.

 

IINM, you have not ans= wered my below email/proposal. I had waited for the new version of the draf= t but it also does not touch this subject.

 

So, could you please c= onsider and answer my comment?

 

In short, in an implem= entation-independent sentence:

 

> I'm wondering if we could address the conflict = on a per FEC/Prefix basis rather than on a per IGP advertisement (range) ba= sis.

> If so, this may avoid the discussion between th= e Quarantine vs ignore policy.

 

 

Thanks

Bruno

 

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce.

[Bruno] My text does not incorporate the source, but= the type of source IOW the type of sub-TLV.

 

So it does not matter = if R2 sends an advertisement or R12 sends advertisement or both of them do = (which could happen when an advertisement is leaked) – what matters i= s what unique entries are in the database independent of source.

[Bruno] It may not matter for your algorithm (pendin= g another thread), but it does for the one I proposed.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

[Bruno] My examples are described in plain text. The= n the examples giving intermediate steps of my algo uses the data that are = needed i.e. the type of advertisement (Prefix-SID vs MS).

Then finally, my algo runs on a per FEC/IP Prefix ba= sis, and not on a per IGP advertisement basis which your format describe.

So I’m sorry but I don’t see how to indu= lge your request.

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /o:p>

     Lx - Maximum prefix length (32 for IPv4,= 128 for IPv6)

     Si - Initial SID value

     Se - End SID value=

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L= , Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L))=

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1   &nb= sp;            =             &nb= sp;            =             &nb= sp;     // identification of Prefix conflicts

           = ;     - For each SIDi find all the prefix Pij associate= d with SIDi           &nb= sp;  // identification of SID conflicts

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

           = ;     then use SIDij for P1

           = ;     else return no SID           = ;            &n= bsp; 

 

this to me specifies a= n implementation – which isn’t necessary.

[Bruno] Well, _you_ are the one talking about= implementation, and more specifically implementation complexity.

Assuming the above algo works, it looks relatively s= imple to implement, in which case, I would not buy the argument about imple= mentation complexity which is the only argument in favor or the “igno= re” or “quarantine” policy.

Bottom line, I would welcome your feedback and comme= nts on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

 

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

__________________________________________________________=
_______________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des info=
rmations 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 al=
tere, 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 aut=
horisation.


If you have received this email in error, please notify th=
e sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for message=
s that have been modified, changed or falsified.


Thank you.


__________________________________________________________=
_______________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des info=
rmations 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 al=
tere, 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 aut=
horisation.


If you have received this email in error, please notify th=
e sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for message=
s that have been modified, changed or falsified.


Thank you.


__________________________________________________________=
_______________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des info=
rmations 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 al=
tere, 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 aut=
horisation.


If you have received this email in error, please notify th=
e sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for message=
s that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.




_______________________________________________
spring mailing list
spring@ietf.org
https://www.i=
etf.org/mailman/listinfo/spring

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F96DEAAOPEXCLILM21corp_--