From nobody Tue Oct 2 06:28:34 2018 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 3C4481292F1; Tue, 2 Oct 2018 06:28:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , spring@ietf.org, spring-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153848690023.5137.11609834348494624428.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2018 06:28:20 -0700 Archived-At: Subject: [spring] WG Action: Rechartered Source Packet Routing in Networking (spring) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 13:28:21 -0000 The Source Packet Routing in Networking (spring) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Source Packet Routing in Networking (spring) ----------------------------------------------------------------------- Current status: Active WG Chairs: Rob Shakir Bruno Decraene Assigned Area Director: Martin Vigoureux Routing Area Directors: Alvaro Retana Deborah Brungard Martin Vigoureux Mailing list: Address: spring@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spring Archive: https://mailarchive.ietf.org/arch/browse/spring/ Group page: https://datatracker.ietf.org/group/spring/ Charter: https://datatracker.ietf.org/doc/charter-ietf-spring/ The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as a forum to discuss SPRING networks operations, define new applications of, and specify extensions of Segment Routing technologies. SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING WG defines procedures that allow a node to steer a packet through an SR Policy instantiated as an ordered list of instructions called segments and without the need for per-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING nodes must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for other network applications. The scope of the SPRING WG work includes both single Autonomous System (AS) and multi-AS environments. Segment Routing typically operates within a single trust domain which requires the enforcement of a strict boundary and preventing Segment Routing packets from entering the trusted domain from the untrusted exterior. Certain deployments may however involve multiple trust domains which in turn may imply the use of cross/inter domain segments. Risk models associated with these various scenarios may necessitate the use of a cryptographic integrity checks to validate that the segment list is provided by an authorised entity. As is customary in the Routing Area, the SPRING WG will also identify and address any other security considerations introduced by the technologies it defines; addressing such considerations may require the introduction of new functionality in protocols leveraged for Source Routing, in which case the SPRING WG will formulate requirements to be considered by the appropriate WG for that work. The SPRING WG is however not expected to wait on the development of a solution to these requirements before progressing its own documents. SPRING technologies may be deployed in environments spanning a range of risk and threat models, which may impact both the security considerations and the requirements placed on other protocols in order to support Source Routing protocols. The technologies SPRING WG defines may be applicable to both centralised and distributed path computation. The SPRING WG will manage its specific work items by milestones agreed with the responsible Area Director. The work-items of the SPRING WG include functional specifications for: o Segment Routing policies and the associated steering, signalling and traffic engineering mechanisms. o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes. o SRv6 network programming for the underlay networks and overlay services, and including data plane behavior and functions associated with SIDs o Operation, Administration and Management (OAM), and traffic accounting in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Inter-working between SRv6 and SR-MPLS and between SR and existing routing solutions to allow for seamless deployment and co-existence. o New types of segments mapping to forwarding behaviour (e.g., local ingress replication, local forwarding resources, a pre-existing replication structure) if needed for new usages. Any of the above may require architectural extensions. The work-items of SPRING WG also include: o Specification of management models (YANG) for Segment Routing applications, services and networks with SR-MPLS and SRv6 dataplanes. The SPRING WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include (but may not be limited to): * mpls on the MPLS dataplane and OAM extensions, * 6man on the IPv6 dataplane for SR and associated OAM extensions * lsr on OSPF and IS-IS extensions to flood SPRING-related information * idr for BGP extensions * bess for VPN control plane * pce on extensions to communicate with an external entity to compute and program SPRING paths * teas on generic traffic engineering architecture * sfc on service chaining applications * rtgwg on fast-reroute technologies Milestones: Oct 2018 - SR-MPLS sent to IESG Oct 2018 - MPLS anycast sent to IESG Dec 2018 - SR-MPLS configuration YANG model sent to IESG Jul 2019 - SR-TE policy sent to IESG Jul 2019 - SR-MPLS OAM sent to IESG Jul 2019 - SR-MPLS Performance Measurement to IESG Jul 2019 - SR-IPv6 OAM sent to IESG Dec 2019 - SRv6 Network Programming to IESG Dec 2019 - SR policies YANG model sent to IESG Dec 2019 - Stateless service chaining with SR sent to IESG From nobody Tue Oct 9 01:59:59 2018 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 0F69B13122D; Tue, 9 Oct 2018 01:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 s8quet2W7N-N; Tue, 9 Oct 2018 01:59:55 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.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 809AC1311AA; Tue, 9 Oct 2018 01:59:55 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 42TrlY6wCGz108W; Tue, 9 Oct 2018 10:59:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 42TrlY5vyGz8sYp; Tue, 9 Oct 2018 10:59:53 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0415.000; Tue, 9 Oct 2018 10:59:53 +0200 From: To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: IETF 103 - SPRING meeting Thread-Index: AdRfrEgCG6F6jPJ/S5SrNk2qkjrTYA== Date: Tue, 9 Oct 2018 08:59:52 +0000 Message-ID: <3602_1539075593_5BBC6E09_3602_457_1_53C29892C857584299CBF5D05346208A47B63D72@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.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47B63D72OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] IETF 103 - SPRING meeting X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 08:59:58 -0000 --_000_53C29892C857584299CBF5D05346208A47B63D72OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, For IETF 103, the SPRING WG is currently scheduled to meet Wednesday 09:00-= 11:00. We have a two hours session. https://datatracker.ietf.org/meeting/103/agenda.html It is time to start building the SPRING WG agenda. Please send to chairs your request for a presentation slot, indicating draf= t name, speaker, and desired duration (covering presentation and discussion= ), before Monday 2018-10-22 COB. Before is better. If it is not the first presentation of a non-WG draft, please give a reason= why it is required to have a new presentation slot. A checklist is available on the wiki: https://trac.ietf.org/trac/spring/wik= i/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting Please send your slides before Tuesday 13:00 local time. Earlier is better. Thanks, --Bruno, Rob ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A47B63D72OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi all,
 
 
For IETF 103, the SPRING WG is currently schedule=
d to meet Wednesday 09:00-11:00. We have a two hours session.
https://datatracker.ietf.org/meeting/103/agenda.html
 
It is time to start building the SPRING WG agenda=
.
 
Please send to chairs your request for a presenta=
tion slot, indicating draft name, speaker, and desired duration (covering p=
resentation and discussion), before Monday 2018-10-22 COB. Before is better=
.
 
If it is not the first presentation of a non-WG d=
raft, please give a reason why it is required to have a new presentation sl=
ot.
 
A checklist is available on the wiki: https://trac.ietf.org/tra=
c/spring/wiki/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting
 
 
Please send your slides before Tuesday 13:00 loca=
l time. Earlier is better.
 
 
Thanks,
--Bruno, Rob

  

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A47B63D72OPEXCLILM21corp_-- From nobody Sat Oct 13 10:10:57 2018 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 A2461130E2F for ; Sat, 13 Oct 2018 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 7HfoHUkGOiwx for ; Sat, 13 Oct 2018 10:10:53 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 C67AC130DEB for ; Sat, 13 Oct 2018 10:10:50 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9DHAmJG006808 for ; Sat, 13 Oct 2018 18:10:48 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 61A172203C for ; Sat, 13 Oct 2018 18:10:48 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 4D1C82203A for ; Sat, 13 Oct 2018 18:10:48 +0100 (BST) Received: from 950129200 (4.43.114.87.dyn.plus.net [87.114.43.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9DHAlEn015531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Oct 2018 18:10:48 +0100 Reply-To: From: "Adrian Farrel" To: "'SPRING WG List'" Date: Sat, 13 Oct 2018 18:10:46 +0100 Message-ID: <017701d46317$aeee7dd0$0ccb7970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdRjF3DYQwTFd5XmQQyUo9rJOxpX2g== Content-Language: en-gb X-Originating-IP: 87.114.43.4 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24154.001 X-TM-AS-Result: No--11.403-10.0-31-10 X-imss-scan-details: No--11.403-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24154.001 X-TMASE-Result: 10--11.403500-10.000000 X-TMASE-MatchedRID: n9sIU/ARozTMvjrgTxHPpLiMC5wdwKqdLdLfmiFS7fu67Q3uPo9KI0sq 2Qq9h9WiPn+OUf98vV562zfFb3UqEuZHRjmtPnwOBPueREbgUKGeimGtNywjttp1biJhIyNRp7u eaEkDqTMmYuoq7bKp2ayDYF/RX6N86mVrY9/neAIcMLpr3hTUANIv4RV84lHTut/GVGOoEndfFG 0p9UU3w9awGpF9TV3zadKAzOpy9pZOnGZrvAmZirMjW/sniEQKsQ+fqZPOkZzxSV7YBeBhSzZoO FSxfaf0jk05nQBBWNpcz1Fo0vGaHtoZHjFpZt7N/O70vD0Lt8C7atxTbKDEIA6QlBHhBZuwooh6 +sXV4NWgFN91JwK3C3wLyTE8Sb+87bdBxC9wVFcF8rFt9xmDKcBDOqHwPghjDO+DX+rUwfbj/oY 0gNp66q3WS3pROsBbX7bicKxRIU23sNbcHjySQSs3zPQeiEbe+gtHj7OwNO0PXZPurZ0hS0vZ8D IGLUIu0cc78odsLQw51hKD1h4yFlK0k4yXFEiB X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [spring] New Version of draft-farrel-spring-sr-domain-interconnect X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 17:10:56 -0000 Hi, Nothing much happening with this draft. The new revision fixes a reference. We think our work here is done although it is disappointing that a = couple of (informative) references have expired: - I-D.sivabalan-pce-binding-label-sid - I-D.ietf-idr-bgpls-segment-routing-epe We would still welcome comments. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 13 October 2018 18:04 > To: Adrian Farrel; John Drake > Subject: New Version Notification for = draft-farrel-spring-sr-domain-interconnect- > 05.txt >=20 >=20 > A new version of I-D, = draft-farrel-spring-sr-domain-interconnect-05.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-farrel-spring-sr-domain-interconnect > Revision: 05 > Title: Interconnection of Segment Routing Domains - Problem > Statement and Solution Landscape > Document date: 2018-10-13 > Group: Individual Submission > Pages: 35 > URL: = https://www.ietf.org/internet-drafts/draft-farrel-spring-sr-domain- > interconnect-05.txt > Status: = https://datatracker.ietf.org/doc/draft-farrel-spring-sr-domain- > interconnect/ > Htmlized: = https://tools.ietf.org/html/draft-farrel-spring-sr-domain- > interconnect-05 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain- > interconnect > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-farrel-spring-sr-domain- > interconnect-05 >=20 > Abstract: > Segment Routing (SR) is a forwarding paradigm for use in MPLS and > IPv6 networks. It is intended to be deployed in discrete domains > that may be data centers, access networks, or other networks that = are > under the control of a single operator and that can easily be > upgraded to support this new technology. >=20 > Traffic originating in one SR domain often terminates in another SR > domain, but must transit a backbone network that provides > interconnection between those domains. >=20 > This document describes a mechanism for providing connectivity > between SR domains to enable end-to-end or domain-to-domain traffic > engineering. >=20 > The approach described allows connectivity between SR domains, > utilizes traffic engineering mechanisms (RSVP-TE or Segment = Routing) > across the backbone network, makes heavy use of pre-existing > technologies, and requires the specification of very few additional > mechanisms. >=20 > This document provides some background and a problem statement, > explains the solution mechanism, gives references to other = documents > that define protocol mechanisms, and provides examples. It does = not > define any new protocol mechanisms. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Sat Oct 13 10:24:57 2018 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 BCDDF130E2F for ; Sat, 13 Oct 2018 10:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 LkiFEOfzGKCF for ; Sat, 13 Oct 2018 10:24:53 -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 55728130DE6 for ; Sat, 13 Oct 2018 10:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5252; q=dns/txt; s=iport; t=1539451493; x=1540661093; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=T6ySGGDLvUWXaS1aR/tFUuN2W4dB/1MCjM3Wv0+EOSs=; b=cb1FSRIxWwxcXIfXifZyWG8RKjmFGXXhYztt8f4XbyK/LySlJpXdPBhE Z2rnoqUoVaxaCuC2944GJqIR+9atvQZHO0mEXFhoo2iFalbYnHknKQ8EI is1rp1iSVA25FJGACIoL0GHjwYutz5XVTQ2bxVxvDaXKISs+fz0ufGrVT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADiKcJb/4sNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmfygKg2uIFowpgWgllweBegsBARg?= =?us-ascii?q?LhANGAheERiE0DQ0BAwEBAgEBAm0cDIU5AQEBBAEBIRE6FwQCAQgRBAEBAwI?= =?us-ascii?q?jAwICAiULFAEICAEBBAESG4MFAYIBD6QRgS6EMwc9hGGBC4pBF4IAgREBJww?= =?us-ascii?q?TgkyDGwEBAgEBFoE6DSaCXTGCJgKIXIVhgT+OLgkChlOKBheBT0yEJIlfjEO?= =?us-ascii?q?JQwIRFIEmHTiBVXAVGiEqAYJBCYIdF4hbhT5viTCBLIEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,377,1534809600"; d="scan'208";a="465780535" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Oct 2018 17:24:51 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w9DHOp9m008126 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 13 Oct 2018 17:24:51 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Oct 2018 13:24:50 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Sat, 13 Oct 2018 13:24:50 -0400 From: "Acee Lindem (acee)" To: "adrian@olddog.co.uk" , "'SPRING WG List'" Thread-Topic: [spring] New Version of draft-farrel-spring-sr-domain-interconnect Thread-Index: AdRjF3DYQwTFd5XmQQyUo9rJOxpX2gAAjUaA Date: Sat, 13 Oct 2018 17:24:50 +0000 Message-ID: References: <017701d46317$aeee7dd0$0ccb7970$@olddog.co.uk> In-Reply-To: <017701d46317$aeee7dd0$0ccb7970$@olddog.co.uk> 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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <8564B164540CBA4997FD607AC7647C00@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [spring] New Version of draft-farrel-spring-sr-domain-interconnect X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 17:24:56 -0000 SGkgQWRyaWFuLCANCg0K77u/T24gMTAvMTMvMTgsIDE6MTEgUE0sICJzcHJpbmcgb24gYmVoYWxm IG9mIEFkcmlhbiBGYXJyZWwiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg YWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQoNCiAgICBIaSwNCiAgICANCiAgICBOb3RoaW5n IG11Y2ggaGFwcGVuaW5nIHdpdGggdGhpcyBkcmFmdC4NCiAgICANCiAgICBUaGUgbmV3IHJldmlz aW9uIGZpeGVzIGEgcmVmZXJlbmNlLg0KICAgIA0KICAgIFdlIHRoaW5rIG91ciB3b3JrIGhlcmUg aXMgZG9uZSBhbHRob3VnaCBpdCBpcyBkaXNhcHBvaW50aW5nIHRoYXQgYSBjb3VwbGUgb2YgKGlu Zm9ybWF0aXZlKSByZWZlcmVuY2VzIGhhdmUgZXhwaXJlZDoNCiAgICAtIEktRC5zaXZhYmFsYW4t cGNlLWJpbmRpbmctbGFiZWwtc2lkDQogICAgLSBJLUQuaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1y b3V0aW5nLWVwZQ0KDQpJIGp1c3QgcmV2aWV3ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgbGF0dGVy IGRyYWZ0IChhcyBhIGNvbnRyaWJ1dG9yKSBhbmQgaXQgd2lsbCBiZSByZWZyZXNoZWQgc2hvcnRs eS4gVGhlIHJlZnJlc2ggd2FzIGRlbGF5ZWQgdG8gYWRkcmVzcyBhbGwgb2YgU3VlIEhhcmVzJyBz aGVwaGVyZCByZXZpZXcgY29tbWVudHMuIA0KDQpUaGFua3MsDQpBY2VlDQoNCiAgICANCiAgICBX ZSB3b3VsZCBzdGlsbCB3ZWxjb21lIGNvbW1lbnRzLg0KICAgIA0KICAgIFRoYW5rcywNCiAgICBB ZHJpYW4NCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQogICAgPiBTZW50OiAxMyBPY3RvYmVyIDIwMTggMTg6MDQNCiAgICA+IFRvOiBBZHJpYW4g RmFycmVsOyBKb2huIERyYWtlDQogICAgPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWZhcnJlbC1zcHJpbmctc3ItZG9tYWluLWludGVyY29ubmVjdC0NCiAgICA+ IDA1LnR4dA0KICAgID4gDQogICAgPiANCiAgICA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1mYXJyZWwtc3ByaW5nLXNyLWRvbWFpbi1pbnRlcmNvbm5lY3QtMDUudHh0DQogICAgPiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFkcmlhbiBGYXJyZWwgYW5kIHBvc3RlZCB0 byB0aGUNCiAgICA+IElFVEYgcmVwb3NpdG9yeS4NCiAgICA+IA0KICAgID4gTmFtZToJCWRyYWZ0 LWZhcnJlbC1zcHJpbmctc3ItZG9tYWluLWludGVyY29ubmVjdA0KICAgID4gUmV2aXNpb246CTA1 DQogICAgPiBUaXRsZToJCUludGVyY29ubmVjdGlvbiBvZiBTZWdtZW50IFJvdXRpbmcgRG9tYWlu cyAtIFByb2JsZW0NCiAgICA+IFN0YXRlbWVudCBhbmQgU29sdXRpb24gTGFuZHNjYXBlDQogICAg PiBEb2N1bWVudCBkYXRlOgkyMDE4LTEwLTEzDQogICAgPiBHcm91cDoJCUluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KICAgID4gUGFnZXM6CQkzNQ0KICAgID4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1mYXJyZWwtc3ByaW5nLXNyLWRvbWFp bi0NCiAgICA+IGludGVyY29ubmVjdC0wNS50eHQNCiAgICA+IFN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYXJyZWwtc3ByaW5nLXNyLWRvbWFp bi0NCiAgICA+IGludGVyY29ubmVjdC8NCiAgICA+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFycmVsLXNwcmluZy1zci1kb21haW4tDQogICAgPiBp bnRlcmNvbm5lY3QtMDUNCiAgICA+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZhcnJlbC1zcHJpbmctc3ItZG9tYWluLQ0KICAgID4g aW50ZXJjb25uZWN0DQogICAgPiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWZhcnJlbC1zcHJpbmctc3ItZG9tYWluLQ0KICAgID4gaW50ZXJj b25uZWN0LTA1DQogICAgPiANCiAgICA+IEFic3RyYWN0Og0KICAgID4gICAgU2VnbWVudCBSb3V0 aW5nIChTUikgaXMgYSBmb3J3YXJkaW5nIHBhcmFkaWdtIGZvciB1c2UgaW4gTVBMUyBhbmQNCiAg ICA+ICAgIElQdjYgbmV0d29ya3MuICBJdCBpcyBpbnRlbmRlZCB0byBiZSBkZXBsb3llZCBpbiBk aXNjcmV0ZSBkb21haW5zDQogICAgPiAgICB0aGF0IG1heSBiZSBkYXRhIGNlbnRlcnMsIGFjY2Vz cyBuZXR3b3Jrcywgb3Igb3RoZXIgbmV0d29ya3MgdGhhdCBhcmUNCiAgICA+ICAgIHVuZGVyIHRo ZSBjb250cm9sIG9mIGEgc2luZ2xlIG9wZXJhdG9yIGFuZCB0aGF0IGNhbiBlYXNpbHkgYmUNCiAg ICA+ICAgIHVwZ3JhZGVkIHRvIHN1cHBvcnQgdGhpcyBuZXcgdGVjaG5vbG9neS4NCiAgICA+IA0K ICAgID4gICAgVHJhZmZpYyBvcmlnaW5hdGluZyBpbiBvbmUgU1IgZG9tYWluIG9mdGVuIHRlcm1p bmF0ZXMgaW4gYW5vdGhlciBTUg0KICAgID4gICAgZG9tYWluLCBidXQgbXVzdCB0cmFuc2l0IGEg YmFja2JvbmUgbmV0d29yayB0aGF0IHByb3ZpZGVzDQogICAgPiAgICBpbnRlcmNvbm5lY3Rpb24g YmV0d2VlbiB0aG9zZSBkb21haW5zLg0KICAgID4gDQogICAgPiAgICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhIG1lY2hhbmlzbSBmb3IgcHJvdmlkaW5nIGNvbm5lY3Rpdml0eQ0KICAgID4gICAg YmV0d2VlbiBTUiBkb21haW5zIHRvIGVuYWJsZSBlbmQtdG8tZW5kIG9yIGRvbWFpbi10by1kb21h aW4gdHJhZmZpYw0KICAgID4gICAgZW5naW5lZXJpbmcuDQogICAgPiANCiAgICA+ICAgIFRoZSBh cHByb2FjaCBkZXNjcmliZWQgYWxsb3dzIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIFNSIGRvbWFpbnMs DQogICAgPiAgICB1dGlsaXplcyB0cmFmZmljIGVuZ2luZWVyaW5nIG1lY2hhbmlzbXMgKFJTVlAt VEUgb3IgU2VnbWVudCBSb3V0aW5nKQ0KICAgID4gICAgYWNyb3NzIHRoZSBiYWNrYm9uZSBuZXR3 b3JrLCBtYWtlcyBoZWF2eSB1c2Ugb2YgcHJlLWV4aXN0aW5nDQogICAgPiAgICB0ZWNobm9sb2dp ZXMsIGFuZCByZXF1aXJlcyB0aGUgc3BlY2lmaWNhdGlvbiBvZiB2ZXJ5IGZldyBhZGRpdGlvbmFs DQogICAgPiAgICBtZWNoYW5pc21zLg0KICAgID4gDQogICAgPiAgICBUaGlzIGRvY3VtZW50IHBy b3ZpZGVzIHNvbWUgYmFja2dyb3VuZCBhbmQgYSBwcm9ibGVtIHN0YXRlbWVudCwNCiAgICA+ICAg IGV4cGxhaW5zIHRoZSBzb2x1dGlvbiBtZWNoYW5pc20sIGdpdmVzIHJlZmVyZW5jZXMgdG8gb3Ro ZXIgZG9jdW1lbnRzDQogICAgPiAgICB0aGF0IGRlZmluZSBwcm90b2NvbCBtZWNoYW5pc21zLCBh bmQgcHJvdmlkZXMgZXhhbXBsZXMuICBJdCBkb2VzIG5vdA0KICAgID4gICAgZGVmaW5lIGFueSBu ZXcgcHJvdG9jb2wgbWVjaGFuaXNtcy4NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0K ICAgID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+IA0KICAg ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCiAgICBz cHJpbmdAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZw0KICAgIA0KDQo= From nobody Mon Oct 15 06:24:30 2018 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 12F31129BBF; Mon, 15 Oct 2018 06:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VvKCSkGNAg5y; Mon, 15 Oct 2018 06:24:26 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 017B8130E63; Mon, 15 Oct 2018 06:24:22 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id p64-v6so27626563itp.0; Mon, 15 Oct 2018 06:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YjhJG22WaB9mTaSvzNqmDOCfgUaHgm5kkYqtGgyYWKQ=; b=sF8j45+r/30ureWvz3OqKRrmIXf75MuKh74LQQZJvFE2cUCLsTd3jBNtonPnwZGYCY x/wfmsRTLfgnsfj1gpixpDF05ZdRrKisjGQwapH74RZOMymgCn6y8BbvPusSr4tMRx8j ZOyXCdeLpDbArnkh22OBdDQNhmZ98gpF2kLgFeX5ZEfCGNf9FD95u8MQCdlEZtusDBnw SG6siJbejPhSuIAkdKparzs+pFnxy7v2kBGxXn1nxBwmySMg2ztnDmE9FotBCByREiJO I1zBjuRrZSNnpBmwacGRc4+UWl3PnhMCs38bSdL//tWyd6fGiX4sygJEoxXqpXOcaHfa u84A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YjhJG22WaB9mTaSvzNqmDOCfgUaHgm5kkYqtGgyYWKQ=; b=rheLLKH+L6vBa6xz0/ONu0aCW2THUW1Uv06hD+bZna9R4dz/pzFFbh5gK/+PdkLrtq /Ho4+44Bo1xQknl5lQxcUcMBmzcxcEGzwCNkDjsb+/OKBgnA4iBpSz321aTz3g8prRmS o8aXmTJ389AW+MN//LOMi33/8u+97PAzUIfmaqYvtMJ6EC9n1LZYhH5enB6PWR4fHB2J o6WIJrNSNYwkpEChhf4mh2YeLwb0zV7dBMvBQUD8hdazg0EPrMAnRLVXUoRcCPEMnCh4 b8uWzZJwD2APFZev4s8QUCKTHCjdEzcFE3PWw9Lxr2sE1QuI9HZnvJW+KmBkVhz70LFf EYlg== X-Gm-Message-State: ABuFfojxDgQCXecLmpUKLf9KtbpPPKI9tohrbkm3nfiVgClaJl2y1pqQ cS2ZxabrDa+PyLX3bTsHbNlnDo6USZMndTXt3PQ= X-Google-Smtp-Source: ACcGV61Ykd+v2KvKvEVt5vA6eT4sao5abitQlj/vyFHzhRfzzLf2CamdiLy4bR25eENgN7x/E86wTmx5Hms/ZNv9IH0= X-Received: by 2002:a02:38c:: with SMTP id e12-v6mr13305406jae.71.1539609862122; Mon, 15 Oct 2018 06:24:22 -0700 (PDT) MIME-Version: 1.0 References: <017701d46317$aeee7dd0$0ccb7970$@olddog.co.uk> In-Reply-To: From: Dhruv Dhody Date: Mon, 15 Oct 2018 18:54:10 +0530 Message-ID: To: "Acee Lindem (acee)" Cc: Farrel Adrian , spring@ietf.org, "Siva Sivabalan (msiva)" , draft-sivabalan-pce-binding-label-sid@ietf.org Content-Type: multipart/alternative; boundary="000000000000ecb3030578445aee" Archived-At: Subject: Re: [spring] New Version of draft-farrel-spring-sr-domain-interconnect X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 13:24:29 -0000 --000000000000ecb3030578445aee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, Regarding the binding SID, we have an update ready to go. I am awaiting confirmation from a co-author, it should be in datatracker SOON. WIP: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-sivabalan-pce-b= inding-label-sid-05.txt Diff: https://tools.ietf.org/rfcdiff?url1=3Ddraft-sivabalan-pce-binding-label-sid= -04&url2=3Dhttps://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/= draft-sivabalan-pce-binding-label-sid-05.txt Thanks! Dhruv On Sat, Oct 13, 2018 at 10:55 PM Acee Lindem (acee) wrote: > Hi Adrian, > > =EF=BB=BFOn 10/13/18, 1:11 PM, "spring on behalf of Adrian Farrel" < > spring-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote: > > Hi, > > Nothing much happening with this draft. > > The new revision fixes a reference. > > We think our work here is done although it is disappointing that a > couple of (informative) references have expired: > - I-D.sivabalan-pce-binding-label-sid > - I-D.ietf-idr-bgpls-segment-routing-epe > > I just reviewed a new version of the latter draft (as a contributor) and > it will be refreshed shortly. The refresh was delayed to address all of S= ue > Hares' shepherd review comments. > > Thanks, > Acee > > > We would still welcome comments. > > Thanks, > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 13 October 2018 18:04 > > To: Adrian Farrel; John Drake > > Subject: New Version Notification for > draft-farrel-spring-sr-domain-interconnect- > > 05.txt > > > > > > A new version of I-D, > draft-farrel-spring-sr-domain-interconnect-05.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Name: draft-farrel-spring-sr-domain-interconnect > > Revision: 05 > > Title: Interconnection of Segment Routing Domains - > Problem > > Statement and Solution Landscape > > Document date: 2018-10-13 > > Group: Individual Submission > > Pages: 35 > > URL: > https://www.ietf.org/internet-drafts/draft-farrel-spring-sr-domain- > > interconnect-05.txt > > Status: > https://datatracker.ietf.org/doc/draft-farrel-spring-sr-domain- > > interconnect/ > > Htmlized: > https://tools.ietf.org/html/draft-farrel-spring-sr-domain- > > interconnect-05 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain- > > interconnect > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-farrel-spring-sr-domain- > > interconnect-05 > > > > Abstract: > > Segment Routing (SR) is a forwarding paradigm for use in MPLS an= d > > IPv6 networks. It is intended to be deployed in discrete domain= s > > that may be data centers, access networks, or other networks tha= t > are > > under the control of a single operator and that can easily be > > upgraded to support this new technology. > > > > Traffic originating in one SR domain often terminates in another > SR > > domain, but must transit a backbone network that provides > > interconnection between those domains. > > > > This document describes a mechanism for providing connectivity > > between SR domains to enable end-to-end or domain-to-domain > traffic > > engineering. > > > > The approach described allows connectivity between SR domains, > > utilizes traffic engineering mechanisms (RSVP-TE or Segment > Routing) > > across the backbone network, makes heavy use of pre-existing > > technologies, and requires the specification of very few > additional > > mechanisms. > > > > This document provides some background and a problem statement, > > explains the solution mechanism, gives references to other > documents > > that define protocol mechanisms, and provides examples. It does > not > > define any new protocol mechanisms. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org= . > > > > The IETF Secretariat > > _______________________________________________ > 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 > --000000000000ecb3030578445aee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,=C2=A0

Regarding the binding SID, we have an update r= eady to go. I am awaiting confirmation from a co-author, it should be in da= tatracker SOON.=C2=A0

Diff:=C2=A0https://tools.ie= tf.org/rfcdiff?url1=3Ddraft-sivabalan-pce-binding-label-sid-04&url2=3Dh= ttps://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-sivaba= lan-pce-binding-label-sid-05.txt
<= br>
Thanks!=C2=A0
Dhruv

On Sat, Oct 13, 2018 at 10:55 PM Acee Lindem (acee) <= acee@cisco.com> wrote:
Hi Adrian,

=EF=BB=BFOn 10/13/18, 1:11 PM, "spring on behalf of Adrian Farrel"= ; <spring-b= ounces@ietf.org on behalf of adrian@olddog.co.uk> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 Nothing much happening with this draft.

=C2=A0 =C2=A0 The new revision fixes a reference.

=C2=A0 =C2=A0 We think our work here is done although it is disappointing t= hat a couple of (informative) references have expired:
=C2=A0 =C2=A0 - I-D.sivabalan-pce-binding-label-sid
=C2=A0 =C2=A0 - I-D.ietf-idr-bgpls-segment-routing-epe

I just reviewed a new version of the latter draft (as a contributor) and it= will be refreshed shortly. The refresh was delayed to address all of Sue H= ares' shepherd review comments.

Thanks,
Acee


=C2=A0 =C2=A0 We would still welcome comments.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Adrian

=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=C2=A0 =C2=A0 > Sent: 13 October 2018 18:04
=C2=A0 =C2=A0 > To: Adrian Farrel; John Drake
=C2=A0 =C2=A0 > Subject: New Version Notification for draft-farrel-sprin= g-sr-domain-interconnect-
=C2=A0 =C2=A0 > 05.txt
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > A new version of I-D, draft-farrel-spring-sr-domain-inte= rconnect-05.txt
=C2=A0 =C2=A0 > has been successfully submitted by Adrian Farrel and pos= ted to the
=C2=A0 =C2=A0 > IETF repository.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dra= ft-farrel-spring-sr-domain-interconnect
=C2=A0 =C2=A0 > Revision: 05
=C2=A0 =C2=A0 > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Intercon= nection of Segment Routing Domains - Problem
=C2=A0 =C2=A0 > Statement and Solution Landscape
=C2=A0 =C2=A0 > Document date:=C2=A0 =C2=A0 2018-10-13
=C2=A0 =C2=A0 > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
=C2=A0 =C2=A0 > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 35
=C2=A0 =C2=A0 > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draf= t-farrel-spring-sr-domain-
=C2=A0 =C2=A0 > interconnect-05.txt
=C2=A0 =C2=A0 > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-farrel-spring= -sr-domain-
=C2=A0 =C2=A0 > interconnect/
=C2=A0 =C2=A0 > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-farrel-spring-sr-domain-=
=C2=A0 =C2=A0 > interconnect-05
=C2=A0 =C2=A0 > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-farrel-s= pring-sr-domain-
=C2=A0 =C2=A0 > interconnect
=C2=A0 =C2=A0 > Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-fa= rrel-spring-sr-domain-
=C2=A0 =C2=A0 > interconnect-05
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Abstract:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Segment Routing (SR) is a forwarding paradi= gm for use in MPLS and
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 IPv6 networks.=C2=A0 It is intended to be d= eployed in discrete domains
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 that may be data centers, access networks, = or other networks that are
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 under the control of a single operator and = that can easily be
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 upgraded to support this new technology. =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Traffic originating in one SR domain often = terminates in another SR
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 domain, but must transit a backbone network= that provides
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 interconnection between those domains.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 This document describes a mechanism for pro= viding connectivity
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 between SR domains to enable end-to-end or = domain-to-domain traffic
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 engineering.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 The approach described allows connectivity = between SR domains,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 utilizes traffic engineering mechanisms (RS= VP-TE or Segment Routing)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 across the backbone network, makes heavy us= e of pre-existing
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 technologies, and requires the specificatio= n of very few additional
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 mechanisms.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 This document provides some background and = a problem statement,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 explains the solution mechanism, gives refe= rences to other documents
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 that define protocol mechanisms, and provid= es examples.=C2=A0 It does not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 define any new protocol mechanisms.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please note that it may take a couple of minutes from th= e time of submission
=C2=A0 =C2=A0 > until the htmlized version and diff are available at tools.i= etf.org.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The IETF Secretariat

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 spring mailing list
=C2=A0 =C2=A0 spring@i= etf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/spr= ing


_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000ecb3030578445aee-- From nobody Mon Oct 15 09:12:11 2018 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 2D9AE130E9D; Mon, 15 Oct 2018 09:12:09 -0700 (PDT) X-Quarantine-ID: <4tiEgcDqroCe> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...@OPEXCLILM21.corporate.adroot.infra.ftgroup>\n X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 4tiEgcDqroCe; Mon, 15 Oct 2018 09:12:05 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B71130EC0; Mon, 15 Oct 2018 09:12:03 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 42Yk3P55yfz2y3d; Mon, 15 Oct 2018 18:12:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 42Yk3P453wzCqkS; Mon, 15 Oct 2018 18:12:01 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0415.000; Mon, 15 Oct 2018 18:12:01 +0200 From: To: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "abashandy.ietf@gmail.com" CC: SPRING WG List Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Thread-Index: AdPzgj45KwPIKnTMSDy4d61puK5luwK+2i5gGYgd9HA= Date: Mon, 15 Oct 2018 16:12:01 +0000 Message-ID: <6143_1539619921_5BC4BC51_6143_164_1_53C29892C857584299CBF5D05346208A47B69553@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@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.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47B69553OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 16:12:09 -0000 --_000_53C29892C857584299CBF5D05346208A47B69553OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors, Ahmed, Could you progress on this document? Thread is: https://mailarchive.ietf.org/arch/browse/spring/?q=3Dsubject%3Ad= raft-ietf-spring-segment-routing-mpls Comments still to be addressed/resolved are the following: https://mailarchive.ietf.org/arch/msg/spring/xx-t5v5IW2P_8rZykeJrvl9qDIE = (from myself since 2018-05-24) https://mailarchive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw (f= rom Chris Bowers since 2018-06-08) https://mailarchive.ietf.org/arch/msg/spring/yIwUvKddrcR-gxPQZSMjbynTX74 (f= rom PK since 2018-06-09) https://mailarchive.ietf.org/arch/msg/spring/5PHhLlMIxLgoFdoRC1Wqz6xCBnI (= from PK since 2018-06-09) https://mailarchive.ietf.org/arch/msg/spring/w0ZmOAcDf_TUUWLkeFk_E6jzQm4 (f= rom Ruediger 2018-06-13) https://mailarchive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ (f= rom Shraddha 2018-07-20 & +1 from Sasha) https://mailarchive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk (f= rom Sasha & St=E9phane discussion 2018-08-06) Authors, Ahmed, Thank you for engaging the authors of those comments and update the draft. Thank you, --Bruno From: DECRAENE Bruno IMT/OLN Sent: Thursday, June 07, 2018 6:52 PM To: SPRING WG List Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hi all, A quick update on the status of this WGLC: - All the authors have responded about IPR (thank you!). Still missing repl= ies from some contributors (Wim, Edward, Igor, Saku). I've sent them a remi= nder this Monday. - Two people (Zafar, Adrian) have responded supporting publication. - No opposition. - Two persons have sent comments (Adrian, myself). Thanks Adrian. - Authors have not replied to any comment so far. - The WGLC period was scheduled to end tomorrow. I wish we had more support, reviews, and authors' involvement to reply to r= eviews. The WGLC is extended by a week. Please review the document and send your co= mments to the list, no later than *June 15* Thank you, --Bruno From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, May 24, 2018 7:14 PM To: SPRING WG List Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hello Working Group, This email starts a Working Group Last Call on draft-ietf-spring-segment-ro= uting-mpls-13 [1] which is considered mature and ready for a final working = group review. Please read this document if you haven't read the most recent version yet, = and send your comments to the list, no later than *June 08*. As a reminder, this document had already passed a WGLC more than a year ago= on version -06 [2], had been sent to the AD but then returned to the WG. Since then, the document has significantly changed, so please read it again= . In particular, it now includes the resolution in case of incoming label c= ollision. Hence it killed draft-ietf-spring-conflict-resolution. Both co-chairs co-author this document, hence: - Shraddha has agreed to be the document shepherd. Thank you Shraddha. - Martin, our AD, has agreed to evaluate the WG consensus. Thank you, Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 [2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A47B69553OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Authors, Ahmed= ,

 

Could you prog= ress on this document?

 

Thread is: https://mailarchive.ietf.org/arch/browse/spring/?q=3Dsubject%3Adraft-ietf-s= pring-segment-routing-mpls

 

Comments still= to be addressed/resolved are the following:

http= s://mailarchive.ietf.org/arch/msg/spring/xx-t5v5IW2P_8rZykeJrvl9qDIE&nb= sp;  (from myself since 2018-05-24)

http= s://mailarchive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw (from Chris Bowers since 2018-06-08)

http= s://mailarchive.ietf.org/arch/msg/spring/yIwUvKddrcR-gxPQZSMjbynTX74 (from PK since 2018-06-09)

http= s://mailarchive.ietf.org/arch/msg/spring/5PHhLlMIxLgoFdoRC1Wqz6xCBnI&nb= sp; (from PK since 2018-06-09)

https://mailarchive.ietf.org/arch/msg/s=
pring/w0ZmOAcDf_TUUWLkeFk_E6jzQm4 (from Rue=
diger 2018-06-13)

http= s://mailarchive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ (from Shraddha 2018-07-20 & +1 from Sa= sha)

http= s://mailarchive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk (from Sasha & St=E9phane discussion 2018-08-06)

 

 

Authors, Ahmed= ,

Thank you for = engaging the authors of those comments and update the draft.

 

Thank you,

--Bruno

 

 

 

From:<= /b> DECRAENE Bruno IMT/OLN
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls= -13

 

Hi all,

 

A quick update= on the status of this WGLC:

 

- All the auth= ors have responded about IPR (thank you!). Still missing replies from some = contributors (Wim, Edward, Igor, Saku). I’ve sent them a reminder this Monday.

- Two people (= Zafar, Adrian) have responded supporting publication.

- No oppositio= n.

- Two persons = have sent comments (Adrian, myself). Thanks Adrian.

- Authors have= not replied to any comment so far.

- The WGLC per= iod was scheduled to end tomorrow.

 

I wish we had = more support, reviews, and authors’ involvement to reply to reviews.<= o:p>

 

The WGLC is ex= tended by a week. Please review the document and send your comments to the = list, no later than *June 15*

 

Thank you,

--Bruno

 

From:<= /b> bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13<= o:p>

 

Hello Working Group,
    
This email starts a Working Group Last Call on dr=
aft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and =
ready for a final working group review.
    
Please read this document if you haven't read the=
 most recent version yet, and send your comments to the list, no later than=
 *June 08*.
 
As a reminder, this document had already passed a=
 WGLC more than a year ago on version -06 [2], had been sent to the AD but =
then returned to the WG.
Since then, the document has significantly change=
d, so please read it again. In particular, it now includes the resolution i=
n case of incoming label collision. Hence it killed draft-ietf-spring-confl=
ict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd=
. Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG c=
onsensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf=
-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/m=
sg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
______________________________________________________________________=
___________________________________________________
 
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_53C29892C857584299CBF5D05346208A47B69553OPEXCLILM21corp_-- From nobody Mon Oct 15 22:46:02 2018 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 5AF85128D68; Mon, 15 Oct 2018 22:46:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <153966876033.2963.11783048796845322991@ietfa.amsl.com> Date: Mon, 15 Oct 2018 22:46:00 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-msdc-10.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 05:46:01 -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 WG of the IETF. Title : BGP-Prefix Segment in large-scale data centers Authors : Clarence Filsfils Stefano Previdi Gaurav Dawra Ebben Aries Petr Lapukhov Filename : draft-ietf-spring-segment-routing-msdc-10.txt Pages : 24 Date : 2018-10-15 Abstract: This document describes the motivation and benefits for applying segment routing in BGP-based large-scale data-centers. It describes the design to deploy segment routing in those data-centers, for both the MPLS and IPv6 dataplanes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-10 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-msdc-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-10 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 Oct 15 22:46:29 2018 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 75597130DD4; Mon, 15 Oct 2018 22:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EKyjZenZRZ6l; Mon, 15 Oct 2018 22:46:01 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 AA3B812D4E7; Mon, 15 Oct 2018 22:46:00 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id j4-v6so19647844ljc.12; Mon, 15 Oct 2018 22:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WHx0KOsaX/FKVlbp+rH4D7HSMMfxunlZsufIh93lIP4=; b=NNcAHQ9/aKHsTZES7TK8P2t+i5hD805T+a3vH7KNZ7ocWxj2KjE4wspvK0WKAv2KfJ AYCEDyv27NPD37Jlc3HPbk+dB2Q7UoNVuBquss1QwjHr4Fmv4jIqYNDbUWbAyXiXJWtf 5dvA3BlDYtn9v3MUxgXRHQqwW1aakmT2SEuIIZWtU9YuBYVoX9a1zi2+hHMQ4jVPplle g2uRd9idXMVF9gakrnhAyHUdyiyZpKvET1TRf6s+fnp8VEFr4j34ZPS1LpbLs9V7X5ay Qye7/SlynC2iY2P4MJmSjAItD74BR7H4ITq/+DNzKd1FrgG8JKIDBNCyUoSzqBGRZdrG xHyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WHx0KOsaX/FKVlbp+rH4D7HSMMfxunlZsufIh93lIP4=; b=Uk3riYAtp17ih5N+Oib9PrWELLXAjos8KNZLrlIqjOfagtamhMc0yalCpXX3Akvq2x 6ICT75MKiYA5i1m7hLsFvMoLGNMKuVcwEyo3sr/TdM1DOFg1op3DnpQQW6jnYqiR5XPM 2SRdlxMtfA6IWS6+yJHOgIwsQxGUChTyMhdUeDfOBPDkyGmSIfw0wjtYLCmAbSLvkjDZ LKEwYOonJeuhOLC3kalRNNhYsmTNmfj3EiEqZ9iZsEP5h1vjUl56jYB9phGD9svEcMWe JufuaEbv5VwnvFIfNDoo2VpsD4dg/6wglMXyjja5OsOZ/+Wm4kM/3bnb1O5ARDnHFlGk lNiw== X-Gm-Message-State: ABuFfogaXhZCn4337jTb8YKTglqTXM6y8X1sjL9Fx+TzB+Qhzy0PA0Nq oN9EqNxFtvMoeyr6FpMoN0AlATamjD8vY/Q3cGU= X-Google-Smtp-Source: ACcGV63VhcJPtsOO37OkNr71CoHbdtZ4YPF0UR3m9AepsVEnGIR92nElSTO9SrSupxzvhrpaX9e4xBpFz1oL52pelR0= X-Received: by 2002:a2e:8545:: with SMTP id u5-v6mr12541973ljj.164.1539668758503; Mon, 15 Oct 2018 22:45:58 -0700 (PDT) MIME-Version: 1.0 References: <40ED2C86-3403-4D89-8CA8-FBB9651BF2AB@gmail.com> <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> In-Reply-To: From: Gaurav Dawra Date: Mon, 15 Oct 2018 22:45:46 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Alvaro Retana , Martin Stiemerling , SPRING WG , tsv-art@ietf.org Content-Type: multipart/alternative; boundary="0000000000006c2492057852112d" Archived-At: Subject: Re: [spring] [Tsv-art] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 05:46:20 -0000 --0000000000006c2492057852112d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi MIrja, I have posted a new version. Please do let me know if we need to discuss further. We can do it over the phone. Cheers, Gaurav On Mon, Sep 3, 2018 at 4:29 AM Gaurav Dawra wrote: > Hi Mirja, > > Please see inline...[Gaurav2] > > On Thu, Aug 9, 2018 at 8:30 AM Mirja K=C3=BChlewind > wrote: > >> Hi Gaurav, >> >> please see inline. >> >> On 03.08.2018 07:20, Gaurav Dawra wrote: >> >> Hey Mirja, >> >> Sorry for the long delay. I was traveling constantly since IETF and bit >> lost in my mailbox and discussion with Authors. Please see my response >> inline[Gaurav] >> >> >> I think with your changes you addressed explicit problems Martin called >> out, however, I still have high level concerns about these sections as t= hey >> are mostly giving speculative recommendation which are not clear to me t= o >> work in practice. >> >> Regarding section 7.1, you say >> "A flowlet is defined as a burst of packets from the same flow followed >> by an idle interval." >> but then you say >> "...then the application can break the elephant flow F into flowlets F1, >> F2, F3, F4..." >> >> This sounds like you would just divide an elephant flow mostly randomly >> into flowlets which can interact badly with the congestion control. If y= ou >> actually have chunks of data that are transmitted with large enough idle >> interval in between (as you define flowlets in the first sentence), that= is >> not an elephant flow anymore and it will not help you to "spread the loa= d >> of the elephant flow through all the ECMP paths". In summary I actually >> don't see how the concept of flowlets can be helpful to address the prob= lem >> you have at all, and I still advise you to remove section 7.1 entirely. >> >> [Gaurav] Hi Mirja, Thanks for the review. The proposal here is no >> different that current ECMP hashing at flowlet level. The only differenc= e >> which is being pointed out here is that if we use SR, we could leverage = on >> the ability of be aware of multiple disjoint paths rather than the hashi= ng. >> It=E2=80=99s pins the flowlets to particular paths which is basic SR ope= rations. >> >> >> Yes the problem is that we usually don't recommend ECMP hashing on >> flowlet level because it can interact badly with the end-end mechanisms = of >> that flow. As I said, I don't see how the notion of flowlets help you >> problem and therefore I still recommend to remove that paragraph. >> [Gaurav2] OK. It took sometime to get to consensus with authors. Will >> update the text to use 5-tuple flows instead of flowlets. Would that >> suffice? I will update the text shortly. >> >> >> Regarding section 7.2, I also still skeptical about any benefits that ca= n >> be achieved. Given you are in a data center, the controller should alrea= dy >> know about static parameters such as the maximum bandwidth per link. >> >> For dynamic parameters, e.g. like loss rate, measuring them on a per-flo= w >> bases is the wrong thing to do. What I mean is you can ask a router abou= t >> the average loss rate that it observes and that might give you some >> valuable, however, if you ask a TCP flow about the average loss rate the >> answer will mainly depend on the congestion controller used and the >> currently available bandwidth, which is a very dynamic property and not = a >> link characteristic. So this information is not usable for performance >> aware routing. A flow could give you information about the observed RTT >> (min/max) on a certain path, or the maximum available bandwidth on a pat= h, >> but as I said, given you are in a data center environment these are >> information that the controller already should have anyway. >> >> [Gaurav] They are two separate mechanisms. Most DCs have some sort of >> data-plane/ECMP aware tracing mechanism to detect the loss/delays and ca= n >> be combined with Application back-off to detect issue. All this section = is >> suggesting is that SR can be used to pin the path to particular set of E= CMP >> paths instead of relying on ECMP hashing. >> >> >> This is not quite what the text says. If that is the statement you want >> to make, that is fine but then you don't need to talk about performance >> aware routing at all. >> > [Gaurav2] I will update the text here with statement i mentioned above. > IMHO, it's performance aware routing wrt to end-host traffic. > >> >> >> Your example with detecting a faulty path due to losses does not work >> with TCP as you never know if these loses are due to a problem on the pa= th, >> self-induced or by a competing flow. And even if you don't use TCP and e= .g. >> send constant bit rate traffic, there may be a large number of competing >> TCP flows that can induce the loses. Try to steer traffic "away" on a >> time-scale that is slower than TCP dynamics or even your flow dynamic (w= hen >> flows start or end) in case you have a lot of very short flow, in the be= st >> case doesn't work and in the worst case leads to oscillation. >> >> [Gaurav] As I said above, there are other mechanisms to detect loss and >> trace the path on which loss is seen. This is a common mechanism used in >> MSDCs. >> >> I think this is beyond the scope of the document. >> > [Gaurav2] Will update the text. > >> >> >> >> I am happy to discuss further over the phone to try to explain the >> thought process. I will also do check again with Authors to update the t= ext >> or something else based on our conversation. >> >> >> Maybe see if some update can be made to the text first and then we can >> have another discussion if needed. >> [Gaurav2] Sounds good. Will update the text shortly and then we can >> discuss if needed. >> > > Cheers, > > Gaurav > >> >> >> Cheers, >> >> >> >> Gaurav >> >> If you want to make TCP use for handover situation where one path might >> go away or become unusable, it's best to use Multipath TCP (with coupled >> congestion control) instead because that works on the right time scale. >> Again, I don't think this is a use case for SR and I would recommend to >> remove the section entirely. >> >> Mirja >> >> >> >> >> On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra >> wrote: >> >>> Hi Mirja, >>> >>> Ack. Let me work with authors to close ASAP. >>> >>> Cheers, >>> >>> Gaurav >>> >>> Sent from my iPhone >>> >>> On Jul 5, 2018, at 10:06 AM, Mirja K=C3=BChlewind >>> wrote: >>> >>> Hi Gaurav, >>> >>> sorry for my very long delay but this got somehow a bit lost in my >>> mailbox. >>> >>> I think with your changes you addressed explicit problems Martin called >>> out, however, I still have high level concerns about these sections as = they >>> are mostly giving speculative recommendation which are not clear to me = to >>> work in practice. >>> >>> Regarding section 7.1, you say >>> "A flowlet is defined as a burst of packets from the same flow followed >>> by an idle interval." >>> but then you say >>> "...then the application can break the elephant flow F into flowlets F1= , >>> F2, F3, F4..." >>> >>> This sounds like you would just divide an elephant flow mostly randomly >>> into flowlets which can interact badly with the congestion control. If = you >>> actually have chunks of data that are transmitted with large enough idl= e >>> interval in between (as you define flowlets in the first sentence), tha= t is >>> not an elephant flow anymore and it will not help you to "spread the lo= ad >>> of the elephant flow through all the ECMP paths". In summary I actually >>> don't see how the concept of flowlets can be helpful to address the pro= blem >>> you have at all, and I still advise you to remove section 7.1 entirely. >>> >>> Regarding section 7.2, I also still skeptical about any benefits that >>> can be achieved. Given you are in a data center, the controller should >>> already know about static parameters such as the maximum bandwidth per >>> link. For dynamic parameters, e.g. like loss rate, measuring them on a >>> per-flow bases is the wrong thing to do. What I mean is you can ask a >>> router about the average loss rate that it observes and that might give= you >>> some valuable, however, if you ask a TCP flow about the average loss ra= te >>> the answer will mainly depend on the congestion controller used and the >>> currently available bandwidth, which is a very dynamic property and not= a >>> link characteristic. So this information is not usable for performance >>> aware routing. A flow could give you information about the observed RTT >>> (min/max) on a certain path, or the maximum available bandwidth on a pa= th, >>> but as I said, given you are in a data center environment these are >>> information that the controller already should have anyway. >>> >>> Your example with detecting a faulty path due to losses does not work >>> with TCP as you never know if these loses are due to a problem on the p= ath, >>> self-induced or by a competing flow. And even if you don't use TCP and = e.g. >>> send constant bit rate traffic, there may be a large number of competin= g >>> TCP flows that can induce the loses. Try to steer traffic "away" on a >>> time-scale that is slower than TCP dynamics or even your flow dynamic (= when >>> flows start or end) in case you have a lot of very short flow, in the b= est >>> case doesn't work and in the worst case leads to oscillation. >>> >>> If you want to make TCP use for handover situation where one path might >>> go away or become unusable, it's best to use Multipath TCP (with couple= d >>> congestion control) instead because that works on the right time scale. >>> Again, I don't think this is a use case for SR and I would recommend to >>> remove the section entirely. >>> >>> Mirja >>> >>> >>> On 05.07.2018 04:08, Gaurav Dawra wrote: >>> >>> Hey Alvaro, Mirja, >>> >>> Friendly reminder to further progress this document. >>> >>> Cheers, >>> >>> Gaurav >>> >>> On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra >>> wrote: >>> >>>> Hi Alvaro, Mirja >>>> >>>> Any feedback or next steps to close this? >>>> >>>> Cheers, >>>> >>>> Gaurav >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 12, 2018, at 7:06 AM, Gaurav Dawra >>>> wrote: >>>> >>>> Hi Mirja, >>>> >>>> Friendly Reminder...Could you please also advice if there is anything >>>> further to DISCUSS on this document which was also related to TCP upda= tes >>>> below? >>>> >>>> Cheers, >>>> >>>> Gaurav >>>> >>>> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana >>>> wrote: >>>> >>>>> Thanks Martin! >>>>> >>>>> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@gmail.com= ) >>>>> wrote: >>>>> >>>>> Hi Alvaro, all, >>>>> >>>>> Thanks for addressing my concerns. >>>>> >>>>> This version is good to go from my side. >>>>> >>>>> Kind regards, >>>>> >>>>> ;Martin >>>>> >>>>> Am 30.05.18 um 21:55 schrieb Alvaro Retana: >>>>> > Martin: >>>>> > br/>> Hi!! How are you? >>>>> > br/>> Gaurav just posted a revision. Please takke a look and let u= s >>>>> know if br/>> the changes address your concerrns or not. >>>>> > br/>> >>>>> https://www.ietf.org/rfcdiff??url2=3Ddraft-ietf-spring-segment-routin= g-msdc-09 >>>>> > br/>> Thanks!!! >>>>> > br/>> Alvaro. < >>>>> > br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra (( >>>>> gdawra.ietf@gmail.com br/>> ) wrote: >>>>> > br/>>> Hi Martin, < >>>>> >> >>>>> >> Thanks for review. I will post the new version. Hopefully, it will >>>>> br/>>> address all your comments and we can close thhis review. >>>>> >> >>>>> >> Any updates on below response? >>>>> >> >>>>> >> Cheers, >>>>> >> >>>>> >> Gaurav >>>>> >> >>>>> >> Sent from my iPhone >>>>> >> >>>>> >> On May 23, 2018, at 4:17 AM, Gaurav Dawra >>>> br/>>> > wrote: >>>>> >> >>>>> >>> Hi Martin, >>>>> >>> >>>>> >>> Thanks for the review. Any further comments here ? I will post th= e >>>>> br/>>>> new version soon. < >>>>> >>> >>>>> >>> Cheers, >>>>> >>> >>>>> >>> Gaurav >>>>> >>> >>>>> >>> Sent from my iPhone >>>>> >>> >>>>> >>> On May 16, 2018, at 7:44 PM, Gaurav Dawra >>>> br/>>>> >> wrote: >>>>> >>> >>>>> >>>> Hi Martin, >>>>> >>>> >>>>> >>>> Apologies from my end we had few internal authors conversations >>>>> on br/>>>>> the points you have raised. < >>>>> >>>> >>>>> >>>> Please find below my response. I will be happy to discuss >>>>> further, br/>>>>> if needed. < >>>>> >>>> >>>>> >>>> inline... >>>>> >>>> >>>>> >>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling < >>>>> mls.ietf@gmail.com br/>>>>>> > wrote: >>>>> >>>>> >>>>> >>>>> Hi Gaurav, >>>>> >>>>> >>>>> >>>>> This got lost on my end, sorry for this. The filter just moved >>>>> br/>>>>>> these messages out of my sight... :-/ >>>>> >>>>> >>>>> >>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra: >>>>> >>>>>> Hey Martin, >>>>> >>>>>> Sorry for late reply. Please see some comments inline[Gaurav] >>>>> >>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>> >>>>> br/>>>>>>>>; >>>> mls.ietf@gmail.com>> wrote: >>>>> >>>>>>> >>>>> >>>>>>> Hi all, >>>>> >>>>>>> >>>>> >>>>>>> I've reviewed this document as part of the transport area >>>>> review br/>>>>>>>> team's ongoing effort to review key IETF documents= . >>>>> These br/>>>>t;>>>> comments were written primarily for the transpo= rt >>>>> area directors, br/>>>>>>>> but are copied to the doocument's authors= for >>>>> their information br/>>>>>>>&> and to allow them to address any issue= s >>>>> raised. When done at the >>>>> >>>>>>> time of IETF Last Call, the authors should consider this >>>>> review br/>>>>>>>> together with any other last-call comments they re= ceive. >>>>> Please br/>>>&>>>>> always CC tsv-art@=E2=80=A6 if you reply to or fo= rward >>>>> this review. >>>>> >>>>>>> >>>>> >>>>>>> Summary: >>>>> >>>>>>> This draft has serious issues in Section 7..1, 7.2 and in one >>>>> part br/>>>>>>>> of Secction3, described in the review, and needs to = be >>>>> rethought. br/>>&>>>>>> The other sections are good AFAIK. >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> Technicals: >>>>> >>>>>>> The overall draft looks ok, but the three points below look >>>>> br/>>>>>>>> strange and need a fix before publication IMHO: >>>>> >>>>>>> >>>>> >>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not >>>>> well br/>>>>>>>> proven funcationality and not even safe to use >>>>> functionality. br/>>>&>>>>> Both are some sort discussing that differ= ent >>>>> paths in the network br/>>>>>>>> could be used by the eend host traff= ic. >>>>> This sounds pretty much br/>>>>>>>t;> like the Path Aware Networkin= g >>>>> Proposed Research Group br/>>t;>>>>>> (https://irtf.org/panrg) and >>>>> hints to the fact that there is no br/>>>>>>>> commonly understannd a= nd >>>>> accepted engineering solution in this space. >>>>> >>>>>>> >>>>> >>>>>>> Section 7.1: >>>>> >>>>>>> [KANDULA04] is a really old reference that hasn't been >>>>> followed br/>>>>>>>> up iin recent times and even worse there is no >>>>> evidence that this br/>>t;>>>>>> is going to work good enough or st= able >>>>> enough under real Internet br/>>>>>>>> traffic. Additioonally, it is = more >>>>> than unclear how any modern TCP br/>>>>&ggt;>>> implementation will r= eact >>>>> to this >>>>> >>>>>> [Gaurav] Will get back on this. >>>>> >>>>> >>>>> >>>>> I will reply to the other email dicussing this. >>>>> >>>> I have replied to other thread. >>>>> >>>>> >>>>> >>>>>>> >>>>> >>>>>>> Section 7.2: >>>>> >>>>>>> This section describes an idea without detailing too much >>>>> about br/>>>>>>>> any furtther aspects. Further it changes the common= ly >>>>> accepted br/>>>;>>>>> notion of what an end host can do with the netw= ork. >>>>> At best this br/>>>>>>>> would require a good ddefinition of what an = end >>>>> host in your br/>>>>>>>&ggt; setting is, e.g., a highly modified piec= e of >>>>> (at least) software >>>>> >>>>>>> that usually not found in OS availble on the market (yet?) >>>>> >>>>>>> Further communicating instantaneous path characteristics to a >>>>> br/>>>>>>>> central point is potentially a bad idea, as the data is a= lready >>>>> br/>>>;>>>>> outdated when reported by any node. >>>>> >>>>>> [Gaurav] I believe Authors are trying to highlight that Host >>>>> which br/>>>>>>> is defineed in br/>>>>>>> ( >>>>> https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) >>>>> br/>>>>>>> can innfluence the traffic based on the Calculations local= ly or >>>>> br/>>>t;>>>> jointly with the controller. Implementations can decid= e how >>>>> much br/>>>>>>> Centralized -vs- localized coontrol is allowed at Hos= t >>>>> based on br/>>>>>>> perfoormance data collection. >>>>> >>>>> >>>>> >>>>> Performance data collection (monitoring?) isn't crucial when it >>>>> br/>>>>>> comes to timely (actuaally real-time) reaction. However, th= is >>>>> br/>>>>>> secttion isn't just about performance data collection as it= is >>>>> about br/>>>>>>> "Performance-aware routing" this seems to try to int= eract >>>>> in br/>>>>>> real-time with the network behhavior of TCP. This isn't = even >>>>> close br/>>>>>> to acceeptable. >>>>> >>>>> >>>>> >>>>> I would be ok to say that it is useful to collect performance >>>>> data br/>>>>>> for offline analysis and improvement of the data netwo= rk. >>>>> However, br/>>>>>&ggt; this is at completely different magnitues of t= ime >>>>> scales. >>>>> >>>>> >>>>> >>>>> I would recommend to remove the TCP part from this section >>>>> entirely. >>>>> >>>> Ack, will update in next rev: >>>>> >>>> >>>>> >>>> Section will read like this: >>>>> >>>> >>>>> >>>> ; >>>>> >>>> /Knowing the path associated with flows/packets, the end host >>>>> may/ >>>>> >>>> /deduce certain characteristics of the path on its own, and/ >>>>> >>>> /additionally use the information supplied with path information= / >>>>> >>>> /pushed from the controller or received via pull request. The >>>>> host/ >>>>> >>>> /may further share its path observations with the centralized >>>>> agent,/ >>>>> >>>> /so that the latter may keep up-to-date network health map to >>>>> assist/ >>>>> >>>> /other hosts with this information./ >>>>> >>>> // >>>>> >>>> /For example, an application A.1 at HostA may pin a flow >>>>> destined/ >>>>> >>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. >>>>> The/ >>>>> >>>> /application A.1 may collect information on packet loss, deduced >>>>> from/ >>>>> >>>> /Other offline mechanisms. [There are some pingMesh mechanisms >>>>> which / >>>>> >>>> /Can be used here]/ >>>>> >>>> /Through these mechanisms information to a centralized agent, >>>>> e.g./ >>>>> >>>> /after a flow completes, or periodically for longer lived flows.= / >>>>> >>>> /Next, using both local and/or global performance data, >>>>> application/ >>>>> >>>> /A.1 as well as other applications sharing the same resources in >>>>> the/ >>>>> >>>> /DC fabric may pick up the best path for the new flow, or update >>>>> an/ >>>>> >>>> /existing path (e.g.: when informed of congestion on an existing= / >>>>> >>>> /path)./ >>>>> >>>> ; >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> >>>>> >>>>>>> Section 3, 3rd bullet point: >>>>> >>>>>>> It is the foundation of TCP that the network is regarded as a >>>>> br/>>>>>>>> black box and that you infer from the transmission of pac= kets >>>>> br/>>>>;>>>> what the current state of the network path is. Inferring >>>>> network br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a = bad >>>>> idea, as br/>>>>>>>>; this would required that all paths exhibit this= and >>>>> if not what br//>>>>>>>> is going to happen? >>>>> >>>>>>> It could be an interesting research field to change many >>>>> points br/>>>>>>>> in TCP'ss behavior, but this once again points to = the >>>>> fact that br/>>>&>>>>> this not the IETF works but IRTF or elsewhere. >>>>> >>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is >>>>> rightly br/>>>>>>> treating Network as Black Box. Authors are implyin= g per >>>>> path br/>>>>;>>> performance metrics as not cached. Is there some cha= nge in >>>>> text br/>>>>>>> you are suggesting?? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I would recommend to remove the 3rd bullet point completey. TCP >>>>> br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is >>>>> br/>>>>>> something the network could decide, e.g., rerouting TCP flo= ws >>>>> br/>&ggt;>>>> within the network or changing the forwarding path in t= he >>>>> network br/>>>>>> for particular flows (if it is not routed). >>>>> >>>> >>>>> >>>> Ack, after discussion, we will remove the Section 3 - >>>>> 3rd br/>>>>> bullet point. Willl update in next rev - coming shortly. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> >>>>> Martin >>>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Tsv-art mailing listTsv-art@ietf.orghttps://www.ietf.org/mailman/listin= fo/tsv-art >>> >>> >>> >> >> --0000000000006c2492057852112d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi MIrja,

I have posted a new version. = Please do let me know if we need=C2=A0to discuss further. We can do it over= =C2=A0the phone.

Cheers,

= Gaurav


On Mon, Sep 3, 2018 at 4:29 AM Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Mirja,

Please = see inline...[Gaurav2]

On Thu, Aug 9, 2018 at 8:30 AM Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
=20 =20 =20
Hi Gaurav,

please see inline.

On 03.08.2018 07:20, Gaurav Dawra wrote:
=20
Hey Mirja,

Sorry for the long delay. I was traveling constantly since IETF and bit lost in my mailbox and discussion with Authors. Please see my response inline[Gaurav]


I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.

Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the applicat= ion can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow through all the ECMP paths". In summar= y I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.<= /span>

[Gaurav] Hi Mirja, Thanks for the review. The proposal here is no different that current ECMP hashing at flowlet level. The only difference which is being pointed out here is that if we use SR, we could leverage on the ability of be aware of multiple disjoint paths rather than the hashing. It=E2=80=99s pins the flowlets to particular paths which is basic SR operations.


Yes the problem is that we usually don't recommend ECMP hashing on flowlet level because it can interact badly with the end-end mechanisms of that flow. As I said, I don't see how the notion of flowlets help you problem and therefore I still recommend to remove that paragraph.
[Gaurav2] OK. It took sometime to get to consensus with authors. Will u= pdate the text to use 5-tuple flows instead of flowlets. Would that suffice= ? I will update the text shortly.


Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link.

For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.

[Gaurav] They are two separate mechanisms. Most DCs have some sort of data-plane/ECMP aware tracing mechanism to detect the loss/delays and can be combined with Application back-off to detect issue. All this section is suggesting is that SR can be used to pin the path to particular set of ECMP paths instead of relying on ECMP hashing.


This is not quite what the text says. If that is the statement you want to make, that is fine but then you don't need to talk about performance aware routing at all.
= [Gaurav2] I will update the text here with statement i mentioned above. IMH= O, it's performance aware routing wrt to end-host traffic.=C2=A0 =C2=A0=


Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away" on a time-scale that is= slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.

[Gaurav] As I said above, there are other mechanisms to detect loss and trace the path on which loss is seen. This is a common mechanism used in MSDCs.

I think this is beyond the scope of the document.=C2=A0
[Gaurav2] Will update the text.

=C2=A0

I am happy to discuss further over the phone to try to explain the thought process. I will also do check again with Authors to update the text or something else based on our conversation.


Maybe see if some update can be made to the text first and then we can have another discussion if needed.
[Gaurav2] Sounds good. Will update the text shortly and then we can dis= cuss if needed.

Cheers,

Gaurav=C2=A0

=C2=A0

Cheers,

=C2=A0

Gaurav

If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for SR and I would recommend to remove the section entirely.

Mirja<= sub><= /span>

=C2=A0



On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Mirja,

Ack. Let me work with authors to close ASAP.

Cheers,

Gaurav

Sent from my iPhone

On Jul 5, 2018, at 10:06 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:

Hi Gaurav,

sorry for my very long delay but this got somehow a bit lost in my mailbox.

I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.

Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the application can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow throug= h all the ECMP paths". In summary I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.

Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link. For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.

Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away= " on a time-scale that is slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.

If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for S= R and I would recommend to remove the section entirely.

Mirja


On 05.07.2018 04:08, Gaurav Dawra wrote:
Hey Alvaro, Mirja,=C2=A0

Friendly reminder to further progress this document.

Cheers,

Gaurav

On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra <gdawra.= ietf@gmail.com> wrote:
Hi Alvaro, Mirja=C2=A0

Any feedback or next steps to close this?

Cheers,

Gaurav

Sent from my iPhone

On Jun 12, 2018, at 7:06 AM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:

Hi Mirja,

Friendly Reminder...Could you please also advice if there is anything further to DISCUSS on this document which was also related to TCP updates below?

Cheers,

Gaurav
=
On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <aretana.i= etf@gmail.com> wrote:

Thanks Martin!

On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@gmail.com) wrote:

Hi Alvaro, all,

Thanks for addressing my concerns.

This version is good to go from my side.

Kind regards,

;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> br/>> Hi!!=C2=A0 How ar= e you?
> br/>> Gaurav just posted a revision.=C2=A0 Please takke a look and let us know if br/>> the changes address your concerrns or not.
> br/>> https://www.ietf.org/rfcdiff??url2=3Ddraft-iet= f-spring-segment-routing-msdc-09
> br/>> Thanks!!!
> br/>> Alvaro. <
> br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((gdawra.ietf@gmail.com br/>> <mailto:gdawra.ietf@@gmail.com>) wrote:
> br/>>> Hi Martin, <
>>
>> Thanks for review. I will post the new version. Hopefully, it will br/>>> address all your comments and we can close thhis review.
>>
>> Any updates on below response?
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>= > On May 23, 2018, at 4:17 AM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>> <mailto:gdawra.ietf@@gmail.com>> wrote:
>>
>>> Hi Martin,
>>>
>>&g= t; Thanks for the review. Any further comments here ? I will post the br/>>>&g= t; new version soon. <
>>>= ;
>>> Cheers,
>>>
>>> Gaurav
>>>
>>> Sent from my iPhone
>>>
>= >> On May 16, 2018, at 7:44 PM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>>&g= t; <mailto:gdawra.ietf@@gmail..com>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>&g= t;> Apologies from my end we had few internal authors conversations on br/>>>&g= t;> the points you have raised. <
>>>>
>>>> Please find below my response. I will be happy to discuss further, br/>>>&g= t;> if needed. <
>>>>
>>>> <Gaurav> inline...
>>>= ;>
>>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <mls.ietf@gmail.com br/>>>>>> <mailto:mls.iietf@gmail.com>> wrote:
>>>>>
>>>>> Hi Gaurav,
>>>>>
>>&g= t;>> This got lost on my end, sorry for this. The filter just moved br/>>>&g= t;>> these messages out of my sight... :-/
>>>= ;>>
>>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
>>>>>> Hey Martin,
>>>>>> Sorry for late reply. Please see some comments inline[Gaurav]
>= >>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>&g= t;>>>> <mls.ietf@@gmail.com <mailto:mls.ietf@gmail.com>= ; br/>>>>>>>>; <mailto:mls.ietf@gmail.com>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>&g= t;>>>> I've reviewed this document as part of the transport area review br/>>>&g= t;>>>> team's ongoin= g effort to review key IETF documents. These br/>>>&a= mp;gtt;>>>> comments were written primarily for the transport area directors, br/>>>&g= t;>>>> but are copied to the doocument's authors for their information br/>>>&g= t;>>>&> and to allow them to address any issues raised. When done at the
>>>>>>> time of IETF Last Call, the authors should consider this review br/>>>&g= t;>>>> together with any other last-call comments they receive. Please br/>>>&a= mp;>>>>> always CC tsv-art@=E2=80=A6= if you reply to or forward this review.
>>>>>>>
>>>>>>> Summary:
>>>>>>> This draft has serious issues in Section 7..1, 7.2 and in one part br/>>>&g= t;>>>> of Secction3, described in the review, and needs to be rethought. br/>>&>>>>>> The other sections are good AFAIK.
>>>>>>>
>>>>>>>
>>>>>>> Technicals:
>>>>>>> The overall draft looks ok, but the three points below look br/>>>&g= t;>>>> strange and need a fix before publication IMHO:
>>>>>>>
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well br/>>>&g= t;>>>> proven funcationality and not even safe to use functionality. br/>>>&>>>>> Both are some sort discussing that different paths in the network br/>>>&g= t;>>>> could be used by the eend host traffic. This sounds pretty much br/>>>>>>&gtt;> like the Path Aware Networking Proposed Research Group br/>&gtt;>>>>>> (https://irtf.org/panrg) and hints to the fact that there is no br/>>>&g= t;>>>> commonly understannd and accepted engineering solution in this space.
>>>>>>>
>>>>>>> Section 7.1:
>>>>>>> [KANDULA04] is a really old reference that hasn't been followed br/>>>&g= t;>>>> up iin recent times and even worse there is no evidence that this br/>&gtt;&= gt;>>>>> is going to work good enough or stable enough under real Internet br/>>>&g= t;>>>> traffic. Additioonally, it is more than unclear how any modern TCP br/>>>&g= t;&ggt;>>> implementation will react to this
>>>= ;>>> [Gaurav] Will get back on this.
>>>>>
>>>>> I will reply to the other email dicussing this.
>>>> <Gaurav> I have replied to other thread.
>>>>>
>>>>>>>
>>>>>>> Section 7.2:
>>&g= t;>>>> This section describes an idea without detailing too much about br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted br/>>>;&= gt;>>>> notion of what an end host can do with the network. At best this br/>>>&g= t;>>>> would require a good ddefinition of what an end host in your br/>>>&g= t;>>>&ggt; setting is, e.g., a highly modified piece of (at least) software
>>>= ;>>>> that usually not found in OS availble on the market (yet?)
>>&g= t;>>>> Further communicating instantaneous path characteristics to a br/>>>&g= t;>>>> central point is potentially a bad idea, as the data is already br/>>>;>>>>> outdated when reported by any node.
>>>>>> [Gaurav] I believe Authors are trying to highlight that Host which br/>>>&g= t;>>> is defineed in br/>>>>>>> (https://tools.ietf.or= g/html/draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the traffic based on the Calculations locally or br/>>&g= tt;>>>> jointly with the controller. Implementations can decide how much br/>>>&g= t;>>> Centralized -vs- localized coontrol is allowed at Host based on br/>>>>>>> perfoormance data collection.
>>>>>
>>>>> Performance data collection (monitoring?) isn't crucial when it br/>>>&g= t;>> comes to timely (actuaally real-time) reaction. However, this br/>>>>>> secttion isn't just about performance data collection as it is about br/>>>&g= t;>>> "Performance-aware routing" this seems to try to interact in br/>>>&g= t;>> real-time with the network behhavior of TCP. This isn't even close br/>>>&g= t;>> to acceeptable.
>>>>>
>>>>> I would be ok to say that it is useful to collect performance data br/>>>&g= t;>> for offline analysis and improvement of the data network. However, br/>>>&g= t;>&ggt; this is at completely different magnitues of time scales.
>>>= ;>>
>>>>> I would recommend to remove the TCP part from this section entirely.
>>>> <Gaurav>Ack, will update in next rev:
>>>>
>>>> Section will read like this:
>>>>
>>>> ;
>>>> /Knowing the path associated with flows/packets, the end host may/
>>>> /deduce certain characteristics of the path on its own, and/
>>>> /additionally use the information supplied with path information/
>>>> /pushed from the controller or received via pull request. The host/
>>>> /may further share its path observations with the centralized agent,/
>>>> /so that the latter may keep up-to-date network health map to assist/
>>>> /other hosts with this information./
>>>> //
>>>> /For example, an application A.1 at HostA may pin a flow destined/
>>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/
>>>> /application A.1 may collect information on packet loss, deduced from/
>>>> /Other offline mechanisms. [There are some pingMesh mechanisms which /
>>>> /Can be used here]/
>>>> /Through these mechanisms information to a centralized agent, e.g./
>>>> /after a flow completes, or periodically for longer lived flows./
>>>> /Next, using both local and/or global performance data, application/
>>>> /A.1 as well as other applications sharing the same resources in the/
>>>> /DC fabric may pick up the best path for the new flow, or update an/
>>>> /existing path (e.g.: when informed of congestion on an existing/
>>>> /path)./
>>>> ;
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> Section 3, 3rd bullet point:
>>&g= t;>>>> It is the foundation of TCP that the network is regarded as a br/>>>>>>>> black box and that you infer from the transmission of packets br/>>>>;>>>> what the current state of the network path is. Inferring network br/>>>&g= t;>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as br/>>>&g= t;>>>>; this would required that all paths exhibit this and if not what br//>>>&= gt;>>>> is going to happen?
>>>>>>> It could be an interesting research field to change many points br/>>>&g= t;>>>> in TCP'ss behavior, but this once again points to the fact that br/>>>&a= mp;>>>>> this not the IETF works but IRTF or elsewhere.
>>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly br/>>>&g= t;>>> treating Network as Black Box. Authors are implying per path br/>>>&g= t;;>>> performance metrics as not cached. Is there some change in text br/>>>>>>> you are suggesting??
>>>>>
>>>>>
>>>>> I would recommend to remove the 3rd bullet point completey. TCP br/>>>>>> isn't the place to rememmber "good&quo= t; or "bad" paths. This is br/>>>>>> something the network could decide, e.g., rerouting TCP flows br/>&ggt;&= gt;>>> within the network or changing the forwarding path in the network br/>>>&g= t;>> for particular flows (if it is not routed).
>>>>
>>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd br/>>>&g= t;> bullet point.=C2=A0Willl update in next rev - coming shortly.
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> =C2=A0Martin
>>>>>
>>>> 




__________________________________________=
_____
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art



--0000000000006c2492057852112d-- From nobody Wed Oct 17 11:52:23 2018 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 A9186130E19; Wed, 17 Oct 2018 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeCkbLmA0DbE; Wed, 17 Oct 2018 11:52:16 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 91DCF130EDD; Wed, 17 Oct 2018 11:52:16 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9HIo9q0001049; Wed, 17 Oct 2018 11:52:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=IbjgVsSRKfzQMI9+yO2f234SxNA7RL/ITMw6A3U7YlQ=; b=uo8+2E/SMmANuaNY+6P3gmfRagZ7qQ5K129AbLnkueiN42Vj3y7Hu/77KnXfQml730C0 dirgzVxjsMD0smiy6C/DWV5nJK9Bzi3oK3541Y83M6I/qK9+hg4iwVJ2nsK5zgGcH19R Cw0EMnjj7I0ofALmUZLdnVVPYLnL/HrDrKjrEJKS4TLYdAW1dbRkAVyOLtvh+GjBElc6 sEK3PSFRR/uyEVGeVKz+VawWm62uJiFTONic6YsiTTT3YR1UlWYzwmnvssp+CPaLmzFP G5CX9sp6pNJ+wJWFoqYlYNfuJ2sqZbYMRdASHyt0y/4VUdP1ZTKQm1hqZWFvVP5DbgQf OA== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0051.outbound.protection.outlook.com [216.32.181.51]) by mx0b-00273201.pphosted.com with ESMTP id 2n69dyg5v2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Oct 2018 11:52:15 -0700 Received: from BYAPR05MB3943.namprd05.prod.outlook.com (52.135.195.146) by BYAPR05MB5288.namprd05.prod.outlook.com (20.177.126.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.18; Wed, 17 Oct 2018 18:52:12 +0000 Received: from BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::b5ef:187a:d2a8:984c]) by BYAPR05MB3943.namprd05.prod.outlook.com ([fe80::b5ef:187a:d2a8:984c%5]) with mapi id 15.20.1250.014; Wed, 17 Oct 2018 18:52:12 +0000 From: Shraddha Hegde To: "spring-chairs@ietf.org" CC: "spring@ietf.org" Thread-Topic: New version draft-hegde-spring-node-protection-for-sr-te-paths-04 Thread-Index: AdRmSiBeZfzK0nfZRcaN2KK/go7mBQ== Date: Wed, 17 Oct 2018 18:52:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [116.197.184.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5288; 6:dFSyKLDSxG+FqYxOsAkZ+WDYy0WtEksZm1mZ9yXQ4WM0xFNjU/JbxJcjQJMgKHxsEyeTAjP1eDs+5dvOyu9SPEQIjwN+12ylbj/VYyS5ftlVv6tTD1YJ5+D1VUhMv/eJbnsJC1BYO2X73xBhegX526L3us3rw2S1E7ljon968UdeEPy2N7gjkaexLtFMrfnTbN2AzMJiV0e/ZPwljXsam60wrHXKAvPBmingteetTwpsabnDwgKQti3V3RblaE88DEjoym1JOsg4IrHWc92RF8MPySsybZI86xYLb4mfgYNx7BNjUOB/WepT7nZHEd80aea+XXEi9nXI6ITmXF5tz00xL/E7OuMfWBuxOdmteDFV7JJwuChwd1fcZ3O/OvALQu0UZa+AoWw2YcH7R88oWl0TReB1gM0N0nvNXogMzmK+pcS1LU4bukuzcJNtpDdoqwNMiSlp7dEdvH2blCOehg==; 5:7Z/gsuLxyC557caEhNC3dlPtz3K3l/b2pAx5vBPztRvllbD9ZRMZ4fPWUQS6LftO1vzFyWXDwmygBNJ4j7RbYSyi55Ec4D1Je0wc3SrZY7I2DNUYs69JoUJfdkvDyZSOuLb2vMok5FMZThgxpZKjJHDfJCX4sYjE873spt0vd3A=; 7:SX9820lhx/cv2siSFmaUDGeOFdv/Ae4FKgcZlq7KuKbSTGsjPOf+M3nS4GTyjjaOMXH8sHYzYIozZDvkgHdpt8kbRyFOmf0Ck3ObuxeU8Al6PwxztWuyQubuxLOght1PcQnlFS+8Bji0HXaYLiyDard+HeN+WrhqN9V4e3r9bE0cyCAGMBOT207cb+xK8DCHL8MhaVrc+4Kg8Rb3Orw/8jfwPzeYZ6paxpIKpZftJvqVrkpZOOqMLVK+aOGlo1Cp x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9cfc0ed0-918b-41f4-e272-08d63461a649 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5288; x-ms-traffictypediagnostic: BYAPR05MB5288: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(4982022)(52105095)(3002001)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB5288; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5288; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(136003)(396003)(346002)(189003)(199004)(6116002)(2906002)(71200400001)(71190400001)(7736002)(53936002)(8676002)(99286004)(8936002)(68736007)(9686003)(102836004)(81166006)(2900100001)(81156014)(6306002)(2351001)(7696005)(305945005)(3846002)(55016002)(5660300001)(105586002)(106356001)(86362001)(74316002)(6916009)(316002)(256004)(966005)(2501003)(5250100002)(4744004)(186003)(25786009)(450100002)(97736004)(5640700003)(6436002)(6506007)(476003)(486006)(33656002)(4326008)(14454004)(478600001)(66066001)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5288; H:BYAPR05MB3943.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: +w7f8yXrL/EoUWUxPMIJtJPkQoJMQ7SAfKnA0bHzKAQ0yCd8RXElV0BxISFr2y/Jpt/WuTMWiPFyGePF4wzGqKWBAgUKtlkH3kdNy+ODbbnuTDUDQ/4OhIY7r5RqE2XqxySDNs3By7lmhhmD1Au9S1TMULrYDEao/+6GQvMSLKDuH0w5pcprOv88gc8Q7ANr14A4GIph7PAE38a9EVtR/y6BmaisdEmUHrV8FYQhcP+tU5r+piVxcZka7tVIm1tu83DxMirgWhJRw5QPqiYt/Kw7x32ht49WlfImTJORwER9bVyKZCXVZP6LEMeWHAUZmPkMGJdPkM6mrILMazfnywgOFKH9MdPb0dN0Faeztt4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR05MB39432F82915BCB7945FE4075D5FF0BYAPR05MB3943namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9cfc0ed0-918b-41f4-e272-08d63461a649 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 18:52:12.4164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5288 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170156 Archived-At: Subject: [spring] New version draft-hegde-spring-node-protection-for-sr-te-paths-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 18:52:19 -0000 --_000_BYAPR05MB39432F82915BCB7945FE4075D5FF0BYAPR05MB3943namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chairs, We have posted a New version of draft draft-hegde-spring-node-protection-fo= r-sr-te-paths. This draft has been presented multiple times and we have addressed the comm= ents received. Authors of the draft would like to ask for working group adoption. https://datatracker.ietf.org/doc/draft-hegde-spring-node-protection-for-sr-= te-paths/ Rgds Shraddha --_000_BYAPR05MB39432F82915BCB7945FE4075D5FF0BYAPR05MB3943namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Chairs,
 
We have posted a New version of draft draft-hegde-spring-node-protecti= on-for-sr-te-paths.
This draft has been presented multiple times and we have addressed the= comments received.
Authors of the draft would like to ask for working group adoption.
 
 
 
Rgds
Shraddha
 
 --_000_BYAPR05MB39432F82915BCB7945FE4075D5FF0BYAPR05MB3943namp_-- From nobody Thu Oct 18 03:25:48 2018 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 BD9E612D4ED; Thu, 18 Oct 2018 03:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 gT6XZME_34Dx; Thu, 18 Oct 2018 03:25:35 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 248A512D4E9; Thu, 18 Oct 2018 03:25:35 -0700 (PDT) Received: from nb-10688.ethz.ch ([82.130.103.20]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpa id 1gD5Uj-0002XQ-Lm; Thu, 18 Oct 2018 12:25:33 +0200 To: Gaurav Dawra Cc: Martin Stiemerling , SPRING WG , tsv-art@ietf.org, Alvaro Retana References: <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> From: =?UTF-8?Q?Mirja_K=c3=bchlewind_=28IETF=29?= Message-ID: <870b223b-5fa7-e5f3-919f-f36521d69d68@kuehlewind.net> Date: Thu, 18 Oct 2018 12:25:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------575845898AD8FA365B1C152C" Content-Language: en-US X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1539858335;c2f1fa98; X-HE-SMSGID: 1gD5Uj-0002XQ-Lm Archived-At: Subject: Re: [spring] [Tsv-art] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 10:25:40 -0000 This is a multi-part message in MIME format. --------------575845898AD8FA365B1C152C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Gaurav, thanks for your edits but unfortunately they don't address my concerns. Saying that a flowlet is per 5-tuple is just a clarification of what a flowlet is but doeen't change anything about what the text says. Please consider removing section 7 entirely because this is really beyond the doc of this document and would need further discussion in one or multiple separate documents. Why is that not an option for the authors? Why do you think that section 7 is important for this document? Mirja On 16.10.18 07:45, Gaurav Dawra wrote: > Hi MIrja, > > I have posted a new version. Please do let me know if we need to > discuss further. We can do it over the phone. > > Cheers, > > Gaurav > > > On Mon, Sep 3, 2018 at 4:29 AM Gaurav Dawra > wrote: > > Hi Mirja, > > Please see inline...[Gaurav2] > > On Thu, Aug 9, 2018 at 8:30 AM Mirja Kühlewind > > wrote: > > Hi Gaurav, > > please see inline. > > On 03.08.2018 07:20, Gaurav Dawra wrote: >> Hey Mirja, >> >> Sorry for the long delay. I was traveling constantly since >> IETF and bit lost in my mailbox and discussion with Authors. >> Please see my response inline[Gaurav] >> >> _ >> I think with your changes you addressed explicit problems >> Martin called out, however, I still have high level concerns >> about these sections as they are mostly giving speculative >> recommendation which are not clear to me to work in practice. >> >> Regarding section 7.1, you say _ >> "A flowlet is defined as a burst of packets from the same >> flow followed by an idle interval." >> _but then you say _ >> "...then the application can break the elephant flow F into >> flowlets F1, F2, F3, F4..." >> >> This sounds like you would just divide an elephant flow >> mostly randomly into flowlets which can interact badly with >> the congestion control. If you actually have chunks of data >> that are transmitted with large enough idle interval in >> between (as you define flowlets in the first sentence), that >> is not an elephant flow anymore and it will not help you to >> "spread the load of the elephant flow through all the ECMP >> paths". In summary I actually don't see how the concept of >> flowlets can be helpful to address the problem you have at >> all, and I still advise you to remove section 7.1 entirely. >> >> _[Gaurav] Hi Mirja, Thanks for the review. _The proposal here >> is no different that current ECMP hashing at flowlet level. >> The only difference which is being pointed out here is that >> if we use SR, we could leverage on the ability of be aware of >> multiple disjoint paths rather than the hashing. It’s pins >> the flowlets to particular paths which is basic SR operations. >> > > Yes the problem is that we usually don't recommend ECMP > hashing on flowlet level because it can interact badly with > the end-end mechanisms of that flow. As I said, I don't see > how the notion of flowlets help you problem and therefore I > still recommend to remove that paragraph. > [Gaurav2] OK. It took sometime to get to consensus with > authors. Will update the text to use 5-tuple flows instead of > flowlets. Would that suffice? I will update the text shortly. >> >> _ >> Regarding section 7.2, I also still skeptical about any >> benefits that can be achieved. Given you are in a data >> center, the controller should already know about static >> parameters such as the maximum bandwidth per link. >> >> _For dynamic parameters, e.g. like loss rate, measuring them >> on a per-flow bases is the wrong thing to do. What I mean is >> you can ask a router about the average loss rate that it >> observes and that might give you some valuable, however, if >> you ask a TCP flow about the average loss rate the answer >> will mainly depend on the congestion controller used and the >> currently available bandwidth, which is a very dynamic >> property and not a link characteristic. So this information >> is not usable for performance aware routing. A flow could >> give you information about the observed RTT (min/max) on a >> certain path, or the maximum available bandwidth on a path, >> but as I said, given you are in a data center environment >> these are information that the controller already should have >> anyway. >> >> _[Gaurav] They are two separate mechanisms. _Most DCs have >> some sort of data-plane/ECMP aware tracing mechanism to >> detect the loss/delays and can be combined with Application >> back-off to detect issue. All this section is suggesting is >> that SR can be used to pin the path to particular set of ECMP >> paths instead of relying on ECMP hashing. >> > > _This is not quite what the text says. If that is the > statement you want to make, that is fine but then you don't > need to talk about performance aware routing at all. > > [Gaurav2] I will update the text here with statement i mentioned > above. IMHO, it's performance aware routing wrt to end-host traffic. > > >> _ >> Your example with detecting a faulty path due to losses does >> not work with TCP as you never know if these loses are due to >> a problem on the path, self-induced or by a competing flow. >> And even if you don't use TCP and e.g. send constant bit rate >> traffic, there may be a large number of competing TCP flows >> that can induce the loses. Try to steer traffic "away" on a >> time-scale that is slower than TCP dynamics or even your flow >> dynamic (when flows start or end) in case you have a lot of >> very short flow, in the best case doesn't work and in the >> worst case leads to oscillation. >> >> _[Gaurav] As _I said above, there are other mechanisms to >> detect loss and trace the path on which loss is seen. This is >> a common mechanism used in MSDCs. >> > _I think this is beyond the scope of the document. > > [Gaurav2] Will update the text. > > >> _ >> >> _ >> >> _I am happy to discuss further over the phone to try to >> explain the thought process. I will also do check again with >> Authors to update the text or something else based on our >> conversation. >> > > Maybe see if some update can be made to the text first and > then we can have another discussion if needed. > [Gaurav2] Sounds good. Will update the text shortly and then > we can discuss if needed. > > > Cheers, > > Gaurav > >> _ >> >> _ >> >> _Cheers, >> >> _ >> >> _Gaurav >> >> If you want to make TCP use for handover situation where one >> path might go away or become unusable, it's best to use >> Multipath TCP (with coupled congestion control) instead >> because that works on the right time scale. Again, I don't >> think this is a use case for SR and I would recommend to >> remove the section entirely. >> >> Mirja _ >> >> _ >> >> >> >> On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra >> > wrote: >> >> Hi Mirja, >> >> Ack. Let me work with authors to close ASAP. >> >> Cheers, >> >> Gaurav >> >> Sent from my iPhone >> >> On Jul 5, 2018, at 10:06 AM, Mirja Kühlewind >> > wrote: >> >>> Hi Gaurav, >>> >>> sorry for my very long delay but this got somehow a bit >>> lost in my mailbox. >>> >>> I think with your changes you addressed explicit >>> problems Martin called out, however, I still have high >>> level concerns about these sections as they are mostly >>> giving speculative recommendation which are not clear to >>> me to work in practice. >>> >>> Regarding section 7.1, you say >>> "A flowlet is defined as a burst of packets from the >>> same flow followed by an idle interval." >>> but then you say >>> "...then the application can break the elephant flow F >>> into flowlets F1, F2, F3, F4..." >>> >>> This sounds like you would just divide an elephant flow >>> mostly randomly into flowlets which can interact badly >>> with the congestion control. If you actually have chunks >>> of data that are transmitted with large enough idle >>> interval in between (as you define flowlets in the first >>> sentence), that is not an elephant flow anymore and it >>> will not help you to "spread the load of the elephant >>> flow through all the ECMP paths". In summary I actually >>> don't see how the concept of flowlets can be helpful to >>> address the problem you have at all, and I still advise >>> you to remove section 7.1 entirely. >>> >>> Regarding section 7.2, I also still skeptical about any >>> benefits that can be achieved. Given you are in a data >>> center, the controller should already know about static >>> parameters such as the maximum bandwidth per link. For >>> dynamic parameters, e.g. like loss rate, measuring them >>> on a per-flow bases is the wrong thing to do. What I >>> mean is you can ask a router about the average loss rate >>> that it observes and that might give you some valuable, >>> however, if you ask a TCP flow about the average loss >>> rate the answer will mainly depend on the congestion >>> controller used and the currently available bandwidth, >>> which is a very dynamic property and not a link >>> characteristic. So this information is not usable for >>> performance aware routing. A flow could give you >>> information about the observed RTT (min/max) on a >>> certain path, or the maximum available bandwidth on a >>> path, but as I said, given you are in a data center >>> environment these are information that the controller >>> already should have anyway. >>> >>> Your example with detecting a faulty path due to losses >>> does not work with TCP as you never know if these loses >>> are due to a problem on the path, self-induced or by a >>> competing flow. And even if you don't use TCP and e.g. >>> send constant bit rate traffic, there may be a large >>> number of competing TCP flows that can induce the loses. >>> Try to steer traffic "away" on a time-scale that is >>> slower than TCP dynamics or even your flow dynamic (when >>> flows start or end) in case you have a lot of very short >>> flow, in the best case doesn't work and in the worst >>> case leads to oscillation. >>> >>> If you want to make TCP use for handover situation where >>> one path might go away or become unusable, it's best to >>> use Multipath TCP (with coupled congestion control) >>> instead because that works on the right time scale. >>> Again, I don't think this is a use case for SR and I >>> would recommend to remove the section entirely. >>> >>> Mirja >>> >>> >>> On 05.07.2018 04:08, Gaurav Dawra wrote: >>>> Hey Alvaro, Mirja, >>>> >>>> Friendly reminder to further progress this document. >>>> >>>> Cheers, >>>> >>>> Gaurav >>>> >>>> On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra >>>> > >>>> wrote: >>>> >>>> Hi Alvaro, Mirja >>>> >>>> Any feedback or next steps to close this? >>>> >>>> Cheers, >>>> >>>> Gaurav >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 12, 2018, at 7:06 AM, Gaurav Dawra >>>> >>> > wrote: >>>> >>>>> Hi Mirja, >>>>> >>>>> Friendly Reminder...Could you please also advice >>>>> if there is anything further to DISCUSS on this >>>>> document which was also related to TCP updates below? >>>>> >>>>> Cheers, >>>>> >>>>> Gaurav >>>>> >>>>> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana >>>>> >>>> > wrote: >>>>> >>>>> Thanks Martin! >>>>> >>>>> >>>>> On June 6, 2018 at 3:14:45 PM, Martin >>>>> Stiemerling (mls.ietf@gmail.com >>>>> ) wrote: >>>>> >>>>>> Hi Alvaro, all, >>>>>> >>>>>> Thanks for addressing my concerns. >>>>>> >>>>>> This version is good to go from my side. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> ;Martin >>>>>> >>>>>> Am 30.05.18 um 21:55 schrieb Alvaro Retana: >>>>>> > Martin: >>>>>> > br/>> Hi!!  How are you? >>>>>> > br/>> Gaurav just posted a revision. Please >>>>>> takke a look and let us know if br/>> the >>>>>> changes address your concerrns or not. >>>>>> > br/>> >>>>>> https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-segment-routing-msdc-09 >>>>>> >>>>>> > br/>> Thanks!!! >>>>>> > br/>> Alvaro. < >>>>>> > br/>> On May 25, 2018 at 12:08:46 PM, >>>>>> Gaurav Dawra ((gdawra.ietf@gmail.com >>>>>> br/>> >>>>>> >>>>> @gmail.com >>>>>> >) wrote: >>>>>> > br/>>> Hi Martin, < >>>>>> >> >>>>>> >> Thanks for review. I will post the new >>>>>> version. Hopefully, it will br/>>> address >>>>>> all your comments and we can close thhis review. >>>>>> >> >>>>>> >> Any updates on below response? >>>>>> >> >>>>>> >> Cheers, >>>>>> >> >>>>>> >> Gaurav >>>>>> >> >>>>>> >> Sent from my iPhone >>>>>> >> >>>>>> >> On May 23, 2018, at 4:17 AM, Gaurav Dawra >>>>>> >>>>> br/>>> >>>>>> >>>>> @gmail.com >>>>>> >> wrote: >>>>>> >> >>>>>> >>> Hi Martin, >>>>>> >>> >>>>>> >>> Thanks for the review. Any further comments >>>>>> here ? I will post the br/>>>> new version >>>>>> soon. < >>>>>> >>> >>>>>> >>> Cheers, >>>>>> >>> >>>>>> >>> Gaurav >>>>>> >>> >>>>>> >>> Sent from my iPhone >>>>>> >>> >>>>>> >>> On May 16, 2018, at 7:44 PM, Gaurav Dawra >>>>>> >>>>> br/>>>> >>>>>> >>>>> @gmail..com >>>>>> >> wrote: >>>>>> >>> >>>>>> >>>> Hi Martin, >>>>>> >>>> >>>>>> >>>> Apologies from my end we had few internal >>>>>> authors conversations on br/>>>>> the points >>>>>> you have raised. < >>>>>> >>>> >>>>>> >>>> Please find below my response. I will be happy to discuss further, br/>>>>> if needed. < >>>>>> >>>> >>>>>> >>>> inline... >>>>>> >>>> >>>>>> >>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling >>>>> br/>>>>>> >>>>>> >>>>> >> wrote: >>>>>> >>>>> >>>>>> >>>>> Hi Gaurav, >>>>>> >>>>> >>>>>> >>>>> This got lost on my end, sorry for this. The >>>>>> filter just moved br/>>>>>> these messages >>>>>> out of my sight... :-/ >>>>>> >>>>> >>>>>> >>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra: >>>>>> >>>>>> Hey Martin, >>>>>> >>>>>> Sorry for late reply. Please see some comments inline[Gaurav] >>>>>> >>>>>>> On Jan 9, 2018, at 2:25 PM, Martin >>>>>> Stiemerling br/>>>>>>>> >>>>> >>>>> > br/>>>>>>>>; >>>>>> >>>>> >> wrote: >>>>>> >>>>>>> >>>>>> >>>>>>> Hi all, >>>>>> >>>>>>> >>>>>> >>>>>>> I've reviewed this document as part of the >>>>>> transport area review br/>>>>>>>> team's >>>>>> ongoing effort to review key IETF documents. >>>>>> These br/>>>>t;>>>> comments were written >>>>>> primarily for the transport area directors, >>>>>> br/>>>>>>>> but are copied to the doocument's >>>>>> authors for their information br/>>>>>>>&> >>>>>> and to allow them to address any issues >>>>>> raised. When done at the >>>>>> >>>>>>> time of IETF Last Call, the authors should consider this review br/>>>>>>>> together >>>>>> with any other last-call comments they >>>>>> receive. Please br/>>>&>>>>> always CC >>>>>> tsv-art@… if you reply to or forward this >>>>>> review. >>>>>> >>>>>>> >>>>>> >>>>>>> Summary: >>>>>> >>>>>>> This draft has serious issues in Section 7..1, 7.2 and in one part br/>>>>>>>> of >>>>>> Secction3, described in the review, and needs >>>>>> to be rethought. br/>>&>>>>>> The other >>>>>> sections are good AFAIK. >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> Technicals: >>>>>> >>>>>>> The overall draft looks ok, but the three points below look br/>>>>>>>> strange and >>>>>> need a fix before publication IMHO: >>>>>> >>>>>>> >>>>>> >>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well br/>>>>>>>> >>>>>> proven funcationality and not even safe to >>>>>> use functionality. br/>>>&>>>>> Both are some >>>>>> sort discussing that different paths in the >>>>>> network br/>>>>>>>> could be used by the eend >>>>>> host traffic. This sounds pretty much >>>>>> br/>>>>>>>t;> like the Path Aware >>>>>> Networking Proposed Research Group >>>>>> br/>>t;>>>>>> (https://irtf.org/panrg) and >>>>>> hints to the fact that there is no >>>>>> br/>>>>>>>> commonly understannd and accepted >>>>>> engineering solution in this space. >>>>>> >>>>>>> >>>>>> >>>>>>> Section 7.1: >>>>>> >>>>>>> [KANDULA04] is a really old reference that hasn't been followed br/>>>>>>>> up iin >>>>>> recent times and even worse there is no >>>>>> evidence that this br/>>t;>>>>>> is going >>>>>> to work good enough or stable enough under >>>>>> real Internet br/>>>>>>>> traffic. >>>>>> Additioonally, it is more than unclear how >>>>>> any modern TCP br/>>>>&ggt;>>> implementation >>>>>> will react to this >>>>>> >>>>>> [Gaurav] Will get back on this. >>>>>> >>>>> >>>>>> >>>>> I will reply to the other email dicussing this. >>>>>> >>>> I have replied to other thread. >>>>>> >>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> Section 7.2: >>>>>> >>>>>>> This section describes an idea without >>>>>> detailing too much about br/>>>>>>>> any >>>>>> furtther aspects. Further it changes the >>>>>> commonly accepted br/>>>;>>>>> notion of what >>>>>> an end host can do with the network. At best >>>>>> this br/>>>>>>>> would require a good >>>>>> ddefinition of what an end host in your >>>>>> br/>>>>>>>&ggt; setting is, e.g., a highly >>>>>> modified piece of (at least) software >>>>>> >>>>>>> that usually not found in OS availble on the >>>>>> market (yet?) >>>>>> >>>>>>> Further communicating instantaneous path >>>>>> characteristics to a br/>>>>>>>> central >>>>>> point is potentially a bad idea, as the data >>>>>> is already br/>>>;>>>>> outdated when >>>>>> reported by any node. >>>>>> >>>>>> [Gaurav] I believe Authors are trying to highlight that Host which br/>>>>>>> is >>>>>> defineed in br/>>>>>>> >>>>>> (https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) >>>>>> br/>>>>>>> can innfluence the traffic based >>>>>> on the Calculations locally or br/>>>t;>>>> >>>>>> jointly with the controller. Implementations >>>>>> can decide how much br/>>>>>>> Centralized >>>>>> -vs- localized coontrol is allowed at Host >>>>>> based on br/>>>>>>> perfoormance data >>>>>> collection. >>>>>> >>>>> >>>>>> >>>>> Performance data collection (monitoring?) isn't crucial when it br/>>>>>> comes to timely >>>>>> (actuaally real-time) reaction. However, this >>>>>> br/>>>>>> secttion isn't just about >>>>>> performance data collection as it is about >>>>>> br/>>>>>>> "Performance-aware routing" this >>>>>> seems to try to interact in br/>>>>>> >>>>>> real-time with the network behhavior of TCP. >>>>>> This isn't even close br/>>>>>> to acceeptable. >>>>>> >>>>> >>>>>> >>>>> I would be ok to say that it is useful to collect performance data br/>>>>>> for offline >>>>>> analysis and improvement of the data network. >>>>>> However, br/>>>>>&ggt; this is at completely >>>>>> different magnitues of time scales. >>>>>> >>>>> >>>>>> >>>>> I would recommend to remove the TCP part from this section entirely. >>>>>> >>>> Ack, will update in next rev: >>>>>> >>>> >>>>>> >>>> Section will read like this: >>>>>> >>>> >>>>>> >>>> ; >>>>>> >>>> /Knowing the path associated with flows/packets, the end host may/ >>>>>> >>>> /deduce certain characteristics of the path on its own, and/ >>>>>> >>>> /additionally use the information supplied with path information/ >>>>>> >>>> /pushed from the controller or received via pull request. The host/ >>>>>> >>>> /may further share its path observations with the centralized agent,/ >>>>>> >>>> /so that the latter may keep up-to-date network health map to assist/ >>>>>> >>>> /other hosts with this information./ >>>>>> >>>> // >>>>>> >>>> /For example, an application A.1 at HostA may pin a flow destined/ >>>>>> >>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/ >>>>>> >>>> /application A.1 may collect information on packet loss, deduced from/ >>>>>> >>>> /Other offline mechanisms. [There are some pingMesh mechanisms which / >>>>>> >>>> /Can be used here]/ >>>>>> >>>> /Through these mechanisms information to a centralized agent, e.g./ >>>>>> >>>> /after a flow completes, or periodically for longer lived flows./ >>>>>> >>>> /Next, using both local and/or global performance data, application/ >>>>>> >>>> /A.1 as well as other applications sharing the same resources in the/ >>>>>> >>>> /DC fabric may pick up the best path for the new flow, or update an/ >>>>>> >>>> /existing path (e.g.: when informed of congestion on an existing/ >>>>>> >>>> /path)./ >>>>>> >>>> ; >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> Section 3, 3rd bullet point: >>>>>> >>>>>>> It is the foundation of TCP that the network >>>>>> is regarded as a br/>>>>>>>> black box and >>>>>> that you infer from the transmission of >>>>>> packets br/>>>>;>>>> what the current state >>>>>> of the network path is. Inferring network >>>>>> br/>>>>>>>> path metrics (you mention SRTT, >>>>>> MSS, CWND ) is a bad idea, as br/>>>>>>>>; >>>>>> this would required that all paths exhibit >>>>>> this and if not what br//>>>>>>>> is going to >>>>>> happen? >>>>>> >>>>>>> It could be an interesting research field to change many points br/>>>>>>>> in TCP'ss >>>>>> behavior, but this once again points to the >>>>>> fact that br/>>>&>>>>> this not the IETF >>>>>> works but IRTF or elsewhere. >>>>>> >>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly br/>>>>>>> treating >>>>>> Network as Black Box. Authors are implying >>>>>> per path br/>>>>;>>> performance metrics as >>>>>> not cached. Is there some change in text >>>>>> br/>>>>>>> you are suggesting?? >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> I would recommend to remove the 3rd bullet point completey. TCP br/>>>>>> isn't the place to >>>>>> rememmber "good" or "bad" paths. This is >>>>>> br/>>>>>> something the network could decide, >>>>>> e.g., rerouting TCP flows br/>&ggt;>>>> >>>>>> within the network or changing the forwarding >>>>>> path in the network br/>>>>>> for particular >>>>>> flows (if it is not routed). >>>>>> >>>> >>>>>> >>>> Ack, after discussion, we will remove the Section 3 - 3rd br/>>>>> bullet >>>>>> point. Willl update in next rev - coming >>>>>> shortly. >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> Kind regards, >>>>>> >>>>> >>>>>> >>>>>  Martin >>>>>> >>>>> >>>>>> >>>> >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Tsv-art mailing list >>>> Tsv-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tsv-art >>> >> > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art --------------575845898AD8FA365B1C152C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Gaurav,

thanks for your edits but unfortunately they don't address my concerns.

Saying that a flowlet is per 5-tuple is just a clarification of what a flowlet is but doeen't change anything about what the text says.

Please consider removing section 7 entirely because this is really beyond the doc of this document and would need further discussion in one or multiple separate documents. Why is that not an option for the authors? Why do you think that section 7 is important for this document?

Mirja


On 16.10.18 07:45, Gaurav Dawra wrote:
Hi MIrja,

I have posted a new version. Please do let me know if we need to discuss further. We can do it over the phone.

Cheers,

Gaurav


On Mon, Sep 3, 2018 at 4:29 AM Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Mirja,

Please see inline...[Gaurav2]

On Thu, Aug 9, 2018 at 8:30 AM Mirja Kühlewind <ietf@kuehlewind.net> wrote:
Hi Gaurav,

please see inline.

On 03.08.2018 07:20, Gaurav Dawra wrote:
Hey Mirja,

Sorry for the long delay. I was traveling constantly since IETF and bit lost in my mailbox and discussion with Authors. Please see my response inline[Gaurav]


I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.

Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the application can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow through all the ECMP paths". In summary I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.

[Gaurav] Hi Mirja, Thanks for the review. The proposal here is no different that current ECMP hashing at flowlet level. The only difference which is being pointed out here is that if we use SR, we could leverage on the ability of be aware of multiple disjoint paths rather than the hashing. It’s pins the flowlets to particular paths which is basic SR operations.


Yes the problem is that we usually don't recommend ECMP hashing on flowlet level because it can interact badly with the end-end mechanisms of that flow. As I said, I don't see how the notion of flowlets help you problem and therefore I still recommend to remove that paragraph.
[Gaurav2] OK. It took sometime to get to consensus with authors. Will update the text to use 5-tuple flows instead of flowlets. Would that suffice? I will update the text shortly.


Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link.

For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.

[Gaurav] They are two separate mechanisms. Most DCs have some sort of data-plane/ECMP aware tracing mechanism to detect the loss/delays and can be combined with Application back-off to detect issue. All this section is suggesting is that SR can be used to pin the path to particular set of ECMP paths instead of relying on ECMP hashing.


This is not quite what the text says. If that is the statement you want to make, that is fine but then you don't need to talk about performance aware routing at all.
[Gaurav2] I will update the text here with statement i mentioned above. IMHO, it's performance aware routing wrt to end-host traffic.   


Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away" on a time-scale that is slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.

[Gaurav] As I said above, there are other mechanisms to detect loss and trace the path on which loss is seen. This is a common mechanism used in MSDCs.

I think this is beyond the scope of the document. 
[Gaurav2] Will update the text.

 

I am happy to discuss further over the phone to try to explain the thought process. I will also do check again with Authors to update the text or something else based on our conversation.


Maybe see if some update can be made to the text first and then we can have another discussion if needed.
[Gaurav2] Sounds good. Will update the text shortly and then we can discuss if needed.

Cheers,

Gaurav 

 

Cheers,

 

Gaurav

If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for SR and I would recommend to remove the section entirely.

Mirja

 



On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Mirja,

Ack. Let me work with authors to close ASAP.

Cheers,

Gaurav

Sent from my iPhone

On Jul 5, 2018, at 10:06 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:

Hi Gaurav,

sorry for my very long delay but this got somehow a bit lost in my mailbox.

I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.

Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the application can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow through all the ECMP paths". In summary I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.

Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link. For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.

Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away" on a time-scale that is slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.

If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for SR and I would recommend to remove the section entirely.

Mirja


On 05.07.2018 04:08, Gaurav Dawra wrote:
Hey Alvaro, Mirja, 

Friendly reminder to further progress this document.

Cheers,

Gaurav

On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Alvaro, Mirja 

Any feedback or next steps to close this?

Cheers,

Gaurav

Sent from my iPhone

On Jun 12, 2018, at 7:06 AM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:

Hi Mirja,

Friendly Reminder...Could you please also advice if there is anything further to DISCUSS on this document which was also related to TCP updates below?

Cheers,

Gaurav

On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:

Thanks Martin!


On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@gmail.com) wrote:
Hi Alvaro, all,

Thanks for addressing my concerns.

This version is good to go from my side.

Kind regards,

;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> br/>> Hi!!  How are you?
> br/>> Gaurav just posted a revision.  Please takke a look and let us know if br/>> the changes address your concerrns or not.
> br/>> https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-segment-routing-msdc-09
> br/>> Thanks!!!
> br/>> Alvaro. <
> br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((gdawra.ietf@gmail.com br/>> <mailto:gdawra.ietf@@gmail.com>) wrote:
> br/>>> Hi Martin, <
>>
>> Thanks for review. I will post the new version. Hopefully, it will br/>>> address all your comments and we can close thhis review.
>>
>> Any updates on below response?
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>> On May 23, 2018, at 4:17 AM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>> <mailto:gdawra.ietf@@gmail.com>> wrote:
>>
>>> Hi Martin,
>>>
>>> Thanks for the review. Any further comments here ? I will post the br/>>>> new version soon. <
>>>
>>> Cheers,
>>>
>>> Gaurav
>>>
>>> Sent from my iPhone
>>>
>>> On May 16, 2018, at 7:44 PM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>>> <mailto:gdawra.ietf@@gmail..com>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Apologies from my end we had few internal authors conversations on br/>>>>> the points you have raised. <
>>>>
>>>> Please find below my response. I will be happy to discuss further, br/>>>>> if needed. <
>>>>
>>>> <Gaurav> inline...
>>>>
>>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <mls.ietf@gmail.com br/>>>>>> <mailto:mls.iietf@gmail.com>> wrote:
>>>>>
>>>>> Hi Gaurav,
>>>>>
>>>>> This got lost on my end, sorry for this. The filter just moved br/>>>>>> these messages out of my sight... :-/
>>>>>
>>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
>>>>>> Hey Martin,
>>>>>> Sorry for late reply. Please see some comments inline[Gaurav]
>>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>> <mls.ietf@@gmail.com <mailto:mls.ietf@gmail.com> br/>>>>>>>>; <mailto:mls.ietf@gmail.com>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've reviewed this document as part of the transport area review br/>>>>>>>> team's ongoing effort to review key IETF documents. These br/>>>&gtt;>>>> comments were written primarily for the transport area directors, br/>>>>>>>> but are copied to the doocument's authors for their information br/>>>>>>>&> and to allow them to address any issues raised. When done at the
>>>>>>> time of IETF Last Call, the authors should consider this review br/>>>>>>>> together with any other last-call comments they receive. Please br/>>>&>>>>> always CC tsv-art@… if you reply to or forward this review.
>>>>>>>
>>>>>>> Summary:
>>>>>>> This draft has serious issues in Section 7..1, 7.2 and in one part br/>>>>>>>> of Secction3, described in the review, and needs to be rethought. br/>>&>>>>>> The other sections are good AFAIK.
>>>>>>>
>>>>>>>
>>>>>>> Technicals:
>>>>>>> The overall draft looks ok, but the three points below look br/>>>>>>>> strange and need a fix before publication IMHO:
>>>>>>>
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well br/>>>>>>>> proven funcationality and not even safe to use functionality. br/>>>&>>>>> Both are some sort discussing that different paths in the network br/>>>>>>>> could be used by the eend host traffic. This sounds pretty much br/>>>>>>&gtt;> like the Path Aware Networking Proposed Research Group br/>&gtt;>>>>>> (https://irtf.org/panrg) and hints to the fact that there is no br/>>>>>>>> commonly understannd and accepted engineering solution in this space.
>>>>>>>
>>>>>>> Section 7.1:
>>>>>>> [KANDULA04] is a really old reference that hasn't been followed br/>>>>>>>> up iin recent times and even worse there is no evidence that this br/>&gtt;>>>>>> is going to work good enough or stable enough under real Internet br/>>>>>>>> traffic. Additioonally, it is more than unclear how any modern TCP br/>>>>&ggt;>>> implementation will react to this
>>>>>> [Gaurav] Will get back on this.
>>>>>
>>>>> I will reply to the other email dicussing this.
>>>> <Gaurav> I have replied to other thread.
>>>>>
>>>>>>>
>>>>>>> Section 7.2:
>>>>>>> This section describes an idea without detailing too much about br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted br/>>>;>>>>> notion of what an end host can do with the network. At best this br/>>>>>>>> would require a good ddefinition of what an end host in your br/>>>>>>>&ggt; setting is, e.g., a highly modified piece of (at least) software
>>>>>>> that usually not found in OS availble on the market (yet?)
>>>>>>> Further communicating instantaneous path characteristics to a br/>>>>>>>> central point is potentially a bad idea, as the data is already br/>>>;>>>>> outdated when reported by any node.
>>>>>> [Gaurav] I believe Authors are trying to highlight that Host which br/>>>>>>> is defineed in br/>>>>>>> (https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the traffic based on the Calculations locally or br/>>&gtt;>>>> jointly with the controller. Implementations can decide how much br/>>>>>>> Centralized -vs- localized coontrol is allowed at Host based on br/>>>>>>> perfoormance data collection.
>>>>>
>>>>> Performance data collection (monitoring?) isn't crucial when it br/>>>>>> comes to timely (actuaally real-time) reaction. However, this br/>>>>>> secttion isn't just about performance data collection as it is about br/>>>>>>> "Performance-aware routing" this seems to try to interact in br/>>>>>> real-time with the network behhavior of TCP. This isn't even close br/>>>>>> to acceeptable.
>>>>>
>>>>> I would be ok to say that it is useful to collect performance data br/>>>>>> for offline analysis and improvement of the data network. However, br/>>>>>&ggt; this is at completely different magnitues of time scales.
>>>>>
>>>>> I would recommend to remove the TCP part from this section entirely.
>>>> <Gaurav>Ack, will update in next rev:
>>>>
>>>> Section will read like this:
>>>>
>>>> ;
>>>> /Knowing the path associated with flows/packets, the end host may/
>>>> /deduce certain characteristics of the path on its own, and/
>>>> /additionally use the information supplied with path information/
>>>> /pushed from the controller or received via pull request. The host/
>>>> /may further share its path observations with the centralized agent,/
>>>> /so that the latter may keep up-to-date network health map to assist/
>>>> /other hosts with this information./
>>>> //
>>>> /For example, an application A.1 at HostA may pin a flow destined/
>>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/
>>>> /application A.1 may collect information on packet loss, deduced from/
>>>> /Other offline mechanisms. [There are some pingMesh mechanisms which /
>>>> /Can be used here]/
>>>> /Through these mechanisms information to a centralized agent, e.g./
>>>> /after a flow completes, or periodically for longer lived flows./
>>>> /Next, using both local and/or global performance data, application/
>>>> /A.1 as well as other applications sharing the same resources in the/
>>>> /DC fabric may pick up the best path for the new flow, or update an/
>>>> /existing path (e.g.: when informed of congestion on an existing/
>>>> /path)./
>>>> ;
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> Section 3, 3rd bullet point:
>>>>>>> It is the foundation of TCP that the network is regarded as a br/>>>>>>>> black box and that you infer from the transmission of packets br/>>>>;>>>> what the current state of the network path is. Inferring network br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as br/>>>>>>>>; this would required that all paths exhibit this and if not what br//>>>>>>>> is going to happen?
>>>>>>> It could be an interesting research field to change many points br/>>>>>>>> in TCP'ss behavior, but this once again points to the fact that br/>>>&>>>>> this not the IETF works but IRTF or elsewhere.
>>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly br/>>>>>>> treating Network as Black Box. Authors are implying per path br/>>>>;>>> performance metrics as not cached. Is there some change in text br/>>>>>>> you are suggesting??
>>>>>
>>>>>
>>>>> I would recommend to remove the 3rd bullet point completey. TCP br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is br/>>>>>> something the network could decide, e.g., rerouting TCP flows br/>&ggt;>>>> within the network or changing the forwarding path in the network br/>>>>>> for particular flows (if it is not routed).
>>>>
>>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd br/>>>>> bullet point. Willl update in next rev - coming shortly.
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>>  Martin
>>>>>
>>>> 




_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art





_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

--------------575845898AD8FA365B1C152C-- From nobody Thu Oct 18 18:42:58 2018 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 4EBEA130E4A for ; Thu, 18 Oct 2018 18:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.563 X-Spam-Level: X-Spam-Status: No, score=-14.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 XKwFXi0y491Y for ; Thu, 18 Oct 2018 18:42:52 -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 D725D126DBF for ; Thu, 18 Oct 2018 18:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=93640; q=dns/txt; s=iport; t=1539913371; x=1541122971; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5yRwlRA0pQdGqT6xVrLlQMJQ02xRAydAXVbxwXkx4ok=; b=ONw2VtwQGU2pFDJ+taZ5yYw330SJdm2EHAbZ+1UsMu3UvBlg/UEBy9Sv CGegu7VBSeJ5IER+FJFDm3RBFYdlyoF1TujQMl98TQVW2bp1QEFAsxA6K /Vy/hi2xRNWNTQ03G7t4HM1Ep+2mX7rDuILtcvjEzI4PuVrgV/db/Khub E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABkNclb/4ENJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgFKmZ/KAqDa4gXjBqCDZcPFIFmCwEBhGw?= =?us-ascii?q?CF4RsITQNDQEDAQECAQECbR0LhTkBAQEBAxoBCAQGOAoKEAIBBgIRAQIBAiE?= =?us-ascii?q?BBgMCAgIwFAMGCAIEDgUIgxmBHWSLaZtNezOKJ4tNF4IAgRABghR+gxsEgRs?= =?us-ascii?q?sOAYQgk2CVwKIVwg5SIRNFYFAhDqJKgVOCQKJOIclH4FPhHKDFIZTiSCMfwI?= =?us-ascii?q?RFIEmHThBgRRwFTuCbAmCHRd8AQMEjRVvAYkGK4EBgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,397,1534809600"; d="scan'208,217";a="187639891" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 01:42:50 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9J1gnOX018784 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2018 01:42:50 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Oct 2018 20:42:49 -0500 Received: from xch-aln-011.cisco.com ([173.36.7.21]) by XCH-ALN-011.cisco.com ([173.36.7.21]) with mapi id 15.00.1395.000; Thu, 18 Oct 2018 20:42:49 -0500 From: "Siva Sivabalan (msiva)" To: "spring@ietf.org" CC: "robjs=40google.com@dmarc.ietf.org" Thread-Topic: [spring] Comments on draft-spring-segment-routing-policy Thread-Index: AQHUI5HnrmwGBsDxVEmQ6kno4nzKBaUilxmAgAOi+5A= Date: Fri, 19 Oct 2018 01:42:49 +0000 Message-ID: <9ba2813b9f9b4800baf4ba8255242d6b@XCH-ALN-011.cisco.com> References: <5424EA3D-A726-4D96-950E-9C63ED93D49B@cisco.com> In-Reply-To: <5424EA3D-A726-4D96-950E-9C63ED93D49B@cisco.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.86.248.18] Content-Type: multipart/alternative; boundary="_000_9ba2813b9f9b4800baf4ba8255242d6bXCHALN011ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [spring] Comments on draft-spring-segment-routing-policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 01:42:56 -0000 --_000_9ba2813b9f9b4800baf4ba8255242d6bXCHALN011ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KUGxlYXNlIHNlZSBv dXIgcmVzcG9uc2UgaW4tbGluZS4NCg0KVGhhbmtzLA0KU2l2YQ0KcC5zOiBXZSB3aWxsIGJlIHBv c3RpbmcgYSBuZXcgcmV2aXNpb24gb2YgdGhlIFNSIHBvbGljeSBkcmFmdCByZWZsZWN0aW5nIHlv dXIgY29tbWVudHMuDQoNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgUm9iIFNoYWtpciA8 cm9ianM9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpyb2Jqcz00MGdvb2dsZS5j b21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlc2RheSwgSnVseSAyNCwgMjAxOCBhdCA1OjA0 IFBNDQpUbzogImRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3lAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3lA dG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGlj eUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LXBvbGljeUB0b29scy5pZXRmLm9yZz4+LCBTUFJJTkcgV0cgTGlzdCA8c3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NwcmluZ10gQ29tbWVudHMgb24g ZHJhZnQtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kNCg0KKEFzIGFuIGluZGl2aWR1YWwg Y29udHJpYnV0b3IpDQoNCkhpIEF1dGhvcnMsDQoNCkkgaGF2ZSBhIG51bWJlciBvZiBjb21tZW50 cyBvbiBkcmFmdC1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeSwgc29tZSBhcmUgdGVjaG5p Y2FsLCBzb21lIGFyZSBlZGl0b3JpYWwuICBGcmFua2x5LCBJIGZpbmQgdGhpcyBkb2N1bWVudCBx dWl0ZSBkaWZmaWN1bHQgdG8gcmVhZCBzaW5jZSBpdCBkb2Vzbid0IGNvaGVyZW50bHkgbWFrZSB1 cCBhIHNwZWNpZmljYXRpb24gLSBhbmQgcmF0aGVyIGp1bXBzIGFib3V0IHF1aXRlIGEgbG90LCB3 aXRoIGEgbnVtYmVyIG9mIHRoaW5ncyBiZWluZyByZS1zdGF0ZWQuIEkgdW5kZXJzdGFuZCB0aGF0 IHRoaXMgaGFwcGVucyBkdXJpbmcgZGV2ZWxvcG1lbnQgb2YgYSBzcGVjaWZpY2F0aW9uLCBidXQg bm93IHRoaXMgaXMgYSBXRyBkb2MsIHdlIHNob3VsZCBmb2N1cyBvbiBtYWtpbmcgdGhpcyBkb2N1 bWVudCBhcyBjbGVhciBhcyBpdCBjYW4gYmUuDQoNClBsZWFzZSBmaW5kIG15IHNwZWNpZmljIGNv bW1lbnRzIGJlbG93Og0KDQogICogICAoMS4gSW50cm9kdWN0aW9uKSBJbiB0aGlzIHNlY3Rpb24g eW91IHVzZSB0aGUgd29yZGluZyAiYXVnbWVudGVkIHdpdGggYW4gb3JkZXJlZCBsaXN0IG9mIHNl Z21lbnRzIiAtIEkgd291bGQgc3VnZ2VzdCByZXdvcmRpbmcgdGhpcy4gV2hpbHN0IGl0IG1pZ2h0 IGJlIHRoZSBjYXNlIGZvciBTUnY2LCBmb3IgU1ItTVBMUywgZWl0aGVyIHdlJ3JlIGRvaW5nIHBv cCtwdXNoLCBvciBzaW1wbHkgcHVzaGluZyB0aGUgbmV3IHNlZ21lbnQgbGlzdC4gSW4gdGhpcyBj YXNlLCBpdCdzIG5vdCByZWFsbHkgImF1Z21lbnRpbmciLCBidXQgYWRkaW5nIGEgbmV3IHN0YWNr IG9mIGhlYWRlcnMuDQpGb3IgU1ItTVBMUywgd2hlbiB3ZSBzdGVlciBpbnRvIHRoZSBTUiBQb2xp Y3kgd2UgYXJlIGRvaW5nIGFuIGltcG9zaXRpb24gb2YgdGhlIGxhYmVsIHN0YWNrIGNvcnJlc3Bv bmRpbmcgdGhlIFNJRCBsaXN0IG9uIHRoZSBwYWNrZXQuIFNvIHdlIGFyZSBhZGRpbmcgbGFiZWxz LiBTaW5jZSB0aGUgd29yZCBpbXBvc2l0aW9uIGhhcyBzcGVjaWFsIGNvbm5vdGF0aW9ucyB3aXRo IE1QTFMsIHdlIHRob3VnaHQgdGhhdCDigJxhdWdtZW504oCdIHdvdWxkIGJlIGEgbmV1dHJhbCB3 b3JkIHRoYXQgZml0cyBib3RoIFNSdjYgYW5kIFNSLU1QTFMuDQoNCiAgKiAgICgyLiBTUiBQb2xp Y3kpIFRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhpcyBzZWN0aW9uIGlzbid0IHJlYWxseSBjbGVhciB0 byBtZS4NCg0KICAgICAqICAgV2hhdCBpcyBtZWFudCBieSBhICJzcGVjaWZpYyBpbnRlbnQiPyBJ IHRoaW5rIHRoYXQgbXVsdGlwbGUgImludGVudHMiIG1pZ2h0IGhhdmUgdGhlIHNhbWUgU1IgcG9s aWN5IC0gZS5nLiwgc29tZSBsYXRlbmN5IG9wdGltaXNhdGlvbiBhbmQgSUdQIHNob3J0ZXN0IHBh dGggYXJlIGRpZmZlcmVudCAiaW50ZW50cyIsIGJ1dCBhcmUgbGlrZWx5IHRvIG1lYW4gdGhlIHNh bWUgcG9saWN5LiBDb25zaWRlciByZXdvcmRpbmcgdGhpcyB0byBhICJjb21tb24gcGF0aGluZyBi ZWhhdmlvdXIiIG9yIHNpbWlsYXIuDQpZb3UgYXJlIHJpZ2h0IHRoYXQgYSBTUiBQb2xpY3kgd2l0 aCBsYXRlbmN5IG9wdGltaXphdGlvbiBpbnRlbnQgYW5kIElHUCBzaG9ydGVzdCBwYXRoIGludGVu dCBtYXkgaGF2ZSB0aGUgc2FtZSBwYXRoIOKAkyBhbmQgaGVuY2UgdGhlIHNhbWUg4oCccGF0aGlu ZyBiZWhhdmlvcuKAnS4gQnV0IHRoZWlyIGludGVudCBpcyBkaWZmZXJlbnQgYW5kIHF1aXRlIGxp a2VseSB3aXRoIHNvbWUgbmV0d29yayB0b3BvbG9neSBvciBvdGhlciBjaGFuZ2VzLCB0aGVpciBw YXRoIHdvdWxkIGRpdmVyZ2UuIEhlbmNlIHRoZSBlbXBoYXNpcyBvbiDigJxpbnRlbnTigJ0gcmF0 aGVyIHRoYW4gdGhlIOKAnHBhdGhpbmfigJ0uDQoNCiAgICAgKiAgIFdoeSBkbyB3ZSBuZWVkIHRv IHJlZmVyIHRvIHdoYXQgdGhlIFNSIGFyY2hpdGVjdHVyZSBzYXlzIGFib3V0IGluc3RydWN0aW9u cz8gSXQgc2VlbXMgdG8gbWUgaGVyZSB0aGUgY29yZSBwb2ludCBpcyAiQW4gU1IgUG9saWN5IG1h eSBjb25zaXN0IG9mIGFueSB0eXBlIG9mIHNlZ21lbnQiLiBJcyB0aGVyZSBhIHRlY2huaWNhbCBy ZWFzb24gdG8gbm90IGp1c3Qgd29yZCB0aGlzIG1vcmUgc2ltcGx5Pw0KVGhlIHJlYXNvbiBpcyB0 byBzaW1wbHkgcmVtaW5kIHRoYXQgdGhlIGluc3RydWN0aW9ucyBhcmUgbm90IGp1c3QgdG9wb2xv Z2ljYWwgKGUuZy4gZm9yIGEgVEUgdXNlLWNhc2UpIGJ1dCBhbHNvIHdpZGVyIHRvIGluY2x1ZGlu ZyBvdGhlcnMgbGlrZSBzZXJ2aWNlIHNlZ21lbnRzLg0KDQogICogICAoMi4xIElkZW50aWZpY2F0 aW9uIG9mIGFuIFNSIHBvbGljeSkgV2hlcmUgdGhlcmUgaXMgYSA8aGVhZGVuZCwgZW5kcG9pbnQs IGNvbG91cj4gdHVwbGUsIEkgYmVsaWV2ZSB0aGF0IHRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBz YXkgdGhhdCB0aGUgaGVhZGVuZCBJUHZbNDZdIGFkZHJlc3MgaXMgZG9tYWluIHVuaXF1ZSAtLSBp cyB0aGlzIGV4cGVjdGVkLCBpZiBzbywgc2hvdWxkIGl0IGJlIHN0YXRlZD8NCkFncmVlIGFuZCB3 aWxsIGFkZCB0ZXh0IHRvIGNsYXJpZnkgdGhlIHNhbWUuDQoNCiAgKiAgICgyLjEpICJBbiBpbXBs ZW1lbnRhdGlvbiBNQVkgYWxsb3cgYXNzaWdubWVudCBvZiBhIHN5bWJvbGljIG5hbWUiIC0gdGhl IE1VU1QgTk9UIHRoYXQgaXMgc3BlY2lmaWVkIGhlcmUgaXMgaW50ZXJlc3RpbmcuIEkgYmVsaWV2 ZSBIYXJpc2ggYXNrZWQgYSBzaW1pbGFyIHF1ZXN0aW9uIGluIHRoZSB3b3JraW5nIGdyb3VwLiBX aGF0IGlzIHRoZSBpbnRlbnRpb24gd2l0aCB0aGUgTVVTVCBOT1Q/IE9wZXJhdGlvbmFsbHksIHNo b3VsZCB0aGVzZSBuYW1lcyBiZSB1bmlxdWUgcGVyIHBvbGljeSAob3RoZXJ3aXNlLCBpdCBzZWVt cyB0aGV5IGFyZSBwcm9iYWJseSBub3QgdGhhdCB1c2VyIGZyaWVuZGx5IGZvciBpZGVudGlmaWNh dGlvbikuDQpXZSB3aWxsIHVwZGF0ZSB0aGUgdGV4dCB0byByZW1vdmUgdGhlIE1VU1QgTk9UIGFu ZCBjbGFyaWZ5IHRoZSB1c2FnZS4NCg0KICAqICAgKDIuLjIpIFRoZXJlIGlzIHNvbWUgcmVwZXRp dGlvbiBpbiB0aGlzIHNlY3Rpb24gd2hpY2ggbWFrZXMgaXQgcXVpdGUgdW5jbGVhciAtLSBJIGJl bGlldmUgdGhlIGtleSBwb2ludHMgYXJlOg0KDQogICAgICogICBBIHBvbGljeSBoYXMgYSBzZXQg b2YgY2FuZGlkYXRlIHBhdGhzLg0KICAgICAqICAgVGhvc2UgY2FuZGlkYXRlIHBhdGhzIGNhbiBi ZSBkeW5hbWljIG9yIGV4cGxpY2l0Lg0KICAgICAqICAgQ2FuZGlkYXRlIHBhdGhzIGNvbXByaXNl IG9mIGEgc2V0IG9mIG9uZSBvciBtb3JlIFNJRCBsaXN0cy4NCiAgICAgKiAgIEV4cGxpY2l0IGNh bmRpZGF0ZSBwYXRocyBoYXZlIGV4dGVybmFsbHkgKHRvIHRoZSByb3V0ZXIpIHNwZWNpZmllZCBT SUQgbGlzdHMuIER5bmFtaWMgb25lcyBhcmUgY29tcHV0ZWQgb24gdGhlIFNJRCBsaXN0cy4NCiAg ICAgKiAgIFdpdGhpbiBlYWNoIFNJRCBsaXN0LCB0cmFmZmljIGlzIGxvYWQtYmFsYW5jZWQgYWNy b3NzIHRoZSBTSUQtbGlzdHMgYWNjb3JkaW5nIHRvIGEgd2VpZ2h0Lg0KDQpJcyB0aGlzIHNlY3Rp b24gc2F5aW5nIHNvbWV0aGluZyBlbHNlIG90aGVyIHRoYW4gdGhlIGFib3ZlIC0tIGlmIG5vdCwg SSByZWNvbW1lbmQgcmV3b3JkaW5nIGl0IHRvIG5vdCB0byBoYXZlIGFzIG1hbnkgZGVjaXNpb24g Y3JpdGVyaWEgaW4gaXQgdG8gcGFyc2UuDQpXZSB3aWxsIHJlbW92ZSBhIHJlcGVhdGVkIHNlbnRl bmNlIGluIHRoZXJlIHRvIGltcHJvdmUgdGhlIHRleHQuDQoNCiAgKiAgICgyLjIpIFRoZSB3aG9s ZSBzdWItcGFyYWdyYXBoIGFib3V0IHJlcGxpY2F0aW9uIGlzIGh1Z2VseSB1bmRlcnNwZWNpZmll ZC4gV2Ugc2F5IGFib3ZlIHRoYXQgdHJhZmZpYyBpcyBsb2FkLWJhbGFuY2VkIGFjcm9zcyB0aGUg U0lEIGxpc3RzIC0gYnV0IHRoZW4gd2Ugc2F5IHRoYXQgdHJhZmZpYyBtaWdodCBiZSByZXBsaWNh dGVkLiBUaGUgSURSIGRyYWZ0LCBhbmQgdGhpcyBkcmFmdCBoYXZlIG5vIGZ1cnRoZXIgbWVudGlv biBvZiAicmVwbGljYXRpb24iLiBJIHdvdWxkIGhpZ2hseSByZWNvbW1lbmQgcmVtb3ZpbmcgdGhp cyBzZWN0aW9uLCBzaW5jZSBJIHRoaW5rIHNwZWNpZnlpbmcgdGhpcyBmdWxseSByZXF1aXJlcyBz aWduaWZpY2FudGx5IG1vcmUgd29yaywgYW5kIGlzIGJldHRlciBkb25lIGluIGFub3RoZXIgZHJh ZnQuDQpXZSB3aWxsIHJlbW92ZSB0aGlzIHRleHQgZnJvbSB0aGlzIGRyYWZ0IHNpbmNlIHRoaXMg dG9waWMgaXMgbm93IGJlaW5nIHdvcmtlZCBvbiBpbiBkcmFmdC12b3llci1zcHJpbmctc3ItcDJt cC1wb2xpY3ksIHdoaWNoIHdhcyBub3QgYXZhaWxhYmxlIGF0IHRoZSB0aW1lIG9mIHdyaXRpbmcg dGhlIFNSIFBvbGljeSBhcmNoaXRlY3R1cmUgZHJhZnQuDQoNCiAgKiAgICgyLjMpIEkgd291bGQg cmVjb21tZW5kIHRoYXQgdGhlICJMb2NhbCIgc2hvdWxkIHNpbXBseSBzYXkgInZpYSBjb25maWd1 cmF0aW9uIi4gIllhbmcgbW9kZWwgdGhyb3VnaCBORVRDT05GIiBpc24ndCBhY2N1cmF0ZSBzaW5j ZSBZQU5HIGFuZCBORVRDT05GIGFyZSBub3QgY291cGxlZCwgYW5kIGdSUEMgaGVyZSBpcyBhbWJp Z3VvdXMNCkFncmVlIGFuZCB3aWxsIHVwZGF0ZSB0aGUgdGV4dC4NCg0KICAqICAgKDIuMyArIDIu MTIpIFRoZXJlIGFyZSBhIGxvdCBvZiBwcmlvcml0aWVzIGFuZCBwcmVmZXJlbmNlcyBnb2luZyBv biBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICAgICogICBXZSBoYXZlIHByb3RvY29sIG9yaWdpbiwg cHJlZmVyZW5jZSwgYW5kIHRoZW4gcHJpb3JpdHkuIEkgd291bGQgcmVjb21tZW5kIHJlc3RydWN0 dXJpbmcgdG8gZGlzY3VzcyBjbGVhcmx5IGhvdyB0aGVzZSBhbGwgcmVsYXRlIHRvIGVhY2ggb3Ro ZXIuDQpTZWMgMi45IGRvZXMgdGhpcy4NCg0KICAgICAqICAgRnJvbSBteSBwYXJzaW5nLCB5b3Vy IGludGVudGlvbiBpcyB0byBzYXk6DQoNCiAgICAgICAgKiAgIFdpdGhpbiBhbiBpbmRpdmlkdWFs IFNSIHBvbGljeSB0aGUgY2FuZGlkYXRlIHBhdGggdG8gc2VsZWN0IGlzIHNwZWNpZmllZCB1c2lu ZyBwcmVmZXJlbmNlLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIHRoZSBsb2FkLXNoYXJpbmcg c2VjdGlvbiBpbiAyLjIgc2hvdWxkIHN0YXRlIHRoYXQgdGhpcyBpcyBvbmx5IHdoZW4gdGhlIGNh bmRpZGF0ZSBwYXRocyBhcmUgb2YgdGhlIHNhbWUgcHJlZmVyZW5jZS4NClNlbGVjdGlvbiBlbnN1 cmVzIG9uZSBhbmQgb25seSBvbmUgQ1AgaXMgc2VsZWN0ZWQgYW5kIGxvYWQgc2hhcmluZyBoYXBw ZW5zIGJldHdlZW4gU2VnbWVudC1MaXN0cyBvZiB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlIHBhdGgu DQoNCiAgICAgICAgICAgKiAgIFNlZSBmdXJ0aGVyIGNvbW1lbnRzIG9uIGNhbmRpZGF0ZSBwYXRo cyBhbmQgYmFja3VwcyBiZWxvdy4NCg0KICAgICAgICAqICAgSWYgbXVsdGlwbGUgU1IgcG9saWNp ZXMgdGhhdCBoYXZlIHRoZSBzYW1lIDxjb2xvdXIsIGVuZHBvaW50PiBhcmUgc3BlY2lmaWVkLCB0 aGVuIHRoZSBwcm90b2NvbC1vcmlnaW4gaXMgdXNlZCB0byBzZWxlY3QgYmV0d2VlbiB0aGVtLiBZ b3Ugc2hvdWxkIGV4cGxpY2l0bHkgc3RhdGUgd2hldGhlciBwcm90b2NvbC1vcmlnaW4gaXMgYmV0 dGVyIGFzIGxvd2VyIG9yIGhpZ2hlci4NCkl0IGlzIHNwZWNpZmllZCB0aGF0IGhpZ2hlciBpcyBi ZXR0ZXIuIFBsZWFzZSBzZWUgU2VjIDIuOSB3aGVyZSB0aGUgdGllYnJlYWtlciBpcyBleHBsYWlu ZWQuDQoNCiAgICAgICAgKiAgIFRoZXJlIGlzIHNvbWUgaGVhZC1lbmQgc3BlY2lmaWMgcmVjb21w dXRhdGlvbiBwcmlvcml0eSB0aGF0IGlzIHVzZWQgb25seSBmb3IgZHluYW1pYyBjYW5kaWRhdGUg cGF0aHMuLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIEknZCByZWNvbW1lbmQgZXhwbGljaXRs eSBjYWxsaW5nIHRoaXMgInJlY29tcHV0YXRpb24tcHJpb3JpdHkiLg0KSXQgaXMgbm90IHNwZWNp ZmljIHRvIGR5bmFtaWMgcGF0aHMgc2luY2UgZXZlbiBleHBsaWNpdCBwYXRocyBuZWVkIHRvIGJl IGV2YWx1YXRlZCBmb3IgcmVhY2hhYmlsaXR5L3ZhbGlkaXR5LiBXZSB3aWxsIGFkZCB0ZXh0IHRv IGNsYXJpZnkgdGhpcyBpbiBTZWMgMi4xMi4NCg0KICAqICAgKDIuMysyLjEyKzkuMykgVGhlcmUg YXJlIG1hbnkgc3Bhbm5lcnMgdGhyb3duIGludG8gdGhlIHdvcmtzIHRocm91Z2hvdXQgdGhpcyBk b2N1bWVudCBhcyB0byBob3cgdGhpbmdzIGFjdHVhbGx5IG9wZXJhdGUgd2l0aCBkaWZmZXJlbnQg cHJlZmVyZW5jZXMuIEZvciBleGFtcGxlOg0KDQogICAgICogICBJZiBJIGhhdmUgbXVsdGlwbGUg Y2FuZGlkYXRlIHBhdGhzIGFsbCB3aXRoIHRoZSBzYW1lIHdlaWdodCAtIEkgdGhpbmsgeW91IHNh eSB3ZSBzaG91bGQgbG9hZC1zaGFyZSBhY3Jvc3MgdGhlIHdlaWdodHMuIEl0IGRvZXNuJ3Qgc2Vl bSB0byBiZSBzdGF0ZWQgd2hlbiBJIHNob3VsZCBmYWlsb3ZlciB0byB0aGUgbG93ZXIgcHJlZmVy ZW5jZSBwYXRocy4NCkFzIG1lbnRpb25lZCBhYm92ZSwgdGhlcmUgaXMgbm8gbG9hZC1iYWxhbmNp bmcgYmV0d2VlbiBjYW5kaWRhdGUgcGF0aHMgYnV0IGl0IGlzIGJldHdlZW4gU2VnbWVudCBMaXN0 cyB3aXRoaW4gYSBzcGVjaWZpYyBjYW5kaWRhdGUgcGF0aHMuDQoNCiAgICAgKiAgIE15IGFzc3Vt cHRpb24gaXMgdGhhdCBJIGRvIG5vdCBjb21wYXJlIHByZWZlcmVuY2UgYWNyb3NzIGRpZmZlcmVu dCBwcm90b2NvbCBvcmlnaW5zIC0tIGkuZS4sIEkgcGljayB0aGUgcHJvdG9jb2wtb3JpZ2luIHRo YXQgaXMgYmVzdCwgYW5kIHRoZW4gc2VsZWN0IHdpdGhpbiBpdHMgY2FuZGlkYXRlIHBhdGhzIC0g c3VjaCB0aGF0IGl0IGlzIG9ubHkgd2hlbiBBTEwgQkdQIChmb3IgZXhhbXBsZSkgcGF0aHMgaGF2 ZSBmYWlsZWQsIHRoYXQgSSBnbyBhbmQgbG9vayBhdCBvbmVzIGNvbmZpZ3VyZWQgc3RhdGljYWxs eS4gVGhpcyB3b3VsZCBiZSBteSBwcmVmZXJlbmNlIC0gYnV0IGl0IHNob3VsZCBiZSBjbGFyaWZp ZWQgaW4gdGhlIGRvYy4NClByZWZlcmVuY2UgaXMgY29tcGFyZWQgYWNyb3NzIG9yaWdpbnMgYW5k IGhhcyBoaWdoZXIgcHJpb3JpdHkgdGhhbiB0aGUgcHJvdG9jb2wgb3JpZ2luLiBQbGVhc2Ugc2Vl IFNlYyAyLjkuDQoNCiAgICAgKiAgIFRoZSBiYWNrdXAgc2VtYW50aWNzIHRoYXQgYXJlIGluIHRo aXMgZG9jIGFyZSByZWFsbHkgcHJlZmVyZW5jZSBmYWlsb3ZlciBBRkFJQ1M/DQpUaGlzIGlzIGp1 c3QgcHJlZmVyZW5jZSBmYWlsb3ZlciBhbmQgbm90IGJhY2t1cCBpbiB0aGUgc2Vuc2Ugb2YgZmFz dC1yZXJvdXRlLiBTZWMgOS4zIHRhbGtzIGFib3V0IHRoZSBiYWNrdXAgaW4gdGhlIGNvbnRleHQg b2YgZmFzdC1yZXJvdXRlLiBBcyBzdWNoIHRoZXkgYXJlIGluZGVwZW5kZW50Lg0KVGhlcmUgaXMg bWVudGlvbiB0aGF0ICJhbm90aGVyIC4uLiBjYW5kaWRhdGUgcGF0aCBNQVkgYmUgZGVzaWduYXRl ZCBhcyBhIGJhY2t1cCBmb3IgYSBzcGVjaWZpYyBvciBhbGwgLi4uIGNhbmRpZGF0ZSBwYXRocyIu IEhvdyBkb2VzIHRoaXMgd29yaz8gV2hlcmUgaXMgdGhpcyBzaWduYWxsZWQgdGhhdCBhIHBhcnRp Y3VsYXIgcG9saWN5IGlzIGEgYmFja3VwIGZvciBhbm90aGVyPw0KU2luY2UgdGhpcyBpcyBTUiBQ b2xpY3kgYXJjaGl0ZWN0dXJlLCBpdCBkb2VzIG5vdCBjb3ZlciB0aGUgc2lnbmFsaW5nIGFzcGVj dHMg4oCTIHRob3NlIHNob3VsZCBiZSB3b3JrZWQgb3V0IGluIHNlcGFyYXRlIGRvY3VtZW50cy4g SSBhZ3JlZSB0aGF0IEJHUC1TUlRFIGZvciBpbnN0YW5jZSwgZG9lcyBub3QgaW5jbHVkZSB0aGlz IGluZGljYXRpb24gb2YgYmFja3VwIHlldC4gSG93ZXZlciwgdGhlcmUgaXMgYW4gaW50ZXJlc3Qg dG8gYWRkIHRoaXMuDQpIb3cgZG9lcyB0aGlzIHRoZW4gaW50ZXJhY3Qgd2l0aCB0aGUgcHJlZmVy ZW5jZXMgYW5kIHByb3RvY29sIG9yaWdpbiB2YWx1ZXM/DQpUaGUgYmFja3VwIG5vdGlvbiBpbiBT ZWMgOS4zIGlzIGluZGVwZW5kZW50IG9mIHRpZS1icmVha2VyLiBUaGUgYmFja3VwIG1heSBiZSBw aWNrZWQgYXMgdGhlIG5leHQgYmVzdCBjYW5kaWRhdGUgcGF0aCBPUiBhIGNhbmRpZGF0ZSBwYXRo IHdoaWNoIGhhcyBiZWVuIGV4cGxpY2l0bHkgc2lnbmFsZWQgYXMgYSBiYWNrdXAgZm9yIHRoZSBi ZXN0IGNhbmRpZGF0ZSBwYXRoIHRoYXQgd2FzIHNlbGVjdGVkLg0KDQogICogICAoMi44KSAiQSBj YW5kaWRhdGUgcGF0aCBpcyB2YWxpZCBpZiBpdCBpcyB1c2FibGUiIC0tIHlvdSBzaG91bGQgZGVm aW5lIHVzYWJsZSBzb21ld2hlcmUuIFRoaXMgaXMgdGhlIG9ubHkgdXNlIG9mIHRoZSB3b3JkICJ1 c2FibGUiIGluIHRoZSBkb2N1bWVudC4gSWYgaXQganVzdCBtZWFucyB0aGF0IGl0IGhhcyBtZXQg aXRzIHZhbGlkaXR5IGNyaXRlcmlvbiBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA1LCB0aGVuIHRo aXMgc2hvdWxkIGp1c3QgYmUgc3RhdGVkLg0KSXQgc2hvdWxkIGhhdmUgYmVlbiAtIEEgY2FuZGlk YXRlIHBhdGggaXMgdXNhYmxlIHdoZW4gaXQgdmFsaWQuIFdlIHdpbGwgY29ycmVjdCB0aGlzLg0K DQogICogICAoMi43KzIuOCsyLjkpIEZvciBjbGFyaXR5LCBJIHdvdWxkIGNvbGxhcHNlIHRoZXNl IHNlY3Rpb25zIGludG8gc29tZXRoaW5nIGNvaGVyZW50IC0gYnJlYWtpbmcgdGhlbSB1cCBtYWtl cyB0aGUgZG9jdW1lbnQgbGVzcyByZWFkYWJsZS4NCkVhY2ggb2YgdGhlbSBhcmUgaW5kZXBlbmRl bnQgdG9waWMgYW5kIGhlbmNlIGhhdmUgYmVlbiBrZXB0IHNlcGFyYXRlIGZvciBjbGFyaXR5Lg0K DQogICogICAoMi44KSBJdCBpcyBvbmx5IFJFQ09NTUVOREVEIHRoYXQgYSBjYW5kaWRhdGUgcGF0 aCBmb3IgYW4gU1IgcG9saWN5IGlzIGdpdmVuIGEgZGlmZmVyZW50IHByZWZlcmVuY2UuIFRoZXJl IGFyZSB0aGVuIHRpZWJyZWFrZXIgcnVsZXMgdGhhdCBhcmUgb25seSBNQVkuLiBQbGVhc2UgZXhw bGljaXRseSBzcGVjaWZ5IHRoaXMgLS0gaXQncyBnb2luZyB0byBiZSBhIG5pZ2h0bWFyZSB0byBt YW5hZ2UgYSBtdWx0aS12ZW5kb3IgbmV0d29yayBhbmQgdGVzdCB0aGlzIGlmIHRoZXJlIGFyZSBv cHRpb25hbCB3YXlzIHRvIHRpZS1icmVhaywgZXNwZWNpYWxseSBhcyB0aGUgbnVtYmVyIG9mIHBy ZWZlcmVuY2VzL3ByaW9yaXRpZXMgZXQgYWwuIG1lYW5zIHRoZSBudW1iZXIgY29tYmluYXRpb25z IGlzIGxhcmdlLg0KV2lsbCB1cGRhdGUgdGhlIHRleHQgYmFzZWQgb24geW91ciBhbmQgY28tYXV0 aG9y4oCZcyBzdWdnZXN0aW9ucy4NCg0KICAqICAgKDIuMTEpIFRoaXMgc3BlY2lmaWNhdGlvbiBv ZiBXRUNNUCBzZWVtcyBsaWtlIGl0IHNheXMgdGhlIHNhbWUgdGhpbmcgdGhhdCBpcyBpbiAyLjIg LS0gY2FuIHlvdSBjb25zaWRlciBtYWtpbmcgdGhlc2UgY29oZXJlbnRseSBzdGF0ZWQgaW4gdGhl IGRvY3VtZW50Pw0KU2VjIDIuMTEgdGFsa3MgYWJvdXQgaW5zdGFudGlhdGlvbiBvZiBwb2xpY3kg aW4gdGhlIGZvcndhcmRpbmcgcGxhbmUgYW5kIGRpc2N1c3NlcyBXRUNNUCBpbiB0aGF0IGNvbnRl eHQuIFdoaWxlIFNlYyAyLjIgYnJpbmdzIGluIHdlaWdodCBvbmx5IHRvIGRlc2NyaWJlIHRoZSBh c3NvY2lhdGlvbiBhbmQgaW50ZW50aW9uIGZvciBoYXZpbmcgbXVsdGlwbGUgU2VnbWVudC1MaXN0 cyB3aXRoaW4gYSBjYW5kaWRhdGUgcGF0aC4NCg0KICAqICAgKDMpIFdoYXQgaXMgdGhlIHJlYXNv biB0byBkZWZpbmUgYW4gU1ItREIgaGVyZT8gSXQgc2VlbXMgbGlrZSB0aGVyZSBpcyBsaXR0bGUg cmVmZXJlbmNlIHRvIHRoaXMgZWxzZXdoZXJlLCBhbmQgaXQgcmVwbGljYXRlcyBpbmZvcm1hdGlv biBmcm9tIG90aGVyIHBsYWNlcyAtIGUuZy4sIEJHUCBSSUIsIE1QTFMgbGFiZWwgdGFibGVzLCBh bmQgSUdQLVRFIGRhdGFiYXNlLiBEbyB5b3UgaW50ZW5kIHRoYXQgaW1wbGVtZW50b3JzIGNyZWF0 ZSBzb21lIG5ldyBsb29rdXAgb2YgdGhpcyBpbmZvcm1hdGlvbiwgb3IgaXMgdGhpcyBjb25jZXB0 dWFsPw0KVGhpcyBzZWN0aW9uIGlzIGNvbmNlcHR1YWwgYW5kIHRoaXMgaXMgaGlnaGxpZ2h0ZWQg d2l0aCB0aGUgdXNhZ2Ugb2YgbXVsdGlwbGUgTUFZIGtleXdvcmRzLiBJdCBoZWxwcyB0aGUgcmVh ZGVyIHRvIHVuZGVyc3RhbmQgYWxsIHRoZSBwaWVjZXMgb2YgaW5mb3JtYXRpb24gdGhhdCBoZWxw IGluIGNvbXB1dGF0aW9uIG9yIHZhbGlkYXRpb24gb2YgU1IgUG9saWN5LiBXZSB3aWxsIGFkZCB0 ZXh0IHRvIGNsYXJpZnkgdGhpcy4NCg0KICAgICAqICAgVGhpcyBjb25jZXB0IGlzIG9ubHkgZGVm aW5lZCBoZXJlIGluIHRoZSBkb2N1bWVudCAtLSBpc24ndCBpdCBqdXN0IGFuIGltcGxlbWVudGF0 aW9uIGRldGFpbCB0aGF0IGRvZXMgbm90IG5lZWQgdG8gYmUgc3RhbmRhcmRpemVkPw0KVGhpcyBj b25jZXB0IGlzIG5lY2Vzc2FyeSB0byBjbGFyaWZ5IHRvIGltcGxlbWVudGVycyBvbiB0aGUgbXVs dGlwbGUgcGllY2VzIG9mIGluZm9ybWF0aW9uIHRoYXQg4oCcTUFZ4oCdIGJlIHJlcXVpcmVkIGZv ciBTUiBQb2xpY3kgY29tcHV0YXRpb24gb3IgdmFsaWRhdGlvbi4NCg0KICAgICAqICAgV2h5IHNo b3VsZCB3ZSByZXBsaWNhdGUgdGhlIElHUCBjb250ZW50cyBpbiB0aGlzIFNSREI/DQpUaGVyZSBp cyBubyByZXBsaWNhdGlvbiByZXF1aXJlbWVudCBtZW50aW9uZWQuIFRoYXQgaXMgbGVmdCB0byB0 aGUgaW1wbGVtZW50YXRpb24gYXMgdGhpcyBpcyBjb25jZXB0dWFsLg0KDQogICAgICogICBZb3Ug YXJlIHJlY29tbWVuZGluZyBoZXJlIHRoYXQgaW5mb3JtYXRpb24gc3VjaCBhcyB0b3BvbG9neSBp cyBsZWFybnQgZnJvbSBvdGhlciBkb21haW5zIC0gd2h5IGlzIHRoaXMgYSByZXF1aXJlbWVudCBm b3IgU1ItVEUgcG9saWN5PyBJdCBjZXJ0YWlubHkgZG9lc24ndCBzZWVtIGxpa2UgYSBiYXNlIHJl cXVpcmVtZW50Lg0KSXQgaXMgYSBNQVkuIENlcnRhaW5seSBub3QgYSDigJxiYXNl4oCdIHJlcXVp cmVtZW50Lg0KDQogICAgICAgICAgICAgICAgICAgIFRvIGJlIGNsZWFyLCBJIHdvdWxkIHJlY29t bWVuZCByZW1vdmluZyB0aGlzIGVudGlyZSBzZWN0aW9uIGZyb20gdGhlIGRvY3VtZW50Lg0KSU1I TyBpdCBpcyBpbXBvcnRhbnQgY29uY2VwdHVhbCBpbmZvcm1hdGlvbiBmb3IgaW1wbGVtZW50ZXJz IGFuZCBoZW5jZSByZWxldmFudCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICogICAoNS4yKSBJIGZp bmQgdGhpcyB3aG9sZSBzZWN0aW9uIHVuZGVyLXNwZWNpZmllZCBhZ2Fpbi4NClRoZXJlIHdhcyBz cGVjaWZpY2F0aW9uIGZvciB0aGlzIGluIHRoZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoaXMgZHJh ZnQgd2hpY2ggd2FzIG1vdmVkIHRvIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29u c2lkZXJhdGlvbnMgKHBsZWFzZSBzZWUgU2VjIDMuMSB0aGVyZSkgdXBvbiB5b3VyIHJlcXVlc3Qu IEN1cnJlbnRseSB3ZSBoYXZlIHB1dCBhIGNyb3NzLXJlZmVyZW5jZSB0byB0aGF0IGRyYWZ0Lg0K VGhlIFBDRSBkcmFmdCByZWZlcmVuY2VkIGRvZXMgbm90IHNlZW0gdG8gdGVsbCBtZSBob3cgdG8g c3BlY2lmeSBhbiBvcHRpbWlzYXRpb24gb2JqZWN0aXZlLCBhbmQgdGhlcmUgZG9lc24ndCBzZWVt IHRvIGJlIGFueSBleHBsYW5hdGlvbiBvZiB3aGVyZSBvciBob3cgdGhpcyB3b3VsZCBiZSBzcGVj aWZpZWQgYXQgYSBoZWFkLWVuZCBpbiBjb25maWd1cmF0aW9uLiBJIHdvdWxkIHJlY29tbWVuZCBy ZW1vdmluZyB0aGlzIGZyb20gdGhpcyBkb2N1bWVudCBhcyBpdCBzZWVtcyB0byBiZSBlaXRoZXI6 DQpUaGUgUENFUCBkcmFmdCByZWZlcmVuY2VkIGRlc2NyaWJlcyB0aGUgcHJvdG9jb2wgZXh0ZW5z aW9ucyBmb3IgU1IsIHdoaWNoIGFyZSB1c2VkIGZvciBTUiBQb2xpY3kuIEl0IGRvZXMgbm90IGRl c2NyaWJlIHRoZSB2YXJpb3VzIG9wdGltaXphdGlvbiBtZXRyaWNzIGF2YWlsYWJsZSBpbiBQQ0VQ IHNpZ25hbGluZyBlLmcuIFJGQzU0NDAgYW5kIFJGQzgyMzMuDQoNCiAgICAgKiAgIEltcGxlbWVu dGF0aW9uIHNwZWNpZmljIC0tIGlmIGl0J3MgaW4gY29uZmlndXJhdGlvbi4gVGhlIG9ubHkgZGlm ZmVyZW5jZSBtaWdodCBiZSBpZiBvbmUgd2VyZSB0byB3YW50IHRvIHNwZWNpZnkgYSBZQU5HIG1v ZGVsIHRoYXQgc3BlY2lmaWNhbGx5IGRpc2N1c3NlcyBob3cgdG8gc3BlY2lmeSBzdWNoIG9iamVj dGl2ZXMuDQpUaGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IGlzIGludHJvZHVjaW5nIHRoZSBrZXkgY29u Y2VwdHMgYW5kIHN0cnVjdHVyZS4gVGhlIFlhbmcgbW9kZWwgaXRzZWxmIGlzIGNvdmVyZWQgYnkg YSBzZXBhcmF0ZSBkb2N1bWVudC4gVGhpcyBzcGVjaWZpYyBhc3BlY3Qgd2lsbCBiZSBjb3ZlcmVk IGluIGEgZnV0dXJlIHZlcnNpb24gb2YgZHJhZnQtdGhvbWFzLXNwcmluZy1zci1wb2xpY3kteWFu Zy4NCg0KICAgICAqICAgQSBmZXcgeWVhcnMgYWdvLCB3ZSBkaXNjdXNzZWQgdGhpcyB3aG9sZSBw cm9ibGVtIHNwYWNlLCBhbmQgdGhlIGNvbmNsdXNpb24gc2VlbWVkIHRvIGJlIHRoYXQgaGF2aW5n IHN1Y2ggb2JqZWN0aXZlcyBzcGVjaWZpZWQgb24gdGhlIGhlYWQtZW5kIHdvdWxkIGVuZCB1cCB3 aXRoIHNpZ25pZmljYW50IGNvZGUgY2h1cm4gLSBoYXZpbmcgYW4gb3BhcXVlIGlkZW50aWZpZXIg dGhhdCBjb3VsZCBiZSBoYW5kZWQgdG8gdGhlIFBDRSBzZWVtZWQgbW9yZSBsb2dpY2FsLg0KSSBi ZWxpZXZlIHlvdSByZWZlciB0byB0aGUgbm90aW9uIG9mIHByb2ZpbGUtSUQgaW4gUENFUCBmb3Ig c3BlY2lmeWluZyB0cmFmZmljIHN0ZWVyaW5nIGFuZCBvdGhlciBmZWF0dXJlcy4gVGhhdCBjb25j ZXB0IGlzIHN0aWxsIGFwcGxpY2FibGUgdG8gU1IgcG9saWN5Lg0KDQogICogICAoNikgUGxlYXNl IGNhbiB3ZSBzdG9wIHdyaXRpbmcgSUVURiBkb2N1bWVudHMgbGlrZSB0aGV5IGFyZSBtYXJrZXRp bmcgYSB0ZWNobm9sb2d5IC0gIlggaXMgZnVuZGFtZW50YWwgdG8gU2VnbWVudCBSb3V0aW5nIiBp cyBub3QgYSB1c2VmdWwgc3RhdGVtZW50LiBQbGVhc2Ugb2JqZWN0aXZlbHkgc3RhdGUgdGhlIHRl Y2huaWNhbCBiZW5lZml0LiBFaXRoZXIgd2F5LCB0aGlzIHNlZW1zIGxpa2UgdGhpcyBzZWN0aW9u IGNhbiBiZSByZW1vdmVkLg0KV2UgYmVsaWV2ZSB0aGlzIGlzIGEgdGVjaG5pY2FsIHBvaW50IGFu ZCB0aGUgcmVhc29ucyBhcmUgZXhwbGFpbmVkIGluIHRoZSBuZXh0IHNlbnRlbmNlIOKAkyDigJxp dCBwcm92aWRlcyBzY2FsaW5nLCBuZXR3b3JrIG9wYWNpdHkgYW5kIHNlcnZpY2UgaW5kZXBlbmRl bmNl4oCdLiBJZiB5b3UgdGhpbmsgb3RoZXJ3aXNlLCBwbGVhc2UgbGV0IHVzIGtub3cuDQoNCiAg KiAgICg2LjIpIFBsZWFzZSBtYWtlIGl0IGEgTVVTVCB0aGF0IGFuIGFsZXJ0IG9mIHNvbWUgZm9y bSBpcyBnZW5lcmF0ZWQgd2hlbiB0aGUgQlNJRCBpcyBub3QgYXZhaWxhYmxlLiBPdGhlcndpc2Ug aXQgaXMgZW50aXJlbHkgb3BhcXVlIHRvIGFuIG9wZXJhdG9yIHRoYXQgdGhpcyB3YXNuJ3QgYWNj ZXB0ZWQgYW5kIHRoYXQgdGhlaXIgcG9saWN5IGlzIG5vdCBpbiB1c2UuDQpBZ3JlZWQuIFdlIHdp bGwgdXBkYXRlIHRoaXMgaW4gdGhlIHRleHQuDQoNCg0KICAqICAgKDYuMikgSW4gdGhlIGNhc2Ug b2YgQlNJRCBzdGlja2luZXNzLCBpZiBDYW5kaWRhdGVQYXRoMSBzcGVjaWZpZXMgbGFiZWwgNDIg KGFzc3VtZWQgdG8gYmUgaW4gU1JMQiksIGFuZCBpcyBtb3JlIHByZWZlcmFibGUgdGhhbiBDYW5k aWRhdGVQYXRoMiB0aGVuIEFJVUksIHdlJ2xsIGluc3RhbGwgdGhpcyBwb2xpY3kgYW5kIHVzZSBs YWJlbCA0Mi4gSWYgd2UgYXNzdW1lIHRoYXQgdGhlcmUncyBzb21lIHNlY29uZCBDYW5kaWRhdGVQ YXRoMiwgd2hpY2ggZG9lcyBub3Qgc3BlY2lmeSBhIEJTSUQuIElmIENhbmRpZGF0ZVBhdGgxIGlz IHN1YnNlcXVlbnRseSB3aXRoZHJhd24sIGV2ZW4gdGhvdWdoIENhbmRpZGF0ZVBhdGgyIGRvZXNu J3Qgc3BlY2lmeSBhIEJTSUQsIGxhYmVsIDQyIHdpbGwgYmUgcmV0YWluZWQuIElmIENQMSBpcyBu b3cgcmUtYWR2ZXJ0aXNlZCwgd2hhdCBoYXBwZW5zIC0gaXMgdGhpcyBCU0lEIGNvbnNpZGVyZWQg InVzZWQiIGV2ZW4gdGhvdWdoIGl0J3MgZXNzZW50aWFsbHkgbm93IGEgZHluYW1pYyBhbGxvY2F0 aW9uIHdpdGhpbiB0aGUgU1JMQj8NCkNQMSB3aWxsIGJlIHByZWZlcnJlZCBhbmQgc2luY2UgNDIg d2FzIHNwZWNpZmllZCBCU0lEIGZvciBpdCwgaXQgd2lsbCB1c2UgdGhlIHNhbWUgQlNJRC4NCg0K ICAqICAgKDYuNCkgU3BlY2lmeWluZyBiaW5kaW5nIFNJRHMgY2FuIGJlIGFzc2lnbmVkIHRvIGFu eSBlbGVtZW50IGRvZXNuJ3Qgc2VlbSB0byBoYXZlIGFueSByZWFsIGJlbmVmaXQgb2YgYmVpbmcg aW4gdGhpcyBkcmFmdC4gSWYgdGhlcmUgYXJlIG5ldyBCU0lEIGJpbmRpbmdzIHRoYXQgYWN0dWFs bHkgcmVxdWlyZSBzdGFuZGFyZGlzYXRpb24gLSB0aGVuIEkgd291bGQgaGlnaGx5IHJlY29tbWVu ZCBwdXR0aW5nIGluIHRoZWlyIG93biBkcmFmdC4gdGhlcmUgYXJlIG1hbnkgcXVlc3Rpb25zIHRo YXQgY29tZSBmcm9tIHRoaXMgc2hvcnQgcGFyYWdyYXBoLiBGb3IgZXhhbXBsZSwgaG93IGFyZSB0 aG9zZSBiaW5kaW5nIFNJRHMgY29uc2lkZXJlZCB2YWxpZD8gSXMgdGhlcmUgT0FNIGludGVyd29y a2luZyB0aGF0IGlzIG5lZWRlZCB3aXRoIG90aGVyIG5ldHdvcmtzIGZvciBsaXZlbGluZXNzIGRl dGVjdGlvbiBldGMuIFdlIGV4cGxpY2l0bHkgcmVtb3ZlZCBhIGxvdCBvZiB0aGUgQlNJRC0+UlNW UCBpbmNsdWRpbmcgRVJPIGFkdmVydGlzZW1lbnQgaW4gZWFybGllciByZXZpc2lvbnMgb2YgU1Ig cmVsYXRlZCBJR1AgZHJhZnRzLg0KVGhpcyBpcyBhbiBpbXBvcnRhbnQgY29uY2VwdCBmb3IgdGhl IEJTSUQgYXMgaXQgcmVsYXRlcyB0byBTUiBQb2xpY3kgYW5kIG5lZWRzIHRvIGJlIGNvdmVyZWQg aW4gdGhpcyBhcmNoaXRlY3R1cmUgZHJhZnQuIEEgUG9saWN5IGNhbiBiZSBhbiBpbnN0cnVjdGlv biB0byBzdGVlciBvdmVyIGEgc3BlY2lmaWMgaW50ZXJmYWNlLiBUaGUgcmVsZXZhbnQgZXhhbXBs ZXMgd2VyZSBleHBsYWluZWQgaW4gYSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgYnV0 IHdlcmUgbW92ZWQgaW50byBkcmFmdC1maWxzZmlscy1zci1wb2xpY3ktY29uc2lkZXJhdGlvbnMg YmFzZWQgb24geW91ciBpbnB1dC4gSW4gZmFjdCwgdGhlIGRldGFpbHMgZm9yIHRoZSBvcHRpY2Fs IFNSIHBhdGggdXNlLWNhc2UgZGVzY3JpYmVkIGluIGRyYWZ0LWFuYW5kLXNwcmluZy1wb2ktc3Ig YnVpbGRzIG9uIHRvcCBvZiB0aGlzIGNvbnN0cnVjdC4NCg0KDQogICogICAoNykgVGhlIFNSLVRF IFBvbGljeSBTdGF0ZSBpcyBkZWZpbmVkIGhlcmUgdG8gY29udGFpbiB0aGUgcmVhc29uIHRoYXQg YSBwb2xpY3kgb3IgY2FuZGlkYXRlIHBhdGggaXMgbm90IHZhbGlkLCBob3dldmVyLCB0aGUgZW5j b2RpbmdzIGluIGlldGYtaWRyLXRlLWxzcC1kaXN0cmlidXRpb24gZG9uJ3Qgc2VlbSB0byBzYXkg aG93IHRoaXMgc2hvdWxkIGJlIGVuY29kZWQuIElzIHRoaXMgdGhlIHJpZ2h0IHJlZmVyZW5jZT8g SXMgdGhlcmUgZXh0ZW5zaW9uIHRvIHRoYXQgd29yayB3aGljaCBpcyByZXF1aXJlZD8NCllvdXIg b2JzZXJ2YXRpb25zIGFyZSBjb3JyZWN0LiBUaGlzIHdhcyBpbnRyb2R1Y2VkIGluIGRyYWZ0LWll dGYtaWRyLXRlLWxzcC1kaXN0cmlidXRpb24tMDkuIFNpbmNlIHRoaXMgaXMgdGhlIGFyY2hpdGVj dHVyZSBkb2N1bWVudCwgdGhpbmdzIGFyZSBsaWtlbHkgdG8gY29tZSBoZXJlIGZpcnN0IGJlZm9y ZSB3ZSB3b3JrIG9uIG5lY2Vzc2FyeSBleHRlbnNpb25zIGluIHRoZSBwcm90b2NvbHMuDQoNCiAg KiAgICg4LjEgKyA4LjIpIFRoZSBkb2N1bWVudCBhcHBlYXJzIHRvIGhhdmUgbXVsdGlwbGUgZGlm ZmVyZW50IHBsYWNlcyB3aGVyZSBpdCBkaXNjdXNzZXMgdmFsaWRpdHkuIElzIHRoZXJlIGEgcmVh c29uIHRoYXQgdGhpcyBjYW4ndCBiZSBjb3ZlcmVkIGluIDIuMTAgb3IgMi4xMT8gVGhpcyB3b3Vs ZCBiZSBhIG1vcmUgbmF0dXJhbCBwbGFjZSBmb3IgdGhlIGRlZmluaXRpb24gb2YgImRyb3Agb24g aW52YWxpZCIgdG9vLg0KV2UgaGF2ZSBwdXQgYSByZWZlcmVuY2UgdG8gdGhlIHNlY3Rpb25zIDIu MTAgYW5kIDUgd2hpY2ggZGVzY3JpYmUgdGhlIHZhbGlkaXR5IG9mIFNSIFBvbGljeSBpbiB0aGUg dGV4dCBvZiBzZWN0aW9uIDguMS4gVGhlIOKAnGRyb3Agb24gaW52YWxpZOKAnSBpcyBhIHN0ZWVy aW5nIGFuZCBmb3J3YXJkaW5nIHBsYW5lIG5vdGlvbiBhbmQgaGVuY2UgbW9yZSBhcHByb3ByaWF0 ZSB1bmRlciBTZWN0aW9uIDguDQoNCiAgKiAgICg4LjIpIERyb3Agb24gaW52YWxpZCBhcHBlYXJz IHVuZGVyc3BlY2lmaWVkIHRvIG1lIGhlcmUgLS0gc2hvdWxkIGl0IGJlIG1haW50YWluZWQgd2hl biB0aGVyZSB3YXMgYW4gYWN0aXZlIEJTSUQgYnV0IGFsbCByZW1vdGUgd2F5cyBvZiBhZHZlcnRp c2luZyBpdCB3ZW50IGF3YXksIG9yIG9ubHkgd2hlbiBhbGwgcGF0aHMgaW4gdGhlaXIgZW50aXJl dHkgYXJlIGludmFsaWQ/DQpUaGlzIGlzIHdoZW4gYWxsIHRoZSBjYW5kaWRhdGUgcGF0aHMgb2Yg dGhlIFNSIFBvbGljeSBhcmUgaW52YWxpZCBhbmQgaGVuY2UgdGhlIHBvbGljeSBpcyBpbnZhbGlk Lg0KSWYgdGhlIHBvbGljeSBkaWQgbm90IHNwZWNpZnkgYSBCU0lEIC0gaS5lLiwgaXQgd2FzIGR5 bmFtaWNhbGx5IGFsbG9jYXRlZCwgc2hvdWxkIHRoaXMgYmUgZnJlZWQ/DQpBcyBpcyBtZW50aW9u ZWQgaW4gc2VjIDguMiwgZm9yIGRyb3Atb24taW52YWxpZCBTUiBQb2xpY2llcywgdGhlIEJTSUQg aXMgcmVxdWlyZWQgYW5kIHJldGFpbmVkIGluIHRoZSBmb3J3YXJkaW5nIGJ1dCB3aXRoIGFuIGFj dGlvbiB0byBkcm9wIHRoZSB0cmFmZmljIG1hdGNoaW5nIGl0Lg0KDQpXaGF0IGlzIHRoZSBiZWhh dmlvdXIgd2hlbiB3ZSBoYXZlIElQMk1QTFMgZW50cmllcyB0aGF0IHJlbHkgb24gdGhhdCBwb2xp Y3kgLS0gdGhleSBzaG91bGQgbmV2ZXIgZmFsbCBiYWNrIHRvIG90aGVyIG1lY2hhbmlzbXMgb2Yg cm91dGluZyB0aGUgdHJhZmZpYyB2aWEgYW4gYWx0ZXJuYXRlIE1QTFMgdHVubmVsLCBvciBhbHRl cm5hdGUgSVAgZm9yd2FyZGluZyBlbnRyeT8NClNpbmNlIGl0IGlzIG1hcmtlZCBhcyBkcm9wLW9u LWludmFsaWQsIHRoZW4gdGhlIHRyYWZmaWMgbWF0Y2hpbmcgdGhlIGlwMm1wbHMgZW50cmllcyBh bmQgZ2V0dGluZyBzdGVlcmluZyBpbnRvIHRoaXMgcG9saWN5IHdvdWxkIGFsc28gZ2V0IGRyb3Bw ZWQuIFRoZSDigJxub3JtYWzigJ0gZGVmYXVsdCBiZWhhdmlvciBmb3IgU1IgUG9saWN5IHdvdWxk IGJlIHRoYXQgb24gYmVjb21pbmcgaW52YWxpZCwgaXQgd291bGQgYmUgdGFrZW4gb3V0IGFuZCB3 ZSB3b3VsZCBmYWxsYmFjayB0byBvdGhlciBhbHRlcm5hdGVzIG9yIHRoZSBJUCBmb3J3YXJkaW5n LiBTbyBkcm9wLXVwb24taW52YWxpZCBpcyByZWFsbHkgYSBzcGVjaWFsIGJlaGF2aW9yLg0KDQog ICogICAoOS4yKSBJdCdzIHZlcnkgdW5jbGVhciB0byBtZSBob3cgb25lIGFjdHVhbGx5IHByb3Zp c2lvbnMgdGhpcyBsaW5rIHByb3RlY3RpbmcgcG9saWN5LiBZb3UgaGF2ZSA8Y29sb3VyLCBlbmRw b2ludD4gYXMgdGhlIHVuaXF1ZSB0dXBsZSAtLSB3aGF0IGlzIHRoZSBwb2xpY3kgdGhhdCBvbmUg aW5zdGFsbHMgdXNpbmcgdGhlIGZyYW1ld29yayB0aGF0IGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1 bWVudCB0byBkZWZpbmUgYW4gU1ItVEUgcG9saWN5IGZvciBsaW5rIHByb3RlY3Rpb24/IFdoYXQn cyB0aGUgbWF0Y2ggY3JpdGVyaWEgZm9yIGl0Pw0KVGhlIFNSIFBvbGljeSBpcyBsb2NhbGx5IGNv bmZpZ3VyZWQgYXMgYSBiYWNrdXAgcGF0aCBmb3IgcHJvdGVjdGluZyB0aGUgc3BlY2lmaWMgbGlu ay4gV2UgaGF2ZSBhZGRlZCB0ZXh0IHRvIG1lbnRpb24gdGhpcy4NCg0KICAqICAgKDkuMykgVGhp cyBoYXMgYSBzaW1pbGFyIHByb2JsZW0gYXMgdGhlIHBvaW50IHJhaXNlZCBhYm92ZSBhYm91dCBo b3cgb25lIHNwZWNpZmllcyB0aGF0IGEgcG9saWN5IGlzIGEgYmFja3VwIGZvciBhbm90aGVyIHBv bGljeS4NCk5vdGUgdGhhdCA5LjMgaXMgYWJvdXQgc3BlY2lmeWluZyBvbmUgQ1AgYXMgYmFja3Vw IGZvciBhbm90aGVyIHdpdGhpbiB0aGUgc2FtZSBTUiBQb2xpY3kgYW5kIHNvIGl0IGlzIGRpZmZl cmVudCBmcm9tIDkuMi4gVGhlIGJhY2t1cCBpcyBwcm92aXNpb25lZCBhbmQgd2UgaGF2ZSBhZGRl ZCBzb21lIHRleHQgdG8gY2xhcmlmeSB0aGlzLiBUaGlzIGlzIG5vdCB5ZXQgc29tZXRoaW5nIGNv dmVyZWQgaW4gdGhlIHNpZ25hbGluZyBvciB0aGUgWWFuZyBtb2RlbCDigJMgYnV0IHNvbWV0aGlu ZyB0aGF0IGlzIG5lY2Vzc2FyeSBmb3IgYWNoaWV2aW5nIGZhc3QtcmVyb3V0ZSB3aXRoIHBhdGgg cHJvdGVjdGlvbiBmb3IgU1IgUG9saWN5IENhbmRpZGF0ZSBwYXRocy4NClRoYW5rcyBmb3IgeW91 ciByZXZpZXcgb2YgdGhlc2UgaXNzdWVzLiBIYXBweSB0byBkaXNjdXNzIHRoZW0gb24gdGhlIGxp c3QgZnVydGhlci4NCg0KS2luZCByZWdhcmRzLA0Kci4NCg== --_000_9ba2813b9f9b4800baf4ba8255242d6bXCHALN011ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6ODQ4NDQ4NzE4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTU0NTE4NjQxMjt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgUm9iLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWFueSB0aGFua3MgZm9yIHlvdXIgY29tbWVu dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIG91ciBy ZXNwb25zZSBpbi1saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5TaXZhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPnAuczogV2Ugd2lsbCBi ZSBwb3N0aW5nIGEgbmV3IHJldmlzaW9uIG9mIHRoZSBTUiBwb2xpY3kgZHJhZnQgcmVmbGVjdGlu ZyB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5zcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgUm9i IFNoYWtpciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmpzPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZyI+cm9ianM9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VHVlc2RheSwgSnVseSAyNCwgMjAxOCBhdCA1OjA0IFBNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LXBvbGljeUB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LXBvbGljeUB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFm dC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5QHRvb2xzLmlldGYub3JnIj5kcmFm dC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5QHRvb2xzLmlldGYub3JnPC9hPiZn dDssDQogU1BSSU5HIFdHIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmci PnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltzcHJpbmddIENv bW1lbnRzIG9uIGRyYWZ0LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbE9yaWdpbmFsQm9keSI+KEFzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3IpIDxvOnA+ DQo8L286cD48L2E+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkhpIEF1dGhvcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSBoYXZlIGEgbnVtYmVyIG9mIGNvbW1lbnRz IG9uIGRyYWZ0LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LCBzb21lIGFyZSB0ZWNobmlj YWwsIHNvbWUgYXJlIGVkaXRvcmlhbC4mbmJzcDsgRnJhbmtseSwgSSBmaW5kIHRoaXMgZG9jdW1l bnQgcXVpdGUgZGlmZmljdWx0IHRvIHJlYWQgc2luY2UgaXQgZG9lc24ndCBjb2hlcmVudGx5DQog bWFrZSB1cCBhIHNwZWNpZmljYXRpb24gLSBhbmQgcmF0aGVyIGp1bXBzIGFib3V0IHF1aXRlIGEg bG90LCB3aXRoIGEgbnVtYmVyIG9mIHRoaW5ncyBiZWluZyByZS1zdGF0ZWQuIEkgdW5kZXJzdGFu ZCB0aGF0IHRoaXMgaGFwcGVucyBkdXJpbmcgZGV2ZWxvcG1lbnQgb2YgYSBzcGVjaWZpY2F0aW9u LCBidXQgbm93IHRoaXMgaXMgYSBXRyBkb2MsIHdlIHNob3VsZCBmb2N1cyBvbiBtYWtpbmcgdGhp cyBkb2N1bWVudCBhcyBjbGVhciBhcyBpdCBjYW4NCiBiZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5QbGVhc2UgZmluZCBteSBzcGVjaWZpYyBjb21tZW50cyBi ZWxvdzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPigxLiBJbnRyb2R1Y3Rp b24pIEluIHRoaXMgc2VjdGlvbiB5b3UgdXNlIHRoZSB3b3JkaW5nICZxdW90O2F1Z21lbnRlZCB3 aXRoIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyZxdW90OyAtIEkgd291bGQgc3VnZ2VzdCBy ZXdvcmRpbmcgdGhpcy4gV2hpbHN0IGl0IG1pZ2h0IGJlIHRoZSBjYXNlIGZvciBTUnY2LCBmb3Ig U1ItTVBMUywgZWl0aGVyIHdlJ3JlIGRvaW5nIHBvcCYjNDM7cHVzaCwNCiBvciBzaW1wbHkgcHVz aGluZyB0aGUgbmV3IHNlZ21lbnQgbGlzdC4gSW4gdGhpcyBjYXNlLCBpdCdzIG5vdCByZWFsbHkg JnF1b3Q7YXVnbWVudGluZyZxdW90OywgYnV0IGFkZGluZyBhIG5ldyBzdGFjayBvZiBoZWFkZXJz LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PGk+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxQjA2OTYiPkZvciBTUi1NUExTLCB3aGVuIHdlIHN0ZWVyIGludG8gdGhlIFNS IFBvbGljeSB3ZSBhcmUgZG9pbmcgYW4gaW1wb3NpdGlvbiBvZiB0aGUgbGFiZWwgc3RhY2sgY29y cmVzcG9uZGluZw0KIHRoZSBTSUQgbGlzdCBvbiB0aGUgcGFja2V0LiBTbyB3ZSBhcmUgYWRkaW5n IGxhYmVscy4gU2luY2UgdGhlIHdvcmQgaW1wb3NpdGlvbiBoYXMgc3BlY2lhbCBjb25ub3RhdGlv bnMgd2l0aCBNUExTLCB3ZSB0aG91Z2h0IHRoYXQg4oCcYXVnbWVudOKAnSB3b3VsZCBiZSBhIG5l dXRyYWwgd29yZCB0aGF0IGZpdHMgYm90aCBTUnY2IGFuZCBTUi1NUExTLjwvc3Bhbj48L2k+PC9i Pjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48 c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+PG86cD48L286cD48L3NwYW4+PC9iPjwvc3Bhbj48 L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPigyLiBTUiBQb2xpY3kpIFRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhpcyBzZWN0aW9uIGlzbid0 IHJlYWxseSBjbGVhciB0byBtZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjx1bCB0 eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5XaGF0IGlzIG1lYW50IGJ5IGEgJnF1b3Q7c3BlY2lmaWMgaW50ZW50JnF1 b3Q7PyBJIHRoaW5rIHRoYXQgbXVsdGlwbGUgJnF1b3Q7aW50ZW50cyZxdW90OyBtaWdodCBoYXZl IHRoZSBzYW1lIFNSIHBvbGljeSAtIGUuZy4sIHNvbWUgbGF0ZW5jeSBvcHRpbWlzYXRpb24gYW5k IElHUCBzaG9ydGVzdCBwYXRoIGFyZSBkaWZmZXJlbnQgJnF1b3Q7aW50ZW50cyZxdW90OywgYnV0 IGFyZSBsaWtlbHkgdG8gbWVhbiB0aGUgc2FtZQ0KIHBvbGljeS4gQ29uc2lkZXIgcmV3b3JkaW5n IHRoaXMgdG8gYSAmcXVvdDtjb21tb24gcGF0aGluZyBiZWhhdmlvdXImcXVvdDsgb3Igc2ltaWxh ci48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48 c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+WW91IGFyZSByaWdodCB0aGF0IGEgU1IgUG9saWN5 IHdpdGggbGF0ZW5jeSBvcHRpbWl6YXRpb24gaW50ZW50IGFuZCBJR1Agc2hvcnRlc3QgcGF0aCBp bnRlbnQgbWF5IGhhdmUNCiB0aGUgc2FtZSBwYXRoIOKAkyBhbmQgaGVuY2UgdGhlIHNhbWUg4oCc cGF0aGluZyBiZWhhdmlvcuKAnS4gQnV0IHRoZWlyIGludGVudCBpcyBkaWZmZXJlbnQgYW5kIHF1 aXRlIGxpa2VseSB3aXRoIHNvbWUgbmV0d29yayB0b3BvbG9neSBvciBvdGhlciBjaGFuZ2VzLCB0 aGVpciBwYXRoIHdvdWxkIGRpdmVyZ2UuIEhlbmNlIHRoZSBlbXBoYXNpcyBvbiDigJxpbnRlbnTi gJ0gcmF0aGVyIHRoYW4gdGhlIOKAnHBhdGhpbmfigJ0uPC9zcGFuPjwvaT48L2I+PC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPldoeSBkbyB3ZSBuZWVkIHRvIHJlZmVyIHRvIHdoYXQgdGhlIFNSIGFyY2hpdGVjdHVy ZSBzYXlzIGFib3V0IGluc3RydWN0aW9ucz8gSXQgc2VlbXMgdG8gbWUgaGVyZSB0aGUgY29yZSBw b2ludCBpcyAmcXVvdDtBbiBTUiBQb2xpY3kgbWF5IGNvbnNpc3Qgb2YgYW55IHR5cGUgb2Ygc2Vn bWVudCZxdW90Oy4gSXMgdGhlcmUgYSB0ZWNobmljYWwgcmVhc29uIHRvIG5vdCBqdXN0IHdvcmQg dGhpcw0KIG1vcmUgc2ltcGx5PzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij5UaGUgcmVhc29uIGlz IHRvIHNpbXBseSByZW1pbmQgdGhhdCB0aGUgaW5zdHJ1Y3Rpb25zIGFyZSBub3QganVzdCB0b3Bv bG9naWNhbCAoZS5nLiBmb3IgYSBURSB1c2UtY2FzZSkNCiBidXQgYWxzbyB3aWRlciB0byBpbmNs dWRpbmcgb3RoZXJzIGxpa2Ugc2VydmljZSBzZWdtZW50cy48L3NwYW4+PC9pPjwvYj48L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPigyLjEgSWRlbnRp ZmljYXRpb24gb2YgYW4gU1IgcG9saWN5KSBXaGVyZSB0aGVyZSBpcyBhICZsdDtoZWFkZW5kLCBl bmRwb2ludCwgY29sb3VyJmd0OyB0dXBsZSwgSSBiZWxpZXZlIHRoYXQgdGhlIGludGVudGlvbiBo ZXJlIGlzIHRvIHNheSB0aGF0IHRoZSBoZWFkZW5kIElQdls0Nl0gYWRkcmVzcyBpcyBkb21haW4g dW5pcXVlIC0tIGlzIHRoaXMgZXhwZWN0ZWQsIGlmIHNvLCBzaG91bGQNCiBpdCBiZSBzdGF0ZWQ/ PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFCMDY5NiI+QWdyZWUgYW5kIHdpbGwgYWRkIHRleHQgdG8gY2xhcmlmeSB0aGUg c2FtZS48L3NwYW4+PC9pPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPigyLjEpICZxdW90O0FuIGltcGxlbWVudGF0aW9uIE1BWSBhbGxvdyBh c3NpZ25tZW50IG9mIGEgc3ltYm9saWMgbmFtZSZxdW90OyAtIHRoZSBNVVNUIE5PVCB0aGF0IGlz IHNwZWNpZmllZCBoZXJlIGlzIGludGVyZXN0aW5nLiBJIGJlbGlldmUgSGFyaXNoIGFza2VkIGEg c2ltaWxhciBxdWVzdGlvbiBpbiB0aGUgd29ya2luZyBncm91cC4gV2hhdCBpcyB0aGUgaW50ZW50 aW9uIHdpdGggdGhlDQogTVVTVCBOT1Q/IE9wZXJhdGlvbmFsbHksIHNob3VsZCB0aGVzZSBuYW1l cyBiZSB1bmlxdWUgcGVyIHBvbGljeSAob3RoZXJ3aXNlLCBpdCBzZWVtcyB0aGV5IGFyZSBwcm9i YWJseSBub3QgdGhhdCB1c2VyIGZyaWVuZGx5IGZvciBpZGVudGlmaWNhdGlvbikuPG86cD48L286 cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6 IzFCMDY5NiI+V2Ugd2lsbCB1cGRhdGUgdGhlIHRleHQgdG8gcmVtb3ZlIHRoZSBNVVNUIE5PVCBh bmQgY2xhcmlmeSB0aGUgdXNhZ2UuPC9zcGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4oMi4uMikgVGhlcmUgaXMgc29tZSByZXBl dGl0aW9uIGluIHRoaXMgc2VjdGlvbiB3aGljaCBtYWtlcyBpdCBxdWl0ZSB1bmNsZWFyIC0tIEkg YmVsaWV2ZSB0aGUga2V5IHBvaW50cyBhcmU6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+QSBwb2xpY3kgaGFzIGEgc2V0IG9mIGNhbmRpZGF0ZSBwYXRo cy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwyIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+VGhvc2UgY2FuZGlkYXRlIHBhdGhzIGNhbiBiZSBkeW5hbWljIG9yIGV4cGxpY2l0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDIgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5DYW5kaWRhdGUgcGF0aHMgY29tcHJpc2Ugb2YgYSBzZXQgb2Ygb25lIG9yIG1vcmUgU0lEIGxp c3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDIgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij5FeHBsaWNpdCBjYW5kaWRhdGUgcGF0aHMgaGF2ZSBleHRlcm5hbGx5ICh0byB0aGUg cm91dGVyKSBzcGVjaWZpZWQgU0lEIGxpc3RzLiBEeW5hbWljIG9uZXMgYXJlIGNvbXB1dGVkIG9u IHRoZSBTSUQgbGlzdHMuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPldpdGhpbiBlYWNoIFNJRCBsaXN0LCB0cmFmZmljIGlzIGxvYWQt YmFsYW5jZWQgYWNyb3NzIHRoZSBTSUQtbGlzdHMgYWNjb3JkaW5nIHRvIGEgd2VpZ2h0Ljxicj4N Cjxicj4NCklzIHRoaXMgc2VjdGlvbiBzYXlpbmcgc29tZXRoaW5nIGVsc2Ugb3RoZXIgdGhhbiB0 aGUgYWJvdmUgLS0gaWYgbm90LCBJIHJlY29tbWVuZCByZXdvcmRpbmcgaXQgdG8gbm90IHRvIGhh dmUgYXMgbWFueSBkZWNpc2lvbiBjcml0ZXJpYSBpbiBpdCB0byBwYXJzZS48bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzFCMDY5NiI+V2Ugd2lsbCByZW1vdmUgYSByZXBlYXRlZCBzZW50ZW5jZSBpbiB0aGVyZSB0 byBpbXByb3ZlIHRoZSB0ZXh0Ljwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+ PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+KDIuMikgVGhlIHdob2xlIHN1Yi1wYXJhZ3Jh cGggYWJvdXQgcmVwbGljYXRpb24gaXMgaHVnZWx5IHVuZGVyc3BlY2lmaWVkLiBXZSBzYXkgYWJv dmUgdGhhdCB0cmFmZmljIGlzIGxvYWQtYmFsYW5jZWQgYWNyb3NzIHRoZSBTSUQgbGlzdHMgLSBi dXQgdGhlbiB3ZSBzYXkgdGhhdCB0cmFmZmljIG1pZ2h0IGJlIHJlcGxpY2F0ZWQuIFRoZSBJRFIg ZHJhZnQsIGFuZCB0aGlzDQogZHJhZnQgaGF2ZSBubyBmdXJ0aGVyIG1lbnRpb24gb2YgJnF1b3Q7 cmVwbGljYXRpb24mcXVvdDsuIEkgd291bGQgaGlnaGx5IHJlY29tbWVuZCByZW1vdmluZyB0aGlz IHNlY3Rpb24sIHNpbmNlIEkgdGhpbmsgc3BlY2lmeWluZyB0aGlzIGZ1bGx5IHJlcXVpcmVzIHNp Z25pZmljYW50bHkgbW9yZSB3b3JrLCBhbmQgaXMgYmV0dGVyIGRvbmUgaW4gYW5vdGhlciBkcmFm dC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUIwNjk2Ij5XZSB3aWxsIHJlbW92ZSB0aGlzIHRleHQgZnJvbSB0aGlzIGRy YWZ0IHNpbmNlIHRoaXMgdG9waWMgaXMgbm93IGJlaW5nIHdvcmtlZCBvbiBpbiBkcmFmdC12b3ll ci1zcHJpbmctc3ItcDJtcC1wb2xpY3ksDQogd2hpY2ggd2FzIG5vdCBhdmFpbGFibGUgYXQgdGhl IHRpbWUgb2Ygd3JpdGluZyB0aGUgU1IgUG9saWN5IGFyY2hpdGVjdHVyZSBkcmFmdC48L3NwYW4+ PC9pPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPigyLjMpIEkgd291bGQgcmVjb21tZW5kIHRoYXQgdGhlICZxdW90O0xvY2FsJnF1b3Q7IHNo b3VsZCBzaW1wbHkgc2F5ICZxdW90O3ZpYSBjb25maWd1cmF0aW9uJnF1b3Q7LiAmcXVvdDtZYW5n IG1vZGVsIHRocm91Z2ggTkVUQ09ORiZxdW90OyBpc24ndCBhY2N1cmF0ZSBzaW5jZSBZQU5HIGFu ZCBORVRDT05GIGFyZSBub3QgY291cGxlZCwgYW5kIGdSUEMgaGVyZSBpcyBhbWJpZ3VvdXM8bzpw PjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJj b2xvcjojMUIwNjk2Ij5BZ3JlZSBhbmQgd2lsbCB1cGRhdGUgdGhlIHRleHQuPC9zcGFuPjwvaT48 L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4o Mi4zJm5ic3A7JiM0MzsgMi4xMikgVGhlcmUgYXJlIGEgbG90IG9mIHByaW9yaXRpZXMgYW5kIHBy ZWZlcmVuY2VzIGdvaW5nIG9uIGluIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9s aT48L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPldlIGhhdmUgcHJvdG9jb2wgb3JpZ2luLCBwcmVm ZXJlbmNlLCBhbmQgdGhlbiBwcmlvcml0eS4gSSB3b3VsZCByZWNvbW1lbmQgcmVzdHJ1Y3R1cmlu ZyB0byBkaXNjdXNzIGNsZWFybHkgaG93IHRoZXNlIGFsbCByZWxhdGUgdG8gZWFjaCBvdGhlci48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3Bh biBzdHlsZT0iY29sb3I6IzFCMDY5NiI+U2VjIDIuOSBkb2VzIHRoaXMuPC9zcGFuPjwvaT48L2I+ PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHVs IHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPkZyb20gbXkgcGFyc2luZywgeW91ciBpbnRlbnRpb24gaXMgdG8gc2F5 Og0KPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNjIj4N Cjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMyBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPldpdGhpbiBhbiBpbmRpdmlkdWFsIFNSIHBvbGljeSB0aGUg Y2FuZGlkYXRlIHBhdGggdG8gc2VsZWN0IGlzIHNwZWNpZmllZCB1c2luZyBwcmVmZXJlbmNlLiBJ ZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIHRoZSBsb2FkLXNoYXJpbmcgc2VjdGlvbiBpbiAyLjIg c2hvdWxkIHN0YXRlIHRoYXQgdGhpcyBpcw0KPGI+b25seTwvYj4mbmJzcDt3aGVuIHRoZSBjYW5k aWRhdGUgcGF0aHMgYXJlIG9mIHRoZSBzYW1lIHByZWZlcmVuY2UuIDxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PC91bD4NCjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0i Y29sb3I6IzFCMDY5NiI+U2VsZWN0aW9uIGVuc3VyZXMgb25lIGFuZCBvbmx5IG9uZSBDUCBpcyBz ZWxlY3RlZCBhbmQgbG9hZCBzaGFyaW5nIGhhcHBlbnMgYmV0d2VlbiBTZWdtZW50LUxpc3RzIG9m DQogdGhlIHNlbGVjdGVkIGNhbmRpZGF0ZSBwYXRoLjwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFCMDY5NiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNj Ij4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8dWwgdHlwZT0ic3F1 YXJlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWw0IGxmbzEiPg0K PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+U2VlIGZ1cnRoZXIg Y29tbWVudHMgb24gY2FuZGlkYXRlIHBhdGhzIGFuZCBiYWNrdXBzIGJlbG93LjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC91bD4NCjwvdWw+DQo8L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNjIj4N Cjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMyBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPklmIG11bHRpcGxlIFNSIHBvbGljaWVzIHRoYXQgaGF2ZSB0 aGUgc2FtZSAmbHQ7Y29sb3VyLCBlbmRwb2ludCZndDsgYXJlIHNwZWNpZmllZCwgdGhlbiB0aGUg cHJvdG9jb2wtb3JpZ2luIGlzIHVzZWQgdG8gc2VsZWN0IGJldHdlZW4gdGhlbS4gWW91IHNob3Vs ZCBleHBsaWNpdGx5IHN0YXRlIHdoZXRoZXIgcHJvdG9jb2wtb3JpZ2luIGlzIGJldHRlciBhcyBs b3dlciBvciBoaWdoZXIuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC91bD4NCjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij5JdCBpcyBzcGVj aWZpZWQgdGhhdCBoaWdoZXIgaXMgYmV0dGVyLiBQbGVhc2Ugc2VlIFNlYyAyLjkgd2hlcmUgdGhl IHRpZWJyZWFrZXIgaXMgZXhwbGFpbmVkLjwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFC MDY5NiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1 bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMyBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPlRoZXJlIGlzIHNvbWUgaGVhZC1lbmQgc3BlY2lmaWMgcmVjb21w dXRhdGlvbiBwcmlvcml0eSB0aGF0IGlzIHVzZWQgb25seSBmb3IgZHluYW1pYyBjYW5kaWRhdGUg cGF0aHMuLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVuIEknZCByZWNvbW1lbmQgZXhwbGljaXRs eSBjYWxsaW5nIHRoaXMgJnF1b3Q7cmVjb21wdXRhdGlvbi1wcmlvcml0eSZxdW90Oy48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPkl0IGlzIG5vdCBzcGVjaWZpYyB0byBkeW5hbWljIHBh dGhzIHNpbmNlIGV2ZW4gZXhwbGljaXQgcGF0aHMgbmVlZCB0byBiZSBldmFsdWF0ZWQgZm9yIHJl YWNoYWJpbGl0eS92YWxpZGl0eS4NCiBXZSB3aWxsIGFkZCB0ZXh0IHRvIGNsYXJpZnkgdGhpcyBp biBTZWMgMi4xMi48L3NwYW4+PC9pPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPigyLjMmIzQzOzIuMTImIzQzOzkuMykgVGhlcmUgYXJlIG1h bnkgc3Bhbm5lcnMgdGhyb3duIGludG8gdGhlIHdvcmtzIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVu dCBhcyB0byBob3cgdGhpbmdzIGFjdHVhbGx5IG9wZXJhdGUgd2l0aCBkaWZmZXJlbnQgcHJlZmVy ZW5jZXMuIEZvciBleGFtcGxlOg0KPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHVsIHR5 cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPklmIEkgaGF2ZSBtdWx0aXBsZSBjYW5kaWRhdGUgcGF0aHMgYWxsIHdpdGgg dGhlIHNhbWUgd2VpZ2h0IC0gSSB0aGluayB5b3Ugc2F5IHdlIHNob3VsZCBsb2FkLXNoYXJlIGFj cm9zcyB0aGUgd2VpZ2h0cy4gSXQgZG9lc24ndCBzZWVtIHRvIGJlIHN0YXRlZCB3aGVuIEkgc2hv dWxkIGZhaWxvdmVyIHRvIHRoZSBsb3dlciBwcmVmZXJlbmNlIHBhdGhzLjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PC91bD4NCjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xv cjojMUIwNjk2Ij5BcyBtZW50aW9uZWQgYWJvdmUsIHRoZXJlIGlzIG5vIGxvYWQtYmFsYW5jaW5n IGJldHdlZW4gY2FuZGlkYXRlIHBhdGhzIGJ1dCBpdCBpcyBiZXR3ZWVuIFNlZ21lbnQgTGlzdHMN CiB3aXRoaW4gYSBzcGVjaWZpYyBjYW5kaWRhdGUgcGF0aHMuPC9zcGFuPjwvaT48L2I+PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPk15IGFzc3VtcHRpb24gaXMgdGhhdCBJIGRvIG5vdCBjb21wYXJlIHByZWZlcmVu Y2UgYWNyb3NzIGRpZmZlcmVudCBwcm90b2NvbCBvcmlnaW5zIC0tIGkuZS4sIEkgcGljayB0aGUg cHJvdG9jb2wtb3JpZ2luIHRoYXQgaXMgYmVzdCwgYW5kIHRoZW4gc2VsZWN0IHdpdGhpbiBpdHMg Y2FuZGlkYXRlIHBhdGhzIC0gc3VjaCB0aGF0IGl0IGlzIG9ubHkgd2hlbiBBTEwgQkdQDQogKGZv ciBleGFtcGxlKSBwYXRocyBoYXZlIGZhaWxlZCwgdGhhdCBJIGdvIGFuZCBsb29rIGF0IG9uZXMg Y29uZmlndXJlZCBzdGF0aWNhbGx5LiBUaGlzIHdvdWxkIGJlIG15IHByZWZlcmVuY2UgLSBidXQg aXQgc2hvdWxkIGJlIGNsYXJpZmllZCBpbiB0aGUgZG9jLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PC91bD4NCjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2 Ij5QcmVmZXJlbmNlIGlzIGNvbXBhcmVkIGFjcm9zcyBvcmlnaW5zIGFuZCBoYXMgaGlnaGVyIHBy aW9yaXR5IHRoYW4gdGhlIHByb3RvY29sIG9yaWdpbi4gUGxlYXNlIHNlZQ0KIFNlYyAyLjkuPC9z cGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRoZSBiYWNrdXAgc2VtYW50aWNzIHRoYXQgYXJl IGluIHRoaXMgZG9jIGFyZSByZWFsbHkgcHJlZmVyZW5jZSBmYWlsb3ZlciBBRkFJQ1M/DQo8bzpw PjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBz dHlsZT0iY29sb3I6IzFCMDY5NiI+VGhpcyBpcyBqdXN0IHByZWZlcmVuY2UgZmFpbG92ZXIgYW5k IG5vdCBiYWNrdXAgaW4gdGhlIHNlbnNlIG9mIGZhc3QtcmVyb3V0ZS4gU2VjIDkuMyB0YWxrcyBh Ym91dA0KIHRoZSBiYWNrdXAgaW4gdGhlIGNvbnRleHQgb2YgZmFzdC1yZXJvdXRlLiBBcyBzdWNo IHRoZXkgYXJlIGluZGVwZW5kZW50Ljwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5 NiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij5UaGVyZSBpcyBtZW50aW9uIHRoYXQgJnF1b3Q7YW5vdGhlciAuLi4gY2FuZGlkYXRl IHBhdGggTUFZIGJlIGRlc2lnbmF0ZWQgYXMgYSBiYWNrdXAgZm9yIGEgc3BlY2lmaWMgb3IgYWxs IC4uLiBjYW5kaWRhdGUgcGF0aHMmcXVvdDsuIEhvdyBkb2VzIHRoaXMgd29yaz8gV2hlcmUgaXMg dGhpcyBzaWduYWxsZWQgdGhhdCBhIHBhcnRpY3VsYXIgcG9saWN5IGlzIGEgYmFja3VwIGZvciBh bm90aGVyPw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij5T aW5jZSB0aGlzIGlzIFNSIFBvbGljeSBhcmNoaXRlY3R1cmUsIGl0IGRvZXMgbm90IGNvdmVyIHRo ZSBzaWduYWxpbmcgYXNwZWN0cyDigJMgdGhvc2Ugc2hvdWxkIGJlIHdvcmtlZA0KIG91dCBpbiBz ZXBhcmF0ZSBkb2N1bWVudHMuIEkgYWdyZWUgdGhhdCBCR1AtU1JURSBmb3IgaW5zdGFuY2UsIGRv ZXMgbm90IGluY2x1ZGUgdGhpcyBpbmRpY2F0aW9uIG9mIGJhY2t1cCB5ZXQuIEhvd2V2ZXIsIHRo ZXJlIGlzIGFuIGludGVyZXN0IHRvIGFkZCB0aGlzLjwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFCMDY5NiI+PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkhvdyBkb2VzIHRoaXMgdGhlbiBpbnRlcmFj dCB3aXRoIHRoZSBwcmVmZXJlbmNlcyBhbmQgcHJvdG9jb2wgb3JpZ2luIHZhbHVlcz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIw Njk2Ij5UaGUgYmFja3VwIG5vdGlvbiBpbiBTZWMgOS4zIGlzIGluZGVwZW5kZW50IG9mIHRpZS1i cmVha2VyLiBUaGUgYmFja3VwIG1heSBiZSBwaWNrZWQgYXMgdGhlIG5leHQgYmVzdA0KIGNhbmRp ZGF0ZSBwYXRoIE9SIGEgY2FuZGlkYXRlIHBhdGggd2hpY2ggaGFzIGJlZW4gZXhwbGljaXRseSBz aWduYWxlZCBhcyBhIGJhY2t1cCBmb3IgdGhlIGJlc3QgY2FuZGlkYXRlIHBhdGggdGhhdCB3YXMg c2VsZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4oMi44KSAmcXVv dDtBIGNhbmRpZGF0ZSBwYXRoIGlzIHZhbGlkIGlmIGl0IGlzIHVzYWJsZSZxdW90OyAtLSB5b3Ug c2hvdWxkIGRlZmluZSB1c2FibGUgc29tZXdoZXJlLiBUaGlzIGlzIHRoZSBvbmx5IHVzZSBvZiB0 aGUgd29yZCAmcXVvdDt1c2FibGUmcXVvdDsgaW4gdGhlIGRvY3VtZW50LiBJZiBpdCBqdXN0IG1l YW5zIHRoYXQgaXQgaGFzIG1ldCBpdHMgdmFsaWRpdHkgY3JpdGVyaW9uIGFzIHNwZWNpZmllZA0K IGluIFNlY3Rpb24gNSwgdGhlbiB0aGlzIHNob3VsZCBqdXN0IGJlIHN0YXRlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUIwNjk2Ij5JdCBzaG91bGQgaGF2ZSBiZWVuIC0gQSBjYW5kaWRhdGUgcGF0aCBpcyB1c2FibGUg d2hlbiBpdCB2YWxpZC4gV2Ugd2lsbCBjb3JyZWN0IHRoaXMuPC9zcGFuPjwvaT48L2I+PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4oMi43JiM0Mzsy LjgmIzQzOzIuOSkgRm9yIGNsYXJpdHksIEkgd291bGQgY29sbGFwc2UgdGhlc2Ugc2VjdGlvbnMg aW50byBzb21ldGhpbmcgY29oZXJlbnQgLSBicmVha2luZyB0aGVtIHVwIG1ha2VzIHRoZSBkb2N1 bWVudCBsZXNzIHJlYWRhYmxlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPkVhY2ggb2YgdGhlbSBh cmUgaW5kZXBlbmRlbnQgdG9waWMgYW5kIGhlbmNlIGhhdmUgYmVlbiBrZXB0IHNlcGFyYXRlIGZv ciBjbGFyaXR5Ljwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+PG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+KDIuOCkgSXQgaXMgb25seSBSRUNPTU1FTkRFRCB0aGF0IGEg Y2FuZGlkYXRlIHBhdGggZm9yIGFuIFNSIHBvbGljeSBpcyBnaXZlbiBhIGRpZmZlcmVudCBwcmVm ZXJlbmNlLiBUaGVyZSBhcmUgdGhlbiB0aWVicmVha2VyIHJ1bGVzIHRoYXQgYXJlIG9ubHkgTUFZ Li4gUGxlYXNlIGV4cGxpY2l0bHkgc3BlY2lmeSB0aGlzIC0tIGl0J3MgZ29pbmcgdG8gYmUgYSBu aWdodG1hcmUNCiB0byBtYW5hZ2UgYSBtdWx0aS12ZW5kb3IgbmV0d29yayBhbmQgdGVzdCB0aGlz IGlmIHRoZXJlIGFyZSBvcHRpb25hbCB3YXlzIHRvIHRpZS1icmVhaywgZXNwZWNpYWxseSBhcyB0 aGUgbnVtYmVyIG9mIHByZWZlcmVuY2VzL3ByaW9yaXRpZXMgZXQgYWwuIG1lYW5zIHRoZSBudW1i ZXIgY29tYmluYXRpb25zIGlzIGxhcmdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPldpbGwgdXBkYXRlIHRo ZSB0ZXh0IGJhc2VkIG9uIHlvdXIgYW5kIGNvLWF1dGhvcuKAmXMgc3VnZ2VzdGlvbnMuPC9zcGFu PjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij4oMi4xMSkgVGhpcyBzcGVjaWZpY2F0aW9uIG9mIFdFQ01QIHNlZW1zIGxpa2UgaXQgc2F5 cyB0aGUgc2FtZSB0aGluZyB0aGF0IGlzIGluIDIuMiAtLSBjYW4geW91IGNvbnNpZGVyIG1ha2lu ZyB0aGVzZSBjb2hlcmVudGx5IHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQ/PG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5 NiI+U2VjIDIuMTEgdGFsa3MgYWJvdXQgaW5zdGFudGlhdGlvbiBvZiBwb2xpY3kgaW4gdGhlIGZv cndhcmRpbmcgcGxhbmUgYW5kIGRpc2N1c3NlcyBXRUNNUCBpbiB0aGF0IGNvbnRleHQuDQogV2hp bGUgU2VjIDIuMiBicmluZ3MgaW4gd2VpZ2h0IG9ubHkgdG8gZGVzY3JpYmUgdGhlIGFzc29jaWF0 aW9uIGFuZCBpbnRlbnRpb24gZm9yIGhhdmluZyBtdWx0aXBsZSBTZWdtZW50LUxpc3RzIHdpdGhp biBhIGNhbmRpZGF0ZSBwYXRoLjwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+ PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+KDMpIFdoYXQgaXMgdGhlIHJlYXNvbiB0byBk ZWZpbmUgYW4gU1ItREIgaGVyZT8gSXQgc2VlbXMgbGlrZSB0aGVyZSBpcyBsaXR0bGUgcmVmZXJl bmNlIHRvIHRoaXMgZWxzZXdoZXJlLCBhbmQgaXQgcmVwbGljYXRlcyBpbmZvcm1hdGlvbiBmcm9t IG90aGVyIHBsYWNlcyAtIGUuZy4sIEJHUCBSSUIsIE1QTFMgbGFiZWwgdGFibGVzLCBhbmQgSUdQ LVRFIGRhdGFiYXNlLg0KIERvIHlvdSBpbnRlbmQgdGhhdCBpbXBsZW1lbnRvcnMgY3JlYXRlIHNv bWUgbmV3IGxvb2t1cCBvZiB0aGlzIGluZm9ybWF0aW9uLCBvciBpcyB0aGlzIGNvbmNlcHR1YWw/ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUIwNjk2Ij5UaGlzIHNlY3Rpb24gaXMgY29uY2VwdHVhbCBhbmQgdGhpcyBp cyBoaWdobGlnaHRlZCB3aXRoIHRoZSB1c2FnZSBvZiBtdWx0aXBsZSBNQVkga2V5d29yZHMuIEl0 IGhlbHBzDQogdGhlIHJlYWRlciB0byB1bmRlcnN0YW5kIGFsbCB0aGUgcGllY2VzIG9mIGluZm9y bWF0aW9uIHRoYXQgaGVscCBpbiBjb21wdXRhdGlvbiBvciB2YWxpZGF0aW9uIG9mIFNSIFBvbGlj eS4gV2Ugd2lsbCBhZGQgdGV4dCB0byBjbGFyaWZ5IHRoaXMuPC9zcGFuPjwvaT48L2I+PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPlRoaXMgY29uY2VwdCBpcyBvbmx5IGRlZmluZWQgaGVyZSBpbiB0aGUgZG9jdW1l bnQgLS0gaXNuJ3QgaXQganVzdCBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgdGhhdCBkb2VzIG5v dCBuZWVkIHRvIGJlDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+c3RhbmRhcmRpemVkPC9z cGFuPj88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48 aT48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+VGhpcyBjb25jZXB0IGlzIG5lY2Vzc2FyeSB0 byBjbGFyaWZ5IHRvIGltcGxlbWVudGVycyBvbiB0aGUgbXVsdGlwbGUgcGllY2VzIG9mIGluZm9y bWF0aW9uIHRoYXQg4oCcTUFZ4oCdDQogYmUgcmVxdWlyZWQgZm9yIFNSIFBvbGljeSBjb21wdXRh dGlvbiBvciB2YWxpZGF0aW9uLjwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+ PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBl PSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZv MSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5XaHkgc2hv dWxkIHdlIHJlcGxpY2F0ZSB0aGUgSUdQIGNvbnRlbnRzIGluIHRoaXMgU1JEQj88bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0i Y29sb3I6IzFCMDY5NiI+VGhlcmUgaXMgbm8gcmVwbGljYXRpb24gcmVxdWlyZW1lbnQgbWVudGlv bmVkLiBUaGF0IGlzIGxlZnQgdG8gdGhlIGltcGxlbWVudGF0aW9uIGFzIHRoaXMgaXMgY29uY2Vw dHVhbC48L3NwYW4+PC9pPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+WW91IGFyZSByZWNvbW1lbmRpbmcg aGVyZSB0aGF0IGluZm9ybWF0aW9uIHN1Y2ggYXMgdG9wb2xvZ3kgaXMgbGVhcm50IGZyb20gb3Ro ZXIgZG9tYWlucyAtIHdoeSBpcyB0aGlzIGEgcmVxdWlyZW1lbnQgZm9yIFNSLVRFIHBvbGljeT8g SXQgY2VydGFpbmx5IGRvZXNuJ3Qgc2VlbSBsaWtlIGEgYmFzZSByZXF1aXJlbWVudC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUIwNjk2Ij5JdCBpcyBhIE1BWS4gQ2VydGFpbmx5IG5vdCBhIOKAnGJhc2Xi gJ0gcmVxdWlyZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UbyBiZSBj bGVhciwgSSB3b3VsZCByZWNvbW1lbmQgcmVtb3ZpbmcgdGhpcyBlbnRpcmUgc2VjdGlvbiBmcm9t IHRoZSBkb2N1bWVudC48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+PG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFCMDY5NiI+SU1ITyBpdCBpcyBpbXBvcnRhbnQgY29uY2VwdHVhbCBpbmZvcm1h dGlvbiBmb3IgaW1wbGVtZW50ZXJzIGFuZCBoZW5jZSByZWxldmFudCBpbiB0aGlzIGRvY3VtZW50 Ljwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+PG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4oNS4yKSBJIGZpbmQgdGhpcyB3aG9sZSBzZWN0aW9u IHVuZGVyLXNwZWNpZmllZCBhZ2Fpbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPlRoZXJlIHdhcyBzcGVj aWZpY2F0aW9uIGZvciB0aGlzIGluIHRoZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQg d2hpY2ggd2FzIG1vdmVkIHRvIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lk ZXJhdGlvbnMNCiAocGxlYXNlIHNlZSBTZWMgMy4xIHRoZXJlKSB1cG9uIHlvdXIgcmVxdWVzdC4g Q3VycmVudGx5IHdlIGhhdmUgcHV0IGEgY3Jvc3MtcmVmZXJlbmNlIHRvIHRoYXQgZHJhZnQuPC9z cGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGUg UENFIGRyYWZ0IHJlZmVyZW5jZWQgZG9lcyBub3Qgc2VlbSB0byB0ZWxsIG1lIGhvdyB0byBzcGVj aWZ5IGFuIG9wdGltaXNhdGlvbiBvYmplY3RpdmUsIGFuZCB0aGVyZSBkb2Vzbid0IHNlZW0gdG8g YmUgYW55IGV4cGxhbmF0aW9uIG9mIHdoZXJlIG9yIGhvdyB0aGlzIHdvdWxkIGJlIHNwZWNpZmll ZCBhdCBhIGhlYWQtZW5kIGluIGNvbmZpZ3VyYXRpb24uIEkgd291bGQNCiByZWNvbW1lbmQgcmVt b3ZpbmcgdGhpcyBmcm9tIHRoaXMgZG9jdW1lbnQgYXMgaXQgc2VlbXMgdG8gYmUgZWl0aGVyOiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xv cjojMUIwNjk2Ij5UaGUgUENFUCBkcmFmdCByZWZlcmVuY2VkIGRlc2NyaWJlcyB0aGUgcHJvdG9j b2wgZXh0ZW5zaW9ucyBmb3IgU1IsIHdoaWNoIGFyZSB1c2VkIGZvciBTUiBQb2xpY3kuDQogSXQg ZG9lcyBub3QgZGVzY3JpYmUgdGhlIHZhcmlvdXMgb3B0aW1pemF0aW9uIG1ldHJpY3MgYXZhaWxh YmxlIGluIFBDRVAgc2lnbmFsaW5nIGUuZy4gUkZDNTQ0MCBhbmQgUkZDODIzMy48L3NwYW4+PC9p PjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+SW1wbGVtZW50YXRpb24gc3BlY2lmaWMgLS0gaWYgaXQncyBp biBjb25maWd1cmF0aW9uLiBUaGUgb25seSBkaWZmZXJlbmNlIG1pZ2h0IGJlIGlmIG9uZSB3ZXJl IHRvIHdhbnQgdG8gc3BlY2lmeSBhIFlBTkcgbW9kZWwgdGhhdCBzcGVjaWZpY2FsbHkgZGlzY3Vz c2VzIGhvdyB0byBzcGVjaWZ5IHN1Y2ggb2JqZWN0aXZlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5 NiI+VGhlIGFyY2hpdGVjdHVyZSBkcmFmdCBpcyBpbnRyb2R1Y2luZyB0aGUga2V5IGNvbmNlcHRz IGFuZCBzdHJ1Y3R1cmUuIFRoZSBZYW5nIG1vZGVsIGl0c2VsZiBpcyBjb3ZlcmVkDQogYnkgYSBz ZXBhcmF0ZSBkb2N1bWVudC4gVGhpcyBzcGVjaWZpYyBhc3BlY3Qgd2lsbCBiZSBjb3ZlcmVkIGlu IGEgZnV0dXJlIHZlcnNpb24gb2YgZHJhZnQtdGhvbWFzLXNwcmluZy1zci1wb2xpY3kteWFuZy48 L3NwYW4+PC9pPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+QSBmZXcgeWVhcnMgYWdvLCB3ZSBkaXNjdXNz ZWQgdGhpcyB3aG9sZSBwcm9ibGVtIHNwYWNlLCBhbmQgdGhlIGNvbmNsdXNpb24gc2VlbWVkIHRv IGJlIHRoYXQgaGF2aW5nIHN1Y2ggb2JqZWN0aXZlcyBzcGVjaWZpZWQgb24gdGhlIGhlYWQtZW5k IHdvdWxkIGVuZCB1cCB3aXRoIHNpZ25pZmljYW50IGNvZGUgY2h1cm4gLSBoYXZpbmcgYW4gb3Bh cXVlIGlkZW50aWZpZXINCiB0aGF0IGNvdWxkIGJlIGhhbmRlZCB0byB0aGUgUENFIHNlZW1lZCBt b3JlIGxvZ2ljYWwuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPkkgYmVsaWV2ZSB5b3UgcmVmZXIg dG8gdGhlIG5vdGlvbiBvZiBwcm9maWxlLUlEIGluIFBDRVAgZm9yIHNwZWNpZnlpbmcgdHJhZmZp YyBzdGVlcmluZyBhbmQgb3RoZXINCiBmZWF0dXJlcy4gVGhhdCBjb25jZXB0IGlzIHN0aWxsIGFw cGxpY2FibGUgdG8gU1IgcG9saWN5LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9zcGFuPjwv cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+KDYpIFBsZWFzZSBjYW4gd2Ugc3RvcCB3cml0aW5nIElFVEYgZG9jdW1lbnRzIGxpa2UgdGhl eSBhcmUgbWFya2V0aW5nIGEgdGVjaG5vbG9neSAtICZxdW90O1ggaXMgZnVuZGFtZW50YWwgdG8g U2VnbWVudCBSb3V0aW5nJnF1b3Q7IGlzIG5vdCBhIHVzZWZ1bCBzdGF0ZW1lbnQuIFBsZWFzZSBv YmplY3RpdmVseSBzdGF0ZSB0aGUgdGVjaG5pY2FsIGJlbmVmaXQuIEVpdGhlciB3YXksIHRoaXMN CiBzZWVtcyBsaWtlIHRoaXMgc2VjdGlvbiBjYW4gYmUgcmVtb3ZlZC48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5XZSBiZWxpZXZlIHRoaXMgaXMgYSB0ZWNobmljYWwgcG9pbnQgYW5kIHRoZSByZWFzb25zIGFy ZSBleHBsYWluZWQgaW4gdGhlIG5leHQgc2VudGVuY2Ug4oCTIOKAnGl0IHByb3ZpZGVzDQogc2Nh bGluZywgbmV0d29yayBvcGFjaXR5IGFuZCBzZXJ2aWNlIGluZGVwZW5kZW5jZeKAnS48L3NwYW4+ PC9pPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5JZiB5b3UgdGhpbmsgb3RoZXJ3aXNlLCBwbGVhc2UgbGV0IHVzIGtu b3cuPC9zcGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4oNi4yKSBQbGVhc2UgbWFrZSBpdCBhIE1VU1QgdGhhdCBhbiBhbGVydCBv ZiBzb21lIGZvcm0gaXMgZ2VuZXJhdGVkIHdoZW4gdGhlIEJTSUQgaXMgbm90IGF2YWlsYWJsZS4g T3RoZXJ3aXNlIGl0IGlzIGVudGlyZWx5IG9wYXF1ZSB0byBhbiBvcGVyYXRvciB0aGF0IHRoaXMg d2Fzbid0IGFjY2VwdGVkIGFuZCB0aGF0IHRoZWlyIHBvbGljeSBpcyBub3QgaW4gdXNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PGk+PHNwYW4gc3R5bGU9ImNv bG9yOiMxQjA2OTYiPkFncmVlZC4gV2Ugd2lsbCB1cGRhdGUgdGhpcyBpbiB0aGUgdGV4dC48L3Nw YW4+PC9pPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4oNi4yKSBJbiB0aGUgY2FzZSBvZiBCU0lEIHN0aWNr aW5lc3MsIGlmIENhbmRpZGF0ZVBhdGgxIHNwZWNpZmllcyBsYWJlbCA0MiAoYXNzdW1lZCB0byBi ZSBpbiBTUkxCKSwgYW5kIGlzIG1vcmUgcHJlZmVyYWJsZSB0aGFuIENhbmRpZGF0ZVBhdGgyJm5i c3A7dGhlbiBBSVVJLCB3ZSdsbCBpbnN0YWxsIHRoaXMgcG9saWN5IGFuZCB1c2UgbGFiZWwgNDIu IElmIHdlIGFzc3VtZSB0aGF0DQogdGhlcmUncyBzb21lIHNlY29uZCBDYW5kaWRhdGVQYXRoMiwg d2hpY2ggZG9lcyBub3Qgc3BlY2lmeSBhIEJTSUQuIElmIENhbmRpZGF0ZVBhdGgxJm5ic3A7aXMg c3Vic2VxdWVudGx5IHdpdGhkcmF3biwgZXZlbiB0aG91Z2ggQ2FuZGlkYXRlUGF0aDImbmJzcDtk b2Vzbid0IHNwZWNpZnkgYSBCU0lELCBsYWJlbCA0MiB3aWxsIGJlIHJldGFpbmVkLiBJZiBDUDEg aXMgbm93IHJlLWFkdmVydGlzZWQsIHdoYXQgaGFwcGVucyAtIGlzIHRoaXMgQlNJRCBjb25zaWRl cmVkDQogJnF1b3Q7dXNlZCZxdW90OyBldmVuIHRob3VnaCBpdCdzIGVzc2VudGlhbGx5IG5vdyBh IGR5bmFtaWMgYWxsb2NhdGlvbiB3aXRoaW4gdGhlIFNSTEI/Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5 NiI+Q1AxIHdpbGwgYmUgcHJlZmVycmVkIGFuZCBzaW5jZSA0MiB3YXMgc3BlY2lmaWVkIEJTSUQg Zm9yIGl0LCBpdCB3aWxsIHVzZSB0aGUgc2FtZSBCU0lELjwvc3Bhbj48L2k+PC9iPjwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzFCMDY5NiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+KDYuNCkgU3BlY2lm eWluZyBiaW5kaW5nIFNJRHMgY2FuIGJlIGFzc2lnbmVkIHRvIGFueSBlbGVtZW50IGRvZXNuJ3Qg c2VlbSB0byBoYXZlIGFueSByZWFsIGJlbmVmaXQgb2YgYmVpbmcgaW4gdGhpcyBkcmFmdC4gSWYg dGhlcmUgYXJlIG5ldyBCU0lEIGJpbmRpbmdzIHRoYXQgYWN0dWFsbHkgcmVxdWlyZSBzdGFuZGFy ZGlzYXRpb24gLSB0aGVuIEkgd291bGQgaGlnaGx5DQogcmVjb21tZW5kIHB1dHRpbmcgaW4gdGhl aXIgb3duIGRyYWZ0LiB0aGVyZSBhcmUgbWFueSBxdWVzdGlvbnMgdGhhdCBjb21lIGZyb20gdGhp cyBzaG9ydCBwYXJhZ3JhcGguIEZvciBleGFtcGxlLCBob3cgYXJlIHRob3NlIGJpbmRpbmcgU0lE cyBjb25zaWRlcmVkIHZhbGlkPyBJcyB0aGVyZSBPQU0gaW50ZXJ3b3JraW5nIHRoYXQgaXMgbmVl ZGVkIHdpdGggb3RoZXIgbmV0d29ya3MgZm9yIGxpdmVsaW5lc3MgZGV0ZWN0aW9uIGV0Yy4gV2Ug ZXhwbGljaXRseQ0KIHJlbW92ZWQgYSBsb3Qgb2YgdGhlIEJTSUQtJmd0O1JTVlAgaW5jbHVkaW5n IEVSTyBhZHZlcnRpc2VtZW50IGluIGVhcmxpZXIgcmV2aXNpb25zIG9mIFNSIHJlbGF0ZWQgSUdQ IGRyYWZ0cy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij5UaGlzIGlzIGFuIGltcG9ydGFudCBjb25jZXB0IGZv ciB0aGUgQlNJRCBhcyBpdCByZWxhdGVzIHRvIFNSIFBvbGljeSBhbmQgbmVlZHMgdG8gYmUgY292 ZXJlZCBpbiB0aGlzDQogYXJjaGl0ZWN0dXJlIGRyYWZ0LiBBIFBvbGljeSBjYW4gYmUgYW4gaW5z dHJ1Y3Rpb24gdG8gc3RlZXIgb3ZlciBhIHNwZWNpZmljIGludGVyZmFjZS4gVGhlIHJlbGV2YW50 IGV4YW1wbGVzIHdlcmUgZXhwbGFpbmVkIGluIGEgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGlzIGRy YWZ0IGJ1dCB3ZXJlIG1vdmVkIGludG8gZHJhZnQtZmlsc2ZpbHMtc3ItcG9saWN5LWNvbnNpZGVy YXRpb25zIGJhc2VkIG9uIHlvdXIgaW5wdXQuIEluIGZhY3QsIHRoZSBkZXRhaWxzDQogZm9yIHRo ZSBvcHRpY2FsIFNSIHBhdGggdXNlLWNhc2UgZGVzY3JpYmVkIGluIGRyYWZ0LWFuYW5kLXNwcmlu Zy1wb2ktc3IgYnVpbGRzIG9uIHRvcCBvZiB0aGlzIGNvbnN0cnVjdC48L3NwYW4+PC9pPjwvYj48 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPig3KSBUaGUgU1ItVEUgUG9saWN5IFN0YXRlIGlz IGRlZmluZWQgaGVyZSB0byBjb250YWluIHRoZSByZWFzb24gdGhhdCBhIHBvbGljeSBvciBjYW5k aWRhdGUgcGF0aCBpcyBub3QgdmFsaWQsIGhvd2V2ZXIsIHRoZSBlbmNvZGluZ3MgaW4gaWV0Zi1p ZHItdGUtbHNwLWRpc3RyaWJ1dGlvbiBkb24ndCBzZWVtIHRvIHNheSBob3cgdGhpcyBzaG91bGQg YmUgZW5jb2RlZC4NCiBJcyB0aGlzIHRoZSByaWdodCByZWZlcmVuY2U/IElzIHRoZXJlIGV4dGVu c2lvbiB0byB0aGF0IHdvcmsgd2hpY2ggaXMgcmVxdWlyZWQ/PG86cD48L286cD48L3NwYW4+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+WW91 ciBvYnNlcnZhdGlvbnMgYXJlIGNvcnJlY3QuIFRoaXMgd2FzIGludHJvZHVjZWQgaW4gZHJhZnQt aWV0Zi1pZHItdGUtbHNwLWRpc3RyaWJ1dGlvbi0wOS4gU2luY2UNCiB0aGlzIGlzIHRoZSBhcmNo aXRlY3R1cmUgZG9jdW1lbnQsIHRoaW5ncyBhcmUgbGlrZWx5IHRvIGNvbWUgaGVyZSBmaXJzdCBi ZWZvcmUgd2Ugd29yayBvbiBuZWNlc3NhcnkgZXh0ZW5zaW9ucyBpbiB0aGUgcHJvdG9jb2xzLjwv c3Bhbj48L2k+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFCMDY5NiI+PG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+KDguMSAmIzQzOyA4LjIpIFRoZSBkb2N1bWVudCBhcHBlYXJzIHRvIGhhdmUgbXVs dGlwbGUgZGlmZmVyZW50IHBsYWNlcyB3aGVyZSBpdCBkaXNjdXNzZXMgdmFsaWRpdHkuIElzIHRo ZXJlIGEgcmVhc29uIHRoYXQgdGhpcyBjYW4ndCBiZSBjb3ZlcmVkIGluIDIuMTAgb3IgMi4xMT8g VGhpcyB3b3VsZCBiZSBhIG1vcmUgbmF0dXJhbCBwbGFjZSBmb3IgdGhlIGRlZmluaXRpb24NCiBv ZiAmcXVvdDtkcm9wIG9uIGludmFsaWQmcXVvdDsgdG9vLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYi PldlIGhhdmUgcHV0IGEgcmVmZXJlbmNlIHRvIHRoZSBzZWN0aW9ucyAyLjEwIGFuZCA1IHdoaWNo IGRlc2NyaWJlIHRoZSB2YWxpZGl0eSBvZiBTUiBQb2xpY3kgaW4gdGhlDQogdGV4dCBvZiBzZWN0 aW9uIDguMS4gVGhlIOKAnGRyb3Agb24gaW52YWxpZOKAnSBpcyBhIHN0ZWVyaW5nIGFuZCBmb3J3 YXJkaW5nIHBsYW5lIG5vdGlvbiBhbmQgaGVuY2UgbW9yZSBhcHByb3ByaWF0ZSB1bmRlciBTZWN0 aW9uIDguPC9zcGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij4oOC4yKSBEcm9wIG9uIGludmFsaWQgYXBwZWFycyB1bmRlcnNwZWNp ZmllZCB0byBtZSBoZXJlIC0tIHNob3VsZCBpdCBiZSBtYWludGFpbmVkIHdoZW4gdGhlcmUgd2Fz IGFuIGFjdGl2ZSBCU0lEIGJ1dCBhbGwgcmVtb3RlIHdheXMgb2YgYWR2ZXJ0aXNpbmcgaXQgd2Vu dCBhd2F5LCBvciBvbmx5IHdoZW4gYWxsIHBhdGhzIGluIHRoZWlyIGVudGlyZXR5IGFyZSBpbnZh bGlkPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxQjA2OTYiPlRoaXMgaXMgd2hlbiBhbGwgdGhlIGNhbmRpZGF0ZSBwYXRo cyBvZiB0aGUgU1IgUG9saWN5IGFyZSBpbnZhbGlkIGFuZCBoZW5jZSB0aGUgcG9saWN5IGlzIGlu dmFsaWQuPC9zcGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SWYgdGhlIHBv bGljeSBkaWQgbm90IHNwZWNpZnkgYSBCU0lEIC0gaS5lLiwgaXQgd2FzIGR5bmFtaWNhbGx5IGFs bG9jYXRlZCwgc2hvdWxkIHRoaXMgYmUgZnJlZWQ/DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxQjA2OTYiPkFzIGlzIG1lbnRpb25lZCBpbiBzZWMgOC4yLCBmb3IgZHJv cC1vbi1pbnZhbGlkIFNSIFBvbGljaWVzLCB0aGUgQlNJRCBpcyByZXF1aXJlZCBhbmQgcmV0YWlu ZWQgaW4NCiB0aGUgZm9yd2FyZGluZyBidXQgd2l0aCBhbiBhY3Rpb24gdG8gZHJvcCB0aGUgdHJh ZmZpYyBtYXRjaGluZyBpdC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPg0KPC9z cGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+V2hhdCBpcyB0aGUgYmVoYXZpb3VyIHdoZW4gd2UgaGF2ZSBJUDJNUExT IGVudHJpZXMgdGhhdCByZWx5IG9uIHRoYXQgcG9saWN5IC0tIHRoZXkgc2hvdWxkIG5ldmVyIGZh bGwgYmFjayB0byBvdGhlciBtZWNoYW5pc21zIG9mIHJvdXRpbmcgdGhlIHRyYWZmaWMgdmlhIGFu IGFsdGVybmF0ZSBNUExTIHR1bm5lbCwgb3IgYWx0ZXJuYXRlIElQIGZvcndhcmRpbmcgZW50cnk/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzFCMDY5NiI+U2luY2UgaXQgaXMgbWFya2VkIGFzIGRyb3Atb24taW52YWxpZCwgdGhlbiB0 aGUgdHJhZmZpYyBtYXRjaGluZyB0aGUgaXAybXBscyBlbnRyaWVzIGFuZCBnZXR0aW5nIHN0ZWVy aW5nDQogaW50byB0aGlzIHBvbGljeSB3b3VsZCBhbHNvIGdldCBkcm9wcGVkLiBUaGUg4oCcbm9y bWFs4oCdIGRlZmF1bHQgYmVoYXZpb3IgZm9yIFNSIFBvbGljeSB3b3VsZCBiZSB0aGF0IG9uIGJl Y29taW5nIGludmFsaWQsIGl0IHdvdWxkIGJlIHRha2VuIG91dCBhbmQgd2Ugd291bGQgZmFsbGJh Y2sgdG8gb3RoZXIgYWx0ZXJuYXRlcyBvciB0aGUgSVAgZm9yd2FyZGluZy4gU28gZHJvcC11cG9u LWludmFsaWQgaXMgcmVhbGx5IGEgc3BlY2lhbCBiZWhhdmlvci48L3NwYW4+PC9pPjwvYj48L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxQjA2OTYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPig5LjIpIEl0 J3MgdmVyeSB1bmNsZWFyIHRvIG1lIGhvdyBvbmUgYWN0dWFsbHkgcHJvdmlzaW9ucyB0aGlzIGxp bmsgcHJvdGVjdGluZyBwb2xpY3kuIFlvdSBoYXZlICZsdDtjb2xvdXIsIGVuZHBvaW50Jmd0OyBh cyB0aGUgdW5pcXVlIHR1cGxlIC0tIHdoYXQgaXMgdGhlIHBvbGljeSB0aGF0IG9uZSBpbnN0YWxs cyB1c2luZyB0aGUgZnJhbWV3b3JrIHRoYXQgaXMgZGVmaW5lZCBpbg0KIHRoaXMgZG9jdW1lbnQg dG8gZGVmaW5lIGFuIFNSLVRFIHBvbGljeSBmb3IgbGluayBwcm90ZWN0aW9uPyBXaGF0J3MgdGhl IG1hdGNoIGNyaXRlcmlhIGZvciBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij5UaGUgU1IgUG9saWN5IGlz IGxvY2FsbHkgY29uZmlndXJlZCBhcyBhIGJhY2t1cCBwYXRoIGZvciBwcm90ZWN0aW5nIHRoZSBz cGVjaWZpYyBsaW5rLiBXZSBoYXZlIGFkZGVkDQogdGV4dCB0byBtZW50aW9uIHRoaXMuPC9zcGFu PjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij4oOS4zKSBUaGlzIGhhcyBhIHNpbWlsYXIgcHJvYmxlbSBhcyB0aGUgcG9pbnQgcmFpc2Vk IGFib3ZlIGFib3V0IGhvdyBvbmUgc3BlY2lmaWVzIHRoYXQgYSBwb2xpY3kgaXMgYSBiYWNrdXAg Zm9yIGFub3RoZXIgcG9saWN5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxQjA2OTYiPk5vdGUgdGhhdCA5LjMgaXMgYWJv dXQgc3BlY2lmeWluZyBvbmUgQ1AgYXMgYmFja3VwIGZvciBhbm90aGVyIHdpdGhpbiB0aGUgc2Ft ZSBTUiBQb2xpY3kgYW5kIHNvIGl0DQogaXMgZGlmZmVyZW50IGZyb20gOS4yLiBUaGUgYmFja3Vw IGlzIHByb3Zpc2lvbmVkIGFuZCB3ZSBoYXZlIGFkZGVkIHNvbWUgdGV4dCB0byBjbGFyaWZ5IHRo aXMuIFRoaXMgaXMgbm90IHlldCBzb21ldGhpbmcgY292ZXJlZCBpbiB0aGUgc2lnbmFsaW5nIG9y IHRoZSBZYW5nIG1vZGVsIOKAkyBidXQgc29tZXRoaW5nIHRoYXQgaXMgbmVjZXNzYXJ5IGZvciBh Y2hpZXZpbmcgZmFzdC1yZXJvdXRlIHdpdGggcGF0aCBwcm90ZWN0aW9uIGZvciBTUiBQb2xpY3kN CiBDYW5kaWRhdGUgcGF0aHMuPC9zcGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUIwNjk2Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRoYW5rcyBmb3Ig eW91ciByZXZpZXcgb2YgdGhlc2UgaXNzdWVzLiBIYXBweSB0byBkaXNjdXNzIHRoZW0gb24gdGhl IGxpc3QgZnVydGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9ba2813b9f9b4800baf4ba8255242d6bXCHALN011ciscocom_-- From nobody Thu Oct 18 19:09:49 2018 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 B437C130E2F for ; Thu, 18 Oct 2018 19:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.563 X-Spam-Level: X-Spam-Status: No, score=-14.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZinQZ5VRenwA for ; Thu, 18 Oct 2018 19:09:44 -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 8F41C130E46 for ; Thu, 18 Oct 2018 19:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38802; q=dns/txt; s=iport; t=1539914982; x=1541124582; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SkfeqZmBXtG3OHWC47czkd0QYYzEvi2CSzYSCuZ5uRI=; b=FVyxvv7MYzxyDSOLiMbDwMnKloQYBmx5Q46a7Ltz4yhG9aoOrCSaMxOF UfuuoIjvZl5zc5Dyjc6tqASFNyFVtUxV4mW6P8G0GZgYzBdt6Rycox7NH 84WC4Mb+I3BEhjWNBlOQRc9Dgbfm23izEhomIo1FNliSax2QF3T0TXjBM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADCO8lb/5ldJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDXdmfygKg2tihzWMGoINlw+BegsBAYRsAhe?= =?us-ascii?q?EbCE0DQ0BAwEBAgEBAm0ohTkBAQEBAyMKXAIBCBEBAwEBIQoCAgIwFwYIAgQ?= =?us-ascii?q?BEggTgwaBHWSnLoEuiiiLTReBQT+BEAGDEoUkgl2CVwKIV4VWjzkFTgkCkF0?= =?us-ascii?q?fgU+EcolniSCMfwIRFIEmHTiBVXAVO4JsgiYXjhlvijOBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,398,1534809600"; d="scan'208,217";a="468416584" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 02:09:40 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w9J29e9A014966 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2018 02:09:40 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Oct 2018 21:09:40 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Thu, 18 Oct 2018 21:09:40 -0500 From: "Ketan Talaulikar (ketant)" To: Rob Shakir , SPRING WG List , "draft-filsfils-spring-sr-policy-considerations@tools.ietf.org" Thread-Topic: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01 Thread-Index: AQHUJC8gIgkUpf/WTkeLttnG75TNTqUmVw4Q Date: Fri, 19 Oct 2018 02:09:39 +0000 Message-ID: <3470b63ec7264ac096e326a59d97b50f@XCH-ALN-008.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.65.42.234] Content-Type: multipart/alternative; boundary="_000_3470b63ec7264ac096e326a59d97b50fXCHALN008ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 02:09:48 -0000 --_000_3470b63ec7264ac096e326a59d97b50fXCHALN008ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4gUGxlYXNlIGZp bmQgaW5saW5lIGJlbG93IG91ciByZXNwb25zZXMuDQoNCldpbGwgd29yayBvbiBwb3N0aW5nIGFu IHVwZGF0ZSB0byB0aGUgZHJhZnQgdG8gaW5jb3Jwb3JhdGUgeW91ciBjb21tZW50cy4NCg0KVGhh bmtzLA0KS2V0YW4NCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFJvYiBTaGFraXINClNlbnQ6IDI1IEp1bHkgMjAxOCAyMToxOQ0KVG86IFNQUklO RyBXRyBMaXN0IDxzcHJpbmdAaWV0Zi5vcmc+OyBkcmFmdC1maWxzZmlscy1zcHJpbmctc3ItcG9s aWN5LWNvbnNpZGVyYXRpb25zQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBbc3ByaW5nXSBDb21t ZW50cyBvbiBkcmFmdC1maWxzZmlscy1zcHJpbmctc3ItcG9saWN5LWNvbnNpZGVyYXRpb25zLTAx DQoNCihBcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKQ0KDQpIaSBBdXRob3JzLA0KDQpQZXIg bXkgY29tbWVudHMgaW4gU1BSSU5HIGF0IElFVEYgMTAyLCBJIGhhdmUgYSBudW1iZXIgb2YgY29t bWVudHMvY29uY2VybnMgYWJvdXQgdGhlIGNvbnRlbnRzIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFz ZSBmaW5kIHRoZW0gYmVsb3cuIEkgbG9vayBmb3J3YXJkIHRvIGRpc2N1c3NpbmcgdGhlbSBpbiBt b3JlIGRldGFpbC4uDQoNCiAgKiAgICgyKSBXaGF0IGlzIHRoZSBpbnRlbnRpb24gb2YgdGhlIGRp YWdyYW0gc2hvd24gaW4gdGhpcyBzZWN0aW9uPyBJdCBzZWVtcyB0byBiZSBjb21wbGV0ZWx5IGFu IGltcGxlbWVudGF0aW9uIGRldGFpbCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGhhcyB0aGUgIlNS UE0iIHRoYXQgYWN0cyBhcyBhIGNlbnRyYWwgcmVzb2x1dGlvbiBwb2ludC4gRm9yIGluc3RhbmNl LCB3aGF0IHNob3VsZCBhIHJlYWRlciBsZWFybiBmcm9tIHRoZSBmYWN0IHRoYXQgdGhlIFNSUE0g aXMgbm90IGEgc3RhbmRhcmQgUklCIHJlc29sdXRpb24gcHJvY2Vzcz8gSWYgdGhlcmUgYXJlIHN1 Z2dlc3Rpb25zIHRoYXQgb25lIHdhbnRzIHRoaXMgaW1wbGVtZW50YXRpb24gLSBzaG91bGQgdGhl cmUgYmUgc29tZSBkaXNjdXNzaW9uIG9mIHRoZSBjb21wbGV4aXR5IG9mIHRoaXMgbmV3IEFQSSBi ZXR3ZWVuIHNheSwgdGhlIEJHUCBkYWVtb24gYW5kIGEgZ2VuZXJhbCBSSUIgcHJvY2Vzcz8NCltL VF0gV2Ugd2lsbCBjbGFyaWZ5IGluIHRoZSB0ZXh0IHRoYXQgdGhlIHNlY3Rpb24gcHJvdmlkZXMg YSBjb25jZXB0dWFsIG92ZXJ2aWV3IG9mIGNvbXBvbmVudHMvZnVuY3Rpb25hbGl0eSB0aGF0IHdv cmsgd2l0aCBlYWNoIG90aGVyIHRvIGltcGxlbWVudCBTUiBQb2xpY3kgb24gYSBoZWFkZW5kLiBU aGUgaW50ZW50aW9uIGlzIG5vdCB0byBkZWZpbmUgQVBJcyBiZXR3ZWVuIHRoZSBibG9ja3Mgc2lu Y2UgdGhvc2UgYXJlIGltcGxlbWVudGF0aW9uIGRldGFpbHMuIFdlIGhhdmUgc2V2ZXJhbCBkcmFm dHMgcmVsYXRlZCB0byB0aGUgU1IgUG9saWN5IGZ1bmN0aW9uYWxpdHkg4oCTIGJlc2lkZXMgdGhl IGFyY2hpdGVjdHVyZSBkcmFmdCwgdGhlcmUgYXJlIGV4dGVuc2lvbnMgdG8gQkdQIChCR1AtU1JU RSAmIExTKSwgUENFUCB0aGVuIHdlIGhhdmUgWWFuZyBtb2RlbC4gVGhpcyBkcmFmdCBwdXRzIHRo ZXNlIGJsb2NrcyBpbnRvIHJlZmVyZW5jZSBzbyBpbXBsZW1lbnRlcnMgZ2V0IGFuIGlkZWEgb2Yg dGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCBtYXBzIHRvIHNheSBCR1AgYW5kIHRoZSBTUiBQb2xpY3kg cHJvY2Vzc2VzIChlLmcuIGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kp Lg0KDQogICogICAoMikgTXkgZ2VuZXJhbCBmZWVkYmFjayBvbiB0aGlzIHNlY3Rpb24gaXMgdGhh dCB0aGlzIGlzIGltcGxlbWVudGF0aW9uIGRpc2N1c3Npb24sIHRoYXQgZG9lcyBub3QgYWRkIHRv IHRoZSBJRVRGIGNvbnRlbnQgdGhhdCB3ZSBhcmUgcHVibGlzaGluZyB3aXRoaW4gU1BSSU5HLiBM aWtlIHdlIGhhdmUgaGFkIGRpc2N1c3Npb24gb2YgdXNlIGNhc2UgZHJhZnRzLCBJIHRoaW5rIHRo aXMgaXMgc2ltaWxhciBidXQgZnJvbSB0aGUgaW1wbGVtZW50b3Igc2lkZS4gSSdkIGxpa2UgdG8g ZGlzY3VzcyB0aGUgdmFsdWUgdGhhdCB0aGlzIGNvbnRlbnQgaGFzLg0KW0tUXSBUaGVyZSBpcyBh IGRpZmZlcmVuY2UgYmV0d2VlbiBkb2N1bWVudGluZyBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIGFu ZCBwcm92aWRpbmcgYSBjb25jZXB0dWFsIG92ZXJ2aWV3IG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBh c3BlY3RzLiBFc3BlY2lhbGx5IHdoZW4gZGVmaW5pbmcgYW4gYXJjaGl0ZWN0dXJlIHdoaWNoIGlu dm9sdmVzIG11bHRpcGxlIHByb3RvY29scyBhbmQgZnVuY3Rpb25hbCBibG9ja3MuIEkgZmluZCBp dCB2YWx1YWJsZSBhcyBhbiBpbXBsZW1lbnRlciBteXNlbGYuDQoNCiAgKiAgICgzLjEpIEkgdGhp bmsgdGhhdCB0aGlzIHNlY3Rpb24gaGFzIHNvbWUgdXNlZnVsIGNvbnRlbnQsIGJ1dCBpdCdzIGJ1 cmllZCBieSBzdGFydGluZyBvdXQgYnkgZGVmaW5pbmcgdGhlIGFsZ29yaXRobXMuLiBXaHkgbm90 IG1ha2UgdGhpcyBzZWN0aW9uIGJlIGZvY3VzZWQgdG93YXJkcyB0aGUgY29uc3RyYWludHMgdGhh dCBtdXN0IGJlIGNvbnNpZGVyZWQgd2hlbiBjYWxjdWxhdGluZyBhIFNJRCBzdGFjayBmb3IgYSBw YXJ0aWN1bGFyIHBhdGguIGkuZS4sIHRoZSBrZXkgcG9pbnRzIHNlZW0gdG8gYmU6DQoNCiAgICAg KiAgIFVzZSBvZiB0aGUgSUdQIG1ldHJpYyBhcyB0aGUgbWV0cmljIGZvciBwYXRoIG9wdGltaXNh dGlvbiBpcyBkZXNpcmFibGUsIGVzcGVjaWFsbHkgaW4gY29uc3RyYWluZWQgcHVzaCBvciByZWFk YWJsZSBkZXB0aCBlbnZpcm9ubWVudHMsIGJlY2F1c2UgaXQgYWxsb3dzIHRoZSBtaW5pbXVtIG51 bWJlciBvZiBkZXZpYXRpb25zIGZyb20gdGhlIHNob3J0ZXN0IHBhdGggYW5kIHRoZXJlZm9yZSBs YWJlbHMuDQogICAgICogICBJZiBhIGRpZmZlcmVudCBtZXRyaWMgaXMgdXNlZCwgdGhlbiB0aGlz IGltcGxpZXMgdGhhdCBldmVyeSB0aW1lIHRoYXQgbWV0cmljIGRpZmZlcnMgZnJvbSB0aGUgSUdQ IG1ldHJpYywgdGhlbiB0aGlzIHdpbGwgcmVzdWx0IGluIGFkZGl0aW9uYWwgU0lEcy4NCg0KICAg ICAgICAqICAgVGhlcmUgaXMgbm8gbWVudGlvbiBvZiBmbGV4LWFsZ29yaXRobSBpbiB0aGlzIHNl Y3Rpb24uIEl0IHNlZW1zIHJlbGV2YW50IGdpdmVuIHRoYXQgeW91IGNhbiBhbHNvIG1pdGlnYXRl IHRoZSBwcm9ibGVtIHRoYXQgaXMgdHJ5aW5nIHRvIGJlIHNvbHZlZCBoZXJlIGJ5IGhhdmluZyBh IHNldCBvZiBwcmVmaXggU0lEcyBwZXIgbWV0cmljLg0KW0tUXSBXZSB3aWxsIHB1dCBhIGZvcndh cmQgcmVmZXJlbmNlIHRvIHRoZSBGbGV4IEFsZ28gc2VjdGlvbiBoZXJlLg0KDQogICAgICogICBJ dCBtYXkgYmUgYWR2YW50YWdlb3VzIHRvIHNhY3JpZmljZSBvcHRpbWFsaXR5IG9mIHRoZSBwYXRo IGNhbGN1bGF0aW9uIHNvbHV0aW9uIGJ5IHJlbGF4aW5nIHRoZSBvcHRpbWlzYXRpb24gY29uc3Ry YWludHMuDQoNCiAgICAgICAgKiAgIFRoZSBkcmFmdCBzaG91bGQgdGFsayBhYm91dCB0aGUgb3Bl cmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgaGVyZSAtIGkuZS4sIGl0IGltcGxpZXMgdGhhdCB5b3Ug Y2FuIGFjdHVhbGx5IHRvbGVyYXRlIHRoZSBtYXJnaW4gaW4gdGhlIG9wdGltaXNhdGlvbiBvYmpl Y3RpdmUgZm9yIHRoZSBzZXJ2aWNlLg0KICAgICAgICAqICAgVGhlICJqdXN0IHBpY2sgdGhlIGJl c3QgeW91IGNhbiBkbyB3aXRoaW4gTiBTSURzIiBpcyBkYW5nZXJvdXMsIHNpbmNlIGl0IG1lYW5z IHRoYXQgdGhlIG5ldHdvcmsgZGVsaXZlcnMgYSBzZXJ2aWNlIHRoYXQgKmlzbid0KiB3aGF0IHRo ZSBvcGVyYXRvciBhc2tlZCBmb3IgLSB3aGljaCBtYXkgcmVzdWx0IGluIHNlcnZpY2UgZGVncmFk YXRpb24gKGUuZy4sIGNvbnNpZGVyIGxpdmUvbGl2ZSB3aGVyZSB0aGVyZSBpcyBhIG1heGltdW0g bGF0ZW5jeSBkaWZmZXJlbmNlIHRoYXQgaXMgdG9sZXJhYmxlIGJldHdlZW4gdGhlIHR3byBmZWVk cykuDQpbS1RdIFdlIHdpbGwgYWRkIHRleHQgY2xhcmlmeWluZyB0aGlzIGFzcGVjdC4gSG93ZXZl ciwgdGhlIHBvaW50IGlzIGFsc28gdGhhdCB0aGUgb3BlcmF0b3IgbWF5IGJlIE9LIHdpdGggdGhl IOKAnGJlc3QgcG9zc2libGXigJ0gYW5kIHNvIHN1Y2ggYW4gb3B0aW9uIG1heSBiZSB1c2VmdWwg aW4gc29tZSBkZXBsb3ltZW50cy4NCg0KICAqICAgKDMuMikgSSdtIHVuY2xlYXIgb2YgdGhlIHZh bHVlIG9mIHRoaXMgdGV4dC4gSXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSdyZSByZXN0YXRpbmcgc29t ZSBvZiB0aGUgb3B0aW1pc2F0aW9uIG9iamVjdGl2ZXMgdGhhdCBhcmUga25vd24gZm9yIGdlbmVy YWwgVEUgKGFuZCwgZm9yIGV4YW1wbGUsIGFyZSBkZXNjcmliZWQgYnkgLSBzYXkgUkZDMzIwOSku IFdoYXQgaXMgaXQgdGhhdCB3ZSdyZSB0cnlpbmcgdG8gY29tbXVuaWNhdGUgdG8gdGhlIHJlYWRl ciBoZXJlIC0tIGNhbiBpdCBiZSBjb3ZlcmVkIGJ5ICJleGlzdGluZyBwYXRoIGNhbGN1bGF0aW9u IGNvbnNpZGVyYXRpb25zLCBzdWNoIGFzIHJlc291cmNlIGFmZmluaXR5IFtyZmMzMjA5XSBjYW4g YmUgYXBwbGllZCB0byB0aGUgcGF0aCBjYWxjdWxhdGlvbiBvZiBTUiBwYXRocyI/DQpbS1RdIFdl IGRvIG5vdCBhc3N1bWUgdGhhdCBhbnlvbmUgdGhhdCBpcyBkZXBsb3lpbmcgU1IgUG9saWNpZXMg aXMgZmFtaWxpYXIgd2l0aCBSU1ZQLVRFLiBSRkMzMjA5IGRvZXMgY292ZXIgcmVzb3VyY2UgYWZm aW5pdHkgYnV0IG5vdCB0aGUgb3RoZXJzLiBTb21lIG9mIHRoZSBjb25zdHJhaW50cyBhcmUgdW5p cXVlIHRvIFNSLiBIZW5jZSwgdGhlcmUgaXMgYSB2YWx1ZSBpbiBzcGVjaWZ5aW5nIHRoZSBhdmFp bGFibGUgY29uc3RyYWludHMuDQoNCiAgKiAgICgzLjQpIEknbSBhZ2FpbiBnb2luZyB0byBxdWVz dGlvbiB0aGUgdmFsdWUgb2YgdGhpcyBzZWN0aW9uIC0tIGl0IGRvZXNuJ3Qgc2VlbSB0byBnaXZl IGVub3VnaCBkZXRhaWwgb2YgdGhlIGFsZ29yaXRobSB0aGF0IHlvdSdyZSBwcm9wb3NpbmcgdG8g YmUgZ2VuZXJhbGx5IHVzZWZ1bCwgYW5kIHBvaW50cyBvdXQgaXQgaXMgYSBub2RlLWxvY2FsIGJl aGF2aW91ci4gSWYgdGhlcmUncyBhIGRlc2lyZSB0byBnZXQgdG8gYSBjb21tb24gdW5kZXJzdGFu ZGluZyBvZiBob3cgdG8gdGFrZSBhIHBhdGggYW5kIGNvbXByZXNzIGl0cyBTSUQgc3RhY2ssIHRo ZW4gbGV0J3Mgd3JpdGUgdGhpcyBvdXQuDQpbS1RdIEFncmVlIHRoYXQgdGhpcyBpcyBhIG5vZGUg bG9jYWwgYmVoYXZpb3IuIEhvd2V2ZXIsIHRoZSBoaWdoIGxldmVsIGRlc2NyaXB0aW9uIGRvZXMg aW5kaWNhdGUgaG93IGFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGdvIGFib3V0IGRldGVybWluaW5n IGEgcGF0aCB0byBhIFNJRCBpbiBhbiBlZmZpY2llbnQgbWFubmVyLg0KDQogICogICAoNCkgU2Vl IG15IGNvbW1lbnRzIG9uIFNlY3Rpb24gMiBvZiB0aGlzIGRvY3VtZW50LCB3aHkgaXMgZGVzY3Jp YmluZyBob3cgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gZGlmZmVyZW50IHByb2Nlc3NlcyB3aXRo aW4gd2hhdCBzb3VuZHMgbGlrZSBhIHNpbmdsZSBpbXBsZW1lbnRhdGlvbiBzb21ldGhpbmcgdGhh dCB3ZSBzaG91bGQgcHVibGlzaCB3aXRoaW4gdGhlIElFVEY/DQpbS1RdIFRoZXNlIGV4YW1wbGVz IGFyZSBpbXBvcnRhbnQgdG8gaWxsdXN0cmF0ZSBob3cgdGhlIGNhbmRpZGF0ZSBwYXRoIHNlbGVj dGlvbiB0aWVicmVha2VyIHJ1bGVzIHdvcmsgaW4gZGlmZmVyZW50IGNvbmRpdGlvbnMuIFRoZSBp bnRlcmFjdGlvbnMgYXJlIGFsc28gdmFsdWFibGUgdG8gdW5kZXJzdGFuZCB0aGUgc2VsZWN0aW9u IHdoaWNoIGhhcHBlbnMgc2F5IHdpdGhpbiBCR1AgKGJhc2VkIG9uIGl0cyBiZXN0IHBhdGgpIGZv ciBCR1AtU1JURSBhbmQgdGhlIHNlbGVjdGlvbiB0aGF0IHRoZW4gaGFwcGVucyBhdCBTUiBQb2xp Y3kgbGV2ZWwuIFRoaXMgc2VjdGlvbiB3YXMgb3JpZ2luYWxseSBwbGFjZWQgaW4gdGhlIEFwcGVu ZGl4IG9mIHRoZSBTUiBQb2xpY3kgQXJjaGl0ZWN0dXJlIGRyYWZ0IHNpbmNlIHRoZSBjYW5kaWRh dGUgcGF0aCBzZWxlY3Rpb24gdGllYnJlYWtlciBydWxlcyB3ZXJlIHNwZWNpZmllZCBpbiB0aGF0 IGRyYWZ0LiBMYXRlciB3YXMgbW92ZSB0byB0aGlzIGluZm9ybWF0aW9uYWwgZHJhZnQuDQoNCiAg KiAgICg1KzUuMSs1LjIpIFRoZSBjb3JlIHBvaW50IHRoYXQgc2VlbXMgdG8gYmUgYmVpbmcgbWFk ZSBoZXJlIGlzIHRoYXQgLSB3aXRoaW4gYSBzaW5nbGUgSUdQIGFyZWEgdGhlIGhlYWQtZW5kIGhh cyBhbGwgdGhlIHZpc2liaWxpdHkgaXQgcmVxdWlyZXM7IGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBh cmVhcywgdGhlcmUgYXJlIHdheXMgdGhhdCBhIGhlYWQtZW5kIGNvdWxkIGdldCBhY2Nlc3MgdG8g dGhlIGFyZWFzIHRoYXQgaXQgaXMgbm90IHBhcnQgb2YgKGUuZy4sIEJHUC1MUykuIElzIGFueXRo aW5nIG1vcmUgYmVpbmcgc2FpZCBoZXJlPyBEbyB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0 aGF0IHRoZXJlIGFyZSBCR1AtTFMgUlJzIGFjdHVhbGx5IG1hdHRlcj8NCltLVF0gVGhlIGludGVu dGlvbiBpcyB0byBwcm92aWRlIGd1aWRhbmNlIGZvciBzb21lIG9mIHRoZSBkZXBsb3ltZW50IG9w dGlvbnMgZm9yIGFjaGlldmluZyB0aGlzIGZ1bmN0aW9uYWxpdHkuDQoNCiAgKiAgICg1LjMpIFNp bWlsYXJseSB0byB0aGUgYWJvdmUsIHRoaXMgc2VlbXMgdG8gYXNzdW1lIG9uZSBwYXJ0aWN1bGFy IG1lY2hhbmlzbSBvZiBidWlsZGluZyBhIGNlbnRyYWxpc2VkIHN5c3RlbSwgdGhhdCBkb2Vzbid0 IG5lZWQgYW55IG5ldyBleHRlbnNpb25zIGluIHRoZSBJRVRGLiBJcyB0aGlzIHNvbWV0aGluZyB0 aGF0IHdlIG5lZWQgdG8gZG9jdW1lbnQ/DQpbS1RdIFdlIGV4cGxhaW4gd2hpbGUgdGFraW5nIGFu IGV4YW1wbGUgb2YgYSBtZWNoYW5pc20gYmFzZWQgb24gSUVURiBzdGFuZGFyZHMgdGhhdCBpcyBh dmFpbGFibGUgZm9yIG9wZXJhdG9ycyBsb29raW5nIHRvIGRlcGxveSB0aGlzIG1vZGVsLg0KDQog ICogICAoNi4yKSBUaGlzIHNlY3Rpb24gc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGVyZSBjYW4gbmV2 ZXIgYmUgYWxsb2NhdGlvbnMgZnJvbSB0aGUgU1JMQiB0aGF0IGFyZSBub3QgZHluYW1pY2FsbHkg YWR2ZXJ0aXNlZCB2aWEgc29tZSBvdGhlciBwcm90b2NvbC4gSXMgdGhpcyByZWFsbHkgdHJ1ZT8N CltLVF0gSSBkb27igJl0IGJlbGlldmUgdGhpcyB3YXMgdGhlIGludGVudGlvbi4gV2Ugd2lsbCBj bGFyaWZ5IHRoaXMgaW4gdGhlIHRleHQuDQoNCiAgKiAgICg4KSBHaXZlbiB0aGF0IHRoZXJlIGlz IGEgc2VwYXJhdGUgZHJhZnQgZGlzY3Vzc2luZyB0aGlzIC0tIHdoYXQgaXMgdGhlIG1vdGl2YXRp b24gdG8gaGF2ZSB0aGlzIGluIHRoaXMgZG9jdW1lbnQ/DQpbS1RdIFRoaXMgc2VjdGlvbiBnaXZl cyBhbmQgb3ZlcnZpZXcgb2YgdGhlIHByb3Bvc2FsIHdpdGggYW4gZXhhbXBsZSBvZiBvcHRpY2Fs IGNpcmN1aXQuIEl0IGFsc28gY2xhcmlmaWVzIHRoYXQgdGhlIGNvbmNlcHQgZGVzY3JpYmVkIGlz IGFwcGxpY2FibGUgbm90IGp1c3QgZm9yIG9wdGljYWwgbGlua3MgYnV0IGluIGdlbmVyYWwgdG8g b3RoZXIgdHlwZXMgb2YgbGF5ZXIgMiBjaXJjdWl0cyBhbmQgdHVubmVscyBhcyB3ZWxsLiBUaGUg ZHJhZnQtYW5hbmQtc3ByaW5nLXBvaS1zciBnb2VzIGludG8gdGhlIGRldGFpbHMgb2YgdGhlIHVz ZS1jYXNlLCBwcm90b2NvbCBtZWNoYW5pc20gYW5kIGV4dGVuc2lvbnMgc3BlY2lmaWNhbGx5IGZv ciBvcHRpY2FsIG5ldHdvcmtzIG9ubHkuDQpUaGFua3MsDQpyLg0K --_000_3470b63ec7264ac096e326a59d97b50fXCHALN008ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDg3OTk0ODgxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czo1OTA1Mjg1MTg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0 NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFJvYiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuIFBsZWFzZSBmaW5kIGlu bGluZSBiZWxvdyBvdXIgcmVzcG9uc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tSU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsIHdvcmsgb24gcG9zdGlu ZyBhbiB1cGRhdGUgdG8gdGhlIGRyYWZ0IHRvIGluY29ycG9yYXRlIHlvdXIgY29tbWVudHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t SU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPktldGFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t SU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBzcHJpbmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0 Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2IgU2hha2lyPGJyPg0KPGI+U2VudDo8L2I+IDI1IEp1 bHkgMjAxOCAyMToxOTxicj4NCjxiPlRvOjwvYj4gU1BSSU5HIFdHIExpc3QgJmx0O3NwcmluZ0Bp ZXRmLm9yZyZndDs7IGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lkZXJhdGlv bnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NwcmluZ10gQ29tbWVudHMg b24gZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXBvbGljeS1jb25zaWRlcmF0aW9ucy0wMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oQXMgYW4gaW5kaXZpZHVh bCBjb250cmlidXRvcik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgQXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyIG15IGNvbW1lbnRzIGluIFNQUklORyBhdCBJRVRGIDEw MiwgSSBoYXZlIGEgbnVtYmVyIG9mIGNvbW1lbnRzL2NvbmNlcm5zIGFib3V0IHRoZSBjb250ZW50 cyBvZiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgZmluZCB0aGVtIGJlbG93LiBJIGxvb2sgZm9yd2Fy ZCB0byBkaXNjdXNzaW5nIHRoZW0gaW4gbW9yZSBkZXRhaWwuLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCigyKSBXaGF0IGlzIHRoZSBpbnRlbnRpb24gb2YgdGhlIGRpYWdyYW0g c2hvd24gaW4gdGhpcyBzZWN0aW9uPyBJdCBzZWVtcyB0byBiZSBjb21wbGV0ZWx5IGFuIGltcGxl bWVudGF0aW9uIGRldGFpbCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGhhcyB0aGUgJnF1b3Q7U1JQ TSZxdW90OyB0aGF0IGFjdHMgYXMgYSBjZW50cmFsIHJlc29sdXRpb24gcG9pbnQuIEZvciBpbnN0 YW5jZSwgd2hhdCBzaG91bGQgYSByZWFkZXIgbGVhcm4gZnJvbSB0aGUgZmFjdCB0aGF0IHRoZQ0K IFNSUE0gaXMgbm90IGEgc3RhbmRhcmQgUklCIHJlc29sdXRpb24gcHJvY2Vzcz8gSWYgdGhlcmUg YXJlIHN1Z2dlc3Rpb25zIHRoYXQgb25lIHdhbnRzIHRoaXMgaW1wbGVtZW50YXRpb24gLSBzaG91 bGQgdGhlcmUgYmUgc29tZSBkaXNjdXNzaW9uIG9mIHRoZSBjb21wbGV4aXR5IG9mIHRoaXMgbmV3 IEFQSSBiZXR3ZWVuIHNheSwgdGhlIEJHUCBkYWVtb24gYW5kIGEgZ2VuZXJhbCBSSUIgcHJvY2Vz cz88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltLVF0NCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPldlIHdpbGwgY2xhcmlm eSBpbiB0aGUgdGV4dCB0aGF0IHRoZSBzZWN0aW9uIHByb3ZpZGVzIGEgY29uY2VwdHVhbCBvdmVy dmlldyBvZiBjb21wb25lbnRzL2Z1bmN0aW9uYWxpdHkgdGhhdCB3b3JrIHdpdGggZWFjaCBvdGhl ciB0byBpbXBsZW1lbnQgU1IgUG9saWN5IG9uIGEgaGVhZGVuZC4gVGhlIGludGVudGlvbiBpcyBu b3QgdG8NCiBkZWZpbmUgQVBJcyBiZXR3ZWVuIHRoZSBibG9ja3Mgc2luY2UgdGhvc2UgYXJlIGlt cGxlbWVudGF0aW9uIGRldGFpbHMuIFdlIGhhdmUgc2V2ZXJhbCBkcmFmdHMgcmVsYXRlZCB0byB0 aGUgU1IgUG9saWN5IGZ1bmN0aW9uYWxpdHkg4oCTIGJlc2lkZXMgdGhlIGFyY2hpdGVjdHVyZSBk cmFmdCwgdGhlcmUgYXJlIGV4dGVuc2lvbnMgdG8gQkdQIChCR1AtU1JURSAmYW1wOyBMUyksIFBD RVAgdGhlbiB3ZSBoYXZlIFlhbmcgbW9kZWwuIFRoaXMgZHJhZnQgcHV0cw0KIHRoZXNlIGJsb2Nr cyBpbnRvIHJlZmVyZW5jZSBzbyBpbXBsZW1lbnRlcnMgZ2V0IGFuIGlkZWEgb2YgdGhlIGZ1bmN0 aW9uYWxpdHkgdGhhdCBtYXBzIHRvIHNheSBCR1AgYW5kIHRoZSBTUiBQb2xpY3kgcHJvY2Vzc2Vz IChlLmcuIGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kpLjwvc3Bhbj48 L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCigyKSBNeSBnZW5lcmFsIGZlZWRiYWNrIG9uIHRoaXMgc2VjdGlvbiBp cyB0aGF0IHRoaXMgaXMgaW1wbGVtZW50YXRpb24gZGlzY3Vzc2lvbiwgdGhhdCBkb2VzIG5vdCBh ZGQgdG8gdGhlIElFVEYgY29udGVudCB0aGF0IHdlIGFyZSBwdWJsaXNoaW5nIHdpdGhpbiBTUFJJ TkcuIExpa2Ugd2UgaGF2ZSBoYWQgZGlzY3Vzc2lvbiBvZiB1c2UgY2FzZSBkcmFmdHMsIEkgdGhp bmsgdGhpcyBpcyBzaW1pbGFyIGJ1dCBmcm9tIHRoZSBpbXBsZW1lbnRvciBzaWRlLg0KIEknZCBs aWtlIHRvIGRpc2N1c3MgdGhlIHZhbHVlIHRoYXQgdGhpcyBjb250ZW50IGhhcy48bzpwPjwvbzpw PjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPltLVF0NCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3 ZWVuIGRvY3VtZW50aW5nIGltcGxlbWVudGF0aW9uIGRldGFpbHMgYW5kIHByb3ZpZGluZyBhIGNv bmNlcHR1YWwgb3ZlcnZpZXcgb2YgdGhlIGltcGxlbWVudGF0aW9uIGFzcGVjdHMuIEVzcGVjaWFs bHkgd2hlbiBkZWZpbmluZyBhbiBhcmNoaXRlY3R1cmUgd2hpY2ggaW52b2x2ZXMgbXVsdGlwbGUN CiBwcm90b2NvbHMgYW5kIGZ1bmN0aW9uYWwgYmxvY2tzLiBJIGZpbmQgaXQgdmFsdWFibGUgYXMg YW4gaW1wbGVtZW50ZXIgbXlzZWxmLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCigzLjEpIEkgdGhp bmsgdGhhdCB0aGlzIHNlY3Rpb24gaGFzIHNvbWUgdXNlZnVsIGNvbnRlbnQsIGJ1dCBpdCdzIGJ1 cmllZCBieSBzdGFydGluZyBvdXQgYnkgZGVmaW5pbmcgdGhlIGFsZ29yaXRobXMuLiBXaHkgbm90 IG1ha2UgdGhpcyBzZWN0aW9uIGJlIGZvY3VzZWQgdG93YXJkcyB0aGUgY29uc3RyYWludHMgdGhh dCBtdXN0IGJlIGNvbnNpZGVyZWQgd2hlbiBjYWxjdWxhdGluZyBhIFNJRCBzdGFjayBmb3IgYSBw YXJ0aWN1bGFyIHBhdGguIGkuZS4sDQogdGhlIGtleSBwb2ludHMgc2VlbSB0byBiZTo8bzpwPjwv bzpwPjwvbGk+PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQpVc2Ugb2YgdGhl IElHUCBtZXRyaWMgYXMgdGhlIG1ldHJpYyBmb3IgcGF0aCBvcHRpbWlzYXRpb24gaXMgZGVzaXJh YmxlLCBlc3BlY2lhbGx5IGluIGNvbnN0cmFpbmVkIHB1c2ggb3IgcmVhZGFibGUgZGVwdGggZW52 aXJvbm1lbnRzLCBiZWNhdXNlIGl0IGFsbG93cyB0aGUgbWluaW11bSBudW1iZXIgb2YgZGV2aWF0 aW9ucyBmcm9tIHRoZSBzaG9ydGVzdCBwYXRoIGFuZCB0aGVyZWZvcmUgbGFiZWxzLjxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4N CklmIGEgZGlmZmVyZW50IG1ldHJpYyBpcyB1c2VkLCB0aGVuIHRoaXMgaW1wbGllcyB0aGF0IGV2 ZXJ5IHRpbWUgdGhhdCBtZXRyaWMgZGlmZmVycyBmcm9tIHRoZSBJR1AgbWV0cmljLCB0aGVuIHRo aXMgd2lsbCByZXN1bHQgaW4gYWRkaXRpb25hbCBTSURzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0K PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNx dWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMyBsZm8xIj4N ClRoZXJlIGlzIG5vIG1lbnRpb24gb2YgZmxleC1hbGdvcml0aG0gaW4gdGhpcyBzZWN0aW9uLiBJ dCBzZWVtcyByZWxldmFudCBnaXZlbiB0aGF0IHlvdSBjYW4gYWxzbyBtaXRpZ2F0ZSB0aGUgcHJv YmxlbSB0aGF0IGlzIHRyeWluZyB0byBiZSBzb2x2ZWQgaGVyZSBieSBoYXZpbmcgYSBzZXQgb2Yg cHJlZml4IFNJRHMgcGVyIG1ldHJpYy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+W0tUXQ0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+V2Ugd2lsbCBwdXQgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0 aGUgRmxleCBBbGdvIHNlY3Rpb24gaGVyZS48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0K PHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMiBsZm8xIj4NCkl0IG1heSBiZSBhZHZhbnRhZ2VvdXMgdG8gc2FjcmlmaWNlIG9wdGltYWxp dHkgb2YgdGhlIHBhdGggY2FsY3VsYXRpb24gc29sdXRpb24gYnkgcmVsYXhpbmcgdGhlIG9wdGlt aXNhdGlvbiBjb25zdHJhaW50cy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDMgbGZvMSI+DQpUaGUgZHJhZnQgc2hv dWxkIHRhbGsgYWJvdXQgdGhlIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIGhlcmUgLSBpLmUu LCBpdCBpbXBsaWVzIHRoYXQgeW91IGNhbiBhY3R1YWxseSB0b2xlcmF0ZSB0aGUgbWFyZ2luIGlu IHRoZSBvcHRpbWlzYXRpb24gb2JqZWN0aXZlIGZvciB0aGUgc2VydmljZS48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDMgbGZvMSI+DQpUaGUg JnF1b3Q7anVzdCBwaWNrIHRoZSBiZXN0IHlvdSBjYW4gZG8gd2l0aGluIE4gU0lEcyZxdW90OyBp cyBkYW5nZXJvdXMsIHNpbmNlIGl0IG1lYW5zIHRoYXQgdGhlIG5ldHdvcmsgZGVsaXZlcnMgYSBz ZXJ2aWNlIHRoYXQgKmlzbid0KiB3aGF0IHRoZSBvcGVyYXRvciBhc2tlZCBmb3IgLSB3aGljaCBt YXkgcmVzdWx0IGluIHNlcnZpY2UgZGVncmFkYXRpb24gKGUuZy4sIGNvbnNpZGVyIGxpdmUvbGl2 ZSB3aGVyZSB0aGVyZSBpcyBhIG1heGltdW0gbGF0ZW5jeQ0KIGRpZmZlcmVuY2UgdGhhdCBpcyB0 b2xlcmFibGUgYmV0d2VlbiB0aGUgdHdvIGZlZWRzKS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwv dWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+W0tUXQ0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+V2Ugd2lsbCBhZGQgdGV4dCBjbGFyaWZ5aW5n IHRoaXMgYXNwZWN0LiBIb3dldmVyLCB0aGUgcG9pbnQgaXMgYWxzbyB0aGF0IHRoZSBvcGVyYXRv ciBtYXkgYmUgT0sgd2l0aCB0aGUg4oCcYmVzdCBwb3NzaWJsZeKAnSBhbmQgc28gc3VjaCBhbiBv cHRpb24gbWF5IGJlIHVzZWZ1bCBpbiBzb21lIGRlcGxveW1lbnRzLjwvc3Bhbj48L2k+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCigzLjIpIEknbSB1bmNsZWFyIG9mIHRoZSB2YWx1ZSBvZiB0aGlzIHRleHQuIEl0IHNl ZW1zIHRvIG1lIHRoYXQgd2UncmUgcmVzdGF0aW5nIHNvbWUgb2YgdGhlIG9wdGltaXNhdGlvbiBv YmplY3RpdmVzIHRoYXQgYXJlIGtub3duIGZvciBnZW5lcmFsIFRFIChhbmQsIGZvciBleGFtcGxl LCBhcmUgZGVzY3JpYmVkIGJ5IC0gc2F5IFJGQzMyMDkpLiBXaGF0IGlzIGl0IHRoYXQgd2UncmUg dHJ5aW5nIHRvIGNvbW11bmljYXRlIHRvIHRoZSByZWFkZXINCiBoZXJlIC0tIGNhbiBpdCBiZSBj b3ZlcmVkIGJ5ICZxdW90O2V4aXN0aW5nIHBhdGggY2FsY3VsYXRpb24gY29uc2lkZXJhdGlvbnMs IHN1Y2ggYXMgcmVzb3VyY2UgYWZmaW5pdHkgW3JmYzMyMDldIGNhbiBiZSBhcHBsaWVkIHRvIHRo ZSBwYXRoIGNhbGN1bGF0aW9uIG9mIFNSIHBhdGhzJnF1b3Q7PzxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+W0tUXQ0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+V2UgZG8gbm90IGFzc3VtZSB0aGF0IGFueW9uZSB0aGF0IGlz IGRlcGxveWluZyBTUiBQb2xpY2llcyBpcyBmYW1pbGlhciB3aXRoIFJTVlAtVEUuIFJGQzMyMDkg ZG9lcyBjb3ZlciByZXNvdXJjZSBhZmZpbml0eSBidXQgbm90IHRoZSBvdGhlcnMuIFNvbWUgb2Yg dGhlIGNvbnN0cmFpbnRzIGFyZSB1bmlxdWUgdG8gU1IuIEhlbmNlLA0KIHRoZXJlIGlzIGEgdmFs dWUgaW4gc3BlY2lmeWluZyB0aGUgYXZhaWxhYmxlIGNvbnN0cmFpbnRzLjwvc3Bhbj48L2k+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCigzLjQpIEknbSBhZ2FpbiBnb2luZyB0byBxdWVzdGlvbiB0aGUgdmFsdWUgb2Yg dGhpcyBzZWN0aW9uIC0tIGl0IGRvZXNuJ3Qgc2VlbSB0byBnaXZlIGVub3VnaCBkZXRhaWwgb2Yg dGhlIGFsZ29yaXRobSB0aGF0IHlvdSdyZSBwcm9wb3NpbmcgdG8gYmUgZ2VuZXJhbGx5IHVzZWZ1 bCwgYW5kIHBvaW50cyBvdXQgaXQgaXMgYSBub2RlLWxvY2FsIGJlaGF2aW91ci4gSWYgdGhlcmUn cyBhIGRlc2lyZSB0byBnZXQgdG8gYSBjb21tb24gdW5kZXJzdGFuZGluZw0KIG9mIGhvdyB0byB0 YWtlIGEgcGF0aCBhbmQgY29tcHJlc3MgaXRzIFNJRCBzdGFjaywgdGhlbiBsZXQncyB3cml0ZSB0 aGlzIG91dC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltLVF0NCjwvc3Bhbj48L2k+PC9iPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiM0NDU0NkEiPkFncmVlIHRo YXQgdGhpcyBpcyBhIG5vZGUgbG9jYWwgYmVoYXZpb3IuIEhvd2V2ZXIsIHRoZSBoaWdoIGxldmVs IGRlc2NyaXB0aW9uIGRvZXMgaW5kaWNhdGUgaG93IGFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGdv IGFib3V0IGRldGVybWluaW5nIGEgcGF0aCB0byBhIFNJRCBpbiBhbiBlZmZpY2llbnQgbWFubmVy Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiM0NDU0 NkEiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KKDQpIFNlZSBteSBjb21tZW50 cyBvbiBTZWN0aW9uIDIgb2YgdGhpcyBkb2N1bWVudCwgd2h5IGlzIGRlc2NyaWJpbmcgaG93IHRo ZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCBwcm9jZXNzZXMgd2l0aGluIHdoYXQgc291 bmRzIGxpa2UgYSBzaW5nbGUgaW1wbGVtZW50YXRpb24gc29tZXRoaW5nIHRoYXQgd2Ugc2hvdWxk IHB1Ymxpc2ggd2l0aGluIHRoZSBJRVRGPzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0tUXQ0K PC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+VGhlc2UgZXhhbXBsZXMgYXJlIGltcG9ydGFudCB0byBpbGx1c3RyYXRlIGhvdyB0 aGUgY2FuZGlkYXRlIHBhdGggc2VsZWN0aW9uIHRpZWJyZWFrZXIgcnVsZXMgd29yayBpbiBkaWZm ZXJlbnQgY29uZGl0aW9ucy4gVGhlIGludGVyYWN0aW9ucyBhcmUgYWxzbyB2YWx1YWJsZSB0byB1 bmRlcnN0YW5kIHRoZSBzZWxlY3Rpb24gd2hpY2gNCiBoYXBwZW5zIHNheSB3aXRoaW4gQkdQIChi YXNlZCBvbiBpdHMgYmVzdCBwYXRoKSBmb3IgQkdQLVNSVEUgYW5kIHRoZSBzZWxlY3Rpb24gdGhh dCB0aGVuIGhhcHBlbnMgYXQgU1IgUG9saWN5IGxldmVsLiBUaGlzIHNlY3Rpb24gd2FzIG9yaWdp bmFsbHkgcGxhY2VkIGluIHRoZSBBcHBlbmRpeCBvZiB0aGUgU1IgUG9saWN5IEFyY2hpdGVjdHVy ZSBkcmFmdCBzaW5jZSB0aGUgY2FuZGlkYXRlIHBhdGggc2VsZWN0aW9uIHRpZWJyZWFrZXIgcnVs ZXMNCiB3ZXJlIHNwZWNpZmllZCBpbiB0aGF0IGRyYWZ0LiBMYXRlciB3YXMgbW92ZSB0byB0aGlz IGluZm9ybWF0aW9uYWwgZHJhZnQuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KKDUmIzQzOzUuMSYj NDM7NS4yKSBUaGUgY29yZSBwb2ludCB0aGF0IHNlZW1zIHRvIGJlIGJlaW5nIG1hZGUgaGVyZSBp cyB0aGF0IC0gd2l0aGluIGEgc2luZ2xlIElHUCBhcmVhIHRoZSBoZWFkLWVuZCBoYXMgYWxsIHRo ZSB2aXNpYmlsaXR5IGl0IHJlcXVpcmVzOyBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgYXJlYXMsIHRo ZXJlIGFyZSB3YXlzIHRoYXQgYSBoZWFkLWVuZCBjb3VsZCBnZXQgYWNjZXNzIHRvIHRoZSBhcmVh cyB0aGF0IGl0IGlzIG5vdCBwYXJ0IG9mDQogKGUuZy4sIEJHUC1MUykuIElzIGFueXRoaW5nIG1v cmUgYmVpbmcgc2FpZCBoZXJlPyBEbyB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0aGF0IHRo ZXJlIGFyZSBCR1AtTFMgUlJzIGFjdHVhbGx5IG1hdHRlcj88bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltLVF0NCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPlRoZSBpbnRlbnRpb24gaXMgdG8gcHJvdmlkZSBndWlkYW5jZSBm b3Igc29tZSBvZiB0aGUgZGVwbG95bWVudCBvcHRpb25zIGZvciBhY2hpZXZpbmcgdGhpcyBmdW5j dGlvbmFsaXR5Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCig1LjMpIFNpbWlsYXJseSB0byB0aGUg YWJvdmUsIHRoaXMgc2VlbXMgdG8gYXNzdW1lIG9uZSBwYXJ0aWN1bGFyIG1lY2hhbmlzbSBvZiBi dWlsZGluZyBhIGNlbnRyYWxpc2VkIHN5c3RlbSwgdGhhdCBkb2Vzbid0IG5lZWQgYW55IG5ldyBl eHRlbnNpb25zIGluIHRoZSBJRVRGLiBJcyB0aGlzIHNvbWV0aGluZyB0aGF0IHdlIG5lZWQgdG8g ZG9jdW1lbnQ/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bS1RdDQo8L3NwYW4+PC9pPjwvYj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5XZSBleHBs YWluIHdoaWxlIHRha2luZyBhbiBleGFtcGxlIG9mIGEgbWVjaGFuaXNtIGJhc2VkIG9uIElFVEYg c3RhbmRhcmRzIHRoYXQgaXMgYXZhaWxhYmxlIGZvciBvcGVyYXRvcnMgbG9va2luZyB0byBkZXBs b3kgdGhpcyBtb2RlbC48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooNi4yKSBUaGlzIHNlY3Rpb24g c2VlbXMgdG8gaW1wbHkgdGhhdCB0aGVyZSBjYW4gbmV2ZXIgYmUgYWxsb2NhdGlvbnMgZnJvbSB0 aGUgU1JMQiB0aGF0IGFyZSBub3QgZHluYW1pY2FsbHkgYWR2ZXJ0aXNlZCB2aWEgc29tZSBvdGhl ciBwcm90b2NvbC4gSXMgdGhpcyByZWFsbHkgdHJ1ZT88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltLVF0NCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBiZWxpZXZlIHRoaXMgd2FzIHRoZSBpbnRlbnRpb24u IFdlIHdpbGwgY2xhcmlmeSB0aGlzIGluIHRoZSB0ZXh0Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N Cig4KSBHaXZlbiB0aGF0IHRoZXJlIGlzIGEgc2VwYXJhdGUgZHJhZnQgZGlzY3Vzc2luZyB0aGlz IC0tIHdoYXQgaXMgdGhlIG1vdGl2YXRpb24gdG8gaGF2ZSB0aGlzIGluIHRoaXMgZG9jdW1lbnQ/ PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bS1RdDQo8L3NwYW4+PC9pPjwvYj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojNDQ1NDZBIj5UaGlzIHNlY3Rpb24gZ2l2 ZXMgYW5kIG92ZXJ2aWV3IG9mIHRoZSBwcm9wb3NhbCB3aXRoIGFuIGV4YW1wbGUgb2Ygb3B0aWNh bCBjaXJjdWl0LiBJdCBhbHNvIGNsYXJpZmllcyB0aGF0IHRoZSBjb25jZXB0IGRlc2NyaWJlZCBp cyBhcHBsaWNhYmxlIG5vdCBqdXN0IGZvciBvcHRpY2FsIGxpbmtzIGJ1dCBpbiBnZW5lcmFsIHRv IG90aGVyDQogdHlwZXMgb2YgbGF5ZXIgMiBjaXJjdWl0cyBhbmQgdHVubmVscyBhcyB3ZWxsLiBU aGUgZHJhZnQtYW5hbmQtc3ByaW5nLXBvaS1zciBnb2VzIGludG8gdGhlIGRldGFpbHMgb2YgdGhl IHVzZS1jYXNlLCBwcm90b2NvbCBtZWNoYW5pc20gYW5kIGV4dGVuc2lvbnMgc3BlY2lmaWNhbGx5 IGZvciBvcHRpY2FsIG5ldHdvcmtzIG9ubHkuDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3470b63ec7264ac096e326a59d97b50fXCHALN008ciscocom_-- From nobody Thu Oct 18 23:24:04 2018 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 EDBE31277BB; Thu, 18 Oct 2018 23:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 3pXfLZYM2gLm; Thu, 18 Oct 2018 23:24:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C28EA126BED; Thu, 18 Oct 2018 23:23:59 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4E864A69CE18F; Fri, 19 Oct 2018 07:23:56 +0100 (IST) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 07:23:56 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0399.000; Fri, 19 Oct 2018 14:23:43 +0800 From: "Chengli (IP Technology Research)" To: "draft-ietf-spring-segment-routing-policy@ietf.org" , "draft-ietf-idr-segment-routing-te-policy@ietf.org" CC: SPRING WG List , Lizhenbin Thread-Topic: Question: Inconsistency of SR policy structure Thread-Index: AdRndBziOl2h89Q1SVKtaryHB0wLpw== Date: Fri, 19 Oct 2018 06:23:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB01A4DC6Fdggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] Question: Inconsistency of SR policy structure X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 06:24:03 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB01A4DC6Fdggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors, I am working on updating drafts of path segment extensions in BGP/BGP-LS: * https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-d= istribution-00 * https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-se= gment-00 But I found the inconsistency of SR policy structure. * In https://tools.ietf.org/html//draft-ietf-spring-segment-routing-pol= icy-01, the SR policy's structure looks like: SR policy POL1 Candidate-path CP1 Preference 200 Weight W1, SID-List1 Weight W2, SID-List2 Candidate-path CP2 Preference 100 Weight W3, SID-List3 Weight W4, SID-List4 So the structure is : SR Policy Candidate-path p1 Weighted SID-list1 Weighted SID-list2 Candidate-path p2 Weighted SID-list3 Weighted SID-list4 But in https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy= -04, SR policy is described by following structure, SR Policy SAFI NLRI: Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID Preference Priority Policy Name Explicit NULL Label Policy (ENLP) Segment List Weight Segment Segment ... ... The structure is, SR Policy SID list1 SID list2 Where is the candidate-path? it seems like they are not aligned. Thanks, Cheng --_000_C7C2E1C43D652C4E9E49FE7517C236CB01A4DC6Fdggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors,

 

I am working on updating drafts of path segment exte= nsions in BGP/BGP-LS:

·         https://tools.ietf.org/html= /draft-li-idr-sr-policy-path-segment-distribution-00

·         https://tools.ietf.org/html/draft= -li-idr-bgp-ls-sr-policy-path-segment-00

 

But I found the inconsistency of SR policy structure= .

 

       &nbs= p;    SR policy POL1 <headend, color, endpoint>=

       &nbs= p;      Candidate-path CP1 <protocol-origin =3D= 20, originator =3D

   100:1.1.1.1, discriminator =3D 1&= gt;

       &nbs= p;        Preference 200

       &nbs= p;        Weight W1, SID-List1 <SID11= ...SID1i>

       &nbs= p;        Weight W2, SID-List2 <SID21= ...SID2j>

       &nbs= p;      Candidate-path CP2 <protocol-origin =3D= 20, originator =3D

   100:2.2.2.2, discriminator =3D 2&= gt;

       &nbs= p;        Preference 100

       &nbs= p;        Weight W3, SID-List3 <SID31= ...SID3i>

       &nbs= p;        Weight W4, SID-List4 <SID41= ...SID4j>

 

So the structure is :

SR Policy=

  &= nbsp;           &nbs= p; Candidate-path p1

  &= nbsp;           &nbs= p;            &= nbsp;    Weighted SID-list1

  &= nbsp;           &nbs= p;            &= nbsp;    Weighted SID-list2

  &= nbsp;           &nbs= p; Candidate-path p2

  &= nbsp;           &nbs= p;            &= nbsp;    Weighted SID-list3

  &= nbsp;           &nbs= p;            &= nbsp;    Weighted SID-list4

 

But in https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04= , SR policy is described by following structure,

 

   SR Policy SAFI NLRI: <Distinguisher, Policy-Colo=
r, Endpoint>
   Attributes:
      Tunnel Encaps Attribute (23)
         Tunnel Type: SR=
 Policy
          &nbs=
p;  Binding SID
          &nbs=
p;  Preference
          &nbs=
p;  Priority
          &nbs=
p;  Policy Name
           &nb=
sp; Explicit NULL Label Policy (ENLP)
          &nbs=
p;  Segment List
          &nbs=
p;      Weight
          &nbs=
p;      Segment
          &nbs=
p;      Segment
          &nbs=
p;      ...
          &nbs=
p;  ...

 

The structure is,

        &= nbsp;       SR Policy

        &= nbsp;           &nbs= p;           SID list1

        &= nbsp;           &nbs= p;           SID list2

 

Where is the candidate-path?  it seems like the= y are not aligned.

 

Thanks,

Cheng

 

 

 

--_000_C7C2E1C43D652C4E9E49FE7517C236CB01A4DC6Fdggeml529mbxchi_-- From nobody Thu Oct 18 23:48:57 2018 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 09DEC126BED for ; Thu, 18 Oct 2018 23:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.20150623.gappssmtp.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 V3L9tUG4NTb6 for ; Thu, 18 Oct 2018 23:48:54 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 E513C127AC2 for ; Thu, 18 Oct 2018 23:48:50 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 206-v6so2480355wmb.5 for ; Thu, 18 Oct 2018 23:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MNcFRpvYg8gFVh5aIOhnJADbHDRlh6cC9U4GiDCFelo=; b=rY7LgaNrnCcIzQO9qe4dMH0L5zXsVC9GYfvedQqOEGk5J6874ut0qlqRecfGCePcPH XyuWT4AaMyyOUOo0eQGk3yd24FOxT1cnKpYolbdcN3UcRmjjRCMDPGktDoPw3GxuAOHL Yr3J5miJuCUxWN8s6POZ5DKhNW/YkjykPlaIRncecbsQHyBsJNFPwi757E9LNoPm7J9v 931dwWfP8KCeW5gsKjYQ5/igcNwyklOJTdqso8/dTc+AlTwTc6oSbTQGMhJeJZ70LzWE Xi4JZvpSNiANxnwnin4espjmu+NgAOXxzB4fI3VFeunwlOmJC942L9wtNnGPFmCMEY/O XV8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MNcFRpvYg8gFVh5aIOhnJADbHDRlh6cC9U4GiDCFelo=; b=TpXrQZUCtbvXqiggbw4puQbh7P240rdfjGMyWWW1C5aUVBaWxqsh1E3V4EcyXTmloA DSNkBdEhzSHMj3ZbZi61+H7H3PBIFvUp1XIvMD69T4RSOxJbcro9bn/DB0SOh3afwSqs vz8Qippq8peobTHluBhVHGGUtIHCHR22R3tW/Vn6/WyNKE7eQGf9cT3ZDF2YOQdGY2hB prWzeXQgOEoaTU/YQscpHa4UfY+ctXV5Qx2qu7L+C5NGV8GYc/l3Ot9WVHT+g/d386S5 sRdG8o1KD6WtYABJWhJHOsHxFlcIFUqqXsweFInvlNDDDwaTJGRnNfiJ3FsgcN45LrQJ hGWw== X-Gm-Message-State: ABuFfohFV/u4AY3eYYdCkhAZwaZNgoRYM1pFAdgnCNeZcer9JWT/J5FR 8Otrf2tDFIUCnoEJv2LBKwEijg== X-Google-Smtp-Source: ACcGV63fFkYTpvmVsY2+ir3CPVaGqO2dxzA+oHSp3XepEoHf6JI9F0RLHan+E+OvWHeSzfTW6L0fcA== X-Received: by 2002:a1c:e0d7:: with SMTP id x206-v6mr3333985wmg.93.1539931729168; Thu, 18 Oct 2018 23:48:49 -0700 (PDT) Received: from [192.168.1.8] (net-2-39-131-107.cust.vodafonedsl.it. [2.39.131.107]) by smtp.gmail.com with ESMTPSA id b139-v6sm4410276wmd.36.2018.10.18.23.48.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Oct 2018 23:48:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: stefano previdi In-Reply-To: Date: Fri, 19 Oct 2018 08:48:55 +0200 Cc: "draft-ietf-spring-segment-routing-policy@ietf.org" , "draft-ietf-idr-segment-routing-te-policy@ietf.org" , SPRING WG List , Robin Content-Transfer-Encoding: quoted-printable Message-Id: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> References: To: "Chengli (IP Technology Research)" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [spring] Question: Inconsistency of SR policy structure X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 06:48:56 -0000 Hi Cheng, to my understanding the definition of an SR Policy = (draft-ietf-spring-segment-routing-policy) is correct. An SR Policy may include different paths and each of these paths may be = advertised in a different way (BGP, PCEP, static, ...). BGP extensions described in draft-ietf-idr-segment-routing-te-policy is = one of the ways paths of a policy may be advertised.=20 In other words, to my understanding at the time we wrote the BGP = extensions, the SR Policy defined in = draft-ietf-spring-segment-routing-policy is the set of all paths = individually advertised in BGP, PCEP, etc. It may looks like a terminology issue but in fact, I don=E2=80=99t think = so. Even if BGP (or PCEP) advertises a policy with a single path, it is = still a valid SR Policy from the perspective of the advertiser. So the = term =E2=80=9CSR Policy=E2=80=9D is valid no matter how many paths ended = up in the policy after the receiver consolidated all of them. And btw, just a detail, your description is a bit misleading: in BGP = also the segment list is weighted. Hope this helps. s. > On Oct 19, 2018, at 8:23 AM, Chengli (IP Technology Research) = wrote: >=20 > Hi authors, > =20 > I am working on updating drafts of path segment extensions in = BGP/BGP-LS: > =C2=B7 = https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distributi= on-00 > =C2=B7 = https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment-00 > =20 > But I found the inconsistency of SR policy structure. > =E2=80=A2 In = https://tools.ietf.org/html//draft-ietf-spring-segment-routing-policy-01, = the SR policy=E2=80=99s structure looks like: > =20 > SR policy POL1 > Candidate-path CP1 100:1.1.1.1, discriminator =3D 1> > Preference 200 > Weight W1, SID-List1 > Weight W2, SID-List2 > Candidate-path CP2 100:2.2.2.2, discriminator =3D 2> > Preference 100 > Weight W3, SID-List3 > Weight W4, SID-List4 > =20 > So the structure is :=20 > SR Policy > Candidate-path p1 > Weighted SID-list1 > Weighted SID-list2 > Candidate-path p2 > Weighted SID-list3 > Weighted SID-list4 > =20 > But in = https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04, = SR policy is described by following structure, > =20 > SR Policy SAFI NLRI: > Attributes: > Tunnel Encaps Attribute (23) > Tunnel Type: SR Policy > Binding SID > Preference > Priority > Policy Name > Explicit NULL Label Policy (ENLP) > Segment List > Weight > Segment > Segment > ... > ... > =20 > The structure is, > SR Policy > SID list1 > SID list2 > =20 > Where is the candidate-path? it seems like they are not aligned. > =20 > Thanks, > Cheng From nobody Thu Oct 18 23:52:44 2018 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 C8CC4130EA2; Thu, 18 Oct 2018 23:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 PX2vSnltc5_V; Thu, 18 Oct 2018 23:52:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177581277BB; Thu, 18 Oct 2018 23:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6094; q=dns/txt; s=iport; t=1539931920; x=1541141520; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dKu+NZrA3AHXSNWeY8OwF69wTotk6ilRcyj6G2tNU7o=; b=Mk0ejTQAwkMgh8ZP9Z5eD6NHpp4CNHTtgerwGYjNUdqEPs7aMAoPBHny XosxPqIehB4Ukl1xlFvqr0CiIESYqdTW1COKHaJys5B9xSpWs8dzx0S2Y gMXD74E0TPfbOE7HVYGsWZXctkG3U4oG5CmUXGrIERIXWbBWzZE1+z5mP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADPfslb/5JdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmfygKg2uIGI4ogz+TUIF6CwEBGA2?= =?us-ascii?q?EAUYCF4RsITQNDQEDAQECAQECbRwMhTkBAQEDAQEBIRE6CwUHBAIBCBEEAQE?= =?us-ascii?q?BAgImAgICJQsVCAgBAQQBDQUIgxqBeQgPplWBLoQwAoVuBYELikMXgUE/gRG?= =?us-ascii?q?DEoJKUQEBA4FlM4JJglcCjkSPdwkChluKBR+QKYxQiVECERSBJh04gVVwFTu?= =?us-ascii?q?CbIF/JxeIW4U+b4pagR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,399,1534809600"; d="scan'208";a="468705118" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 06:51:58 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w9J6pwrZ023288 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2018 06:51:58 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 19 Oct 2018 01:51:57 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Fri, 19 Oct 2018 01:51:57 -0500 From: "Ketan Talaulikar (ketant)" To: stefano previdi , "Chengli (IP Technology Research)" CC: "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG List , "draft-ietf-idr-segment-routing-te-policy@ietf.org" , Robin , "idr@ietf.org" Thread-Topic: [spring] Question: Inconsistency of SR policy structure Thread-Index: AdRndBziOl2h89Q1SVKtaryHB0wLpwALZmiAAApnEPA= Date: Fri, 19 Oct 2018 06:51:57 +0000 Message-ID: References: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> In-Reply-To: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> 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.65.95.111] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] Question: Inconsistency of SR policy structure X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 06:52:23 -0000 KzENCg0KVGhlIGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kgaGFzIHRo ZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWMgMSB0byBleHBsYWluIHRoaXMuDQoNCiAgIFdoaWxlIGZv ciBzaW1wbGljaXR5IHdlIG1heSB3cml0ZSB0aGF0IEJHUCBhZHZlcnRpc2VzIGFuIFNSIFBvbGlj eSwNCiAgIGl0IGhhcyB0byBiZSB1bmRlcnN0b29kIHRoYXQgQkdQIGFkdmVydGlzZXMgYSBjYW5k aWRhdGUgcGF0aCBvZiBhbiBTUg0KICAgcG9saWN5IGFuZCB0aGF0IHRoaXMgU1IgUG9saWN5IG1p Z2h0IGhhdmUgc2V2ZXJhbCBvdGhlciBjYW5kaWRhdGUNCiAgIHBhdGhzIHByb3ZpZGVkIHZpYSBC R1AgKHZpYSBhbiBOTFJJIHdpdGggYSBkaWZmZXJlbnQgZGlzdGluZ3Vpc2hlciBhcw0KICAgZGVm aW5lZCBpbiB0aGlzIGRvY3VtZW50KSwgUENFUCwgTkVUQ09ORiBvciBsb2NhbCBwb2xpY3kNCiAg IGNvbmZpZ3VyYXRpb24uDQoNClRoYW5rcywNCktldGFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2Ygc3RlZmFubyBwcmV2aWRpDQpTZW50OiAxOSBPY3RvYmVyIDIwMTggMTI6MTkNClRvOiBDaGVu Z2xpIChJUCBUZWNobm9sb2d5IFJlc2VhcmNoKSA8Y2hlbmdsaTEzQGh1YXdlaS5jb20+DQpDYzog ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeUBpZXRmLm9yZzsgU1BSSU5H IFdHIExpc3QgPHNwcmluZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGlu Zy10ZS1wb2xpY3lAaWV0Zi5vcmc7IFJvYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbT4NClN1Ympl Y3Q6IFJlOiBbc3ByaW5nXSBRdWVzdGlvbjogSW5jb25zaXN0ZW5jeSBvZiBTUiBwb2xpY3kgc3Ry dWN0dXJlDQoNCkhpIENoZW5nLA0KDQp0byBteSB1bmRlcnN0YW5kaW5nIHRoZSBkZWZpbml0aW9u IG9mIGFuIFNSIFBvbGljeSAoZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGlj eSkgaXMgY29ycmVjdC4NCg0KQW4gU1IgUG9saWN5IG1heSBpbmNsdWRlIGRpZmZlcmVudCBwYXRo cyBhbmQgZWFjaCBvZiB0aGVzZSBwYXRocyBtYXkgYmUgYWR2ZXJ0aXNlZCBpbiBhIGRpZmZlcmVu dCB3YXkgKEJHUCwgUENFUCwgc3RhdGljLCAuLi4pLg0KDQpCR1AgZXh0ZW5zaW9ucyBkZXNjcmli ZWQgaW4gZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeSBpcyBvbmUgb2Yg dGhlIHdheXMgcGF0aHMgb2YgYSBwb2xpY3kgbWF5IGJlIGFkdmVydGlzZWQuIA0KDQpJbiBvdGhl ciB3b3JkcywgdG8gbXkgdW5kZXJzdGFuZGluZyBhdCB0aGUgdGltZSB3ZSB3cm90ZSB0aGUgQkdQ IGV4dGVuc2lvbnMsIHRoZSBTUiBQb2xpY3kgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcG9saWN5IGlzIHRoZSBzZXQgb2YgYWxsIHBhdGhzIGluZGl2aWR1YWxs eSBhZHZlcnRpc2VkIGluIEJHUCwgUENFUCwgZXRjLg0KDQpJdCBtYXkgbG9va3MgbGlrZSBhIHRl cm1pbm9sb2d5IGlzc3VlIGJ1dCBpbiBmYWN0LCBJIGRvbuKAmXQgdGhpbmsgc28uIEV2ZW4gaWYg QkdQIChvciBQQ0VQKSBhZHZlcnRpc2VzIGEgcG9saWN5IHdpdGggYSBzaW5nbGUgcGF0aCwgaXQg aXMgc3RpbGwgYSB2YWxpZCBTUiBQb2xpY3kgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGFk dmVydGlzZXIuIFNvIHRoZSB0ZXJtIOKAnFNSIFBvbGljeeKAnSBpcyB2YWxpZCBubyBtYXR0ZXIg aG93IG1hbnkgcGF0aHMgZW5kZWQgdXAgaW4gdGhlIHBvbGljeSBhZnRlciB0aGUgcmVjZWl2ZXIg Y29uc29saWRhdGVkIGFsbCBvZiB0aGVtLg0KDQpBbmQgYnR3LCBqdXN0IGEgZGV0YWlsLCB5b3Vy IGRlc2NyaXB0aW9uIGlzIGEgYml0IG1pc2xlYWRpbmc6IGluIEJHUCBhbHNvIHRoZSBzZWdtZW50 IGxpc3QgaXMgd2VpZ2h0ZWQuDQoNCkhvcGUgdGhpcyBoZWxwcy4NCnMuDQoNCg0KPiBPbiBPY3Qg MTksIDIwMTgsIGF0IDg6MjMgQU0sIENoZW5nbGkgKElQIFRlY2hub2xvZ3kgUmVzZWFyY2gpIDxj aGVuZ2xpMTNAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBhdXRob3JzLA0KPiAgDQo+IEkg YW0gd29ya2luZyBvbiB1cGRhdGluZyBkcmFmdHMgb2YgcGF0aCBzZWdtZW50IGV4dGVuc2lvbnMg aW4gQkdQL0JHUC1MUzoNCj4gwrcgICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLXNlZ21lbnQtZGlzdHJpYnV0aW9uLTAwDQo+IMK3 ICAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWlkci1iZ3AtbHMt c3ItcG9saWN5LXBhdGgtc2VnbWVudC0wMA0KPiAgDQo+IEJ1dCBJIGZvdW5kIHRoZSBpbmNvbnNp c3RlbmN5IG9mIFNSIHBvbGljeSBzdHJ1Y3R1cmUuDQo+IAnigKIgSW4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sLy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTAx LCB0aGUgU1IgcG9saWN54oCZcyBzdHJ1Y3R1cmUgbG9va3MgbGlrZToNCj4gIA0KPiAgICAgICAg ICAgICBTUiBwb2xpY3kgUE9MMSA8aGVhZGVuZCwgY29sb3IsIGVuZHBvaW50Pg0KPiAgICAgICAg ICAgICAgIENhbmRpZGF0ZS1wYXRoIENQMSA8cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0 b3IgPQ0KPiAgICAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDE+DQo+ICAgICAgICAgICAg ICAgICBQcmVmZXJlbmNlIDIwMA0KPiAgICAgICAgICAgICAgICAgV2VpZ2h0IFcxLCBTSUQtTGlz dDEgPFNJRDExLi4uU0lEMWk+DQo+ICAgICAgICAgICAgICAgICBXZWlnaHQgVzIsIFNJRC1MaXN0 MiA8U0lEMjEuLi5TSUQyaj4NCj4gICAgICAgICAgICAgICBDYW5kaWRhdGUtcGF0aCBDUDIgPHBy b3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCj4gICAgMTAwOjIuMi4yLjIsIGRpc2Ny aW1pbmF0b3IgPSAyPg0KPiAgICAgICAgICAgICAgICAgUHJlZmVyZW5jZSAxMDANCj4gICAgICAg ICAgICAgICAgIFdlaWdodCBXMywgU0lELUxpc3QzIDxTSUQzMS4uLlNJRDNpPg0KPiAgICAgICAg ICAgICAgICAgV2VpZ2h0IFc0LCBTSUQtTGlzdDQgPFNJRDQxLi4uU0lENGo+DQo+ICANCj4gU28g dGhlIHN0cnVjdHVyZSBpcyA6IA0KPiBTUiBQb2xpY3kNCj4gICAgICAgICAgICAgICAgIENhbmRp ZGF0ZS1wYXRoIHAxDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2VpZ2h0ZWQg U0lELWxpc3QxDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2VpZ2h0ZWQgU0lE LWxpc3QyDQo+ICAgICAgICAgICAgICAgICBDYW5kaWRhdGUtcGF0aCBwMg0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRC1saXN0Mw0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRC1saXN0NA0KPiAgDQo+IEJ1dCBpbiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRl LXBvbGljeS0wNCwgU1IgcG9saWN5IGlzIGRlc2NyaWJlZCBieSBmb2xsb3dpbmcgc3RydWN0dXJl LA0KPiAgDQo+ICAgIFNSIFBvbGljeSBTQUZJIE5MUkk6IDxEaXN0aW5ndWlzaGVyLCBQb2xpY3kt Q29sb3IsIEVuZHBvaW50Pg0KPiAgICBBdHRyaWJ1dGVzOg0KPiAgICAgICBUdW5uZWwgRW5jYXBz IEF0dHJpYnV0ZSAoMjMpDQo+ICAgICAgICAgIFR1bm5lbCBUeXBlOiBTUiBQb2xpY3kNCj4gICAg ICAgICAgICAgIEJpbmRpbmcgU0lEDQo+ICAgICAgICAgICAgICBQcmVmZXJlbmNlDQo+ICAgICAg ICAgICAgICBQcmlvcml0eQ0KPiAgICAgICAgICAgICAgUG9saWN5IE5hbWUNCj4gICAgICAgICAg ICAgIEV4cGxpY2l0IE5VTEwgTGFiZWwgUG9saWN5IChFTkxQKQ0KPiAgICAgICAgICAgICAgU2Vn bWVudCBMaXN0DQo+ICAgICAgICAgICAgICAgICAgV2VpZ2h0DQo+ICAgICAgICAgICAgICAgICAg U2VnbWVudA0KPiAgICAgICAgICAgICAgICAgIFNlZ21lbnQNCj4gICAgICAgICAgICAgICAgICAu Li4NCj4gICAgICAgICAgICAgIC4uLg0KPiAgDQo+IFRoZSBzdHJ1Y3R1cmUgaXMsDQo+ICAgICAg ICAgICAgICAgICBTUiBQb2xpY3kNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT SUQgbGlzdDENCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTSUQgbGlzdDINCj4g IA0KPiBXaGVyZSBpcyB0aGUgY2FuZGlkYXRlLXBhdGg/ICBpdCBzZWVtcyBsaWtlIHRoZXkgYXJl IG5vdCBhbGlnbmVkLg0KPiAgDQo+IFRoYW5rcywNCj4gQ2hlbmcNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNw cmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJp bmcNCg== From nobody Fri Oct 19 00:00:33 2018 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 C65E3127AC2; Fri, 19 Oct 2018 00:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 U_Ry7I5wTGRf; Fri, 19 Oct 2018 00:00:29 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D44DD1277CC; Fri, 19 Oct 2018 00:00:28 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 90CAB245C0693; Fri, 19 Oct 2018 08:00:25 +0100 (IST) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 08:00:26 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0382.000; Fri, 19 Oct 2018 15:00:16 +0800 From: "Chengli (IP Technology Research)" To: stefano previdi CC: "draft-ietf-spring-segment-routing-policy@ietf.org" , "draft-ietf-idr-segment-routing-te-policy@ietf.org" , SPRING WG List , Lizhenbin Thread-Topic: Question: Inconsistency of SR policy structure Thread-Index: AdRndBziOl2h89Q1SVKtaryHB0wLp///gUWA//94a6A= Date: Fri, 19 Oct 2018 07:00:16 +0000 Message-ID: References: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> In-Reply-To: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Question: Inconsistency of SR policy structure X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 07:00:32 -0000 SGkgU3RlZmFubywgDQoNClBsZWFzZSBzZWUgbGluZS4NCg0KQ2hlbmcNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RlZmFubyBwcmV2aWRpIFttYWlsdG86c3RlZmFub0Bw cmV2aWRpLm5ldF0gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTksIDIwMTggMjo0OSBQTQ0KVG86 IENoZW5nbGkgKElQIFRlY2hub2xvZ3kgUmVzZWFyY2gpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4N CkNjOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5QGlldGYub3JnOyBk cmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5QGlldGYub3JnOyBTUFJJTkcg V0cgTGlzdCA8c3ByaW5nQGlldGYub3JnPjsgTGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNv bT4NClN1YmplY3Q6IFJlOiBRdWVzdGlvbjogSW5jb25zaXN0ZW5jeSBvZiBTUiBwb2xpY3kgc3Ry dWN0dXJlIA0KDQpIaSBDaGVuZywNCg0KdG8gbXkgdW5kZXJzdGFuZGluZyB0aGUgZGVmaW5pdGlv biBvZiBhbiBTUiBQb2xpY3kgKGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xp Y3kpIGlzIGNvcnJlY3QuDQpbQ2hlbmddICBBZ3JlZS4NCkFuIFNSIFBvbGljeSBtYXkgaW5jbHVk ZSBkaWZmZXJlbnQgcGF0aHMgYW5kIGVhY2ggb2YgdGhlc2UgcGF0aHMgbWF5IGJlIGFkdmVydGlz ZWQgaW4gYSBkaWZmZXJlbnQgd2F5IChCR1AsIFBDRVAsIHN0YXRpYywgLi4uKS4NCg0KQkdQIGV4 dGVuc2lvbnMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1w b2xpY3kgaXMgb25lIG9mIHRoZSB3YXlzIHBhdGhzIG9mIGEgcG9saWN5IG1heSBiZSBhZHZlcnRp c2VkLiANCg0KSW4gb3RoZXIgd29yZHMsIHRvIG15IHVuZGVyc3RhbmRpbmcgYXQgdGhlIHRpbWUg d2Ugd3JvdGUgdGhlIEJHUCBleHRlbnNpb25zLCB0aGUgU1IgUG9saWN5IGRlZmluZWQgaW4gZHJh ZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeSBpcyB0aGUgc2V0IG9mIGFsbCBw YXRocyBpbmRpdmlkdWFsbHkgYWR2ZXJ0aXNlZCBpbiBCR1AsIFBDRVAsIGV0Yy4NCltDaGVuZ10g QWdyZWUuDQoNCkl0IG1heSBsb29rcyBsaWtlIGEgdGVybWlub2xvZ3kgaXNzdWUgYnV0IGluIGZh Y3QsIEkgZG9u4oCZdCB0aGluayBzby4gRXZlbiBpZiBCR1AgKG9yIFBDRVApIGFkdmVydGlzZXMg YSBwb2xpY3kgd2l0aCBhIHNpbmdsZSBwYXRoLCBpdCBpcyBzdGlsbCBhIHZhbGlkIFNSIFBvbGlj eSBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgYWR2ZXJ0aXNlci4gU28gdGhlIHRlcm0g4oCc U1IgUG9saWN54oCdIGlzIHZhbGlkIG5vIG1hdHRlciBob3cgbWFueSBwYXRocyBlbmRlZCB1cCBp biB0aGUgcG9saWN5IGFmdGVyIHRoZSByZWNlaXZlciBjb25zb2xpZGF0ZWQgYWxsIG9mIHRoZW0u DQoNCg0KW0NoZW5nXSBBZ3JlZS4gQnV0IHRoZSBwcm9ibGVtIGlzLiANCkluIEJHUCBleHRlbnNp b25zLCBJIGFtIG5vdCBzdXJlIHRoZSB3aGVyZSBpcyB0aGUgY2FuZGlkYXRlIHBhdGguIEl0IHNl ZW1zIGxpa2UgU1IgaW5jbHVkZXMgbXVsdGlwbGUgU1IgcGF0aCBzcGVjaWZpZWQgYnkgU0lEIGxp c3RzLiANCkJ1dCBpbiBTUiBwb2xpY3kgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LCB0aGUgdXBwZXIg bGV2ZWwgb2YgU0lEIGxpc3QgaXMgdGhlIGNhbmRpZGF0ZSBwYXRoLiBUaGF0IG1ha2VzIG1lIGNv bmZ1c2VkLg0KDQoNCkFuZCBidHcsIGp1c3QgYSBkZXRhaWwsIHlvdXIgZGVzY3JpcHRpb24gaXMg YSBiaXQgbWlzbGVhZGluZzogaW4gQkdQIGFsc28gdGhlIHNlZ21lbnQgbGlzdCBpcyB3ZWlnaHRl ZC4NCltDaGVuZ10gWW91IGFyZSByaWdodC4gSXQgaXMgd2VpZ2h0ZWQuDQoNCg0KSG9wZSB0aGlz IGhlbHBzLg0Kcy4NCg0KDQo+IE9uIE9jdCAxOSwgMjAxOCwgYXQgODoyMyBBTSwgQ2hlbmdsaSAo SVAgVGVjaG5vbG9neSBSZXNlYXJjaCkgPGNoZW5nbGkxM0BodWF3ZWkuY29tPiB3cm90ZToNCj4g DQo+IEhpIGF1dGhvcnMsDQo+ICANCj4gSSBhbSB3b3JraW5nIG9uIHVwZGF0aW5nIGRyYWZ0cyBv ZiBwYXRoIHNlZ21lbnQgZXh0ZW5zaW9ucyBpbiBCR1AvQkdQLUxTOg0KPiDCtyAgICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtc2Vn bWVudC1kaXN0cmlidXRpb24tMDANCj4gwrcgICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbGktaWRyLWJncC1scy1zci1wb2xpY3ktcGF0aC1zZWdtZW50LTAwDQo+ICAN Cj4gQnV0IEkgZm91bmQgdGhlIGluY29uc2lzdGVuY3kgb2YgU1IgcG9saWN5IHN0cnVjdHVyZS4N Cj4gCeKAoiBJbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvL2RyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDEsIHRoZSBTUiBwb2xpY3nigJlzIHN0cnVjdHVyZSBs b29rcyBsaWtlOg0KPiAgDQo+ICAgICAgICAgICAgIFNSIHBvbGljeSBQT0wxIDxoZWFkZW5kLCBj b2xvciwgZW5kcG9pbnQ+DQo+ICAgICAgICAgICAgICAgQ2FuZGlkYXRlLXBhdGggQ1AxIDxwcm90 b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9DQo+ICAgIDEwMDoxLjEuMS4xLCBkaXNjcmlt aW5hdG9yID0gMT4NCj4gICAgICAgICAgICAgICAgIFByZWZlcmVuY2UgMjAwDQo+ICAgICAgICAg ICAgICAgICBXZWlnaHQgVzEsIFNJRC1MaXN0MSA8U0lEMTEuLi5TSUQxaT4NCj4gICAgICAgICAg ICAgICAgIFdlaWdodCBXMiwgU0lELUxpc3QyIDxTSUQyMS4uLlNJRDJqPg0KPiAgICAgICAgICAg ICAgIENhbmRpZGF0ZS1wYXRoIENQMiA8cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0b3Ig PQ0KPiAgICAxMDA6Mi4yLjIuMiwgZGlzY3JpbWluYXRvciA9IDI+DQo+ICAgICAgICAgICAgICAg ICBQcmVmZXJlbmNlIDEwMA0KPiAgICAgICAgICAgICAgICAgV2VpZ2h0IFczLCBTSUQtTGlzdDMg PFNJRDMxLi4uU0lEM2k+DQo+ICAgICAgICAgICAgICAgICBXZWlnaHQgVzQsIFNJRC1MaXN0NCA8 U0lENDEuLi5TSUQ0aj4NCj4gIA0KPiBTbyB0aGUgc3RydWN0dXJlIGlzIDogDQo+IFNSIFBvbGlj eQ0KPiAgICAgICAgICAgICAgICAgQ2FuZGlkYXRlLXBhdGggcDENCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBXZWlnaHRlZCBTSUQtbGlzdDENCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBXZWlnaHRlZCBTSUQtbGlzdDINCj4gICAgICAgICAgICAgICAgIENhbmRp ZGF0ZS1wYXRoIHAyDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2VpZ2h0ZWQg U0lELWxpc3QzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2VpZ2h0ZWQgU0lE LWxpc3Q0DQo+ICANCj4gQnV0IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5LTA0LCBTUiBwb2xpY3kgaXMgZGVzY3Jp YmVkIGJ5IGZvbGxvd2luZyBzdHJ1Y3R1cmUsDQo+ICANCj4gICAgU1IgUG9saWN5IFNBRkkgTkxS STogPERpc3Rpbmd1aXNoZXIsIFBvbGljeS1Db2xvciwgRW5kcG9pbnQ+DQo+ICAgIEF0dHJpYnV0 ZXM6DQo+ICAgICAgIFR1bm5lbCBFbmNhcHMgQXR0cmlidXRlICgyMykNCj4gICAgICAgICAgVHVu bmVsIFR5cGU6IFNSIFBvbGljeQ0KPiAgICAgICAgICAgICAgQmluZGluZyBTSUQNCj4gICAgICAg ICAgICAgIFByZWZlcmVuY2UNCj4gICAgICAgICAgICAgIFByaW9yaXR5DQo+ICAgICAgICAgICAg ICBQb2xpY3kgTmFtZQ0KPiAgICAgICAgICAgICAgRXhwbGljaXQgTlVMTCBMYWJlbCBQb2xpY3kg KEVOTFApDQo+ICAgICAgICAgICAgICBTZWdtZW50IExpc3QNCj4gICAgICAgICAgICAgICAgICBX ZWlnaHQNCj4gICAgICAgICAgICAgICAgICBTZWdtZW50DQo+ICAgICAgICAgICAgICAgICAgU2Vn bWVudA0KPiAgICAgICAgICAgICAgICAgIC4uLg0KPiAgICAgICAgICAgICAgLi4uDQo+ICANCj4g VGhlIHN0cnVjdHVyZSBpcywNCj4gICAgICAgICAgICAgICAgIFNSIFBvbGljeQ0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRCBsaXN0MQ0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRCBsaXN0Mg0KPiAgDQo+IFdoZXJlIGlz IHRoZSBjYW5kaWRhdGUtcGF0aD8gIGl0IHNlZW1zIGxpa2UgdGhleSBhcmUgbm90IGFsaWduZWQu DQo+ICANCj4gVGhhbmtzLA0KPiBDaGVuZw0KDQo= From nobody Fri Oct 19 00:06:05 2018 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 BCB87130DC9 for ; Fri, 19 Oct 2018 00:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.20150623.gappssmtp.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 Vf4DEEwjYU_h for ; Fri, 19 Oct 2018 00:06:00 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 809491277CC for ; Fri, 19 Oct 2018 00:06:00 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id o17-v6so1873424wmh.0 for ; Fri, 19 Oct 2018 00:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VoLGApt6NHNGJ4HKFSnRGQI393jj1n8c1+lj64KCBGI=; b=SDXmsbEJ2O7B+r1/F5poaik7ksRDXDTehWz3peBHcahqVFb5NpCihUhUKQHHHIJQkw K6j3CRBrmG6hVugqpEhH8ITWKWLeBA2AfP+dZDUWg732CdYHMQfug/GJSgQRsahbFShc o3KswTKhyYOgmHdfcIkX21sQnJxx5VAqg3Vb3zYjUyYqA9mFtcYvsD4PsnNKBpi0fEb+ ynI01sdBsXllhFez2xr1HUMKpA9kR+FpBT7BjIbLnNoZky3rs8O8KWfVjefL6G0CiXIj 4nrcB+qXbMh8YdQhG/tZ9FABb+2Jzbq+Cj+5IFSHoILNyY3YXpuQ9cQdGVOVyGKbg/nv HLgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VoLGApt6NHNGJ4HKFSnRGQI393jj1n8c1+lj64KCBGI=; b=o5HxauxprZoW2bIGpiMRBHNW4D0kMFQq+SSaAPL10fQd2f8ijh9b4dm5br1kty4Xoa /AKk7Dogn5t8dkXNSCplOkZepUB5ZRMlthSJxyzK0tOtYW5uxtJVjjLTNzb01XWQ0i8M 7nfNzZpcqPjwi0rFHO2G2BgJa735EpwjjLMQ3xs0PjqlS1h/6LtDKVGKz7N5ia0sx2HI 1Gol3Lj0SDQct5t4ndMFOcwvYI3givlWL8Mg3TGBrt3/7UGJPYJW6qlh51v5SHiq+HWS Ic1Kie+3T/jQkgPxSitgCL5kvrOcmFbiXy/CHOprgtM5qu7ap+KJJYnLiCoOra/RqGcf TiCw== X-Gm-Message-State: ABuFfogUlDk+bwVFXan4e+KraIXjejVD+vqDwTzl4Keao7K4JhJy8qIz c6ikTRQXTYZkBnaBROv4gXnHGw== X-Google-Smtp-Source: AJdET5fb7C0rJB3q2QgEUCNTnMvJx/xLShmm5ei/xdZo8ePiETiM2H2bCPQZHXesTVs9TQsFxFnbnw== X-Received: by 2002:a1c:ef05:: with SMTP id n5-v6mr3305663wmh.93.1539932758915; Fri, 19 Oct 2018 00:05:58 -0700 (PDT) Received: from [192.168.1.8] (net-2-39-131-107.cust.vodafonedsl.it. [2.39.131.107]) by smtp.gmail.com with ESMTPSA id s1-v6sm17088384wrw.35.2018.10.19.00.05.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Oct 2018 00:05:58 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: stefano previdi In-Reply-To: Date: Fri, 19 Oct 2018 09:05:55 +0200 Cc: "draft-ietf-spring-segment-routing-policy@ietf.org" , "draft-ietf-idr-segment-routing-te-policy@ietf.org" , SPRING WG List , Robin Content-Transfer-Encoding: quoted-printable Message-Id: References: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> To: "Chengli (IP Technology Research)" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [spring] Question: Inconsistency of SR policy structure X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 07:06:03 -0000 > On Oct 19, 2018, at 9:00 AM, Chengli (IP Technology Research) = wrote: >=20 > Hi Stefano,=20 >=20 > Please see line. >=20 > Cheng >=20 >=20 > -----Original Message----- > From: stefano previdi [mailto:stefano@previdi.net]=20 > Sent: Friday, October 19, 2018 2:49 PM > To: Chengli (IP Technology Research) > Cc: draft-ietf-spring-segment-routing-policy@ietf.org; = draft-ietf-idr-segment-routing-te-policy@ietf.org; SPRING WG List = ; Lizhenbin > Subject: Re: Question: Inconsistency of SR policy structure=20 >=20 > Hi Cheng, >=20 > to my understanding the definition of an SR Policy = (draft-ietf-spring-segment-routing-policy) is correct. > [Cheng] Agree. > An SR Policy may include different paths and each of these paths may = be advertised in a different way (BGP, PCEP, static, ...). >=20 > BGP extensions described in draft-ietf-idr-segment-routing-te-policy = is one of the ways paths of a policy may be advertised.=20 >=20 > In other words, to my understanding at the time we wrote the BGP = extensions, the SR Policy defined in = draft-ietf-spring-segment-routing-policy is the set of all paths = individually advertised in BGP, PCEP, etc. > [Cheng] Agree. >=20 > It may looks like a terminology issue but in fact, I don=E2=80=99t = think so. Even if BGP (or PCEP) advertises a policy with a single path, = it is still a valid SR Policy from the perspective of the advertiser. So = the term =E2=80=9CSR Policy=E2=80=9D is valid no matter how many paths = ended up in the policy after the receiver consolidated all of them. >=20 >=20 > [Cheng] Agree. But the problem is.=20 > In BGP extensions, I am not sure the where is the candidate path. It = seems like SR includes multiple SR path specified by SID lists.=20 > But in SR policy architecture document, the upper level of SID list is = the candidate path. That makes me confused. [Stefano] see section 1 of draft-ietf-spring-segment-routing-policy as pointed out = by Ketan. In BGP we do advertise a single path (that may have of course, multiple = weighted segment lists). The receiver will add the paths received through BGP (for a given = policy) and put them in the candidate path list for that policy with any = other path that it could have received through other protocols. thanks. s. >=20 >=20 > And btw, just a detail, your description is a bit misleading: in BGP = also the segment list is weighted. > [Cheng] You are right. It is weighted. >=20 >=20 > Hope this helps. > s. >=20 >=20 >> On Oct 19, 2018, at 8:23 AM, Chengli (IP Technology Research) = wrote: >>=20 >> Hi authors, >>=20 >> I am working on updating drafts of path segment extensions in = BGP/BGP-LS: >> =C2=B7 = https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distributi= on-00 >> =C2=B7 = https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment-00 >>=20 >> But I found the inconsistency of SR policy structure. >> =E2=80=A2 In = https://tools.ietf.org/html//draft-ietf-spring-segment-routing-policy-01, = the SR policy=E2=80=99s structure looks like: >>=20 >> SR policy POL1 >> Candidate-path CP1 > 100:1.1.1.1, discriminator =3D 1> >> Preference 200 >> Weight W1, SID-List1 >> Weight W2, SID-List2 >> Candidate-path CP2 > 100:2.2.2.2, discriminator =3D 2> >> Preference 100 >> Weight W3, SID-List3 >> Weight W4, SID-List4 >>=20 >> So the structure is :=20 >> SR Policy >> Candidate-path p1 >> Weighted SID-list1 >> Weighted SID-list2 >> Candidate-path p2 >> Weighted SID-list3 >> Weighted SID-list4 >>=20 >> But in = https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04, = SR policy is described by following structure, >>=20 >> SR Policy SAFI NLRI: >> Attributes: >> Tunnel Encaps Attribute (23) >> Tunnel Type: SR Policy >> Binding SID >> Preference >> Priority >> Policy Name >> Explicit NULL Label Policy (ENLP) >> Segment List >> Weight >> Segment >> Segment >> ... >> ... >>=20 >> The structure is, >> SR Policy >> Weighted SID list1 >> Weighted SID list2 >>=20 >> Where is the candidate-path? it seems like they are not aligned. >>=20 >> Thanks, >> Cheng >=20 From nobody Fri Oct 19 00:30:58 2018 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 8F52A127598; Fri, 19 Oct 2018 00:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 9MD-G4yww3pE; Fri, 19 Oct 2018 00:30:45 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 03F87126BED; Fri, 19 Oct 2018 00:30:45 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B8DF78D7A3E60; Fri, 19 Oct 2018 08:30:39 +0100 (IST) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 08:30:40 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0399.000; Fri, 19 Oct 2018 15:30:30 +0800 From: "Chengli (IP Technology Research)" To: "Ketan Talaulikar (ketant)" , stefano previdi CC: "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG List , "draft-ietf-idr-segment-routing-te-policy@ietf.org" , Lizhenbin , "idr@ietf.org" Thread-Topic: [spring] Question: Inconsistency of SR policy structure Thread-Index: AQHUZ3hGkijESARPnketDLRnPhFG5qUmKmMg Date: Fri, 19 Oct 2018 07:30:29 +0000 Message-ID: References: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Question: Inconsistency of SR policy structure X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 07:30:49 -0000 R2V0ISANCg0KU28gYWN0dWFsbHksIGluIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1wb2xpY3ksIGEgU1IgcG9saWN5IGlzIGlkZW50aWZpZWQgYnkgdGhlIHR1cGxlIDxoZWFkZW5k LCBjb2xvciwgZW5kcG9pbnQ+Lg0KDQpXaXRoaW4gYW4gU1IgcG9saWN5LCBhIGNhbmRpZGF0ZSBw YXRoIGhhcyBpdHMgZGlzdGluZ3Vpc2hlci4gU28gYSBDYW5kaWRhdGUgY2FuIGJlIGlkZW50aWZp ZWQgYnkgPGhlYWRlbmQsIGNvbG9yLCBlbmRwb2ludCwgZGlzdGluZ3Vpc2hlcj4uDQoNCkluIGRy YWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3ksIGFuIFNSIHBvbGljeShBY3R1 YWxseSwgaXQgaXMgYSBjYW5kaWRhdGUgcGF0aCBvZiBhbiBTUiBwb2xpY3kpIGNhbiBiZSBpZGVu dGlmaWVkIGJ5IDxEaXN0aW5ndWlzaGVyLCBQb2xpY3ktQ29sb3IsIEVuZHBvaW50PiAuDQpTaW5j ZSB0aGUgaGVhZGVkIGlzIHRoZSByZWNlaXZlciwgc28gbm8gbmVlZCB0byBiZSBhZGRlZCBpbiB0 aGUgdHVwbGUuIA0KDQpJdCBtYWtlcyBzZW5zZS4gR29vZCBkZXNpZ24hDQoNClRoYW5rcyBmb3Ig ZXhwbGFuYXRpb24uIA0KDQpDaGVuZw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIFttYWlsdG86a2V0YW50QGNpc2NvLmNvbV0g DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTksIDIwMTggMjo1MiBQTQ0KVG86IHN0ZWZhbm8gcHJl dmlkaSA8c3RlZmFub0BwcmV2aWRpLm5ldD47IENoZW5nbGkgKElQIFRlY2hub2xvZ3kgUmVzZWFy Y2gpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4NCkNjOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5QGlldGYub3JnOyBTUFJJTkcgV0cgTGlzdCA8c3ByaW5nQGlldGYub3Jn PjsgZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeUBpZXRmLm9yZzsgTGl6 aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbT47IGlkckBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFtzcHJpbmddIFF1ZXN0aW9uOiBJbmNvbnNpc3RlbmN5IG9mIFNSIHBvbGljeSBzdHJ1Y3R1cmUN Cg0KKzENCg0KVGhlIGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kgaGFz IHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWMgMSB0byBleHBsYWluIHRoaXMuDQoNCiAgIFdoaWxl IGZvciBzaW1wbGljaXR5IHdlIG1heSB3cml0ZSB0aGF0IEJHUCBhZHZlcnRpc2VzIGFuIFNSIFBv bGljeSwNCiAgIGl0IGhhcyB0byBiZSB1bmRlcnN0b29kIHRoYXQgQkdQIGFkdmVydGlzZXMgYSBj YW5kaWRhdGUgcGF0aCBvZiBhbiBTUg0KICAgcG9saWN5IGFuZCB0aGF0IHRoaXMgU1IgUG9saWN5 IG1pZ2h0IGhhdmUgc2V2ZXJhbCBvdGhlciBjYW5kaWRhdGUNCiAgIHBhdGhzIHByb3ZpZGVkIHZp YSBCR1AgKHZpYSBhbiBOTFJJIHdpdGggYSBkaWZmZXJlbnQgZGlzdGluZ3Vpc2hlciBhcw0KICAg ZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50KSwgUENFUCwgTkVUQ09ORiBvciBsb2NhbCBwb2xpY3kN CiAgIGNvbmZpZ3VyYXRpb24uDQoNClRoYW5rcywNCktldGFuDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2Ygc3RlZmFubyBwcmV2aWRpDQpTZW50OiAxOSBPY3RvYmVyIDIwMTggMTI6MTkNClRvOiBD aGVuZ2xpIChJUCBUZWNobm9sb2d5IFJlc2VhcmNoKSA8Y2hlbmdsaTEzQGh1YXdlaS5jb20+DQpD YzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeUBpZXRmLm9yZzsgU1BS SU5HIFdHIExpc3QgPHNwcmluZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91 dGluZy10ZS1wb2xpY3lAaWV0Zi5vcmc7IFJvYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbT4NClN1 YmplY3Q6IFJlOiBbc3ByaW5nXSBRdWVzdGlvbjogSW5jb25zaXN0ZW5jeSBvZiBTUiBwb2xpY3kg c3RydWN0dXJlDQoNCkhpIENoZW5nLA0KDQp0byBteSB1bmRlcnN0YW5kaW5nIHRoZSBkZWZpbml0 aW9uIG9mIGFuIFNSIFBvbGljeSAoZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeSkgaXMgY29ycmVjdC4NCg0KQW4gU1IgUG9saWN5IG1heSBpbmNsdWRlIGRpZmZlcmVudCBw YXRocyBhbmQgZWFjaCBvZiB0aGVzZSBwYXRocyBtYXkgYmUgYWR2ZXJ0aXNlZCBpbiBhIGRpZmZl cmVudCB3YXkgKEJHUCwgUENFUCwgc3RhdGljLCAuLi4pLg0KDQpCR1AgZXh0ZW5zaW9ucyBkZXNj cmliZWQgaW4gZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeSBpcyBvbmUg b2YgdGhlIHdheXMgcGF0aHMgb2YgYSBwb2xpY3kgbWF5IGJlIGFkdmVydGlzZWQuIA0KDQpJbiBv dGhlciB3b3JkcywgdG8gbXkgdW5kZXJzdGFuZGluZyBhdCB0aGUgdGltZSB3ZSB3cm90ZSB0aGUg QkdQIGV4dGVuc2lvbnMsIHRoZSBTUiBQb2xpY3kgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctcG9saWN5IGlzIHRoZSBzZXQgb2YgYWxsIHBhdGhzIGluZGl2aWR1 YWxseSBhZHZlcnRpc2VkIGluIEJHUCwgUENFUCwgZXRjLg0KDQpJdCBtYXkgbG9va3MgbGlrZSBh IHRlcm1pbm9sb2d5IGlzc3VlIGJ1dCBpbiBmYWN0LCBJIGRvbuKAmXQgdGhpbmsgc28uIEV2ZW4g aWYgQkdQIChvciBQQ0VQKSBhZHZlcnRpc2VzIGEgcG9saWN5IHdpdGggYSBzaW5nbGUgcGF0aCwg aXQgaXMgc3RpbGwgYSB2YWxpZCBTUiBQb2xpY3kgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhl IGFkdmVydGlzZXIuIFNvIHRoZSB0ZXJtIOKAnFNSIFBvbGljeeKAnSBpcyB2YWxpZCBubyBtYXR0 ZXIgaG93IG1hbnkgcGF0aHMgZW5kZWQgdXAgaW4gdGhlIHBvbGljeSBhZnRlciB0aGUgcmVjZWl2 ZXIgY29uc29saWRhdGVkIGFsbCBvZiB0aGVtLg0KDQpBbmQgYnR3LCBqdXN0IGEgZGV0YWlsLCB5 b3VyIGRlc2NyaXB0aW9uIGlzIGEgYml0IG1pc2xlYWRpbmc6IGluIEJHUCBhbHNvIHRoZSBzZWdt ZW50IGxpc3QgaXMgd2VpZ2h0ZWQuDQoNCkhvcGUgdGhpcyBoZWxwcy4NCnMuDQoNCg0KPiBPbiBP Y3QgMTksIDIwMTgsIGF0IDg6MjMgQU0sIENoZW5nbGkgKElQIFRlY2hub2xvZ3kgUmVzZWFyY2gp IDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBhdXRob3JzLA0KPiAgDQo+ IEkgYW0gd29ya2luZyBvbiB1cGRhdGluZyBkcmFmdHMgb2YgcGF0aCBzZWdtZW50IGV4dGVuc2lv bnMgaW4gQkdQL0JHUC1MUzoNCj4gwrcgICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLXNlZ21lbnQtZGlzdHJpYnV0aW9uLTAwDQo+ IMK3ICAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWlkci1iZ3At bHMtc3ItcG9saWN5LXBhdGgtc2VnbWVudC0wMA0KPiAgDQo+IEJ1dCBJIGZvdW5kIHRoZSBpbmNv bnNpc3RlbmN5IG9mIFNSIHBvbGljeSBzdHJ1Y3R1cmUuDQo+IAnigKIgSW4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sLy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5 LTAxLCB0aGUgU1IgcG9saWN54oCZcyBzdHJ1Y3R1cmUgbG9va3MgbGlrZToNCj4gIA0KPiAgICAg ICAgICAgICBTUiBwb2xpY3kgUE9MMSA8aGVhZGVuZCwgY29sb3IsIGVuZHBvaW50Pg0KPiAgICAg ICAgICAgICAgIENhbmRpZGF0ZS1wYXRoIENQMSA8cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdp bmF0b3IgPQ0KPiAgICAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDE+DQo+ICAgICAgICAg ICAgICAgICBQcmVmZXJlbmNlIDIwMA0KPiAgICAgICAgICAgICAgICAgV2VpZ2h0IFcxLCBTSUQt TGlzdDEgPFNJRDExLi4uU0lEMWk+DQo+ICAgICAgICAgICAgICAgICBXZWlnaHQgVzIsIFNJRC1M aXN0MiA8U0lEMjEuLi5TSUQyaj4NCj4gICAgICAgICAgICAgICBDYW5kaWRhdGUtcGF0aCBDUDIg PHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCj4gICAgMTAwOjIuMi4yLjIsIGRp c2NyaW1pbmF0b3IgPSAyPg0KPiAgICAgICAgICAgICAgICAgUHJlZmVyZW5jZSAxMDANCj4gICAg ICAgICAgICAgICAgIFdlaWdodCBXMywgU0lELUxpc3QzIDxTSUQzMS4uLlNJRDNpPg0KPiAgICAg ICAgICAgICAgICAgV2VpZ2h0IFc0LCBTSUQtTGlzdDQgPFNJRDQxLi4uU0lENGo+DQo+ICANCj4g U28gdGhlIHN0cnVjdHVyZSBpcyA6IA0KPiBTUiBQb2xpY3kNCj4gICAgICAgICAgICAgICAgIENh bmRpZGF0ZS1wYXRoIHAxDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2VpZ2h0 ZWQgU0lELWxpc3QxDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2VpZ2h0ZWQg U0lELWxpc3QyDQo+ICAgICAgICAgICAgICAgICBDYW5kaWRhdGUtcGF0aCBwMg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRC1saXN0Mw0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRC1saXN0NA0KPiAgDQo+IEJ1dCBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5n LXRlLXBvbGljeS0wNCwgU1IgcG9saWN5IGlzIGRlc2NyaWJlZCBieSBmb2xsb3dpbmcgc3RydWN0 dXJlLA0KPiAgDQo+ICAgIFNSIFBvbGljeSBTQUZJIE5MUkk6IDxEaXN0aW5ndWlzaGVyLCBQb2xp Y3ktQ29sb3IsIEVuZHBvaW50Pg0KPiAgICBBdHRyaWJ1dGVzOg0KPiAgICAgICBUdW5uZWwgRW5j YXBzIEF0dHJpYnV0ZSAoMjMpDQo+ICAgICAgICAgIFR1bm5lbCBUeXBlOiBTUiBQb2xpY3kNCj4g ICAgICAgICAgICAgIEJpbmRpbmcgU0lEDQo+ICAgICAgICAgICAgICBQcmVmZXJlbmNlDQo+ICAg ICAgICAgICAgICBQcmlvcml0eQ0KPiAgICAgICAgICAgICAgUG9saWN5IE5hbWUNCj4gICAgICAg ICAgICAgIEV4cGxpY2l0IE5VTEwgTGFiZWwgUG9saWN5IChFTkxQKQ0KPiAgICAgICAgICAgICAg U2VnbWVudCBMaXN0DQo+ICAgICAgICAgICAgICAgICAgV2VpZ2h0DQo+ICAgICAgICAgICAgICAg ICAgU2VnbWVudA0KPiAgICAgICAgICAgICAgICAgIFNlZ21lbnQNCj4gICAgICAgICAgICAgICAg ICAuLi4NCj4gICAgICAgICAgICAgIC4uLg0KPiAgDQo+IFRoZSBzdHJ1Y3R1cmUgaXMsDQo+ICAg ICAgICAgICAgICAgICBTUiBQb2xpY3kNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTSUQgbGlzdDENCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTSUQgbGlzdDIN Cj4gIA0KPiBXaGVyZSBpcyB0aGUgY2FuZGlkYXRlLXBhdGg/ICBpdCBzZWVtcyBsaWtlIHRoZXkg YXJlIG5vdCBhbGlnbmVkLg0KPiAgDQo+IFRoYW5rcywNCj4gQ2hlbmcNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QN CnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHJpbmcNCg== From nobody Fri Oct 19 00:32:25 2018 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 C0075127598; Fri, 19 Oct 2018 00:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 sxnw-sRT76Te; Fri, 19 Oct 2018 00:32:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0D6A3126BED; Fri, 19 Oct 2018 00:32:21 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8A625487DCDC8; Fri, 19 Oct 2018 08:32:14 +0100 (IST) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 08:32:15 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0399.000; Fri, 19 Oct 2018 15:32:07 +0800 From: "Chengli (IP Technology Research)" To: stefano previdi CC: "draft-ietf-spring-segment-routing-policy@ietf.org" , "draft-ietf-idr-segment-routing-te-policy@ietf.org" , SPRING WG List , Lizhenbin Thread-Topic: Question: Inconsistency of SR policy structure Thread-Index: AdRndBziOl2h89Q1SVKtaryHB0wLp///gUWA//94a6CAAIxVgP//csiQ Date: Fri, 19 Oct 2018 07:32:07 +0000 Message-ID: References: <088015A3-A85F-4086-ADEA-F06A02331740@previdi.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Question: Inconsistency of SR policy structure X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 07:32:24 -0000 SGkgU3RlZmFubywNCg0KWWVzLCB0aGFua3MgZm9yIHlvdXIgcmVwbHkuDQoNClJlZ2FyZHMsDQpD aGVuZw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHN0ZWZhbm8gcHJl dmlkaSBbbWFpbHRvOnN0ZWZhbm9AcHJldmlkaS5uZXRdIA0KU2VudDogRnJpZGF5LCBPY3RvYmVy IDE5LCAyMDE4IDM6MDYgUE0NClRvOiBDaGVuZ2xpIChJUCBUZWNobm9sb2d5IFJlc2VhcmNoKSA8 Y2hlbmdsaTEzQGh1YXdlaS5jb20+DQpDYzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLXBvbGljeUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBv bGljeUBpZXRmLm9yZzsgU1BSSU5HIFdHIExpc3QgPHNwcmluZ0BpZXRmLm9yZz47IExpemhlbmJp biA8bGl6aGVuYmluQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBSZTogUXVlc3Rpb246IEluY29uc2lz dGVuY3kgb2YgU1IgcG9saWN5IHN0cnVjdHVyZSANCg0KDQo+IE9uIE9jdCAxOSwgMjAxOCwgYXQg OTowMCBBTSwgQ2hlbmdsaSAoSVAgVGVjaG5vbG9neSBSZXNlYXJjaCkgPGNoZW5nbGkxM0BodWF3 ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIFN0ZWZhbm8sIA0KPiANCj4gUGxlYXNlIHNlZSBsaW5l Lg0KPiANCj4gQ2hlbmcNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBzdGVmYW5vIHByZXZpZGkgW21haWx0bzpzdGVmYW5vQHByZXZpZGkubmV0XSANCj4gU2Vu dDogRnJpZGF5LCBPY3RvYmVyIDE5LCAyMDE4IDI6NDkgUE0NCj4gVG86IENoZW5nbGkgKElQIFRl Y2hub2xvZ3kgUmVzZWFyY2gpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4NCj4gQ2M6IGRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3lAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRy LXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3lAaWV0Zi5vcmc7IFNQUklORyBXRyBMaXN0IDxzcHJp bmdAaWV0Zi5vcmc+OyBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPg0KPiBTdWJqZWN0 OiBSZTogUXVlc3Rpb246IEluY29uc2lzdGVuY3kgb2YgU1IgcG9saWN5IHN0cnVjdHVyZSANCj4g DQo+IEhpIENoZW5nLA0KPiANCj4gdG8gbXkgdW5kZXJzdGFuZGluZyB0aGUgZGVmaW5pdGlvbiBv ZiBhbiBTUiBQb2xpY3kgKGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kp IGlzIGNvcnJlY3QuDQo+IFtDaGVuZ10gIEFncmVlLg0KPiBBbiBTUiBQb2xpY3kgbWF5IGluY2x1 ZGUgZGlmZmVyZW50IHBhdGhzIGFuZCBlYWNoIG9mIHRoZXNlIHBhdGhzIG1heSBiZSBhZHZlcnRp c2VkIGluIGEgZGlmZmVyZW50IHdheSAoQkdQLCBQQ0VQLCBzdGF0aWMsIC4uLikuDQo+IA0KPiBC R1AgZXh0ZW5zaW9ucyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5n LXRlLXBvbGljeSBpcyBvbmUgb2YgdGhlIHdheXMgcGF0aHMgb2YgYSBwb2xpY3kgbWF5IGJlIGFk dmVydGlzZWQuIA0KPiANCj4gSW4gb3RoZXIgd29yZHMsIHRvIG15IHVuZGVyc3RhbmRpbmcgYXQg dGhlIHRpbWUgd2Ugd3JvdGUgdGhlIEJHUCBleHRlbnNpb25zLCB0aGUgU1IgUG9saWN5IGRlZmlu ZWQgaW4gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeSBpcyB0aGUgc2V0 IG9mIGFsbCBwYXRocyBpbmRpdmlkdWFsbHkgYWR2ZXJ0aXNlZCBpbiBCR1AsIFBDRVAsIGV0Yy4N Cj4gW0NoZW5nXSBBZ3JlZS4NCj4gDQo+IEl0IG1heSBsb29rcyBsaWtlIGEgdGVybWlub2xvZ3kg aXNzdWUgYnV0IGluIGZhY3QsIEkgZG9u4oCZdCB0aGluayBzby4gRXZlbiBpZiBCR1AgKG9yIFBD RVApIGFkdmVydGlzZXMgYSBwb2xpY3kgd2l0aCBhIHNpbmdsZSBwYXRoLCBpdCBpcyBzdGlsbCBh IHZhbGlkIFNSIFBvbGljeSBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgYWR2ZXJ0aXNlci4g U28gdGhlIHRlcm0g4oCcU1IgUG9saWN54oCdIGlzIHZhbGlkIG5vIG1hdHRlciBob3cgbWFueSBw YXRocyBlbmRlZCB1cCBpbiB0aGUgcG9saWN5IGFmdGVyIHRoZSByZWNlaXZlciBjb25zb2xpZGF0 ZWQgYWxsIG9mIHRoZW0uDQo+IA0KPiANCj4gW0NoZW5nXSBBZ3JlZS4gQnV0IHRoZSBwcm9ibGVt IGlzLiANCj4gSW4gQkdQIGV4dGVuc2lvbnMsIEkgYW0gbm90IHN1cmUgdGhlIHdoZXJlIGlzIHRo ZSBjYW5kaWRhdGUgcGF0aC4gSXQgc2VlbXMgbGlrZSBTUiBpbmNsdWRlcyBtdWx0aXBsZSBTUiBw YXRoIHNwZWNpZmllZCBieSBTSUQgbGlzdHMuIA0KPiBCdXQgaW4gU1IgcG9saWN5IGFyY2hpdGVj dHVyZSBkb2N1bWVudCwgdGhlIHVwcGVyIGxldmVsIG9mIFNJRCBsaXN0IGlzIHRoZSBjYW5kaWRh dGUgcGF0aC4gVGhhdCBtYWtlcyBtZSBjb25mdXNlZC4NCg0KDQpbU3RlZmFub10NCnNlZSBzZWN0 aW9uIDEgb2YgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeSBhcyBwb2lu dGVkIG91dCBieSBLZXRhbi4NCkluIEJHUCB3ZSBkbyBhZHZlcnRpc2UgYSBzaW5nbGUgcGF0aCAo dGhhdCBtYXkgaGF2ZSBvZiBjb3Vyc2UsIG11bHRpcGxlIHdlaWdodGVkIHNlZ21lbnQgbGlzdHMp Lg0KDQpUaGUgcmVjZWl2ZXIgd2lsbCBhZGQgdGhlIHBhdGhzIHJlY2VpdmVkIHRocm91Z2ggQkdQ IChmb3IgYSBnaXZlbiBwb2xpY3kpIGFuZCBwdXQgdGhlbSBpbiB0aGUgY2FuZGlkYXRlIHBhdGgg bGlzdCBmb3IgdGhhdCBwb2xpY3kgd2l0aCBhbnkgb3RoZXIgcGF0aCB0aGF0IGl0IGNvdWxkIGhh dmUgcmVjZWl2ZWQgdGhyb3VnaCBvdGhlciBwcm90b2NvbHMuDQoNCnRoYW5rcy4NCnMuDQoNCg0K DQo+IA0KPiANCj4gQW5kIGJ0dywganVzdCBhIGRldGFpbCwgeW91ciBkZXNjcmlwdGlvbiBpcyBh IGJpdCBtaXNsZWFkaW5nOiBpbiBCR1AgYWxzbyB0aGUgc2VnbWVudCBsaXN0IGlzIHdlaWdodGVk Lg0KPiBbQ2hlbmddIFlvdSBhcmUgcmlnaHQuIEl0IGlzIHdlaWdodGVkLg0KPiANCj4gDQo+IEhv cGUgdGhpcyBoZWxwcy4NCj4gcy4NCj4gDQo+IA0KPj4gT24gT2N0IDE5LCAyMDE4LCBhdCA4OjIz IEFNLCBDaGVuZ2xpIChJUCBUZWNobm9sb2d5IFJlc2VhcmNoKSA8Y2hlbmdsaTEzQGh1YXdlaS5j b20+IHdyb3RlOg0KPj4gDQo+PiBIaSBhdXRob3JzLA0KPj4gDQo+PiBJIGFtIHdvcmtpbmcgb24g dXBkYXRpbmcgZHJhZnRzIG9mIHBhdGggc2VnbWVudCBleHRlbnNpb25zIGluIEJHUC9CR1AtTFM6 DQo+PiDCtyAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1pZHIt c3ItcG9saWN5LXBhdGgtc2VnbWVudC1kaXN0cmlidXRpb24tMDANCj4+IMK3ICAgICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWlkci1iZ3AtbHMtc3ItcG9saWN5LXBh dGgtc2VnbWVudC0wMA0KPj4gDQo+PiBCdXQgSSBmb3VuZCB0aGUgaW5jb25zaXN0ZW5jeSBvZiBT UiBwb2xpY3kgc3RydWN0dXJlLg0KPj4gCeKAoiBJbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDEsIHRoZSBTUiBw b2xpY3nigJlzIHN0cnVjdHVyZSBsb29rcyBsaWtlOg0KPj4gDQo+PiAgICAgICAgICAgIFNSIHBv bGljeSBQT0wxIDxoZWFkZW5kLCBjb2xvciwgZW5kcG9pbnQ+DQo+PiAgICAgICAgICAgICAgQ2Fu ZGlkYXRlLXBhdGggQ1AxIDxwcm90b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9DQo+PiAg IDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMT4NCj4+ICAgICAgICAgICAgICAgIFByZWZl cmVuY2UgMjAwDQo+PiAgICAgICAgICAgICAgICBXZWlnaHQgVzEsIFNJRC1MaXN0MSA8U0lEMTEu Li5TSUQxaT4NCj4+ICAgICAgICAgICAgICAgIFdlaWdodCBXMiwgU0lELUxpc3QyIDxTSUQyMS4u LlNJRDJqPg0KPj4gICAgICAgICAgICAgIENhbmRpZGF0ZS1wYXRoIENQMiA8cHJvdG9jb2wtb3Jp Z2luID0gMjAsIG9yaWdpbmF0b3IgPQ0KPj4gICAxMDA6Mi4yLjIuMiwgZGlzY3JpbWluYXRvciA9 IDI+DQo+PiAgICAgICAgICAgICAgICBQcmVmZXJlbmNlIDEwMA0KPj4gICAgICAgICAgICAgICAg V2VpZ2h0IFczLCBTSUQtTGlzdDMgPFNJRDMxLi4uU0lEM2k+DQo+PiAgICAgICAgICAgICAgICBX ZWlnaHQgVzQsIFNJRC1MaXN0NCA8U0lENDEuLi5TSUQ0aj4NCj4+IA0KPj4gU28gdGhlIHN0cnVj dHVyZSBpcyA6IA0KPj4gU1IgUG9saWN5DQo+PiAgICAgICAgICAgICAgICBDYW5kaWRhdGUtcGF0 aCBwMQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRC1saXN0 MQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdlaWdodGVkIFNJRC1saXN0Mg0K Pj4gICAgICAgICAgICAgICAgQ2FuZGlkYXRlLXBhdGggcDINCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBXZWlnaHRlZCBTSUQtbGlzdDMNCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBXZWlnaHRlZCBTSUQtbGlzdDQNCj4+IA0KPj4gQnV0IGluIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5 LTA0LCBTUiBwb2xpY3kgaXMgZGVzY3JpYmVkIGJ5IGZvbGxvd2luZyBzdHJ1Y3R1cmUsDQo+PiAN Cj4+ICAgU1IgUG9saWN5IFNBRkkgTkxSSTogPERpc3Rpbmd1aXNoZXIsIFBvbGljeS1Db2xvciwg RW5kcG9pbnQ+DQo+PiAgIEF0dHJpYnV0ZXM6DQo+PiAgICAgIFR1bm5lbCBFbmNhcHMgQXR0cmli dXRlICgyMykNCj4+ICAgICAgICAgVHVubmVsIFR5cGU6IFNSIFBvbGljeQ0KPj4gICAgICAgICAg ICAgQmluZGluZyBTSUQNCj4+ICAgICAgICAgICAgIFByZWZlcmVuY2UNCj4+ICAgICAgICAgICAg IFByaW9yaXR5DQo+PiAgICAgICAgICAgICBQb2xpY3kgTmFtZQ0KPj4gICAgICAgICAgICAgRXhw bGljaXQgTlVMTCBMYWJlbCBQb2xpY3kgKEVOTFApDQo+PiAgICAgICAgICAgICBTZWdtZW50IExp c3QNCj4+ICAgICAgICAgICAgICAgICBXZWlnaHQNCj4+ICAgICAgICAgICAgICAgICBTZWdtZW50 DQo+PiAgICAgICAgICAgICAgICAgU2VnbWVudA0KPj4gICAgICAgICAgICAgICAgIC4uLg0KPj4g ICAgICAgICAgICAgLi4uDQo+PiANCj4+IFRoZSBzdHJ1Y3R1cmUgaXMsDQo+PiAgICAgICAgICAg ICAgICBTUiBQb2xpY3kNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXZWlnaHRl ZCBTSUQgbGlzdDENCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXZWlnaHRlZCBT SUQgbGlzdDINCj4+IA0KPj4gV2hlcmUgaXMgdGhlIGNhbmRpZGF0ZS1wYXRoPyAgaXQgc2VlbXMg bGlrZSB0aGV5IGFyZSBub3QgYWxpZ25lZC4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gQ2hlbmcNCj4g DQoNCg== From nobody Fri Oct 19 12:03:41 2018 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 D4FD7131027; Fri, 19 Oct 2018 11:56:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spring@ietf.org, martin.vigoureux@nokia.com X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997540086.6592.3035481570894339846.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:40 -0700 Archived-At: Subject: [spring] spring - Requested session has been scheduled for IETF 103 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:49 -0000 Dear Bruno Decraene, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. spring Session 1 (2:00 requested) Wednesday, 7 November 2018, Morning Session I 0900-1100 Room Name: Chitlada 2 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/spring.ics Request Information: --------------------------------------------------------- Working Group Name: Source Packet Routing in Networking Area Name: Routing Area Session Requester: Bruno Decraene Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 180 Conflicts to Avoid: First Priority: mpls 6man lsr teas Second Priority: idr rtgarea rtgwg pce sfc detnet People who must be present: Bruno Decraene Martin Vigoureux Rob Shakir Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Oct 21 22:48:28 2018 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 8AFFB130E03 for ; Sun, 21 Oct 2018 22:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 RrqmwBTOFx66 for ; Sun, 21 Oct 2018 22:48:22 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E77A130DC0 for ; Sun, 21 Oct 2018 22:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43294; q=dns/txt; s=iport; t=1540187302; x=1541396902; h=from:to:subject:date:message-id:references:mime-version; bh=1uF+jeTx0ovF9reo9t8/o5/jDz7EOYGqDZM5ZLhxIHI=; b=V0c6KRnjf3+E1O5JmBw7AEP/q0LLa4fgDE1hK7Ld25KhMsmw86aTfgQa foBpVeXL7sfyBCOVyZdF1H8SVHEuUcCG20tOI9ARYnmVZURJWCT7C4QsR soBW5C/W+a/bqfJwNR2CQvYTmVQv7w+KxGENJQ2AjSfvwzAZZPa//z00l E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAA1ZM1b/4YNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDXdmfygKg2uIGIwYgg2XFYF6CwEBJYRHAhe?= =?us-ascii?q?EdyE0DQ0BAwEBAgEBAm0cDIU6AQEFIwpcAgEIEQEDAQEhAQYDAgICMBQDBgg?= =?us-ascii?q?CBAESCBODB4EdZA+jeIEuhDAChVsFi1IXgUE/gRABgxKDGwEBAgGCBBCCTYJ?= =?us-ascii?q?XAohchVmPQAVOCQKGYIoIH4FShHOJaYklgzOJXgIRFIEmHTiBVXAVO4JsgiY?= =?us-ascii?q?XiFyFPm8BilmBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,410,1534809600"; d="scan'208,217";a="188927739" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 05:48:21 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9M5mKDo008122 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Oct 2018 05:48:20 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 00:48:20 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Mon, 22 Oct 2018 00:48:20 -0500 From: "Ketan Talaulikar (ketant)" To: Rob Shakir , SPRING WG List , "draft-filsfils-spring-sr-policy-considerations@tools.ietf.org" Thread-Topic: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01 Thread-Index: AQHUJC8gIgkUpf/WTkeLttnG75TNTqUmVw4QgAT16eA= Date: Mon, 22 Oct 2018 05:48:20 +0000 Message-ID: <0ebeaafcd19e4c8c8c08b05520051186@XCH-ALN-008.cisco.com> References: 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.41.46] Content-Type: multipart/alternative; boundary="_000_0ebeaafcd19e4c8c8c08b05520051186XCHALN008ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 05:48:27 -0000 --_000_0ebeaafcd19e4c8c8c08b05520051186XCHALN008ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxsLA0KDQpWZXJzaW9uIDIgb2YgdGhlIGRyYWZ0IGhhcyBiZWVuIHN1Ym1pdHRlZCB0 aGF0IGluY29ycG9yYXRlcyB1cGRhdGVzIHRvIGFkZHJlc3MgY29tbWVudHMgZnJvbSBSb2IgYW5k IGEgZmV3IG90aGVyIGVkaXRvcmlhbCBuaXRzLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXBvbGljeS1jb25zaWRlcmF0aW9ucy0wMg0KDQpU aGFua3MsDQpLZXRhbg0KDQpGcm9tOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpDQpTZW50OiAx OSBPY3RvYmVyIDIwMTggMDc6NDANClRvOiAnUm9iIFNoYWtpcicgPHJvYmpzPTQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZz47IFNQUklORyBXRyBMaXN0IDxzcHJpbmdAaWV0Zi5vcmc+OyBkcmFm dC1maWxzZmlscy1zcHJpbmctc3ItcG9saWN5LWNvbnNpZGVyYXRpb25zQHRvb2xzLmlldGYub3Jn DQpTdWJqZWN0OiBSRTogW3NwcmluZ10gQ29tbWVudHMgb24gZHJhZnQtZmlsc2ZpbHMtc3ByaW5n LXNyLXBvbGljeS1jb25zaWRlcmF0aW9ucy0wMQ0KDQpIaSBSb2IsDQoNClRoYW5rcyBmb3IgeW91 ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVhc2UgZmluZCBpbmxpbmUgYmVsb3cgb3VyIHJlc3Bv bnNlcy4NCg0KV2lsbCB3b3JrIG9uIHBvc3RpbmcgYW4gdXBkYXRlIHRvIHRoZSBkcmFmdCB0byBp bmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRzLg0KDQpUaGFua3MsDQpLZXRhbg0KDQpGcm9tOiBzcHJp bmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y Zz4+IE9uIEJlaGFsZiBPZiBSb2IgU2hha2lyDQpTZW50OiAyNSBKdWx5IDIwMTggMjE6MTkNClRv OiBTUFJJTkcgV0cgTGlzdCA8c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ PjsgZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXBvbGljeS1jb25zaWRlcmF0aW9uc0B0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXBvbGljeS1jb25zaWRlcmF0 aW9uc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJpbmddIENvbW1lbnRzIG9uIGRyYWZ0 LWZpbHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lkZXJhdGlvbnMtMDENCg0KKEFzIGFuIGlu ZGl2aWR1YWwgY29udHJpYnV0b3IpDQoNCkhpIEF1dGhvcnMsDQoNClBlciBteSBjb21tZW50cyBp biBTUFJJTkcgYXQgSUVURiAxMDIsIEkgaGF2ZSBhIG51bWJlciBvZiBjb21tZW50cy9jb25jZXJu cyBhYm91dCB0aGUgY29udGVudHMgb2YgdGhpcyBkb2N1bWVudC4gUGxlYXNlIGZpbmQgdGhlbSBi ZWxvdy4gSSBsb29rIGZvcndhcmQgdG8gZGlzY3Vzc2luZyB0aGVtIGluIG1vcmUgZGV0YWlsLi4N Cg0KICAqICAgKDIpIFdoYXQgaXMgdGhlIGludGVudGlvbiBvZiB0aGUgZGlhZ3JhbSBzaG93biBp biB0aGlzIHNlY3Rpb24/IEl0IHNlZW1zIHRvIGJlIGNvbXBsZXRlbHkgYW4gaW1wbGVtZW50YXRp b24gZGV0YWlsIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaGFzIHRoZSAiU1JQTSIgdGhhdCBhY3Rz IGFzIGEgY2VudHJhbCByZXNvbHV0aW9uIHBvaW50LiBGb3IgaW5zdGFuY2UsIHdoYXQgc2hvdWxk IGEgcmVhZGVyIGxlYXJuIGZyb20gdGhlIGZhY3QgdGhhdCB0aGUgU1JQTSBpcyBub3QgYSBzdGFu ZGFyZCBSSUIgcmVzb2x1dGlvbiBwcm9jZXNzPyBJZiB0aGVyZSBhcmUgc3VnZ2VzdGlvbnMgdGhh dCBvbmUgd2FudHMgdGhpcyBpbXBsZW1lbnRhdGlvbiAtIHNob3VsZCB0aGVyZSBiZSBzb21lIGRp c2N1c3Npb24gb2YgdGhlIGNvbXBsZXhpdHkgb2YgdGhpcyBuZXcgQVBJIGJldHdlZW4gc2F5LCB0 aGUgQkdQIGRhZW1vbiBhbmQgYSBnZW5lcmFsIFJJQiBwcm9jZXNzPw0KW0tUXSBXZSB3aWxsIGNs YXJpZnkgaW4gdGhlIHRleHQgdGhhdCB0aGUgc2VjdGlvbiBwcm92aWRlcyBhIGNvbmNlcHR1YWwg b3ZlcnZpZXcgb2YgY29tcG9uZW50cy9mdW5jdGlvbmFsaXR5IHRoYXQgd29yayB3aXRoIGVhY2gg b3RoZXIgdG8gaW1wbGVtZW50IFNSIFBvbGljeSBvbiBhIGhlYWRlbmQuIFRoZSBpbnRlbnRpb24g aXMgbm90IHRvIGRlZmluZSBBUElzIGJldHdlZW4gdGhlIGJsb2NrcyBzaW5jZSB0aG9zZSBhcmUg aW1wbGVtZW50YXRpb24gZGV0YWlscy4gV2UgaGF2ZSBzZXZlcmFsIGRyYWZ0cyByZWxhdGVkIHRv IHRoZSBTUiBQb2xpY3kgZnVuY3Rpb25hbGl0eSDigJMgYmVzaWRlcyB0aGUgYXJjaGl0ZWN0dXJl IGRyYWZ0LCB0aGVyZSBhcmUgZXh0ZW5zaW9ucyB0byBCR1AgKEJHUC1TUlRFICYgTFMpLCBQQ0VQ IHRoZW4gd2UgaGF2ZSBZYW5nIG1vZGVsLiBUaGlzIGRyYWZ0IHB1dHMgdGhlc2UgYmxvY2tzIGlu dG8gcmVmZXJlbmNlIHNvIGltcGxlbWVudGVycyBnZXQgYW4gaWRlYSBvZiB0aGUgZnVuY3Rpb25h bGl0eSB0aGF0IG1hcHMgdG8gc2F5IEJHUCBhbmQgdGhlIFNSIFBvbGljeSBwcm9jZXNzZXMgKGUu Zy4gZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeSkuDQoNCiAgKiAgICgy KSBNeSBnZW5lcmFsIGZlZWRiYWNrIG9uIHRoaXMgc2VjdGlvbiBpcyB0aGF0IHRoaXMgaXMgaW1w bGVtZW50YXRpb24gZGlzY3Vzc2lvbiwgdGhhdCBkb2VzIG5vdCBhZGQgdG8gdGhlIElFVEYgY29u dGVudCB0aGF0IHdlIGFyZSBwdWJsaXNoaW5nIHdpdGhpbiBTUFJJTkcuIExpa2Ugd2UgaGF2ZSBo YWQgZGlzY3Vzc2lvbiBvZiB1c2UgY2FzZSBkcmFmdHMsIEkgdGhpbmsgdGhpcyBpcyBzaW1pbGFy IGJ1dCBmcm9tIHRoZSBpbXBsZW1lbnRvciBzaWRlLiBJJ2QgbGlrZSB0byBkaXNjdXNzIHRoZSB2 YWx1ZSB0aGF0IHRoaXMgY29udGVudCBoYXMuDQpbS1RdIFRoZXJlIGlzIGEgZGlmZmVyZW5jZSBi ZXR3ZWVuIGRvY3VtZW50aW5nIGltcGxlbWVudGF0aW9uIGRldGFpbHMgYW5kIHByb3ZpZGluZyBh IGNvbmNlcHR1YWwgb3ZlcnZpZXcgb2YgdGhlIGltcGxlbWVudGF0aW9uIGFzcGVjdHMuIEVzcGVj aWFsbHkgd2hlbiBkZWZpbmluZyBhbiBhcmNoaXRlY3R1cmUgd2hpY2ggaW52b2x2ZXMgbXVsdGlw bGUgcHJvdG9jb2xzIGFuZCBmdW5jdGlvbmFsIGJsb2Nrcy4gSSBmaW5kIGl0IHZhbHVhYmxlIGFz IGFuIGltcGxlbWVudGVyIG15c2VsZi4NCg0KICAqICAgKDMuMSkgSSB0aGluayB0aGF0IHRoaXMg c2VjdGlvbiBoYXMgc29tZSB1c2VmdWwgY29udGVudCwgYnV0IGl0J3MgYnVyaWVkIGJ5IHN0YXJ0 aW5nIG91dCBieSBkZWZpbmluZyB0aGUgYWxnb3JpdGhtcy4uIFdoeSBub3QgbWFrZSB0aGlzIHNl Y3Rpb24gYmUgZm9jdXNlZCB0b3dhcmRzIHRoZSBjb25zdHJhaW50cyB0aGF0IG11c3QgYmUgY29u c2lkZXJlZCB3aGVuIGNhbGN1bGF0aW5nIGEgU0lEIHN0YWNrIGZvciBhIHBhcnRpY3VsYXIgcGF0 aC4gaS5lLiwgdGhlIGtleSBwb2ludHMgc2VlbSB0byBiZToNCg0KICAgICAqICAgVXNlIG9mIHRo ZSBJR1AgbWV0cmljIGFzIHRoZSBtZXRyaWMgZm9yIHBhdGggb3B0aW1pc2F0aW9uIGlzIGRlc2ly YWJsZSwgZXNwZWNpYWxseSBpbiBjb25zdHJhaW5lZCBwdXNoIG9yIHJlYWRhYmxlIGRlcHRoIGVu dmlyb25tZW50cywgYmVjYXVzZSBpdCBhbGxvd3MgdGhlIG1pbmltdW0gbnVtYmVyIG9mIGRldmlh dGlvbnMgZnJvbSB0aGUgc2hvcnRlc3QgcGF0aCBhbmQgdGhlcmVmb3JlIGxhYmVscy4NCiAgICAg KiAgIElmIGEgZGlmZmVyZW50IG1ldHJpYyBpcyB1c2VkLCB0aGVuIHRoaXMgaW1wbGllcyB0aGF0 IGV2ZXJ5IHRpbWUgdGhhdCBtZXRyaWMgZGlmZmVycyBmcm9tIHRoZSBJR1AgbWV0cmljLCB0aGVu IHRoaXMgd2lsbCByZXN1bHQgaW4gYWRkaXRpb25hbCBTSURzLg0KDQogICAgICAgICogICBUaGVy ZSBpcyBubyBtZW50aW9uIG9mIGZsZXgtYWxnb3JpdGhtIGluIHRoaXMgc2VjdGlvbi4gSXQgc2Vl bXMgcmVsZXZhbnQgZ2l2ZW4gdGhhdCB5b3UgY2FuIGFsc28gbWl0aWdhdGUgdGhlIHByb2JsZW0g dGhhdCBpcyB0cnlpbmcgdG8gYmUgc29sdmVkIGhlcmUgYnkgaGF2aW5nIGEgc2V0IG9mIHByZWZp eCBTSURzIHBlciBtZXRyaWMuDQpbS1RdIFdlIHdpbGwgcHV0IGEgZm9yd2FyZCByZWZlcmVuY2Ug dG8gdGhlIEZsZXggQWxnbyBzZWN0aW9uIGhlcmUuDQoNCiAgICAgKiAgIEl0IG1heSBiZSBhZHZh bnRhZ2VvdXMgdG8gc2FjcmlmaWNlIG9wdGltYWxpdHkgb2YgdGhlIHBhdGggY2FsY3VsYXRpb24g c29sdXRpb24gYnkgcmVsYXhpbmcgdGhlIG9wdGltaXNhdGlvbiBjb25zdHJhaW50cy4NCg0KICAg ICAgICAqICAgVGhlIGRyYWZ0IHNob3VsZCB0YWxrIGFib3V0IHRoZSBvcGVyYXRpb25hbCBjb25z aWRlcmF0aW9ucyBoZXJlIC0gaS5lLiwgaXQgaW1wbGllcyB0aGF0IHlvdSBjYW4gYWN0dWFsbHkg dG9sZXJhdGUgdGhlIG1hcmdpbiBpbiB0aGUgb3B0aW1pc2F0aW9uIG9iamVjdGl2ZSBmb3IgdGhl IHNlcnZpY2UuDQogICAgICAgICogICBUaGUgImp1c3QgcGljayB0aGUgYmVzdCB5b3UgY2FuIGRv IHdpdGhpbiBOIFNJRHMiIGlzIGRhbmdlcm91cywgc2luY2UgaXQgbWVhbnMgdGhhdCB0aGUgbmV0 d29yayBkZWxpdmVycyBhIHNlcnZpY2UgdGhhdCAqaXNuJ3QqIHdoYXQgdGhlIG9wZXJhdG9yIGFz a2VkIGZvciAtIHdoaWNoIG1heSByZXN1bHQgaW4gc2VydmljZSBkZWdyYWRhdGlvbiAoZS5nLiwg Y29uc2lkZXIgbGl2ZS9saXZlIHdoZXJlIHRoZXJlIGlzIGEgbWF4aW11bSBsYXRlbmN5IGRpZmZl cmVuY2UgdGhhdCBpcyB0b2xlcmFibGUgYmV0d2VlbiB0aGUgdHdvIGZlZWRzKS4NCltLVF0gV2Ug d2lsbCBhZGQgdGV4dCBjbGFyaWZ5aW5nIHRoaXMgYXNwZWN0LiBIb3dldmVyLCB0aGUgcG9pbnQg aXMgYWxzbyB0aGF0IHRoZSBvcGVyYXRvciBtYXkgYmUgT0sgd2l0aCB0aGUg4oCcYmVzdCBwb3Nz aWJsZeKAnSBhbmQgc28gc3VjaCBhbiBvcHRpb24gbWF5IGJlIHVzZWZ1bCBpbiBzb21lIGRlcGxv eW1lbnRzLg0KDQogICogICAoMy4yKSBJJ20gdW5jbGVhciBvZiB0aGUgdmFsdWUgb2YgdGhpcyB0 ZXh0LiBJdCBzZWVtcyB0byBtZSB0aGF0IHdlJ3JlIHJlc3RhdGluZyBzb21lIG9mIHRoZSBvcHRp bWlzYXRpb24gb2JqZWN0aXZlcyB0aGF0IGFyZSBrbm93biBmb3IgZ2VuZXJhbCBURSAoYW5kLCBm b3IgZXhhbXBsZSwgYXJlIGRlc2NyaWJlZCBieSAtIHNheSBSRkMzMjA5KS4gV2hhdCBpcyBpdCB0 aGF0IHdlJ3JlIHRyeWluZyB0byBjb21tdW5pY2F0ZSB0byB0aGUgcmVhZGVyIGhlcmUgLS0gY2Fu IGl0IGJlIGNvdmVyZWQgYnkgImV4aXN0aW5nIHBhdGggY2FsY3VsYXRpb24gY29uc2lkZXJhdGlv bnMsIHN1Y2ggYXMgcmVzb3VyY2UgYWZmaW5pdHkgW3JmYzMyMDldIGNhbiBiZSBhcHBsaWVkIHRv IHRoZSBwYXRoIGNhbGN1bGF0aW9uIG9mIFNSIHBhdGhzIj8NCltLVF0gV2UgZG8gbm90IGFzc3Vt ZSB0aGF0IGFueW9uZSB0aGF0IGlzIGRlcGxveWluZyBTUiBQb2xpY2llcyBpcyBmYW1pbGlhciB3 aXRoIFJTVlAtVEUuIFJGQzMyMDkgZG9lcyBjb3ZlciByZXNvdXJjZSBhZmZpbml0eSBidXQgbm90 IHRoZSBvdGhlcnMuIFNvbWUgb2YgdGhlIGNvbnN0cmFpbnRzIGFyZSB1bmlxdWUgdG8gU1IuIEhl bmNlLCB0aGVyZSBpcyBhIHZhbHVlIGluIHNwZWNpZnlpbmcgdGhlIGF2YWlsYWJsZSBjb25zdHJh aW50cy4NCg0KICAqICAgKDMuNCkgSSdtIGFnYWluIGdvaW5nIHRvIHF1ZXN0aW9uIHRoZSB2YWx1 ZSBvZiB0aGlzIHNlY3Rpb24gLS0gaXQgZG9lc24ndCBzZWVtIHRvIGdpdmUgZW5vdWdoIGRldGFp bCBvZiB0aGUgYWxnb3JpdGhtIHRoYXQgeW91J3JlIHByb3Bvc2luZyB0byBiZSBnZW5lcmFsbHkg dXNlZnVsLCBhbmQgcG9pbnRzIG91dCBpdCBpcyBhIG5vZGUtbG9jYWwgYmVoYXZpb3VyLiBJZiB0 aGVyZSdzIGEgZGVzaXJlIHRvIGdldCB0byBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIGhvdyB0 byB0YWtlIGEgcGF0aCBhbmQgY29tcHJlc3MgaXRzIFNJRCBzdGFjaywgdGhlbiBsZXQncyB3cml0 ZSB0aGlzIG91dC4NCltLVF0gQWdyZWUgdGhhdCB0aGlzIGlzIGEgbm9kZSBsb2NhbCBiZWhhdmlv ci4gSG93ZXZlciwgdGhlIGhpZ2ggbGV2ZWwgZGVzY3JpcHRpb24gZG9lcyBpbmRpY2F0ZSBob3cg YW4gaW1wbGVtZW50YXRpb24gY291bGQgZ28gYWJvdXQgZGV0ZXJtaW5pbmcgYSBwYXRoIHRvIGEg U0lEIGluIGFuIGVmZmljaWVudCBtYW5uZXIuDQoNCiAgKiAgICg0KSBTZWUgbXkgY29tbWVudHMg b24gU2VjdGlvbiAyIG9mIHRoaXMgZG9jdW1lbnQsIHdoeSBpcyBkZXNjcmliaW5nIGhvdyB0aGUg aW50ZXJhY3Rpb24gYmV0d2VlbiBkaWZmZXJlbnQgcHJvY2Vzc2VzIHdpdGhpbiB3aGF0IHNvdW5k cyBsaWtlIGEgc2luZ2xlIGltcGxlbWVudGF0aW9uIHNvbWV0aGluZyB0aGF0IHdlIHNob3VsZCBw dWJsaXNoIHdpdGhpbiB0aGUgSUVURj8NCltLVF0gVGhlc2UgZXhhbXBsZXMgYXJlIGltcG9ydGFu dCB0byBpbGx1c3RyYXRlIGhvdyB0aGUgY2FuZGlkYXRlIHBhdGggc2VsZWN0aW9uIHRpZWJyZWFr ZXIgcnVsZXMgd29yayBpbiBkaWZmZXJlbnQgY29uZGl0aW9ucy4gVGhlIGludGVyYWN0aW9ucyBh cmUgYWxzbyB2YWx1YWJsZSB0byB1bmRlcnN0YW5kIHRoZSBzZWxlY3Rpb24gd2hpY2ggaGFwcGVu cyBzYXkgd2l0aGluIEJHUCAoYmFzZWQgb24gaXRzIGJlc3QgcGF0aCkgZm9yIEJHUC1TUlRFIGFu ZCB0aGUgc2VsZWN0aW9uIHRoYXQgdGhlbiBoYXBwZW5zIGF0IFNSIFBvbGljeSBsZXZlbC4gVGhp cyBzZWN0aW9uIHdhcyBvcmlnaW5hbGx5IHBsYWNlZCBpbiB0aGUgQXBwZW5kaXggb2YgdGhlIFNS IFBvbGljeSBBcmNoaXRlY3R1cmUgZHJhZnQgc2luY2UgdGhlIGNhbmRpZGF0ZSBwYXRoIHNlbGVj dGlvbiB0aWVicmVha2VyIHJ1bGVzIHdlcmUgc3BlY2lmaWVkIGluIHRoYXQgZHJhZnQuIExhdGVy IHdhcyBtb3ZlIHRvIHRoaXMgaW5mb3JtYXRpb25hbCBkcmFmdC4NCg0KICAqICAgKDUrNS4xKzUu MikgVGhlIGNvcmUgcG9pbnQgdGhhdCBzZWVtcyB0byBiZSBiZWluZyBtYWRlIGhlcmUgaXMgdGhh dCAtIHdpdGhpbiBhIHNpbmdsZSBJR1AgYXJlYSB0aGUgaGVhZC1lbmQgaGFzIGFsbCB0aGUgdmlz aWJpbGl0eSBpdCByZXF1aXJlczsgaWYgdGhlcmUgYXJlIG11bHRpcGxlIGFyZWFzLCB0aGVyZSBh cmUgd2F5cyB0aGF0IGEgaGVhZC1lbmQgY291bGQgZ2V0IGFjY2VzcyB0byB0aGUgYXJlYXMgdGhh dCBpdCBpcyBub3QgcGFydCBvZiAoZS5nLiwgQkdQLUxTKS4gSXMgYW55dGhpbmcgbW9yZSBiZWlu ZyBzYWlkIGhlcmU/IERvIHRoZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRoYXQgdGhlcmUgYXJl IEJHUC1MUyBSUnMgYWN0dWFsbHkgbWF0dGVyPw0KW0tUXSBUaGUgaW50ZW50aW9uIGlzIHRvIHBy b3ZpZGUgZ3VpZGFuY2UgZm9yIHNvbWUgb2YgdGhlIGRlcGxveW1lbnQgb3B0aW9ucyBmb3IgYWNo aWV2aW5nIHRoaXMgZnVuY3Rpb25hbGl0eS4NCg0KICAqICAgKDUuMykgU2ltaWxhcmx5IHRvIHRo ZSBhYm92ZSwgdGhpcyBzZWVtcyB0byBhc3N1bWUgb25lIHBhcnRpY3VsYXIgbWVjaGFuaXNtIG9m IGJ1aWxkaW5nIGEgY2VudHJhbGlzZWQgc3lzdGVtLCB0aGF0IGRvZXNuJ3QgbmVlZCBhbnkgbmV3 IGV4dGVuc2lvbnMgaW4gdGhlIElFVEYuIElzIHRoaXMgc29tZXRoaW5nIHRoYXQgd2UgbmVlZCB0 byBkb2N1bWVudD8NCltLVF0gV2UgZXhwbGFpbiB3aGlsZSB0YWtpbmcgYW4gZXhhbXBsZSBvZiBh IG1lY2hhbmlzbSBiYXNlZCBvbiBJRVRGIHN0YW5kYXJkcyB0aGF0IGlzIGF2YWlsYWJsZSBmb3Ig b3BlcmF0b3JzIGxvb2tpbmcgdG8gZGVwbG95IHRoaXMgbW9kZWwuDQoNCiAgKiAgICg2LjIpIFRo aXMgc2VjdGlvbiBzZWVtcyB0byBpbXBseSB0aGF0IHRoZXJlIGNhbiBuZXZlciBiZSBhbGxvY2F0 aW9ucyBmcm9tIHRoZSBTUkxCIHRoYXQgYXJlIG5vdCBkeW5hbWljYWxseSBhZHZlcnRpc2VkIHZp YSBzb21lIG90aGVyIHByb3RvY29sLiBJcyB0aGlzIHJlYWxseSB0cnVlPw0KW0tUXSBJIGRvbuKA mXQgYmVsaWV2ZSB0aGlzIHdhcyB0aGUgaW50ZW50aW9uLiBXZSB3aWxsIGNsYXJpZnkgdGhpcyBp biB0aGUgdGV4dC4NCg0KICAqICAgKDgpIEdpdmVuIHRoYXQgdGhlcmUgaXMgYSBzZXBhcmF0ZSBk cmFmdCBkaXNjdXNzaW5nIHRoaXMgLS0gd2hhdCBpcyB0aGUgbW90aXZhdGlvbiB0byBoYXZlIHRo aXMgaW4gdGhpcyBkb2N1bWVudD8NCltLVF0gVGhpcyBzZWN0aW9uIGdpdmVzIGFuZCBvdmVydmll dyBvZiB0aGUgcHJvcG9zYWwgd2l0aCBhbiBleGFtcGxlIG9mIG9wdGljYWwgY2lyY3VpdC4gSXQg YWxzbyBjbGFyaWZpZXMgdGhhdCB0aGUgY29uY2VwdCBkZXNjcmliZWQgaXMgYXBwbGljYWJsZSBu b3QganVzdCBmb3Igb3B0aWNhbCBsaW5rcyBidXQgaW4gZ2VuZXJhbCB0byBvdGhlciB0eXBlcyBv ZiBsYXllciAyIGNpcmN1aXRzIGFuZCB0dW5uZWxzIGFzIHdlbGwuIFRoZSBkcmFmdC1hbmFuZC1z cHJpbmctcG9pLXNyIGdvZXMgaW50byB0aGUgZGV0YWlscyBvZiB0aGUgdXNlLWNhc2UsIHByb3Rv Y29sIG1lY2hhbmlzbSBhbmQgZXh0ZW5zaW9ucyBzcGVjaWZpY2FsbHkgZm9yIG9wdGljYWwgbmV0 d29ya3Mgb25seS4NClRoYW5rcywNCnIuDQo= --_000_0ebeaafcd19e4c8c8c08b05520051186XCHALN008ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA4Nzk5 NDg4MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTkwNTI4NTE4O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5IZWxsbyBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlZlcnNpb24gMiBvZiB0aGUgZHJh ZnQgaGFzIGJlZW4gc3VibWl0dGVkIHRoYXQgaW5jb3Jwb3JhdGVzIHVwZGF0ZXMgdG8gYWRkcmVz cyBjb21tZW50cyBmcm9tIFJvYiBhbmQgYSBmZXcgb3RoZXIgZWRpdG9yaWFsIG5pdHMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4i IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWxzZmls cy1zcHJpbmctc3ItcG9saWN5LWNvbnNpZGVyYXRpb25zLTAyIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXBvbGljeS1jb25zaWRlcmF0aW9ucy0w MjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5LZXRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkNCjxicj4NCjxiPlNlbnQ6PC9iPiAxOSBP Y3RvYmVyIDIwMTggMDc6NDA8YnI+DQo8Yj5Ubzo8L2I+ICdSb2IgU2hha2lyJyAmbHQ7cm9ianM9 NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0OzsgU1BSSU5HIFdHIExpc3QgJmx0O3Nwcmlu Z0BpZXRmLm9yZyZndDs7IGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lkZXJh dGlvbnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtzcHJpbmddIENv bW1lbnRzIG9uIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lkZXJhdGlvbnMt MDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFJvYiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuIFBsZWFzZSBmaW5kIGlubGluZSBi ZWxvdyBvdXIgcmVzcG9uc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tSU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsIHdvcmsgb24gcG9zdGluZyBhbiB1 cGRhdGUgdG8gdGhlIGRyYWZ0IHRvIGluY29ycG9yYXRlIHlvdXIgY29tbWVudHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPktldGFuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9m IDwvYj5Sb2IgU2hha2lyPGJyPg0KPGI+U2VudDo8L2I+IDI1IEp1bHkgMjAxOCAyMToxOTxicj4N CjxiPlRvOjwvYj4gU1BSSU5HIFdHIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWZp bHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lkZXJhdGlvbnNAdG9vbHMuaWV0Zi5vcmciPmRy YWZ0LWZpbHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lkZXJhdGlvbnNAdG9vbHMuaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzcHJpbmddIENvbW1lbnRzIG9uIGRyYWZ0LWZp bHNmaWxzLXNwcmluZy1zci1wb2xpY3ktY29uc2lkZXJhdGlvbnMtMDE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KEFzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0 b3IpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIEF1dGhvcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlBlciBteSBjb21tZW50cyBpbiBTUFJJTkcgYXQgSUVURiAxMDIsIEkgaGF2ZSBh IG51bWJlciBvZiBjb21tZW50cy9jb25jZXJucyBhYm91dCB0aGUgY29udGVudHMgb2YgdGhpcyBk b2N1bWVudC4gUGxlYXNlIGZpbmQgdGhlbSBiZWxvdy4gSSBsb29rIGZvcndhcmQgdG8gZGlzY3Vz c2luZyB0aGVtIGluIG1vcmUgZGV0YWlsLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHVsIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQooMikgV2hhdCBpcyB0aGUgaW50ZW50aW9uIG9mIHRoZSBkaWFncmFtIHNob3duIGluIHRo aXMgc2VjdGlvbj8gSXQgc2VlbXMgdG8gYmUgY29tcGxldGVseSBhbiBpbXBsZW1lbnRhdGlvbiBk ZXRhaWwgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgdGhlICZxdW90O1NSUE0mcXVvdDsgdGhh dCBhY3RzIGFzIGEgY2VudHJhbCByZXNvbHV0aW9uIHBvaW50LiBGb3IgaW5zdGFuY2UsIHdoYXQg c2hvdWxkIGEgcmVhZGVyIGxlYXJuIGZyb20gdGhlIGZhY3QgdGhhdCB0aGUNCiBTUlBNIGlzIG5v dCBhIHN0YW5kYXJkIFJJQiByZXNvbHV0aW9uIHByb2Nlc3M/IElmIHRoZXJlIGFyZSBzdWdnZXN0 aW9ucyB0aGF0IG9uZSB3YW50cyB0aGlzIGltcGxlbWVudGF0aW9uIC0gc2hvdWxkIHRoZXJlIGJl IHNvbWUgZGlzY3Vzc2lvbiBvZiB0aGUgY29tcGxleGl0eSBvZiB0aGlzIG5ldyBBUEkgYmV0d2Vl biBzYXksIHRoZSBCR1AgZGFlbW9uIGFuZCBhIGdlbmVyYWwgUklCIHByb2Nlc3M/PG86cD48L286 cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5bS1RdDQo8L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5XZSB3aWxsIGNsYXJpZnkgaW4gdGhlIHRl eHQgdGhhdCB0aGUgc2VjdGlvbiBwcm92aWRlcyBhIGNvbmNlcHR1YWwgb3ZlcnZpZXcgb2YgY29t cG9uZW50cy9mdW5jdGlvbmFsaXR5IHRoYXQgd29yayB3aXRoIGVhY2ggb3RoZXIgdG8gaW1wbGVt ZW50IFNSIFBvbGljeSBvbiBhIGhlYWRlbmQuIFRoZSBpbnRlbnRpb24gaXMgbm90IHRvDQogZGVm aW5lIEFQSXMgYmV0d2VlbiB0aGUgYmxvY2tzIHNpbmNlIHRob3NlIGFyZSBpbXBsZW1lbnRhdGlv biBkZXRhaWxzLiBXZSBoYXZlIHNldmVyYWwgZHJhZnRzIHJlbGF0ZWQgdG8gdGhlIFNSIFBvbGlj eSBmdW5jdGlvbmFsaXR5IOKAkyBiZXNpZGVzIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQsIHRoZXJl IGFyZSBleHRlbnNpb25zIHRvIEJHUCAoQkdQLVNSVEUgJmFtcDsgTFMpLCBQQ0VQIHRoZW4gd2Ug aGF2ZSBZYW5nIG1vZGVsLiBUaGlzIGRyYWZ0IHB1dHMNCiB0aGVzZSBibG9ja3MgaW50byByZWZl cmVuY2Ugc28gaW1wbGVtZW50ZXJzIGdldCBhbiBpZGVhIG9mIHRoZSBmdW5jdGlvbmFsaXR5IHRo YXQgbWFwcyB0byBzYXkgQkdQIGFuZCB0aGUgU1IgUG9saWN5IHByb2Nlc3NlcyAoZS5nLiBkcmFm dC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5KS48L3NwYW4+PC9pPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQooMikgTXkgZ2VuZXJhbCBmZWVkYmFjayBvbiB0aGlzIHNlY3Rpb24gaXMgdGhhdCB0aGlz IGlzIGltcGxlbWVudGF0aW9uIGRpc2N1c3Npb24sIHRoYXQgZG9lcyBub3QgYWRkIHRvIHRoZSBJ RVRGIGNvbnRlbnQgdGhhdCB3ZSBhcmUgcHVibGlzaGluZyB3aXRoaW4gU1BSSU5HLiBMaWtlIHdl IGhhdmUgaGFkIGRpc2N1c3Npb24gb2YgdXNlIGNhc2UgZHJhZnRzLCBJIHRoaW5rIHRoaXMgaXMg c2ltaWxhciBidXQgZnJvbSB0aGUgaW1wbGVtZW50b3Igc2lkZS4NCiBJJ2QgbGlrZSB0byBkaXNj dXNzIHRoZSB2YWx1ZSB0aGF0IHRoaXMgY29udGVudCBoYXMuPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5bS1RdDQo8L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBkb2N1bWVu dGluZyBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIGFuZCBwcm92aWRpbmcgYSBjb25jZXB0dWFsIG92 ZXJ2aWV3IG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBhc3BlY3RzLiBFc3BlY2lhbGx5IHdoZW4gZGVm aW5pbmcgYW4gYXJjaGl0ZWN0dXJlIHdoaWNoIGludm9sdmVzIG11bHRpcGxlDQogcHJvdG9jb2xz IGFuZCBmdW5jdGlvbmFsIGJsb2Nrcy4gSSBmaW5kIGl0IHZhbHVhYmxlIGFzIGFuIGltcGxlbWVu dGVyIG15c2VsZi48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooMy4xKSBJIHRoaW5rIHRoYXQgdGhp cyBzZWN0aW9uIGhhcyBzb21lIHVzZWZ1bCBjb250ZW50LCBidXQgaXQncyBidXJpZWQgYnkgc3Rh cnRpbmcgb3V0IGJ5IGRlZmluaW5nIHRoZSBhbGdvcml0aG1zLi4gV2h5IG5vdCBtYWtlIHRoaXMg c2VjdGlvbiBiZSBmb2N1c2VkIHRvd2FyZHMgdGhlIGNvbnN0cmFpbnRzIHRoYXQgbXVzdCBiZSBj b25zaWRlcmVkIHdoZW4gY2FsY3VsYXRpbmcgYSBTSUQgc3RhY2sgZm9yIGEgcGFydGljdWxhciBw YXRoLiBpLmUuLA0KIHRoZSBrZXkgcG9pbnRzIHNlZW0gdG8gYmU6PG86cD48L286cD48L2xpPjwv dWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KVXNlIG9mIHRoZSBJR1AgbWV0cmlj IGFzIHRoZSBtZXRyaWMgZm9yIHBhdGggb3B0aW1pc2F0aW9uIGlzIGRlc2lyYWJsZSwgZXNwZWNp YWxseSBpbiBjb25zdHJhaW5lZCBwdXNoIG9yIHJlYWRhYmxlIGRlcHRoIGVudmlyb25tZW50cywg YmVjYXVzZSBpdCBhbGxvd3MgdGhlIG1pbmltdW0gbnVtYmVyIG9mIGRldmlhdGlvbnMgZnJvbSB0 aGUgc2hvcnRlc3QgcGF0aCBhbmQgdGhlcmVmb3JlIGxhYmVscy48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQpJZiBhIGRpZmZl cmVudCBtZXRyaWMgaXMgdXNlZCwgdGhlbiB0aGlzIGltcGxpZXMgdGhhdCBldmVyeSB0aW1lIHRo YXQgbWV0cmljIGRpZmZlcnMgZnJvbSB0aGUgSUdQIG1ldHJpYywgdGhlbiB0aGlzIHdpbGwgcmVz dWx0IGluIGFkZGl0aW9uYWwgU0lEcy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwg dHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDMgbGZvMSI+DQpUaGVyZSBpcyBu byBtZW50aW9uIG9mIGZsZXgtYWxnb3JpdGhtIGluIHRoaXMgc2VjdGlvbi4gSXQgc2VlbXMgcmVs ZXZhbnQgZ2l2ZW4gdGhhdCB5b3UgY2FuIGFsc28gbWl0aWdhdGUgdGhlIHByb2JsZW0gdGhhdCBp cyB0cnlpbmcgdG8gYmUgc29sdmVkIGhlcmUgYnkgaGF2aW5nIGEgc2V0IG9mIHByZWZpeCBTSURz IHBlciBtZXRyaWMuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltLVF0N Cjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QiPldlIHdpbGwgcHV0IGEgZm9yd2FyZCByZWZlcmVuY2UgdG8gdGhlIEZsZXggQWxn byBzZWN0aW9uIGhlcmUuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJj aXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+ DQpJdCBtYXkgYmUgYWR2YW50YWdlb3VzIHRvIHNhY3JpZmljZSBvcHRpbWFsaXR5IG9mIHRoZSBw YXRoIGNhbGN1bGF0aW9uIHNvbHV0aW9uIGJ5IHJlbGF4aW5nIHRoZSBvcHRpbWlzYXRpb24gY29u c3RyYWludHMuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0K PHVsIHR5cGU9ImNpcmNsZSI+DQo8dWwgdHlwZT0ic3F1YXJlIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzEiPg0KVGhlIGRyYWZ0IHNob3VsZCB0YWxrIGFi b3V0IHRoZSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyBoZXJlIC0gaS5lLiwgaXQgaW1wbGll cyB0aGF0IHlvdSBjYW4gYWN0dWFsbHkgdG9sZXJhdGUgdGhlIG1hcmdpbiBpbiB0aGUgb3B0aW1p c2F0aW9uIG9iamVjdGl2ZSBmb3IgdGhlIHNlcnZpY2UuPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzEiPg0KVGhlICZxdW90O2p1c3Qg cGljayB0aGUgYmVzdCB5b3UgY2FuIGRvIHdpdGhpbiBOIFNJRHMmcXVvdDsgaXMgZGFuZ2Vyb3Vz LCBzaW5jZSBpdCBtZWFucyB0aGF0IHRoZSBuZXR3b3JrIGRlbGl2ZXJzIGEgc2VydmljZSB0aGF0 ICppc24ndCogd2hhdCB0aGUgb3BlcmF0b3IgYXNrZWQgZm9yIC0gd2hpY2ggbWF5IHJlc3VsdCBp biBzZXJ2aWNlIGRlZ3JhZGF0aW9uIChlLmcuLCBjb25zaWRlciBsaXZlL2xpdmUgd2hlcmUgdGhl cmUgaXMgYSBtYXhpbXVtIGxhdGVuY3kNCiBkaWZmZXJlbmNlIHRoYXQgaXMgdG9sZXJhYmxlIGJl dHdlZW4gdGhlIHR3byBmZWVkcykuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltLVF0NCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPldlIHdpbGwgYWRkIHRleHQgY2xhcmlmeWluZyB0aGlzIGFzcGVj dC4gSG93ZXZlciwgdGhlIHBvaW50IGlzIGFsc28gdGhhdCB0aGUgb3BlcmF0b3IgbWF5IGJlIE9L IHdpdGggdGhlIOKAnGJlc3QgcG9zc2libGXigJ0gYW5kIHNvIHN1Y2ggYW4gb3B0aW9uIG1heSBi ZSB1c2VmdWwgaW4gc29tZSBkZXBsb3ltZW50cy48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooMy4y KSBJJ20gdW5jbGVhciBvZiB0aGUgdmFsdWUgb2YgdGhpcyB0ZXh0LiBJdCBzZWVtcyB0byBtZSB0 aGF0IHdlJ3JlIHJlc3RhdGluZyBzb21lIG9mIHRoZSBvcHRpbWlzYXRpb24gb2JqZWN0aXZlcyB0 aGF0IGFyZSBrbm93biBmb3IgZ2VuZXJhbCBURSAoYW5kLCBmb3IgZXhhbXBsZSwgYXJlIGRlc2Ny aWJlZCBieSAtIHNheSBSRkMzMjA5KS4gV2hhdCBpcyBpdCB0aGF0IHdlJ3JlIHRyeWluZyB0byBj b21tdW5pY2F0ZSB0byB0aGUgcmVhZGVyDQogaGVyZSAtLSBjYW4gaXQgYmUgY292ZXJlZCBieSAm cXVvdDtleGlzdGluZyBwYXRoIGNhbGN1bGF0aW9uIGNvbnNpZGVyYXRpb25zLCBzdWNoIGFzIHJl c291cmNlIGFmZmluaXR5IFtyZmMzMjA5XSBjYW4gYmUgYXBwbGllZCB0byB0aGUgcGF0aCBjYWxj dWxhdGlvbiBvZiBTUiBwYXRocyZxdW90Oz88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltLVF0N Cjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QiPldlIGRvIG5vdCBhc3N1bWUgdGhhdCBhbnlvbmUgdGhhdCBpcyBkZXBsb3lpbmcg U1IgUG9saWNpZXMgaXMgZmFtaWxpYXIgd2l0aCBSU1ZQLVRFLiBSRkMzMjA5IGRvZXMgY292ZXIg cmVzb3VyY2UgYWZmaW5pdHkgYnV0IG5vdCB0aGUgb3RoZXJzLiBTb21lIG9mIHRoZSBjb25zdHJh aW50cyBhcmUgdW5pcXVlIHRvIFNSLiBIZW5jZSwNCiB0aGVyZSBpcyBhIHZhbHVlIGluIHNwZWNp ZnlpbmcgdGhlIGF2YWlsYWJsZSBjb25zdHJhaW50cy48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQoo My40KSBJJ20gYWdhaW4gZ29pbmcgdG8gcXVlc3Rpb24gdGhlIHZhbHVlIG9mIHRoaXMgc2VjdGlv biAtLSBpdCBkb2Vzbid0IHNlZW0gdG8gZ2l2ZSBlbm91Z2ggZGV0YWlsIG9mIHRoZSBhbGdvcml0 aG0gdGhhdCB5b3UncmUgcHJvcG9zaW5nIHRvIGJlIGdlbmVyYWxseSB1c2VmdWwsIGFuZCBwb2lu dHMgb3V0IGl0IGlzIGEgbm9kZS1sb2NhbCBiZWhhdmlvdXIuIElmIHRoZXJlJ3MgYSBkZXNpcmUg dG8gZ2V0IHRvIGEgY29tbW9uIHVuZGVyc3RhbmRpbmcNCiBvZiBob3cgdG8gdGFrZSBhIHBhdGgg YW5kIGNvbXByZXNzIGl0cyBTSUQgc3RhY2ssIHRoZW4gbGV0J3Mgd3JpdGUgdGhpcyBvdXQuPG86 cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bS1RdDQo8L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojNDQ1NDZBIj5BZ3JlZSB0aGF0IHRoaXMgaXMg YSBub2RlIGxvY2FsIGJlaGF2aW9yLiBIb3dldmVyLCB0aGUgaGlnaCBsZXZlbCBkZXNjcmlwdGlv biBkb2VzIGluZGljYXRlIGhvdyBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBnbyBhYm91dCBkZXRl cm1pbmluZyBhIHBhdGggdG8gYSBTSUQgaW4gYW4gZWZmaWNpZW50IG1hbm5lci48L3NwYW4+PC9p PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojNDQ1NDZBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCig0KSBTZWUgbXkgY29tbWVudHMgb24gU2VjdGlv biAyIG9mIHRoaXMgZG9jdW1lbnQsIHdoeSBpcyBkZXNjcmliaW5nIGhvdyB0aGUgaW50ZXJhY3Rp b24gYmV0d2VlbiBkaWZmZXJlbnQgcHJvY2Vzc2VzIHdpdGhpbiB3aGF0IHNvdW5kcyBsaWtlIGEg c2luZ2xlIGltcGxlbWVudGF0aW9uIHNvbWV0aGluZyB0aGF0IHdlIHNob3VsZCBwdWJsaXNoIHdp dGhpbiB0aGUgSUVURj88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltLVF0NCjwvc3Bhbj48L2k+ PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlRo ZXNlIGV4YW1wbGVzIGFyZSBpbXBvcnRhbnQgdG8gaWxsdXN0cmF0ZSBob3cgdGhlIGNhbmRpZGF0 ZSBwYXRoIHNlbGVjdGlvbiB0aWVicmVha2VyIHJ1bGVzIHdvcmsgaW4gZGlmZmVyZW50IGNvbmRp dGlvbnMuIFRoZSBpbnRlcmFjdGlvbnMgYXJlIGFsc28gdmFsdWFibGUgdG8gdW5kZXJzdGFuZCB0 aGUgc2VsZWN0aW9uIHdoaWNoDQogaGFwcGVucyBzYXkgd2l0aGluIEJHUCAoYmFzZWQgb24gaXRz IGJlc3QgcGF0aCkgZm9yIEJHUC1TUlRFIGFuZCB0aGUgc2VsZWN0aW9uIHRoYXQgdGhlbiBoYXBw ZW5zIGF0IFNSIFBvbGljeSBsZXZlbC4gVGhpcyBzZWN0aW9uIHdhcyBvcmlnaW5hbGx5IHBsYWNl ZCBpbiB0aGUgQXBwZW5kaXggb2YgdGhlIFNSIFBvbGljeSBBcmNoaXRlY3R1cmUgZHJhZnQgc2lu Y2UgdGhlIGNhbmRpZGF0ZSBwYXRoIHNlbGVjdGlvbiB0aWVicmVha2VyIHJ1bGVzDQogd2VyZSBz cGVjaWZpZWQgaW4gdGhhdCBkcmFmdC4gTGF0ZXIgd2FzIG1vdmUgdG8gdGhpcyBpbmZvcm1hdGlv bmFsIGRyYWZ0Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCig1JiM0Mzs1LjEmIzQzOzUuMikgVGhl IGNvcmUgcG9pbnQgdGhhdCBzZWVtcyB0byBiZSBiZWluZyBtYWRlIGhlcmUgaXMgdGhhdCAtIHdp dGhpbiBhIHNpbmdsZSBJR1AgYXJlYSB0aGUgaGVhZC1lbmQgaGFzIGFsbCB0aGUgdmlzaWJpbGl0 eSBpdCByZXF1aXJlczsgaWYgdGhlcmUgYXJlIG11bHRpcGxlIGFyZWFzLCB0aGVyZSBhcmUgd2F5 cyB0aGF0IGEgaGVhZC1lbmQgY291bGQgZ2V0IGFjY2VzcyB0byB0aGUgYXJlYXMgdGhhdCBpdCBp cyBub3QgcGFydCBvZg0KIChlLmcuLCBCR1AtTFMpLiBJcyBhbnl0aGluZyBtb3JlIGJlaW5nIHNh aWQgaGVyZT8gRG8gdGhlIGltcGxlbWVudGF0aW9uIGRldGFpbHMgdGhhdCB0aGVyZSBhcmUgQkdQ LUxTIFJScyBhY3R1YWxseSBtYXR0ZXI/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bS1RdDQo8 L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj5UaGUgaW50ZW50aW9uIGlzIHRvIHByb3ZpZGUgZ3VpZGFuY2UgZm9yIHNvbWUgb2Yg dGhlIGRlcGxveW1lbnQgb3B0aW9ucyBmb3IgYWNoaWV2aW5nIHRoaXMgZnVuY3Rpb25hbGl0eS48 L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooNS4zKSBTaW1pbGFybHkgdG8gdGhlIGFib3ZlLCB0aGlz IHNlZW1zIHRvIGFzc3VtZSBvbmUgcGFydGljdWxhciBtZWNoYW5pc20gb2YgYnVpbGRpbmcgYSBj ZW50cmFsaXNlZCBzeXN0ZW0sIHRoYXQgZG9lc24ndCBuZWVkIGFueSBuZXcgZXh0ZW5zaW9ucyBp biB0aGUgSUVURi4gSXMgdGhpcyBzb21ldGhpbmcgdGhhdCB3ZSBuZWVkIHRvIGRvY3VtZW50Pzxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0tUXQ0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+V2UgZXhwbGFpbiB3aGlsZSB0 YWtpbmcgYW4gZXhhbXBsZSBvZiBhIG1lY2hhbmlzbSBiYXNlZCBvbiBJRVRGIHN0YW5kYXJkcyB0 aGF0IGlzIGF2YWlsYWJsZSBmb3Igb3BlcmF0b3JzIGxvb2tpbmcgdG8gZGVwbG95IHRoaXMgbW9k ZWwuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KKDYuMikgVGhpcyBzZWN0aW9uIHNlZW1zIHRvIGlt cGx5IHRoYXQgdGhlcmUgY2FuIG5ldmVyIGJlIGFsbG9jYXRpb25zIGZyb20gdGhlIFNSTEIgdGhh dCBhcmUgbm90IGR5bmFtaWNhbGx5IGFkdmVydGlzZWQgdmlhIHNvbWUgb3RoZXIgcHJvdG9jb2wu IElzIHRoaXMgcmVhbGx5IHRydWU/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bS1RdDQo8L3Nw YW4+PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEIj5JIGRvbuKAmXQgYmVsaWV2ZSB0aGlzIHdhcyB0aGUgaW50ZW50aW9uLiBXZSB3aWxsIGNs YXJpZnkgdGhpcyBpbiB0aGUgdGV4dC48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooOCkgR2l2ZW4g dGhhdCB0aGVyZSBpcyBhIHNlcGFyYXRlIGRyYWZ0IGRpc2N1c3NpbmcgdGhpcyAtLSB3aGF0IGlz IHRoZSBtb3RpdmF0aW9uIHRvIGhhdmUgdGhpcyBpbiB0aGlzIGRvY3VtZW50PzxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+W0tUXQ0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzQ0NTQ2QSI+VGhpcyBzZWN0aW9uIGdpdmVzIGFuZCBvdmVy dmlldyBvZiB0aGUgcHJvcG9zYWwgd2l0aCBhbiBleGFtcGxlIG9mIG9wdGljYWwgY2lyY3VpdC4g SXQgYWxzbyBjbGFyaWZpZXMgdGhhdCB0aGUgY29uY2VwdCBkZXNjcmliZWQgaXMgYXBwbGljYWJs ZSBub3QganVzdCBmb3Igb3B0aWNhbCBsaW5rcyBidXQgaW4gZ2VuZXJhbCB0byBvdGhlcg0KIHR5 cGVzIG9mIGxheWVyIDIgY2lyY3VpdHMgYW5kIHR1bm5lbHMgYXMgd2VsbC4gVGhlIGRyYWZ0LWFu YW5kLXNwcmluZy1wb2ktc3IgZ29lcyBpbnRvIHRoZSBkZXRhaWxzIG9mIHRoZSB1c2UtY2FzZSwg cHJvdG9jb2wgbWVjaGFuaXNtIGFuZCBleHRlbnNpb25zIHNwZWNpZmljYWxseSBmb3Igb3B0aWNh bCBuZXR3b3JrcyBvbmx5Lg0KPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_0ebeaafcd19e4c8c8c08b05520051186XCHALN008ciscocom_-- From nobody Mon Oct 22 12:02:51 2018 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 15978130D7A; Mon, 22 Oct 2018 12:02:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <154023496803.7727.12546413225688935201@ietfa.amsl.com> Date: Mon, 22 Oct 2018 12:02:48 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-15.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:02: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 WG of the IETF. Title : Segment Routing with MPLS data plane Authors : Ahmed Bashandy Clarence Filsfils Stefano Previdi Bruno Decraene Stephane Litkowski Rob Shakir Filename : draft-ietf-spring-segment-routing-mpls-15.txt Pages : 35 Date : 2018-10-22 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. In the MPLS dataplane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS dataplane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-15 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-mpls-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-15 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 Oct 22 12:06:33 2018 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 A2B4F128D0C; Mon, 22 Oct 2018 12:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qWP7G2wF2GjA; Mon, 22 Oct 2018 12:06:27 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 9CC141277C8; Mon, 22 Oct 2018 12:06:27 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id c10-v6so19453703pgq.4; Mon, 22 Oct 2018 12:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=DRHTqnyNnHNlb0FA9K9xM3eiNUUa3oDFUDi59zFtkQk=; b=HVbNclujh2HuokdwrKXVCN9eNlztc65eASla6QDO0ETLQ+frrn3/DEkUrEg0W7q01D yORsP0UfeuIzEIlV6I1p6oILOtI2XOrPtrSnjYHGRowRTfAzbwTntPpdHtMF1PNP0SbC sG12zDSyzMFRsrRh49zqs013i6CIpZshv615A8qdaKblOEy7AoYBnH37wEzokEVA5jqM GiFZ7Xo0qv55v85GHq6PVVc7dzwNaHUFzciioagn52iKoFIjTctxa8RtXCBMVPTg5oPn 1ir2SOpCkTTSOsaedB1ASYDqmdqGXD+r31SNNrXYxzSPr0r4rP0hSxkWQDDu8XjRzeAL SgBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=DRHTqnyNnHNlb0FA9K9xM3eiNUUa3oDFUDi59zFtkQk=; b=uGOFuBUielTs8UCZDNdROjRTTOjbx3wJgA71k8ozzAeTzbviG/o4J/WnVUTJ1ZSOMK pUWBUq0x11zJnMrE1DswgruLliYqubcM7zcG0BOLMLzcwu9Ky+1BXc4YayOr7CC28wT8 F3Jp6vLnp9bfwkvBX+psDbJCZ2tzOaXY+TRKmc2NCJo5F4oezsbS3Ju036uW0N69yRzh hM144ILpntyfEwe48Oe1w874/MXpLg/lI4OeQqyIRuujOzu47Oken1gUd3q6sDGvlDin hY9d3Z2eNjx/cf+PblNfVbZ/0zV4qwmBI0TKBmPFokVkfRBJbNpyCP2ozekPlEd0ag92 cGxg== X-Gm-Message-State: ABuFfog7a2E9v6f1121X3WNeqcQX0sugfkJAk/WajNFZ/82OK6BTYwrA hwJI/58OE9YkCNJRaRalZv8= X-Google-Smtp-Source: ACcGV60LMO7bFTcXmh1aPf0rH76tB3dOYa/pb4r/wZjbLM5h5VrohcmJO2mYXqcbzKaNvfy++VPg3Q== X-Received: by 2002:a65:4882:: with SMTP id n2-v6mr41953575pgs.225.1540235186826; Mon, 22 Oct 2018 12:06:26 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-185.dsl.rcsntx.sbcglobal.net. [70.234.233.185]) by smtp.gmail.com with ESMTPSA id n82-v6sm48102483pfg.21.2018.10.22.12.06.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 12:06:25 -0700 (PDT) To: bruno.decraene@orange.com, "draft-ietf-spring-segment-routing-mpls@ietf.org" Cc: SPRING WG List References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6143_1539619921_5BC4BC51_6143_164_1_53C29892C857584299CBF5D05346208A47B69553@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: <0649713e-d14c-5e81-cac7-d657d58130b7@gmail.com> Date: Mon, 22 Oct 2018 12:06:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6143_1539619921_5BC4BC51_6143_164_1_53C29892C857584299CBF5D05346208A47B69553@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------CE81025A3D52DA3115B154D0" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:06:31 -0000 This is a multi-part message in MIME format. --------------CE81025A3D52DA3115B154D0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I uploaded version 15 to address the comments below since today is the deadline before the upcoming IETF I will explaining how version 15 addresses each of the comments before the start of the IETF next week Thanks a lot for all the help and the feedback Ahmed On 10/15/18 9:12 AM, bruno.decraene@orange.com wrote: > > Authors, Ahmed, > > Could you progress on this document? > > Thread is: > https://mailarchive.ietf.org/arch/browse/spring/?q=subject%3Adraft-ietf-spring-segment-routing-mpls > > Comments still to be addressed/resolved are the following: > > https://mailarchive.ietf.org/arch/msg/spring/xx-t5v5IW2P_8rZykeJrvl9qDIE > (from myself since 2018-05-24) > > https://mailarchive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw > (from Chris Bowers since 2018-06-08) > > https://mailarchive.ietf.org/arch/msg/spring/yIwUvKddrcR-gxPQZSMjbynTX74 > (from PK since 2018-06-09) > > https://mailarchive.ietf.org/arch/msg/spring/5PHhLlMIxLgoFdoRC1Wqz6xCBnI > (from PK since 2018-06-09) > > https://mailarchive.ietf.org/arch/msg/spring/w0ZmOAcDf_TUUWLkeFk_E6jzQm4 > (from Ruediger 2018-06-13) > > https://mailarchive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ > (from Shraddha 2018-07-20 & +1 from Sasha) > > https://mailarchive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk > (from Sasha & Stéphane discussion 2018-08-06) > > Authors, Ahmed, > > Thank you for engaging the authors of those comments and update the draft. > > Thank you, > > --Bruno > > *From:*DECRAENE Bruno IMT/OLN > *Sent:* Thursday, June 07, 2018 6:52 PM > *To:* SPRING WG List > *Cc:* draft-ietf-spring-segment-routing-mpls@ietf.org > *Subject:* RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 > > Hi all, > > A quick update on the status of this WGLC: > > - All the authors have responded about IPR (thank you!). Still missing > replies from some contributors (Wim, Edward, Igor, Saku). I’ve sent > them a reminder this Monday. > > - Two people (Zafar, Adrian) have responded supporting publication. > > - No opposition. > > - Two persons have sent comments (Adrian, myself). Thanks Adrian. > > - Authors have not replied to any comment so far. > > - The WGLC period was scheduled to end tomorrow. > > I wish we had more support, reviews, and authors’ involvement to reply > to reviews. > > The WGLC is extended by a week. Please review the document and send > your comments to the list, no later than **June 15** > > Thank you, > > --Bruno > > *From:*bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > *Sent:* Thursday, May 24, 2018 7:14 PM > *To:* SPRING WG List > *Cc:* draft-ietf-spring-segment-routing-mpls@ietf.org > *Subject:* WG Last Call for draft-ietf-spring-segment-routing-mpls-13 > > Hello Working Group, > This email starts a Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-13 [1] which is considered > mature and ready for a final working group review. > Please read this document if you haven't read the most recent version > yet, and send your comments to the list, no later than *June 08*. > As a reminder, this document had already passed a WGLC more than a > year ago on version -06 [2], had been sent to the AD but then returned > to the WG. > Since then, the document has significantly changed, so please read it > again. In particular, it now includes the resolution in case of > incoming label collision. Hence it killed > draft-ietf-spring-conflict-resolution. > Both co-chairs co-author this document, hence: > - Shraddha has agreed to be the document shepherd. Thank you Shraddha. > - Martin, our AD, has agreed to evaluate the WG consensus. > Thank you, > Bruno, Rob > [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 > [2] > https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y > _________________________________________________________________________________________________________________________ > 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. --------------CE81025A3D52DA3115B154D0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I uploaded version 15 to address the comments below since today is the deadline before the upcoming IETF

I will explaining how version 15 addresses each of the comments before the start of the IETF next week

Thanks a lot for all the help and the feedback

Ahmed



On 10/15/18 9:12 AM, bruno.decraene@orange.com wrote:

Authors, Ahmed,

 

Could you progress on this document?

 

Thread is: https://mailarchive.ietf.org/arch/browse/spring/?q=subject%3Adraft-ietf-spring-segment-routing-mpls

 

Comments still to be addressed/resolved are the following:

https://mailarchive.ietf.org/arch/msg/spring/xx-t5v5IW2P_8rZykeJrvl9qDIE   (from myself since 2018-05-24)

https://mailarchive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw (from Chris Bowers since 2018-06-08)

https://mailarchive.ietf.org/arch/msg/spring/yIwUvKddrcR-gxPQZSMjbynTX74 (from PK since 2018-06-09)

https://mailarchive.ietf.org/arch/msg/spring/5PHhLlMIxLgoFdoRC1Wqz6xCBnI  (from PK since 2018-06-09)

https://mailarchive.ietf.org/arch/msg/spring/w0ZmOAcDf_TUUWLkeFk_E6jzQm4 (from Ruediger 2018-06-13)

https://mailarchive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ (from Shraddha 2018-07-20 & +1 from Sasha)

https://mailarchive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk (from Sasha & Stéphane discussion 2018-08-06)

 

 

Authors, Ahmed,

Thank you for engaging the authors of those comments and update the draft.

 

Thank you,

--Bruno

 

 

 

From: DECRAENE Bruno IMT/OLN
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

 

Hi all,

 

A quick update on the status of this WGLC:

 

- All the authors have responded about IPR (thank you!). Still missing replies from some contributors (Wim, Edward, Igor, Saku). I’ve sent them a reminder this Monday.

- Two people (Zafar, Adrian) have responded supporting publication.

- No opposition.

- Two persons have sent comments (Adrian, myself). Thanks Adrian.

- Authors have not replied to any comment so far.

- The WGLC period was scheduled to end tomorrow.

 

I wish we had more support, reviews, and authors’ involvement to reply to reviews.

 

The WGLC is extended by a week. Please review the document and send your comments to the list, no later than *June 15*

 

Thank you,

--Bruno

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

 

Hello Working Group,
    
This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review.
    
Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*.
 
As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG.
Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd. Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
_________________________________________________________________________________________________________________________
 
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.

--------------CE81025A3D52DA3115B154D0-- From nobody Mon Oct 22 13:01:37 2018 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 A8908130E5A; Mon, 22 Oct 2018 13:01:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <154023848367.13425.13137552828384489215@ietfa.amsl.com> Date: Mon, 22 Oct 2018 13:01:23 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:01:32 -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 WG of the IETF. Title : Segment Routing Policy Architecture Authors : Clarence Filsfils Siva Sivabalan Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-02.txt Pages : 33 Date : 2018-10-22 Abstract: Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-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 Mon Oct 22 13:10:10 2018 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 4CAC212D7EA for ; Mon, 22 Oct 2018 13:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Mu6WZAzwT00t for ; Mon, 22 Oct 2018 13:10:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211E112F1A2 for ; Mon, 22 Oct 2018 13:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2954; q=dns/txt; s=iport; t=1540239002; x=1541448602; h=from:to:cc:subject:date:message-id:mime-version; bh=Oka/v9YXhA6aL+Mb6DPhAflXzh9htWTTFLNG5SToasc=; b=hl0dYeEmQps2c22rlmSaXhLGfBbt2EddRo5n5iieJVOMsOFCCTVufVnJ dTl53SvXJmnX8RfCZGHUaWkeeWv6UdYwkOugNVg9Bop4paJs99aHb7ILK e+elZQSlAzc4V3aGvBLZOJydyPz8dwkPSfoK+SwUEK/qftFbDZugN17XQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABWLs5b/40NJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDXdmfygKjAOMG5NahUiBegsBASMJhECFFyE?= =?us-ascii?q?0DQ0BAwEBAgEBAm0cAQuFbkwSAQx0JgEEDg2DGoEdZA+oLIoZBYtSF4IAg3U?= =?us-ascii?q?ugxsChzsCjjWQEwkCgVmPDx+QLpY2AhEUgSYdOIFVcBWDJ4sZhT5vAYEnig8?= =?us-ascii?q?BgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,413,1534809600"; d="scan'208,217";a="470231279" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 20:09:51 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w9MK9pMk012325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Oct 2018 20:09:51 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 15:09:51 -0500 Received: from xch-aln-011.cisco.com ([173.36.7.21]) by XCH-ALN-011.cisco.com ([173.36.7.21]) with mapi id 15.00.1395.000; Mon, 22 Oct 2018 15:09:51 -0500 From: "Siva Sivabalan (msiva)" To: "spring@ietf.org" CC: "Clarence Filsfils (cfilsfil)" , "Voyer, Daniel" , "Alex Bogdanov (bogdanov@google.com)" , "pamattes@microsoft.com" Thread-Topic: New version of SR policy draft Thread-Index: AdRqQnbjsUeXKJSnQVaEXVM/NGjF7A== Date: Mon, 22 Oct 2018 20:09:51 +0000 Message-ID: <397b0297a95b4b659553cbc27b9cbd18@XCH-ALN-011.cisco.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: [161.44.213.136] Content-Type: multipart/alternative; boundary="_000_397b0297a95b4b659553cbc27b9cbd18XCHALN011ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: [spring] New version of SR policy draft X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:10:08 -0000 --_000_397b0297a95b4b659553cbc27b9cbd18XCHALN011ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We have posted a new version of SR policy draft: https://www.ietf.org/id/draft-ietf-spring-segment-routing-policy-02.txt Additional reviews and comments will be appreciated. Thanks, Siva --_000_397b0297a95b4b659553cbc27b9cbd18XCHALN011ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We have posted a new version of SR policy draft:

 

https://www.ietf.org/id/draft-ietf-spring-s= egment-routing-policy-02.txt

 

Additional reviews and comments will be appreciated.=

 

Thanks,

Siva

--_000_397b0297a95b4b659553cbc27b9cbd18XCHALN011ciscocom_-- From nobody Mon Oct 22 21:47:35 2018 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 5DC2D130E7F for ; Mon, 22 Oct 2018 21:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 zBCVTf5pFEgL for ; Mon, 22 Oct 2018 21:47:31 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4D01288BD for ; Mon, 22 Oct 2018 21:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7967; q=dns/txt; s=iport; t=1540270051; x=1541479651; h=from:to:subject:date:message-id:references:mime-version; bh=nRAUrc5gS6whwddafmd3nC0QBFGCodzfQaerN2bbbBQ=; b=XbWI7ggQRoB+N2NxS+7Fzmg5L162YBY9P/dKX8WBU240Sn+gdwGTBRdf DvWm5qcpXGLj/EYYrl8eBlMl8poHDDe9fhXvrB6RSOyemHdZx0il2HxlI Cv3fERxq+gICQj3YUkcTPrvPbs1dX1yon3G0irgpCg2fYW9RM7YTbsWzG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AgD/ps5b/40NJK1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYEOd2Z/KAqYIIINeo1ygl4DgjWFDQsBASWERwKFFSE4FgEDAQECAQE?= =?us-ascii?q?CbRwMhToBAQUtXAIBCBEEAQEkBAcyFAcBAQUDAQEEEwiDGoEdZA+nP4QwAoV?= =?us-ascii?q?PHQWLUheBQT+BEYJdBy6BQYFaAQEDghSFJAKONpAVCQKGYIJigkmEXR+QLoM?= =?us-ascii?q?piTGJZgIRFIEmNCGBVXAVgyeCT4hKhT5vjFaBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,414,1534809600"; d="scan'208,217";a="189505979" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 04:47:30 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w9N4lU51009980 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Oct 2018 04:47:30 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 23:47:29 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Mon, 22 Oct 2018 23:47:29 -0500 From: "Ketan Talaulikar (ketant)" To: SPRING WG List Thread-Topic: [Idr] WG LC on changes for draft-ietf-idr-bgp-ls-segment-routing-ext-10 (10/20/2018 to 10/26/2018) Thread-Index: AdRodeLZjjWEFbtqS06VisslSTyGDQBYpQ9QACyvMEA= Date: Tue, 23 Oct 2018 04:47:29 +0000 Message-ID: <6315e48e489e4f9eb7af83643ce72c74@XCH-ALN-008.cisco.com> References: <058401d46876$01952c10$04bf8430$@ndzh.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.24.41.46] Content-Type: multipart/alternative; boundary="_000_6315e48e489e4f9eb7af83643ce72c74XCHALN008ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: [spring] FW: [Idr] WG LC on changes for draft-ietf-idr-bgp-ls-segment-routing-ext-10 (10/20/2018 to 10/26/2018) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 04:47:34 -0000 --_000_6315e48e489e4f9eb7af83643ce72c74XCHALN008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - the BGP-LS SR extensions are going through another short WGLC in IDR = due to the changes done as part of early reviews and shepherd's comments. From: Ketan Talaulikar (ketant) Sent: 22 October 2018 23:15 To: 'Susan Hares' ; idr@ietf.org Cc: 'Robert Raszuk' Subject: RE: [Idr] WG LC on changes for draft-ietf-idr-bgp-ls-segment-routi= ng-ext-10 (10/20/2018 to 10/26/2018) Hi Sue/All, We've received some comments from Robert regarding some text that needs to = be corrected to clarify where the new TLVs are included in the BGP-LS Attri= bute. Also, on a few errors in code-point references for other drafts. Than= ks to Robert for catching these. An updated version 11 of the draft has just been posted to address these co= mments. Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 20 October 2018 18:39 To: idr@ietf.org Subject: [Idr] WG LC on changes for draft-ietf-idr-bgp-ls-segment-routing-e= xt-10 (10/20/2018 to 10/26/2018) Greetings: During the review process of draft-ietf-idr-bgp-ls-segment-routing-ext draf= t there have been a number of changes to the draft. Due to the number of = changes, it is important to do a working group last call on the changes. = This call will end on 10/26/2018. It is the intent of the WG chairs forw= ard this draft to the IESG for publication on 10/26/2018. For your ease, the latest version is at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-10 Susan Hares IDR co-chair --_000_6315e48e489e4f9eb7af83643ce72c74XCHALN008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI = 211; the BGP-LS SR extensions are going through another short WGLC in IDR d= ue to the changes done as part of early reviews and shepherd’s commen= ts.

&n= bsp;

&n= bsp;

From: Ketan Talaulikar (ketant)
Sent: 22 October 2018 23:15
To: 'Susan Hares' <shares@ndzh.com>; idr@ietf.org
Cc: 'Robert Raszuk' <robert@raszuk.net>
Subject: RE: [Idr] WG LC on changes for draft-ietf-idr-bgp-ls-segmen= t-routing-ext-10 (10/20/2018 to 10/26/2018)

 

Hi Sue/= All,

&n= bsp;

We̵= 7;ve received some comments from Robert regarding some text that needs to b= e corrected to clarify where the new TLVs are included in the BGP-LS Attrib= ute. Also, on a few errors in code-point references for other drafts. Thanks to Robert for catching these.

&n= bsp;

An upda= ted version 11 of the draft has just been posted to address these comments.=

&n= bsp;

Thanks,=

Ketan

&n= bsp;

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: 20 October 2018 18:39
To: idr@ietf.org
Subject: [Idr] WG LC on changes for draft-ietf-idr-bgp-ls-segment-ro= uting-ext-10 (10/20/2018 to 10/26/2018)

 

Greetings:

 

During the review process of draft-ietf-idr-bgp-ls-s= egment-routing-ext draft there have been a number of changes to the draft. =   Due to the number of changes, it is important to do a working g= roup last call on the changes.   This call will end on 10/26/2018.    It is the intent of the WG chairs for= ward this draft to the IESG for publication on 10/26/2018.

 

For your ease, the latest version is at:   = ;

https://tools.ietf.org/html/draft-ietf-idr= -bgp-ls-segment-routing-ext-10

 

Susan Hares

IDR co-chair

 

--_000_6315e48e489e4f9eb7af83643ce72c74XCHALN008ciscocom_-- From nobody Mon Oct 22 21:49:11 2018 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 9A646130E7E for ; Mon, 22 Oct 2018 21:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.969 X-Spam-Level: X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 cVrf79djESaJ for ; Mon, 22 Oct 2018 21:49:07 -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 EBE58130E7F for ; Mon, 22 Oct 2018 21:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5634; q=dns/txt; s=iport; t=1540270147; x=1541479747; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+NMGKV16fOzT1JAA3Zv9r0k7sou+IzE9047WW4y8yzs=; b=R2rSSInHbjvJrSxjtyXROv0XoKOa7kB6I3Ar3zMOUubmjtDottvMUyzU FHNBWvdYUiDaOYaTAQ6MF3I87aUprieDZvT/X2Ebkrnn0tvp/hBy02Lhi pE83GFG13A+CJXKu4zuJ+xub8ag9EEaRUpsTojKEVQe+tgikM/EVeb26v g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AABop85b/4oNJK1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBZYEOd2Z/KAqYIIINjmyCXgOCNYUNCwEBI4RJAoUVITgWAQMBAQI?= =?us-ascii?q?BAQJtHAyFOgEBAQQtXAIBCBEEAQEkCzIbAQEFAwEBBBMIgxqBHWQPpz+EMAK?= =?us-ascii?q?FTx0Fi1IXgUE/gRGDEoFBgVoBAQOHOAKONpAVCQKGYIJigkmEXR+QLoJiR4k?= =?us-ascii?q?xiWYCERSBJjQhgT4PCHAVgyeCT4hKhT5vjFaBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,414,1534809600"; d="scan'208,217";a="189484874" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 04:49:06 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w9N4n66n027605 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Oct 2018 04:49:06 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 23:49:05 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Mon, 22 Oct 2018 23:49:05 -0500 From: "Ketan Talaulikar (ketant)" To: SPRING WG List Thread-Topic: [Idr] draft-ietf-idr-bgpls-segment-routing-epe-17 - 1 week review of changes (10/20/2018 to 10/26/2018). Thread-Index: AdRoc/eEEkdbz0ikQxSRjIJ4bOXiNACF6tww Date: Tue, 23 Oct 2018 04:49:05 +0000 Message-ID: References: <056b01d46874$a0db7920$e2926b60$@ndzh.com> In-Reply-To: <056b01d46874$a0db7920$e2926b60$@ndzh.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.24.41.46] Content-Type: multipart/alternative; boundary="_000_d51ce31236e84d03a07cb30c36057ffaXCHALN008ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: [spring] FW: [Idr] draft-ietf-idr-bgpls-segment-routing-epe-17 - 1 week review of changes (10/20/2018 to 10/26/2018). X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 04:49:09 -0000 --_000_d51ce31236e84d03a07cb30c36057ffaXCHALN008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - the BGP-LS SR EPE extensions are going through another short WGLC in = IDR due to the significant editorial changes done as part of early reviews = and shepherd's comments. From: Idr On Behalf Of Susan Hares Sent: 20 October 2018 18:29 To: idr@ietf.org Subject: [Idr] draft-ietf-idr-bgpls-segment-routing-epe-17 - 1 week review = of changes (10/20/2018 to 10/26/2018). Greetings: During the review process of draft-ietf-idr-bgpls-segment-routing-epe draft= there has been a number of changes to the draft. Due to the number of ch= anges, it is important to do a working group last call on the changes. Th= is call will end on 10/26/2018. It is the intent of the WG chairs forwar= d this draft to the IESG for publication on 10/26/2018. The WG should examine changes between version -13 and -17.txt. For your ea= se, -17.txt is at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-17 Susan Hares IDR co-chair --_000_d51ce31236e84d03a07cb30c36057ffaXCHALN008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI = 211; the BGP-LS SR EPE extensions are going through another short WGLC in I= DR due to the significant editorial changes done as part of early reviews a= nd shepherd’s comments.

&n= bsp;

&n= bsp;

From: Idr <idr-bounces@ietf.org> On = Behalf Of Susan Hares
Sent: 20 October 2018 18:29
To: idr@ietf.org
Subject: [Idr] draft-ietf-idr-bgpls-segment-routing-epe-17 - 1 week = review of changes (10/20/2018 to 10/26/2018).

 

Greetings:

 

During the review process of draft-ietf-idr-bgpls-se= gment-routing-epe draft there has been a number of changes to the draft. &n= bsp; Due to the number of changes, it is important to do a working gro= up last call on the changes.   This call will end on 10/26/2018.    It is the intent of the WG chairs for= ward this draft to the IESG for publication on 10/26/2018.

 

The WG should examine changes between version -13 an= d -17.txt.  For your ease, -17.txt is at:

 

https://tools.ietf.org/html/draft-ietf-idr-= bgpls-segment-routing-epe-17

 

Susan Hares

IDR co-chair

 

 

 

 

--_000_d51ce31236e84d03a07cb30c36057ffaXCHALN008ciscocom_-- From nobody Mon Oct 22 21:50:28 2018 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 11877130E89 for ; Mon, 22 Oct 2018 21:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 B3QUF9wSa4c8 for ; Mon, 22 Oct 2018 21:50:23 -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 46FD4130E7F for ; Mon, 22 Oct 2018 21:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21924; q=dns/txt; s=iport; t=1540270223; x=1541479823; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qm4Q42QeLActsZsDTnUl00nODYEab9dSD00acYq08wY=; b=aPkbj3/Wv/Tb+qrb5eByMDM3FG0YSZlAF/8WaqDrwBPBBzw+C+DKCsMZ r0K6ROXDdThkeLJGfWP5UB0BDbBCWVx5HyiGQVwQJe31FFttcQZ6Mdgvt jIG4toXWepneicJvBEOzyQy5nGs9FOj8IorifffpQB/pD8Z8d9ToR4T3L Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABop85b/4cNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCoNriBiMHYINlxWBegsBASW?= =?us-ascii?q?ERwIXhH4hNA0NAQMBAQIBAQJtHAyFOgEBAQQjVAIQAgEIEQMBAisCAgIwGwE?= =?us-ascii?q?BBQMCBAENBYMhAYEdZA+mEYEuhDACDEA9hGiLUheBQT+BECgfgkyDGwEBAgE?= =?us-ascii?q?BFoFnBhiCRTGCJgKJZoRQFYV9igMJAoZgihAXgVJMhCeJaYkngzOJZgIRFIE?= =?us-ascii?q?mHTiBVXAVGiEqAYJBCYsQhT5vAYxVgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,414,1534809600"; d="scan'208,217";a="189485298" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 04:50:22 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w9N4oLqC006632 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 04:50:22 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 00:50:20 -0400 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 00:50:21 -0400 From: "Zafar Ali (zali)" To: "spring@ietf.org" , Greg Mirsky CC: "Zafar Ali (zali)" Thread-Topic: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt Thread-Index: AQHUalVLRamQ9+4BoUaFJWPII5O64aUsQyIA Date: Tue, 23 Oct 2018 04:50:21 +0000 Message-ID: References: <154024675512.13647.2522788833729168667.idtracker@ietfa.amsl.com> In-Reply-To: <154024675512.13647.2522788833729168667.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.251.66] Content-Type: multipart/alternative; boundary="_000_A5B120097EBC4D0A9FDC5D054570E229ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.159, xch-rtp-019.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 04:50:27 -0000 --_000_A5B120097EBC4D0A9FDC5D054570E229ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZyBhbmQgdGhlIFdHLA0KDQpXZSBoYXZlIHVwZGF0ZSBkcmFmdC1hbGktc3ByaW5nLWJm ZC1zci1wb2xpY3kgdG8gYWRkcmVzcyBjb21tZW50cyB3ZSByZWNlaXZlZCBvbiB0aGUgbGlzdCBv ciBkdXJpbmcgV0cgc2Vzc2lvbiBwcmVzZW50YXRpb24uIFRoaXMgaW5jbHVkZXMgY29tbWVudCBv biBjb250cm9sbGluZyB0aGUgcmV0dXJuIHBhdGguDQoNCkNhbiB5b3UgcGxlYXNlIHJldmlldyB0 aGUgY2hhbmdlcyBhbmQgYWR2aXNlIG9mIHlvdXIgY29tbWVudHM/DQoNClRoYW5rcw0KDQpSZWdh cmRzIOKApiBaYWZhcg0KDQpGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPg0KRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDE4IGF0IDY6 MTkgUE0NClRvOiAiTmFnZW5kcmEgS3VtYXIgTmFpbmFyIChuYWlrdW1hcikiIDxuYWlrdW1hckBj aXNjby5jb20+LCAiS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSIgPGtldGFudEBjaXNjby5jb20+ LCAiWmFmYXIgQWxpICh6YWxpKSIgPHphbGlAY2lzY28uY29tPiwgIkNhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKSIgPGNwaWduYXRhQGNpc2NvLmNvbT4sICJDbGFyZW5jZSBGaWxzZmlscyAoY2Zp bHNmaWwpIiA8Y2ZpbHNmaWxAY2lzY28uY29tPiwgIk5hZ2VuZHJhIEt1bWFyIE5haW5hciAobmFp a3VtYXIpIiA8bmFpa3VtYXJAY2lzY28uY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3ktMDIudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMi50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmFnZW5kcmEgS3VtYXIgTmFpbmFy IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICAg ICAgICAgZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5DQpSZXZpc2lvbjogICAgICAgICAg ICAgIDAyDQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJk aW5nIERldGVjdGlvbiAoQkZEKSBmb3IgU2VnbWVudCBSb3V0aW5nIFBvbGljaWVzIGZvciBUcmFm ZmljIEVuZ2luZWVyaW5nDQpEb2N1bWVudCBkYXRlOiAgICAgICAgICAgICAgIDIwMTgtMTAtMjIN Ckdyb3VwOiAgICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAg ICAgICAgICAgICAgICAgIDExDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMi50eHQNClN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbGkt c3ByaW5nLWJmZC1zci1wb2xpY3kvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMg0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWxpLXNwcmlu Zy1iZmQtc3ItcG9saWN5DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMg0KDQpBYnN0cmFjdDoN CiAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93cyBhIGhlYWRlbmQgbm9kZSB0byBzdGVlciBh IHBhY2tldCBmbG93DQogICBhbG9uZyBhbnkgcGF0aCB1c2luZyBhIHNlZ21lbnQgbGlzdCB3aGlj aCBpcyByZWZlcnJlZCB0byBhcyBhIFNSDQogICBQb2xpY3kuICBJbnRlcm1lZGlhdGUgcGVyLWZs b3cgc3RhdGVzIGFyZSBlbGltaW5hdGVkIHRoYW5rcyB0byBzb3VyY2UNCiAgIHJvdXRpbmcuICBU aGUgaGVhZGVyIG9mIGEgcGFja2V0IHN0ZWVyZWQgaW4gYW4gU1IgUG9saWN5IGlzIGF1Z21lbnRl ZA0KICAgd2l0aCB0aGUgb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGFzc29jaWF0ZWQgd2l0aCB0 aGF0IFNSIFBvbGljeS4NCiAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJG RCkgaXMgdXNlZCB0byBtb25pdG9yIGRpZmZlcmVudA0KICAga2luZHMgb2YgcGF0aHMgYmV0d2Vl biBub2RlLiAgQkZEIG1lY2hhbmlzbXMgY2FuIGJlIGFsc28gdXNlZCB0bw0KICAgbW9uaXRvciB0 aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBwYXRoIGluZGljYXRlZCBieSBhIFNSIFBvbGljeSBhbmQg dG8NCiAgIGRldGVjdCBhbnkgZmFpbHVyZXMuICBTZWFtbGVzcyBCRkQgKFMtQkZEKSBleHRlbnNp b25zIHByb3ZpZGUgYQ0KICAgc2ltcGxpZmllZCBtZWNoYW5pc20gd2hpY2ggaXMgc3VpdGFibGUg Zm9yIG1vbml0b3Jpbmcgb2YgcGF0aHMgdGhhdA0KICAgYXJlIHNldHVwIGR5bmFtaWNhbGx5IGFu ZCBvbiBhIGxhcmdlIHNjYWxlLg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNl IG9mIFNlYW1sZXNzIEJGRCAoUy1CRkQpIG1lY2hhbmlzbSB0bw0KICAgbW9uaXRvciB0aGUgU1Ig UG9saWNpZXMgdGhhdCBhcmUgdXNlZCBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIGluDQog ICBTUiBkZXBsb3ltZW50cy4NCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_A5B120097EBC4D0A9FDC5D054570E229ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgR3JlZyBhbmQgdGhlIFdHLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ug aGF2ZSB1cGRhdGUgZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5IHRvIGFkZHJlc3MgY29t bWVudHMgd2UgcmVjZWl2ZWQgb24gdGhlIGxpc3Qgb3IgZHVyaW5nIFdHIHNlc3Npb24gcHJlc2Vu dGF0aW9uLiBUaGlzIGluY2x1ZGVzIGNvbW1lbnQgb24gY29udHJvbGxpbmcgdGhlIHJldHVybiBw YXRoLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcGxlYXNlIHJldmlldyB0aGUg Y2hhbmdlcyBhbmQgYWR2aXNlIG9mIHlvdXIgY29tbWVudHM/DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VGhhbmtzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPlJlZ2FyZHMg4oCmIFphZmFyDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZx dW90OyAmbHQ7aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5N b25kYXksIE9jdG9iZXIgMjIsIDIwMTggYXQgNjoxOSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7 TmFnZW5kcmEgS3VtYXIgTmFpbmFyIChuYWlrdW1hcikmcXVvdDsgJmx0O25haWt1bWFyQGNpc2Nv LmNvbSZndDssICZxdW90O0tldGFuIFRhbGF1bGlrYXIgKGtldGFudCkmcXVvdDsgJmx0O2tldGFu dEBjaXNjby5jb20mZ3Q7LCAmcXVvdDtaYWZhciBBbGkgKHphbGkpJnF1b3Q7ICZsdDt6YWxpQGNp c2NvLmNvbSZndDssICZxdW90O0NhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSZxdW90OyAmbHQ7 Y3BpZ25hdGFAY2lzY28uY29tJmd0OywgJnF1b3Q7Q2xhcmVuY2UgRmlsc2ZpbHMgKGNmaWxzZmls KSZxdW90OyAmbHQ7Y2ZpbHNmaWxAY2lzY28uY29tJmd0OywNCiAmcXVvdDtOYWdlbmRyYSBLdW1h ciBOYWluYXIgKG5haWt1bWFyKSZxdW90OyAmbHQ7bmFpa3VtYXJAY2lzY28uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFsaS1z cHJpbmctYmZkLXNyLXBvbGljeS0wMi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvYT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmFnZW5kcmEgS3VtYXIgTmFpbmFyIGFuZCBwb3N0ZWQg dG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SUVU RiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pk5hbWU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5kcmFmdC1hbGktc3ByaW5nLWJmZC1zci1w b2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5SZXZp c2lvbjo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ VGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5C aWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGZvciBTZWdtZW50IFJvdXRp bmcgUG9saWNpZXMgZm9yIFRyYWZmaWMgRW5naW5lZXJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Eb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+MjAxOC0xMC0y MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkdyb3VwOjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+UGFnZXM6PHNwYW4gY2xhc3M9ImFw cGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj4xMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0w Mi50eHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbGktc3ByaW5nLWJmZC1zci1w b2xpY3ktMDIudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+U3Rh dHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsaS1z cHJpbmctYmZkLXNyLXBvbGljeS8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsaS1zcHJp bmctYmZkLXNyLXBvbGljeS88L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWxpLXNwcmluZy1iZmQt c3ItcG9saWN5LTAyIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9s aWN5LTAyPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SHRtbGl6ZWQ6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1hbGktc3ByaW5nLWJmZC1z ci1wb2xpY3kiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWxpLXNwcmluZy1iZmQt c3ItcG9saWN5PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+RGlmZjom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+QWJzdHJhY3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7IFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93cyBhIGhl YWRlbmQgbm9kZSB0byBzdGVlciBhIHBhY2tldCBmbG93PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7IGFsb25nIGFueSBwYXRoIHVzaW5n IGEgc2VnbWVudCBsaXN0IHdoaWNoIGlzIHJlZmVycmVkIHRvIGFzIGEgU1I8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgUG9saWN5LiZu YnNwOyZuYnNwO0ludGVybWVkaWF0ZSBwZXItZmxvdyBzdGF0ZXMgYXJlIGVsaW1pbmF0ZWQgdGhh bmtzIHRvIHNvdXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiZuYnNwOyZuYnNwOyByb3V0aW5nLiZuYnNwOyZuYnNwO1RoZSBoZWFkZXIgb2YgYSBwYWNr ZXQgc3RlZXJlZCBpbiBhbiBTUiBQb2xpY3kgaXMgYXVnbWVudGVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7IHdpdGggdGhlIG9yZGVy ZWQgbGlzdCBvZiBzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGggdGhhdCBTUiBQb2xpY3kuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7IEJp ZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgdXNlZCB0byBtb25pdG9y IGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PiZuYnNwOyZuYnNwOyBraW5kcyBvZiBwYXRocyBiZXR3ZWVuIG5vZGUuJm5ic3A7Jm5ic3A7QkZE IG1lY2hhbmlzbXMgY2FuIGJlIGFsc28gdXNlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyBtb25pdG9yIHRoZSBhdmFpbGFiaWxp dHkgb2YgdGhlIHBhdGggaW5kaWNhdGVkIGJ5IGEgU1IgUG9saWN5IGFuZCB0bzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyBkZXRlY3Qg YW55IGZhaWx1cmVzLiZuYnNwOyZuYnNwO1NlYW1sZXNzIEJGRCAoUy1CRkQpIGV4dGVuc2lvbnMg cHJvdmlkZSBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ Jm5ic3A7Jm5ic3A7IHNpbXBsaWZpZWQgbWVjaGFuaXNtIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBt b25pdG9yaW5nIG9mIHBhdGhzIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgYXJlIHNldHVwIGR5bmFtaWNhbGx5IGFuZCBvbiBh IGxhcmdlIHNjYWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIFNlYW1sZXNz IEJGRCAoUy1CRkQpIG1lY2hhbmlzbSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyBtb25pdG9yIHRoZSBTUiBQb2xpY2llcyB0aGF0 IGFyZSB1c2VkIGZvciBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkgaW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgU1IgZGVwbG95bWVu dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A5B120097EBC4D0A9FDC5D054570E229ciscocom_-- From nobody Mon Oct 22 21:50:38 2018 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 B3F04130EB9 for ; Mon, 22 Oct 2018 21:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.20150623.gappssmtp.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 gWqXKlDLITz5 for ; Mon, 22 Oct 2018 21:50:25 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 370FD1288BD for ; Mon, 22 Oct 2018 21:50:25 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id c32so56794otb.8 for ; Mon, 22 Oct 2018 21:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hhmp3qCpaCnmX/X+5LTOLLj291UfU5bES68AR5JFokI=; b=0xKHBkqPDclnxf5OrdZMSunLZhxX5xlUj23VzAldNlx1XGqKE2qdugYP86Qo7nEPFM ZZRo6g09WMxB1ATMtKplfqwiKKbPHDK0OgB8120gc9IHIDNh11QvYWIkqrF3tGAJCPAU vfCjfE0TrZlunmCL3ITW/3o8hSd8IHxmMOwcW8gjuTyYrwyYEEaceqVqpCGX+UZyuOJL +sralEQAanJxnOBOpNz9s2HywnnZ0Kfon2ONGC+HT/PsJrvjE2Kf12GnR1Cjbr1qOmrC HVN5CT3HYx/R6ZlgESUNvT9EFo1kniRMvfZ0cCiMRPdNRL4KCEMTxgzRoKJggwtarzFn TuYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hhmp3qCpaCnmX/X+5LTOLLj291UfU5bES68AR5JFokI=; b=CGVscBV/Ogt7tvXDUrNtTr4sow68MacB4l4P0JcraY599lGUosQNHsdNyn6gZLQMU1 ki2O+dZ+Dss1J+3S3yAxDFUhW1srEoo854tnrYat3cfTY9jim3cx2pNNei6Tvm5ItaxB schJVqcGiV4HosMVQ+tL1PzXrUKZk00XRf+IL6TV4K+G14dbkErlzMfMs5bCDNqe4L5j Ks6XEj9R6FXKSSNWSXJvmn0uQqWlZc4vgGsQM+j6AgP6uO2MAyUsFBHzG4C/wCvc8Eoc zokF9ri4nm5myazNdufKHljff67vsTTKrINVMJ23SHFkOMZ8OD+inTqTqn+t5F0DYWdm Ih1A== X-Gm-Message-State: ABuFfoiNj5H7gNrbiC9MemK0ABlkIsT2Ih6rqHBcXmvhs6xlTWLA+niB HD9kZumMbmSMziDfB6FMLE9V+UKAi9JCQcTvvmLaUA== X-Google-Smtp-Source: ACcGV61a530HS/EEdSRi3Mu6bKQMFh3+OgRkMmnuATYaa45QKApoxytQcXFqAqiXKZQiZERNmk7Ccn9/uDcuEqgaF0M= X-Received: by 2002:a9d:3e50:: with SMTP id h16mr28083332otg.8.1540270224041; Mon, 22 Oct 2018 21:50:24 -0700 (PDT) MIME-Version: 1.0 References: <3470b63ec7264ac096e326a59d97b50f@XCH-ALN-008.cisco.com> In-Reply-To: <3470b63ec7264ac096e326a59d97b50f@XCH-ALN-008.cisco.com> From: Rob Shakir Date: Mon, 22 Oct 2018 21:50:12 -0700 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: Rob Shakir , SPRING WG List , "draft-filsfils-spring-sr-policy-considerations@tools.ietf.org" Content-Type: multipart/alternative; boundary="0000000000009009440578de1be0" Archived-At: Subject: Re: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 04:50:36 -0000 --0000000000009009440578de1be0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ketan, Authors, Thanks for the update. Further responses are in-line marked [rjs]. My key feedback here is that I feel like we're not really on the same page as to what this draft is trying to communicate. Perhaps if we agreed this, then it'd be clearer what the right direction for the document is. I'd really encourage the WG to read this doc and provide the authors with feedback -- especially if you have an implementation, or are implementing SR-TE Policy in your network. On Thu, 18 Oct 2018 at 19:10 Ketan Talaulikar (ketant) wrote: > > > - (2) What is the intention of the diagram shown in this section? It > seems to be completely an implementation detail that an implementation= has > the "SRPM" that acts as a central resolution point. For instance, what > should a reader learn from the fact that the SRPM is not a standard RI= B > resolution process? If there are suggestions that one wants this > implementation - should there be some discussion of the complexity of = this > new API between say, the BGP daemon and a general RIB process? > > *[KT] **We will clarify in the text that the section provides a > conceptual overview of components/functionality that work with each other > to implement SR Policy on a headend. The intention is not to define APIs > between the blocks since those are implementation details. We have severa= l > drafts related to the SR Policy functionality =E2=80=93 besides the archi= tecture > draft, there are extensions to BGP (BGP-SRTE & LS), PCEP then we have Yan= g > model. This draft puts these blocks into reference so implementers get an > idea of the functionality that maps to say BGP and the SR Policy processe= s > (e.g. draft-ietf-idr-segment-routing-te-policy).* > > - (2) My general feedback on this section is that this is > implementation discussion, that does not add to the IETF content that = we > are publishing within SPRING. Like we have had discussion of use case > drafts, I think this is similar but from the implementor side. I'd lik= e to > discuss the value that this content has. > > *[KT] **There is a difference between documenting implementation details > and providing a conceptual overview of the implementation aspects. > Especially when defining an architecture which involves multiple protocol= s > and functional blocks. I find it valuable as an implementer myself.* > [rjs] I don't think that the edits that are made to this section particularly add anything. If the intention is the conceptual overview, I don't understand why we refer to say, the "SRP process". Conceptually, shouldn't this be describing interaction between functional blocks? i.e., we have a functional block in the architecture that is responsible for learning candidate paths (it's an implementation detail from where...), and selects the active path, installing it into the RIB or FIB. If the intention is to have this be conceptual, my suggestion would be to make the language refer to architectural concepts - rather than what seem to be realisations of the idea, and to convert the diagrams into lists that describe what each block is doing. Others may have thoughts on this too - especially where they have other implementations. > > - (3.1) I think that this section has some useful content, but it's > buried by starting out by defining the algorithms.. Why not make this > section be focused towards the constraints that must be considered whe= n > calculating a SID stack for a particular path. i.e., the key points se= em to > be: > > > - Use of the IGP metric as the metric for path optimisation is > desirable, especially in constrained push or readable depth environ= ments, > because it allows the minimum number of deviations from the shortes= t path > and therefore labels. > - If a different metric is used, then this implies that every time > that metric differs from the IGP metric, then this will result in > additional SIDs. > > > - There is no mention of flex-algorithm in this section. It seems > relevant given that you can also mitigate the problem that is tr= ying to be > solved here by having a set of prefix SIDs per metric. > > *[KT] **We will put a forward reference to the Flex Algo section here.* > > - It may be advantageous to sacrifice optimality of the path > calculation solution by relaxing the optimisation constraints. > > > - The draft should talk about the operational considerations here - > i.e., it implies that you can actually tolerate the margin in th= e > optimisation objective for the service. > - The "just pick the best you can do within N SIDs" is > dangerous, since it means that the network delivers a service th= at *isn't* > what the operator asked for - which may result in service degrad= ation > (e.g., consider live/live where there is a maximum latency diffe= rence that > is tolerable between the two feeds). > > *[KT] **We will add text clarifying this aspect. However, the point is > also that the operator may be OK with the =E2=80=9Cbest possible=E2=80=9D= and so such an > option may be useful in some deployments.* > [rjs] I don't think that we agree at all on whether this section is useful in its current form. What is the message that we're trying to convey in this section of the document? If it is that there are possible algorithms that may be used by an operator dependent on their service, I'm not clear that we need to document this. The value to me *would be* that we cover some of the caveats of calculating policies that are specific to SR -- i.e., SID stack depth being something that is influenced by divergence from the shortest path, and the fact that we might need to sacrifice the optimal solution to pathing based on these constraints, then I think it'd be useful. The current text does not get this across clearly. > > - (3.2) I'm unclear of the value of this text. It seems to me that > we're restating some of the optimisation objectives that are known for > general TE (and, for example, are described by - say RFC3209). What is= it > that we're trying to communicate to the reader here -- can it be cover= ed by > "existing path calculation considerations, such as resource affinity > [rfc3209] can be applied to the path calculation of SR paths"? > > *[KT] **We do not assume that anyone that is deploying SR Policies is > familiar with RSVP-TE. RFC3209 does cover resource affinity but not the > others. Some of the constraints are unique to SR. Hence, there is a value > in specifying the available constraints.* > [rjs]: Again, we might have to agree to disagree here. I did not make an assertion that someone was familiar with RSVP-TE, but that they were familiar with *TE* -- there are networks that meet these constraints that do not use SR or RSVP-TE.... Again, I'd find it very useful to understand what the authors are trying to communicate in this section. If it's that there are particular trade-offs, sure, let's find new wording -- but if not, then I'm not clear why SPRING needs to standardise an incomplete list of optimisation criteria. > > - (3.4) I'm again going to question the value of this section -- it > doesn't seem to give enough detail of the algorithm that you're propos= ing > to be generally useful, and points out it is a node-local behaviour. I= f > there's a desire to get to a common understanding of how to take a pat= h and > compress its SID stack, then let's write this out. > > *[KT] **Agree that this is a node local behavior. However, the high level > description does indicate how an implementation could go about determinin= g > a path to a SID in an efficient manner.* > [rjs]: If there's really value in this high-level description (I'm not sure I agree...) -- it seems like then restructuring this section to write out the algorithm then use it to illustrate how it operates on a network after this. > > - (4) See my comments on Section 2 of this document, why is describing > how the interaction between different processes within what sounds lik= e a > single implementation something that we should publish within the IETF= ? > > *[KT] **These examples are important to illustrate how the candidate path > selection tiebreaker rules work in different conditions. The interactions > are also valuable to understand the selection which happens say within BG= P > (based on its best path) for BGP-SRTE and the selection that then happens > at SR Policy level. This section was originally placed in the Appendix of > the SR Policy Architecture draft since the candidate path selection > tiebreaker rules were specified in that draft. Later was move to this > informational draft.* > [rjs]: In my view, this example would be best _as succinctly_ as possible to demonstrate the preferences in the actual draft. It seems to me that the explanations themselves are quite wordy to make a couple of clear points: - BGP path selection is unaffected by SR-TE policy. - If a protocol does not make its own path selection, then SR-TE policy attributes are considered to differentiate between them. etc. Ideally, this should be clear in the policy architecture draft itself. If it can't be made clear, then I think we should seriously consider whether we have the right level of complexity here. > > - (5+5.1+5.2) The core point that seems to be being made here is that > - within a single IGP area the head-end has all the visibility it requ= ires; > if there are multiple areas, there are ways that a head-end could get > access to the areas that it is not part of (e.g., BGP-LS). Is anything= more > being said here? Do the implementation details that there are BGP-LS R= Rs > actually matter? > > *[KT] **The intention is to provide guidance for some of the deployment > options for achieving this functionality.* > > - (5.3) Similarly to the above, this seems to assume one particular > mechanism of building a centralised system, that doesn't need any new > extensions in the IETF. Is this something that we need to document? > > *[KT] **We explain while taking an example of a mechanism based on IETF > standards that is available for operators looking to deploy this model.* > > - (6.2) This section seems to imply that there can never be > allocations from the SRLB that are not dynamically advertised via some > other protocol. Is this really true? > > *[KT] **I don=E2=80=99t believe this was the intention. We will clarify t= his in > the text.* > > - (8) Given that there is a separate draft discussing this -- what is > the motivation to have this in this document? > > *[KT] **This section gives and overview of the proposal with an example > of optical circuit. It also clarifies that the concept described is > applicable not just for optical links but in general to other types of > layer 2 circuits and tunnels as well. The draft-anand-spring-poi-sr goes > into the details of the use-case, protocol mechanism and extensions > specifically for optical networks only.* > [rjs]: For the above points -- I think we've clearly seen in the WG and IESG that there is not a huge amount of appetite to publish use case drafts. From an operational perspective, I also don't really find these sections that useful since they don't really give me enough information to be able to figure out an implementation. I'd be interested whether the working group thinks that they are sufficiently of interest to include in this document. Cheers, r. > Thanks, > > r. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000009009440578de1be0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ketan, Authors,

Thanks for the update. = Further responses are in-line marked [rjs].=C2=A0

= My key feedback here is that I feel like we're not really on the same p= age as to what this draft is trying to communicate. Perhaps if we agreed th= is, then it'd be clearer what the right direction for the document is.<= /div>

I'd really encourage the WG to read this doc a= nd provide the authors with feedback -- especially if you have an implement= ation, or are implementing SR-TE Policy in your network.

On Thu, 18 Oct 2018 at 19:10 Ketan = Talaulikar (ketant) <ketant@cisco.co= m> wrote:


  • (2) What is the intention of the diagram shown in this section? It seems to= be completely an implementation detail that an implementation has the &quo= t;SRPM" that acts as a central resolution point. For instance, what sh= ould a reader learn from the fact that the SRPM is not a standard RIB resolution process? If there are suggestions th= at one wants this implementation - should there be some discussion of the c= omplexity of this new API between say, the BGP daemon and a general RIB pro= cess?

[KT] We will= clarify in the text that the section provides a conceptual overview of com= ponents/functionality that work with each other to implement SR Policy on a= headend. The intention is not to define APIs between the blocks since those are implementation details. We = have several drafts related to the SR Policy functionality =E2=80=93 beside= s the architecture draft, there are extensions to BGP (BGP-SRTE & LS), = PCEP then we have Yang model. This draft puts these blocks into reference so implementers get an idea of the functionali= ty that maps to say BGP and the SR Policy processes (e.g. draft-ietf-idr-se= gment-routing-te-policy).

=

<= div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
  • (2) My general feedback on this section is that this is implementation disc= ussion, that does not add to the IETF content that we are publishing within= SPRING. Like we have had discussion of use case drafts, I think this is si= milar but from the implementor side. I'd like to discuss the value that this content has.

[KT] There i= s a difference between documenting implementation details and providing a c= onceptual overview of the implementation aspects. Especially when defining = an architecture which involves multiple protocols and functional blocks. I find it valuable as an implementer myse= lf.


[r= js] I don't think that the edits that are made to this section particul= arly add anything. If the intention is the conceptual overview, I don't= understand why we refer to say, the "SRP process". Conceptually,= shouldn't this be describing interaction between functional blocks? i.= e., we have a functional block in the architecture that is responsible for = learning candidate paths (it's an implementation detail from where...),= and selects the active path, installing it into the RIB or FIB.
=
If the intention is to have this be conceptual, my suggestio= n would be to make the language refer to architectural concepts - rather th= an what seem to be realisations of the idea, and to convert the diagrams in= to lists that describe what each block is doing. Others may have thoughts o= n this too - especially where they have other implementations.
= =C2=A0

  • (3.1) I think that this section has some useful content, but it's burie= d by starting out by defining the algorithms.. Why not make this section be= focused towards the constraints that must be considered when calculating a= SID stack for a particular path. i.e., the key points seem to be:
    • Use of the IGP metric as the metric for path optimisation is desirable, esp= ecially in constrained push or readable depth environments, because it allo= ws the minimum number of deviations from the shortest path and therefore la= bels.
    • If a different metric is used, then this implies that every time that metri= c differs from the IGP metric, then this will result in additional SIDs.=
      • There is no mention of flex-algorithm in this section. It seems relevant gi= ven that you can also mitigate the problem that is trying to be solved here= by having a set of prefix SIDs per metric.

[KT] We will= put a forward reference to the Flex Algo section here.

    • It may be advantageous to sacrifice optimality of the path calculation solu= tion by relaxing the optimisation constraints.
      • The draft should talk about the operational considerations here - i.e., it = implies that you can actually tolerate the margin in the optimisation objec= tive for the service.
      • The "just pick the best you can do within N SIDs" is dangerous, s= ince it means that the network delivers a service that *isn't* what the= operator asked for - which may result in service degradation (e.g., consid= er live/live where there is a maximum latency difference that is tolerable between the two feeds).

[KT] We will= add text clarifying this aspect. However, the point is also that the opera= tor may be OK with the =E2=80=9Cbest possible=E2=80=9D and so such an optio= n may be useful in some deployments.


[rjs] I don't think that we agree at all= on whether this section is useful in its current form. What is the message= that we're trying to convey in this section of the document? If it is = that there are possible algorithms that may be used by an operator dependen= t on their service, I'm not clear that we need to document this. The va= lue to me *would be* that we cover some of the caveats of calculating polic= ies that are specific to SR -- i.e., SID stack depth being something that i= s influenced by divergence from the shortest path, and the fact that we mig= ht need to sacrifice the optimal solution to pathing based on these constra= ints, then I think it'd be useful. The current text does not get this a= cross clearly.
=C2=A0

  • (3.2) I'm unclear of the value of this text. It seems to me that we'= ;re restating some of the optimisation objectives that are known for genera= l TE (and, for example, are described by - say RFC3209). What is it that we= 're trying to communicate to the reader here -- can it be covered by "existing path calculation consideration= s, such as resource affinity [rfc3209] can be applied to the path calculati= on of SR paths"?

[KT] We do n= ot assume that anyone that is deploying SR Policies is familiar with RSVP-T= E. RFC3209 does cover resource affinity but not the others. Some of the con= straints are unique to SR. Hence, there is a value in specifying the available constraints.


[rjs]: Again, we might= have to agree to disagree here. I did not make an assertion that someone w= as familiar with RSVP-TE, but that they were familiar with *TE* -- there ar= e networks that meet these constraints that do not use SR or RSVP-TE.... Ag= ain, I'd find it very useful to understand what the authors are trying = to communicate in this section. If it's that there are particular trade= -offs, sure, let's find new wording -- but if not, then I'm not cle= ar why SPRING needs to standardise an incomplete list of optimisation crite= ria.
=C2=A0

  • (3.4) I'm again going to question the value of this section -- it doesn= 't seem to give enough detail of the algorithm that you're proposin= g to be generally useful, and points out it is a node-local behaviour. If t= here's a desire to get to a common understanding of how to take a path and compress its SID stack, then let's write thi= s out.

[KT] Agree t= hat this is a node local behavior. However, the high level description does= indicate how an implementation could go about determining a path to a SID = in an efficient manner.


[rjs]: If there's really value in this high-level des= cription (I'm not sure I agree...) -- it seems like then restructuring = this section to write out the algorithm then use it to illustrate how it op= erates on a network after this.
=C2=A0

  • (4) See my comments on Section 2 of this document, why is describing how th= e interaction between different processes within what sounds like a single = implementation something that we should publish within the IETF?<= /u>

[KT] These e= xamples are important to illustrate how the candidate path selection tiebre= aker rules work in different conditions. The interactions are also valuable= to understand the selection which happens say within BGP (based on its best path) for BGP-SRTE and the selec= tion that then happens at SR Policy level. This section was originally plac= ed in the Appendix of the SR Policy Architecture draft since the candidate = path selection tiebreaker rules were specified in that draft. Later was move to this informational draft.<= /span>


[rjs]:= In my view, this example would be best _as succinctly_ as possible to demo= nstrate the preferences in the actual draft. It seems to me that the explan= ations themselves are quite wordy to make a couple of clear points:

=C2=A0- BGP path selection is unaffected by SR-TE policy.=
=C2=A0- If a protocol does not make its own path selection, then= SR-TE policy attributes are considered to differentiate between them.
=C2=A0etc.

Ideally, this should be clear in = the policy architecture draft itself. If it can't be made clear, then I= think we should seriously consider whether we have the right level of comp= lexity here.
=C2=A0

=

  • (5+5.1+5.2) The core point that seems to be being made here is that - withi= n a single IGP area the head-end has all the visibility it requires; if the= re are multiple areas, there are ways that a head-end could get access to t= he areas that it is not part of (e.g., BGP-LS). Is anything more being said here? Do the implementation de= tails that there are BGP-LS RRs actually matter?

[KT] The int= ention is to provide guidance for some of the deployment options for achiev= ing this functionality.<= /p>

  • (5.3) Similarly to the above, this seems to assume one particular mechanism= of building a centralised system, that doesn't need any new extensions= in the IETF. Is this something that we need to document?

[KT] We expl= ain while taking an example of a mechanism based on IETF standards that is = available for operators looking to deploy this model.

  • (6.2) This section seems to imply that there can never be allocations from = the SRLB that are not dynamically advertised via some other protocol. Is th= is really true?

[KT] I don= =E2=80=99t believe this was the intention. We will clarify this in the text= .

<= div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
  • (8) Given that there is a separate draft discussing this -- what is the mot= ivation to have this in this document?

[KT] This se= ction gives and overview of the proposal with an example of optical circuit= . It also clarifies that the concept described is applicable not just for o= ptical links but in general to other types of layer 2 circuits and tunnels as well. The draft-anand-spring-poi-= sr goes into the details of the use-case, protocol mechanism and extensions= specifically for optical networks only.


[rjs]: For the above points -- I think w= e've clearly seen in the WG and IESG that there is not a huge amount of= appetite to publish use case drafts. From an operational perspective, I al= so don't really find these sections that useful since they don't re= ally give me enough information to be able to figure out an implementation.= I'd be interested whether the working group thinks that they are suffi= ciently of interest to include in this document.

C= heers,
r.
=C2=A0

Thanks,

r.

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000009009440578de1be0-- From nobody Mon Oct 22 22:03:03 2018 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 CC788130E7E; Mon, 22 Oct 2018 22:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.969 X-Spam-Level: X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 TkcwdXfs0IAK; Mon, 22 Oct 2018 22:02:51 -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 C39651288BD; Mon, 22 Oct 2018 22:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19186; q=dns/txt; s=iport; t=1540270970; x=1541480570; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fWrXaRGqdzLfEpxo7WxDMvWqOMQzP84VrZ4rGQJYg0A=; b=hO16GuG2OgT7RbTXTL3ZklLn/b0IbWoRAeJCa63NlP3dI+FgZ4VTpBOM A+gv7QChVBQdy2UlpSvK4JsT67qCp9rxZZz49u/2vjQOAKoCgIDhEL4qQ 8lRPn/Tfh7IsP37H7BNYdUv6imZfQNXpPJ0kfXSHXtMhcYxjQbnsBX+Pw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACgqs5b/5RdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCoNriBiMHYFoJYh6iFOFSBS?= =?us-ascii?q?BZgsBASOESQIXhQEhNA0NAQMBAQIBAQJtHAyFOgEBAQQjRBACEAIBCBEDAQI?= =?us-ascii?q?rAgICHxEbAQEFAwIEAQ0FgyEBgR1MAxUPphCBLoQwAgxAPYJDDYIYi1IXgUE?= =?us-ascii?q?/gREnDBOCTIJWRQEBAgEBgSUFARIBPx6CRTGCJgKJZoRQFYV9iVUuCQKGYIZ?= =?us-ascii?q?sgyQXgVJMhCeJaYxaeYhtAhEUgSYdOGRxcBUaISoBgkEJixCFPm8BizaBH4E?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.54,414,1534809600"; d="scan'208,217";a="470178547" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 05:02:49 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9N52nNQ027951 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 05:02:49 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 01:02:47 -0400 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 01:02:48 -0400 From: "Zafar Ali (zali)" To: "spring@ietf.org" , "ippm@ietf.org" CC: "Zafar Ali (zali)" Thread-Topic: New Version Notification for draft-ali-spring-ioam-srv6-00.txt Thread-Index: AQHUalnT5j34q1fcJk2TMDZjR9ZZW6UsRpOA Date: Tue, 23 Oct 2018 05:02:48 +0000 Message-ID: References: <154024869199.13647.14370745305459927374.idtracker@ietfa.amsl.com> In-Reply-To: <154024869199.13647.14370745305459927374.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.251.66] Content-Type: multipart/alternative; boundary="_000_BF79756437264923B4D1C5F8DF9ADD23ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.159, xch-rtp-019.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [spring] FW: New Version Notification for draft-ali-spring-ioam-srv6-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 05:02:53 -0000 --_000_BF79756437264923B4D1C5F8DF9ADD23ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRywNCg0KDQpXZSBoYXZlIHVwbG9hZGVkIGEgc3RyYWlnaHQgZm9yd2FyZCBkcmFmdCBv biBob3cgSU9BTSBkYXRhIGNhbiBiZSBjYXJyaWVkIGluIFNSdjYgbmV0d29yay4NCg0KDQoNClRo ZSBwdXJwb3NlIG9mIHRoaXMgZW1haWwgaXMgdG8gc29saWNpdCB5b3VyIGNvbW1lbnRzIG9uIHRo aXMgd29yay4gV2UgcGxhbiB0byBwcmVzZW50IHRoaXMgd29yayBpbiBTcHJpbmcgYW5kIGluIElQ UE0gV0dzIGF0IElFVEYxMDMuDQoNCg0KDQpMb29raW5nIGZvcndhcmQgdG8gYW55IGZlZWRiYWNr Lg0KDQpUaGFua3MNCg0KUmVnYXJkcyDigKYgWmFmYXIgKG9uIGJlaGFsZiBvZiB0aGUgY28tYXV0 aG9ycykuDQoNCkZyb206ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQpEYXRlOiBNb25kYXksIE9jdG9iZXIgMjIsIDIwMTggYXQgNjo1MSBQTQ0K VG86ICJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPiwgIk1hY2gg Q2hlbiAoR3VveWkpIiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+LCAiRnJhbmsgQnJvY2tuZXJzIChm YnJvY2tuZSkiIDxmYnJvY2tuZUBjaXNjby5jb20+LCAiTmFnZW5kcmEgS3VtYXIgTmFpbmFyIChu YWlrdW1hcikiIDxuYWlrdW1hckBjaXNjby5jb20+LCAiWmFmYXIgQWxpICh6YWxpKSIgPHphbGlA Y2lzY28uY29tPiwgIk5hZ2VuZHJhIEt1bWFyIE5haW5hciAobmFpa3VtYXIpIiA8bmFpa3VtYXJA Y2lzY28uY29tPiwgR2F1cmF2IERhd3JhIDxnZGF3cmEuaWV0ZkBnbWFpbC5jb20+LCAiQ2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpIiA8Y3BpZ25hdGFAY2lzY28uY29tPiwgTWFjaCBDaGVuIDxt YWNoLmNoZW5AaHVhd2VpLmNvbT4sICJjZihtYWlsZXIgbGlzdCkiIDxjZkBjaXNjby5jb20+LCBD aGVuZyBMaSA8Y2hlbmdsaTEzQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWFsaS1zcHJpbmctaW9hbS1zcnY2LTAwLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hbGktc3ByaW5nLWlvYW0tc3J2Ni0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWmFmYXIgQWxpIGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICAgICAgICAgZHJhZnQtYWxpLXNw cmluZy1pb2FtLXNydjYNClJldmlzaW9uOiAgICAgICAgICAgICAgMDANClRpdGxlOiAgICAgICAg ICAgICAgICAgICAgICBTZWdtZW50IFJvdXRpbmcgSGVhZGVyIGVuY2Fwc3VsYXRpb24gZm9yIElu LXNpdHUgT0FNIERhdGENCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAgMjAxOC0xMC0yMg0K R3JvdXA6ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAg ICAgICAgICAgICAgICAgOA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1hbGktc3ByaW5nLWlvYW0tc3J2Ni0wMC50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbGktc3ByaW5n LWlvYW0tc3J2Ni8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYWxpLXNwcmluZy1pb2FtLXNydjYtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFsaS1zcHJpbmctaW9hbS1zcnY2DQoN Cg0KQWJzdHJhY3Q6DQogICBJbi1zaXR1IE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQg TWFpbnRlbmFuY2UgKElPQU0pIHJlY29yZHMNCiAgIG9wZXJhdGlvbmFsIGFuZCB0ZWxlbWV0cnkg aW5mb3JtYXRpb24gaW4gdGhlIGRhdGEgcGFja2V0IHdoaWxlIHRoZQ0KICAgcGFja2V0IHRyYXZl cnNlcyBhIHBhdGggYmV0d2VlbiB0d28gcG9pbnRzIGluIHRoZSBuZXR3b3JrLiAgVGhpcw0KICAg ZG9jdW1lbnQgZGVmaW5lcyBob3cgSU9BTSBkYXRhIGZpZWxkcyBhcmUgdHJhbnNwb3J0ZWQgYXMg cGFydCBvZiB0aGUNCiAgIFNlZ21lbnQgUm91dGluZyB3aXRoIElQdjYgZGF0YSBwbGFuZSAoU1J2 NikgaGVhZGVyLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_BF79756437264923B4D1C5F8DF9ADD23ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtdGFi LXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBX RywgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBoYXZlIHVwbG9hZGVkIGEgc3RyYWlnaHQg Zm9yd2FyZCBkcmFmdCBvbiBob3cgPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JT0FNIGRhdGEg Y2FuIGJlIGNhcnJpZWQgaW4gU1J2NiBuZXR3b3JrLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIHB1 cnBvc2Ugb2YgdGhpcyBlbWFpbCBpcyB0byBzb2xpY2l0IHlvdXIgY29tbWVudHMgb24gdGhpcyB3 b3JrLiBXZSBwbGFuIHRvIHByZXNlbnQgdGhpcyB3b3JrIGluIFNwcmluZyBhbmQgaW4gSVBQTSBX R3MgYXQgSUVURjEwMy4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TG9va2luZyBmb3J3YXJkIHRvIGFueSBmZWVkYmFj ay4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyDigKYgWmFmYXIgKG9uIGJlaGFsZiBvZiB0aGUgY28t YXV0aG9ycykuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4mcXVvdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmcXVvdDsgJmx0O2ludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBPY3RvYmVyIDIyLCAy MDE4IGF0IDY6NTEgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1Jha2VzaCBHYW5kaGkgKHJnYW5k aGkpJnF1b3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDssICZxdW90O01hY2ggQ2hlbiAoR3Vv eWkpJnF1b3Q7ICZsdDttYWNoLmNoZW5AaHVhd2VpLmNvbSZndDssICZxdW90O0ZyYW5rIEJyb2Nr bmVycyAoZmJyb2NrbmUpJnF1b3Q7ICZsdDtmYnJvY2tuZUBjaXNjby5jb20mZ3Q7LCAmcXVvdDtO YWdlbmRyYSBLdW1hciBOYWluYXIgKG5haWt1bWFyKSZxdW90OyAmbHQ7bmFpa3VtYXJAY2lzY28u Y29tJmd0OywgJnF1b3Q7WmFmYXIgQWxpICh6YWxpKSZxdW90OyAmbHQ7emFsaUBjaXNjby5jb20m Z3Q7LCAmcXVvdDtOYWdlbmRyYQ0KIEt1bWFyIE5haW5hciAobmFpa3VtYXIpJnF1b3Q7ICZsdDtu YWlrdW1hckBjaXNjby5jb20mZ3Q7LCBHYXVyYXYgRGF3cmEgJmx0O2dkYXdyYS5pZXRmQGdtYWls LmNvbSZndDssICZxdW90O0NhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSZxdW90OyAmbHQ7Y3Bp Z25hdGFAY2lzY28uY29tJmd0OywgTWFjaCBDaGVuICZsdDttYWNoLmNoZW5AaHVhd2VpLmNvbSZn dDssICZxdW90O2NmKG1haWxlciBsaXN0KSZxdW90OyAmbHQ7Y2ZAY2lzY28uY29tJmd0OywgQ2hl bmcgTGkgJmx0O2NoZW5nbGkxM0BodWF3ZWkuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5O ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFsaS1zcHJpbmctaW9hbS1zcnY2LTAw LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9h PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1hbGktc3ByaW5nLWlvYW0tc3J2Ni0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFph ZmFyIEFsaSBhbmQgcG9zdGVkIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPklFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij5OYW1lOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ZHJhZnQt YWxpLXNwcmluZy1pb2FtLXNydjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij5SZXZpc2lvbjo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+VGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj5TZWdtZW50IFJvdXRpbmcgSGVhZGVyIGVuY2Fwc3VsYXRpb24gZm9yIElu LXNpdHUgT0FNIERhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij5Eb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+MjAxOC0xMC0yMjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+UGFnZXM6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj44PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VVJMOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYWxpLXNwcmluZy1pb2FtLXNydjYtMDAudHh0Ij48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYWxpLXNwcmluZy1pb2FtLXNydjYtMDAudHh0PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsaS1zcHJpbmctaW9hbS1zcnY2LyI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtYWxpLXNwcmluZy1pb2FtLXNydjYvPC9zcGFuPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWFsaS1zcHJpbmctaW9hbS1zcnY2LTAwIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWxpLXNw cmluZy1pb2FtLXNydjYtMDA8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFsaS1z cHJpbmctaW9hbS1zcnY2Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFsaS1zcHJp bmctaW9hbS1zcnY2PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+QWJzdHJhY3Q6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5i c3A7IEluLXNpdHUgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWludGVuYW5jZSAo SU9BTSkgcmVjb3JkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiZuYnNwOyZuYnNwOyBvcGVyYXRpb25hbCBhbmQgdGVsZW1ldHJ5IGluZm9ybWF0aW9uIGlu IHRoZSBkYXRhIHBhY2tldCB3aGlsZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgcGFja2V0IHRyYXZlcnNlcyBhIHBhdGggYmV0 d2VlbiB0d28gcG9pbnRzIGluIHRoZSBuZXR3b3JrLiZuYnNwOyZuYnNwO1RoaXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgZG9jdW1l bnQgZGVmaW5lcyBob3cgSU9BTSBkYXRhIGZpZWxkcyBhcmUgdHJhbnNwb3J0ZWQgYXMgcGFydCBv ZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz cDsmbmJzcDsgU2VnbWVudCBSb3V0aW5nIHdpdGggSVB2NiBkYXRhIHBsYW5lIChTUnY2KSBoZWFk ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BF79756437264923B4D1C5F8DF9ADD23ciscocom_-- From nobody Mon Oct 22 22:21:23 2018 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 57C12130EA5; Mon, 22 Oct 2018 22:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.969 X-Spam-Level: X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 e9yam7bg4aDE; Mon, 22 Oct 2018 22:21:15 -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 5CAE4130EBE; Mon, 22 Oct 2018 22:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6545; q=dns/txt; s=iport; t=1540272075; x=1541481675; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gPBC5wFjGI6wS8XJiwqn+Ksw25aTKlKkjzrK6bJ5ctc=; b=OakmzSEljUAIo6karxCew+/A+TqZhYslquMmgF5YpBrA7i9wIbvBSecm zSMMG7+CwZxigP+5OtuSILyuVIfyHCe8T3Fhk8PdLYau6iLTgtkgJ0Or1 AcINMP3tHT4CGGZEATvgydlOnj87hZ7kEPxzeXEqkStE5jtu6JjxGQdHM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACvrs5b/5ldJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCowDjB2CDZFNhUiBJANTCwE?= =?us-ascii?q?BJYRHAoUcITQNDQEDAQECAQECbRwMhToBAQEELUwQAgEIEQQBAS8yHQgBAQQ?= =?us-ascii?q?BDQUIgxqBHWQPpzCEPkCFIAWLUheBQT+DdS6DGwIDAYc3Ao42kBUJAoZgigg?= =?us-ascii?q?fkC6MWolmAhEUgSYdODSBIXAVgyeLGYU+bwGMVYEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,414,1534809600"; d="scan'208,217";a="473517923" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 05:21:14 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w9N5LDx3007569 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 05:21:14 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 00:21:13 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 00:21:13 -0500 From: "Ketan Talaulikar (ketant)" To: "spring-chairs@ietf.org" , "spring@ietf.org" CC: "draft-ietf-spring-segment-routing-policy@ietf.org" , "draft-filsfils-spring-sr-policy-considerations@ietf.org" Thread-Topic: New version of SR policy draft Thread-Index: AdRqQnbjsUeXKJSnQVaEXVM/NGjF7AATOJtQ Date: Tue, 23 Oct 2018 05:21:13 +0000 Message-ID: <84fd4dbc008e40f5a64c631b4081665d@XCH-ALN-008.cisco.com> References: <397b0297a95b4b659553cbc27b9cbd18@XCH-ALN-011.cisco.com> In-Reply-To: <397b0297a95b4b659553cbc27b9cbd18@XCH-ALN-011.cisco.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.24.41.46] Content-Type: multipart/alternative; boundary="_000_84fd4dbc008e40f5a64c631b4081665dXCHALN008ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] New version of SR policy draft X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 05:21:19 -0000 --_000_84fd4dbc008e40f5a64c631b4081665dXCHALN008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rob/Bruno, Would like to request for a 15 min slot to present updates to the SR Policy= drafts below and to discuss the inputs/comments on their coverage of topic= s. https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ https://datatracker.ietf.org/doc/draft-filsfils-spring-sr-policy-considerat= ions/ While we continue the discussion on the mailer, f2f interactions may also h= elp in converging. Thanks, Ketan From: spring On Behalf Of Siva Sivabalan (msiva) Sent: 23 October 2018 01:40 To: spring@ietf.org Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com) ; Clarence Filsfils (cfilsfil) ; Voyer, Danie= l Subject: [spring] New version of SR policy draft Hi All, We have posted a new version of SR policy draft: https://www.ietf.org/id/draft-ietf-spring-segment-routing-policy-02.txt Additional reviews and comments will be appreciated. Thanks, Siva --_000_84fd4dbc008e40f5a64c631b4081665dXCHALN008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello R= ob/Bruno,

&n= bsp;

Would l= ike to request for a 15 min slot to present updates to the SR Policy drafts= below and to discuss the inputs/comments on their coverage of topics.=

&n= bsp;

https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-pol= icy/

https://datatracker.ietf.org/doc/draft-filsfils-spring-sr-policy= -considerations/

&n= bsp;

While w= e continue the discussion on the mailer, f2f interactions may also help in = converging.

&n= bsp;

Thanks,=

Ketan

&n= bsp;

From: spring <spring-bounces@ietf.org> = On Behalf Of Siva Sivabalan (msiva)
Sent: 23 October 2018 01:40
To: spring@ietf.org
Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com) <= bogdanov@google.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.co= m>; Voyer, Daniel <daniel.voyer@bell.ca>
Subject: [spring] New version of SR policy draft

 

Hi All,

 

We have posted a new version of SR policy draft:

 

https://www.ietf.org/id/draft-ietf-spring-s= egment-routing-policy-02.txt

 

Additional reviews and comments will be appreciated.=

 

Thanks,

Siva

--_000_84fd4dbc008e40f5a64c631b4081665dXCHALN008ciscocom_-- From nobody Tue Oct 23 02:42:08 2018 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 619E8130F28; Tue, 23 Oct 2018 02:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Fo3DLjyIJXpp; Tue, 23 Oct 2018 02:42:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C5333130EE7; Tue, 23 Oct 2018 02:41:55 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BC01343C27783; Tue, 23 Oct 2018 10:41:50 +0100 (IST) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Oct 2018 10:41:51 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0399.000; Tue, 23 Oct 2018 17:41:44 +0800 From: "Chengli (IP Technology Research)" To: SPRING WG List CC: "internet-drafts@ietf.org" , Rakesh Gandhi , Lizhenbin , Dhruv Dhody , Mach Chen , "Dongjie (Jimmy)" , Mach Chen Thread-Topic: New Version Notification for draft-li-spring-srv6-path-segment-00.txt Thread-Index: AQHUadV7AD+FH+tqlUygvGG0TtCn3KUslCBw Date: Tue, 23 Oct 2018 09:41:43 +0000 Message-ID: References: <154019186121.15130.15286964174041637107.idtracker@ietfa.amsl.com> In-Reply-To: <154019186121.15130.15286964174041637107.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB01A523B6dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] New Version Notification for draft-li-spring-srv6-path-segment-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 09:42:07 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB01A523B6dggeml529mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRywNCg0KDQoNCldlIGhhdmUgcG9zdGVkIGEgbmV3IGRyYWZ0IG9uIGhvdyBTUnY2IHBh dGggY2FuIGJlIGlkZW50aWZpZWQgYnkgU1J2NiBwYXRoIHNlZ21lbnQsIGFuZCB3ZSBwbGFuIHRv IHByZXNlbnQgdGhpcyB3b3JrIGluIFNwcmluZyBXR3MgYXQgSUVURjEwMy4NCg0KDQpUaGUgcHVy cG9zZSBvZiB0aGlzIGVtYWlsIGlzIHRvIHNvbGljaXQgeW91ciBjb21tZW50cyBvbiB0aGlzIHdv cmsuDQoNCg0KDQpMb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFjay4NCg0KDQoNClRoYW5r cywNCg0KQ2hlbmcgKG9uIGJlaGFsZiBvZiB0aGUgY28tYXV0aG9ycykuDQoNCg0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KDQpTZW50OiBNb25kYXksIE9jdG9i ZXIgMjIsIDIwMTggMzowNCBQTQ0KDQpUbzogUmFrZXNoIEdhbmRoaSA8cmdhbmRoaUBjaXNjby5j b20+OyBMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPjsgRGhydXYgRGhvZHkgPGRocnV2 LmlldGZAZ21haWwuY29tPjsgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT47IERvbmdq aWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1 YXdlaS5jb20+OyBDaGVuZ2xpIChJUCBUZWNobm9sb2d5IFJlc2VhcmNoKSA8Y2hlbmdsaTEzQGh1 YXdlaS5jb20+DQoNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bGktc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50LTAwLnR4dA0KDQoNCg0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQtMDAudHh0DQoNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2hlbmcgTGkgYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICAgICAgICAgICBkcmFmdC1s aS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQNCg0KUmV2aXNpb246ICAgICAgICAgICAgICAwMA0K DQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgUGF0aCBTZWdtZW50IGZvciBTUnY2IChTZWdt ZW50IFJvdXRpbmcgaW4gSVB2NikNCg0KRG9jdW1lbnQgZGF0ZTogICAgICAgICAgICAgICAyMDE4 LTEwLTIyDQoNCkdyb3VwOiAgICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K DQpQYWdlczogICAgICAgICAgICAgICAgICAgOA0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLXNwcmluZy1zcnY2LXBhdGgtc2Vn bWVudC0wMC50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWxpLXNwcmluZy1zcnY2LXBhdGgtc2VnbWVudC8NCg0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRo LXNlZ21lbnQtMDANCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtbGktc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50DQoNCg0KDQoNCg0K QWJzdHJhY3Q6DQoNCiAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93cyBmb3IgYSBmbGV4aWJs ZSBkZWZpbml0aW9uIG9mIGVuZC10by1lbmQNCg0KICAgcGF0aHMgYnkgZW5jb2RpbmcgcGF0aHMg YXMgc2VxdWVuY2VzIG9mIHRvcG9sb2dpY2FsIHN1Yi1wYXRocywgY2FsbGVkDQoNCiAgICJzZWdt ZW50cyIuICBTZWdtZW50IHJvdXRpbmcgYXJjaGl0ZWN0dXJlIGNhbiBiZSBpbXBsZW1lbnRlZCBv dmVyIGFuDQoNCiAgIE1QTFMgZGF0YSBwbGFuZSBhcyB3ZWxsIGFzIGFuIElQdjYgZGF0YSBwbGFu ZS4NCg0KDQoNCiAgIEZ1cnRoZXIsIFBhdGggU2VnbWVudCBoYXMgYmVlbiBkZWZpbmVkIHRvIGlk ZW50aWZ5IGFuIFNSIHBhdGggaW4gU1ItDQoNCiAgIE1QTFMgbmV0d29ya3MsIGFuZCB1c2VkIGZv ciB2YXJpb3VzIHVzZS1jYXNlcyBzdWNoIGFzIGVuZC10by1lbmQgU1INCg0KICAgUGF0aCBQcm90 ZWN0aW9uIGFuZCBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCAoUE0pIG9mIGFuIFNSIHBhdGguDQoN CiAgIFNpbWlsYXIgdG8gU1ItTVBMUywgdGhpcyBkb2N1bWVudCBkZWZpbmVzIFBhdGggU2VnbWVu dCBpbiBTUnY2DQoNCiAgIG5ldHdvcmtzIHRvIGlkZW50aWZ5IGFuIFNSdjYgcGF0aC4NCg0KDQoN Cg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_C7C2E1C43D652C4E9E49FE7517C236CB01A523B6dggeml529mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRlYXIgV0csIDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBoYXZlIHBvc3RlZCBhIG5ldyBkcmFmdCBvbiBo b3cgU1J2NiBwYXRoIGNhbiBiZSBpZGVudGlmaWVkIGJ5IFNSdjYgcGF0aCBzZWdtZW50LCBhbmQg d2UgcGxhbiB0byBwcmVzZW50IHRoaXMgd29yayBpbiBTcHJpbmcgV0dzIGF0IElFVEYxMDMuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHB1cnBvc2Ugb2YgdGhpcyBlbWFpbCBpcyB0 byBzb2xpY2l0IHlvdXIgY29tbWVudHMgb24gdGhpcyB3b3JrLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGZlZWRiYWNrLiA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Q2hlbmcgKG9uIGJlaGFsZiBvZiB0aGUgY28tYXV0aG9ycykuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+U2VudDogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDE4IDM6MDQgUE08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRvOiBSYWtlc2ggR2FuZGhpICZs dDtyZ2FuZGhpQGNpc2NvLmNvbSZndDs7IExpemhlbmJpbiAmbHQ7bGl6aGVuYmluQGh1YXdlaS5j b20mZ3Q7OyBEaHJ1diBEaG9keSAmbHQ7ZGhydXYuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBNYWNoIENo ZW4gJmx0O21hY2guY2hlbkBodWF3ZWkuY29tJmd0OzsgRG9uZ2ppZSAoSmltbXkpICZsdDtqaWUu ZG9uZ0BodWF3ZWkuY29tJmd0OzsgTWFjaCBDaGVuICZsdDttYWNoLmNoZW5AaHVhd2VpLmNvbSZn dDs7IENoZW5nbGkgKElQIFRlY2hub2xvZ3kNCiBSZXNlYXJjaCkgJmx0O2NoZW5nbGkxM0BodWF3 ZWkuY29tJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRo LXNlZ21lbnQtMDAudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWxpLXNwcmluZy1zcnY2LXBhdGgtc2VnbWVudC0wMC50eHQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgQ2hlbmcgTGkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAwMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGl0bGU6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFBhdGggU2VnbWVudCBmb3IgU1J2NiAoU2VnbWVudCBSb3V0aW5nIGluIElQdjYp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Eb2N1bWVudCBkYXRlOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE4LTEwLTIyPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5QYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtbGktc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50LTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1saS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQvPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXNwcmluZy1zcnY2LXBh dGgtc2VnbWVudC0wMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRt bGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGktc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+QWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU2VnbWVudCBSb3V0aW5nIChTUikgYWxsb3dzIGZv ciBhIGZsZXhpYmxlIGRlZmluaXRpb24gb2YgZW5kLXRvLWVuZDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHBhdGhzIGJ5IGVuY29kaW5nIHBhdGhz IGFzIHNlcXVlbmNlcyBvZiB0b3BvbG9naWNhbCBzdWItcGF0aHMsIGNhbGxlZDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7ICZxdW90O3NlZ21lbnRz JnF1b3Q7LiZuYnNwOyBTZWdtZW50IHJvdXRpbmcgYXJjaGl0ZWN0dXJlIGNhbiBiZSBpbXBsZW1l bnRlZCBvdmVyIGFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgTVBMUyBkYXRhIHBsYW5lIGFzIHdlbGwgYXMgYW4gSVB2NiBkYXRhIHBsYW5lLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgRnVydGhlciwgUGF0aCBT ZWdtZW50IGhhcyBiZWVuIGRlZmluZWQgdG8gaWRlbnRpZnkgYW4gU1IgcGF0aCBpbiBTUi08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBNUExTIG5l dHdvcmtzLCBhbmQgdXNlZCBmb3IgdmFyaW91cyB1c2UtY2FzZXMgc3VjaCBhcyBlbmQtdG8tZW5k IFNSPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg UGF0aCBQcm90ZWN0aW9uIGFuZCBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCAoUE0pIG9mIGFuIFNS IHBhdGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgU2ltaWxhciB0byBTUi1NUExTLCB0aGlzIGRvY3VtZW50IGRlZmluZXMgUGF0aCBTZWdtZW50 IGluIFNSdjY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBuZXR3b3JrcyB0byBpZGVudGlmeSBhbiBTUnY2IHBhdGguPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CB01A523B6dggeml529mbxchi_-- From nobody Tue Oct 23 13:22:33 2018 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 4B970129619 for ; Tue, 23 Oct 2018 13:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 IvRP6JEn_cKO for ; Tue, 23 Oct 2018 13:22:24 -0700 (PDT) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 90A841294D7 for ; Tue, 23 Oct 2018 13:22:24 -0700 (PDT) Received: by mail-it1-x136.google.com with SMTP id h6-v6so13234098ith.0 for ; Tue, 23 Oct 2018 13:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+od2Sowl5doKw9s75K1CcyrLwpwkgTVPu1OPu3ZfczY=; b=Q57txHS6+tR09+SE/XM23T2+tlFuWNq55DDFGODaEKC+yMX6qjgOV3o7cMUUyCv8vt 9a6m05vyu7ex1uNO3/14jNtuL0g7GMDOenq9IrU1r154Iydw6TtMFFJv5mzuS6Doj27g GEchy7FDnfj0V3YlVK1IM6ZACq92rl+6fHylKMtZ0r32MEXtuGlaHa2ftDHpxxGDN1ny WwaaR3gD0K6A/sltCi/XKOw01C3ha9S5gS/pXvd4lBKZJ7z3CCym/0ijiJyqC5ji+4mS pTtJ/CKdOhTq53e8SEXPieL/Fms3zaTsLZ+DguB2OYCRpKt709bJBnQjrv0axkm4XI5D kLPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+od2Sowl5doKw9s75K1CcyrLwpwkgTVPu1OPu3ZfczY=; b=C2hRD+vKA3/BOY862J2F6gzj+0I5zPaoy3QXSRwex26qO7i/dhTm2H+bmievgMWkCj 9oX++RRpKUixeE4pCqZEsYCZ8KpKz9Umfg7u2oaTij0Ou/dg89EuaaxaL4EEocBGQrJw l0kv9X9UBkUuXENgqe0Ma1cIgxiYCbEw5sJkswUX3K1Z12xRmgAWEZ2AVueIFGW7nETN wx9MQQZLFj3BFpLRBypK6hnJsGHoJcXV9ycWZ5vObWkqwJE+7eBqK4CDoQnLqRQ7Ow+U Z2Yp6265tJuyFKjEuI/RsoIwSo/MJXPLpOOrMdrV7CbFvhff/JYN4rzr1QF62TTC8JBT 42Fg== X-Gm-Message-State: ABuFfoj3IGV0E+gwD5puinJZayNiPHlkPizgHnB/f1o7sVjr0w6VKCeM wi0i4FxCvUbhw/Umve/vrduh7oz+SQwq003aRvF3Hb75 X-Google-Smtp-Source: ACcGV60Himc3S4h0HFhQrvKigVU3/MMu4Hjl9/PJ0AxDdqKjy0MIjRRAHMkmuuccqog1tePkjLFHIO9ucoqSoMx7QlE= X-Received: by 2002:a02:1da:: with SMTP id 87-v6mr10358367jak.16.1540326143538; Tue, 23 Oct 2018 13:22:23 -0700 (PDT) MIME-Version: 1.0 References: <154021232437.15373.8616632445718136122@ietfa.amsl.com> In-Reply-To: <154021232437.15373.8616632445718136122@ietfa.amsl.com> From: Xufeng Liu Date: Tue, 23 Oct 2018 16:22:11 -0400 Message-ID: To: "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009fbd2f0578eb2030" Archived-At: Subject: [spring] Fwd: [Teas] I-D Action: draft-ietf-teas-yang-sr-te-topo-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 20:22:31 -0000 --0000000000009fbd2f0578eb2030 Content-Type: text/plain; charset="UTF-8" Dear Spring WG, TEAS Working Group is current working on a data model that is related to SR, so we would like to get reviews and comments here. The document is as forwarded. This data model complements https://tools.ietf.org/html/draft-ietf-spring-sr-yang to provide modeled topological information that can help in SR policy computation on a controller. Thanks, - Xufeng (on behalf of authors and TEAS WG) ---------- Forwarded message --------- From: Date: Mon, Oct 22, 2018 at 8:46 AM Subject: [Teas] I-D Action: draft-ietf-teas-yang-sr-te-topo-03.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : YANG Data Model for SR and SR TE Topologies Authors : Xufeng Liu Igor Bryskin Vishnu Pavan Beeram Tarek Saad Himanshu Shah Stephane Litkowski Filename : draft-ietf-teas-yang-sr-te-topo-03.txt Pages : 30 Date : 2018-10-22 Abstract: This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) traffic engineering (TE) topology. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-sr-te-topo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-03 https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-sr-te-topo-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-yang-sr-te-topo-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/ _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --0000000000009fbd2f0578eb2030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Spring WG,

T= EAS Working Group is current working on a data model that is related to SR,= so we would like to get reviews and comments here. The document is as forw= arded. This data model complements https://tools.ietf.org/html/draft-ietf-spring-sr-= yang to provide modeled topological information that can help in SR pol= icy computation on a controller.

Thanks,

- Xufeng (on behalf of authors and TEAS WG)
---------- Forwarded message = ---------
From: <internet-drafts@ietf.org>
Date: Mon, Oct 22, 201= 8 at 8:46 AM
Subject: [Teas] I-D Action: draft-ietf-teas-yang-sr-te-topo= -03.txt
To: <i-d-announce@i= etf.org>
Cc: <teas@ietf.org<= /a>>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Traffic Engineering Architecture and Signa= ling WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= YANG Data Model for SR and SR TE Topologies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xufe= ng Liu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Igor Bryskin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Vishnu Pavan Beeram
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tarek Saad
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Himanshu Shah
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Stephane Litkowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-teas-yang-sr-te-topo-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-22

Abstract:
=C2=A0 =C2=A0This document defines a YANG data model for Segment Routing (S= R)
=C2=A0 =C2=A0topology and Segment Routing (SR) traffic engineering (TE) top= ology.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-teas-yang-sr-te-topo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf= -teas-yang-sr-te-topo-03
https://datatracker.ietf.org= /doc/html/draft-ietf-teas-yang-sr-te-topo-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-teas-yang-sr-te-topo-03


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
--0000000000009fbd2f0578eb2030-- From nobody Wed Oct 24 00:14:18 2018 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 E37AC130DF7 for ; Wed, 24 Oct 2018 00:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 xz4MoOV6iWcB for ; Wed, 24 Oct 2018 00:14:15 -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 138B3130DE5 for ; Wed, 24 Oct 2018 00:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2574; q=dns/txt; s=iport; t=1540365255; x=1541574855; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hhscpaiqMXp8R0UPFV+be3VfcHM5Qt6akIiwDtDiyMY=; b=VDSVQQ8G/3t3rZScZoa7Y7lqhGRenCRpukDiqIBSh8spqbRnmJjqsFq1 K5oB2xvoX8K0u5aik2DkLUOvQk3j1beAI5nK9ao5JbErvpUzQYHXFnKFO zMPlYvoEtjoUDfmKWYSyHi7j9OKiSkgAK/1Oe57hLhL5SVfplHJKcF+t3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAQG9Bb/5RdJa1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYIEZn8oCoNriBiMHoFolz0UgWYLAQElhEcCF4JyITQ?= =?us-ascii?q?NDQEDAQECAQECbRwBC4U7BiMRQxICAQgaAhEVAgICMBUGAQYDAgQTgyEBggE?= =?us-ascii?q?Pp3GBLoQwAgxAPYRrgQuKVxeBQT+BOAwTgkyDGwEBAgEBFoECDU8ogkQxgiY?= =?us-ascii?q?CjlKFfYoPCQKGZIoSF4FSTIQpiW+JLIM0iW4CERSBJh04gVVwFRpLAYJBCYJ?= =?us-ascii?q?GiEqFPm8BiyKBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,419,1534809600"; d="scan'208";a="190299099" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 07:14:14 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9O7EErA012685 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Oct 2018 07:14:14 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 02:14:13 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1395.000; Wed, 24 Oct 2018 02:14:13 -0500 From: "Pablo Camarillo (pcamaril)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-filsfils-spring-srv6-network-programming-06.txt Thread-Index: AQHUajNKsNGeRNgoNUGOC+wBugc1RqUuc0YA Date: Wed, 24 Oct 2018 07:14:13 +0000 Message-ID: <6B0ED69C-0A39-4290-BC9C-4833D616AB75@cisco.com> References: <154023215511.6985.2112984587927316788.idtracker@ietfa.amsl.com> In-Reply-To: <154023215511.6985.2112984587927316788.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.55.164.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [spring] FW: New Version Notification for draft-filsfils-spring-srv6-network-programming-06.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 07:14:17 -0000 RGVhciBTcHJpbmcgV0csDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIG9mIGRy YWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcuDQpUaGlzIGlzIG1h aW5seSBhbiBlZGl0b3JpYWwgdXBkYXRlIHRvIGNsYXJpZnkgdGhlIHRleHQuIFdlIGhhdmUgdGFr ZW4gaW50byBhY2NvdW50IGJvdGggdGhlIGVtYWlscyBhcyB3ZWxsIGFzIHRoZSBxdWVzdGlvbnMg cmFpc2VkIGF0IHRoZSBtaWMgZHVyaW5nIGxhc3QgSUVURi4NCldlIGhhdmUgYWxzbyB1cGRhdGVk IHRoZSBpbGx1c3RyYXRpb25zIHdpdGggYSBuZXcgdG9wb2xvZ3kgYW5kIGFkZHJlc3NpbmcuDQoN CkZlZWRiYWNrIGlzIHdlbGNvbWUuDQoNClRoYW5rcywNClBhYmxvIChvbiBiZWhhbGYgb2YgdGhl IGNvYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzKQ0KDQrvu79PbiAyMi8xMC8yMDE4LCAyMDoxNiwg ImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3Jv dGU6DQoNCiAgICANCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmlsc2ZpbHMtc3By aW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy0wNi50eHQNCiAgICBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFBhYmxvIENhbWFyaWxsbyBHYXJ2aWEgYW5kIHBvc3RlZCB0byB0 aGUNCiAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgDQogICAgTmFtZToJCWRyYWZ0LWZpbHNmaWxz LXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcNCiAgICBSZXZpc2lvbjoJMDYNCiAgICBU aXRsZToJCVNSdjYgTmV0d29yayBQcm9ncmFtbWluZw0KICAgIERvY3VtZW50IGRhdGU6CTIwMTgt MTAtMjINCiAgICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOgkJNTUN CiAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMDYudHh0DQog ICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcvDQogICAgSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWxzZmlscy1zcHJpbmct c3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTA2DQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNydjYt bmV0d29yay1wcm9ncmFtbWluZw0KICAgIERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNydjYtbmV0d29yay1wcm9n cmFtbWluZy0wNg0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIHRoZSBTUnY2IG5ldHdvcmsgcHJvZ3JhbW1pbmcgY29uY2VwdCBhbmQgaXRzDQogICAg ICAgbW9zdCBiYXNpYyBmdW5jdGlvbnMuDQogICAgDQogICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KICAgIA0KICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgDQogICAgDQoNCg== From nobody Wed Oct 24 00:47:50 2018 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 70FAF130E62; Wed, 24 Oct 2018 00:47:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ladislav Lhotka To: Cc: spring@ietf.org, ietf@ietf.org, draft-ietf-spring-sr-yang.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154036725541.6830.14208644072725478318@ietfa.amsl.com> Date: Wed, 24 Oct 2018 00:47:35 -0700 Archived-At: Subject: [spring] Yangdoctors early review of draft-ietf-spring-sr-yang-09 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 07:47:36 -0000 Reviewer: Ladislav Lhotka Review result: On the Right Track *** General comments This document contains two YANG modules: ietf-segment-routing-common and ietf-segment-routing. The latter augments ietf-routing with data necessary for configuring and operating segment routing, but also provides groupings that define data to be used in segment routing extensions of routing protocols and interfaces. This design makes it relatively easy to define such IGP extensions. **** Naming - My suggestion is to review the identifiers defined in the modules so as to adhere more closely to the identifier naming conventions in sec. 4.3.1 of RFC 8407. It is subjective to decide which acronyms are well-known but, in my view, "srgb", "srlb" and "msd" do not fall into this category. For example, "msd" can be changed to to "max-sid-depth" (both as a data node and a feature). - On the other hand, the "-cfg" suffix in the names of several groupings should be removed - according to RFC 8407, identifiers should not carry semantics. (And perhaps the same groupings can also be used for state data?) **** Revisions The YANG modules contain revision dates of all development versions. Although RFC 8407 doesn't require to do so, I think it can be useful for the developmnent and testing of the modules. However, these development revisions should be removed before publishing the RFC (maybe the authors intend to do so). **** References Normative References should include the RFCs defining YANG modules that are imported by the segment-routing modules: 6991, 7223, 8294 and 8349. *** Specific comments - Containers "connected-prefix-sid-map" and "local-prefix-sid" have subcontainers "ipv4" and "ipv6" that only differ in the type of the "prefix" leaf. An alternative solution can be to change the outer containers into lists with "address-family" as the key. Did the authors discuss this option? - The text uses the terms "states" and "operational states" in several places. The plural form looks weird to me. From nobody Wed Oct 24 00:59:02 2018 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 78134130DF2; Wed, 24 Oct 2018 00:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CGIViK-hAydC; Wed, 24 Oct 2018 00:58:57 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 906FD12F1AC; Wed, 24 Oct 2018 00:58:57 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A9201D0C594; Wed, 24 Oct 2018 08:58:52 +0100 (IST) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Oct 2018 08:58:53 +0100 Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.146]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0382.000; Wed, 24 Oct 2018 15:58:42 +0800 From: "Pengshuping (Peng Shuping, IP Tech Dept)" To: "spring@ietf.org" CC: Lizhenbin , "internet-drafts@ietf.org" , "Pengshuping (Peng Shuping, IP Tech Dept)" Thread-Topic: New Version Notification for draft-peng-spring-srv6-compatibility-00.txt Thread-Index: AQHUahK1Q79YVyTMNkmTbXwdEZicgqUuCU8A Date: Wed, 24 Oct 2018 07:58:42 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE14662765@DGGEML532-MBX.china.huawei.com> References: <154021816427.5670.16518696525720877559.idtracker@ietfa.amsl.com> In-Reply-To: <154021816427.5670.16518696525720877559.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-peng-spring-srv6-compatibility-00=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 07:59:01 -0000 RGVhciBXRywgDQoNCldlIGhhdmUgcG9zdGVkIGEgbmV3IGRyYWZ0IG9uIFNSdjYgY29tcGF0aWJp bGl0eSB3aXRoIGxlZ2FjeSBkZXZpY2VzLiANCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1wZW5nLXNwcmluZy1zcnY2LWNvbXBhdGliaWxpdHktMDAudHh0DQoJDQpM b29raW5nIGZvcndhcmRzIHRvIHlvdXIgY29tbWVudHMuIFRoYW5rIHlvdSEgIA0KDQpCZXN0IFJl Z2FyZHMsDQpTaHVwaW5nIA0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANCuWPkemAgeaXtumXtDogMjAxOOW5tDEw5pyIMjLml6UgMjI6MjMNCuaUtuS7tuS6ujogcGVu Z3NodXBpbmcgPHBlbmdzaHVwaW5nQGh1YXdlaS5jb20+OyBMaXpoZW5iaW4gPGxpemhlbmJpbkBo dWF3ZWkuY29tPg0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBl bmctc3ByaW5nLXNydjYtY29tcGF0aWJpbGl0eS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtcGVuZy1zcHJpbmctc3J2Ni1jb21wYXRpYmlsaXR5LTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTaHVwaW5nIFBlbmcgYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtcGVuZy1zcHJpbmctc3J2Ni1jb21w YXRpYmlsaXR5DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJU1J2NiBDb21wYXRpYmlsaXR5IHdpdGgg TGVnYWN5IERldmljZXMNCkRvY3VtZW50IGRhdGU6CTIwMTgtMTAtMjINCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBlbmctc3ByaW5nLXNydjYtY29tcGF0aWJp bGl0eS0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1wZW5nLXNwcmluZy1zcnY2LWNvbXBhdGliaWxpdHkvDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbmctc3ByaW5nLXNydjYtY29t cGF0aWJpbGl0eS0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtcGVuZy1zcHJpbmctc3J2Ni1jb21wYXRpYmlsaXR5DQoNCg0KQWJz dHJhY3Q6DQogICBXaGVuIGRlcGxveWluZyBTUnY2IG9uIGxlZ2FjeSBkZXZpY2VzLCB0aGVyZSBh cmUgc29tZSBjb21wYXRpYmlsaXR5DQogICBjaGFsbGVuZ2VzIHN1Y2ggYXMgdGhlIHN1cHBvcnQg b2YgU1JIIHByb2Nlc3NpbmcuICBUaGlzIGRvY3VtZW50DQogICBpZGVudGlmaWVzIHNvbWUgb2Yg dGhlIG1ham9yIGNoYWxsZW5nZXMsIGFuZCBwcm92aWRlcyBzb2x1dGlvbnMgdGhhdA0KICAgYXJl IGFibGUgdG8gbWl0aWdhdGUgdGhvc2UgY2hhbGxlbmdlcyBhbmQgc21vb3RoIHRoZSBldm9sdXRp b24NCiAgIHRvd2FyZHMgU1J2NiBkZXBsb3ltZW50Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg== From nobody Wed Oct 24 06:54:14 2018 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 0A0B6128DFD for ; Wed, 24 Oct 2018 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FDUjs46D6vyt for ; Wed, 24 Oct 2018 06:54:10 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70837127133 for ; Wed, 24 Oct 2018 06:54:10 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 42gBZ80s0Rz7ty4; Wed, 24 Oct 2018 15:54:08 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.59]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 42gBZ76N4hz3wbB; Wed, 24 Oct 2018 15:54:07 +0200 (CEST) Received: from OPEXCNORM2F.corporate.adroot.infra.ftgroup ([fe80::994e:c3e:1d70:d2b4]) by OPEXCNORM73.corporate.adroot.infra.ftgroup ([fe80::3991:195b:e05c:93d5%21]) with mapi id 14.03.0415.000; Wed, 24 Oct 2018 15:54:04 +0200 From: To: "Siva Sivabalan (msiva)" CC: "pamattes@microsoft.com" , "Alex Bogdanov (bogdanov@google.com)" , "Clarence Filsfils (cfilsfil)" , "Voyer, Daniel" , "spring@ietf.org" Thread-Topic: New version of SR policy draft Thread-Index: AdRqQnbjsUeXKJSnQVaEXVM/NGjF7ABXk2Fw Date: Wed, 24 Oct 2018 13:54:03 +0000 Message-ID: <25221_1540389247_5BD0797F_25221_242_1_53C29892C857584299CBF5D05346208A47F65A26@OPEXCNORM2F.corporate.adroot.infra.ftgroup> References: <397b0297a95b4b659553cbc27b9cbd18@XCH-ALN-011.cisco.com> In-Reply-To: <397b0297a95b4b659553cbc27b9cbd18@XCH-ALN-011.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.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47F65A26OPEXCNORM2Fcorp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] New version of SR policy draft X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:54:13 -0000 --_000_53C29892C857584299CBF5D05346208A47F65A26OPEXCNORM2Fcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Siva, Thanks for the updated draft. May be providing a high level description of the changes would help getting= review and comments on the document. Thanks, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Siva Sivabalan (= msiva) Sent: Monday, October 22, 2018 10:10 PM To: spring@ietf.org Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com); Clarence F= ilsfils (cfilsfil); Voyer, Daniel Subject: [spring] New version of SR policy draft Hi All, We have posted a new version of SR policy draft: https://www.ietf.org/id/draft-ietf-spring-segment-routing-policy-02.txt Additional reviews and comments will be appreciated. Thanks, Siva ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A47F65A26OPEXCNORM2Fcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Siva,

 

Thanks for the= updated draft.

May be providi= ng a high level description of the changes would help getting review and co= mments on the document.

 

Thanks,

--Bruno

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Siva Sivabalan (msiva)
Sent: Monday, October 22, 2018 10:10 PM
To: spring@ietf.org
Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com); Cla= rence Filsfils (cfilsfil); Voyer, Daniel
Subject: [spring] New version of SR policy draft

 

Hi All,

 

We have posted a new version of= SR policy draft:

 

https://www.ietf.org/i= d/draft-ietf-spring-segment-routing-policy-02.txt

 

Additional reviews and comments= will be appreciated.

 

Thanks,

Siva

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A47F65A26OPEXCNORM2Fcorp_-- From nobody Wed Oct 24 07:22:35 2018 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 BA0FA12F295 for ; Wed, 24 Oct 2018 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 wnUGGEtDd5ng for ; Wed, 24 Oct 2018 07:22:33 -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 C158D1200D7 for ; Wed, 24 Oct 2018 07:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11235; q=dns/txt; s=iport; t=1540390952; x=1541600552; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CkOf+sWNSCxuB00frn29bz2SR65sQzDJ4srNJ9Mzhsk=; b=cF8PDJ8ntSlcdQ74x/Om1fPCfxYHzXNwTCmYX1U/862o4DufIdpLUf9H lj+R9f0d0Lpykvv0aP9w7x15Y6t9zKCQBDo+i2hNl26OJiPychmFSKTGT BfMBy/owXtmquJYCVNOTuxIBraTLQZ87xOnUVJ3RGSvN2gT9+i2Z6suWC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAD0f9Bb/4kNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCowDjBiCDZFNhUgUgRADUws?= =?us-ascii?q?BASOESQKDCyE0DQ0BAwEBAgEBAm0cAQuFOgEBAQQtTBACAQgRBAEBKAcyFAk?= =?us-ascii?q?IAQEEDgUIgxqBHWQPqTWKHQWLYheCAIN1LoMbAoEuARIBVYUkAohTggaDXoY?= =?us-ascii?q?SigcJApBqH4FShHSJapZEAhEUgSYdODQwcXAVgyeLGYU+bwGKboEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,420,1534809600"; d="scan'208,217";a="190488759" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 14:22:14 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w9OEME24015847 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2018 14:22:14 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 09:22:14 -0500 Received: from xch-aln-011.cisco.com ([173.36.7.21]) by XCH-ALN-011.cisco.com ([173.36.7.21]) with mapi id 15.00.1395.000; Wed, 24 Oct 2018 09:22:14 -0500 From: "Siva Sivabalan (msiva)" To: "bruno.decraene@orange.com" CC: "pamattes@microsoft.com" , "Alex Bogdanov (bogdanov@google.com)" , "Clarence Filsfils (cfilsfil)" , "Voyer, Daniel" , "spring@ietf.org" Thread-Topic: New version of SR policy draft Thread-Index: AdRqQnbjsUeXKJSnQVaEXVM/NGjF7ABXk2FwAAEJMEA= Date: Wed, 24 Oct 2018 14:22:13 +0000 Message-ID: References: <397b0297a95b4b659553cbc27b9cbd18@XCH-ALN-011.cisco.com> <25221_1540389247_5BD0797F_25221_242_1_53C29892C857584299CBF5D05346208A47F65A26@OPEXCNORM2F.corporate.adroot.infra.ftgroup> In-Reply-To: <25221_1540389247_5BD0797F_25221_242_1_53C29892C857584299CBF5D05346208A47F65A26@OPEXCNORM2F.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.86.253.23] Content-Type: multipart/alternative; boundary="_000_ae8c7ef50c4b47da808d2ab754b1af9aXCHALN011ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [spring] New version of SR policy draft X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 14:22:35 -0000 --_000_ae8c7ef50c4b47da808d2ab754b1af9aXCHALN011ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruno, We will send it out. Thanks, Siva From: bruno.decraene@orange.com Sent: Wednesday, October 24, 2018 9:54 AM To: Siva Sivabalan (msiva) Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com) ; Clarence Filsfils (cfilsfil) ; Voyer, Danie= l ; spring@ietf.org Subject: RE: New version of SR policy draft Hi Siva, Thanks for the updated draft. May be providing a high level description of the changes would help getting= review and comments on the document. Thanks, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Siva Sivabalan (= msiva) Sent: Monday, October 22, 2018 10:10 PM To: spring@ietf.org Cc: pamattes@microsoft.com; Alex Bogdanov (b= ogdanov@google.com); Clarence Filsfils (cfilsfi= l); Voyer, Daniel Subject: [spring] New version of SR policy draft Hi All, We have posted a new version of SR policy draft: https://www.ietf.org/id/draft-ietf-spring-segment-routing-policy-02.txt Additional reviews and comments will be appreciated. Thanks, Siva ___________________________________________________________________________= ______________________________________________ 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_ae8c7ef50c4b47da808d2ab754b1af9aXCHALN011ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

We will send it out.

 

Thanks,

Siva=

 

From: bruno.decraene@orange.com <bruno.dec= raene@orange.com>
Sent: Wednesday, October 24, 2018 9:54 AM
To: Siva Sivabalan (msiva) <msiva@cisco.com>
Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com) <= bogdanov@google.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.co= m>; Voyer, Daniel <daniel.voyer@bell.ca>; spring@ietf.org
Subject: RE: New version of SR policy draft

 

Hi Siva,

 

Thanks for the updated draft.<= /span>

May be providing a high level description= of the changes would help getting review and comments on the document.

 

Thanks,

--Bruno

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Siva Sivabalan (msiva)
Sent: Monday, October 22, 2018 10:10 PM
To: spring@ietf.org
Cc: pamattes@microsoft.com= ; Alex Bogdanov (bogdanov@google= .com); Clarence Filsfils (cfilsfil); Voyer, Daniel
Subject: [spring] New version of SR policy draft

 

Hi All,

 

We have posted a new version of SR policy draft:

 

https://www.ietf.org/id/draft-ietf-spring-s= egment-routing-policy-02.txt

 

Additional reviews and comments will be appreciated.=

 

Thanks,

Siva

____________________________________________________=
_____________________________________________________________________<=
/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_ae8c7ef50c4b47da808d2ab754b1af9aXCHALN011ciscocom_-- From nobody Wed Oct 24 11:06:01 2018 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 65434129619 for ; Wed, 24 Oct 2018 11:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 NxVZtO0P7joy for ; Wed, 24 Oct 2018 11:05:58 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 976FE124C04 for ; Wed, 24 Oct 2018 11:05:58 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id y10-v6so3712300ioa.10 for ; Wed, 24 Oct 2018 11:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EPzWAqBDWADHeb05jmaRnQGikNW9ZJcvVCpO9gekmxA=; b=Yn2sYBAJYRga7uwKvDu2uVqLlyqkxlvYoaK6vLSZm1dPF0I7MQKm8kRhwLmwS838Cl KeasiXlqgvnMADUMRfJ66zExVfoeE05Q9yfEu5XrtQZlH4nUwZHggjcW7eP50gnTFdHB Nb8KwsKqqZBzjcFMZlcVG3LjKRWct5DtdC00GK2FHx0+d2/Q+6O/VkBUwTin67QyuU4O KTBB3rqjBpolK7can9DObqROginTTk4wEKVnPCVDSUKF7ngnRV75sxmnQqJQBgCNcdcw G+T+BsaPZPTU42b2lhT9qEuSGrHrxsehSrI1XT7Rz4VdaPW7ls1dHVIYSmjedJ/AHy0l SbXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EPzWAqBDWADHeb05jmaRnQGikNW9ZJcvVCpO9gekmxA=; b=Lh2TUw/qo0wzRjXwjVVXT56kPvORZ4+/9vyTPYJehV7e+niCAgxWp/hRzk8T4jaE2e dw/qX2HDZLL/Wy8tAXpk0GPmFYn18BnDSkGFksz9EiDtE7bY8/4omnJJ3vZQkZ4rbhau 3K8lmX0yNCdq8eWk2WCm/FiqqFCOaTo5VgCAwttIfY1hvOfOOA9TsvXoZImRcfQs5Que 85+zm3vN2HJ1ltvkurF98H6g8p96czlW7/4uklThyeCv8QXsYd0ARuiF0GboE91JNmc+ UMJqOJNfvvEw/DQcfqjnQ7lNCoV9f88ntAvq9o71YfFypk57ea/W0/dkrFLPw98fVOMt /imw== X-Gm-Message-State: AGRZ1gJsnFpE8e+g4ctYSwWZ1Ho01VJoxaEkY1KoBwSTR/3avMVINTIv q1nQ5qaN8oUBRISr2FG13tzYNPDsQJ2Bbf8FTBRwijbm5YPGrA== X-Google-Smtp-Source: AJdET5fctDLozUvM2aKDyAqF59BfK6Lp3cBe3AAcgsWMiBU0/v5Xd+YVG9SBmHycScMG8RwfGshhoYLqGH6PzT7vzWs= X-Received: by 2002:a5e:a80d:: with SMTP id c13-v6mr15771690ioa.283.1540404357050; Wed, 24 Oct 2018 11:05:57 -0700 (PDT) MIME-Version: 1.0 From: Przemyslaw Krol Date: Wed, 24 Oct 2018 11:05:20 -0700 Message-ID: To: spring@ietf.org Content-Type: multipart/alternative; boundary="00000000000083e2890578fd564a" Archived-At: Subject: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:06:00 -0000 --00000000000083e2890578fd564a Content-Type: text/plain; charset="UTF-8" Authors, There seems to be a discrepancy in BSID flag ordering: https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04#section-2.4.2 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|I| | +-+-+-+-+-+-+-+-+ https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04#section-8.5 Bit Description Reference --------------------------------------------------------------------------------- 0 Drop Upon Invalid Flag (I-Flag) This document 1 Specified-BSID-Only Flag (S-Flag) This document Would it be possible to clarify this please? Also, draft mentions "V-flag: Segment Verification Flag": V-Flag: This flag encodes the "Segment Verification" behavior. It is used by SRPM as described in section 5 in [I-D.ietf-spring-segment-routing-policy]. Yet its meaning doesn't look to be clearly described in either drafts. thanks, pk -- Przemyslaw "PK" Krol | Strategic Network Engineer ing | pkrol@google.com --00000000000083e2890578fd564a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors,

There seems to be a = discrepancy in BSID flag ordering:

=C2=A0 =C2=A00 1 2 3 4 5 6 7
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|S|I|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+


Bit=C2=A0 =C2=A0 Description=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reference
-----------------------= ----------------------------------------------------------
=C2=A0= =C2=A00=C2=A0 =C2=A0 =C2=A0Drop Upon Invalid Flag (I-Flag)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document
=C2=A0 =C2=A01=C2= =A0 =C2=A0 =C2=A0Specified-BSID-Only Flag (S-Flag)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0This document

Would it be p= ossible to clarify this please?

Also, draft mentio= ns "V-flag: Segment Verification Flag":

=
=C2=A0 =C2=A0V-Flag: This flag encodes the "Segment Verification&= quot; behavior.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 is used by SRPM as = described in section 5 in
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-spring-s= egment-routing-policy].

Yet its meaning does= n't look to be clearly described in either drafts.

=
thanks,
pk


--
=
Przemyslaw "PK" Krol |=C2=A0Strategic Network Engi= neering |=C2=A0pkrol@google.com=C2=A0
=
--00000000000083e2890578fd564a-- From nobody Wed Oct 24 11:09:11 2018 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 005BE1276D0 for ; Wed, 24 Oct 2018 11:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 21tLCosIrskY for ; Wed, 24 Oct 2018 11:09:08 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 615CC124C04 for ; Wed, 24 Oct 2018 11:09:07 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id n3-v6so4712891lfe.7 for ; Wed, 24 Oct 2018 11:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p1Rv2RgFDUr0rRdF+Oe5K4ZIfz0fmgcyegMGpPJZC24=; b=TNysNq7/WaQqrMddKJKP+qu180FO0dQFxo9d12wDX5gH3AOakIHsCKpHuhIsD71JIq G66OG/jZW/kVekxfryrEN+BlauWcaK29xR3L2yGcOBuzMfG+BHAF6I9j2euP45Iz1voB y6w/TE0c6PI9IBw3ToWw9NSe4618FqyzJBLn30brJLjZzkynyG9YGNw/QAmtG4vnakjs 6lssX3zLQ+6IkgSU83UCyYI92xh8YxfFLVgJY8ug5VFr5iJIn1lcvsuAve7hokeWY27M luLnTKnL9OdWrk9wHra1GwwCo9zbg9bfRohjSyqsjS/Qd+57TT4JAgLr4kjTbf+qTgWI 17uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p1Rv2RgFDUr0rRdF+Oe5K4ZIfz0fmgcyegMGpPJZC24=; b=sdVckdxvUk++urFv2TxbbkGf/npxqAiOMb2311eAvig/APrZB9GRhgRjx1S5bJCYUs xifxspE3Nh0lrbdVEyCu1TOjukyIXkaVxUpXEQpoGLTWjDw6eAozio86VSUYN+tDfxGR dWZVl/aGLJ5gLaWmpBYUJm1xOShpGXeshQq9WfyLsrOEeqg2mckQKeqMp4Y80otQLTUH vb4vpFuDZEsPNxn84pN3Qr2InA79Mtu03yJLKX0djo6n5NU0Iti4wSEZHktl0kHMAEWG Ps9v9DhutrE1n1Yegb6VF5iz51qYPczPMPWOGAXbwP/Glm71uP6R7y3GkI31kA6U80ev 9YVg== X-Gm-Message-State: ABuFfojttokLlvwa3T2RqYZOpGbUC/LBxvCV94tU8MHX4UpcQtoMKjFa Y5JOzVfboBqeOfmAeP4niyUyyWWQjoRk+5sDC60= X-Google-Smtp-Source: ACcGV60FkU3c9Wx2NJQO5KQcT/1KIpGYbZMn52Y+7Bf8yFfKvb9z4hI1qCSpv5/P6PgppSl9z8f9TFMNs+T1RR+nYUk= X-Received: by 2002:a19:5f1e:: with SMTP id t30mr7680461lfb.76.1540404545397; Wed, 24 Oct 2018 11:09:05 -0700 (PDT) MIME-Version: 1.0 References: <154024675512.13647.2522788833729168667.idtracker@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Wed, 24 Oct 2018 11:08:55 -0700 Message-ID: To: "Zafar Ali (zali)" Cc: spring Content-Type: multipart/alternative; boundary="000000000000bd2d010578fd61f9" Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:09:10 -0000 --000000000000bd2d010578fd61f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ali, thank you for your kind consideration of my comments. I've read the new version and section 3.3 in particular. Please kindly consider my comments: - I recall that the idea to construct SR tunnel through the network to terminate at the sender discussed in RFC 8403; - if the test probe with the label stack as {B, C, D, C, A} is the S-BFD control packet, the SBFDInitiator will not receive a single S-BFD packet= . In other words, the proposed approach to control the return path will br= eak the S-BFD because SBFDReflector does not receive the S-BFD packet as it passes through until the specified SR tunnel been crossed. - Another problem of the proposed solution is that the S-BFD control packet received by SBFDInitiator has the destination UDP port 7784 and t= he value of Your Discriminator is the one advertised, explicitly or implicitly, by SBFDReflector, not SBFDInitiator. In summary, I conclude that the approach proposed in section 3.3 is not technically viable and cannot address my earlier comments. Regards, Greg On Mon, Oct 22, 2018 at 9:50 PM Zafar Ali (zali) wrote: > Hi Greg and the WG, > > > > We have update draft-ali-spring-bfd-sr-policy to address comments we > received on the list or during WG session presentation. This includes > comment on controlling the return path. > > > > Can you please review the changes and advise of your comments? > > > > Thanks > > > > Regards =E2=80=A6 Zafar > > > > *From: *"internet-drafts@ietf.org" > *Date: *Monday, October 22, 2018 at 6:19 PM > *To: *"Nagendra Kumar Nainar (naikumar)" , "Ketan > Talaulikar (ketant)" , "Zafar Ali (zali)" < > zali@cisco.com>, "Carlos Pignataro (cpignata)" , > "Clarence Filsfils (cfilsfil)" , "Nagendra Kumar > Nainar (naikumar)" > *Subject: *New Version Notification for > draft-ali-spring-bfd-sr-policy-02.txt > > > > > > A new version of I-D, draft-ali-spring-bfd-sr-policy-02.txt > > has been successfully submitted by Nagendra Kumar Nainar and posted to th= e > > IETF repository. > > > > Name: draft-ali-spring-bfd-sr-policy > > Revision: 02 > > Title: Bidirectional Forwarding Detection (BFD) for > Segment Routing Policies for Traffic Engineering > > Document date: 2018-10-22 > > Group: Individual Submission > > Pages: 11 > > URL: > https://www.ietf.org/internet-drafts/draft-ali-spring-bfd-sr-policy-02.tx= t > > Status: > https://datatracker.ietf.org/doc/draft-ali-spring-bfd-sr-policy/ > > Htmlized: > https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ali-spring-bfd-sr-policy > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ali-spring-bfd-sr-policy-02 > > > > Abstract: > > Segment Routing (SR) allows a headend node to steer a packet flow > > along any path using a segment list which is referred to as a SR > > Policy. Intermediate per-flow states are eliminated thanks to source > > routing. The header of a packet steered in an SR Policy is augmented > > with the ordered list of segments associated with that SR Policy. > > Bidirectional Forwarding Detection (BFD) is used to monitor different > > kinds of paths between node. BFD mechanisms can be also used to > > monitor the availability of the path indicated by a SR Policy and to > > detect any failures. Seamless BFD (S-BFD) extensions provide a > > simplified mechanism which is suitable for monitoring of paths that > > are setup dynamically and on a large scale. > > > > This document describes the use of Seamless BFD (S-BFD) mechanism to > > monitor the SR Policies that are used for Traffic Engineering (TE) in > > SR deployments. > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > --000000000000bd2d010578fd61f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ali,=
thank you for your kind consideration of my comments. I've read th= e new version and section 3.3 in particular. Please kindly consider my comm= ents:
  • I recall that the idea to construct SR tunnel throu= gh the network to terminate at the sender discussed in RFC 8403;
  • if= the test probe with the label stack as=C2=A0{B, C, D, C, A} is the S-BFD c= ontrol packet, the SBFDInitiator will not receive a single S-BFD packet. In= other words, the proposed approach to control the return path will break t= he S-BFD because SBFDReflector does not receive the S-BFD packet as it pass= es through until the specified SR tunnel been=C2=A0crossed.=C2=A0
  • A= nother problem of the proposed solution is that the S-BFD control packet re= ceived by SBFDInitiator has the destination UDP port 7784 and the value of = Your Discriminator is the one advertised, explicitly or implicitly, by=C2= =A0 SBFDReflector, not=C2=A0 SBFDInitiator.
In summary, I con= clude that the approach proposed in section 3.3 is not technically viable a= nd cannot address my earlier comments.

Regards,
Greg=C2=A0

On Mon, Oct 22, 2018 at 9:50 PM Zafar Ali (zali)= <zali@cisco.com= > wrote:

Hi Greg and the WG,

=C2=A0

We have update draft-ali-spring-bfd-sr-policy to add= ress comments we received on the list or during WG session presentation. Th= is includes comment on controlling the return path.

=C2=A0

Can you please review the changes and advise of your= comments?

=C2=A0

Thanks

=C2=A0

Regards =E2=80=A6 Zafar

=C2=A0

From= : "internet-drafts@ietf.org= " <internet-drafts@ietf.org>
Date: Monday, October 22, 2018 at 6:19 PM
To: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>, "= Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Zafar Ali (zali)" <<= a href=3D"mailto:zali@cisco.com" target=3D"_blank">zali@cisco.com>, = "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "Clarence Filsfil= s (cfilsfil)" <cfilsfil@cisco.com>, "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
Subject: New Version Notification for draft-ali-spring-bfd-sr-policy= -02.txt

=C2=A0

A new version of I-D, draft-ali-spring-bfd-sr-= policy-02.txt

has been successfully submitted by Nagendra Ku= mar Nainar and posted to the

IETF repository.

=C2=A0

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ali-spring-bfd-sr-policy

Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 02

Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Bidirectional Forwarding Detection (BFD) for Segment Routing Policie= s for Traffic Engineering

Document date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2018-10-22

Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Submission

Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 11

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://www.ietf.org/internet-drafts/draft-ali-spring-bfd-sr-policy-02.txt

Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 https://datatracker.ietf.org/doc/draft-ali= -spring-bfd-sr-policy/

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-ali-spring-= bfd-sr-policy-02

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/= draft-ali-spring-bfd-sr-policy<= /span>

Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdiff?url2=3Dd= raft-ali-spring-bfd-sr-policy-02

=C2=A0

Abstract:

=C2=A0=C2=A0 Segment Routing (SR) allows a hea= dend node to steer a packet flow

=C2=A0=C2=A0 along any path using a segment li= st which is referred to as a SR

=C2=A0=C2=A0 Policy.=C2=A0=C2=A0Intermediate p= er-flow states are eliminated thanks to source

=C2=A0=C2=A0 routing.=C2=A0=C2=A0The header of= a packet steered in an SR Policy is augmented

=C2=A0=C2=A0 with the ordered list of segments= associated with that SR Policy.

=C2=A0=C2=A0 Bidirectional Forwarding Detectio= n (BFD) is used to monitor different

=C2=A0=C2=A0 kinds of paths between node.=C2= =A0=C2=A0BFD mechanisms can be also used to

=C2=A0=C2=A0 monitor the availability of the p= ath indicated by a SR Policy and to

=C2=A0=C2=A0 detect any failures.=C2=A0=C2=A0S= eamless BFD (S-BFD) extensions provide a

=C2=A0=C2=A0 simplified mechanism which is sui= table for monitoring of paths that

=C2=A0=C2=A0 are setup dynamically and on a la= rge scale.

=C2=A0

=C2=A0=C2=A0 This document describes the use o= f Seamless BFD (S-BFD) mechanism to

=C2=A0=C2=A0 monitor the SR Policies that are = used for Traffic Engineering (TE) in

=C2=A0=C2=A0 SR deployments.

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

=C2=A0

=C2=A0

Please note that it may take a couple of minut= es from the time of submission

until the htmlized version and diff are availa= ble at tools.ietf.org.

=C2=A0

The IETF Secretariat

=C2=A0

=C2=A0

--000000000000bd2d010578fd61f9-- From nobody Wed Oct 24 13:30:17 2018 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 E3D63130E13 for ; Wed, 24 Oct 2018 13:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 dFgQKR_hMu5m for ; Wed, 24 Oct 2018 13:30:12 -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 B8032128D68 for ; Wed, 24 Oct 2018 13:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46424; q=dns/txt; s=iport; t=1540413011; x=1541622611; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2kNoZ3huWtpxEeiGPAQSWFKCDcQJ16NmjMA6N87vW1U=; b=nJhxw6HTiUzAl0pxOFDiU6cD1icMWZ9ctDKcSkRcUOaT5YSixUC+nPgK Rf9kFXa7zvpTRoRedvZjsG2rNs7dOBPTXj6/If/fMA7UH9oNEVA1o7yw6 lka4uIiTdR83v4M1ufh5fPT848esHUHUD4dB2nmtrG4XiVmPTK82ACWI6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADW1NBb/4cNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1IL2Z/KAqDa4gYjBeBaCWIeo4egXo?= =?us-ascii?q?LAQElhEcCF4J0ITQNDQEDAQECAQECbRwMhToBAQEEIwpKAhACAQgRAwECIQE?= =?us-ascii?q?GAwICAh8RFAkIAgQBDQUbgwYBgR1MAxUPqW2BLoQwAgxAPYJKDYIYi2IXggC?= =?us-ascii?q?BECgME4JMglZFAQECAQEWgWcGEAiCRTGCJgKIX4EJhFQWhX+JYS4JAoZkhmy?= =?us-ascii?q?DJhEGgVJMhCmDF4ZZiS6DNHqIdQIRFIEmDRA4gVVwFRohKgGCQQmCRohKhT5?= =?us-ascii?q?vAYsigR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,421,1534809600"; d="scan'208,217";a="190502563" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 20:30:10 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w9OKUAcQ024720 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2018 20:30:10 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 15:30:09 -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.1395.000; Wed, 24 Oct 2018 15:30:09 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Greg Mirsky , "Zafar Ali (zali)" CC: spring Thread-Topic: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt Thread-Index: AQHUalVL6EoL8dhbuUGdjyALlBGp4KUslvWAgAJxcoD//+RmgA== Date: Wed, 24 Oct 2018 20:30:09 +0000 Message-ID: References: <154024675512.13647.2522788833729168667.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.133] Content-Type: multipart/alternative; boundary="_000_E096E5BA36194D128BDDBE1FF63FDCF4ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 20:30:15 -0000 --_000_E096E5BA36194D128BDDBE1FF63FDCF4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiBUaGUgc2VjdGlvbiBkZWZp bmluZyBjb250cm9sbGVkIHJldHVybiBwYXRoIGlzIHVzaW5nIFMtQkZEIEVjaG8gdGhhdCBpcyBk ZWZpbmVkIGluIHNlY3Rpb24gMTAgb2YgUkZDNzg4MC4gQXMgeW91IG1heSBiZSBhd2FyZSwgZWNo byBwYWNrZXRzIGFyZSBzZWxmLWdlbmVyYXRlZC90ZXJtaW5hdGVkLiBJdCBkb2VzIG5vdCBtYW5k YXRlIHRvIHVzZSBZRCBhcyBTQkZEUmVmbGVjdG9yIGlkLiBTaW5jZSB0aGUgZWNobyBwYWNrZXQg aXMgbm90IGluc3BlY3RlZC9wcm9jZXNzZWQgYnkgYW55IG5vZGVzIG90aGVyIHRoYW4gdGhlIElu aXRpYXRvciwgdGhlIGRldGFpbHMgaW5jbHVkZWQgc3VjaCBhcyBNRC9ZRCAob3IgYW55IGRldGFp bHMgaW4gdGhlIGNvbnRyb2wgcGFja2V0KSBhcmUgYSBsb2NhbCBpbXBsZW1lbnRhdGlvbiBtYXR0 ZXIuIEEgc25pcCBmcm9tIHNlY3Rpb24gMTAgYmVsb3c6DQoNClRoZSBmb2xsb3dpbmcgYXNwZWN0 cyBvZiBTLUJGRCBFY2hvIGZ1bmN0aW9ucyBhcmUgbGVmdCBhcw0KICAgaW1wbGVtZW50YXRpb24g ZGV0YWlscyBhbmQgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQ6DQoNCiAg IG8gIEZvcm1hdCBvZiB0aGUgUy1CRkQgRWNobyBwYWNrZXQgKGUuZy4sIGRhdGEgYmV5b25kIFVE UCBoZWFkZXIpLg0KICAgbyAgUHJvY2VkdXJlcyBvbiB3aGVuIGFuZCBob3cgdG8gdXNlIHRoZSBT LUJGRCBFY2hvIGZ1bmN0aW9uLg0KDQpIb3BlIHRoaXMgY2xhcmlmaWVzLg0KDQpSZWdhcmRzLA0K TmFnZW5kcmENCg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBvbiBi ZWhhbGYgb2YgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCkRhdGU6IFdlZG5l c2RheSwgT2N0b2JlciAyNCwgMjAxOCBhdCAyOjA5IFBNDQpUbzogIlphZmFyIEFsaSAoemFsaSki IDx6YWxpQGNpc2NvLmNvbT4NCkNjOiBzcHJpbmcgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbGkt c3ByaW5nLWJmZC1zci1wb2xpY3ktMDIudHh0DQoNCkhpIEFsaSwNCnRoYW5rIHlvdSBmb3IgeW91 ciBraW5kIGNvbnNpZGVyYXRpb24gb2YgbXkgY29tbWVudHMuIEkndmUgcmVhZCB0aGUgbmV3IHZl cnNpb24gYW5kIHNlY3Rpb24gMy4zIGluIHBhcnRpY3VsYXIuIFBsZWFzZSBraW5kbHkgY29uc2lk ZXIgbXkgY29tbWVudHM6DQoNCiAgKiAgIEkgcmVjYWxsIHRoYXQgdGhlIGlkZWEgdG8gY29uc3Ry dWN0IFNSIHR1bm5lbCB0aHJvdWdoIHRoZSBuZXR3b3JrIHRvIHRlcm1pbmF0ZSBhdCB0aGUgc2Vu ZGVyIGRpc2N1c3NlZCBpbiBSRkMgODQwMzsNCiAgKiAgIGlmIHRoZSB0ZXN0IHByb2JlIHdpdGgg dGhlIGxhYmVsIHN0YWNrIGFzIHtCLCBDLCBELCBDLCBBfSBpcyB0aGUgUy1CRkQgY29udHJvbCBw YWNrZXQsIHRoZSBTQkZESW5pdGlhdG9yIHdpbGwgbm90IHJlY2VpdmUgYSBzaW5nbGUgUy1CRkQg cGFja2V0LiBJbiBvdGhlciB3b3JkcywgdGhlIHByb3Bvc2VkIGFwcHJvYWNoIHRvIGNvbnRyb2wg dGhlIHJldHVybiBwYXRoIHdpbGwgYnJlYWsgdGhlIFMtQkZEIGJlY2F1c2UgU0JGRFJlZmxlY3Rv ciBkb2VzIG5vdCByZWNlaXZlIHRoZSBTLUJGRCBwYWNrZXQgYXMgaXQgcGFzc2VzIHRocm91Z2gg dW50aWwgdGhlIHNwZWNpZmllZCBTUiB0dW5uZWwgYmVlbiBjcm9zc2VkLg0KICAqICAgQW5vdGhl ciBwcm9ibGVtIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBpcyB0aGF0IHRoZSBTLUJGRCBjb250 cm9sIHBhY2tldCByZWNlaXZlZCBieSBTQkZESW5pdGlhdG9yIGhhcyB0aGUgZGVzdGluYXRpb24g VURQIHBvcnQgNzc4NCBhbmQgdGhlIHZhbHVlIG9mIFlvdXIgRGlzY3JpbWluYXRvciBpcyB0aGUg b25lIGFkdmVydGlzZWQsIGV4cGxpY2l0bHkgb3IgaW1wbGljaXRseSwgYnkgIFNCRkRSZWZsZWN0 b3IsIG5vdCAgU0JGREluaXRpYXRvci4NCkluIHN1bW1hcnksIEkgY29uY2x1ZGUgdGhhdCB0aGUg YXBwcm9hY2ggcHJvcG9zZWQgaW4gc2VjdGlvbiAzLjMgaXMgbm90IHRlY2huaWNhbGx5IHZpYWJs ZSBhbmQgY2Fubm90IGFkZHJlc3MgbXkgZWFybGllciBjb21tZW50cy4NCg0KUmVnYXJkcywNCkdy ZWcNCg0KT24gTW9uLCBPY3QgMjIsIDIwMTggYXQgOTo1MCBQTSBaYWZhciBBbGkgKHphbGkpIDx6 YWxpQGNpc2NvLmNvbTxtYWlsdG86emFsaUBjaXNjby5jb20+PiB3cm90ZToNCkhpIEdyZWcgYW5k IHRoZSBXRywNCg0KV2UgaGF2ZSB1cGRhdGUgZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5 IHRvIGFkZHJlc3MgY29tbWVudHMgd2UgcmVjZWl2ZWQgb24gdGhlIGxpc3Qgb3IgZHVyaW5nIFdH IHNlc3Npb24gcHJlc2VudGF0aW9uLiBUaGlzIGluY2x1ZGVzIGNvbW1lbnQgb24gY29udHJvbGxp bmcgdGhlIHJldHVybiBwYXRoLg0KDQpDYW4geW91IHBsZWFzZSByZXZpZXcgdGhlIGNoYW5nZXMg YW5kIGFkdmlzZSBvZiB5b3VyIGNvbW1lbnRzPw0KDQpUaGFua3MNCg0KUmVnYXJkcyDigKYgWmFm YXINCg0KRnJvbTogImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPiIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxOCBhdCA2OjE5 IFBNDQpUbzogIk5hZ2VuZHJhIEt1bWFyIE5haW5hciAobmFpa3VtYXIpIiA8bmFpa3VtYXJAY2lz Y28uY29tPG1haWx0bzpuYWlrdW1hckBjaXNjby5jb20+PiwgIktldGFuIFRhbGF1bGlrYXIgKGtl dGFudCkiIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lzY28uY29tPj4sICJaYWZh ciBBbGkgKHphbGkpIiA8emFsaUBjaXNjby5jb208bWFpbHRvOnphbGlAY2lzY28uY29tPj4sICJD YXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkiIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNw aWduYXRhQGNpc2NvLmNvbT4+LCAiQ2xhcmVuY2UgRmlsc2ZpbHMgKGNmaWxzZmlsKSIgPGNmaWxz ZmlsQGNpc2NvLmNvbTxtYWlsdG86Y2ZpbHNmaWxAY2lzY28uY29tPj4sICJOYWdlbmRyYSBLdW1h ciBOYWluYXIgKG5haWt1bWFyKSIgPG5haWt1bWFyQGNpc2NvLmNvbTxtYWlsdG86bmFpa3VtYXJA Y2lzY28uY29tPj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt YWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3ktMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IE5hZ2VuZHJhIEt1bWFyIE5haW5hciBhbmQgcG9zdGVkIHRvIHRo ZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgICAgICAgIGRyYWZ0LWFsaS1z cHJpbmctYmZkLXNyLXBvbGljeQ0KUmV2aXNpb246ICAgICAgICAgICAgICAwMg0KVGl0bGU6ICAg ICAgICAgICAgICAgICAgICAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJG RCkgZm9yIFNlZ21lbnQgUm91dGluZyBQb2xpY2llcyBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZw0K RG9jdW1lbnQgZGF0ZTogICAgICAgICAgICAgICAyMDE4LTEwLTIyDQpHcm91cDogICAgICAgICAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAgICAgICAgICAx MQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3ktMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9s aWN5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1h bGktc3ByaW5nLWJmZC1zci1wb2xpY3ktMDINCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeQ0K RGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1h bGktc3ByaW5nLWJmZC1zci1wb2xpY3ktMDINCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IFJvdXRp bmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8gc3RlZXIgYSBwYWNrZXQgZmxvdw0KICAg YWxvbmcgYW55IHBhdGggdXNpbmcgYSBzZWdtZW50IGxpc3Qgd2hpY2ggaXMgcmVmZXJyZWQgdG8g YXMgYSBTUg0KICAgUG9saWN5LiAgSW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRlcyBhcmUgZWxp bWluYXRlZCB0aGFua3MgdG8gc291cmNlDQogICByb3V0aW5nLiAgVGhlIGhlYWRlciBvZiBhIHBh Y2tldCBzdGVlcmVkIGluIGFuIFNSIFBvbGljeSBpcyBhdWdtZW50ZWQNCiAgIHdpdGggdGhlIG9y ZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGggdGhhdCBTUiBQb2xpY3kuDQog ICBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGlzIHVzZWQgdG8gbW9u aXRvciBkaWZmZXJlbnQNCiAgIGtpbmRzIG9mIHBhdGhzIGJldHdlZW4gbm9kZS4gIEJGRCBtZWNo YW5pc21zIGNhbiBiZSBhbHNvIHVzZWQgdG8NCiAgIG1vbml0b3IgdGhlIGF2YWlsYWJpbGl0eSBv ZiB0aGUgcGF0aCBpbmRpY2F0ZWQgYnkgYSBTUiBQb2xpY3kgYW5kIHRvDQogICBkZXRlY3QgYW55 IGZhaWx1cmVzLiAgU2VhbWxlc3MgQkZEIChTLUJGRCkgZXh0ZW5zaW9ucyBwcm92aWRlIGENCiAg IHNpbXBsaWZpZWQgbWVjaGFuaXNtIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBtb25pdG9yaW5nIG9m IHBhdGhzIHRoYXQNCiAgIGFyZSBzZXR1cCBkeW5hbWljYWxseSBhbmQgb24gYSBsYXJnZSBzY2Fs ZS4NCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBvZiBTZWFtbGVzcyBCRkQg KFMtQkZEKSBtZWNoYW5pc20gdG8NCiAgIG1vbml0b3IgdGhlIFNSIFBvbGljaWVzIHRoYXQgYXJl IHVzZWQgZm9yIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBpbg0KICAgU1IgZGVwbG95bWVudHMu DQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMu aWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_E096E5BA36194D128BDDBE1FF63FDCF4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9A3828AD6DD3F94894BA0DFA818D2E8F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubS02NTYzMjE0MTg5 MTA4MTI4MjAybTMxMjk0NTEyNTg1NTYxMTk1MDFhcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUt bmFtZTptXy02NTYzMjE0MTg5MTA4MTI4MjAybV8zMTI5NDUxMjU4NTU2MTE5NTAxYXBwbGUtdGFi LXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIwMzM0MTcyNDA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03ODg4NDAxNDt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEdyZWcsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3IgeW91 ciBjb21tZW50cy4gVGhlIHNlY3Rpb24gZGVmaW5pbmcgY29udHJvbGxlZCByZXR1cm4gcGF0aCBp cyB1c2luZyBTLUJGRCBFY2hvIHRoYXQgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDEwIG9mIFJGQzc4 ODAuIEFzIHlvdSBtYXkgYmUgYXdhcmUsIGVjaG8gcGFja2V0cyBhcmUgc2VsZi1nZW5lcmF0ZWQv dGVybWluYXRlZC4gSXQgZG9lcyBub3QgbWFuZGF0ZSB0byB1c2UgWUQgYXMgU0JGRFJlZmxlY3Rv cg0KIGlkLiBTaW5jZSB0aGUgZWNobyBwYWNrZXQgaXMgbm90IGluc3BlY3RlZC9wcm9jZXNzZWQg YnkgYW55IG5vZGVzIG90aGVyIHRoYW4gdGhlIEluaXRpYXRvciwgdGhlIGRldGFpbHMgaW5jbHVk ZWQgc3VjaCBhcyBNRC9ZRCAob3IgYW55IGRldGFpbHMgaW4gdGhlIGNvbnRyb2wgcGFja2V0KSBh cmUgYSBsb2NhbCBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIuIEEgc25pcCBmcm9tIHNlY3Rpb24gMTAg YmVsb3c6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUg Zm9sbG93aW5nIGFzcGVjdHMgb2YgUy1CRkQgRWNobyBmdW5jdGlvbnMgYXJlIGxlZnQgYXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGF0aW9uIGRldGFpbHMgYW5kIGFyZSBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IG8mbmJzcDsgRm9ybWF0IG9mIHRoZSBTLUJGRCBFY2hvIHBhY2tldCAoZS5nLiwg ZGF0YSBiZXlvbmQgVURQIGhlYWRlcikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFBy b2NlZHVyZXMgb24gd2hlbiBhbmQgaG93IHRvIHVzZSB0aGUgUy1CRkQgRWNobyBmdW5jdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvcGUgdGhpcyBjbGFyaWZpZXMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5OYWdlbmRyYSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+c3ByaW5nICZs dDtzcHJpbmctYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEdyZWcgTWlyc2t5ICZs dDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwg T2N0b2JlciAyNCwgMjAxOCBhdCAyOjA5IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtaYWZhciBB bGkgKHphbGkpJnF1b3Q7ICZsdDt6YWxpQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPnNw cmluZyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3Nw cmluZ10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxpLXNwcmluZy1i ZmQtc3ItcG9saWN5LTAyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h aWxPcmlnaW5hbEJvZHkiPkhpIEFsaSwgPG86cD48L286cD48L2E+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPnRoYW5rIHlvdSBmb3IgeW91ciBraW5kIGNvbnNpZGVyYXRpb24gb2YgbXkgY29tbWVudHMu IEkndmUgcmVhZCB0aGUgbmV3IHZlcnNpb24gYW5kIHNlY3Rpb24gMy4zIGluIHBhcnRpY3VsYXIu IFBsZWFzZSBraW5kbHkgY29uc2lkZXIgbXkgY29tbWVudHM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5JIHJlY2FsbCB0aGF0IHRoZSBpZGVhIHRvIGNvbnN0cnVjdCBTUiB0 dW5uZWwgdGhyb3VnaCB0aGUgbmV0d29yayB0byB0ZXJtaW5hdGUgYXQgdGhlIHNlbmRlciBkaXNj dXNzZWQgaW4gUkZDIDg0MDM7PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPmlmIHRoZSB0ZXN0IHByb2JlIHdpdGggdGhlIGxhYmVsIHN0 YWNrIGFzJm5ic3A7e0IsIEMsIEQsIEMsIEF9IGlzIHRoZSBTLUJGRCBjb250cm9sIHBhY2tldCwg dGhlIFNCRkRJbml0aWF0b3Igd2lsbCBub3QgcmVjZWl2ZSBhIHNpbmdsZSBTLUJGRCBwYWNrZXQu IEluIG90aGVyIHdvcmRzLCB0aGUgcHJvcG9zZWQgYXBwcm9hY2ggdG8gY29udHJvbCB0aGUgcmV0 dXJuIHBhdGggd2lsbA0KIGJyZWFrIHRoZSBTLUJGRCBiZWNhdXNlIFNCRkRSZWZsZWN0b3IgZG9l cyBub3QgcmVjZWl2ZSB0aGUgUy1CRkQgcGFja2V0IGFzIGl0IHBhc3NlcyB0aHJvdWdoIHVudGls IHRoZSBzcGVjaWZpZWQgU1IgdHVubmVsIGJlZW4mbmJzcDtjcm9zc2VkLiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Bbm90 aGVyIHByb2JsZW0gb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIHRoYXQgdGhlIFMtQkZEIGNv bnRyb2wgcGFja2V0IHJlY2VpdmVkIGJ5IFNCRkRJbml0aWF0b3IgaGFzIHRoZSBkZXN0aW5hdGlv biBVRFAgcG9ydCA3Nzg0IGFuZCB0aGUgdmFsdWUgb2YgWW91ciBEaXNjcmltaW5hdG9yIGlzIHRo ZSBvbmUgYWR2ZXJ0aXNlZCwgZXhwbGljaXRseSBvciBpbXBsaWNpdGx5LA0KIGJ5Jm5ic3A7IFNC RkRSZWZsZWN0b3IsIG5vdCZuYnNwOyBTQkZESW5pdGlhdG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JbiBzdW1tYXJ5LCBJIGNvbmNsdWRlIHRoYXQgdGhl IGFwcHJvYWNoIHByb3Bvc2VkIGluIHNlY3Rpb24gMy4zIGlzIG5vdCB0ZWNobmljYWxseSB2aWFi bGUgYW5kIGNhbm5vdCBhZGRyZXNzIG15IGVhcmxpZXIgY29tbWVudHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5HcmVnJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5PbiBNb24sIE9jdCAyMiwgMjAxOCBhdCA5OjUwIFBNIFphZmFyIEFsaSAoemFsaSkgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86emFsaUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij56YWxpQGNpc2NvLmNvbTwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+SGkgR3JlZyBhbmQgdGhlIFdHLA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PldlIGhhdmUgdXBkYXRlIGRyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeSB0byBhZGRyZXNz IGNvbW1lbnRzIHdlIHJlY2VpdmVkIG9uIHRoZSBsaXN0IG9yIGR1cmluZyBXRyBzZXNzaW9uIHBy ZXNlbnRhdGlvbi4gVGhpcyBpbmNsdWRlcw0KIGNvbW1lbnQgb24gY29udHJvbGxpbmcgdGhlIHJl dHVybiBwYXRoLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Q2FuIHlvdSBwbGVhc2UgcmV2aWV3IHRoZSBj aGFuZ2VzIGFuZCBhZHZpc2Ugb2YgeW91ciBjb21tZW50cz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+UmVnYXJkcyDi gKYgWmFmYXINCjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij4mcXVvdDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVv dDsNCiAmbHQ7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE9jdG9iZXIgMjIsIDIwMTggYXQgNjoxOSBQTTxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7TmFnZW5kcmEgS3VtYXIgTmFpbmFyIChuYWlrdW1hcikmcXVv dDsgJmx0Ozwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5haWt1bWFyQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5uYWlrdW1hckBjaXNjby5jb208L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDssDQogJnF1b3Q7S2V0 YW4gVGFsYXVsaWthciAoa2V0YW50KSZxdW90OyAmbHQ7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJt YWlsdG86a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5rZXRhbnRAY2lzY28uY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4mZ3Q7LA0KICZxdW90O1phZmFyIEFsaSAoemFsaSkmcXVvdDsgJmx0Ozwvc3Bhbj48L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnphbGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPnphbGlAY2lzY28uY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mZ3Q7LA0KICZxdW90O0NhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSZx dW90OyAmbHQ7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPmNwaWduYXRhQGNpc2NvLmNvbTwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0OywNCiAmcXVvdDtD bGFyZW5jZSBGaWxzZmlscyAoY2ZpbHNmaWwpJnF1b3Q7ICZsdDs8L3NwYW4+PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpjZmlsc2ZpbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Y2ZpbHNmaWxAY2lzY28uY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mZ3Q7LA0KICZxdW90O05hZ2VuZHJhIEt1bWFyIE5haW5hciAobmFpa3Vt YXIpJnF1b3Q7ICZsdDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuYWlrdW1hckBjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+bmFpa3VtYXJAY2lzY28u Y29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxpLXNw cmluZy1iZmQtc3ItcG9saWN5LTAyLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGEgbmFtZT0ibV8tNjU2MzIxNDE4OTEwODEyODIwMl9t XzMxMjk0NTEyNTg1NTYxMSI+Jm5ic3A7PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFsaS1zcHJp bmctYmZkLXNyLXBvbGljeS0wMi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmFnZW5k cmEgS3VtYXIgTmFpbmFyIGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPk5hbWU6PHNwYW4gY2xhc3M9Im0tNjU2 MzIxNDE4OTEwODEyODIwMm0zMTI5NDUxMjU4NTU2MTE5NTAxYXBwbGUtdGFiLXNwYW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmRyYWZ0LWFs aS1zcHJpbmctYmZkLXNyLXBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+UmV2aXNpb246PHNwYW4gY2xhc3M9Im0tNjU2MzIxNDE4OTEwODEyODIw Mm0zMTI5NDUxMjU4NTU2MTE5NTAxYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij5UaXRsZTo8c3BhbiBjbGFzcz0ibS02NTYzMjE0MTg5MTA4MTI4MjAybTMxMjk0NTEyNTg1 NTYxMTk1MDFhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+QmlkaXJlY3Rpb25h bCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBmb3IgU2VnbWVudCBSb3V0aW5nIFBvbGljaWVz IGZvciBUcmFmZmljIEVuZ2luZWVyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5Eb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJtLTY1NjMyMTQxODkx MDgxMjgyMDJtMzEyOTQ1MTI1ODU1NjExOTUwMWFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4yMDE4LTEwLTIyPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Hcm91cDo8c3BhbiBjbGFzcz0ibS02NTYzMjE0MTg5 MTA4MTI4MjAybTMxMjk0NTEyNTg1NTYxMTk1MDFhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+SW5kaXZpZHVhbCBTdWJt aXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Q YWdlczo8c3BhbiBjbGFzcz0ibS02NTYzMjE0MTg5MTA4MTI4MjAybTMxMjk0NTEyNTg1NTYxMTk1 MDFhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+MTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBv bGljeS0wMi50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyLnR4dDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS8iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3kv PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5IdG1saXplZDombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBv bGljeS0wMjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SHRtbGl6 ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1hbGktc3ByaW5nLWJm ZC1zci1wb2xpY3kiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFsaS1zcHJpbmctYmZkLXNy LXBvbGljeS0wMjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BYnN0 cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu YnNwOyZuYnNwOyBTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8g c3RlZXIgYSBwYWNrZXQgZmxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7IGFsb25nIGFueSBwYXRoIHVzaW5nIGEgc2VnbWVudCBs aXN0IHdoaWNoIGlzIHJlZmVycmVkIHRvIGFzIGEgU1I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyBQb2xpY3kuJm5ic3A7Jm5ic3A7 SW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRlcyBhcmUgZWxpbWluYXRlZCB0aGFua3MgdG8gc291 cmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz cDsmbmJzcDsgcm91dGluZy4mbmJzcDsmbmJzcDtUaGUgaGVhZGVyIG9mIGEgcGFja2V0IHN0ZWVy ZWQgaW4gYW4gU1IgUG9saWN5IGlzIGF1Z21lbnRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7IHdpdGggdGhlIG9yZGVyZWQgbGlz dCBvZiBzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGggdGhhdCBTUiBQb2xpY3kuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgQmlkaXJl Y3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpcyB1c2VkIHRvIG1vbml0b3IgZGlm ZmVyZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4m bmJzcDsmbmJzcDsga2luZHMgb2YgcGF0aHMgYmV0d2VlbiBub2RlLiZuYnNwOyZuYnNwO0JGRCBt ZWNoYW5pc21zIGNhbiBiZSBhbHNvIHVzZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyBtb25pdG9yIHRoZSBhdmFpbGFiaWxp dHkgb2YgdGhlIHBhdGggaW5kaWNhdGVkIGJ5IGEgU1IgUG9saWN5IGFuZCB0bzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7IGRldGVj dCBhbnkgZmFpbHVyZXMuJm5ic3A7Jm5ic3A7U2VhbWxlc3MgQkZEIChTLUJGRCkgZXh0ZW5zaW9u cyBwcm92aWRlIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiZuYnNwOyZuYnNwOyBzaW1wbGlmaWVkIG1lY2hhbmlzbSB3aGljaCBpcyBzdWl0YWJsZSBm b3IgbW9uaXRvcmluZyBvZiBwYXRocyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgYXJlIHNldHVwIGR5bmFtaWNhbGx5IGFu ZCBvbiBhIGxhcmdlIHNjYWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBv ZiBTZWFtbGVzcyBCRkQgKFMtQkZEKSBtZWNoYW5pc20gdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyBtb25pdG9yIHRoZSBTUiBQ b2xpY2llcyB0aGF0IGFyZSB1c2VkIGZvciBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkgaW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNw OyBTUiBkZXBsb3ltZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij51bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8L3NwYW4+PGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+dG9vbHMuaWV0Zi5vcmc8L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E096E5BA36194D128BDDBE1FF63FDCF4ciscocom_-- From nobody Wed Oct 24 20:26:17 2018 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 663AE130DD2; Wed, 24 Oct 2018 20:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.968 X-Spam-Level: X-Spam-Status: No, score=-14.968 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 JVSNb6W7o5mM; Wed, 24 Oct 2018 20:26:12 -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 DC6FD12F18C; Wed, 24 Oct 2018 20:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23312; q=dns/txt; s=iport; t=1540437971; x=1541647571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tYfwm+cPBZuJIGOoh99ibH4+1g2uCX3Q8HYU0/Wy9mM=; b=hkXA8z2Wa/J8/mizM5jbAlvgp2VVs4nN1hDS+QlWWgRGMQhXUHDbMWqX G5B/gXHUfrcK386hH1aIerg9AHX0TQkcLAafwc0C+tM8vIAaWTCKyhrzq Z9igtGS0mDxeHLqW21qRjmvt5woTpqi3dF4K6SMEjHoCzUIVV01FPQcrH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABUN9Fb/5tdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDXdmfygKgyw/iBiMGIINlxmBJANTCwEBJYR?= =?us-ascii?q?HAheCdCE0DQ0BAwEBAgEBAm0cDIU6AQEBAQMMFwpMEAIBBgIRAQMBASgDAgI?= =?us-ascii?q?CMBQDBggCBAENBQiDGoEdZA+Lf5tNgS6KKgWLYheBQT+BEYMSgxsBAQIBghS?= =?us-ascii?q?CTYJXAohxhUuGFYlATwkChmWKCh+BUoR1iEiBKIJmiXyJbwIRFIEmHTg0DYE?= =?us-ascii?q?UcBWDJ4ImFxKISoU+bwEBiyGBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,422,1534809600"; d="scan'208,217";a="471183372" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2018 03:26:09 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w9P3Q97e032764 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Oct 2018 03:26:09 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 22:26:08 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Wed, 24 Oct 2018 22:26:08 -0500 From: "Ketan Talaulikar (ketant)" To: Przemyslaw Krol , "spring@ietf.org" CC: "draft-ietf-idr-segment-routing-te-policy@ietf.org" , "Shyam Sethuram (shsethur)" , "Swadesh Agrawal (swaagraw)" , "draft-ietf-spring-segment-routing-policy@ietf.org" Thread-Topic: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency Thread-Index: AQHUa8RBVlJlxOCrNUCfz4/b8fOSnKUvRn8A Date: Thu, 25 Oct 2018 03:26:08 +0000 Message-ID: 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.41.46] Content-Type: multipart/alternative; boundary="_000_ea77b1e910e04117a320536b7de7d5dbXCHALN008ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 03:26:15 -0000 --_000_ea77b1e910e04117a320536b7de7d5dbXCHALN008ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUEssDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGluY2x1ZGluZyB0aGUgQkdQIGRy YWZ0IGF1dGhvcnMgdG8ga2VlcCB0aGVtIHBvc3RlZC4NCg0KUGxlYXNlIGNoZWNrIGlubGluZSBi ZWxvdy4NCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIFByemVteXNsYXcgS3JvbA0KU2VudDogMjQgT2N0b2JlciAyMDE4IDIzOjM1DQpUbzogc3By aW5nQGlldGYub3JnDQpTdWJqZWN0OiBbc3ByaW5nXSBkcmFmdC1wcmV2aWRpLWlkci1zZWdtZW50 LXJvdXRpbmctdGUtcG9saWN5IC0gQlNJRCBmbGFnIGluY29uc2lzdGVuY3kNCg0KQXV0aG9ycywN Cg0KVGhlcmUgc2VlbXMgdG8gYmUgYSBkaXNjcmVwYW5jeSBpbiBCU0lEIGZsYWcgb3JkZXJpbmc6 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0 aW5nLXRlLXBvbGljeS0wNCNzZWN0aW9uLTIuNC4yDQoNCiAgIDAgMSAyIDMgNCA1IDYgNw0KICAg Ky0rLSstKy0rLSstKy0rLSsNCiAgIHxTfEl8ICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0r LSstKw0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItc2VnbWVu dC1yb3V0aW5nLXRlLXBvbGljeS0wNCNzZWN0aW9uLTguNQ0KDQpCaXQgICAgRGVzY3JpcHRpb24g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiAgIDAgICAgIERyb3AgVXBvbiBJbnZhbGlkIEZsYWcgKEktRmxhZykgICAg ICAgICAgICAgVGhpcyBkb2N1bWVudA0KICAgMSAgICAgU3BlY2lmaWVkLUJTSUQtT25seSBGbGFn IChTLUZsYWcpICAgICAgICAgICBUaGlzIGRvY3VtZW50DQoNCldvdWxkIGl0IGJlIHBvc3NpYmxl IHRvIGNsYXJpZnkgdGhpcyBwbGVhc2U/DQpbS1RdIFRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhhdCBp dCBsb29rcyBsaWtlIHBlcmhhcHMgdGhlIElBTkEgc2VjdGlvbiBuZWVkcyB0byBiZSB1cGRhdGVk IHRvIHJlZmxlY3QgdGhlIG9yZGVyaW5nIGluIHRoZSBtYWluIHNlY3Rpb24gdGV4dC4NCg0KQWxz bywgZHJhZnQgbWVudGlvbnMgIlYtZmxhZzogU2VnbWVudCBWZXJpZmljYXRpb24gRmxhZyI6DQoN CiAgIFYtRmxhZzogVGhpcyBmbGFnIGVuY29kZXMgdGhlICJTZWdtZW50IFZlcmlmaWNhdGlvbiIg YmVoYXZpb3IuICBJdA0KICAgICAgaXMgdXNlZCBieSBTUlBNIGFzIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDUgaW4NCiAgICAgIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeV0u DQoNCllldCBpdHMgbWVhbmluZyBkb2Vzbid0IGxvb2sgdG8gYmUgY2xlYXJseSBkZXNjcmliZWQg aW4gZWl0aGVyIGRyYWZ0cy4NCltLVF0gSSBiZWxpZXZlIHRoaXMgaXMgcmVmZXJyaW5nIHRvIHRo ZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWMgNS4xIG9mIHRoZSBkcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5Lg0KDQogICBvICBJdCBpcyBlbXB0eS4NCiAgIG8gIEl0cyB3ZWln aHQgaXMgMC4NCiAgIG8gIFRoZSBoZWFkZW5kIGlzIHVuYWJsZSB0byBwZXJmb3JtIHBhdGggcmVz b2x1dGlvbiBmb3IgdGhlIGZpcnN0IFNJRA0KICAgICAgaW50byBvbmUgb3IgbW9yZSBvdXRnb2lu ZyBpbnRlcmZhY2UocykgYW5kIG5leHQtaG9wKHMpLg0KICAgbyAgVGhlIGhlYWRlbmQgaXMgdW5h YmxlIHRvIHBlcmZvcm0gU0lEIHJlc29sdXRpb24gZm9yIGFueSBub24tZmlyc3QNCiAgICAgIFNJ RCBvZiB0eXBlIDMtdGhyb3VnaC0xMSBpbnRvIGFuIE1QTFMgbGFiZWwgb3IgYW4gU1J2NiBTSUQu DQogICBvICBUaGUgaGVhZGVuZCB2ZXJpZmljYXRpb24gZmFpbHMgZm9yIGFueSBTSUQgZm9yIHdo aWNoIHZlcmlmaWNhdGlvbg0KICAgICAgaGFzIGJlZW4gZXhwbGljaXRseSByZXF1ZXN0ZWQuDQoN CiAgICJVbmFibGUgdG8gcGVyZm9ybSBwYXRoIHJlc29sdXRpb24iIG1lYW5zIHRoYXQgdGhlIGhl YWRlbmQgaGFzIG5vDQogICBwYXRoIHRvIHRoZSBTSUQgaW4gaXRzIFNSIGRhdGFiYXNlLg0KDQog ICBTSUQgdmVyaWZpY2F0aW9uIGlzIHBlcmZvcm1lZCB3aGVuIHRoZSBoZWFkZW5kIGlzIGV4cGxp Y2l0bHkNCiAgIHJlcXVlc3RlZCB0byB2ZXJpZnkgU0lEKHMpIGJ5IHRoZSBjb250cm9sbGVyIHZp YSB0aGUgc2lnbmFsaW5nDQogICBwcm90b2NvbCB1c2VkLg0KDQpOb3JtYWxseSwgb25seSB0aGUg cGF0aCByZXNvbHV0aW9uIGlzIG5lZWRlZCB0byBiZSBwZXJmb3JtZWQgYW5kIHRoYXQgdG9vIGZv ciB0aGUgZmlyc3QgU0lELiBUaGUg4oCcVuKAnSBmbGFnIG1heSBiZSB1c2VkIHRvIGluZGljYXRl IHRvIHRoZSBoZWFkZW5kIHRvIHBlcmZvcm0gdGhlIHZlcmlmaWNhdGlvbi4gV2hlbiB0aGUgU0lE IGlzIG9mIHR5cGUgMSBvciAyIHRoZW4gaXQgaXMgb25seSBhYm91dCBjaGVja2luZyB0aGUgcGF0 aCByZXNvbHV0aW9uIChyZWFjaGFiaWxpdHkpIGZvciBpdC4gV2hlbiB0aGUgU0lEIGlzIG9mIHR5 cGUgMy10aHJvdWdoLTExIHRoZW4gaXQgd291bGQgYmUgYWJvdXQgZmlyc3QgcmVzb2x2aW5nIHRv IGdldCB0aGUgU0lEIHZhbHVlIGFuZCB0aGVuIGRvaW5nIGl0cyBwYXRoIHJlc29sdXRpb24uIFBl cmhhcHMgdGhpcyB0ZXh0IGluIHRoZSBTUiBQb2xpY3kgQXJjaGl0ZWN0dXJlIGRyYWZ0IGNvdWxk IGNsYXJpZnkgdGhpcyBmdXJ0aGVyIChpZiBuZWVkZWQpIGFuZCB3ZSB1c2Ug4oCcU0lEIHZlcmlm aWNhdGlvbuKAnSB0ZXJtIGluIHRoZSBCR1AgZHJhZnQgZm9yIGFsaWdubWVudCBvZiB0ZXJtaW5v bG9naWVzLg0KDQpUaGFua3MsDQpLZXRhbg0KDQp0aGFua3MsDQpwaw0KDQoNCi0tDQpQcnplbXlz bGF3ICJQSyIgS3JvbCB8DQoNCiBTdHJhdGVnaWMgTmV0d29yayBFbmdpbmVlcg0KDQppbmcgfCBw a3JvbEBnb29nbGUuY29tPG1haWx0bzpwa3JvbEBnb29nbGUuY29tPg0KDQoNCg== --_000_ea77b1e910e04117a320536b7de7d5dbXCHALN008ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tSU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBQSyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgaW5jbHVkaW5nIHRoZSBCR1AgZHJhZnQgYXV0aG9y cyB0byBrZWVwIHRoZW0gcG9zdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tSU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QbGVhc2UgY2hlY2sgaW5saW5lIGJl bG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc3ByaW5nICZsdDtzcHJpbmctYm91bmNlc0BpZXRm Lm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+UHJ6ZW15c2xhdyBLcm9sPGJyPg0KPGI+U2Vu dDo8L2I+IDI0IE9jdG9iZXIgMjAxOCAyMzozNTxicj4NCjxiPlRvOjwvYj4gc3ByaW5nQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzcHJpbmddIGRyYWZ0LXByZXZpZGktaWRyLXNlZ21l bnQtcm91dGluZy10ZS1wb2xpY3kgLSBCU0lEIGZsYWcgaW5jb25zaXN0ZW5jeTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZXJlIHNlZW1zIHRvIGJlIGEgZGlzY3JlcGFuY3kgaW4gQlNJRCBmbGFnIG9yZGVyaW5n OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLXNlZ21lbnQt cm91dGluZy10ZS1wb2xpY3ktMDQjc2VjdGlvbi0yLjQuMiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3ktMDQjc2VjdGlv bi0yLjQuMjxicj4NCjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDswIDEgMiAzIDQgNSA2IDc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO3xTfEl8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p ZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeS0wNCNzZWN0aW9uLTguNSI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kt MDQjc2VjdGlvbi04LjU8YnI+DQo8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qml0Jm5ic3A7ICZuYnNwOyBEZXNjcmlw dGlvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgUmVmZXJlbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDswJm5ic3A7ICZu YnNwOyAmbmJzcDtEcm9wIFVwb24gSW52YWxpZCBGbGFnIChJLUZsYWcpJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzEm bmJzcDsgJm5ic3A7ICZuYnNwO1NwZWNpZmllZC1CU0lELU9ubHkgRmxhZyAoUy1GbGFnKSZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldv dWxkIGl0IGJlIHBvc3NpYmxlIHRvIGNsYXJpZnkgdGhpcyBwbGVhc2U/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+W0tUXSBUaGFua3MgZm9yIGNhdGNoaW5nIHRoYXQgaXQgbG9va3MgbGlrZSBwZXJoYXBzIHRo ZSBJQU5BIHNlY3Rpb24gbmVlZHMgdG8gYmUgdXBkYXRlZCB0byByZWZsZWN0IHRoZSBvcmRlcmlu ZyBpbiB0aGUgbWFpbiBzZWN0aW9uIHRleHQuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgZHJhZnQgbWVudGlvbnMgJnF1b3Q7Vi1mbGFnOiBT ZWdtZW50IFZlcmlmaWNhdGlvbiBGbGFnJnF1b3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1YtRmxhZzog VGhpcyBmbGFnIGVuY29kZXMgdGhlICZxdW90O1NlZ21lbnQgVmVyaWZpY2F0aW9uJnF1b3Q7IGJl aGF2aW9yLiZuYnNwOyBJdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgdXNlZCBieSBTUlBNIGFzIGRlc2Ny aWJlZCBpbiBzZWN0aW9uIDUgaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFtJLUQuaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeV0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWV0IGl0cyBtZWFuaW5nIGRvZXNuJ3QgbG9vayB0 byBiZSBjbGVhcmx5IGRlc2NyaWJlZCBpbiBlaXRoZXIgZHJhZnRzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltLVF0gSSBiZWxpZXZlIHRoaXMgaXMgcmVmZXJyaW5nIHRvIHRoZSBmb2xsb3dpbmcgdGV4dCBp biBTZWMgNS4xIG9mIHRoZSBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBvJm5ic3A7IEl0IGlzIGVtcHR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg byZuYnNwOyBJdHMgd2VpZ2h0IGlzIDAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRo ZSBoZWFkZW5kIGlzIHVuYWJsZSB0byBwZXJmb3JtIHBhdGggcmVzb2x1dGlvbiBmb3IgdGhlIGZp cnN0IFNJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50byBvbmUg b3IgbW9yZSBvdXRnb2luZyBpbnRlcmZhY2UocykgYW5kIG5leHQtaG9wKHMpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgaGVhZGVuZCBpcyB1bmFibGUgdG8gcGVyZm9ybSBT SUQgcmVzb2x1dGlvbiBmb3IgYW55IG5vbi1maXJzdDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNJRCBvZiB0eXBlIDMtdGhyb3VnaC0xMSBpbnRvIGFuIE1Q TFMgbGFiZWwgb3IgYW4gU1J2NiBTSUQuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBoZWFkZW5kIHZlcmlmaWNhdGlv biBmYWlscyBmb3IgYW55IFNJRCBmb3Igd2hpY2ggdmVyaWZpY2F0aW9uPG86cD48L286cD48L3Nw YW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGFzIGJlZW4gZXhwbGljaXRseSByZXF1 ZXN0ZWQuPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ICZxdW90O1Vu YWJsZSB0byBwZXJmb3JtIHBhdGggcmVzb2x1dGlvbiZxdW90OyBtZWFucyB0aGF0IHRoZSBoZWFk ZW5kIGhhcyBubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcGF0aCB0byB0aGUgU0lEIGluIGl0cyBT UiBkYXRhYmFzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOw0KPGI+U0lE IHZlcmlmaWNhdGlvbiBpcyBwZXJmb3JtZWQgd2hlbiB0aGUgaGVhZGVuZCBpcyBleHBsaWNpdGx5 PG86cD48L286cD48L2I+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVxdWVzdGVkIHRvIHZlcmlmeSBTSUQocykg YnkgdGhlIGNvbnRyb2xsZXIgdmlhIHRoZSBzaWduYWxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBwcm90b2NvbCB1c2VkPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Lg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3JtYWxs eSwgb25seSB0aGUgcGF0aCByZXNvbHV0aW9uIGlzIG5lZWRlZCB0byBiZSBwZXJmb3JtZWQgYW5k IHRoYXQgdG9vIGZvciB0aGUgZmlyc3QgU0lELiBUaGUg4oCcVuKAnSBmbGFnIG1heSBiZSB1c2Vk IHRvIGluZGljYXRlIHRvIHRoZSBoZWFkZW5kIHRvIHBlcmZvcm0NCiB0aGUgdmVyaWZpY2F0aW9u LiBXaGVuIHRoZSBTSUQgaXMgb2YgdHlwZSAxIG9yIDIgdGhlbiBpdCBpcyBvbmx5IGFib3V0IGNo ZWNraW5nIHRoZSBwYXRoIHJlc29sdXRpb24gKHJlYWNoYWJpbGl0eSkgZm9yIGl0LiBXaGVuIHRo ZSBTSUQgaXMgb2YgdHlwZSAzLXRocm91Z2gtMTEgdGhlbiBpdCB3b3VsZCBiZSBhYm91dCBmaXJz dCByZXNvbHZpbmcgdG8gZ2V0IHRoZSBTSUQgdmFsdWUgYW5kIHRoZW4gZG9pbmcgaXRzIHBhdGgg cmVzb2x1dGlvbi4NCiBQZXJoYXBzIHRoaXMgdGV4dCBpbiB0aGUgU1IgUG9saWN5IEFyY2hpdGVj dHVyZSBkcmFmdCBjb3VsZCBjbGFyaWZ5IHRoaXMgZnVydGhlciAoaWYgbmVlZGVkKSBhbmQgd2Ug dXNlIOKAnFNJRCB2ZXJpZmljYXRpb27igJ0gdGVybSBpbiB0aGUgQkdQIGRyYWZ0IGZvciBhbGln bm1lbnQgb2YgdGVybWlub2xvZ2llcy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+S2V0YW48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6 Ny41cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3Bh Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRDUwRjI1IDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTUiPlByemVt eXNsYXcgJnF1b3Q7UEsmcXVvdDsgS3JvbCB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N Cjx0ZCBub3dyYXA9IiIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgIzMzNjlF OCAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNTU1NTU1Ij4mbmJzcDtTdHJhdGVnaWMgTmV0d29yayBFbmdpbmVlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8dGQgbm93cmFwPSIiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICMwMDk5MzkgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzMzNjlFOCAxLjVwdDtwYWRk aW5nOjIuMHB0Ij5pbmcgfDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjMDA5OTM5IDEu NXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpwa3JvbEBnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPnBrcm9sQGdvb2ds ZS5jb208L3NwYW4+PC9hPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPHRkIG5vd3JhcD0iIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRUVCMjExIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ea77b1e910e04117a320536b7de7d5dbXCHALN008ciscocom_-- From nobody Thu Oct 25 07:50:58 2018 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 22B7D130E63 for ; Thu, 25 Oct 2018 07:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 E1XTYG94stSn for ; Thu, 25 Oct 2018 07:50:52 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 A98C7130E5A for ; Thu, 25 Oct 2018 07:50:52 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id h14-v6so2091011itf.1 for ; Thu, 25 Oct 2018 07:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ll5VtRroqZY+dW18etJrrcMYrbBhI3/UGWXh5tSWIx8=; b=aQitezawk41bpOLeStiv6XcKO4F6PnJ3oEFqL53h/ayKHxcvKZTQFvnezj6z5QfDT+ PEbSBBDoR/FhJ5+6fl355RIj7E9mUEp2R8a0tHnUM1Ee9hRg8R79mT/Bm+TfnEhXpDQZ ApCw2TntYxu1yo01JnyySFJuEVWg1B9WiTbHRmpSO+JIDTK843jMDaxv0WzEWTguNwOh 4vAgmjooeXPAD1Dp5eKmXZNHY31L1185uz4rGu5A1qOseJMKHd7wOYMmuCfYKT8ifgR+ A7My+CFXAN/9ixilzPTEMeYnftiLGeSG8DQp/rDVZ9FzYJoPx+pbMjYwUz+pQv+tj9Dk No0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ll5VtRroqZY+dW18etJrrcMYrbBhI3/UGWXh5tSWIx8=; b=nSszB3W375nKX9rmdTv1typ53+ZEAnsZBAMjxy5xINUkr6Jcqe8/Xuwrlm53CFj8pL 6S0Sz/9YsNvljTH25EbUHkJWoAJjKdKIaUaUtLbf4OwhqchanC+VYquHcTWrmqILy0hy H8F3OPZhd4t/co3bN3GEUY3JnURzWF/IYM2KKlfjLDH2bpthtuEA6XphTi4s3caeZBx8 oSPmuh9JO5f6FYkOcWLJ2juYBi/3ZgVymQqs1XkgKmBOKTALTH01W/IQEwd+pK0Sbrpo m+WfneXC1y9PekBEkQjtKHp8Otn9CjxK2ocEIqs6zVEdcnbp0bEJKmcY22tRciPXEB72 Vt7g== X-Gm-Message-State: AGRZ1gJQMemAOopOSE+ptkCYTcEyYrV9fdZZMGi4YrN7urfAcwoIBSzH D4v351u0c3G2M4DqWB91niMfJ2y4AowG8Ban6XW3Kw== X-Google-Smtp-Source: AJdET5ed0B1qMD+c/W2yL21iSiXDvChKmVnb9GyYKlFiWSVDE0Vh2Bt+ieGHIe8lS2wneON/3SRj5kXvOlb/RBOZ13A= X-Received: by 2002:a24:9cc5:: with SMTP id b188-v6mr1118220ite.167.1540479051651; Thu, 25 Oct 2018 07:50:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Przemyslaw Krol Date: Thu, 25 Oct 2018 07:50:14 -0700 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: spring@ietf.org, draft-ietf-idr-segment-routing-te-policy@ietf.org, shsethur@cisco.com, swaagraw@cisco.com, draft-ietf-spring-segment-routing-policy@ietf.org Content-Type: multipart/alternative; boundary="000000000000a8ca3f05790eba1b" Archived-At: Subject: Re: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 14:50:55 -0000 --000000000000a8ca3f05790eba1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thanks for the reply. *[KT] Thanks for catching that it looks like perhaps the IANA section needs to be updated to reflect the ordering in the main section text.* [PK] Great, thanks for that. Is it safe to assume the ordering in 2.4.2 (instead of 8.5) to be final then? *Normally, only the path resolution is needed to be performed and that too for the first SID. The =E2=80=9CV=E2=80=9D flag may be used to indicate to = the headend to perform the verification. When the SID is of type 1 or 2 then it is only about checking the path resolution (reachability) for it. When the SID is of type 3-through-11 then it would be about first resolving to get the SID value and then doing its path resolution. Perhaps this text in the SR Policy Architecture draft could clarify this further (if needed) and we use =E2=80=9CSID verification=E2=80=9D term in the BGP draft for alignment of t= erminologies.* [PK] I reckon even pointing to draft-ietf-idr-segment-routing-te-policy in the context of SID verification would make the meaning of V-flag much more obvious. Anyhow, this is just a suggestion as it's been signaled to me that it's not easy to make that association. thanks, On Wed, Oct 24, 2018 at 8:26 PM Ketan Talaulikar (ketant) wrote: > Hi PK, > > > > Thanks for your review and including the BGP draft authors to keep them > posted. > > > > Please check inline below. > > > > *From:* spring *On Behalf Of *Przemyslaw Krol > *Sent:* 24 October 2018 23:35 > *To:* spring@ietf.org > *Subject:* [spring] draft-previdi-idr-segment-routing-te-policy - BSID > flag inconsistency > > > > Authors, > > > > There seems to be a discrepancy in BSID flag ordering: > > > https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04#s= ection-2.4.2 > > > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > |S|I| | > > +-+-+-+-+-+-+-+-+ > > > > > https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04#s= ection-8.5 > > > Bit Description Reference > > > -------------------------------------------------------------------------= -------- > > 0 Drop Upon Invalid Flag (I-Flag) This document > > 1 Specified-BSID-Only Flag (S-Flag) This document > > > > Would it be possible to clarify this please? > > *[KT] Thanks for catching that it looks like perhaps the IANA section > needs to be updated to reflect the ordering in the main section text.* > > > > Also, draft mentions "V-flag: Segment Verification Flag": > > > > V-Flag: This flag encodes the "Segment Verification" behavior. It > > is used by SRPM as described in section 5 in > > [I-D.ietf-spring-segment-routing-policy]. > > > > Yet its meaning doesn't look to be clearly described in either drafts. > > *[KT] I believe this is referring to the following text in Sec 5.1 of the > draft-ietf-spring-segment-routing-policy.* > > > > o It is empty. > > o Its weight is 0. > > o The headend is unable to perform path resolution for the first SID > > into one or more outgoing interface(s) and next-hop(s). > > * o The headend is unable to perform SID resolution for any non-first* > > * SID of type 3-through-11 into an MPLS label or an SRv6 SID.* > > * o The headend verification fails for any SID for which verification* > > * has been explicitly requested.* > > > > "Unable to perform path resolution" means that the headend has no > > path to the SID in its SR database. > > > > *SID verification is performed when the headend is explicitly* > > * requested to verify SID(s) by the controller via the signaling* > > * protocol used*. > > > > *Normally, only the path resolution is needed to be performed and that to= o > for the first SID. The =E2=80=9CV=E2=80=9D flag may be used to indicate t= o the headend to > perform the verification. When the SID is of type 1 or 2 then it is only > about checking the path resolution (reachability) for it. When the SID is > of type 3-through-11 then it would be about first resolving to get the SI= D > value and then doing its path resolution. Perhaps this text in the SR > Policy Architecture draft could clarify this further (if needed) and we u= se > =E2=80=9CSID verification=E2=80=9D term in the BGP draft for alignment of= terminologies.* > > > > *Thanks,* > > *Ketan* > > > > thanks, > > pk > > > > > > -- > > Przemyslaw "PK" Krol | > > Strategic Network Engineer > > ing | pkrol@google.com > > > --=20 Przemyslaw "PK" Krol | Strategic Network Engineer ing | pkrol@google.com --000000000000a8ca3f05790eba1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ketan,

Thanks for t= he reply.


[KT] Thanks= for catching that it looks like perhaps the IANA section needs to be updat= ed to reflect the ordering in the main section text.
[PK] Great, thanks for that. Is it safe to assume the ordering in 2.= 4.2 (instead of 8.5) to be final then?

Normally, only the path resolution is needed = to be performed and that too for the first SID. The =E2=80=9CV=E2=80=9D fla= g may be used to indicate to the headend to perform the verification. When = the SID is of type 1 or 2 then it is only about checking the path resolutio= n (reachability) for it. When the SID is of type 3-through-11 then it would= be about first resolving to get the SID value and then doing its path reso= lution. Perhaps this text in the SR Policy Architecture draft could clarify= this further (if needed) and we use =E2=80=9CSID verification=E2=80=9D ter= m in the BGP draft for alignment of terminologies.=


[PK] I rec= kon even pointing to=C2=A0draft-ietf-idr-segment-routing-te-policy in the c= ontext of SID verification would make the meaning of V-flag much more obvio= us. Anyhow, this is just a suggestion as it's been signaled to me that = it's not easy to make that association.

thanks= ,

Hi PK,

=C2=A0

Thanks for your review= and including the BGP draft authors to keep them posted.

=C2=A0

Please check inline be= low.

=C2=A0

From: spring <spring-bounces@ietf.org> On Behalf Of Przemyslaw Krol
Sent: 24 October 2018 23:35
To: spring@ietf= .org
Subject: [spring] draft-previdi-idr-segment-routing-te-policy - BSID= flag inconsistency

=C2=A0

Authors,

=C2=A0

There seems to be a discrepancy in BSID flag orderin= g:

=C2=A0

=C2=A0 =C2=A00 1 2 3 4 5 6 7

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+

=C2=A0 =C2=A0|S|I|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+

=C2=A0


Bit=C2=A0 =C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Reference

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

=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0Drop Upon Invalid = Flag (I-Flag)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document<= u>

=C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0Specified-BSID-Onl= y Flag (S-Flag)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document

=C2=A0

Would it be possible to clarify this please?<= u>

[KT] Thanks for catching that i= t looks like perhaps the IANA section needs to be updated to reflect the or= dering in the main section text.

=C2=A0

Also, draft mentions "V-flag: Segment Verificat= ion Flag":

=C2=A0

=C2=A0 =C2=A0V-Flag: This flag encodes the "Seg= ment Verification" behavior.=C2=A0 It

=C2=A0 =C2=A0 =C2=A0 is used by SRPM as described in= section 5 in

=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-spring-segment-routin= g-policy].

=C2=A0

Yet its meaning doesn't look to be clearly descr= ibed in either drafts.

[KT] I believe this is referrin= g to the following text in Sec 5.1 of the draft-ietf-spring-segment-routing= -policy.

=C2=A0=

=C2=A0=C2=A0 o=C2=A0 It is empty.

=C2=A0=C2=A0 o=C2=A0 Its weight is 0.

=C2=A0=C2=A0 o=C2=A0 The headend is unable to = perform path resolution for the first SID

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 into one or mor= e outgoing interface(s) and next-hop(s).

=C2=A0=C2=A0 o=C2=A0 The headend is unable = to perform SID resolution for any non-first

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SID of type = 3-through-11 into an MPLS label or an SRv6 SID.<= /u>

=C2=A0=C2=A0 o=C2=A0 The headend verificati= on fails for any SID for which verification

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has been exp= licitly requested.

=C2=A0

=C2=A0=C2=A0 "Unable to perform path reso= lution" means that the headend has no

=C2=A0=C2=A0 path to the SID in its SR databas= e.

=C2=A0

=C2=A0=C2=A0 SID verification is performed when the headend is explicitly

=C2=A0=C2=A0 requested to verify SID(s) by = the controller via the signaling

=C2=A0=C2=A0 protocol used= .

=C2=A0

Normally, only the path resolut= ion is needed to be performed and that too for the first SID. The =E2=80=9C= V=E2=80=9D flag may be used to indicate to the headend to perform the verification. When the SID is of type 1 or 2 then it is only about che= cking the path resolution (reachability) for it. When the SID is of type 3-= through-11 then it would be about first resolving to get the SID value and = then doing its path resolution. Perhaps this text in the SR Policy Architecture draft could clarify this f= urther (if needed) and we use =E2=80=9CSID verification=E2=80=9D term in th= e BGP draft for alignment of terminologies.

=C2=A0=

Thanks,

Ketan<= /b>

=C2=A0

thanks,

pk

=C2=A0

=C2=A0

--

Przemyslaw "PK" Krol |

=C2=A0Strategic Network Engineer

ing |=C2=A0pkrol@google.com=C2=A0

=C2=A0



--
=
= --000000000000a8ca3f05790eba1b-- From nobody Thu Oct 25 12:41:27 2018 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 5A96D130EA7 for ; Thu, 25 Oct 2018 12:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ktz28Ab-7lNo for ; Thu, 25 Oct 2018 12:41:21 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 E4986130EC0 for ; Thu, 25 Oct 2018 12:41:20 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id y22-v6so2723764lji.10 for ; Thu, 25 Oct 2018 12:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t2U1HWio/gDLicPiAo2yU2PMgYku4hOwl1sG3bzpHO4=; b=HKk4pihMkaDVVKI4QcGbHjr0Gt37V7YuiV02FrEc86T+oOE/MdwaWEEY+U7ye3GnIe Jv5tHN1gcp0LxzISUNZozuOzQE5NuysAvhUU4/GfqEfuasNMJmsVvbmzff93qjzYPvZq VE0+plvGikxDZvLKoC8Qi5KOvs9Phm2/VXvoNmcyi/56Ol4s0Ln3osrdyB8qUw2ZLqEm s+QNjTQIKyf8hsYii47OnDgkkN0hZG+ULlUfN3+BKXYK0xsuyh9Vjw/vjD09KqQnfe7Z dcBvKJFbbHtavypNo2WC8ur6oMhpvXPTqtBqMNJ9Es+wGJGkYUEA78jhLbH4z82qbNnW BKdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t2U1HWio/gDLicPiAo2yU2PMgYku4hOwl1sG3bzpHO4=; b=VHx7YGiAjJLH3yC3O6KrWCxxB/PsHLaJsx5zc/Ge8zCa6K2l6StMax1oh2oBg5s6m/ l+ncURQm7RcQ0bhbiB4ksFpvHL72kwfPFHdZ2o8DgszPEuaHMMe5T+KPEHHLXbYu39Rl mSdYeHr3/YY/oRlu/XuKrxVdqiFLcOT5njohHLjhs6mgs+4c3LYGn+zv41b919O+8lTg gykbQmkkWO8reLl0lozRFJ2SCnB3gwAiIAa40QbzjWUayOz+C/SWYTnKJPg6FV6It6in aNZhax0VCJB0kZUU+5Ql7rAtmna0VDaNqTGq/p+fUz1gH6joXzMlAHoWJCli0wDDgf6z +WTw== X-Gm-Message-State: AGRZ1gJwMJpVIh4J6ulIValER0hzK+rsflucs0ftBmJt7lB/WMKwA67N ucynhB6wjTAQwf1XquOxvmsfov7AQM7C0nDphL4= X-Google-Smtp-Source: AJdET5c6xMIql79DDepnlf4AcYo5j5UIbzfBn0VuafrV2izLjlB3Uz271UsUxj2kc6rbf2rMrsNpMLOG7SSsZWorNhQ= X-Received: by 2002:a2e:140c:: with SMTP id u12-v6mr369655ljd.76.1540496478896; Thu, 25 Oct 2018 12:41:18 -0700 (PDT) MIME-Version: 1.0 References: <154024675512.13647.2522788833729168667.idtracker@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Thu, 25 Oct 2018 12:41:06 -0700 Message-ID: To: "Nagendra Kumar Nainar (naikumar)" Cc: "Zafar Ali (zali)" , spring Content-Type: multipart/alternative; boundary="00000000000067088c057912c94d" Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 19:41:25 -0000 --00000000000067088c057912c94d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nagendra, yes, you're correct and I was not, thank you for pointing that out. Indeed, Echo mode, whether BFD or S-BFD, may be used as the test probe to help with the characterization of the defect. But such use of Echo will increase the load on the sender and the network. As that is the price, perhaps going for a complete system based on RFC 8403 will give an operator the localization of the failure. Of course, all modes are optional. What I was pointing out with my comment, that BFD has some advantage, at least by the ability to control the reverse direction of the session. Regards, Greg On Wed, Oct 24, 2018 at 1:30 PM Nagendra Kumar Nainar (naikumar) < naikumar@cisco.com> wrote: > Hi Greg, > > > > Thank you for your comments. The section defining controlled return path > is using S-BFD Echo that is defined in section 10 of RFC7880. As you may = be > aware, echo packets are self-generated/terminated. It does not mandate to > use YD as SBFDReflector id. Since the echo packet is not > inspected/processed by any nodes other than the Initiator, the details > included such as MD/YD (or any details in the control packet) are a local > implementation matter. A snip from section 10 below: > > > > The following aspects of S-BFD Echo functions are left as > > implementation details and are outside the scope of this document: > > > > o Format of the S-BFD Echo packet (e.g., data beyond UDP header). > > o Procedures on when and how to use the S-BFD Echo function. > > > > Hope this clarifies. > > > > Regards, > > Nagendra > > > > > > *From: *spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Wednesday, October 24, 2018 at 2:09 PM > *To: *"Zafar Ali (zali)" > *Cc: *spring > *Subject: *Re: [spring] FW: New Version Notification for > draft-ali-spring-bfd-sr-policy-02.txt > > > > Hi Ali, > > thank you for your kind consideration of my comments. I've read the new > version and section 3.3 in particular. Please kindly consider my comments= : > > - I recall that the idea to construct SR tunnel through the network to > terminate at the sender discussed in RFC 8403; > - if the test probe with the label stack as {B, C, D, C, A} is the > S-BFD control packet, the SBFDInitiator will not receive a single S-BF= D > packet. In other words, the proposed approach to control the return pa= th > will break the S-BFD because SBFDReflector does not receive the S-BFD > packet as it passes through until the specified SR tunnel been crossed= . > - Another problem of the proposed solution is that the S-BFD control > packet received by SBFDInitiator has the destination UDP port 7784 and= the > value of Your Discriminator is the one advertised, explicitly or > implicitly, by SBFDReflector, not SBFDInitiator. > > In summary, I conclude that the approach proposed in section 3.3 is not > technically viable and cannot address my earlier comments. > > > > Regards, > > Greg > > > > On Mon, Oct 22, 2018 at 9:50 PM Zafar Ali (zali) wrote: > > Hi Greg and the WG, > > > > We have update draft-ali-spring-bfd-sr-policy to address comments we > received on the list or during WG session presentation. This includes > comment on controlling the return path. > > > > Can you please review the changes and advise of your comments? > > > > Thanks > > > > Regards =E2=80=A6 Zafar > > > > *From: *"internet-drafts@ietf.org" > *Date: *Monday, October 22, 2018 at 6:19 PM > *To: *"Nagendra Kumar Nainar (naikumar)" , "Ketan > Talaulikar (ketant)" , "Zafar Ali (zali)" < > zali@cisco.com>, "Carlos Pignataro (cpignata)" , > "Clarence Filsfils (cfilsfil)" , "Nagendra Kumar > Nainar (naikumar)" > *Subject: *New Version Notification for > draft-ali-spring-bfd-sr-policy-02.txt > > > > > > A new version of I-D, draft-ali-spring-bfd-sr-policy-02.txt > > has been successfully submitted by Nagendra Kumar Nainar and posted to th= e > > IETF repository. > > > > Name: draft-ali-spring-bfd-sr-policy > > Revision: 02 > > Title: Bidirectional Forwarding Detection (BFD) for > Segment Routing Policies for Traffic Engineering > > Document date: 2018-10-22 > > Group: Individual Submission > > Pages: 11 > > URL: > https://www.ietf.org/internet-drafts/draft-ali-spring-bfd-sr-policy-02.tx= t > > Status: > https://datatracker.ietf.org/doc/draft-ali-spring-bfd-sr-policy/ > > Htmlized: > https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ali-spring-bfd-sr-policy > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ali-spring-bfd-sr-policy-02 > > > > Abstract: > > Segment Routing (SR) allows a headend node to steer a packet flow > > along any path using a segment list which is referred to as a SR > > Policy. Intermediate per-flow states are eliminated thanks to source > > routing. The header of a packet steered in an SR Policy is augmented > > with the ordered list of segments associated with that SR Policy. > > Bidirectional Forwarding Detection (BFD) is used to monitor different > > kinds of paths between node. BFD mechanisms can be also used to > > monitor the availability of the path indicated by a SR Policy and to > > detect any failures. Seamless BFD (S-BFD) extensions provide a > > simplified mechanism which is suitable for monitoring of paths that > > are setup dynamically and on a large scale. > > > > This document describes the use of Seamless BFD (S-BFD) mechanism to > > monitor the SR Policies that are used for Traffic Engineering (TE) in > > SR deployments. > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > --00000000000067088c057912c94d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nagendra,
yes, you're correct and I was not, th= ank you for pointing that out. Indeed, Echo mode, whether BFD or S-BFD, may= be used as the test probe to help with the characterization of the defect.= But such use of Echo will increase the load on the sender and the network.= As that is the price, perhaps going for a complete system based on RFC 840= 3 will give an operator the localization of the failure. Of course, all mod= es are optional. What I was pointing out with my comment, that BFD has some= advantage, at least by the ability to control the reverse direction of the= session.

Regards,
Greg

<= div class=3D"gmail_quote">
On Wed, Oct 24, 2018 at 1:30 PM = Nagendra Kumar Nainar (naikumar) <= naikumar@cisco.com> wrote:

Hi Greg,

=C2=A0

Thank you for your comments. The section defining co= ntrolled return path is using S-BFD Echo that is defined in section 10 of R= FC7880. As you may be aware, echo packets are self-generated/terminated. It= does not mandate to use YD as SBFDReflector id. Since the echo packet is not inspected/processed by any nodes other th= an the Initiator, the details included such as MD/YD (or any details in the= control packet) are a local implementation matter. A snip from section 10 = below:

=C2=A0

The following aspects of S-BFD Echo functions = are left as

=C2=A0=C2=A0 implementation details and are ou= tside the scope of this document:

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Format of the S-BFD Echo = packet (e.g., data beyond UDP header).

=C2=A0=C2=A0 o=C2=A0 Procedures on when and ho= w to use the S-BFD Echo function.

=C2=A0

Hope this clarifies.

=C2=A0

Regards,

Nagendra

=C2=A0

=C2=A0

From= : spring <spring-bounces@ietf.= org> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Wednesday, October 24, 2018 at 2:09 PM
To: "Zafar Ali (zali)" <zali@cisco.com>
Cc: spring <= spring@ietf.org>
Subject: Re: [spring] FW: New Version Notification for draft-ali-spr= ing-bfd-sr-policy-02.txt

=C2=A0

Hi Ali,

thank you for your kind consideration of my co= mments. I've read the new version and section 3.3 in particular. Please= kindly consider my comments:

  • I recall that the idea to construct SR tunnel through the network to = terminate at the sender discussed in RFC 8403;
    • if the test probe with the label stack as=C2=A0{B, C, D, C, A} is the= S-BFD control packet, the SBFDInitiator will not receive a single S-BFD pa= cket. In other words, the proposed approach to control the return path will break the S-BFD because SBFDReflector does not receive the S-BFD packet as= it passes through until the specified SR tunnel been=C2=A0crossed.=C2=A0
  • Another problem of the proposed solution is that the S-BFD control pa= cket received by SBFDInitiator has the destination UDP port 7784 and the va= lue of Your Discriminator is the one advertised, explicitly or implicitly, by=C2=A0 SBFDReflector, not=C2=A0 SBFDInitiator.
    • =

In summary, I conclude that the approach propo= sed in section 3.3 is not technically viable and cannot address my earlier = comments.

=C2=A0

Regards,

Greg=C2=A0

=C2=A0

On Mon, Oct 22, 2018 at 9:50 PM Zafar Ali (zal= i) <zal= i@cisco.com> wrote:

Hi Greg and the WG,

=C2=A0

We have update draft-ali-spring-bfd-sr-policy = to address comments we received on the list or during WG session presentati= on. This includes comment on controlling the return path.

=C2=A0

Can you please review the changes and advise o= f your comments?

=C2=A0

Thanks

=C2=A0

Regards =E2=80=A6 Zafar

=C2=A0

From: "= internet-drafts@ietf.org&quo= t; <internet-drafts@ietf.org>
Date: Monday, October 22, 2018 at 6:19 PM
To: "Nagendra Kumar Nainar (naikumar)" <<= a href=3D"mailto:naikumar@cisco.com" target=3D"_blank">naikumar@cisco.com<= span style=3D"font-size:12.0pt;color:black">>, "Ketan Talaulikar (ketant)" <= ketant@cisco.com>, "Zafar Ali (zali)" <zali@cisco.= com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
Subject: New Version Notification for draft-ali-spring-bfd-sr-policy= -02.txt

=C2=A0

A new version of I-D, draft-ali-spring-bfd-sr-= policy-02.txt

has been successfully submitted by Nagendra Ku= mar Nainar and posted to the

IETF repository.

=C2=A0

Name:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 draft-ali-spring-bfd-sr-policy

Revision:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 02

Title:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bidirectional Forwarding Detection (BFD) for Segment Routing Policie= s for Traffic Engineering

Document date:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2018-10-22

Group:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Individual Submission

Pages:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 11

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://www.ietf.org/internet-drafts/draft-ali-spring-bfd-sr-policy-02.txt

Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 https://datatracker.ietf.org/doc/draft-ali= -spring-bfd-sr-policy/

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-ali-spring-= bfd-sr-policy-02

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/= draft-ali-spring-bfd-sr-policy<= /span>

Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdiff?url2=3Dd= raft-ali-spring-bfd-sr-policy-02

=C2=A0

Abstract:

=C2=A0=C2=A0 Segment Routing (SR) allows a hea= dend node to steer a packet flow

=C2=A0=C2=A0 along any path using a segment li= st which is referred to as a SR

=C2=A0=C2=A0 Policy.=C2=A0=C2=A0Intermediate p= er-flow states are eliminated thanks to source

=C2=A0=C2=A0 routing.=C2=A0=C2=A0The header of= a packet steered in an SR Policy is augmented

=C2=A0=C2=A0 with the ordered list of segments= associated with that SR Policy.

=C2=A0=C2=A0 Bidirectional Forwarding Detectio= n (BFD) is used to monitor different

=C2=A0=C2=A0 kinds of paths between node.=C2= =A0=C2=A0BFD mechanisms can be also used to

=C2=A0=C2=A0 monitor the availability of the p= ath indicated by a SR Policy and to

=C2=A0=C2=A0 detect any failures.=C2=A0=C2=A0S= eamless BFD (S-BFD) extensions provide a

=C2=A0=C2=A0 simplified mechanism which is sui= table for monitoring of paths that

=C2=A0=C2=A0 are setup dynamically and on a la= rge scale.

=C2=A0

=C2=A0=C2=A0 This document describes the use o= f Seamless BFD (S-BFD) mechanism to

=C2=A0=C2=A0 monitor the SR Policies that are = used for Traffic Engineering (TE) in

=C2=A0=C2=A0 SR deployments.

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

=C2=A0

=C2=A0

Please note that it may take a couple of minut= es from the time of submission

until the htmlized version and diff are availa= ble at tools.ietf= .org.

=C2=A0

The IETF Secretariat

=C2=A0

=C2=A0

--00000000000067088c057912c94d-- From nobody Thu Oct 25 19:01:06 2018 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 1B5EC130E30 for ; Thu, 25 Oct 2018 19:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OwP6MR80Dt5J for ; Thu, 25 Oct 2018 19:01:03 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 37DC4130E08 for ; Thu, 25 Oct 2018 19:01:03 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id v92-v6so4551512ybi.5 for ; Thu, 25 Oct 2018 19:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zj5L9sspJzothqLFSbNLKmHRpcMblXUMp3VVBM33pdM=; b=ivZmJAt4MMgdOwhwwzKKjqTXl2RJvw2jBhAtU5EywX9j2SggzMn4gVlPOjK1ZGe549 Xyqf+rz9MTeOKLT8JasKTKFYmeYg8VKSvtA69r7RCRbTAKN6y2nLpS563ESIsYLNtBqH cmqMeO7mxqqWWIPCgpf9zL5slZ3WUxuw/tNYTz6G1NX0iRSIc7ZG6/YOlgB/xkhjFxN4 N2EN8eT8UX7EMoNMHEjPvBgOwhQN9204oHxLxuaWcx3qTjsWKHc1CYtl/CfLfBV2PlPI W/tuRnHyojbS+CiDDbDSF3O1oWcvjU5ODnq++U84uMDzzaziCRsUtITyicsw2DKwULPn c7iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zj5L9sspJzothqLFSbNLKmHRpcMblXUMp3VVBM33pdM=; b=FAOZVB+Vwq+14FK0e6/uH1jL3Bp8AMhgXf9xTmyc2Iso3GsY1g9ZT56bTX3yZYFMH3 AHA2iRY5cBTb5p3drlTKJO6yv2l2GQBpELmiPnJO5Is1M1r+lgYRS25365UyNOk0YxCR Mg5IN3pnBQjmiJ+ORIrMjrWnEDcoQKeHLY1Fqt8qHIkDeFI3MwnYFy9rYfdML0qw4MFK 8FXDkAvA0mUmljsSfby8PSwyAwWJzmgcOPEYVT+ucVQM8QZbhAkfzQH95wiMF3qDdZli bJDpkcepVU3VwjpWZX1YhFhtRsR+I/Bbrb3KF/5FoAJ323fAYXynJHdG0xXsunPR9Gie hJRw== X-Gm-Message-State: AGRZ1gJvLQw3ifTphHpKZDFQTLYv8kxY/iXk3J+d5Pn4q7clsyvD5NCE /lphpRL8WGldvLoQCsIoKGUMhcKZ2hg9pPHPXZYC1twnlh8= X-Google-Smtp-Source: AJdET5cK1kSUZ6mhbU73z5rcUzgssRmUM5eP6epJ6oPjYF/rketbjPcqbuZ+HwFPRBC8E1AwqEJFbks3KTt5cac15XQ= X-Received: by 2002:a25:84c7:: with SMTP id x7-v6mr1705952ybm.230.1540519261744; Thu, 25 Oct 2018 19:01:01 -0700 (PDT) MIME-Version: 1.0 From: Rob Shakir Date: Thu, 25 Oct 2018 19:00:49 -0700 Message-ID: To: SPRING WG List Content-Type: multipart/alternative; boundary="0000000000005e3877057918177e" Archived-At: Subject: [spring] Agenda Uploaded for IETF 103 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 02:01:05 -0000 --0000000000005e3877057918177e Content-Type: text/plain; charset="UTF-8" Hi SPRING WG, The agenda for the SPRING working group session at IETF 103 has been uploaded to the datatracker . Again, we were oversubscribed for this session - with approximately 190 minutes of requests for the two hour slot. The majority of these drafts have not been discussed in any detail on the mailing list -- making Bruno and my job somewhat harder! Given the oversubscription, our slots are short -- please focus your presentation on the changes to your drafts, or open items that the working group needs to consider for the work. Apologies if you did not get a slot -- however, this is even more reason to start a thread with what you would have presented on the list! See you in Bangkok, -- Bruno and Rob. --0000000000005e3877057918177e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi SPRING WG,

The agenda for the SPRING= working group session at IETF 103 has been uploaded to=C2=A0the d= atatracker.

Again, we were oversubscribed for = this session - with approximately 190 minutes of requests for the two hour = slot. The majority of these drafts have not been discussed in any detail on= the mailing list -- making Bruno and my job somewhat harder!=C2=A0

Given the oversubscription, our slots are short -- please= focus your presentation on the changes to your drafts, or open items that = the working group needs to consider for the work.=C2=A0

Apologies if you did not get a slot -- however, this is even more rea= son to start a thread with what you would have presented on the list!
=

See you in Bangkok,
-- Bruno and Rob.
--0000000000005e3877057918177e-- From nobody Thu Oct 25 21:18:11 2018 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 393D712F1A6 for ; Thu, 25 Oct 2018 21:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 5jrRLnfDcEgv for ; Thu, 25 Oct 2018 21:18:06 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFD512DD85 for ; Thu, 25 Oct 2018 21:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43720; q=dns/txt; s=iport; t=1540527486; x=1541737086; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=a39qbmRqEdciiIJShxCGIlr1X3ncGH4SlIALeDnXpfM=; b=ajBFhLaGz9xhXTdkmYEegiBcAW/PYAL84ajU0WXBhVbCLnsoLJhdZWS7 MeLp76sAct7u0LWZsXfp+HZKqOMbHyNQpAPCOoJCuJkhs8BefTsOgwjke FFzhxD4eOyG1P2Gi1Y7ANfomkjs4TEtT+g1rRiItHjykbkuONcraL+KHl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAqlNJb/5NdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1IL2Z/KAqDa4gYjBeCDYh9jh+BdwM?= =?us-ascii?q?LAQEYAQyEAUYCF4J6ITQNDQEDAQECAQECbRwMhToBAQEBAwEBIUsJAhACAQg?= =?us-ascii?q?RAwECIQEGAwICAh8GCxQJCAIEDgUbgwYBgR1MAxUPpz+BLoQwAgxAgnkNghi?= =?us-ascii?q?LZxeBQT+BECgfgkyCVkUBAQIBARaBRiEGEAiCRjGCJgKIZoEJhFcWhgiJaS4?= =?us-ascii?q?JAoZnhm+DJxiBUkyEK4MbhmCJMoM5fYYtglQCERSBJg0QOIFVcBUaISoBgkE?= =?us-ascii?q?JNYpbhT5vAYwJgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,426,1534809600"; d="scan'208,217";a="191814009" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 04:18:05 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w9Q4I4Vk028299 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 04:18:05 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 00:18:04 -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.1395.000; Fri, 26 Oct 2018 00:18:03 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "Nagendra Kumar Nainar (naikumar)" , spring , "Zafar Ali (zali)" Thread-Topic: [spring] New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt Thread-Index: AQHUbOLjlZtpuTn2C0KHyKpNbNKlMQ== Date: Fri, 26 Oct 2018 04:18:03 +0000 Message-ID: <3DD11B38-8B3E-429B-8ED7-E64DCFCDE5B0@cisco.com> References: <154024675512.13647.2522788833729168667.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.100.39) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.132] Content-Type: multipart/alternative; boundary="_000_3DD11B388B3E429B8ED7E64DCFCDE5B0ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 04:18:09 -0000 --_000_3DD11B388B3E429B8ED7E64DCFCDE5B0ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KVGhlIHVzZSBvZiBhbiBSRkMgODQwMyBhcHByb2FjaCBoYXMgbm90aGluZyB0byBk byB3aXRoIHRoZSBwcm90b2NvbCB1c2VkIGZvciBDQzoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzg0MDMjcGFnZS01DQoNCiAgIHJldHVybmluZyBwaW5nIG9yIHRyYWNlcm91dGUg cGFja2V0cy4gIFBhY2tldHMgZnJvbSBhIHZhcmlldHkgb2YNCiAgIHByb3RvY29scyBjYW4gYmUg dXNlZCB0byBjaGVjayBjb250aW51aXR5LiAgVGhlc2UgaW5jbHVkZSBJbnRlcm5ldA0KICAgQ29u dHJvbCBNZXNzYWdlIFByb3RvY29sIChJQ01QKSBbUkZDMDc5Ml0gW1JGQzQ0NDNdIFtSRkM0ODg0 XQ0KICAgW1JGQzQ5NTBdLCBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQp IFtSRkM1ODg0XSwNCiAgIFNlYW1sZXNzIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rp b24gKFMtQkZEKSBbUkZDNzg4MF0NCiAgIFtSRkM3ODgxXSAoc2VlIFNlY3Rpb24gMy40IG9mIFtS RkM3ODgyXSksIGFuZCBNUExTIExTUCBwaW5nDQogICBbUkZDODAyOV0uICBUaGV5IGNhbiBhbHNv IGhhdmUgYW55IG90aGVyIE9BTSBmb3JtYXQgc3VwcG9ydGVkIGJ5IHRoZQ0KDQoNCg0KVGhhbmtz LA0KDQrigJQgQ2FybG9zIFBpZ25hdGFybw0KDQpPbiBPY3QgMjUsIDIwMTgsIGF0IDM6NDEgUE0s IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBOYWdlbmRyYSwNCnllcywgeW91J3JlIGNvcnJlY3QgYW5k IEkgd2FzIG5vdCwgdGhhbmsgeW91IGZvciBwb2ludGluZyB0aGF0IG91dC4gSW5kZWVkLCBFY2hv IG1vZGUsIHdoZXRoZXIgQkZEIG9yIFMtQkZELCBtYXkgYmUgdXNlZCBhcyB0aGUgdGVzdCBwcm9i ZSB0byBoZWxwIHdpdGggdGhlIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlIGRlZmVjdC4gQnV0IHN1 Y2ggdXNlIG9mIEVjaG8gd2lsbCBpbmNyZWFzZSB0aGUgbG9hZCBvbiB0aGUgc2VuZGVyIGFuZCB0 aGUgbmV0d29yay4gQXMgdGhhdCBpcyB0aGUgcHJpY2UsIHBlcmhhcHMgZ29pbmcgZm9yIGEgY29t cGxldGUgc3lzdGVtIGJhc2VkIG9uIFJGQyA4NDAzIHdpbGwgZ2l2ZSBhbiBvcGVyYXRvciB0aGUg bG9jYWxpemF0aW9uIG9mIHRoZSBmYWlsdXJlLiBPZiBjb3Vyc2UsIGFsbCBtb2RlcyBhcmUgb3B0 aW9uYWwuIFdoYXQgSSB3YXMgcG9pbnRpbmcgb3V0IHdpdGggbXkgY29tbWVudCwgdGhhdCBCRkQg aGFzIHNvbWUgYWR2YW50YWdlLCBhdCBsZWFzdCBieSB0aGUgYWJpbGl0eSB0byBjb250cm9sIHRo ZSByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgc2Vzc2lvbi4NCg0KUmVnYXJkcywNCkdyZWcNCg0K T24gV2VkLCBPY3QgMjQsIDIwMTggYXQgMTozMCBQTSBOYWdlbmRyYSBLdW1hciBOYWluYXIgKG5h aWt1bWFyKSA8bmFpa3VtYXJAY2lzY28uY29tPG1haWx0bzpuYWlrdW1hckBjaXNjby5jb20+PiB3 cm90ZToNCkhpIEdyZWcsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4gVGhlIHNlY3Rp b24gZGVmaW5pbmcgY29udHJvbGxlZCByZXR1cm4gcGF0aCBpcyB1c2luZyBTLUJGRCBFY2hvIHRo YXQgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDEwIG9mIFJGQzc4ODAuIEFzIHlvdSBtYXkgYmUgYXdh cmUsIGVjaG8gcGFja2V0cyBhcmUgc2VsZi1nZW5lcmF0ZWQvdGVybWluYXRlZC4gSXQgZG9lcyBu b3QgbWFuZGF0ZSB0byB1c2UgWUQgYXMgU0JGRFJlZmxlY3RvciBpZC4gU2luY2UgdGhlIGVjaG8g cGFja2V0IGlzIG5vdCBpbnNwZWN0ZWQvcHJvY2Vzc2VkIGJ5IGFueSBub2RlcyBvdGhlciB0aGFu IHRoZSBJbml0aWF0b3IsIHRoZSBkZXRhaWxzIGluY2x1ZGVkIHN1Y2ggYXMgTUQvWUQgKG9yIGFu eSBkZXRhaWxzIGluIHRoZSBjb250cm9sIHBhY2tldCkgYXJlIGEgbG9jYWwgaW1wbGVtZW50YXRp b24gbWF0dGVyLiBBIHNuaXAgZnJvbSBzZWN0aW9uIDEwIGJlbG93Og0KDQpUaGUgZm9sbG93aW5n IGFzcGVjdHMgb2YgUy1CRkQgRWNobyBmdW5jdGlvbnMgYXJlIGxlZnQgYXMNCiAgIGltcGxlbWVu dGF0aW9uIGRldGFpbHMgYW5kIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50 Og0KDQogICBvICBGb3JtYXQgb2YgdGhlIFMtQkZEIEVjaG8gcGFja2V0IChlLmcuLCBkYXRhIGJl eW9uZCBVRFAgaGVhZGVyKS4NCiAgIG8gIFByb2NlZHVyZXMgb24gd2hlbiBhbmQgaG93IHRvIHVz ZSB0aGUgUy1CRkQgRWNobyBmdW5jdGlvbi4NCg0KSG9wZSB0aGlzIGNsYXJpZmllcy4NCg0KUmVn YXJkcywNCk5hZ2VuZHJhDQoNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgR3JlZyBNaXJz a3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4N CkRhdGU6IFdlZG5lc2RheSwgT2N0b2JlciAyNCwgMjAxOCBhdCAyOjA5IFBNDQpUbzogIlphZmFy IEFsaSAoemFsaSkiIDx6YWxpQGNpc2NvLmNvbTxtYWlsdG86emFsaUBjaXNjby5jb20+Pg0KQ2M6 IHNwcmluZyA8c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFs aS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMi50eHQNCg0KSGkgQWxpLA0KdGhhbmsgeW91IGZvciB5 b3VyIGtpbmQgY29uc2lkZXJhdGlvbiBvZiBteSBjb21tZW50cy4gSSd2ZSByZWFkIHRoZSBuZXcg dmVyc2lvbiBhbmQgc2VjdGlvbiAzLjMgaW4gcGFydGljdWxhci4gUGxlYXNlIGtpbmRseSBjb25z aWRlciBteSBjb21tZW50czoNCg0KICAqICAgSSByZWNhbGwgdGhhdCB0aGUgaWRlYSB0byBjb25z dHJ1Y3QgU1IgdHVubmVsIHRocm91Z2ggdGhlIG5ldHdvcmsgdG8gdGVybWluYXRlIGF0IHRoZSBz ZW5kZXIgZGlzY3Vzc2VkIGluIFJGQyA4NDAzOw0KICAqICAgaWYgdGhlIHRlc3QgcHJvYmUgd2l0 aCB0aGUgbGFiZWwgc3RhY2sgYXMge0IsIEMsIEQsIEMsIEF9IGlzIHRoZSBTLUJGRCBjb250cm9s IHBhY2tldCwgdGhlIFNCRkRJbml0aWF0b3Igd2lsbCBub3QgcmVjZWl2ZSBhIHNpbmdsZSBTLUJG RCBwYWNrZXQuIEluIG90aGVyIHdvcmRzLCB0aGUgcHJvcG9zZWQgYXBwcm9hY2ggdG8gY29udHJv bCB0aGUgcmV0dXJuIHBhdGggd2lsbCBicmVhayB0aGUgUy1CRkQgYmVjYXVzZSBTQkZEUmVmbGVj dG9yIGRvZXMgbm90IHJlY2VpdmUgdGhlIFMtQkZEIHBhY2tldCBhcyBpdCBwYXNzZXMgdGhyb3Vn aCB1bnRpbCB0aGUgc3BlY2lmaWVkIFNSIHR1bm5lbCBiZWVuIGNyb3NzZWQuDQogICogICBBbm90 aGVyIHByb2JsZW0gb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIHRoYXQgdGhlIFMtQkZEIGNv bnRyb2wgcGFja2V0IHJlY2VpdmVkIGJ5IFNCRkRJbml0aWF0b3IgaGFzIHRoZSBkZXN0aW5hdGlv biBVRFAgcG9ydCA3Nzg0IGFuZCB0aGUgdmFsdWUgb2YgWW91ciBEaXNjcmltaW5hdG9yIGlzIHRo ZSBvbmUgYWR2ZXJ0aXNlZCwgZXhwbGljaXRseSBvciBpbXBsaWNpdGx5LCBieSAgU0JGRFJlZmxl Y3Rvciwgbm90ICBTQkZESW5pdGlhdG9yLg0KSW4gc3VtbWFyeSwgSSBjb25jbHVkZSB0aGF0IHRo ZSBhcHByb2FjaCBwcm9wb3NlZCBpbiBzZWN0aW9uIDMuMyBpcyBub3QgdGVjaG5pY2FsbHkgdmlh YmxlIGFuZCBjYW5ub3QgYWRkcmVzcyBteSBlYXJsaWVyIGNvbW1lbnRzLg0KDQpSZWdhcmRzLA0K R3JlZw0KDQpPbiBNb24sIE9jdCAyMiwgMjAxOCBhdCA5OjUwIFBNIFphZmFyIEFsaSAoemFsaSkg PHphbGlAY2lzY28uY29tPG1haWx0bzp6YWxpQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgR3JlZyBh bmQgdGhlIFdHLA0KDQpXZSBoYXZlIHVwZGF0ZSBkcmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xp Y3kgdG8gYWRkcmVzcyBjb21tZW50cyB3ZSByZWNlaXZlZCBvbiB0aGUgbGlzdCBvciBkdXJpbmcg V0cgc2Vzc2lvbiBwcmVzZW50YXRpb24uIFRoaXMgaW5jbHVkZXMgY29tbWVudCBvbiBjb250cm9s bGluZyB0aGUgcmV0dXJuIHBhdGguDQoNCkNhbiB5b3UgcGxlYXNlIHJldmlldyB0aGUgY2hhbmdl cyBhbmQgYWR2aXNlIG9mIHlvdXIgY29tbWVudHM/DQoNClRoYW5rcw0KDQpSZWdhcmRzIOKApiBa YWZhcg0KDQpGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDE4IGF0IDY6 MTkgUE0NClRvOiAiTmFnZW5kcmEgS3VtYXIgTmFpbmFyIChuYWlrdW1hcikiIDxuYWlrdW1hckBj aXNjby5jb208bWFpbHRvOm5haWt1bWFyQGNpc2NvLmNvbT4+LCAiS2V0YW4gVGFsYXVsaWthciAo a2V0YW50KSIgPGtldGFudEBjaXNjby5jb208bWFpbHRvOmtldGFudEBjaXNjby5jb20+PiwgIlph ZmFyIEFsaSAoemFsaSkiIDx6YWxpQGNpc2NvLmNvbTxtYWlsdG86emFsaUBjaXNjby5jb20+Piwg IkNhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSIgPGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86 Y3BpZ25hdGFAY2lzY28uY29tPj4sICJDbGFyZW5jZSBGaWxzZmlscyAoY2ZpbHNmaWwpIiA8Y2Zp bHNmaWxAY2lzY28uY29tPG1haWx0bzpjZmlsc2ZpbEBjaXNjby5jb20+PiwgIk5hZ2VuZHJhIEt1 bWFyIE5haW5hciAobmFpa3VtYXIpIiA8bmFpa3VtYXJAY2lzY28uY29tPG1haWx0bzpuYWlrdW1h ckBjaXNjby5jb20+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3ktMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgTmFnZW5kcmEgS3VtYXIgTmFpbmFyIGFuZCBwb3N0ZWQgdG8g dGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICAgICAgICAgZHJhZnQtYWxp LXNwcmluZy1iZmQtc3ItcG9saWN5DQpSZXZpc2lvbjogICAgICAgICAgICAgIDAyDQpUaXRsZTog ICAgICAgICAgICAgICAgICAgICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAo QkZEKSBmb3IgU2VnbWVudCBSb3V0aW5nIFBvbGljaWVzIGZvciBUcmFmZmljIEVuZ2luZWVyaW5n DQpEb2N1bWVudCBkYXRlOiAgICAgICAgICAgICAgIDIwMTgtMTAtMjINCkdyb3VwOiAgICAgICAg ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgICAgICAgICAg IDExDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMi50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbGktc3ByaW5nLWJmZC1zci1w b2xpY3kvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5 DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMg0KDQpBYnN0cmFjdDoNCiAgIFNlZ21lbnQgUm91 dGluZyAoU1IpIGFsbG93cyBhIGhlYWRlbmQgbm9kZSB0byBzdGVlciBhIHBhY2tldCBmbG93DQog ICBhbG9uZyBhbnkgcGF0aCB1c2luZyBhIHNlZ21lbnQgbGlzdCB3aGljaCBpcyByZWZlcnJlZCB0 byBhcyBhIFNSDQogICBQb2xpY3kuICBJbnRlcm1lZGlhdGUgcGVyLWZsb3cgc3RhdGVzIGFyZSBl bGltaW5hdGVkIHRoYW5rcyB0byBzb3VyY2UNCiAgIHJvdXRpbmcuICBUaGUgaGVhZGVyIG9mIGEg cGFja2V0IHN0ZWVyZWQgaW4gYW4gU1IgUG9saWN5IGlzIGF1Z21lbnRlZA0KICAgd2l0aCB0aGUg b3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGFzc29jaWF0ZWQgd2l0aCB0aGF0IFNSIFBvbGljeS4N CiAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgdXNlZCB0byBt b25pdG9yIGRpZmZlcmVudA0KICAga2luZHMgb2YgcGF0aHMgYmV0d2VlbiBub2RlLiAgQkZEIG1l Y2hhbmlzbXMgY2FuIGJlIGFsc28gdXNlZCB0bw0KICAgbW9uaXRvciB0aGUgYXZhaWxhYmlsaXR5 IG9mIHRoZSBwYXRoIGluZGljYXRlZCBieSBhIFNSIFBvbGljeSBhbmQgdG8NCiAgIGRldGVjdCBh bnkgZmFpbHVyZXMuICBTZWFtbGVzcyBCRkQgKFMtQkZEKSBleHRlbnNpb25zIHByb3ZpZGUgYQ0K ICAgc2ltcGxpZmllZCBtZWNoYW5pc20gd2hpY2ggaXMgc3VpdGFibGUgZm9yIG1vbml0b3Jpbmcg b2YgcGF0aHMgdGhhdA0KICAgYXJlIHNldHVwIGR5bmFtaWNhbGx5IGFuZCBvbiBhIGxhcmdlIHNj YWxlLg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIFNlYW1sZXNzIEJG RCAoUy1CRkQpIG1lY2hhbmlzbSB0bw0KICAgbW9uaXRvciB0aGUgU1IgUG9saWNpZXMgdGhhdCBh cmUgdXNlZCBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIGluDQogICBTUiBkZXBsb3ltZW50 cy4NCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYuLm9yZzxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0K c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQo= --_000_3DD11B388B3E429B8ED7E64DCFCDE5B0ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkdyZWcsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgdXNlIG9mIGFuIFJGQyA4NDAzIGFwcHJv YWNoIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIHByb3RvY29sIHVzZWQgZm9yIENDOjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDMjcGFnZS01IiBjbGFzcz0i Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQwMyNwYWdlLTU8L2E+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3JldHVybmluZyBwaW5nIG9yIHRyYWNlcm91dGUgcGFja2V0 cy4gJm5ic3A7UGFja2V0cyBmcm9tIGEgdmFyaWV0eSBvZjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7cHJvdG9jb2xzIGNhbiBiZSB1c2VkIHRvIGNoZWNrIGNvbnRpbnVpdHkuICZu YnNwO1RoZXNlIGluY2x1ZGUgSW50ZXJuZXQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwO0NvbnRyb2wgTWVzc2FnZSBQcm90b2NvbCAoSUNNUCkgW1JGQzA3OTJdIFtSRkM0NDQzXSBb UkZDNDg4NF08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO1tSRkM0OTUwXSwgQmlk aXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBbUkZDNTg4NF0sPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtTZWFtbGVzcyBCaWRpcmVjdGlvbmFsIEZvcndhcmRp bmcgRGV0ZWN0aW9uIChTLUJGRCkgW1JGQzc4ODBdPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OyAmbmJzcDtbUkZDNzg4MV0gKHNlZSZuYnNwO1NlY3Rpb24gMy40IG9mIFtSRkM3ODgyXSksIGFu ZCBNUExTIExTUCBwaW5nPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtbUkZDODAy OV0uICZuYnNwO1RoZXkgY2FuIGFsc28gaGF2ZSBhbnkgb3RoZXIgT0FNIGZvcm1hdCBzdXBwb3J0 ZWQgYnkgdGhlPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyI+DQpUaGFua3MsPC9kaXY+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyI+DQrigJQgQ2FybG9zIFBpZ25hdGFybzwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIE9jdCAyNSwgMjAxOCwgYXQgMzo0MSBQTSwgR3JlZyBNaXJza3kg Jmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdp bWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj5IaSBOYWdlbmRyYSwNCjxkaXYgY2xhc3M9IiI+eWVzLCB5b3UncmUgY29ycmVjdCBhbmQg SSB3YXMgbm90LCB0aGFuayB5b3UgZm9yIHBvaW50aW5nIHRoYXQgb3V0LiBJbmRlZWQsIEVjaG8g bW9kZSwgd2hldGhlciBCRkQgb3IgUy1CRkQsIG1heSBiZSB1c2VkIGFzIHRoZSB0ZXN0IHByb2Jl IHRvIGhlbHAgd2l0aCB0aGUgY2hhcmFjdGVyaXphdGlvbiBvZiB0aGUgZGVmZWN0LiBCdXQgc3Vj aCB1c2Ugb2YgRWNobyB3aWxsIGluY3JlYXNlIHRoZSBsb2FkIG9uIHRoZSBzZW5kZXINCiBhbmQg dGhlIG5ldHdvcmsuIEFzIHRoYXQgaXMgdGhlIHByaWNlLCBwZXJoYXBzIGdvaW5nIGZvciBhIGNv bXBsZXRlIHN5c3RlbSBiYXNlZCBvbiBSRkMgODQwMyB3aWxsIGdpdmUgYW4gb3BlcmF0b3IgdGhl IGxvY2FsaXphdGlvbiBvZiB0aGUgZmFpbHVyZS4gT2YgY291cnNlLCBhbGwgbW9kZXMgYXJlIG9w dGlvbmFsLiBXaGF0IEkgd2FzIHBvaW50aW5nIG91dCB3aXRoIG15IGNvbW1lbnQsIHRoYXQgQkZE IGhhcyBzb21lIGFkdmFudGFnZSwgYXQNCiBsZWFzdCBieSB0aGUgYWJpbGl0eSB0byBjb250cm9s IHRoZSByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgc2Vzc2lvbi48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+T24gV2VkLCBPY3QgMjQs IDIwMTggYXQgMTozMCBQTSBOYWdlbmRyYSBLdW1hciBOYWluYXIgKG5haWt1bWFyKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5haWt1bWFyQGNpc2NvLmNvbSIgY2xhc3M9IiI+bmFpa3VtYXJAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV8tMzAyNjc2ODYxMzY0 MjY2NDQ0N1dvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBHcmVnLDx1IGNs YXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUg Y2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuIFRoZSBzZWN0aW9uIGRlZmluaW5nIGNv bnRyb2xsZWQgcmV0dXJuIHBhdGggaXMgdXNpbmcgUy1CRkQgRWNobyB0aGF0IGlzIGRlZmluZWQg aW4gc2VjdGlvbiAxMCBvZiBSRkM3ODgwLiBBcyB5b3UgbWF5IGJlIGF3YXJlLCBlY2hvIHBhY2tl dHMgYXJlIHNlbGYtZ2VuZXJhdGVkL3Rlcm1pbmF0ZWQuIEl0IGRvZXMgbm90IG1hbmRhdGUgdG8g dXNlIFlEIGFzIFNCRkRSZWZsZWN0b3INCiBpZC4gU2luY2UgdGhlIGVjaG8gcGFja2V0IGlzIG5v dCBpbnNwZWN0ZWQvcHJvY2Vzc2VkIGJ5IGFueSBub2RlcyBvdGhlciB0aGFuIHRoZSBJbml0aWF0 b3IsIHRoZSBkZXRhaWxzIGluY2x1ZGVkIHN1Y2ggYXMgTUQvWUQgKG9yIGFueSBkZXRhaWxzIGlu IHRoZSBjb250cm9sIHBhY2tldCkgYXJlIGEgbG9jYWwgaW1wbGVtZW50YXRpb24gbWF0dGVyLiBB IHNuaXAgZnJvbSBzZWN0aW9uIDEwIGJlbG93Ojx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNs YXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0i Ij5UaGUgZm9sbG93aW5nIGFzcGVjdHMgb2YgUy1CRkQgRWNobyBmdW5jdGlvbnMgYXJlIGxlZnQg YXM8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRp b24gZGV0YWlscyBhbmQgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQ6PHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7OyIgY2xhc3M9IiI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNz PSIiPjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgRm9ybWF0IG9mIHRoZSBTLUJGRCBFY2hvIHBhY2tl dCAoZS5nLiwgZGF0YSBiZXlvbmQgVURQIGhlYWRlcikuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNz PSIiPjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgUHJvY2VkdXJlcyBvbiB3aGVuIGFuZCBob3cgdG8g dXNlIHRoZSBTLUJGRCBFY2hvIGZ1bmN0aW9uLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJz cDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG9wZSB0aGlzIGNs YXJpZmllcy48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hZ2VuZHJhIDx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZu YnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0i Ij48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu IiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPnNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgR3JlZyBNaXJza3kgJmx0Ozxh IGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE9jdG9iZXIgMjQsIDIwMTggYXQgMjowOSBQTTxiciBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOiA8L2I+JnF1b3Q7WmFmYXIgQWxpICh6YWxpKSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnphbGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+emFsaUBjaXNjby5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNj OiA8L2I+c3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5TdWJqZWN0OiA8L2I+UmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeS0wMi50eHQ8dSBjbGFz cz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9 IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Im1fLTMwMjY3Njg2MTM2NDI2NjQ0NDdfX01haWxPcmlnaW5hbEJvZHkiIGNsYXNzPSIiPkhpIEFs aSwNCjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9hPjwvcD4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj50aGFuayB5b3UgZm9yIHlv dXIga2luZCBjb25zaWRlcmF0aW9uIG9mIG15IGNvbW1lbnRzLiBJJ3ZlIHJlYWQgdGhlIG5ldyB2 ZXJzaW9uIGFuZCBzZWN0aW9uIDMuMyBpbiBwYXJ0aWN1bGFyLiBQbGVhc2Uga2luZGx5IGNvbnNp ZGVyIG15IGNvbW1lbnRzOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjx1bCB0eXBlPSJkaXNjIiBjbGFzcz0iIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj5JIHJlY2FsbCB0aGF0IHRoZSBpZGVh IHRvIGNvbnN0cnVjdCBTUiB0dW5uZWwgdGhyb3VnaCB0aGUgbmV0d29yayB0byB0ZXJtaW5hdGUg YXQgdGhlIHNlbmRlciBkaXNjdXNzZWQgaW4gUkZDIDg0MDM7PHUgY2xhc3M9IiI+PC91Pjx1IGNs YXNzPSIiPjwvdT48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 IiI+aWYgdGhlIHRlc3QgcHJvYmUgd2l0aCB0aGUgbGFiZWwgc3RhY2sgYXMmbmJzcDt7QiwgQywg RCwgQywgQX0gaXMgdGhlIFMtQkZEIGNvbnRyb2wgcGFja2V0LCB0aGUgU0JGREluaXRpYXRvciB3 aWxsIG5vdCByZWNlaXZlIGEgc2luZ2xlIFMtQkZEIHBhY2tldC4gSW4gb3RoZXIgd29yZHMsIHRo ZSBwcm9wb3NlZCBhcHByb2FjaCB0byBjb250cm9sIHRoZSByZXR1cm4gcGF0aCB3aWxsIGJyZWFr DQogdGhlIFMtQkZEIGJlY2F1c2UgU0JGRFJlZmxlY3RvciBkb2VzIG5vdCByZWNlaXZlIHRoZSBT LUJGRCBwYWNrZXQgYXMgaXQgcGFzc2VzIHRocm91Z2ggdW50aWwgdGhlIHNwZWNpZmllZCBTUiB0 dW5uZWwgYmVlbiZuYnNwO2Nyb3NzZWQuJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+QW5v dGhlciBwcm9ibGVtIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBpcyB0aGF0IHRoZSBTLUJGRCBj b250cm9sIHBhY2tldCByZWNlaXZlZCBieSBTQkZESW5pdGlhdG9yIGhhcyB0aGUgZGVzdGluYXRp b24gVURQIHBvcnQgNzc4NCBhbmQgdGhlIHZhbHVlIG9mIFlvdXIgRGlzY3JpbWluYXRvciBpcyB0 aGUgb25lIGFkdmVydGlzZWQsIGV4cGxpY2l0bHkgb3IgaW1wbGljaXRseSwgYnkmbmJzcDsNCiBT QkZEUmVmbGVjdG9yLCBub3QmbmJzcDsgU0JGREluaXRpYXRvci48dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91Pjwvc3Bhbj48L2xpPjwvdWw+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+SW4gc3VtbWFyeSwgSSBjb25jbHVkZSB0aGF0IHRo ZSBhcHByb2FjaCBwcm9wb3NlZCBpbiBzZWN0aW9uIDMuMyBpcyBub3QgdGVjaG5pY2FsbHkgdmlh YmxlIGFuZCBjYW5ub3QgYWRkcmVzcyBteSBlYXJsaWVyIGNvbW1lbnRzLjx1IGNsYXNzPSIiPjwv dT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8 dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPlJlZ2FyZHMsPHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+R3JlZyZuYnNwOzx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPjx1 IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 IiI+T24gTW9uLCBPY3QgMjIsIDIwMTggYXQgOTo1MCBQTSBaYWZhciBBbGkgKHphbGkpICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnphbGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+PHNwYW4gY2xhc3M9IiI+emFsaUBjaXNjby5jb208L3NwYW4+PHNwYW4gY2xhc3M9IiI+ PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iIj4mZ3Q7IHdyb3RlOjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNjY2NjY2MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9IiI+SGkgR3JlZyBhbmQgdGhlIFdHLCA8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj4mbmJz cDs8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj5XZSBoYXZlIHVwZGF0ZSBkcmFmdC1hbGktc3ByaW5n LWJmZC1zci1wb2xpY3kgdG8gYWRkcmVzcyBjb21tZW50cyB3ZSByZWNlaXZlZCBvbiB0aGUgbGlz dCBvciBkdXJpbmcgV0cgc2Vzc2lvbiBwcmVzZW50YXRpb24uIFRoaXMgaW5jbHVkZXMgY29tbWVu dCBvbiBjb250cm9sbGluZyB0aGUgcmV0dXJuIHBhdGguDQo8dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i Ij4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj5DYW4geW91IHBsZWFzZSByZXZpZXcgdGhl IGNoYW5nZXMgYW5kIGFkdmlzZSBvZiB5b3VyIGNvbW1lbnRzPw0KPHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0K PGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiIgY2xhc3M9IiI+VGhhbmtzPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIi PjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiIgY2xhc3M9IiI+UmVnYXJkcyDigKYgWmFm YXINCjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPiZuYnNwOzx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPjxiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Gcm9tOg0KPC9z cGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJw dDsiIGNsYXNzPSIiPiZxdW90Ozwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0IiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4gY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPiZxdW90Ow0KICZs dDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iIj48L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+RGF0ZTogPC9iPk1vbmRheSwgT2N0b2JlciAyMiwgMjAxOCBhdCA2OjE5IFBNPGJyIGNsYXNz PSIiPg0KPGIgY2xhc3M9IiI+VG86IDwvYj4mcXVvdDtOYWdlbmRyYSBLdW1hciBOYWluYXIgKG5h aWt1bWFyKSZxdW90OyAmbHQ7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmFpa3VtYXJA Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiIGNsYXNzPSIiPm5haWt1bWFyQGNpc2NvLmNvbTwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9IiI+PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+Jmd0OywNCiAmcXVvdDtLZXRhbiBUYWxh dWxpa2FyIChrZXRhbnQpJnF1b3Q7ICZsdDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpr ZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiIGNsYXNzPSIiPmtldGFudEBjaXNjby5jb208 L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPiZndDssDQogJnF1b3Q7WmFmYXIg QWxpICh6YWxpKSZxdW90OyAmbHQ7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86emFsaUBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCIgY2xhc3M9IiI+emFsaUBjaXNjby5jb208L3NwYW4+PC9z cGFuPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPiZndDssDQogJnF1b3Q7Q2FybG9zIFBpZ25hdGFy byAoY3BpZ25hdGEpJnF1b3Q7ICZsdDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjcGln bmF0YUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCIgY2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28uY29t PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iIj48L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj4mZ3Q7LA0KICZxdW90O0NsYXJl bmNlIEZpbHNmaWxzIChjZmlsc2ZpbCkmcXVvdDsgJmx0Ozwvc3Bhbj48L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmNmaWxzZmlsQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFu IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0IiBjbGFzcz0iIj5jZmlsc2Zp bEBjaXNjby5jb208L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4g Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPiZndDssDQog JnF1b3Q7TmFnZW5kcmEgS3VtYXIgTmFpbmFyIChuYWlrdW1hcikmcXVvdDsgJmx0Ozwvc3Bhbj48 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5haWt1bWFyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0IiBj bGFzcz0iIj5uYWlrdW1hckBjaXNjby5jb208L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSIiPjwv c3Bhbj48L2E+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNs YXNzPSIiPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OiA8L2I+TmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3ktMDIu dHh0PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIi PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPjxh IG5hbWU9Im1fLTMwMjY3Njg2MTM2NDI2NjQ0NDdfbV8tNjU2MzIxNDE4OTEwODEyODIwMl9tXzMx Mjk0NTEyNTg1NTYxMSIgY2xhc3M9IiI+Jm5ic3A7PC9hPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hbGkt c3ByaW5nLWJmZC1zci1wb2xpY3ktMDIudHh0PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9IiI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOYWdl bmRyYSBLdW1hciBOYWluYXIgYW5kIHBvc3RlZCB0byB0aGU8dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj5JRVRGIHJlcG9zaXRvcnkuPHUgY2xhc3M9IiI+PC91 Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+TmFtZTo8c3BhbiBjbGFzcz0ibV8tMzAyNjc2 ODYxMzY0MjY2NDQ0N20tNjU2MzIxNDE4OTEwODEyODIwMm0zMTI5NDUxMjU4NTU2MTE5NTAxYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPmRyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeTx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPlJldmlzaW9uOjxzcGFuIGNsYXNzPSJtXy0z MDI2NzY4NjEzNjQyNjY0NDQ3bS02NTYzMjE0MTg5MTA4MTI4MjAybTMxMjk0NTEyNTg1NTYxMTk1 MDFhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+MDI8dSBjbGFz cz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj5UaXRsZTo8c3BhbiBjbGFz cz0ibV8tMzAyNjc2ODYxMzY0MjY2NDQ0N20tNjU2MzIxNDE4OTEwODEyODIwMm0zMTI5NDUxMjU4 NTU2MTE5NTAxYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPkJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgZm9yIFNlZ21lbnQgUm91dGluZyBQb2xpY2ll cyBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSIiPkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9Im1fLTMwMjY3Njg2MTM2 NDI2NjQ0NDdtLTY1NjMyMTQxODkxMDgxMjgyMDJtMzEyOTQ1MTI1ODU1NjExOTUwMWFwcGxlLXRh Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4yMDE4LTEwLTIyPHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+R3JvdXA6PHNwYW4g Y2xhc3M9Im1fLTMwMjY3Njg2MTM2NDI2NjQ0NDdtLTY1NjMyMTQxODkxMDgxMjgyMDJtMzEyOTQ1 MTI1ODU1NjExOTUwMWFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248dSBjbGFzcz0i Ij48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj5QYWdlczo8c3BhbiBjbGFzcz0i bV8tMzAyNjc2ODYxMzY0MjY2NDQ0N20tNjU2MzIxNDE4OTEwODEyODIwMm0zMTI5NDUxMjU4NTU2 MTE5NTAxYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjExPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9IiI+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYWxpLXNwcmluZy1iZmQtc3It cG9saWN5LTAyLnR4dCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbGktc3ByaW5nLWJmZC1z ci1wb2xpY3ktMDIudHh0PC9zcGFuPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4gY2xh c3M9IiI+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+U3Rh dHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxpLXNw cmluZy1iZmQtc3ItcG9saWN5LyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIGNsYXNz PSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsaS1zcHJpbmctYmZk LXNyLXBvbGljeS88L3NwYW4+PHNwYW4gY2xhc3M9IiI+PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0i Ij48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj5IdG1saXpl ZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3kt MDIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyPC9zcGFuPjxz cGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9IiI+PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWFsaS1zcHJpbmctYmZkLXNyLXBvbGljeSIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5PC9zcGFuPjxzcGFuIGNs YXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9IiI+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNz PSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1hbGktc3ByaW5nLWJmZC1zci1wb2xpY3kt MDIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5odHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYWxpLXNwcmluZy1iZmQtc3ItcG9saWN5LTAyPC9z cGFuPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9IiI+PHUgY2xhc3M9IiI+ PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91 Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+QWJzdHJhY3Q6PHUgY2xhc3M9IiI+PC91 Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IFNlZ21lbnQgUm91 dGluZyAoU1IpIGFsbG93cyBhIGhlYWRlbmQgbm9kZSB0byBzdGVlciBhIHBhY2tldCBmbG93PHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7 IGFsb25nIGFueSBwYXRoIHVzaW5nIGEgc2VnbWVudCBsaXN0IHdoaWNoIGlzIHJlZmVycmVkIHRv IGFzIGEgU1I8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj4m bmJzcDsmbmJzcDsgUG9saWN5LiZuYnNwOyZuYnNwO0ludGVybWVkaWF0ZSBwZXItZmxvdyBzdGF0 ZXMgYXJlIGVsaW1pbmF0ZWQgdGhhbmtzIHRvIHNvdXJjZTx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyByb3V0aW5nLiZuYnNwOyZuYnNw O1RoZSBoZWFkZXIgb2YgYSBwYWNrZXQgc3RlZXJlZCBpbiBhbiBTUiBQb2xpY3kgaXMgYXVnbWVu dGVkPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7 Jm5ic3A7IHdpdGggdGhlIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGgg dGhhdCBTUiBQb2xpY3kuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJG RCkgaXMgdXNlZCB0byBtb25pdG9yIGRpZmZlcmVudDx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBraW5kcyBvZiBwYXRocyBiZXR3ZWVu IG5vZGUuJm5ic3A7Jm5ic3A7QkZEIG1lY2hhbmlzbXMgY2FuIGJlIGFsc28gdXNlZCB0bzx1IGNs YXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBt b25pdG9yIHRoZSBhdmFpbGFiaWxpdHkgb2YgdGhlIHBhdGggaW5kaWNhdGVkIGJ5IGEgU1IgUG9s aWN5IGFuZCB0bzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIi PiZuYnNwOyZuYnNwOyBkZXRlY3QgYW55IGZhaWx1cmVzLiZuYnNwOyZuYnNwO1NlYW1sZXNzIEJG RCAoUy1CRkQpIGV4dGVuc2lvbnMgcHJvdmlkZSBhPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IHNpbXBsaWZpZWQgbWVjaGFuaXNtIHdo aWNoIGlzIHN1aXRhYmxlIGZvciBtb25pdG9yaW5nIG9mIHBhdGhzIHRoYXQ8dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgYXJlIHNldHVw IGR5bmFtaWNhbGx5IGFuZCBvbiBhIGxhcmdlIHNjYWxlLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyB0aGUgdXNlIG9mIFNlYW1sZXNzIEJGRCAoUy1CRkQpIG1lY2hhbmlzbSB0bzx1IGNsYXNzPSIi PjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBtb25pdG9y IHRoZSBTUiBQb2xpY2llcyB0aGF0IGFyZSB1c2VkIGZvciBUcmFmZmljIEVuZ2luZWVyaW5nIChU RSkgaW48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iIj4mbmJz cDsmbmJzcDsgU1IgZGVwbG95bWVudHMuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHUgY2xhc3M9IiI+ PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91 Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IiI+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjwvc3Bhbj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9 IiI+dG9vbHMuaWV0Zi4ub3JnPC9zcGFuPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48L2E+PHNwYW4g Y2xhc3M9IiI+Ljx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIi PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSIiPlRo ZSBJRVRGIFNlY3JldGFyaWF0PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9IiI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiBjbGFzcz0iIj5zcHJp bmdAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_3DD11B388B3E429B8ED7E64DCFCDE5B0ciscocom_-- From nobody Fri Oct 26 11:22:31 2018 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 100A8126CB6; Fri, 26 Oct 2018 11:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 BdvTH1tmecLd; Fri, 26 Oct 2018 11:22:20 -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 0757E130DDE; Fri, 26 Oct 2018 11:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29052; q=dns/txt; s=iport; t=1540578140; x=1541787740; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zaFXxHww3s59G2OztesmuDTTQtCNAHH9bpx4ObEpe30=; b=cj3zlk/Loiuz2gtxf7DV571BHbCPHqtYFsWqpBPJS7bN69FXP8KUgyTB 7yvVMo5bXiUcrPdz1b7v8BBXcb51/3CMCADRbzxs1pXPEK7dG/PYu8JXe qDGa1hMn3r6VEm6mBl/w91HZ7EQZPP8e2kEtUq7ALdduqGMrDZBouKucU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADqWtNb/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCoNriBiMGIFol0KBegsBARg?= =?us-ascii?q?BCgmEQAIXgwEhNA0NAQMBAQIBAQJtHAyFOwIEAQEhRAcLEAIBCDgHAwICAiU?= =?us-ascii?q?LFBECBA4FgyEBgR1kD6ZKgS6FO4ReBYtnF4FBP4ERJwwTgkyDGwEBghmCTDG?= =?us-ascii?q?CJgKIeIVOhiCKGQkCkH0YkEWCaJQDAhEUgSYdOIFVcBU7KgGCQYImF4hchT5?= =?us-ascii?q?vgSiJSQeBJwGBHgEB?= X-IronPort-AV: E=Sophos;i="5.54,428,1534809600"; d="scan'208,217";a="475259062" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 18:22:18 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9QIMIro016441 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 18:22:18 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 13:22:17 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Fri, 26 Oct 2018 13:22:17 -0500 From: "Darren Dukes (ddukes)" To: "Joel M. Halpern" CC: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUampMSmaiE2sUnkOZwbcZBqOzaaUyIfaAgAAOrAA= Date: Fri, 26 Oct 2018 18:22:17 +0000 Message-ID: References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> 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: [161.44.213.34] Content-Type: multipart/alternative; boundary="_000_BAB7BDF926994B838E88E3BE36606314ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] SRv6 - SRH in encaps or base header - point 2 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 18:22:23 -0000 --_000_BAB7BDF926994B838E88E3BE36606314ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 K3NwcmluZw0KDQpIaSBKb2VsLCB5b3XigJl2ZSBkZXNjcmliZWQgc2VjdGlvbnMgdGl0bGVkIOKA nEludHJhIFNSIERvbWFpbiBQYWNrZXTigJ0sIOKAnFRyYW5zaXQgUGFja2V0IFRocm91Z2ggU1Ig RG9tYWlu4oCdLCBhbmQgIlNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkgQ29ubmVjdGVk4oCd Lg0KDQpJ4oCZdmUgcGFyc2VkIHRoZW0gaW5saW5lIHRvIHRoZSBzZWN0aW9ucyBvZiB0aGUgZHJh ZnQgZGVmaW5pbmcgdGhlbSBhbmQgZ2l2ZW4gbW9yZSBjb250ZXh0IHdoZXJlIG5lZWRlZC4NCg0K T24gT2N0IDIyLCAyMDE4LCBhdCA4OjQ5IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFs cGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCg0KUmVwaHJhc2lu ZyB1c2luZyB0aGUgZXhhbXBsZSBmcm9tIDUuMi4gIEFzc3VtaW5nIHRoYXQgOCBhbmQgOSBhcmUg U1IgSG9zdHMgKG5vdCBqdXN0IGhvc3RzIHdpdGhpbiB0aGUgZG9tYWluLCB0aGV5IGFyZSBjYXBh YmxlIG9mIGFuZCBleHBlY3QgdG8gZGVhbCB3aXRoIFNSSHMsIGFuZCB0aGVyZWZvcmUgaGF2ZSBs b2NhbCBTSURzLCAuLi4pDQoNCkZvciB0cmFmZmljIGZyb20gOCB0byA5IHRoYXQgbmVlZHMgYW4g U1JILCB0aGUgU1JIIGdvZXMgaW4gdGhlIElQdjYgaGVhZGVyIHNlbnQgbXkgOCB0byA5LiAgV2hl biA5IHByb2Nlc3NlcyB0aGUgcGFja2V0LCBpdCBzZWVtcyB0aGF0IGl0IGlzIHRoZSBsYXN0IFNJ RCwgZmlndXJlcyBvdXQgdGhhdCB0aGVyZSBpcyBubyBlbmNhcHN1bGF0aW9uLCBhbmQgc2VuZCB0 aGUgVENQIC8gVURQIC8gUVVJQyBpbmZvcm1hdGlvbiB0byBpdHMgaW50ZXJuYWwgcHJvdG9jb2xz IHN0YWNrcy4NCg0KWWVzLCB0aGlzIGlzIFNlY3Rpb24gNS4zLjEg4oCcSW50cmEgU1IgRG9tYWlu IFBhY2tldOKAnS4NCg0KDQpGb3IgdHJhZmZpYyBmcm9tIDEgdG8gOSwgd2hlcmUgMyBhZGRzIGFu IFNSSCwgdGhhdCBTUkggc3RpbGwgcHJlc3VtYWJseSBlbmRzIGF0IDkuICA5IFJlY2VpdmVzIHRo ZSBJUCBwYWNrZXQuICBTZWVzIHRoYXQgaXQgaXMgYWRkcmVzc2VkIHRvIGl0c2VsZi4gIFNlZXMg dGhhdCB0aGUgU1JIIGlzIGZpbmlzaGVkLiBBbmQgdGhlbiBub3RpY2VzIHRoYXQgdGhlIG5leHQt aGVhZGVyIGlzIElQdjYuICBVbndyYXBzIHRoZSBoZWFkZXIsIGNoZWNrcyB0aGF0IHRoZSBpbm5l ciBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGFsc28gaXRzZWxmLCBhbmQgcGFzc2VzIHRoZSBtYXRl cmlhbCBjYXJyaWVkIGJ5IHRoZSBpbm5lciBoZWFkZXIgdXAgdG8gdGhlIGFwcHJvcHJpYXRlIHN0 YWNrLg0KDQpTbyBub2RlIDEgc2VuZHMgYSBwYWNrZXQgdG8gbm9kZSA5IChBMSxBOSkNCklGIHRo ZXJlIGlzIHNvbWUgc3RlZXJpbmcgaW50byBhbiBTUiBQb2xpY3kgYXQgbm9kZSAzIHRvIHJlYWNo IG5vZGUgOSwgdGhpcyBpcyBpZGVudGljYWwgdG8gc2VjdGlvbiA1LjMuMiDigJxUcmFuc2l0IHBh Y2tldCB0aHJvdWdoIFNSIGRvbWFpbuKAnSwgZXhjZXB0IGZvciBkZXN0aW5hdGlvbiBvZiBBOSB2 aWEgbm9kZSA5IGluc3RlYWQgb2YgQTIgdmlhIG5vZGUgNC4NCg0KDQpUaHVzLCA5IG5lZWRzIHRv IGJlIGFibGUgdG8gY2hlY2sgZm9yIGJvdGggY2FzZXMuICBXZSBhdCBsZWFzdCBuZWVkIHRvIHRl bGwgaW1wbGVtZW50b3JzIHRoYXQuDQpXZWxsLCA5IG5lZWRzIGEgU0lEIFM5IGFuZCBBZGRyZXNz IEE5LiAgVGhhdCBpcyBzaG93biBpbiBTZWN0aW9uIDUuMSBTSUQgYW5kIGFkZHJlc3MgcmVwcmVz ZW50YXRpb24uDQoNCg0KVGhlcmUgaXMgYSBmdXJ0aGVyIGNvbXBsaWNhdGlvbi4gIDkgc2VlbXMg dG8gbmVlZCB0byBoYXZlIGFuIGFkZHJlc3MgdGhhdCBpcyBhIHZhbGlkIFNJRCwgc28gaXQgY2Fu IGJlIHRoZSBsYXN0IGVudHJ5IGluIHRoZSBTUkggZnJvbSA4IHRvIDkuDQpBcyBkZXNjcmliZWQg aW4gdGhlIGRyYWZ0LCBTZWN0aW9uIDUuMSBhIG5vZGUgayBoYXMgYW4gYWRkcmVzcyBBayBhbmQg U0lEIFNrLiAgU28gbm9kZSA5IGhhcyBhIHZhbGlkIFNJRC4NCkZvciB0cmFmZmljIGZyb20gOCB0 byA5LCBBOSBpcyB1c2VkIGFzIHRoZSBkZXN0aW5hdGlvbiBhcyBzaG93biBpbiBzZWN0aW9uIDUu My4xLCA1LjQgYW5kIDUuNS4NCg0KSG93ZXZlciwgaWYgMSB3ZXJlIHRvIHNlbmQgdGhlIHBhY2tl dCB0byB0aGF0IFNJRCBmb3IgOSwgcm91dGVyIDMgd291bGQgYmUgcmVxdWlyZWQgYnkgdGhlIHJ1 bGVzIHdlIGRpc2N1c3NlZCBpbiB0aGUgb3RoZXIgdGhyZWFkIHRvIGRpc2NhcmQgdGhlIHBhY2tl dCBhcyBpdCBpcyBuZWl0aGVyIHRvIHByZWZpeCBub3IgY29udGFpbnMgYW4gSEFNQy4NCkFuZCBz b21laG93LCA4IGFuZCAxIG5lZWQgdG8gZWFjaCBwaWNrIHRoZSByaWdodCBhZGRyZXNzIHRvIHVz ZSBmb3IgOS4gKHNwbGl0IEROUyBtYXliZT8pICBBbmQgMyBuZWVkcyB0byBiZSBhYmxlIHRvIGRl cml2ZSB0ZWggU0lELWZvcm1uIGFkZHJlc3MgZm9yIDkgZnJvbSB0aGUgbm9uLVNJRCBmb3JtIG9m IHRoZSBhZGRyZXNzIHNvIHRoYXQgaXQgKDMpIGNhbiBidWlsZCBhIHByb3BlciBTUkggdG8gZ2V0 IHRoZSBwYWNrZXQgdG8gOS4NClRoaXMgaXMgaW5jb3JyZWN0Lg0KDQpTZWUgU2VjdGlvbiA2LjIu MSDigJxTUiBTb3VyY2UgTm9kZXMgTm90IERpcmVjdGx5IENvbm5lY3RlZOKAnSBJIHdpbGwgZXhw YW5kIG9uIHRoZSBleGFtcGxlIGZyb20gdGhhdCBzZWN0aW9uLg0KDQpOb2RlIDIwIHNlbmRzIGEg cGFja2V0IHRvIEE5IHdpdGggU1IgUG9saWN5IDxINz4gYW5kIGFuIEhNQUMgcHJvdmlkZWQgdG8g bm9kZSAyMCBieSBzb21lIHlldCB0byBiZSBkZWZpbmVkIG1ldGhvZC4gIFJlc3VsdGluZyBpbiBw YWNrZXQgc2VudCBmcm9tIG5vZGUgMjANCiBQOiAoQTIwLEg3KShBOTtTTD0xKShwYXlsb2FkKQ0K DQpSZWNhbGwgSGsgaXMgYSBTSUQgYXQgbm9kZSBrIHJlcXVpcmluZyBITUFDIHZlcmlmaWNhdGlv biwgYW5kIGl0IGlzIGNvdmVyZWQgYnkgUHJlZml4LUguDQoNClByZWZpeC1IIGlzIF9ub3RfIHN1 YmplY3QgdG8gaW5ncmVzcyBmaWx0ZXJpbmcgYXQgbm9kZSAzLg0KDQpUaGVyZWZvcmUgdGhlIHBh Y2tldCBQIGRlc3RpbmVkIHRvIEg3IGlzIG5vdCBzdWJqZWN0IHRvIGluZ3Jlc3MgZmlsdGVyaW5n IGF0IG5vZGUgMy4NCg0KUCBpcyBmb3J3YXJkZWQgdG8gbm9kZSA3LCB3aGVyZSBINyBpcyBwcm9j ZXNzZWQgYW5kIHRoZSBITUFDIHZlcmlmaWVkLg0KDQpJZiB0aGUgSE1BQyBjYW4gbm90IGJlIHZl cmlmaWVkIHRoZSBwYWNrZXQgaXMgZHJvcHBlZCwgZWxzZSBpdCBpcyBmb3J3YXJkZWQgdG8gdGhl IG5leHQgc2VnbWVudCBhbmQgZGVzdGluYXRpb24sIEE5Lg0KDQpEYXJyZW4NCg0KDQoNCllvdXJz LA0KSm9lbA0KDQpPbiAxMC8yMi8xOCA4OjA0IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykgd3Jv dGU6DQppbmxpbmUuDQpPbiBPY3QgMjIsIDIwMTgsIGF0IDc6MjEgUE0sIEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3Rl Og0KLi4NCjIpIE5vdyBsZXQgdXMgbG9vayBhdCBwYWNrZXRzIGFycml2aW5nIGF0IGFuZCBhY3R1 YWxseSBkZXN0aW5lZCBmb3IgYW4gU1IgSG9zdCBpbiB0aGUgU1IgRG9tYWluIHdoZXJlIHRoYXQg cGFja2V0IGhhcyBhbiBTUkguICBJZiB0aGUgcGFja2V0IGlzIGNvbWluZyBmcm9tIGFub3RoZXIg U1IgSG9zdCwgdGhlIFNSSCB3aWxsIGJlIGluIHRoZSBiYXNlIGhlYWRlciwgYW5kIHRoZSBob3N0 IGNhbiBzaW1wbHkgY2hlY2sgaXQgZm9yIGFueSB2aW9sYXRpb25zLCBhbmQgY29udGludWUuICBC dXQsIGlmIHRoZSBwYWNrZXQgY2FtZSBmcm9tIG91dHNpZGUgdGhlIGRvbWFpbiwgdGhlbiBpdCB3 aWxsIGhhdmUgYW4gZW5jYXBzdWxhdGluZyBTUnY2IGhlYWRlci4gIFNvIHRoZSBob3N0IGhhcyB0 byBkZXRlY3QgdGhpcyBjYXNlLCBjaGVjayBhbmQgdGhlbiBwZWFsIG9mZiB0aGUgZW5jYXBzdWxh dGluZyBoZWFkZXIsIGFuZCB0aGVuIHByb2Nlc3MgdGhlIHJlY2VpdmVkIHBhY2tldC4gWWVzLCBp dCBjYW4gZG8gc28uICBCdXQgbm90aGluZyBpbiB0ZWggZG9jdW1lbnQgdGVsbHMgaW1wbGVtZW50 b3JzIHRoZXkgaGF2ZSB0byBkZWFsIHdpdGggYm90aCBjYXNlcy4NCg0KQ2FuIHlvdSBiZSBtb3Jl IHByZWNpc2UgaGVyZS4gIFBlcmhhcHMgdXNlIHRoZSBleGFtcGxlIGZyb20gc2VjdGlvbiA1LjIg b3IgNi4yLjE/DQouLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3Ry YXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0K --_000_BAB7BDF926994B838E88E3BE36606314ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <850CBA0D00A2D548988CD7D4B288427A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCiYjNDM7c3ByaW5nPGJyIGNsYXNzPSIiPg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01U OyIgY2xhc3M9IiI+SGkgSm9lbCwgeW914oCZdmUgZGVzY3JpYmVkIHNlY3Rpb25zIHRpdGxlZCDi gJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLCDigJxUcmFuc2l0IFBhY2tldCBUaHJvdWdoIFNS IERvbWFpbuKAnSwgYW5kICZxdW90O1NSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkgQ29ubmVj dGVk4oCdLjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0i Q291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyIgY2xhc3M9IiI+SeKAmXZlIHBhcnNlZCB0 aGVtIGlubGluZSB0byB0aGUgc2VjdGlvbnMgb2YgdGhlIGRyYWZ0IGRlZmluaW5nIHRoZW0gYW5k IGdpdmVuIG1vcmUgY29udGV4dCB3aGVyZSBuZWVkZWQuPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxm b250IGNvbG9yPSIjNTg1NmQ2IiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9mb250Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBD b3VyaWVyTmV3UFNNVDsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KT24gT2N0IDIyLCAyMDE4LCBhdCA4OjQ5IFBNLCBKb2Vs IE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiBjbGFz cz0iIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGZvbnQgY29sb3I9IiMwMGFmY2QiIGZhY2U9IkNvdXJpZXJOZXdQU01UIiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAxNzUsIDIwNSk7IiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9mb250Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KUmVwaHJhc2luZyB1 c2luZyB0aGUgZXhhbXBsZSBmcm9tIDUuMi4gJm5ic3A7QXNzdW1pbmcgdGhhdCA4IGFuZCA5IGFy ZSBTUiBIb3N0cyAobm90IGp1c3QgaG9zdHMgd2l0aGluIHRoZSBkb21haW4sIHRoZXkgYXJlIGNh cGFibGUgb2YgYW5kIGV4cGVjdCB0byBkZWFsIHdpdGggU1JIcywgYW5kIHRoZXJlZm9yZSBoYXZl IGxvY2FsIFNJRHMsIC4uLik8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBz dHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8Zm9udCBjb2xvcj0i IzAwYWZjZCIgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDE3NSwgMjA1KTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bh bj48L2ZvbnQ+Rm9yIHRyYWZmaWMgZnJvbSA4IHRvIDkgdGhhdCBuZWVkcyBhbiBTUkgsIHRoZSBT UkggZ29lcyBpbiB0aGUgSVB2NiBoZWFkZXIgc2VudCBteSA4IHRvIDkuICZuYnNwO1doZW4gOSBw cm9jZXNzZXMgdGhlIHBhY2tldCwgaXQgc2VlbXMgdGhhdCBpdCBpcyB0aGUgbGFzdCBTSUQsIGZp Z3VyZXMgb3V0IHRoYXQgdGhlcmUgaXMgbm8gZW5jYXBzdWxhdGlvbiwgYW5kIHNlbmQgdGhlIFRD UCAvIFVEUCAvIFFVSUMgaW5mb3JtYXRpb24gdG8NCiBpdHMgaW50ZXJuYWwgcHJvdG9jb2xzIHN0 YWNrcy48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxmb250IGNvbG9yPSIj NTg1NmQ2IiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9m b250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IiBjbGFzcz0iIj5Z ZXMsIHRoaXMgaXMgU2VjdGlvbiA1LjMuMSDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLjwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0iQ291cmllck5l d1BTTVQiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxmb250IGNvbG9y PSIjMDBhZmNkIiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMTc1LCAyMDUpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9z cGFuPjwvZm9udD5Gb3IgdHJhZmZpYyBmcm9tIDEgdG8gOSwgd2hlcmUgMyBhZGRzIGFuIFNSSCwg dGhhdCBTUkggc3RpbGwgcHJlc3VtYWJseSBlbmRzIGF0IDkuICZuYnNwOzkgUmVjZWl2ZXMgdGhl IElQIHBhY2tldC4gJm5ic3A7U2VlcyB0aGF0IGl0IGlzIGFkZHJlc3NlZCB0byBpdHNlbGYuICZu YnNwO1NlZXMgdGhhdCB0aGUgU1JIIGlzIGZpbmlzaGVkLiBBbmQgdGhlbiBub3RpY2VzIHRoYXQg dGhlIG5leHQtaGVhZGVyIGlzIElQdjYuICZuYnNwO1Vud3JhcHMgdGhlIGhlYWRlciwNCiBjaGVj a3MgdGhhdCB0aGUgaW5uZXIgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhbHNvIGl0c2VsZiwgYW5k IHBhc3NlcyB0aGUgbWF0ZXJpYWwgY2FycmllZCBieSB0aGUgaW5uZXIgaGVhZGVyIHVwIHRvIHRo ZSBhcHByb3ByaWF0ZSBzdGFjay48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjxmb250IGNvbG9yPSIjNTg1NmQ2IiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BT TVQ7IiBjbGFzcz0iIj5TbyBub2RlIDEgc2VuZHMgYSBwYWNrZXQgdG8gbm9kZSA5IChBMSxBOSk8 L3NwYW4+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3Vy aWVyTmV3UFNNVDsiIGNsYXNzPSIiPklGIHRoZXJlIGlzIHNvbWUgc3RlZXJpbmcgaW50byBhbiBT UiBQb2xpY3kgYXQgbm9kZSAzIHRvIHJlYWNoIG5vZGUgOSwgdGhpcyBpcyBpZGVudGljYWwgdG8g c2VjdGlvbiA1LjMuMiDigJxUcmFuc2l0IHBhY2tldCB0aHJvdWdoIFNSIGRvbWFpbuKAnSwgZXhj ZXB0IGZvciBkZXN0aW5hdGlvbiBvZiBBOSB2aWEgbm9kZSA5IGluc3RlYWQgb2YgQTIgdmlhIG5v ZGUNCiA0Ljwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0i Q291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxm b250IGNvbG9yPSIjMDBhZmNkIiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMTc1LCAyMDUpOyIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9zcGFuPjwvZm9udD5UaHVzLCA5IG5lZWRzIHRvIGJlIGFibGUgdG8gY2hlY2sgZm9y IGJvdGggY2FzZXMuICZuYnNwO1dlIGF0IGxlYXN0IG5lZWQgdG8gdGVsbCBpbXBsZW1lbnRvcnMg dGhhdC48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IiBjbGFzcz0iIj5XZWxsLCA5IG5lZWRzIGEgU0lE IFM5IGFuZCBBZGRyZXNzIEE5LiAmbmJzcDtUaGF0IGlzIHNob3duIGluIFNlY3Rpb24gNS4xIFNJ RCBhbmQgYWRkcmVzcyByZXByZXNlbnRhdGlvbi48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGZvbnQg Y29sb3I9IiM1ODU2ZDYiIGZhY2U9IkNvdXJpZXJOZXdQU01UIiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2ZvbnQ+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp ZXJOZXdQU01UOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8Zm9udCBjb2xvcj0iIzAwYWZjZCIgZmFjZT0iQ291cmllck5l d1BTTVQiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDE3NSwgMjA1 KTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+VGhlcmUgaXMgYSBmdXJ0 aGVyIGNvbXBsaWNhdGlvbi4gJm5ic3A7OSBzZWVtcyB0byBuZWVkIHRvIGhhdmUgYW4gYWRkcmVz cyB0aGF0IGlzIGEgdmFsaWQgU0lELCBzbyBpdCBjYW4gYmUgdGhlIGxhc3QgZW50cnkgaW4gdGhl IFNSSCBmcm9tIDggdG8gOS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IiBjbGFzcz0iIj5BcyBkZXNj cmliZWQgaW4gdGhlIGRyYWZ0LCBTZWN0aW9uIDUuMSBhIG5vZGUgayBoYXMgYW4gYWRkcmVzcyBB ayBhbmQgU0lEIFNrLiAmbmJzcDtTbyBub2RlIDkgaGFzIGEgdmFsaWQgU0lELjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyIgY2xh c3M9IiI+Rm9yIHRyYWZmaWMgZnJvbSA4IHRvIDksIEE5IGlzIHVzZWQgYXMgdGhlIGRlc3RpbmF0 aW9uIGFzIHNob3duIGluIHNlY3Rpb24gNS4zLjEsIDUuNCBhbmQgNS41Ljwvc3Bhbj48YnIgY2xh c3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250 LWZhbWlseTogQ291cmllck5ld1BTTVQ7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IiBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCkhvd2V2ZXIsIGlmIDEgd2VyZSB0byBz ZW5kIHRoZSBwYWNrZXQgdG8gdGhhdCBTSUQgZm9yIDksIHJvdXRlciAzIHdvdWxkIGJlIHJlcXVp cmVkIGJ5IHRoZSBydWxlcyB3ZSBkaXNjdXNzZWQgaW4gdGhlIG90aGVyIHRocmVhZCB0byBkaXNj YXJkIHRoZSBwYWNrZXQgYXMgaXQgaXMgbmVpdGhlciB0byBwcmVmaXggbm9yIGNvbnRhaW5zIGFu IEhBTUMuPGJyIGNsYXNzPSIiPg0KQW5kIHNvbWVob3csIDggYW5kIDEgbmVlZCB0byBlYWNoIHBp Y2sgdGhlIHJpZ2h0IGFkZHJlc3MgdG8gdXNlIGZvciA5LiAoc3BsaXQgRE5TIG1heWJlPykgJm5i c3A7QW5kIDMgbmVlZHMgdG8gYmUgYWJsZSB0byBkZXJpdmUgdGVoIFNJRC1mb3JtbiBhZGRyZXNz IGZvciA5IGZyb20gdGhlIG5vbi1TSUQgZm9ybSBvZiB0aGUgYWRkcmVzcyBzbyB0aGF0IGl0ICgz KSBjYW4gYnVpbGQgYSBwcm9wZXIgU1JIIHRvIGdldCB0aGUgcGFja2V0IHRvIDkuPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENv dXJpZXJOZXdQU01UOyIgY2xhc3M9IiI+VGhpcyBpcyBpbmNvcnJlY3QuPC9zcGFuPjxiciBjbGFz cz0iIj4NCjxmb250IGNvbG9yPSIjNTg1NmQ2IiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmll ck5ld1BTTVQ7IiBjbGFzcz0iIj5TZWUgU2VjdGlvbiA2LjIuMSDigJxTUiBTb3VyY2UgTm9kZXMg Tm90IERpcmVjdGx5IENvbm5lY3RlZOKAnSBJIHdpbGwgZXhwYW5kIG9uIHRoZSBleGFtcGxlIGZy b20gdGhhdCBzZWN0aW9uLjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZk NiIgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyIgY2xhc3M9IiI+Tm9kZSAy MCBzZW5kcyBhIHBhY2tldCB0byBBOSB3aXRoIFNSIFBvbGljeSAmbHQ7SDcmZ3Q7IGFuZCBhbiBI TUFDIHByb3ZpZGVkIHRvIG5vZGUgMjAgYnkgc29tZSB5ZXQgdG8gYmUgZGVmaW5lZCBtZXRob2Qu ICZuYnNwO1Jlc3VsdGluZyBpbiBwYWNrZXQgc2VudCBmcm9tIG5vZGUgMjA8L3NwYW4+PGJyIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsiIGNsYXNz PSIiPiZuYnNwO1A6IChBMjAsSDcpKEE5O1NMPTEpKHBheWxvYWQpPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxmb250IGNvbG9yPSIjNTg1NmQ2IiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5l d1BTTVQ7IiBjbGFzcz0iIj5SZWNhbGwgSGsgaXMgYSBTSUQgYXQgbm9kZSBrIHJlcXVpcmluZyBI TUFDIHZlcmlmaWNhdGlvbiwgYW5kIGl0IGlzIGNvdmVyZWQgYnkgUHJlZml4LUguPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxmb250IGNvbG9yPSIjNTg1NmQ2IiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog Q291cmllck5ld1BTTVQ7IiBjbGFzcz0iIj5QcmVmaXgtSCBpcyBfbm90XyBzdWJqZWN0IHRvIGlu Z3Jlc3MgZmlsdGVyaW5nIGF0IG5vZGUgMy48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGZvbnQgY29s b3I9IiM1ODU2ZDYiIGZhY2U9IkNvdXJpZXJOZXdQU01UIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsiIGNsYXNz PSIiPlRoZXJlZm9yZSB0aGUgcGFja2V0IFAgZGVzdGluZWQgdG8gSDcgaXMgbm90IHN1YmplY3Qg dG8gaW5ncmVzcyBmaWx0ZXJpbmcgYXQgbm9kZSAzLjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8Zm9u dCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyIg Y2xhc3M9IiI+UCBpcyBmb3J3YXJkZWQgdG8gbm9kZSA3LCB3aGVyZSBINyBpcyBwcm9jZXNzZWQg YW5kIHRoZSBITUFDIHZlcmlmaWVkLjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0i IzU4NTZkNiIgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv Zm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyIgY2xhc3M9IiI+ SWYgdGhlIEhNQUMgY2FuIG5vdCBiZSB2ZXJpZmllZCB0aGUgcGFja2V0IGlzIGRyb3BwZWQsIGVs c2UgaXQgaXMgZm9yd2FyZGVkIHRvIHRoZSBuZXh0IHNlZ21lbnQgYW5kIGRlc3RpbmF0aW9uLCBB OS48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGZvbnQgY29sb3I9IiM1ODU2ZDYiIGZhY2U9IkNvdXJp ZXJOZXdQU01UIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsiIGNsYXNzPSIiPkRhcnJlbjwvc3Bhbj48YnIgY2xh c3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZm9udD4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxmb250IGNv bG9yPSIjMDBhZmNkIiBmYWNlPSJDb3VyaWVyTmV3UFNNVCIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMTc1LCAyMDUpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9zcGFuPjwvZm9udD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWls eTogQ291cmllck5ld1BTTVQ7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCllvdXJzLDxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCkpvZWw8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9u dC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8Zm9udCBjb2xvcj0iIzAwYWZjZCIg ZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDE3NSwgMjA1KTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQ U01UOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQpPbiAxMC8yMi8xOCA4OjA0IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9j a3F1b3RlPg0KaW5saW5lLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPk9uIE9jdCAyMiwgMjAxOCwgYXQgNzoyMSBQTSwgSm9lbCBNLiBIYWxwZXJuICZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgY2xhc3M9IiI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCi4uPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQoyKSBOb3cg bGV0IHVzIGxvb2sgYXQgcGFja2V0cyBhcnJpdmluZyBhdCBhbmQgYWN0dWFsbHkgZGVzdGluZWQg Zm9yIGFuIFNSIEhvc3QgaW4gdGhlIFNSIERvbWFpbiB3aGVyZSB0aGF0IHBhY2tldCBoYXMgYW4g U1JILiAmbmJzcDtJZiB0aGUgcGFja2V0IGlzIGNvbWluZyBmcm9tIGFub3RoZXIgU1IgSG9zdCwg dGhlIFNSSCB3aWxsIGJlIGluIHRoZSBiYXNlIGhlYWRlciwgYW5kIHRoZSBob3N0IGNhbiBzaW1w bHkgY2hlY2sgaXQgZm9yIGFueSB2aW9sYXRpb25zLA0KIGFuZCBjb250aW51ZS4gJm5ic3A7QnV0 LCBpZiB0aGUgcGFja2V0IGNhbWUgZnJvbSBvdXRzaWRlIHRoZSBkb21haW4sIHRoZW4gaXQgd2ls bCBoYXZlIGFuIGVuY2Fwc3VsYXRpbmcgU1J2NiBoZWFkZXIuICZuYnNwO1NvIHRoZSBob3N0IGhh cyB0byBkZXRlY3QgdGhpcyBjYXNlLCBjaGVjayBhbmQgdGhlbiBwZWFsIG9mZiB0aGUgZW5jYXBz dWxhdGluZyBoZWFkZXIsIGFuZCB0aGVuIHByb2Nlc3MgdGhlIHJlY2VpdmVkIHBhY2tldC4gWWVz LCBpdCBjYW4gZG8gc28uDQogJm5ic3A7QnV0IG5vdGhpbmcgaW4gdGVoIGRvY3VtZW50IHRlbGxz IGltcGxlbWVudG9ycyB0aGV5IGhhdmUgdG8gZGVhbCB3aXRoIGJvdGggY2FzZXMuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KQ2FuIHlvdSBiZSBtb3JlIHByZWNp c2UgaGVyZS4gJm5ic3A7UGVyaGFwcyB1c2UgdGhlIGV4YW1wbGUgZnJvbSBzZWN0aW9uIDUuMiBv ciA2LjIuMT88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQouLjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGZvbnQgY29sb3I9IiM1ODU2ZDYiIGZhY2U9IkNvdXJpZXJO ZXdQU01UIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsiIGNsYXNzPSIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxiciBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IiBjbGFz cz0iIj5JRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIGNsYXNzPSIiIHN0eWxlPSJmb250 LWZhbWlseTogQ291cmllck5ld1BTTVQ7Ij5pcHY2QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiPkFkbWluaXN0cmF0aXZlIFJlcXVl c3RzOiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYiIGNsYXNzPSIiIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BAB7BDF926994B838E88E3BE36606314ciscocom_-- From nobody Fri Oct 26 11:23:09 2018 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 02E9B130E98; Fri, 26 Oct 2018 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 8s17PhB4aRIO; Fri, 26 Oct 2018 11:22:47 -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 F3DE8130E8E; Fri, 26 Oct 2018 11:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27180; q=dns/txt; s=iport; t=1540578167; x=1541787767; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lsF7n/wvvQ7Fw+9NQRNcLuyNLQAxuPX1LWwaXq+9714=; b=ICTvVUrtSfJeSoQ27lLzPhhskI/zjEo570DWhyBmTwDhC/Dd5Ih/yW9y u1ton/KQwQIPdlqzMvelFUxlu0EmKhZpv2a9zy4oJXGDua7MBXkuW2Ofv lt3iPF5sK6i5nEzmdg8ug2V1QjX5BOyqdJ72sc6YPPxMslrmfQanBR6Sj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADqWtNb/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8oCoNriBiMGIFol0KBegsBARg?= =?us-ascii?q?BCgmEQAIXgwEhNA0NAQMBAQIBAQJtHAyFOwIEAQEhSwsQAgEIPwMCAgIlCxQ?= =?us-ascii?q?RAgQOBYMhAYEdZA+mSoEuhTuEXgWLZxeBQT+BEAEnDBOCTIMbAQGEZTGCJgK?= =?us-ascii?q?IVCQthSGQOQkCkH0YgVKEd4MbhmGWawIRFIEmHTiBVXAVOyoBgkGCIQUXiFy?= =?us-ascii?q?FPm+BKIp3AYEeAQE?= X-IronPort-AV: E=Sophos;i="5.54,428,1534809600"; d="scan'208,217";a="191694025" 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; 26 Oct 2018 18:22:45 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9QIMjPw016951 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 18:22:45 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 13:22:45 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Fri, 26 Oct 2018 13:22:45 -0500 From: "Darren Dukes (ddukes)" To: "Joel M. Halpern" CC: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" Thread-Topic: SRv6 revision: edge behavior minor description issue Thread-Index: AQHUalr1KASsPg78Tka4D48iVsqN/aUsQdOAgAAB7oCAAAoUgIAAAtyAgAXV3oCAAApTAA== Date: Fri, 26 Oct 2018 18:22:45 +0000 Message-ID: <2847719C-B915-4872-83E0-A64A8CBF3AD8@cisco.com> References: <18dc95a7-7505-fe05-a44c-957823f9c5e9@joelhalpern.com> <711F5B74-B389-41A6-990A-0C4671A6059D@cisco.com> <5e2bdc8b-84ba-2001-2ed5-5eeafa1c66cc@joelhalpern.com> <187ED21C-B385-429D-8F41-7DEDB4DE97FE@cisco.com> <6a880982-b2cb-c157-6ce1-9c431337e327@joelhalpern.com> <8FE6EAA8-7A2A-4B1B-95DA-49916D062220@cisco.com> In-Reply-To: <8FE6EAA8-7A2A-4B1B-95DA-49916D062220@cisco.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: [161.44.213.34] Content-Type: multipart/alternative; boundary="_000_2847719CB915487283E0A64A8CBF3AD8ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] SRv6 revision: edge behavior minor description issue X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 18:22:57 -0000 --_000_2847719CB915487283E0A64A8CBF3AD8ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 K3NwcmluZw0KDQpIaSBKb2VsLCBBY2sgb24gZm9yd2FyZCByZWZlcmVuY2UgaW4gNi4yLCBJ4oCZ bGwgdXNlIHRoZSB0ZXh0IEkgc3VnZ2VzdGVkLg0KDQpIb3dldmVyIFByZWZpeC1IIGlzIGFuIGV4 YW1wbGUgZm9yIHRoZSBmb2xsb3dpbmcNCg0KPHF1b3RlPg0KICAgU1IgRG9tYWluIGluZ3Jlc3Mg cm91dGVycyBwZXJtaXQgdHJhZmZpYyBkZXN0aW5lZCB0byBzZWxlY3QgU0lEcyB3aXRoDQogICBz ZWdtZW50IGxpc3RzLg0KPC9xdW90ZT4NCg0KICAgbG9jYWwgcG9saWN5IHJlcXVpcmluZyBITUFD IFRMViBwcm9jZXNzaW5nIGZvciB0aG9zZSBzZWxlY3QgU0lEcywNCiAgIGkuZS4gdGhvc2UgU0lE cyBwcm92aWRlIGEgZ2F0ZXdheSB0byB0aGUgU1IgRG9tYWluIGZvciBhIHNldCBvZg0KDQoNClBy ZWZpeC1IIGlzIGlzIGEgdXNlZnVsIGlsbHVzdHJhdGlvbiwgYnV0IGl0IGlzIG9ubHkgb25lIHdh eSBhbiBhZG1pbmlzdHJhdG9yIG1heSBjaG9vc2UgdG8gcGVybWl0IHBhY2tldHMgZGVzdGluZWQg dG8gU0lEcyByZXF1aXJpbmcgSE1BQyBUTFYgcHJvY2Vzc2luZyB0byBlbnRlciB0aGVpciBkb21h aW4uDQoNCkRlcGVuZGluZyBvbiB0aGUgZGVwbG95bWVudCBzaGUgbWF5IGRlY2lkZSB0byBwZXJt aXQgc3BlY2lmaWMgc291cmNlIGFkZHJlc3MgdG8gdXNlIHNwZWNpZmljIFNJRHMgcmVxdWlyaW5n IEhNQUMgcHJvY2Vzc2luZyBvbiBzcGVjaWZpYyBpbnRlcmZhY2VzIG9ubHkuDQpJbiB0aGlzIGNh c2UgdGhlIGZhY3QgdGhhdCBhbGwgdGhvc2UgU0lEcyBhcmUgYWxsb2NhdGVkIHdpdGhpbiBhIFBy ZWZpeC1IIGlzIG5vdCByZWxldmFudCwgbm9yIHdvdWxkIHNoZSBwZXJtaXQgcGFja2V0cyBkZXN0 aW5lZCB0byBwcmVmaXgtSCBhdCBhbGwgaW5ncmVzcyBub2Rlcy4NCg0KRGFycmVuDQoNCg0KT24g T2N0IDIyLCAyMDE4LCBhdCA4OjM5IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVy bi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCg0KSSBhbSBub3Qgc3Vy ZSBJIGFtIHB1dHRpbmcgdGhlIGludGVuZGVkIHBpZWNlcyB0b2dldGhlciByaWdodC4NCg0KQSBw YWNrZXQgYXJyaXZlcyBhdCBhIGRvbWFpbiBlZGdlIHRoYXQgc3VwcG9ydHMgU1J2Ni4gIFRoZXJl IHNlZW0gbm93IHRvIGJlIHNldmVyYWwgY2FzZXMgKEkgaGFkIGlnbm9yZWQgcHJlZml4LUggYXMg ZnJhZ2lsZSwgYnV0IHRoYXQgaXMgYSBkaWZmZXJlbnQgZGViYXRlLg0KDQoxKSBUaGUgcGFja2V0 IGlzIG5vdCBhZGRyZXNzZWQgdG8gYW55IFNJRCBpbiB0aGUgZG9tYWluLiAgVGhlbiB0aGUgcGFj a2V0IGNhbiBiZSBwcm9jZXNzZWQsIHBvc3NpYmx5IGVuY2Fwc3VsYXRlZCB3aXRoIGFuIFNSSCwg YW5kIHNlbnQgaW53YXJkcy4NCg0KMikgVGhlIHBhY2tldCBpcyBhZGRyZXNzZWQgdG8gYSBTSUQg dGhhdCBpcyBub3QgaW4gcHJlZml4LUggKGkuZS4gbm90IGEgU0lEIGtub3duIHRvIGJlIGNvbmZp Z3VyZWQgdG8gY2hlY2sgSE1BQ3MuKSAgRHJvcCB0aGUgcGFja2V0LiAgVGhpcyB3YXMgdGhlIHN0 ZXAgSSBoYWQgbm90IHVuZGVyc3Rvb2QgaW4gYnkgcHJldmlvdXMgcmVhZGluZyBvZiA2LjIuMSwg YXMgaXQgc2VlbXMgc3RydWN0dXJhbGx5IHRvIGJlIHBhcnQgb2YgYW4gZXhhbXBsZSwgbm90IGEg cmVxdWlyZWQgcGllY2Ugb2YgY29uZmlndXJhdGlvbiBiZWhhdmlvci4NCg0KMykgVGhlIHBhY2tl dCBpcyBhZGRyZXNzIHRvIGEgU0lEIGluIHByZWZpeC1ILiAgSWYgdGhhdCBTSUQgaXMgdGhpcyBu b2RlLCBjaGVjayB0aGUgSE1BQyBhbmQgYWN0IGJhc2VkIG9uIGl0LiAgSWYgaXQgaXMgc29tZSBv dGhlciBTSUQgd2l0aGluIHByZWZpeC1ILCB0aGVuIHNlbmQgaXQgb24gaXRzIHdheS4NCg0KSWYg dGhhdCBpcyB0aGUgaW50ZW5kZWQgYmVoYXZpb3IsIHRoZW4gSSB3b3VsZCBzdWdnZXN0IGV4dHJh IHRleHQgaW4gNi4yLiAgVGhlIHRleHQgY2FuIGZvcndhcmQgcmVmZXJlbmNlIHByZWZpeC1IIGZv ciBTSURzIGtub3duIHRvIGNoZWNrIEhNQUMuICBBbmQgc2hvdWxkIGluY2x1ZGUgdGhlIGNhc2Ug d2hlcmUgdGVoIFNJRCBpcyB0aGlzIGVkZ2Ugbm9kZSAod2hpY2ggaXMgZnJhbmtseSB0aGUgbW9z dCBsaWtlbHkgYW5kIHJvYnVzdCB3YXkgdG8gZG8gdGhlIGNoZWNraW5nLikNCg0KSWYgeW91IGRv IG5vdCBpbnRlbmQgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIHVzZSBvZiBwcmVmaXgtSCB0byBiZSBu b3JtYXRpdmUsIHRoZW4geW91IG5lZWQgdG8gZXhwbGFpbiB0aGF0IG1hZ2ljIGtub3dsZWRnZSBv ZiBzdWNoIGNoZWNraW5nIGlzIG5lY2Vzc2FyeSwgb3IgdGhhdCB0aGUgaW5ncmVzcyBlZGdlIG5v ZGUgbXVzdCBjaGVjayB0aGUgSC1NQUMgZXZlbiBpZiBpdCBpcyBub3QgdGhlIGN1cnJlbnQgZGVz dGluYXRpb24sIHdoZW4gaXQgZG9lcyBub3QgaGF2ZSBzdWNoIGNvbmZpZ3VyYXRpb24uDQoNCllv dXJzLA0KSm9lbA0KDQpPbiAxMC8yMi8xOCA4OjI4IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykg d3JvdGU6DQpPbiBPY3QgMjIsIDIwMTgsIGF0IDc6NTIgUE0sIEpvZWwgTS4gSGFscGVybiA8am1o QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4gPG1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQoNClRoZSB0ZXh0IGluIHNlY3Rpb24gNi4yLjEgaXMg ZmluZSwgYW5kIGNsZWFyLiAgSXQgbWVyZWx5IGNvbnRyYWRpY3RzIHRoZSB0ZXh0IGluIHNlY3Rp b24gNi4yLiAgV2hhdCBJIGFtIGFza2luZyBpcyBub3QgZm9yIGEgYmVoYXZpb3JhbCBjaGFuZ2Us IGJ1dCBzaW1wbHkgdGhhdCB0aGUgdGV4dCBpbiA2LjIgYWNrbm93ZWxkZ2UgdGhlIGFjY2VwdGlv biBvZiA2LjIuMSBleHBsaWNpdGx5LA0KQXJlIHlvdSBzdWdnZXN0aW5nIHRleHQgbGlrZSB0aGUg Zm9sbG93aW5nIGluIHNlY3Rpb24gNi4yIHBhcmEgMT8NCiDigJwuLi5TSE9VTEQgZGlzY2FyZCBw YWNrZXRzIGRlc3RpbmVkIHRvIFNJRHMgd2l0aGluIHRoZSBTUiBEb21haW4gKjxuZXc+IHdoaWNo IGRvIG5vdCByZXF1aXJlIEhNQUMgdmVyaWZpY2F0aW9uIDwvbmV3PiogKG9mIHRoZSBwcmVzZW5j ZSBvZiBhbiBTUkgpIHRvIGF2b2lkIGF0dGFja3Mgb24gdGhlIFNSIERvbWFpbiBhcyBkZXNjcmli ZWQgYW5kIHJlZmVyZW5jZWQgaW4gW1JGQzUwOTVdLiAqPG5ldz4gU0lEcyByZXF1aXJpbmcgSE1B QyB2ZXJpZmljYXRpb24gYXJlIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDYuMi4xLi48L25ldz4qIg0K YW5kIGFzIGEgc2lkZSBlZmZlY3Qgbm90IHN0YXRlIHRoYXQgdGhlIGRpc2NhcmQgaGFwcGVucyAi cmVnYXJkbGVzcyBvZiB0aGUgcHJlc2VuY2Ugb2YgYW4gU1JIIiwgc2luY2UgaW4gdGhlIHByZXNl bmNlIG9mIGFuIFNSSCwgdGhlIGVkZ2Ugbm9kZSBoYXMgdG8gKEkgd291bGQgaG9wZSBNVVNUKSBj aGVjayB0aGUgU1JIIGZvciBhbiBITUFDLCBhbmQgYXR0ZW1wdCB0byB2ZXJpZnkgdGhlIEhNQUMu DQpUaGVyZSBpcyBubyBuZWVkIGZvciBhbiBlZGdlIHRvIGNoZWNrIGZvciBhbiBTUkggd2hlbiB0 aGUgZGVzdGluYXRpb24gaXMgd2l0aGluIFByZWZpeC1IIChhcyBkZWZpbmVkIGluIDYuMi4xKS4N Cg0KSSBzdXBwb3NlIHRoYXQgaWYgdGhlIGVkZ2Ugbm9kZSAga25ldyB0aGF0IHRoZXJlIHdlcmUg bm8gdmFsaWQgSE1BQ3MsIHRoZW4gaXQgY291bGQgc2tpcCBjaGVja2luZyB0aGUgU1JIIHNpbmNl IGl0IGNhbid0IGJlIHZhbGlkLiAgSWYgeW91IHdhbnQgdGhhdCBpbmNsdWRlZCwgZG8gc28uDQoN Ckl0IHdvdWxkIHRha2UgYSBmZXcgZXh0cmEgc2VudGVuY2UgZm9yIDYuMiB0eW8gcHJvcGVybHkg c2V0IHRoZSBncm91bmQgZm9yIDYuMi4xLg0KDQpJIHJlYWxseSBkaXNsaWtlIHdoZW4gdGhlIHRl eHQgc2F5cyAiWCBTSE9VTEQgZG8gWSIgYW5kIHRoZW4gaW4gYSBsYXRlciBzZWN0aW9uLCB3aXRo b3V0IGV2ZW4gc2F5aW5nICJ0aGlzIGlzIGFuIGV4Y2VwdGlvbiB0byB0aGUgYWJvdmUiIHRoZSB0 ZXh0IHNheXMgIlggU0hPVUxEIGRvIFogdW5kZXIgY29uZGl0aW9uIFEiLiAgSXQgY29uZnVzZXMg cmVhZGVycy4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDEwLzIyLzE4IDc6NDUgUE0sIERhcnJlbiBE dWtlcyAoZGR1a2VzKSB3cm90ZToNClRoYW5rcyBKb2VsLCBwbGVhc2Ugc2VlIGlubGluZS4NCk9u IE9jdCAyMiwgMjAxOCwgYXQgNjo1OSBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBl cm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+PiB3cm90ZToNCg0KSSB0aGluayB0aGlzIGlzIGEgbWlub3IgaXNzdWUuICBTZWN0aW9u cyA2LjIgYW5kIDYuMi4xIHRhbGsgYWJvdXQgcHJvY2Vzc2luZyBvZiBwYWNrZXRzIGZyb20gb3V0 c2lkZSB0aGUgU1IgRG9tYWluLiAgU2VjdGlvbiA2LjIsIHNheXMgdGhhdCBlZGdlIG5vZGVzICJT SE9VTEQgZGlzY2FyZCBwYWNrZXRzIGRlc3RpbmVkIHRvIFNJRHMgd2l0aGluIHRoZSBTUiBkb21h aW4uIiAgU291bmRzIGdvb2QuICBJdCBldmVuIGluY2x1ZGVzIHRoZSBwYXJlbnRoZXRpY2FsICIo cmVnYXJkbGVzcyBvZiB0aGUgcHJlc2VuY2Ugb2YgYW4gU1JIKSIgIFdoaWNoIHNvdW5kcyBldmVu IGJldHRlci4gIEJ1dCBpcyBjb250cmFkaWN0ZWQgYnkgc2VjdGlvbiA2LjIuMS4NCg0KU2VjdGlv biA2LjIuMSBzYXlzIHRoYXQgYW4gdHJ1c3RlZCBleHRlcm5hbCBub2RlIGNhbiBwcm92aWRlIGFu IFNSSC4gVGhlIHRydXN0ZWQgbm9kZSBwcm90ZWN0cyB0aGF0IFNSSCB3aXRoIGFuIEhNQUMgVExW LiAgQXQgdGhlIGRvbWFpbiBlZGdlLCBJIHByZXN1bWUgd2Uga25vdyBpdCBpcyBhIHRydXN0ZWQg bm9kZSBieSB0aGUgSE1BQyBUTFYuICAoTm90IGJ5IHRoZSBJUCBTb3VyY2UgYWRkcmVzcywgc2lu Y2UgdGhhdCBtYXkgYmUgZmFsc2UuKSAgV2hpY2ggbWVhbnMgdGhhdCBpbiBmYWN0LCB0aGUgZGlz Y2FyZCBpbiBzZWN0aW9uIDYuMiBpcyBub3QgInJlZ2FyZGxlc3Mgb2YgdGhlIHByZXNlbmNlIG9m IGFuIFNSSCIgaXQgaXMgcmF0aGVyIHVubGVzcyB0aGVyZSBpcyBhbiBTUkggd2l0aCBhIHZhbGlk IEhNQUMuDQpQbGVhc2UgcmUtcmVhZCBwYWdlIDIwICh0aGUgcmVzdCBvZiA2LjIuMSkgYW5kIGxl dCBtZSBrbm93IGlmIHlvdSBzdGlsbCB0aGluayB0aGlzIGlzIG5vdCBmdWxseSBkZWZpbmVkLiAg VGhpcyBpcyBjbGVhciB3aXRoIFByZWZpeC1IIGFuZCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgU0lE cyBhc3NpZ25lZCBmcm9tIHRoYXQgcHJlZml4Lg0KDQpJZiB0aGF0IGlzIHRoZSBpbnRlbnRpb24g Zm9yIDYuMiwgY291bGQgd2UgcGxlYXNlIGhhdmUgdGhlIHRleHQgc2F5IHRoYXQuICBBbmQgdGhl biB1cGdyYWRlIHRoZSBTSE9VTEQgZm9yIHRoZSBlZGdlIHRvIGEgTVVTVD8NCkZvciB0aGUgSW50 ZXJuYWwgbm9kZXMgaW4gc2VjdGlvbiA2LjIsIHRoZSBTSE9VTEQgb3VnaHQgdG8gYWxzbyByZWZl cmVuY2UgdGhlIEhNQUMuICBJIGNhbiBzZWUgbGVhdmluZyB0aGF0IGFzIGEgU0hPVUxELCBhbHRo b3VnaCBJIHdvdWxkIHByZWZlciB0byBzZWUgaXQgYXMgYSBNVVNULg0KSWYgYWZ0ZXIgcmUtcmVh ZGluZyB5b3Ugc3RpbGwgaGF2ZSBhIGNvbmNlcm4gaW4gdGhpcyBhcmVhIGxldCBtZSBrbm93IGFu ZCB3ZSBjYW4gdGFsayBtb3JlLg0KRGFycmVuDQoNCllvdXJzLA0KSm9lbA0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnPG1h aWx0bzppcHY2QGlldGYub3JnPiA8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2 ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0K --_000_2847719CB915487283E0A64A8CBF3AD8ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3B262ECFF913594B8A7EADFE8A971FA8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCiYjNDM7c3ByaW5nDQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KPGZvbnQgY29sb3I9IiM1ODU2 ZDYiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDg4LCA4NiwgMjE0KTsi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+SGkgSm9lbCwgQWNrIG9uIGZv cndhcmQgcmVmZXJlbmNlIGluIDYuMiwgSeKAmWxsIHVzZSB0aGUgdGV4dCBJIHN1Z2dlc3RlZC48 YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoODgsIDg2LCAyMTQpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9zcGFuPjwvZm9udD5Ib3dldmVyIFByZWZpeC1IIGlzIGFuIGV4YW1wbGUgZm9yIHRoZSBmb2xs b3dpbmc8YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0ibW9ub3NwYWNl IiBzaXplPSIyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYig4OCwgODYs IDIxNCk7IHdoaXRlLXNwYWNlOiBwcmU7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+ PC9mb250PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgb3JwaGFuczogMjsgd2lk b3dzOiAyOyIgY2xhc3M9IiI+Jmx0O3F1b3RlJmd0Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDtTUiBEb21haW4gaW5ncmVzcyByb3V0ZXJzIHBlcm1pdCB0cmFm ZmljIGRlc3RpbmVkIHRvIHNlbGVjdCBTSURzIHdpdGg8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IiBj bGFzcz0iIj4mbmJzcDsgJm5ic3A7c2VnbWVudCBsaXN0cy48L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7 IiBjbGFzcz0iIj4mbHQ7L3F1b3RlJmd0Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxl PSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IGJyZWFrLWJlZm9yZTogcGFnZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBv cnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij4gICBsb2NhbCBwb2xpY3kgcmVxdWlyaW5nIEhNQUMgVExW IHByb2Nlc3NpbmcgZm9yIHRob3NlIHNlbGVjdCBTSURzLA0KICAgaS5lLiB0aG9zZSBTSURzIHBy b3ZpZGUgYSBnYXRld2F5IHRvIHRoZSBTUiBEb21haW4gZm9yIGEgc2V0IG9mDQo8L3ByZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgZmFjZT0i bW9ub3NwYWNlIiBzaXplPSIyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn Yig4OCwgODYsIDIxNCk7IHdoaXRlLXNwYWNlOiBwcmU7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PC9mb250PlByZWZpeC1IIGlzIGlzIGEgdXNlZnVsIGlsbHVzdHJhdGlvbiwgYnV0 IGl0IGlzIG9ubHkgb25lIHdheSBhbiBhZG1pbmlzdHJhdG9yIG1heSBjaG9vc2UgdG8gcGVybWl0 IHBhY2tldHMgZGVzdGluZWQgdG8gU0lEcyByZXF1aXJpbmcgSE1BQyBUTFYgcHJvY2Vzc2luZyB0 byBlbnRlciB0aGVpciBkb21haW4uPGJyIGNsYXNzPSIiPg0KPGZvbnQgY29sb3I9IiM1ODU2ZDYi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDg4LCA4NiwgMjE0KTsiIGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+RGVwZW5kaW5nIG9uIHRoZSBkZXBs b3ltZW50IHNoZSBtYXkgZGVjaWRlIHRvIHBlcm1pdCBzcGVjaWZpYyBzb3VyY2UgYWRkcmVzcyB0 byB1c2Ugc3BlY2lmaWMgU0lEcyByZXF1aXJpbmcgSE1BQyBwcm9jZXNzaW5nIG9uIHNwZWNpZmlj IGludGVyZmFjZXMgb25seS48YnIgY2xhc3M9IiI+DQpJbiB0aGlzIGNhc2UgdGhlIGZhY3QgdGhh dCBhbGwgdGhvc2UgU0lEcyBhcmUgYWxsb2NhdGVkIHdpdGhpbiBhIFByZWZpeC1IIGlzIG5vdCBy ZWxldmFudCwgbm9yIHdvdWxkIHNoZSBwZXJtaXQgcGFja2V0cyBkZXN0aW5lZCB0byBwcmVmaXgt SCBhdCBhbGwgaW5ncmVzcyBub2Rlcy48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZk NiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoODgsIDg2LCAyMTQpOyIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9udD5EYXJyZW48YnIgY2xhc3M9IiI+ DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoODgsIDg2LCAyMTQpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9zcGFuPjwvZm9udD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiBPY3QgMjIsIDIwMTgsIGF0IDg6MzkgUE0sIEpvZWwgTS4gSGFs cGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIGNsYXNzPSIiPmpt aEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQo8Zm9udCBjb2xvcj0iIzAwYWZj ZCIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMTc1LCAyMDUpOyIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9udD5JIGFtIG5vdCBzdXJlIEkgYW0g cHV0dGluZyB0aGUgaW50ZW5kZWQgcGllY2VzIHRvZ2V0aGVyIHJpZ2h0LjxiciBjbGFzcz0iIj4N Cjxmb250IGNvbG9yPSIjMDBhZmNkIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAxNzUsIDIwNSk7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9mb250 PkEgcGFja2V0IGFycml2ZXMgYXQgYSBkb21haW4gZWRnZSB0aGF0IHN1cHBvcnRzIFNSdjYuICZu YnNwO1RoZXJlIHNlZW0gbm93IHRvIGJlIHNldmVyYWwgY2FzZXMgKEkgaGFkIGlnbm9yZWQgcHJl Zml4LUggYXMgZnJhZ2lsZSwgYnV0IHRoYXQgaXMgYSBkaWZmZXJlbnQgZGViYXRlLjxiciBjbGFz cz0iIj4NCjxmb250IGNvbG9yPSIjMDBhZmNkIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAxNzUsIDIwNSk7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+ PC9mb250PjEpIFRoZSBwYWNrZXQgaXMgbm90IGFkZHJlc3NlZCB0byBhbnkgU0lEIGluIHRoZSBk b21haW4uICZuYnNwO1RoZW4gdGhlIHBhY2tldCBjYW4gYmUgcHJvY2Vzc2VkLCBwb3NzaWJseSBl bmNhcHN1bGF0ZWQgd2l0aCBhbiBTUkgsIGFuZCBzZW50IGlud2FyZHMuPGJyIGNsYXNzPSIiPg0K PGZvbnQgY29sb3I9IiMwMGFmY2QiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDE3NSwgMjA1KTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+ MikgVGhlIHBhY2tldCBpcyBhZGRyZXNzZWQgdG8gYSBTSUQgdGhhdCBpcyBub3QgaW4gcHJlZml4 LUggKGkuZS4gbm90IGEgU0lEIGtub3duIHRvIGJlIGNvbmZpZ3VyZWQgdG8gY2hlY2sgSE1BQ3Mu KSAmbmJzcDtEcm9wIHRoZSBwYWNrZXQuICZuYnNwO1RoaXMgd2FzIHRoZSBzdGVwIEkgaGFkIG5v dCB1bmRlcnN0b29kIGluIGJ5IHByZXZpb3VzIHJlYWRpbmcgb2YgNi4yLjEsIGFzIGl0IHNlZW1z IHN0cnVjdHVyYWxseSB0byBiZSBwYXJ0DQogb2YgYW4gZXhhbXBsZSwgbm90IGEgcmVxdWlyZWQg cGllY2Ugb2YgY29uZmlndXJhdGlvbiBiZWhhdmlvci48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xv cj0iIzAwYWZjZCIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMTc1 LCAyMDUpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9udD4zKSBUaGUgcGFj a2V0IGlzIGFkZHJlc3MgdG8gYSBTSUQgaW4gcHJlZml4LUguICZuYnNwO0lmIHRoYXQgU0lEIGlz IHRoaXMgbm9kZSwgY2hlY2sgdGhlIEhNQUMgYW5kIGFjdCBiYXNlZCBvbiBpdC4gJm5ic3A7SWYg aXQgaXMgc29tZSBvdGhlciBTSUQgd2l0aGluIHByZWZpeC1ILCB0aGVuIHNlbmQgaXQgb24gaXRz IHdheS48YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzAwYWZjZCIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMTc1LCAyMDUpOyIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9zcGFuPjwvZm9udD5JZiB0aGF0IGlzIHRoZSBpbnRlbmRlZCBiZWhhdmlvciwgdGhl biBJIHdvdWxkIHN1Z2dlc3QgZXh0cmEgdGV4dCBpbiA2LjIuICZuYnNwO1RoZSB0ZXh0IGNhbiBm b3J3YXJkIHJlZmVyZW5jZSBwcmVmaXgtSCBmb3IgU0lEcyBrbm93biB0byBjaGVjayBITUFDLiAm bmJzcDtBbmQgc2hvdWxkIGluY2x1ZGUgdGhlIGNhc2Ugd2hlcmUgdGVoIFNJRCBpcyB0aGlzIGVk Z2Ugbm9kZSAod2hpY2ggaXMgZnJhbmtseSB0aGUgbW9zdCBsaWtlbHkgYW5kDQogcm9idXN0IHdh eSB0byBkbyB0aGUgY2hlY2tpbmcuKTxiciBjbGFzcz0iIj4NCjxmb250IGNvbG9yPSIjMDBhZmNk IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAxNzUsIDIwNSk7IiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9mb250PklmIHlvdSBkbyBub3QgaW50ZW5k IHRoZSBjb25maWd1cmF0aW9uIGFuZCB1c2Ugb2YgcHJlZml4LUggdG8gYmUgbm9ybWF0aXZlLCB0 aGVuIHlvdSBuZWVkIHRvIGV4cGxhaW4gdGhhdCBtYWdpYyBrbm93bGVkZ2Ugb2Ygc3VjaCBjaGVj a2luZyBpcyBuZWNlc3NhcnksIG9yIHRoYXQgdGhlIGluZ3Jlc3MgZWRnZSBub2RlIG11c3QgY2hl Y2sgdGhlIEgtTUFDIGV2ZW4gaWYgaXQgaXMgbm90IHRoZSBjdXJyZW50IGRlc3RpbmF0aW9uLA0K IHdoZW4gaXQgZG9lcyBub3QgaGF2ZSBzdWNoIGNvbmZpZ3VyYXRpb24uPGJyIGNsYXNzPSIiPg0K PGZvbnQgY29sb3I9IiMwMGFmY2QiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDE3NSwgMjA1KTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+ WW91cnMsPGJyIGNsYXNzPSIiPg0KSm9lbDxiciBjbGFzcz0iIj4NCjxmb250IGNvbG9yPSIjMDBh ZmNkIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAxNzUsIDIwNSk7 IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9mb250Pk9uIDEwLzIyLzE4IDg6Mjgg UE0sIERhcnJlbiBEdWtlcyAoZGR1a2VzKSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQpPbiBPY3QgMjIsIDIwMTgsIGF0IDc6NTIgUE0sIEpv ZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIGNs YXNzPSIiPmptaEBqb2VsaGFscGVybi5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSIgY2xhc3M9IiI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0 OyZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+PC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHRleHQgaW4gc2VjdGlvbiA2LjIu MSBpcyBmaW5lLCBhbmQgY2xlYXIuICZuYnNwO0l0IG1lcmVseSBjb250cmFkaWN0cyB0aGUgdGV4 dCBpbiBzZWN0aW9uIDYuMi4gJm5ic3A7V2hhdCBJIGFtIGFza2luZyBpcyBub3QgZm9yIGEgYmVo YXZpb3JhbCBjaGFuZ2UsIGJ1dCBzaW1wbHkgdGhhdCB0aGUgdGV4dCBpbiA2LjIgYWNrbm93ZWxk Z2UgdGhlIGFjY2VwdGlvbiBvZiA2LjIuMSBleHBsaWNpdGx5LDxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4N CkFyZSB5b3Ugc3VnZ2VzdGluZyB0ZXh0IGxpa2UgdGhlIGZvbGxvd2luZyBpbiBzZWN0aW9uIDYu MiBwYXJhIDE/PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ PC9ibG9ja3F1b3RlPg0KJm5ic3A74oCcLi4uU0hPVUxEIGRpc2NhcmQgcGFja2V0cyBkZXN0aW5l ZCB0byBTSURzIHdpdGhpbiB0aGUgU1IgRG9tYWluICombHQ7bmV3Jmd0OyB3aGljaCBkbyBub3Qg cmVxdWlyZSBITUFDIHZlcmlmaWNhdGlvbiAmbHQ7L25ldyZndDsqIChvZiB0aGUgcHJlc2VuY2Ug b2YgYW4gU1JIKSB0byBhdm9pZCBhdHRhY2tzIG9uIHRoZSBTUiZuYnNwO0RvbWFpbiBhcyBkZXNj cmliZWQgYW5kIHJlZmVyZW5jZWQgaW4gW1JGQzUwOTVdLiAqJmx0O25ldyZndDsgU0lEcyByZXF1 aXJpbmcgSE1BQyB2ZXJpZmljYXRpb24NCiBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNi4yLjEu LiZsdDsvbmV3Jmd0OyomcXVvdDs8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj5hbmQgYXMgYSBzaWRlIGVmZmVjdCBub3Qgc3RhdGUgdGhhdCB0aGUgZGlzY2Fy ZCBoYXBwZW5zICZxdW90O3JlZ2FyZGxlc3Mgb2YgdGhlIHByZXNlbmNlIG9mIGFuIFNSSCZxdW90 Oywgc2luY2UgaW4gdGhlIHByZXNlbmNlIG9mIGFuIFNSSCwgdGhlIGVkZ2Ugbm9kZSBoYXMgdG8g KEkgd291bGQgaG9wZSBNVVNUKSBjaGVjayB0aGUgU1JIIGZvciBhbiBITUFDLCBhbmQgYXR0ZW1w dCB0byB2ZXJpZnkgdGhlIEhNQUMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KVGhlcmUgaXMgbm8gbmVl ZCBmb3IgYW4gZWRnZSB0byBjaGVjayBmb3IgYW4gU1JIIHdoZW4gdGhlIGRlc3RpbmF0aW9uIGlz IHdpdGhpbiBQcmVmaXgtSCAoYXMgZGVmaW5lZCBpbiA2LjIuMSkuPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj48L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQpJIHN1cHBvc2UgdGhhdCBpZiB0aGUgZWRnZSBu b2RlICZuYnNwO2tuZXcgdGhhdCB0aGVyZSB3ZXJlIG5vIHZhbGlkIEhNQUNzLCB0aGVuIGl0IGNv dWxkIHNraXAgY2hlY2tpbmcgdGhlIFNSSCBzaW5jZSBpdCBjYW4ndCBiZSB2YWxpZC4gJm5ic3A7 SWYgeW91IHdhbnQgdGhhdCBpbmNsdWRlZCwgZG8gc28uPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KSXQgd291bGQgdGFr ZSBhIGZldyBleHRyYSBzZW50ZW5jZSBmb3IgNi4yIHR5byBwcm9wZXJseSBzZXQgdGhlIGdyb3Vu ZCBmb3IgNi4yLjEuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+PC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KSSByZWFsbHkgZGlzbGlrZSB3aGVuIHRoZSB0ZXh0IHNh eXMgJnF1b3Q7WCBTSE9VTEQgZG8gWSZxdW90OyBhbmQgdGhlbiBpbiBhIGxhdGVyIHNlY3Rpb24s IHdpdGhvdXQgZXZlbiBzYXlpbmcgJnF1b3Q7dGhpcyBpcyBhbiBleGNlcHRpb24gdG8gdGhlIGFi b3ZlJnF1b3Q7IHRoZSB0ZXh0IHNheXMgJnF1b3Q7WCBTSE9VTEQgZG8gWiB1bmRlciBjb25kaXRp b24gUSZxdW90Oy4gJm5ic3A7SXQgY29uZnVzZXMgcmVhZGVycy48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQpZb3Vycyw8 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVv dGU+DQpKb2VsPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ PC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+PC9ibG9ja3F1b3RlPg0KT24gMTAvMjIvMTggNzo0NSBQTSwgRGFycmVuIER1a2VzIChk ZHVrZXMpIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KVGhh bmtzIEpvZWwsIHBsZWFzZSBzZWUgaW5saW5lLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9i bG9ja3F1b3RlPg0KT24gT2N0IDIyLCAyMDE4LCBhdCA2OjU5IFBNLCBKb2VsIE0uIEhhbHBlcm4g Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiBjbGFzcz0iIj5qbWhAam9l bGhhbHBlcm4uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i IGNsYXNzPSIiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90 ZT4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxv Y2txdW90ZT4NCkkgdGhpbmsgdGhpcyBpcyBhIG1pbm9yIGlzc3VlLiAmbmJzcDtTZWN0aW9ucyA2 LjIgYW5kIDYuMi4xIHRhbGsgYWJvdXQgcHJvY2Vzc2luZyBvZiBwYWNrZXRzIGZyb20gb3V0c2lk ZSB0aGUgU1IgRG9tYWluLiAmbmJzcDtTZWN0aW9uIDYuMiwgc2F5cyB0aGF0IGVkZ2Ugbm9kZXMg JnF1b3Q7U0hPVUxEIGRpc2NhcmQgcGFja2V0cyBkZXN0aW5lZCB0byBTSURzIHdpdGhpbiB0aGUg U1IgZG9tYWluLiZxdW90OyAmbmJzcDtTb3VuZHMgZ29vZC4gJm5ic3A7SXQgZXZlbiBpbmNsdWRl cyB0aGUgcGFyZW50aGV0aWNhbA0KICZxdW90OyhyZWdhcmRsZXNzIG9mIHRoZSBwcmVzZW5jZSBv ZiBhbiBTUkgpJnF1b3Q7ICZuYnNwO1doaWNoIHNvdW5kcyBldmVuIGJldHRlci4gJm5ic3A7QnV0 IGlzIGNvbnRyYWRpY3RlZCBieSBzZWN0aW9uIDYuMi4xLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClNl Y3Rpb24gNi4yLjEgc2F5cyB0aGF0IGFuIHRydXN0ZWQgZXh0ZXJuYWwgbm9kZSBjYW4gcHJvdmlk ZSBhbiBTUkguIFRoZSB0cnVzdGVkIG5vZGUgcHJvdGVjdHMgdGhhdCBTUkggd2l0aCBhbiBITUFD IFRMVi4gJm5ic3A7QXQgdGhlIGRvbWFpbiBlZGdlLCBJIHByZXN1bWUgd2Uga25vdyBpdCBpcyBh IHRydXN0ZWQgbm9kZSBieSB0aGUgSE1BQyBUTFYuICZuYnNwOyhOb3QgYnkgdGhlIElQIFNvdXJj ZSBhZGRyZXNzLCBzaW5jZSB0aGF0IG1heSBiZSBmYWxzZS4pDQogJm5ic3A7V2hpY2ggbWVhbnMg dGhhdCBpbiBmYWN0LCB0aGUgZGlzY2FyZCBpbiBzZWN0aW9uIDYuMiBpcyBub3QgJnF1b3Q7cmVn YXJkbGVzcyBvZiB0aGUgcHJlc2VuY2Ugb2YgYW4gU1JIJnF1b3Q7IGl0IGlzIHJhdGhlciB1bmxl c3MgdGhlcmUgaXMgYW4gU1JIIHdpdGggYSB2YWxpZCBITUFDLjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4N ClBsZWFzZSByZS1yZWFkIHBhZ2UgMjAgKHRoZSByZXN0IG9mIDYuMi4xKSBhbmQgbGV0IG1lIGtu b3cgaWYgeW91IHN0aWxsIHRoaW5rIHRoaXMgaXMgbm90IGZ1bGx5IGRlZmluZWQuICZuYnNwO1Ro aXMgaXMgY2xlYXIgd2l0aCBQcmVmaXgtSCBhbmQgdGhlIGRlZmluaXRpb24gb2YgdGhlIFNJRHMg YXNzaWduZWQgZnJvbSB0aGF0IHByZWZpeC48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxv Y2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PjwvYmxvY2txdW90ZT4NCklmIHRoYXQgaXMgdGhlIGludGVudGlvbiBmb3IgNi4yLCBjb3VsZCB3 ZSBwbGVhc2UgaGF2ZSB0aGUgdGV4dCBzYXkgdGhhdC4gJm5ic3A7QW5kIHRoZW4gdXBncmFkZSB0 aGUgU0hPVUxEIGZvciB0aGUgZWRnZSB0byBhIE1VU1Q/PGJyIGNsYXNzPSIiPg0KRm9yIHRoZSBJ bnRlcm5hbCBub2RlcyBpbiBzZWN0aW9uIDYuMiwgdGhlIFNIT1VMRCBvdWdodCB0byBhbHNvIHJl ZmVyZW5jZSB0aGUgSE1BQy4gJm5ic3A7SSBjYW4gc2VlIGxlYXZpbmcgdGhhdCBhcyBhIFNIT1VM RCwgYWx0aG91Z2ggSSB3b3VsZCBwcmVmZXIgdG8gc2VlIGl0IGFzIGEgTVVTVC48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Js b2NrcXVvdGU+DQpJZiBhZnRlciByZS1yZWFkaW5nIHlvdSBzdGlsbCBoYXZlIGEgY29uY2VybiBp biB0aGlzIGFyZWEgbGV0IG1lIGtub3cgYW5kIHdlIGNhbiB0YWxrIG1vcmUuPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KRGFycmVu PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQpZb3Vycyw8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+ DQpKb2VsPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+PC9ibG9ja3F1b3RlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQpJRVRGIElQdjYgd29ya2luZyBncm91 cCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj48L2Jsb2NrcXVvdGU+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgY2xhc3M9 IiI+aXB2NkBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiBj bGFzcz0iIj5tYWlsdG86aXB2NkBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPg0KQWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2NiIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djY8L2E+PGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGZvbnQgY29sb3I9IiM1ODU2 ZDYiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDg4LCA4NiwgMjE0KTsi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4NCklFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGll dGYub3JnIiBjbGFzcz0iIj5pcHY2QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4NCkFkbWluaXN0cmF0aXZlIFJl cXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8YnIgY2xh c3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_2847719CB915487283E0A64A8CBF3AD8ciscocom_-- From nobody Fri Oct 26 11:28:41 2018 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 38840130DE8; Fri, 26 Oct 2018 11:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 wslkaWGIW3pt; Fri, 26 Oct 2018 11:28:38 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 CBEBD130DDB; Fri, 26 Oct 2018 11:28:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AE212A6743D; Fri, 26 Oct 2018 11:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540578518; bh=q9sFVZstqO56WXSk4HmKcC1WTPieMTwNrqMT6Zy5/Vg=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=e9FE7knryRdLqQ7Y/BfK9mR3oQYgGOLiyk+CL44/dnaV0h8J8VJMfHGfV5xPwRjdG 5BESC/Sdg4BYnyv3qXwKO3Vnb0nOJ4XBaUFjIAktfidtxhov19nWIIEbjOeaFBPa6P Ax8Yubn2AUj1C2nxM3RU6yUH1GSNFgYjT3i2qsUo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1528DA6769B; Fri, 26 Oct 2018 11:28:38 -0700 (PDT) From: Joel Halpern To: "Darren Dukes (ddukes)" Cc: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> Message-ID: <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> Date: Fri, 26 Oct 2018 14:28:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] SRv6 - SRH in encaps or base header - point 2 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 18:28:40 -0000 (resending, +spring as requested) Thank you for the responses. I will respond in line, marked . I fear it will shortly get too deep, but the context is important. I will rephrase here an issue from another thread that I ahve not seen your comments on. If Node 9 is sending traffic to Node 1 (for example, the reverse traffic for the traffic from 1 to 9 in the examples below), it presumably has an SR Policy to be applied. The issue I raised before is the leakage issue. If 9 puts the SRH in its packet (as the document currently mandates), then it will not be possible for 3 to remove the SRH. Thus, the SRH will leak. Some have argued that is not a big deal. It seems to matter to me. But there is an additional problem. A1 is not a SID. Therefore, 9 can not put A1 into the SRH. If it can not put A1 into the SRH, and it does not encapsulate the packet, where does it put A1. Yours, Joel On 10/26/18 1:29 PM, Darren Dukes (ddukes) wrote: > Hi Joel, you’ve described sections titled “Intra SR Domain Packetâ€, “Transit Packet Through SR Domainâ€, and "SR Source Nodes Not Directly Connectedâ€. > > I’ve parsed them inline to the sections of the draft defining them and given more context where needed. > >> On Oct 22, 2018, at 8:49 PM, Joel M. Halpern wrote: >> >> Rephrasing using the example from 5.2. Assuming that 8 and 9 are SR Hosts (not just hosts within the domain, they are capable of and expect to deal with SRHs, and therefore have local SIDs, ...) >> >> For traffic from 8 to 9 that needs an SRH, the SRH goes in the IPv6 header sent my 8 to 9. When 9 processes the packet, it seems that it is the last SID, figures out that there is no encapsulation, and send the TCP / UDP / QUIC information to its internal protocols stacks. > > Yes, this is Section 5.3.1 “Intra SR Domain Packetâ€. Agreed as far as it goes. However, the existence of S9 and A9 points to a problem. Node 8 is trying to put on an SRH going through Sx, Sy, whatever for some reason. It can't put A9 into the SRH, as AH is not a SID, it is an address. I presume node 8 got S9 from whatever provided him the SR Policy that it is using. Does it simply use S9 as the address for node 9, rather than A9 that it got from DNS? And does the TCP stack know that this substitution is being made? (This is another example of a problem that goes away if we always encapsulate.) > >> >> For traffic from 1 to 9, where 3 adds an SRH, that SRH still presumably ends at 9. 9 Receives the IP packet. Sees that it is addressed to itself. Sees that the SRH is finished. And then notices that the next-header is IPv6. Unwraps the header, checks that the inner destination address is also itself, and passes the material carried by the inner header up to the appropriate stack. > > So node 1 sends a packet to node 9 (A1,A9) > IF there is some steering into an SR Policy at node 3 to reach node 9, this is identical to section 5.3.2 “Transit packet through SR domainâ€, except for destination of A9 via node 9 instead of A2 via node 4. > >> >> Thus, 9 needs to be able to check for both cases. We at least need to tell implementors that. > Well, 9 needs a SID S9 and Address A9. That is shown in Section 5.1 SID and address representation. > So, let us assume that 3 has an SR policy it wants to apply to the traffic from A1 to A9. In this case, the S9 / A9 dichotomy is not a problem, I think. Node 3 encapsualtes the packet from A1 to A9, uses S3 as the source address of the encapsulating header, and ends the SID list in the SRH with S9. The unspecified part is that node 9 needs to be prepared to receive such packets and do the double processing. It is reasonable double processing. My only request here is that we tell folks they need to support it. >> >> There is a further complication. 9 seems to need to have an address that is a valid SID, so it can be the last entry in the SRH from 8 to 9. > As described in the draft, Section 5.1 a node k has an address Ak and SID Sk. So node 9 has a valid SID. > For traffic from 8 to 9, A9 is used as the destination as shown in section 5.3.1, 5.4 and 5.5. > >> However, if 1 were to send the packet to that SID for 9, router 3 would be required by the rules we discussed in the other thread to discard the packet as it is neither to prefix nor contains an HAMC. >> And somehow, 8 and 1 need to each pick the right address to use for 9. (split DNS maybe?) And 3 needs to be able to derive teh SID-formn address for 9 from the non-SID form of the address so that it (3) can build a proper SRH to get the packet to 9. I have retained your answer below for context, but I think that answers the wrong question. I believe what is itnended is that only A9 appears in DNS. So Node 1 will see 9 as A9, and will use that. S9 will appear in SR Policies about traffic to node 9, but not in DNS. That is what we need. I wish it were clearer in the text. If node 20 is generating SRHs with HMACs, then this is largely the same as the case from 8 to 9, except that whomever creates the SR Policy that 20 is using needs to also make sure that whatever the first SID is in teh list, it processes HMACs and is recognizable to node 3 as doing such processing. I am guessing that the reason for allowing internal nodes to do the processing is to move the verification load off the edge nodes. It does create significant additional configuration complexity. > This is incorrect. > > See Section 6.2.1 “SR Source Nodes Not Directly Connected†I will expand on the example from that section. > > Node 20 sends a packet to A9 with SR Policy and an HMAC provided to node 20 by some yet to be defined method. Resulting in packet sent from node 20 > P: (A20,H7)(A9;SL=1)(payload) > > Recall Hk is a SID at node k requiring HMAC verification, and it is covered by Prefix-H. > > Prefix-H is _not_ subject to ingress filtering at node 3. > > Therefore the packet P destined to H7 is not subject to ingress filtering at node 3. > > P is forwarded to node 7, where H7 is processed and the HMAC verified. > > If the HMAC can not be verified the packet is dropped, else it is forwarded to the next segment and destination, A9. > > Darren > > >> >> Yours, >> Joel >> >> On 10/22/18 8:04 PM, Darren Dukes (ddukes) wrote: >>> inline. >>>> On Oct 22, 2018, at 7:21 PM, Joel M. Halpern wrote: >> .. >>>> 2) Now let us look at packets arriving at and actually destined for an SR Host in the SR Domain where that packet has an SRH. If the packet is coming from another SR Host, the SRH will be in the base header, and the host can simply check it for any violations, and continue. But, if the packet came from outside the domain, then it will have an encapsulating SRv6 header. So the host has to detect this case, check and then peal off the encapsulating header, and then process the received packet. Yes, it can do so. But nothing in teh document tells implementors they have to deal with both cases. >>>> >>> Can you be more precise here. Perhaps use the example from section 5.2 or 6.2.1? >> .. > From nobody Fri Oct 26 11:31:26 2018 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 32709130DE9; Fri, 26 Oct 2018 11:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 tmb-v1O4Mkee; Fri, 26 Oct 2018 11:31:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 38946130E0C; Fri, 26 Oct 2018 11:31:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 18645A6743D; Fri, 26 Oct 2018 11:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540578674; bh=WHGvvaHF/ZiQl230JreEbooMg0N/HV92/4cwiGcHbuI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BK0O7E+BYPQG2FIpwIW4js8BxEaUB61lBqpjcySqMHJzS7fY9An+U8bJ69zC4KZeP 5T1lckh3tOAcHp7dBw2nDclP+vR0mSNAx1GegG4IkuUhfQRZZeE7HAQQE4RBkITECG 81F0H/fsaMrphgl4tSx0pYiNw0HaKel6mq1LwuME= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 63144A676BA; Fri, 26 Oct 2018 11:31:13 -0700 (PDT) To: "Darren Dukes (ddukes)" Cc: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" References: <18dc95a7-7505-fe05-a44c-957823f9c5e9@joelhalpern.com> <711F5B74-B389-41A6-990A-0C4671A6059D@cisco.com> <5e2bdc8b-84ba-2001-2ed5-5eeafa1c66cc@joelhalpern.com> <187ED21C-B385-429D-8F41-7DEDB4DE97FE@cisco.com> <6a880982-b2cb-c157-6ce1-9c431337e327@joelhalpern.com> <8FE6EAA8-7A2A-4B1B-95DA-49916D062220@cisco.com> <2847719C-B915-4872-83E0-A64A8CBF3AD8@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 26 Oct 2018 14:31:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2847719C-B915-4872-83E0-A64A8CBF3AD8@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] SRv6 revision: edge behavior minor description issue X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 18:31:17 -0000 While I would prefer an explicit enumeration of cases, I think your proposed text likely fixes the specific problem. Yours, Joel On 10/26/18 2:22 PM, Darren Dukes (ddukes) wrote: > +spring > > Hi Joel, Ack on forward reference in 6.2, I’ll use the text I suggested. > > However Prefix-H is an example for the following > > >    SR Domain ingress routers permit traffic destined to select SIDs with >    segment lists. > >> local policy requiring HMAC TLV processing for those select SIDs, >> i.e. those SIDs provide a gateway to the SR Domain for a set of > > Prefix-H is is a useful illustration, but it is only one way an > administrator may choose to permit packets destined to SIDs requiring > HMAC TLV processing to enter their domain. > > Depending on the deployment she may decide to permit specific source > address to use specific SIDs requiring HMAC processing on specific > interfaces only. > In this case the fact that all those SIDs are allocated within a > Prefix-H is not relevant, nor would she permit packets destined to > prefix-H at all ingress nodes. > > Darren > > >> On Oct 22, 2018, at 8:39 PM, Joel M. Halpern > > wrote: >> >> I am not sure I am putting the intended pieces together right. >> >> A packet arrives at a domain edge that supports SRv6.  There seem now >> to be several cases (I had ignored prefix-H as fragile, but that is a >> different debate. >> >> 1) The packet is not addressed to any SID in the domain.  Then the >> packet can be processed, possibly encapsulated with an SRH, and sent >> inwards. >> >> 2) The packet is addressed to a SID that is not in prefix-H (i.e. not >> a SID known to be configured to check HMACs.)  Drop the packet.  This >> was the step I had not understood in by previous reading of 6.2.1, as >> it seems structurally to be part of an example, not a required piece >> of configuration behavior. >> >> 3) The packet is address to a SID in prefix-H.  If that SID is this >> node, check the HMAC and act based on it.  If it is some other SID >> within prefix-H, then send it on its way. >> >> If that is the intended behavior, then I would suggest extra text in >> 6.2.  The text can forward reference prefix-H for SIDs known to check >> HMAC.  And should include the case where teh SID is this edge node >> (which is frankly the most likely and robust way to do the checking.) >> >> If you do not intend the configuration and use of prefix-H to be >> normative, then you need to explain that magic knowledge of such >> checking is necessary, or that the ingress edge node must check the >> H-MAC even if it is not the current destination, when it does not have >> such configuration. >> >> Yours, >> Joel >> >> On 10/22/18 8:28 PM, Darren Dukes (ddukes) wrote: >>>> On Oct 22, 2018, at 7:52 PM, Joel M. Halpern >>> > wrote: >>>> >>>> The text in section 6.2.1 is fine, and clear.  It merely contradicts >>>> the text in section 6.2.  What I am asking is not for a behavioral >>>> change, but simply that the text in 6.2 acknoweldge the acception of >>>> 6.2.1 explicitly, >>> Are you suggesting text like the following in section 6.2 para 1? >>>  “...SHOULD discard packets destined to SIDs within the SR Domain >>> * which do not require HMAC verification * (of the >>> presence of an SRH) to avoid attacks on the SR Domain as described >>> and referenced in [RFC5095]. * SIDs requiring HMAC verification >>> are discussed in Section 6.2.1..*" >>>> and as a side effect not state that the discard happens "regardless >>>> of the presence of an SRH", since in the presence of an SRH, the >>>> edge node has to (I would hope MUST) check the SRH for an HMAC, and >>>> attempt to verify the HMAC. >>> There is no need for an edge to check for an SRH when the destination >>> is within Prefix-H (as defined in 6.2.1). >>>> >>>> I suppose that if the edge node  knew that there were no valid >>>> HMACs, then it could skip checking the SRH since it can't be valid. >>>>  If you want that included, do so. >>>> >>>> It would take a few extra sentence for 6.2 tyo properly set the >>>> ground for 6.2.1. >>>> >>>> I really dislike when the text says "X SHOULD do Y" and then in a >>>> later section, without even saying "this is an exception to the >>>> above" the text says "X SHOULD do Z under condition Q".  It confuses >>>> readers. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 10/22/18 7:45 PM, Darren Dukes (ddukes) wrote: >>>>> Thanks Joel, please see inline. >>>>>> On Oct 22, 2018, at 6:59 PM, Joel M. Halpern >>>>> > wrote: >>>>>> >>>>>> I think this is a minor issue.  Sections 6.2 and 6.2.1 talk about >>>>>> processing of packets from outside the SR Domain.  Section 6.2, >>>>>> says that edge nodes "SHOULD discard packets destined to SIDs >>>>>> within the SR domain."  Sounds good.  It even includes the >>>>>> parenthetical "(regardless of the presence of an SRH)"  Which >>>>>> sounds even better.  But is contradicted by section 6.2.1. >>>>>> >>>>>> Section 6.2.1 says that an trusted external node can provide an >>>>>> SRH. The trusted node protects that SRH with an HMAC TLV.  At the >>>>>> domain edge, I presume we know it is a trusted node by the HMAC >>>>>> TLV.  (Not by the IP Source address, since that may be false.) >>>>>>  Which means that in fact, the discard in section 6.2 is not >>>>>> "regardless of the presence of an SRH" it is rather unless there >>>>>> is an SRH with a valid HMAC. >>>>> Please re-read page 20 (the rest of 6.2.1) and let me know if you >>>>> still think this is not fully defined.  This is clear with Prefix-H >>>>> and the definition of the SIDs assigned from that prefix. >>>>>> >>>>>> If that is the intention for 6.2, could we please have the text >>>>>> say that.  And then upgrade the SHOULD for the edge to a MUST? >>>>>> For the Internal nodes in section 6.2, the SHOULD ought to also >>>>>> reference the HMAC.  I can see leaving that as a SHOULD, although >>>>>> I would prefer to see it as a MUST. >>>>> If after re-reading you still have a concern in this area let me >>>>> know and we can talk more. >>>>> Darren >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Oct 27 14:32:58 2018 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 2FD18130DE8; Sat, 27 Oct 2018 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ro0pfhIK7Yfl; Sat, 27 Oct 2018 14:32:52 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 294C91274D0; Sat, 27 Oct 2018 14:32:52 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id j2-v6so2148908pfn.11; Sat, 27 Oct 2018 14:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=JsgZDMTfwcKzu0ORpVGUb9tMY/LhXvZVlkMKRPupnlw=; b=ACV6dD9V+pYDkbuXlgdxQT3ONhJ7FZXNLAZapuhMGOHSiuJKDuNdSKQoUihMtLTaG7 b8ZqOclsEI50Ty6sOcMWKulMo2JaMLu7M97BZ4Z28yqAOpTnGURLH7QiADkLcPGmv6pb RYGhtPPzk07UJozCRQ2o0Sw1nGvxTvj7fBUI7MBU+lQSO9GeVMgjCzPIZnFYaf00/lR/ xACPmPYgkTjq/Bcj/g1k3miU2sL1gCKUh292RnmA+jssyzc3CRO7wpITHrgmzKTeNJ47 fhTvAWKO7P+LYwKXuGeE0tFdRLthSw/PZQYU6BkJ8xpABIISTgwSGMxoAUEGVkuHgDlf 3OYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=JsgZDMTfwcKzu0ORpVGUb9tMY/LhXvZVlkMKRPupnlw=; b=mNCApZF4/+O5+f3/o/bkM4J6eHAssKTbcKmEoys4YXcqQ8FjH6D1S7R6Q+wBD/Mw70 bGsMf/2YDdo+zUgkSZFpVCRfQZxtlYnFmTFELHNidI9C/s6qaDrkffrKj8NIAsqvpder 6enl/vH5WYmpMOL2aEppqfHT2ssp0ENaqeXU4xkuX6z2mRxR0CvXtBmFbju7SiWsErhM HQBRuJ82Z/FQ25eM8IwlxZGpY/cWE71RAJglhSeuEXldC05XXfCW84lSQLEOXthbCS0G SFL5S0Ld7SLrtLJyD0c+iSwTNVIFt9k/SpcXJ1SbTDLN3plpJVTtp/LbJo0rbxsLrTtt hBAw== X-Gm-Message-State: AGRZ1gJNetbTa+V4lQBB2UZWWB3Bv50igFlcUjtItsQ4Aha9O2OaWAzV Y9/m445bFBleyd7adI+r1Nc= X-Google-Smtp-Source: AJdET5emhkrZ3uw5pZvm1hwqL/A1f68V81jjMCs8LdNgkoWhEUlVFMY9F4spiW1uwWliPWON/HlFcA== X-Received: by 2002:a63:e818:: with SMTP id s24-v6mr7974149pgh.90.1540675971391; Sat, 27 Oct 2018 14:32:51 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id x189-v6sm8353892pfb.162.2018.10.27.14.32.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 14:32:50 -0700 (PDT) To: bruno.decraene@orange.com, "draft-ietf-spring-segment-routing-mpls@ietf.org" Cc: SPRING WG List References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> <13758_1527183609_5B06F8F9_13758_220_1_53C29892C857584299CBF5D05346208A47A53780@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: <00239620-318d-d9cc-f1b2-f03f8a6ea160@gmail.com> Date: Sat, 27 Oct 2018 14:32:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <13758_1527183609_5B06F8F9_13758_220_1_53C29892C857584299CBF5D05346208A47A53780@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------BC08951BF1A31DCA8A684B17" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 21:32:56 -0000 This is a multi-part message in MIME format. --------------BC08951BF1A31DCA8A684B17 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I uploaded version 15 on Oct/23 to address comments. Thanks a lot for the comments See my reply "#Ahmed" On 5/24/18 10:40 AM, bruno.decraene@orange.com wrote: > > Hi authors, > > I’ve reviewed the document. > > It looks good, thanks for your effort. > > Please find below some comments, nothing major. > > Thanks for considering them as part of the WG LC. > > Thanks, > > Regards, > > Bruno > > --- > > Somewhere in Abstract/1. Introduction/2. MPLS Instantiation of Segment > Routing > > MPLS Instantiation of Segment Routing is sometimes referred to with > two different names: MPLS-SR or SR-MPLS which seems sub-optimal. > > [I.D.-ietf-spring-segment-routing] uses the term SR-MPLS. May this > term should also be used at least once in this document. > > --- > > §2.2 > > "using the SRGB of the node" > > Please expand SRGB on first used. (in -13, this term is expand on §2.3 > which is after) > #Ahmed: Done > > --- > > §2.3 > > OLD: Just like SRGB, the SRLB need not be a single > >    contiguous range of label, except the SRGB MUST only be used to > >    instantiate global SIDs into the MPLS forwarding plane. > > NEW: > > Just like SRGB, the SRLB need not be a single > >    contiguous range of label. > > (simplify the sentence. The rule is already stated before in this section) > #Ahmed: I used a more general (and IMO more precise) wording > > --- > > [SRLB] > > "Hence it is > >    specified the same way and follows the same rules SRGB is specified > >    above in this sub-section." > > Sentence is not crystal clear and could probably be rephrased. > > More importantly, the sentence is incorrect: the SRLB does not follow > the last SRGB rules ( "The list of label ranges MUST only be used to > instantiate global SIDs into the MPLS forwarding plane") > #Ahmed: I used a more general (and IMO more precise) wording > > ------ > > §2.4 > > "0 =< I < size." > > "size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1" > > Algorithm looks good to me. Yet starting the index at 0 for SID index, > and 1 for SRGB sub-blocks may be slightly misleading. "Lh(1)- Ll(1)" > seems only defined in this document so an option would be to start > with "Lh(0)- Ll(0)" (this would impact the algo: :s/j = 1/ j = 0) > > Up to you. > #Ahmed: I left it as it is :) > > ------ > > §2.5 > > OLD: MPLS Incoming Label MAP > > NEW: MPLS Incoming Label Map > #Ahmed: Corrected > > (as per https://tools.ietf.org/html/rfc3031#section-3.11 ) > > -- > > OLD: o  (Endpoint, Color) representing an SR policy [I.D. > filsfils-spring-segment-routing-policy] > > NEW: o  an SR policy [I.D.-ietf-spring-segment-routing] > > (Otherwise, this would likely require a _Normative_ reference to I.D. > filsfils-spring-segment-routing-policy which would significantly delay > the RFC publication of this document. While > [I.D.-ietf-spring-segment-routing is already in the RFC editor queue > and does define a SR policy. ) > #Ahmed: This has become rfc8402. I overlooked this one and I will make it refer to rfc8402 in version 16 > > -- > > OLD: > >    o  (Prefix, Routing Instance, Topology, Algorithm), where a topology > >       is identified by a set of links with metrics. For the purpose of > >       incoming label collision resolution, the same numerical value > >       SHOULD be used on all routers to identify the same set of links > >       with metrics. > > (It's not crystal clear what "numerical value" refers to, given the > list (Prefix, Routing Instance, Topology, Algorithm)) > > NEW1: > >    o  (Prefix, Routing Instance, Topology, Algorithm), where a topology > >       is identified by a set of links with metrics. For the purpose of > >       incoming label collision resolution, the same Topology numerical > value > >       SHOULD be used on all routers to identify the same set of links > >       with metrics. > #Ahmed: I used this wording (thanks) > > NEW2: > >    o  (Prefix, Routing Instance, Topology, Algorithm). A Topology > >       identifies a set of links with metrics. For the purpose of > >       incoming label collision resolution, the same Topology numerical > value > >       SHOULD be used on all routers to identify the same set of links > >       with metrics. > > ----- > > §2.5.1 > > "       o All addresses are represented in 128 bits as follows > >             . IPv6 address is encoded natively > >             . IPv4 address is encoded in the most significant bits and > >                the remaining bits are set to zero > >        o All prefixes are represented by 128. > >             . A prefix is encoded in the most significant bits and the > >                remaining bits are set to zero. > >             . The prefix length is encoded before the prefix" > > "All prefixes are represented by 128." > > 128 what? Could be bits, but this does not fit with the addition of > the prefix length. > > "The prefix length is encoded before the prefix" > > using a field of what size? > #Ahmed: I corrected this to be (128+8) > > Do we (really) need 2 different encodings for prefix and address? > Especially since the rest of the algorithm does not make the difference: > >    "o  Encode the remaining set of FECs as follows > >        o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length, > >          Prefix, SR Algorithm, routing_instance_id, Topology)" > #Ahmed: It is just that conceptually an address and a prefix are different and they are usually handled quite differently by routing protocols > > --- > > §2.5.2. Redistribution between Routing Protocol Instances > > "   o  If the receiving instance's SRGB is the same as the SRGB of origin > >       instance, THEN > >        o the index is redistributed with the route > >    o  Else > >        o the index is not redistributed and if needed it is the duty of > >          the receiving instance to allocate a fresh index relative to > >          its own SRGB" > > With a strict interpretation of this rule, when one increases the size > of the SRGB, all indexes from redistributed prefixes will be withdrawn > because it's unlikely that we can guaranty that the change of both > SRGB be atomic. > > Could this be accommodated? e.g. by only using the SRBG below the > index ? i.e SRGB [0;index] or just the mapped label in both SRGB? > #Ahmed: I think this is a very fine corner case. But I am open to any suggestion > > --- > > §2.6 > > OLD: > > In the general case, the ingress node may not have exactly have the > >    same data of the receiving node, so the result may be different. > > NEW: > > In the general case, the ingress node may not have exactly the > >    same data of the receiving node, so the result may be different. > #Ahmed: I used that wording > > ---- > > §2.10 > > OLD > >    This document covers the calculation of outgoing label for the top > >    label only. The case where outgoing label is not the top label and is > >    part of a stack of labels that instantiates a routing policy or a > >    traffic engineering tunnel is covered in other documents such as > > [I.D.filsfils-spring-segment-routing-policy]. > > This may be understood as requiring a _normative_ reference for > [I.D.filsfils-spring-segment-routing-policy], which would > significantly delay the RFC publication of this document. > > Proposed NEW1: > >    This document covers the calculation of outgoing label for the top > >    label only. Other cases are out of scope of this document. > > Or NEW2: > >   This document covers the calculation of outgoing label for the top > >    label only. The case where outgoing label is not the top label and is > >    part of a stack of labels that instantiates a routing policy or a > >    traffic engineering tunnel is out of scope of this document. > #Ahmed: I changed the wording a little bit such that [I.D.filsfils-spring-segment-routing-policy] is an example > > -- > > §2.10.1 > > "   Suppose an MCC on a router "R0" determines that PUSH or CONTINUE > >    operation is to be applied to an incoming packet whose active SID is > >    the global SID "Si" ..." > >  My undertanding is that "whose" in "whose active SID" refers to the > the "incoming packet". This seems to imply that the incoming packet is > (already) labeled. > > - This does not match the example used in the following paregraph, > where the incoming packet is IP. > >  "An example of a method to determine the SID > >    "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis- > >    segment-routing-extensions] receives the prefix-SID "Si" sub-TLV > >    advertised with prefix "P/m" in TLV 135 and the destination address > >    of the incoming IPv4 packet is covered by the prefix "P/m"." > >  - Also, you can't simply perform a PUSH on a received label packet. > You first need to POP or SWAP the incoming label. > > May be proposed NEW: > >    Suppose an MCC on a router "R0" determines that a PUSH or CONTINUE > >    operation is to be applied to an incoming packet, related to the > global SID "Si" ... > #Ahmed: Modified the text as suggested > > ----- > > §2.10.1 > > OLD: If the neighbor "N" does not support SR or "I" does not satisfy > >       the inequality specified in Section 2.4 for the SRGB of the > >       neighbor "N" > > May be a more generic sentence: > > NEW   If the neighbor "N" does not support SR or advertises a SRGB > invalid or too small, > #Ahmed: Modified as suggested > >  ----- > > §2.10.1 > > OLD: > >        o If it is possible to send the packet towards the neighbor "N" > >           using standard MPLS forwarding behavior as specified in > >           {RFC3031] and [RFC3032], then forward the packet. The method > >           by which a router decides whether it is possible to send the > >           packet to "N" or not is beyond the scope of this document. For > >           example, the router "R0" can use the downstream label > >           determined by another MCC, such as LDP [RFC5036], to send the > >           packet. > > The fall back to LDP seems like a mandated behavior. If so, the > behavior seems under-specified. In particular "out of scope of this > document" does not seem like a valid argument. > #Ahmed: In general LDP is not mandated. The statement says use MPLS. How and what protocol is used to determine what to do with the incoming label(s) (if any) and what is (are) the outgoing label(s) is totally outside the scope of this document. > > Possible NEW: > > "       o If this neighbor "N" advertises a valid label for the same > FEC via another MCC (e.g. LDP [RFC5036]), then forward the packet to > N, using the label advertised by this MCC. > > ---- > > 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for > Local SIDs > >   "A local SID on a router "R0" corresponds to a local label such as an > >    IGP adj-SID. In such scenario, the outgoing label towards a next-hop > >    "N" is determined by the MCC running on the router "R0"and the > >    forwarding behavior for CONTINUE operation is identical to swap > >    operation [RFC3032] on an MPLS label" > > I'm not seeing a case where an IGP adj-SID would have "CONTINUE" as a > forwarding behavior. > > And the SR architecture requires a NEXT operation: > > "      When a node binds an Adj-SID to a local data-link L, the node MUST > >        install the following FIB entry: > >       Incoming Active Segment: V > >       Ingress Operation: NEXT > >       Egress Interface: L" > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.4 > > A solution would be to simply remove "such as an IGP adj-SID" > #Ahmed: I agree and I removed adj-SID > > --- > > §3 IGP Segment examples > > This section, also useful, is quite long and not normative for this > STD track doc. An option may be to move it to appendix. > > Up to you. > #Ahmed: Agreed and moved to appendix > > --- > > §3.1 > > "R2 is the next-hop along the shortest path towards R8. By applying > >    the steps in Section 2.8 the local label downloaded to R1's FIB > >    corresponding to the global SID index 8 is 1008 because the SRGB of > >    R2 is [1000,5000] as shown in Figure 2." > >  may be > > OLD:  local label downloaded to R1's FIB > > NEW:  local outgoing label downloaded to R1's FIB > >  (because I would assume that by default, label downloaded in the FIB > is probably the incomig label one) > #Ahmed Changed "local" to "outgoing" > >  -- > > OLD: owned by the R8 > > NEW1: OLD: owned by R8 > > NEW2: OLD: owned by the node R8 > #Ahmed: Done > > -- > > "The packet arrives at router R2. Because the top label 1008 > >    corresponds to the IGP SID "8", which is the prefix-SID attached to > >    the prefix 192.0.2.8/32 owned by the R8, then the instruction > >    associated with the SID is "forward the packet using all ECMP/UCMP > >    interfaces and all ECMP/UCMP next-hop(s) along the shortest path > >    towards R8". " > > IGP prefix-SID are typically forwarded along the ECMP shortest path. > I'm not sure where "UCMP" is coming from. Also "along the shortest > path" seems to be incompatible with UCMP. > #Ahmed: I changed the wording to "shortest/useable" > > -- > > "Because R3 > >    is the penultimate hop, R3 applies NEXT operation then sends the > >    packet to R8." > >    "penultimate hop" is a required but not sufficient reason. You are > assuming that R8 asked for PHP, but I'm not seeing this assumption > stated in the text. > #Ahmed: I changed to wording to use  "assume" > > --- > > "The NEXT operation results in popping the outer label > >    and sending the packet as a pure IPv4 packet to R8. The > >    In conclusion, " > > OLD: The > > NEW: > #Ahmed: In many places, I refer to each operation using "the". > > --- > > §3.2 & §3.3 & §3.4 & §3.5 > > " Using the > >    calculation techniques specified in Section 2.10 and 2.11 the > >    resulting label stack starting from the topmost label is <1002, 9001, > >    1008>." > > Actually section 2.10 only defines the calculation technique for the > top label: > >    "This document covers the calculation of outgoing label for the top > >    label only. The case where outgoing label is not the top label and is > >    part of a stack of labels that instantiates a routing policy or a > >    traffic engineering tunnel is covered in other documents such as > > [I.D.filsfils-spring-segment-routing-policy]." > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13#section-2.10 > >    Hence this document does not define the behavior for this example > 2. You would need to either extend this doc to cover the push of a > stack of label/SID or remove these examples 2, 3, 4, 5 > #Ahmed Done > > ---- > > [RFC8174] to be added to normative references. > #Ahmed: Done > > *From:*bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > *Sent:* Thursday, May 24, 2018 7:14 PM > *To:* SPRING WG List > *Cc:* draft-ietf-spring-segment-routing-mpls@ietf.org > *Subject:* WG Last Call for draft-ietf-spring-segment-routing-mpls-13 > > Hello Working Group, > This email starts a Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-13 [1] which is considered > mature and ready for a final working group review. > Please read this document if you haven't read the most recent version > yet, and send your comments to the list, no later than *June 08*. > As a reminder, this document had already passed a WGLC more than a > year ago on version -06 [2], had been sent to the AD but then returned > to the WG. > Since then, the document has significantly changed, so please read it > again. In particular, it now includes the resolution in case of > incoming label collision. Hence it killed > draft-ietf-spring-conflict-resolution. > Both co-chairs co-author this document, hence: > - Shraddha has agreed to be the document shepherd. Thank you Shraddha. > - Martin, our AD, has agreed to evaluate the WG consensus. > Thank you, > Bruno, Rob > [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 > [2] > https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y > _________________________________________________________________________________________________________________________ > 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. --------------BC08951BF1A31DCA8A684B17 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I uploaded version 15 on Oct/23 to address comments.

Thanks a lot for the comments

See my reply "#Ahmed"


On 5/24/18 10:40 AM, bruno.decraene@orange.com wrote:

Hi authors,

 

I’ve reviewed the document.

It looks good, thanks for your effort.

 

Please find below some comments, nothing major.

Thanks for considering them as part of the WG LC.

 

Thanks,

Regards,

Bruno

 

---

Somewhere in Abstract/1. Introduction/2. MPLS Instantiation of Segment Routing

 

MPLS Instantiation of Segment Routing is sometimes referred to with two different names: MPLS-SR or SR-MPLS which seems sub-optimal.

[I.D.-ietf-spring-segment-routing] uses the term SR-MPLS. May this term should also be used at least once in this document.

 

---

§2.2

"using the SRGB of the node"

Please expand SRGB on first used. (in -13, this term is expand on §2.3 which is after)

 

#Ahmed: Done

---

§2.3

OLD: Just like SRGB, the SRLB need not be a single

   contiguous range of label, except the SRGB MUST only be used to

   instantiate global SIDs into the MPLS forwarding plane.

 

NEW:

Just like SRGB, the SRLB need not be a single

   contiguous range of label.

  

(simplify the sentence. The rule is already stated before in this section)

#Ahmed: I used a more general (and IMO more precise) wording

 

---

[SRLB]

"Hence it is

   specified the same way and follows the same rules SRGB is specified

   above in this sub-section."

 

Sentence is not crystal clear and could probably be rephrased.

More importantly, the sentence is incorrect: the SRLB does not follow the last SRGB rules ( "The list of label ranges MUST only be used to instantiate global SIDs into the MPLS forwarding plane")

#Ahmed: I used a more general (and IMO more precise) wording

 

------

§2.4

 

"0 =< I < size."

"size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1"

 

Algorithm looks good to me. Yet starting the index at 0 for SID index, and 1 for SRGB sub-blocks may be slightly misleading. "Lh(1)- Ll(1)" seems only defined in this document so an option would be to start with "Lh(0)- Ll(0)" (this would impact the algo: :s/j = 1/ j = 0)

Up to you.

#Ahmed: I left it as it is :)

 

------

§2.5

 

OLD: MPLS Incoming Label MAP

NEW: MPLS Incoming Label Map

#Ahmed: Corrected

 

(as per https://tools.ietf.org/html/rfc3031#section-3.11 )

--

OLD: o  (Endpoint, Color) representing an SR policy [I.D. filsfils-spring-segment-routing-policy]

NEW: o  an SR policy [I.D.-ietf-spring-segment-routing]

 

(Otherwise, this would likely require a _Normative_ reference to I.D. filsfils-spring-segment-routing-policy which would significantly delay the RFC publication of this document. While [I.D.-ietf-spring-segment-routing is already in the RFC editor queue and does define a SR policy. )

#Ahmed: This has become rfc8402. I overlooked this one and I will make it refer to rfc8402 in version 16

 

--

OLD:

 

   o  (Prefix, Routing Instance, Topology, Algorithm), where a topology

      is identified by a set of links with metrics. For the purpose of

      incoming label collision resolution, the same numerical value

      SHOULD be used on all routers to identify the same set of links

      with metrics.

 

(It's not crystal clear what "numerical value" refers to, given the list (Prefix, Routing Instance, Topology, Algorithm))

             

NEW1:

   o  (Prefix, Routing Instance, Topology, Algorithm), where a topology

      is identified by a set of links with metrics. For the purpose of

      incoming label collision resolution, the same Topology numerical value

      SHOULD be used on all routers to identify the same set of links

      with metrics.

#Ahmed: I used this wording (thanks)

              

              

NEW2:

   o  (Prefix, Routing Instance, Topology, Algorithm). A Topology

      identifies a set of links with metrics. For the purpose of

      incoming label collision resolution, the same Topology numerical value

      SHOULD be used on all routers to identify the same set of links

      with metrics.

 

-----

§2.5.1

 

"       o All addresses are represented in 128 bits as follows

 

            . IPv6 address is encoded natively

 

            . IPv4 address is encoded in the most significant bits and

               the remaining bits are set to zero

 

       o All prefixes are represented by 128.

 

            . A prefix is encoded in the most significant bits and the

               remaining bits are set to zero.

 

            . The prefix length is encoded before the prefix"

                                  

                                  

                                  

"All prefixes are represented by 128."

128 what? Could be bits, but this does not fit with the addition of the prefix length.

 

"The prefix length is encoded before the prefix"

using a field of what size?

#Ahmed: I corrected this to be (128+8)

 

 

Do we (really) need 2 different encodings for prefix and address? Especially since the rest of the algorithm does not make the difference:

   "o  Encode the remaining set of FECs as follows

 

       o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length,

         Prefix, SR Algorithm, routing_instance_id, Topology)"

#Ahmed: It is just that conceptually an address and a prefix are different and they are usually handled quite differently by routing protocols

---

§2.5.2. Redistribution between Routing Protocol Instances

 

 

"   o  If the receiving instance's SRGB is the same as the SRGB of origin

      instance, THEN

 

       o the index is redistributed with the route

 

   o  Else

 

       o the index is not redistributed and if needed it is the duty of

         the receiving instance to allocate a fresh index relative to

         its own SRGB"

                       

With a strict interpretation of this rule, when one increases the size of the SRGB, all indexes from redistributed prefixes will be withdrawn because it's unlikely that we can guaranty that the change of both SRGB be atomic.

Could this be accommodated? e.g. by only using the SRBG below the index ? i.e SRGB [0;index] or just the mapped label in both SRGB?

#Ahmed: I think this is a very fine corner case. But I am open to any suggestion

---

§2.6

OLD:

In the general case, the ingress node may not have exactly have the

   same data of the receiving node, so the result may be different.

 

NEW:

In the general case, the ingress node may not have exactly the

   same data of the receiving node, so the result may be different.

#Ahmed: I used that wording

 

----

§2.10

 

OLD

   This document covers the calculation of outgoing label for the top

   label only. The case where outgoing label is not the top label and is

   part of a stack of labels that instantiates a routing policy or a

   traffic engineering tunnel is covered in other documents such as

   [I.D.filsfils-spring-segment-routing-policy].

  

This may be understood as requiring a _normative_ reference for [I.D.filsfils-spring-segment-routing-policy], which would significantly delay the RFC publication of this document.

 

Proposed NEW1:

   This document covers the calculation of outgoing label for the top

   label only. Other cases are out of scope of this document.

 

Or NEW2:

  This document covers the calculation of outgoing label for the top

   label only. The case where outgoing label is not the top label and is

   part of a stack of labels that instantiates a routing policy or a

   traffic engineering tunnel is out of scope of this document.

#Ahmed: I changed the wording a little bit such that [I.D.filsfils-spring-segment-routing-policy] is an example

-- 

§2.10.1

 

"   Suppose an MCC on a router "R0" determines that PUSH or CONTINUE

   operation is to be applied to an incoming packet whose active SID is

   the global SID "Si" ..."

  

 My undertanding is that "whose" in "whose active SID" refers to the the "incoming packet". This seems to imply that the incoming packet is (already) labeled.

- This does not match the example used in the following paregraph, where the incoming packet is IP.

 "An example of a method to determine the SID

   "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis-

   segment-routing-extensions] receives the prefix-SID "Si" sub-TLV

   advertised with prefix "P/m" in TLV 135 and the destination address

   of the incoming IPv4 packet is covered by the prefix "P/m"."

 - Also, you can't simply perform a PUSH on a received label packet. You first need to POP or SWAP the incoming label.

 

May be proposed NEW:

   Suppose an MCC on a router "R0" determines that a PUSH or CONTINUE

   operation is to be applied to an incoming packet, related to the global SID "Si" ...

#Ahmed: Modified the text as suggested

-----

§2.10.1

 

OLD: If the neighbor "N" does not support SR or "I" does not satisfy

      the inequality specified in Section 2.4 for the SRGB of the

      neighbor "N"

             

May be a more generic sentence:

 

NEW   If the neighbor "N" does not support SR or advertises a SRGB invalid or too small,

#Ahmed: Modified as suggested

 -----

§2.10.1

 

OLD:

       o If it is possible to send the packet towards the neighbor "N"

          using standard MPLS forwarding behavior as specified in

          {RFC3031] and [RFC3032], then forward the packet. The method

          by which a router decides whether it is possible to send the

          packet to "N" or not is beyond the scope of this document. For

          example, the router "R0" can use the downstream label

          determined by another MCC, such as LDP [RFC5036], to send the

          packet.

 

The fall back to LDP seems like a mandated behavior. If so, the behavior seems under-specified. In particular "out of scope of this document" does not seem like a valid argument.

#Ahmed: In general LDP is not mandated. The statement says use MPLS. How and what protocol is used to determine what to do with the incoming label(s) (if any) and what is (are) the outgoing label(s) is totally outside the scope of this document. 

 

Possible NEW:

"       o If this neighbor "N" advertises a valid label for the same FEC via another MCC (e.g. LDP [RFC5036]), then forward the packet to N, using the label advertised by this MCC.

 

----

2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for Local SIDs

 

  "A local SID on a router "R0" corresponds to a local label such as an

   IGP adj-SID. In such scenario, the outgoing label towards a next-hop

   "N" is determined by the MCC running on the router "R0"and the

   forwarding behavior for CONTINUE operation is identical to swap

   operation [RFC3032] on an MPLS label"

  

I'm not seeing a case where an IGP adj-SID would have "CONTINUE" as a forwarding behavior.

And the SR architecture requires a NEXT operation:

"      When a node binds an Adj-SID to a local data-link L, the node MUST

       install the following FIB entry:

 

      Incoming Active Segment: V

      Ingress Operation: NEXT

      Egress Interface: L"

 

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.4

 

A solution would be to simply remove "such as an IGP adj-SID"

#Ahmed: I agree and I removed adj-SID

---

§3 IGP Segment examples

 

This section, also useful, is quite long and not normative for this STD track doc. An option may be to move it to appendix.

Up to you.

#Ahmed: Agreed and moved to appendix

---

§3.1

 

"R2 is the next-hop along the shortest path towards R8. By applying

   the steps in Section 2.8 the local label downloaded to R1's FIB

   corresponding to the global SID index 8 is 1008 because the SRGB of

   R2 is [1000,5000] as shown in Figure 2."

  

 may be

OLD:  local label downloaded to R1's FIB

NEW:  local outgoing label downloaded to R1's FIB

 (because I would assume that by default, label downloaded in the FIB is probably the incomig label one)

#Ahmed Changed "local" to "outgoing"

 --

OLD: owned by the R8

NEW1: OLD: owned by R8

NEW2: OLD: owned by the node R8

#Ahmed: Done

--

"The packet arrives at router R2. Because the top label 1008

   corresponds to the IGP SID "8", which is the prefix-SID attached to

   the prefix 192.0.2.8/32 owned by the R8, then the instruction

   associated with the SID is "forward the packet using all ECMP/UCMP

   interfaces and all ECMP/UCMP next-hop(s) along the shortest path

   towards R8". "

 

IGP prefix-SID are typically forwarded along the ECMP shortest path. I'm not sure where "UCMP" is coming from. Also "along the shortest path" seems to be incompatible with UCMP.

#Ahmed: I changed the wording to "shortest/useable"

--

"Because R3

   is the penultimate hop, R3 applies NEXT operation then sends the

   packet to R8."

 

   "penultimate hop" is a required but not sufficient reason. You are assuming that R8 asked for PHP, but I'm not seeing this assumption stated in the text.

#Ahmed:
I changed to wording to use  "assume"

---

"The NEXT operation results in popping the outer label

   and sending the packet as a pure IPv4 packet to R8. The

 

   In conclusion, "

  

OLD: The

NEW:

#Ahmed: In many places, I refer to each operation using "the".

---

§3.2 & §3.3 & §3.4 & §3.5

" Using the

   calculation techniques specified in Section 2.10 and 2.11 the

   resulting label stack starting from the topmost label is <1002, 9001,

   1008>."

  

Actually section 2.10 only defines the calculation technique for the top label:

 

   "This document covers the calculation of outgoing label for the top

   label only. The case where outgoing label is not the top label and is

   part of a stack of labels that instantiates a routing policy or a

   traffic engineering tunnel is covered in other documents such as

   [I.D.filsfils-spring-segment-routing-policy]."

   https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13#section-2.10

  

   Hence this document does not define the behavior for this example 2. You would need to either extend this doc to cover the push of a stack of label/SID or remove these examples 2, 3, 4, 5

#Ahmed Done

----

[RFC8174] to be added to normative references.

#Ahmed: Done

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

 

Hello Working Group,
    
This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review.
    
Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*.
 
As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG.
Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd. Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
_________________________________________________________________________________________________________________________
 
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.

--------------BC08951BF1A31DCA8A684B17-- From nobody Sat Oct 27 15:04:16 2018 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 C0E641276D0; Sat, 27 Oct 2018 15:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rwszWNzed4Ew; Sat, 27 Oct 2018 15:04:08 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 76DE81274D0; Sat, 27 Oct 2018 15:04:08 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id i4-v6so2099384pgq.9; Sat, 27 Oct 2018 15:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=lwUYkA8MxhKoq+LUMWZD21vJyHt8Orw5JZ7Rf1ldpew=; b=DhwRbbxOSERLdHNAIfp+P4Bh0mpflPrtbUc+REBYkalUod+7tZWJ+uu7VOxp9n9G+k hpBjyD1Entvn18bj32iuOdSq6jZZM6othfLzuxUQoKTV5kHb32lK0UOVL2NFuld91Roc i0hK2B+fheBo6SvcrOHQ9lPLIhvSLNNZT2NoLty7ScuShFmTyTymPm/xzOx5/BfPI+TR P6d1fAAeHImFKtCPOwcESc4nGWgJWQwzmx6mXmnIgEJJcu5JOJ7CssIL2w7J59tltY+/ h04vQPDfMGFw5EMkRBiRkViw+Eg6QOfIaomfpmpiFANNepaeSc+WwcOyZxwEnBaNLTdf wiKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lwUYkA8MxhKoq+LUMWZD21vJyHt8Orw5JZ7Rf1ldpew=; b=q4oaVA6uF31KJ9uKk22hpDi61mtVKPF3lLYDXDgWcnkXSqqYfo4gbrfOxCz8UfAGOx wHG2ThxYVkOTA2EVYz9uTXQVqgQ69tr2jo468h0GCL07dF30V/T6RTI61yRCkzjBPOv/ ruRKDZyPdg+9D7OSRjztBTklTczh6Inda8C3t1oPyRAIkggRRP2ZShu3sil6k3RaPBiZ vP38r6Qle24lx4ve9cmE97nwZNKn2mlTA91Ea+80vQGMxqkXPOhO2c82fs4hS5740Unn VjPrxrH2zzv4SrUZE15M9vA4qVwezF/4o60PVCM9LFZClyjsc14nNhEIQYKwg43c8W5N Vxhw== X-Gm-Message-State: AGRZ1gIv4FdHMeCRW+l/gG/x2eANUJD4dF5LwlSw6ZfBqdj+Xz6ak1eV q7CHOJW/GOGzPPaLpdjDx2hRi6rU X-Google-Smtp-Source: AJdET5eVpDG7vsNvabaMuaj4I4DJ2le0jYBDor/q8CNYaAL0arvp27aRj/g1a+MPt4uxy2UXjZ8j3Q== X-Received: by 2002:a65:6295:: with SMTP id f21-v6mr8406561pgv.167.1540677847721; Sat, 27 Oct 2018 15:04:07 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id x23-v6sm16524957pfh.56.2018.10.27.15.04.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 15:04:07 -0700 (PDT) To: Chris Bowers , SPRING WG List , bruno.decraene@orange.com Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: Date: Sat, 27 Oct 2018 15:04:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------424842803700142EAC7A3435" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 22:04:14 -0000 This is a multi-part message in MIME format. --------------424842803700142EAC7A3435 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks a lot for the examples. Version 15 of the document incorporates all of the examples in the appendix (all examples have been moved to appendix), except the examples where - Incoming label=1009 - Incoming label=1018 - Incoming label=1019 - Binding-SID label=1023 See my comments at "#Ahmed" under each of these 4 examples I have a response for your comment right after the examples that use  "Incoming label=1008" and "Incoming label=1015" Ahmed On 6/8/18 11:14 AM, Chris Bowers wrote: > SPRING WG, > > I generally support publication of > draft-ietf-spring-segment-routing-mpls. However, I think > that the text in sections 2.5 and 2.6 (on incoming label collisions) > needs some work before publication. This text was added to > the draft a few months ago, and has not gotten much review > from the WG as a whole. The review and proposed text below > focuses on these sections. > > As I understand the current text of the draft, the general > approach to resolving incoming label collisions seems > well-reasoned and complete.  However, it is possible that > my interpretation of these tie-breaking rules is > not what the authors intended. > > I'd like to propose the examples below to be included > in the draft to help clarify the tie-breaking rules > for incoming label collisions described in section 2.5. > I have highlighted several cases in these examples, > where I think the rules in section 2.5 need > to be clarified in order to unambiguously determine > the winning FEC in an example. > > It may also be the case that the authors or other > WG participants will disagree with the interpretation of the > rules used to choose a winning FEC in some of these > examples.  In that case, we should discuss > what is the correct interpretation, and clarify the > text in the draft to make the correct interpretation > clear. > > > Incoming label collision examples > ========= > > Node A > OSPF default admin distance for implementation=50 > ISIS default admin distance for implementation=60 > > ========= > Example incoming label conflict for label=1005 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.5/32 > with index=5 > OSPF SRGB on node A = [1000,1999] > Incoming label=1005 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.105/32 > with index=5 > ISIS SRGB on node A = [1000,1999] > Incoming label=1005 > > FEC1 and FEC2 both use dynamic SID assignment.  Since neither of > the FEC types is SR Policy, we use the default admin distances of 50 > and 60 to break the tie.  So FEC1 wins. > > ========= > Example incoming label conflict for label=1006 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.6/32 > with index=6 > OSPF SRGB on node A = [1000,1999] > Incoming label=1006 > > FEC2) > ISIS adjacency sid advertisement from node A with label=1006 > Incoming label=1006 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC1 and FEC2 both use dynamic SID assignment.  Since neither of > the FEC types is SR Policy, we use the default admin distances of 50 > and 60 to break the tie.  So FEC1 wins. > > ========= > Example incoming label conflict for label=1007 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.7/32 > with index=7 > OSPF SRGB on node A = [1000,1999] > Incoming label=1007 > > FEC2) > ISIS adjacency sid advertisement from node A with label=1007 > Incoming label=1007 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID > assignment. So FEC2 wins. > > ========= > Example incoming label conflict for label=1008 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.8/32 > with index=8 > OSPF SRGB on node A = [1000,1999] > Incoming label=1008 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint = 192.0.2.208, color = 100, SID-List = > Binding-SID label = 1008 > > FEC1 and FEC2 both use dynamic SID assignment. > Since one of the FEC types is SR Policy, default admin > distance is not used to break the tie. > /* The text in Section 2.5.1 needs to be clarified to specify > whether SR Policy always loses or always wins in this case. */ #Ahmed: Section 2.5.1 in page 9 clearly says      The default FEC administrative distance order starting from the      lowest value SHOULD be and then lists the FECs Hence the list specifies the default admin distance starting from the "lowest" The Binding SID appears in the 2nd sub-bullet of the second bullet. Hence the binding SID of a policy receives the maximal default admin distance. Hence FEC1 should win I adapted this example so that it shows the the default admin distance of a binding SID is always higher than the default admin distances of other FECs > > ========= > Example incoming label conflict for label=1009 on node A > > FEC1) > OSPF adjacency sid advertisement by node A with label=1009 > Incoming label=1009 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC2) > ISIS adjacency sid advertisement by node A with label=1009 > Incoming label=1009 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC1 and FEC2 both use explicit SID assignment.  This kind of > incoming label collision should never occur, since an > implement of explicit SID assignment MUST guarantee > collision freeness on the same router. #Ahmed The example is not clear. If the adjacency SIDs for ISIS and OSPF are out of the same interface towards the same neighbor, then there is no collision If they are out of different interfaces and/or towards different neighbors, then this is an example of a faulty implementation. Implementation must not allow multiple MCCs on the same box to assign the same local label to two different FECs Although assigning the same label to more than one FEC is a problem from the MPLS point of view, in version 15,  I added a  paragraph in page 8 to prohibit that for completeness > > ======== > Example incoming label conflict for label=1010 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.110/32 > with index=10 > ISIS SRGB on node A = [1000,1999] > Incoming label=1010 > > FEC2) > ISIS adjacency sid advertisement by node A with label=1010 > Incoming label=1010 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  FEC1 has FEC type > code-point=120, while FEC2 has FEC type code-point=130. > Therefore, FEC1 wins. > > ========= > Example incoming label conflict for label=1011 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.111/32 > with index=11 > ISIS SRGB on node A = [1000,1999] > Incoming label=1011 > > FEC2) > ISIS prefix sid advertisement from node C for 2001:DB8:1000::11/128 > with index=11 > ISIS SRGB on node A = [1000,1999] > Incoming label=1011 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Since IPv4 is > preferred over IPv6, FEC1 wins. > > ========= > Example incoming label conflict for label=1012 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.112/32 > with index=12 > ISIS SRGB on node A = [1000,1999] > Incoming label=1012 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.128/30 > with index=12 > ISIS SRGB on node A = [1000,1999] > Incoming label=1012 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Both are IPv4 address > family, so we compare prefix length.  FEC1 has prefix length=32, > and FEC2 has prefix length=30, so FEC2 wins. > > ========= > Example incoming label conflict for label=1013 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.113/32 > with index=13 > ISIS SRGB on node A = [1000,1999] > Incoming label=1013 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.213/32 > with index=13 > ISIS SRGB on node A = [1000,1999] > Incoming label=1013 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Both are IPv4 address > family, so we compare prefix length.  Prefix lengths are the same, > so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins. > > ========= > Example incoming label conflict for label=1014 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.114/32 > with index=14 > Routing Instance ID = 1000 > ISIS SRGB on node A = [1000,1999] > Incoming label=1014 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.114/32 > with index=14 > Routing Instance ID = 2000 > ISIS SRGB on node A = [1000,1999] > Incoming label=1014 > > These two FECs match all the way through the prefix length and prefix. > So Routing Instance ID breaks the tie, with FEC1 winning. > > ========= > Example incoming label conflict for label=1015 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.115/32 > with index=15 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > ISIS SRGB on node A = [1000,1999] > Incoming label=1015 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.115/32 > with index=15 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 40 > ISIS SRGB on node A = [1000,1999] > Incoming label=1015 > > These two FECs match all the way through the prefix length, prefix, and > Routing Instance ID.  We compare ISIS Multi-topology ID, so FEC2 wins. > > /* There appears to be a typo in section 2.5.1, with two different > orderings shown for a prefix-based FEC: > Prefix, Routing Instance, Topology, Algorithm > and > (Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology) > This needs to be corrected. */ #Ahmed: This is not a mistake. This bullet illustrates how to encode a prefix and hence it separates the prefix into  its two components: "prefix length" and "prefix" > > ========= > Example incoming label conflict for label=1016 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.116/32 > with index=16 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > SR algorithm = 0 > ISIS SRGB on node A = [1000,1999] > Incoming label=1016 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.116/32 > with index=16 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > SR algorithm = 22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1016 > > These two FECs match all the way through the prefix length, prefix, and > Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so > FEC1 wins. > > ========= > Example incoming label conflict for label=1017 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.117/32 > with index=17 > ISIS SRGB on node A = [1000,1999] > Incoming label=1017 > > FEC2) > ISIS mapping server advertisement (SID/Label Binding TLV) from node D: > Range=100, Prefix = 203.0.113.1/32 > This mapping server advertisment generates 100 mappings, one of which > maps 203.0.113.17/32 to index=17. > ISIS SRGB on node A = [1000,1999] > Incoming label=1017 > > The fact that FEC1 comes from a normal prefix sid advertisement and > FEC2 is generated from a mapping server advertisement is not > used as a tie-breaking parameter. Both FECs use dynamic SID assignment, > are from the same MCC, have the same FEC type code-point=120. Their prefix > lengths are the same as well.  FEC2 wins based on lower numerical > prefix value, > since 203.0.113.17 is less than 203.0.113.117. > > ========= > Example incoming label conflict for label=1018 on node A > > FEC1) > ISIS IPv4 adjacency sid advertisement from node A with label=1018 > corresponding to next-hop interface address=192.0.2.100, outgoing > interface ID=5 > Incoming label=1018 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC2) > ISIS IPv6 adjacency sid advertisement from node A with label=1018 > corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6. > Incoming label=1018 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > Both FECs use dynamic SID assignment, are from the same MCC, > and have the same FEC type code-point=130.  FEC1 wins > because IPv4 address family is preferred over IPv6. #Ahmed: This is another example of a faulty implementation because the implementation of ISIS must not allow allocating the same local label to two different adj-SIDs on the same node A > > ========= > Example incoming label conflict for label=1019 on node A > > FEC1) > ISIS IPv4 adjacency sid advertisement from node A with label=1019 > corresponding to next-hop interface address=192.0.2.220, outgoing > interface ID=7 > Incoming label=1019 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC2) > ISIS IPv4 adjacency sid advertisement from node A with label=1019 > corresponding to next-hop interface address=192.0.2.230, outgoing > interface ID=8 > Incoming label=1019 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > Both FECs use dynamic SID assignment, are from the same MCC, > and have the same FEC type code-point=130. Both FECs have to > same address family.  FEC1 wins based on having the lowest next-hop > interface address. > > /* It is not clear how to construct an example that > would result in using the outgoing interface ID as a tie-breaker. > It would be useful to understand why this is and clarify > it in the text. */ #Ahmed: This is a third example of a faulty implementation because the implementation of ISIS must not allow allocating the same local label to two different adj-SIDs on the same box > ========= > Example incoming label conflict for label=1020 on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=2001:DB8:3000::100, color=100, SID-List= > Binding-SID label=1020 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.60, color=100, SID-List= > Binding-SID label=1020 > > The FECs match through the tie-breaks up to and including > having the same FEC type code-point=140. > FEC2 wins based on IPv4 address family being preferred > over IPv6. > > ========= > Example incoming label conflict for label=1021 on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.70, color=100, SID-List= > Binding-SID label=1021 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.71, color=100, SID-List= > Binding-SID label=1021 > > The FECs match through the tie-breaks up to and including > having the same address family. FEC1 wins by having the > lower numerical endpoint address value. > > ========= > > I'd like to propose the examples below to be included > in the draft to help clarify section 2.6 > (currently entitled "Outgoing Label Collision"). > > > Examples of the Effect Incoming Label Collision on Outgoing Label > Programming > ==================================== > > Example of effect of incoming label collision for label=1022 > on outgoing label programming on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.122/32 > with index=22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1022 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.222/32 > with index=22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1022 > > FEC1 wins based on lowest numerical prefix value.  This means that node A > installs a transit MPLS forwarding entry to SWAP incoming label=1022, > with outgoing label N, > and use outgoing interace I. N is determined by the index associated > with FEC1 (index=22) and > the SRGB advertised by the next-hop node on the shortest path to reach > 203.0.113.122/32 . > > Node A will generally also install an ingress MPLS forwarding entry > corresponding to FEC1 for > incoming prefix=203.0.113.122/32 pushing > outgoing label N, and using outgoing interace I. > > The rule in section 2.6 means that node A MUST NOT install an ingress > MPLS forwarding entry > corresponding to FEC2 ( which would be for incoming > prefix=203.0.113.222/32 ). > ======== > > Example of effect of incoming label collision for label=1023 > on outgoing label programming on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.80, color=100, SID-List= > Binding-SID label=1023 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.81, color=100, SID-List= > Binding-SID label=1023 > > FEC1 wins by having the lower numerical endpoint address value. This > means that node A > installs a transit MPLS forwarding entry to SWAP incoming label=1023, > with outgoing labels > and outgoing interface determined by the SID-List for FEC1. > Node A will generally also install an ingress MPLS forwarding entry > corresponding to FEC1 for > incoming prefix=192.0.2.80/32 pushing outgoing > labels and using the outgoing interface > determined by the SID-List for FEC1. > > The rule in section 2.6 means that node A MUST NOT install an ingress > MPLS forwarding entry > corresponding to FEC2 ( which would be for incoming > prefix=192.0.2.81/32 ). #Ahmed It seems like there is a misunderstanding here. A policy is identified by a color and an IP address. What gets installed in the FIB is the MPLS label representing the binding SID. A packet arriving with the top label equal to the binding SID gets forwarded into the policy. The endpoint and color are unique identifier of the policy on the box The IP address is the address of an endpoint, NOT a prefix. So the instantiation or advertisement of a policy does not result in installing any prefixes in FIB > > ======== > > General comment: > > section 2.6 title: > existing: > Outgoing Label Collision: > proposed: > Effect of Incoming Label Collision on Outgoing Label Programming : > -------------------------------------- > > > Thanks, > Chris > > > On Thu, May 24, 2018 at 12:14 PM, > wrote: > > Hello Working Group, > > This email starts a Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-13 [1] which is considered > mature and ready for a final working group review. > > Please read this document if you haven't read the most recent > version yet, and send your comments to the list, no later than > *June 08*. > > As a reminder, this document had already passed a WGLC more than a > year ago on version -06 [2], had been sent to the AD but then > returned to the WG. > > Since then, the document has significantly changed, so please read > it again. In particular, it now includes the resolution in case of > incoming label collision. Hence it killed > draft-ietf-spring-conflict-resolution. > > Both co-chairs co-author this document, hence: > > - Shraddha has agreed to be the document shepherd.. Thank you > Shraddha. > > - Martin, our AD, has agreed to evaluate the WG consensus. > > Thank you, > > Bruno, Rob > > [1] > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 > > > [2] > https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y > > > _________________________________________________________________________________________________________________________ > > 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 > > > --------------424842803700142EAC7A3435 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks a lot for the examples.

Version 15 of the document incorporates all of the examples in the appendix (all examples have been moved to appendix), except the examples where
- Incoming label=1009
- Incoming label=1018
- Incoming label=1019
- Binding-SID label=1023

See my comments at "#Ahmed" under each of these 4 examples


I have a response for your comment right after the examples that use  "Incoming label=1008" and "Incoming label=1015"


Ahmed



On 6/8/18 11:14 AM, Chris Bowers wrote:
SPRING WG,

I generally support publication of
draft-ietf-spring-segment-routing-mpls. However, I think
that the text in sections 2.5 and 2.6 (on incoming label collisions)
needs some work before publication. This text was added to
the draft a few months ago, and has not gotten much review
from the WG as a whole. The review and proposed text below
focuses on these sections.

As I understand the current text of the draft, the general
approach to resolving incoming label collisions seems
well-reasoned and complete.  However, it is possible that
my interpretation of these tie-breaking rules is
not what the authors intended.

I'd like to propose the examples below to be included
in the draft to help clarify the tie-breaking rules
for incoming label collisions described in section 2.5.
I have highlighted several cases in these examples,
where I think the rules in section 2.5 need
to be clarified in order to unambiguously determine
the winning FEC in an example.

It may also be the case that the authors or other
WG participants will disagree with the interpretation of the
rules used to choose a winning FEC in some of these
examples.  In that case, we should discuss
what is the correct interpretation, and clarify the
text in the draft to make the correct interpretation
clear.


Incoming label collision examples
=========

Node A
OSPF default admin distance for implementation=50
ISIS default admin distance for implementation=60

=========
Example incoming label conflict for label=1005 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.5/32 with index=5
OSPF SRGB on node A = [1000,1999]
Incoming label=1005

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.105/32 with index=5
ISIS SRGB on node A = [1000,1999]
Incoming label=1005

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1006 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.6/32 with index=6
OSPF SRGB on node A = [1000,1999]
Incoming label=1006

FEC2)
ISIS adjacency sid advertisement from node A with label=1006
Incoming label=1006
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1007 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.7/32 with index=7
OSPF SRGB on node A = [1000,1999]
Incoming label=1007

FEC2)
ISIS adjacency sid advertisement from node A with label=1007
Incoming label=1007
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
assignment. So FEC2 wins.

=========
Example incoming label conflict for label=1008 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.8/32 with index=8
OSPF SRGB on node A = [1000,1999]
Incoming label=1008

FEC2)
SR Policy advertisement from controller to node A
Endpoint = 192.0.2.208, color = 100, SID-List = <S1, S2>
Binding-SID label = 1008

FEC1 and FEC2 both use dynamic SID assignment. 
Since one of the FEC types is SR Policy, default admin
distance is not used to break the tie. 
/* The text in Section 2.5.1 needs to be clarified to specify
whether SR Policy always loses or always wins in this case. */
#Ahmed:
Section 2.5.1 in page 9 clearly says
     The default FEC administrative distance order starting from the
     lowest value SHOULD be
and then lists the FECs
Hence the list specifies the default admin distance starting from the
"lowest"
The Binding SID appears in the 2nd sub-bullet of the second
bullet. Hence the binding SID of a policy receives the maximal default
admin distance. Hence FEC1 should win
I adapted this example so that it shows the the default admin distance
of a binding SID is always higher than the default admin distances of
other FECs


=========
Example incoming label conflict for label=1009 on node A

FEC1)
OSPF adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC2)
ISIS adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 and FEC2 both use explicit SID assignment.  This kind of
incoming label collision should never occur, since an
implement of explicit SID assignment MUST guarantee
collision freeness on the same router.
#Ahmed
The example is not clear. If the adjacency SIDs for ISIS and OSPF are
out of the same interface towards the same neighbor, then there is no
collision
If they are out of different interfaces and/or towards different
neighbors, then this is an example of a faulty
implementation. Implementation must not allow multiple MCCs on the
same box to assign the same local label to two different FECs

Although assigning the same label to more than one FEC is a problem from the MPLS point of view, in version 15,  I added a  paragraph in page 8 to prohibit that for completeness

========
Example incoming label conflict for label=1010 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.110/32 with index=10
ISIS SRGB on node A = [1000,1999]
Incoming label=1010

FEC2)
ISIS adjacency sid advertisement by node A with label=1010
Incoming label=1010
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  FEC1 has FEC type
code-point=120, while FEC2 has FEC type code-point=130.
Therefore, FEC1 wins. 

=========
Example incoming label conflict for label=1011 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.111/32 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC2)
ISIS prefix sid advertisement from node C for 2001:DB8:1000::11/128 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Since IPv4 is
preferred over IPv6, FEC1 wins.

=========
Example incoming label conflict for label=1012 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.112/32 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.128/30 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  FEC1 has prefix length=32,
and FEC2 has prefix length=30, so FEC2 wins.

=========
Example incoming label conflict for label=1013 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.113/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.213/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  Prefix lengths are the same,
so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins.

=========
Example incoming label conflict for label=1014 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.114/32 with index=14
Routing Instance ID = 1000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.114/32 with index=14
Routing Instance ID = 2000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

These two FECs match all the way through the prefix length and prefix.
So Routing Instance ID breaks the tie, with FEC1 winning.

=========
Example incoming label conflict for label=1015 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 40
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID.  We compare ISIS Multi-topology ID, so FEC2 wins.

/* There appears to be a typo in section 2.5.1, with two different
orderings shown for a prefix-based FEC:
Prefix, Routing Instance, Topology, Algorithm
and
(Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology)
This needs to be corrected. */
#Ahmed:
This is not a mistake. This bullet illustrates how to encode a
prefix and hence it separates the prefix into  its two components:
"prefix length" and "prefix"

=========
Example incoming label conflict for label=1016 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 0
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 22
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so
FEC1 wins.

=========
Example incoming label conflict for label=1017 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.117/32 with index=17
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

FEC2)
ISIS mapping server advertisement (SID/Label Binding TLV) from node D:
Range=100, Prefix = 203.0.113.1/32
This mapping server advertisment generates 100 mappings, one of which
maps 203.0.113.17/32 to index=17.
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

The fact that FEC1 comes from a normal prefix sid advertisement and
FEC2 is generated from a mapping server advertisement is not
used as a tie-breaking parameter. Both FECs use dynamic SID assignment,
are from the same MCC, have the same FEC type code-point=120. Their prefix
lengths are the same as well.  FEC2 wins based on lower numerical prefix value,
since 203.0.113.17 is less than 203.0.113.117.

=========
Example incoming label conflict for label=1018 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1018
corresponding to next-hop interface address=192.0.2.100, outgoing interface ID=5
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv6 adjacency sid advertisement from node A with label=1018
corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6.
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130.  FEC1 wins
because IPv4 address family is preferred over IPv6.

#Ahmed:
This is another example of a faulty implementation because the
implementation of ISIS must not allow allocating the same local label
to two different adj-SIDs on the same node A


=========
Example incoming label conflict for label=1019 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.220, outgoing interface ID=7
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.230, outgoing interface ID=8
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130. Both FECs have to
same address family.  FEC1 wins based on having the lowest next-hop
interface address. 

/* It is not clear how to construct an example that
would result in using the outgoing interface ID as a tie-breaker.
It would be useful to understand why this is and clarify
it in the text. */
#Ahmed:
This is a third example of a faulty implementation because the
implementation of ISIS must not allow allocating the same local label
to two different adj-SIDs on the same box
=========
Example incoming label conflict for label=1020 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>
Binding-SID label=1020

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>
Binding-SID label=1020

The FECs match through the tie-breaks up to and including
having the same FEC type code-point=140.
FEC2 wins based on IPv4 address family being preferred
over IPv6.  

=========
Example incoming label conflict for label=1021 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2>
Binding-SID label=1021

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4>
Binding-SID label=1021

The FECs match through the tie-breaks up to and including
having the same address family. FEC1 wins by having the
lower numerical endpoint address value.

=========

I'd like to propose the examples below to be included
in the draft to help clarify section 2.6
(currently entitled "Outgoing Label Collision").


Examples of the Effect Incoming Label Collision on Outgoing Label Programming
====================================

Example of effect of incoming label collision for label=1022
on outgoing label programming on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.122/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.222/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC1 wins based on lowest numerical prefix value.  This means that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1022, with outgoing label N,
and use outgoing interace I. N is determined by the index associated with FEC1 (index=22) and
the SRGB advertised by the next-hop node on the shortest path to reach
203.0.113.122/32.

Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for
incoming prefix=203.0.113.122/32 pushing outgoing label N, and using outgoing interace I.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=203.0.113.222/32). 
========

Example of effect of incoming label collision for label=1023
on outgoing label programming on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>
Binding-SID label=1023

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4>
Binding-SID label=1023

FEC1 wins by having the lower numerical endpoint address value. This means that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1023, with outgoing labels
and outgoing interface determined by the SID-List for FEC1.
Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for
incoming prefix=192.0.2.80/32 pushing outgoing labels and using the outgoing interface
determined by the SID-List for FEC1.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=192.0.2.81/32). 
#Ahmed
It seems like there is a misunderstanding here. A policy is identified by a color and an IP address. What gets installed in the FIB is the MPLS label representing the binding SID. A packet arriving with the top label equal to the binding SID gets forwarded into the policy. The endpoint and color are unique identifier of the policy on the box
The IP address is the address of an endpoint, NOT a prefix. So the instantiation or advertisement of a policy does not result in installing any prefixes in FIB

========

General comment:

section 2.6 title:
existing:
Outgoing Label Collision:
proposed:
Effect of Incoming Label Collision on Outgoing Label Programming :
--------------------------------------


Thanks,
Chris


On Thu, May 24, 2018 at 12:14 PM, <bruno.decraene@orange.com> wrote:
Hello Working Group,
    
This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review.
    
Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*.
 
As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG.
Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd.. Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
_________________________________________________________________________________________________________________________

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



--------------424842803700142EAC7A3435-- From nobody Sat Oct 27 15:24:31 2018 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 CC3D0130DDA; Sat, 27 Oct 2018 15:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gzeSsS3-gUCx; Sat, 27 Oct 2018 15:24:26 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 D160C126F72; Sat, 27 Oct 2018 15:24:25 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id t6-v6so2051115plo.9; Sat, 27 Oct 2018 15:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=11JntZbUHarDaW6c3pz3Cyu4iUUbc61nbkkK1ZbTV7o=; b=GEWzYItxOLQd2EAk2H6SXFVRWEhJK/6K42Qb3Yz4r9zD/xb525lSUSpjJ8GtVgdwca kiQFWgj74Gv/sLcQbbCWH42qmd4vusonWZ2cflpGQz9dxGOeVjupMdfdIhr8bmURfVHL c7PCSdHXHqKR91JxgZj1uKe5YzLoTrCoZEHYXt/eofKL1DVIttEmDFrR219bfewEUT8+ sk7AJbADASJ7Zy+T26u6uM2l0XBMuZl19yQJCjAO2QCowswc03CbF57THJzHm6cyRrSt 3NBecAeqrCDYUcRoGIbZqYNqhmT8kiEZkxuu33CIPs/USdNB8v/szVV2J0AKV1TRBgFq ALkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=11JntZbUHarDaW6c3pz3Cyu4iUUbc61nbkkK1ZbTV7o=; b=tBEWOe4zTU6T4ZkN1MA4lkXE1HhdUrW+iGr9Cnhm/DTqKSRfRelFGRGicx9rEWvO84 YV+2MOznFhRsMVRNBh8M+/cO4re4FptWV6v5h4P5RXuT8agOsEv/UYoz09wMeolPtkqe z/0Uxs84ScLsnKz0ynQhqgX6MqzhkqpNTjvFQ+xnPK3GLmbwbVqxNJDbO/mxR+n36KI1 miqkbfQEz5QxgdwuxIrz//egyoS4Wu11bBzt0g80PbPabSZ0YMzlxoP1BFmsjqHL6Yvg GeutCOBrB6KnjN1OesKPbhG80UI7f5EndQoH1zn6w1Lwen+QkYjbLTEVGkUALjujR/+j G/+A== X-Gm-Message-State: AGRZ1gJ0LdlXRHuBZGYuw95hvMCPzkdoI6l09kVvY15ZCMcgn+VQ9ltm VlMRwFDjG9d0uaajoGVUa24= X-Google-Smtp-Source: AJdET5ez2mjDvKspJGfAsMxqCwJgCQE1hWffgjyH25EbcoLdeaUbe/m8PMB2r4X9/dBNWfdK64HTYg== X-Received: by 2002:a17:902:4383:: with SMTP id j3-v6mr8752386pld.265.1540679065171; Sat, 27 Oct 2018 15:24:25 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id l2-v6sm15654431pgp.20.2018.10.27.15.24.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 15:24:24 -0700 (PDT) To: Przemyslaw Krol , spring@ietf.org Cc: Bruno Decraene , draft-ietf-spring-segment-routing-mpls@ietf.org, chrisbowers.ietf@gmail.com References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: Date: Sat, 27 Oct 2018 15:24:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------037EA0EDF97C787972A107D8" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 22:24:30 -0000 This is a multi-part message in MIME format. --------------037EA0EDF97C787972A107D8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks a for the comments Version 15 of the draft addresses your comments. See my comments below "#Ahmed" On 6/9/18 12:01 AM, Przemyslaw Krol wrote: > Greetings, > > Few minor, cosmetic/editorial suggestions: > > 2.5. Incoming Label Collision > [...] > *(Endpoint, Color)* representing an SR policy [I.D. > filsfils-spring-segment-routing-policy] > > (Color, Endpoint) is the ordering used by the policy draft. If the > decision is to correct it, there is few references in the draft > #Ahmed: It does not matter from the point of view of label collision > 2.5.1. Tie-breaking Rules > [...] >        o The Color ID is encoded using *16 bits* > * > * > should be 32 bits > (https://tools.ietf.org/html/rfc5512#section-4.3.1 && > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-00#section-2.1) #Ahmed: Modified as suggested > > > 2.6. Outgoing Label Collision > [...] > In the general case, the ingress node may not have exactly *have* the > same data of the receiving node #Ahmed Corrected > > 2.7. PUSH, CONTINUE, and NEXT > PUSH, NEXT, and CONTINUE are operations applied by the forwarding plan*e*. > [...] > #Ahmed: Corrected > 2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs > [...] > an IGP with SR extensions *[*I-D.ietf-isis-segment-routing-extensions, > I-D.ietf-ospf-segment-routing-extensions] > > ^^^ missing '[' or alternatively both references should be enclosed in > their own [] #Ahmed: Corrected > > > thanks, > pk > > On Fri, Jun 8, 2018 at 11:14 AM Chris Bowers > > wrote: > > SPRING WG, > > I generally support publication of > draft-ietf-spring-segment-routing-mpls. However, I think > that the text in sections 2.5 and 2.6 (on incoming label collisions) > needs some work before publication. This text was added to > the draft a few months ago, and has not gotten much review > from the WG as a whole. The review and proposed text below > focuses on these sections. > > As I understand the current text of the draft, the general > approach to resolving incoming label collisions seems > well-reasoned and complete.  However, it is possible that > my interpretation of these tie-breaking rules is > not what the authors intended. > > I'd like to propose the examples below to be included > in the draft to help clarify the tie-breaking rules > for incoming label collisions described in section 2.5. > I have highlighted several cases in these examples, > where I think the rules in section 2.5 need > to be clarified in order to unambiguously determine > the winning FEC in an example. > > It may also be the case that the authors or other > WG participants will disagree with the interpretation of the > rules used to choose a winning FEC in some of these > examples.  In that case, we should discuss > what is the correct interpretation, and clarify the > text in the draft to make the correct interpretation > clear. > > > Incoming label collision examples > ========= > > Node A > OSPF default admin distance for implementation=50 > ISIS default admin distance for implementation=60 > > ========= > Example incoming label conflict for label=1005 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.5/32 > with index=5 > OSPF SRGB on node A = [1000,1999] > Incoming label=1005 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.105/32 > with index=5 > ISIS SRGB on node A = [1000,1999] > Incoming label=1005 > > FEC1 and FEC2 both use dynamic SID assignment.  Since neither of > the FEC types is SR Policy, we use the default admin distances of 50 > and 60 to break the tie.  So FEC1 wins. > > ========= > Example incoming label conflict for label=1006 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.6/32 > with index=6 > OSPF SRGB on node A = [1000,1999] > Incoming label=1006 > > FEC2) > ISIS adjacency sid advertisement from node A with label=1006 > Incoming label=1006 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC1 and FEC2 both use dynamic SID assignment.  Since neither of > the FEC types is SR Policy, we use the default admin distances of 50 > and 60 to break the tie.  So FEC1 wins. > > ========= > Example incoming label conflict for label=1007 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.7/32 > with index=7 > OSPF SRGB on node A = [1000,1999] > Incoming label=1007 > > FEC2) > ISIS adjacency sid advertisement from node A with label=1007 > Incoming label=1007 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID > assignment. So FEC2 wins. > > ========= > Example incoming label conflict for label=1008 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100..8/32 > with index=8 > OSPF SRGB on node A = [1000,1999] > Incoming label=1008 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint = 192.0.2.208, color = 100, SID-List = > Binding-SID label = 1008 > > FEC1 and FEC2 both use dynamic SID assignment. > Since one of the FEC types is SR Policy, default admin > distance is not used to break the tie. > /* The text in Section 2.5.1 needs to be clarified to specify > whether SR Policy always loses or always wins in this case. */ > > ========= > Example incoming label conflict for label=1009 on node A > > FEC1) > OSPF adjacency sid advertisement by node A with label=1009 > Incoming label=1009 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC2) > ISIS adjacency sid advertisement by node A with label=1009 > Incoming label=1009 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC1 and FEC2 both use explicit SID assignment.  This kind of > incoming label collision should never occur, since an > implement of explicit SID assignment MUST guarantee > collision freeness on the same router. > > ======== > Example incoming label conflict for label=1010 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.110/32 > with index=10 > ISIS SRGB on node A = [1000,1999] > Incoming label=1010 > > FEC2) > ISIS adjacency sid advertisement by node A with label=1010 > Incoming label=1010 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  FEC1 has FEC type > code-point=120, while FEC2 has FEC type code-point=130. > Therefore, FEC1 wins. > > ========= > Example incoming label conflict for label=1011 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.111/32 > with index=11 > ISIS SRGB on node A = [1000,1999] > Incoming label=1011 > > FEC2) > ISIS prefix sid advertisement from node C for > 2001:DB8:1000::11/128 with index=11 > ISIS SRGB on node A = [1000,1999] > Incoming label=1011 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Since IPv4 is > preferred over IPv6, FEC1 wins. > > ========= > Example incoming label conflict for label=1012 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.112/32 > with index=12 > ISIS SRGB on node A = [1000,1999] > Incoming label=1012 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.128/30 > with index=12 > ISIS SRGB on node A = [1000,1999] > Incoming label=1012 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Both are IPv4 address > family, so we compare prefix length.  FEC1 has prefix length=32, > and FEC2 has prefix length=30, so FEC2 wins. > > ========= > Example incoming label conflict for label=1013 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.113/32 > with index=13 > ISIS SRGB on node A = [1000,1999] > Incoming label=1013 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113..213/32 > with index=13 > ISIS SRGB on node A = [1000,1999] > Incoming label=1013 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Both are IPv4 address > family, so we compare prefix length.  Prefix lengths are the same, > so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins.. > > ========= > Example incoming label conflict for label=1014 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.114/32 > with index=14 > Routing Instance ID = 1000 > ISIS SRGB on node A = [1000,1999] > Incoming label=1014 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.114/32 > with index=14 > Routing Instance ID = 2000 > ISIS SRGB on node A = [1000,1999] > Incoming label=1014 > > These two FECs match all the way through the prefix length and > prefix. > So Routing Instance ID breaks the tie, with FEC1 winning. > > ========= > Example incoming label conflict for label=1015 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.115/32 > with index=15 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > ISIS SRGB on node A = [1000,1999] > Incoming label=1015 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.115/32 > with index=15 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 40 > ISIS SRGB on node A = [1000,1999] > Incoming label=1015 > > These two FECs match all the way through the prefix length, > prefix, and > Routing Instance ID.  We compare ISIS Multi-topology ID, so FEC2 wins. > > /* There appears to be a typo in section 2.5.1, with two different > orderings shown for a prefix-based FEC: > Prefix, Routing Instance, Topology, Algorithm > and > (Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology) > This needs to be corrected. */ > > ========= > Example incoming label conflict for label=1016 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.116/32 > with index=16 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > SR algorithm = 0 > ISIS SRGB on node A = [1000,1999] > Incoming label=1016 > > FEC2) > ISIS prefix sid advertisement from node C for 203..0.113.116/32 > with index=16 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > SR algorithm = 22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1016 > > These two FECs match all the way through the prefix length, > prefix, and > Routing Instance ID, and Multi-topology ID. We compare SR > algorithm ID, so > FEC1 wins. > > ========= > Example incoming label conflict for label=1017 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.117/32 > with index=17 > ISIS SRGB on node A = [1000,1999] > Incoming label=1017 > > FEC2) > ISIS mapping server advertisement (SID/Label Binding TLV) from node D: > Range=100, Prefix = 203.0.113.1/32 > This mapping server advertisment generates 100 mappings, one of which > maps 203.0.113.17/32 to index=17. > ISIS SRGB on node A = [1000,1999] > Incoming label=1017 > > The fact that FEC1 comes from a normal prefix sid advertisement and > FEC2 is generated from a mapping server advertisement is not > used as a tie-breaking parameter. Both FECs use dynamic SID > assignment, > are from the same MCC, have the same FEC type code-point=120. > Their prefix > lengths are the same as well.  FEC2 wins based on lower numerical > prefix value, > since 203.0.113.17 is less than 203.0.113.117. > > ========= > Example incoming label conflict for label=1018 on node A > > FEC1) > ISIS IPv4 adjacency sid advertisement from node A with label=1018 > corresponding to next-hop interface address=192.0.2.100, outgoing > interface ID=5 > Incoming label=1018 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC2) > ISIS IPv6 adjacency sid advertisement from node A with label=1018 > corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6. > Incoming label=1018 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > Both FECs use dynamic SID assignment, are from the same MCC, > and have the same FEC type code-point=130.  FEC1 wins > because IPv4 address family is preferred over IPv6. > > ========= > Example incoming label conflict for label=1019 on node A > > FEC1) > ISIS IPv4 adjacency sid advertisement from node A with label=1019 > corresponding to next-hop interface address=192.0.2.220, outgoing > interface ID=7 > Incoming label=1019 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC2) > ISIS IPv4 adjacency sid advertisement from node A with label=1019 > corresponding to next-hop interface address=192.0.2.230, outgoing > interface ID=8 > Incoming label=1019 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > Both FECs use dynamic SID assignment, are from the same MCC, > and have the same FEC type code-point=130. Both FECs have to > same address family.  FEC1 wins based on having the lowest next-hop > interface address. > > /* It is not clear how to construct an example that > would result in using the outgoing interface ID as a tie-breaker. > It would be useful to understand why this is and clarify > it in the text. */ > ========= > Example incoming label conflict for label=1020 on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=2001:DB8:3000::100, color=100, SID-List= > Binding-SID label=1020 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.60, color=100, SID-List= > Binding-SID label=1020 > > The FECs match through the tie-breaks up to and including > having the same FEC type code-point=140. > FEC2 wins based on IPv4 address family being preferred > over IPv6. > > ========= > Example incoming label conflict for label=1021 on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.70, color=100, SID-List= > Binding-SID label=1021 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.71, color=100, SID-List= > Binding-SID label=1021 > > The FECs match through the tie-breaks up to and including > having the same address family. FEC1 wins by having the > lower numerical endpoint address value. > > ========= > > I'd like to propose the examples below to be included > in the draft to help clarify section 2.6 > (currently entitled "Outgoing Label Collision"). > > > Examples of the Effect Incoming Label Collision on Outgoing Label > Programming > ==================================== > > Example of effect of incoming label collision for label=1022 > on outgoing label programming on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.122/32 > with index=22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1022 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.222/32 > with index=22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1022 > > FEC1 wins based on lowest numerical prefix value.  This means that > node A > installs a transit MPLS forwarding entry to SWAP incoming > label=1022, with outgoing label N, > and use outgoing interace I. N is determined by the index > associated with FEC1 (index=22) and > the SRGB advertised by the next-hop node on the shortest path to reach > 203.0.113.122/32 . > > Node A will generally also install an ingress MPLS forwarding > entry corresponding to FEC1 for > incoming prefix=203.0.113.122/32 pushing > outgoing label N, and using outgoing interace I. > > The rule in section 2.6 means that node A MUST NOT install an > ingress MPLS forwarding entry > corresponding to FEC2 ( which would be for incoming > prefix=203.0.113.222/32 ). > ======== > > Example of effect of incoming label collision for label=1023 > on outgoing label programming on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.80, color=100, SID-List= > Binding-SID label=1023 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.81, color=100, SID-List= > Binding-SID label=1023 > > FEC1 wins by having the lower numerical endpoint address value. > This means that node A > installs a transit MPLS forwarding entry to SWAP incoming > label=1023, with outgoing labels > and outgoing interface determined by the SID-List for FEC1. > Node A will generally also install an ingress MPLS forwarding > entry corresponding to FEC1 for > incoming prefix=192.0.2.80/32 pushing > outgoing labels and using the outgoing interface > determined by the SID-List for FEC1. > > The rule in section 2.6 means that node A MUST NOT install an > ingress MPLS forwarding entry > corresponding to FEC2 ( which would be for incoming > prefix=192.0.2.81/32 ). > > ======== > > General comment: > > section 2.6 title: > existing: > Outgoing Label Collision: > proposed: > Effect of Incoming Label Collision on Outgoing Label Programming : > -------------------------------------- > > > Thanks, > Chris > > > On Thu, May 24, 2018 at 12:14 PM, > wrote: > > Hello Working Group, > > This email starts a Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-13 [1] which is > considered mature and ready for a final working group review. > > Please read this document if you haven't read the most recent > version yet, and send your comments to the list, no later than > *June 08*. > > As a reminder, this document had already passed a WGLC more > than a year ago on version -06 [2], had been sent to the AD > but then returned to the WG. > > Since then, the document has significantly changed, so please > read it again. In particular, it now includes the resolution > in case of incoming label collision. Hence it killed > draft-ietf-spring-conflict-resolution. > > Both co-chairs co-author this document, hence: > > - Shraddha has agreed to be the document shepherd... Thank you > Shraddha. > > - Martin, our AD, has agreed to evaluate the WG consensus. > > Thank you, > > Bruno, Rob > > [1] > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 > > [2] > https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y > > _________________________________________________________________________________________________________________________ > > 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 > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > -- > Przemyslaw "PK" Krol |  Strategic Network Engineer ing > |pkrol@google.com > --------------037EA0EDF97C787972A107D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks a for the comments

Version 15 of the draft addresses your comments. See my comments below "#Ahmed"


On 6/9/18 12:01 AM, Przemyslaw Krol wrote:
Greetings,

Few minor, cosmetic/editorial suggestions:

2.5. Incoming Label Collision
[...]
(Endpoint, Color) representing an SR policy [I.D. filsfils-spring-segment-routing-policy]

(Color, Endpoint) is the ordering used by the policy draft. If the decision is to correct it, there is few references in the draft

#Ahmed: It does not matter from the point of view of label collision
2.5.1. Tie-breaking Rules
[...]
       o The Color ID is encoded using 16 bits

should be 32 bits 
#Ahmed: Modified as suggested


2.6. Outgoing Label Collision
[...]
In the general case, the ingress node may not have exactly have the same data of the receiving node
#Ahmed
Corrected

2.7. PUSH, CONTINUE, and NEXT
PUSH, NEXT, and CONTINUE are operations applied by the forwarding plane.
[...]

#Ahmed:
Corrected
2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs
[...]
an IGP with SR extensions [I-D.ietf-isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-extensions]

^^^ missing '[' or alternatively both references should be enclosed in their own []
#Ahmed:
Corrected


thanks,
pk

On Fri, Jun 8, 2018 at 11:14 AM Chris Bowers <chrisbowers.ietf@gmail.com> wrote:
SPRING WG,

I generally support publication of
draft-ietf-spring-segment-routing-mpls. However, I think
that the text in sections 2.5 and 2.6 (on incoming label collisions)
needs some work before publication. This text was added to
the draft a few months ago, and has not gotten much review
from the WG as a whole. The review and proposed text below
focuses on these sections.

As I understand the current text of the draft, the general
approach to resolving incoming label collisions seems
well-reasoned and complete.  However, it is possible that
my interpretation of these tie-breaking rules is
not what the authors intended.

I'd like to propose the examples below to be included
in the draft to help clarify the tie-breaking rules
for incoming label collisions described in section 2.5.
I have highlighted several cases in these examples,
where I think the rules in section 2.5 need
to be clarified in order to unambiguously determine
the winning FEC in an example.

It may also be the case that the authors or other
WG participants will disagree with the interpretation of the
rules used to choose a winning FEC in some of these
examples.  In that case, we should discuss
what is the correct interpretation, and clarify the
text in the draft to make the correct interpretation
clear.


Incoming label collision examples
=========

Node A
OSPF default admin distance for implementation=50
ISIS default admin distance for implementation=60

=========
Example incoming label conflict for label=1005 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.5/32 with index=5
OSPF SRGB on node A = [1000,1999]
Incoming label=1005

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.105/32 with index=5
ISIS SRGB on node A = [1000,1999]
Incoming label=1005

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1006 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.6/32 with index=6
OSPF SRGB on node A = [1000,1999]
Incoming label=1006

FEC2)
ISIS adjacency sid advertisement from node A with label=1006
Incoming label=1006
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1007 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.7/32 with index=7
OSPF SRGB on node A = [1000,1999]
Incoming label=1007

FEC2)
ISIS adjacency sid advertisement from node A with label=1007
Incoming label=1007
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
assignment. So FEC2 wins.

=========
Example incoming label conflict for label=1008 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100..8/32 with index=8
OSPF SRGB on node A = [1000,1999]
Incoming label=1008

FEC2)
SR Policy advertisement from controller to node A
Endpoint = 192.0.2.208, color = 100, SID-List = <S1, S2>
Binding-SID label = 1008

FEC1 and FEC2 both use dynamic SID assignment. 
Since one of the FEC types is SR Policy, default admin
distance is not used to break the tie. 
/* The text in Section 2.5.1 needs to be clarified to specify
whether SR Policy always loses or always wins in this case. */

=========
Example incoming label conflict for label=1009 on node A

FEC1)
OSPF adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC2)
ISIS adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 and FEC2 both use explicit SID assignment.  This kind of
incoming label collision should never occur, since an
implement of explicit SID assignment MUST guarantee
collision freeness on the same router.

========
Example incoming label conflict for label=1010 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.110/32 with index=10
ISIS SRGB on node A = [1000,1999]
Incoming label=1010

FEC2)
ISIS adjacency sid advertisement by node A with label=1010
Incoming label=1010
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  FEC1 has FEC type
code-point=120, while FEC2 has FEC type code-point=130.
Therefore, FEC1 wins. 

=========
Example incoming label conflict for label=1011 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.111/32 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC2)
ISIS prefix sid advertisement from node C for 2001:DB8:1000::11/128 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Since IPv4 is
preferred over IPv6, FEC1 wins.

=========
Example incoming label conflict for label=1012 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.112/32 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.128/30 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  FEC1 has prefix length=32,
and FEC2 has prefix length=30, so FEC2 wins.

=========
Example incoming label conflict for label=1013 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.113/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113..213/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  Prefix lengths are the same,
so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins..

=========
Example incoming label conflict for label=1014 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.114/32 with index=14
Routing Instance ID = 1000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.114/32 with index=14
Routing Instance ID = 2000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

These two FECs match all the way through the prefix length and prefix.
So Routing Instance ID breaks the tie, with FEC1 winning.

=========
Example incoming label conflict for label=1015 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 40
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID.  We compare ISIS Multi-topology ID, so FEC2 wins.

/* There appears to be a typo in section 2.5.1, with two different
orderings shown for a prefix-based FEC:
Prefix, Routing Instance, Topology, Algorithm
and
(Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology)
This needs to be corrected. */

=========
Example incoming label conflict for label=1016 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 0
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

FEC2)
ISIS prefix sid advertisement from node C for 203..0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 22
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so
FEC1 wins.

=========
Example incoming label conflict for label=1017 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.117/32 with index=17
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

FEC2)
ISIS mapping server advertisement (SID/Label Binding TLV) from node D:
Range=100, Prefix = 203.0.113.1/32
This mapping server advertisment generates 100 mappings, one of which
maps 203.0.113.17/32 to index=17.
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

The fact that FEC1 comes from a normal prefix sid advertisement and
FEC2 is generated from a mapping server advertisement is not
used as a tie-breaking parameter. Both FECs use dynamic SID assignment,
are from the same MCC, have the same FEC type code-point=120. Their prefix
lengths are the same as well.  FEC2 wins based on lower numerical prefix value,
since 203.0.113.17 is less than 203.0.113.117.

=========
Example incoming label conflict for label=1018 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1018
corresponding to next-hop interface address=192.0.2.100, outgoing interface ID=5
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv6 adjacency sid advertisement from node A with label=1018
corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6.
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130.  FEC1 wins
because IPv4 address family is preferred over IPv6.

=========
Example incoming label conflict for label=1019 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.220, outgoing interface ID=7
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.230, outgoing interface ID=8
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130. Both FECs have to
same address family.  FEC1 wins based on having the lowest next-hop
interface address. 

/* It is not clear how to construct an example that
would result in using the outgoing interface ID as a tie-breaker.
It would be useful to understand why this is and clarify
it in the text. */
=========
Example incoming label conflict for label=1020 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>
Binding-SID label=1020

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>
Binding-SID label=1020

The FECs match through the tie-breaks up to and including
having the same FEC type code-point=140.
FEC2 wins based on IPv4 address family being preferred
over IPv6.  

=========
Example incoming label conflict for label=1021 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2>
Binding-SID label=1021

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4>
Binding-SID label=1021

The FECs match through the tie-breaks up to and including
having the same address family. FEC1 wins by having the
lower numerical endpoint address value.

=========

I'd like to propose the examples below to be included
in the draft to help clarify section 2.6
(currently entitled "Outgoing Label Collision").


Examples of the Effect Incoming Label Collision on Outgoing Label Programming
====================================

Example of effect of incoming label collision for label=1022
on outgoing label programming on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.122/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.222/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC1 wins based on lowest numerical prefix value.  This means that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1022, with outgoing label N,
and use outgoing interace I. N is determined by the index associated with FEC1 (index=22) and
the SRGB advertised by the next-hop node on the shortest path to reach
203.0.113.122/32.

Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for
incoming prefix=203.0.113.122/32 pushing outgoing label N, and using outgoing interace I.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=203.0.113.222/32). 
========

Example of effect of incoming label collision for label=1023
on outgoing label programming on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>
Binding-SID label=1023

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4>
Binding-SID label=1023

FEC1 wins by having the lower numerical endpoint address value. This means that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1023, with outgoing labels
and outgoing interface determined by the SID-List for FEC1.
Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for
incoming prefix=192.0.2.80/32 pushing outgoing labels and using the outgoing interface
determined by the SID-List for FEC1.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=192.0.2.81/32). 

========

General comment:

section 2.6 title:
existing:
Outgoing Label Collision:
proposed:
Effect of Incoming Label Collision on Outgoing Label Programming :
--------------------------------------


Thanks,
Chris


On Thu, May 24, 2018 at 12:14 PM, <bruno..decraene@orange.com> wrote:
Hello Working Group,
    
This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review.
    
Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*.
 
As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG.
Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd... Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
_________________________________________________________________________________________________________________________

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


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


--
Przemyslaw "PK" Krol |=C2=A0Strategic Network Engineering |=C2=A0pkrol@google.com= =C2=A0
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | pkrol@google.com 

--------------037EA0EDF97C787972A107D8-- From nobody Sat Oct 27 15:34:31 2018 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 8D966130DDA; Sat, 27 Oct 2018 15:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2bOdmf8jPyGd; Sat, 27 Oct 2018 15:34:23 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 57095126F72; Sat, 27 Oct 2018 15:34:23 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id a19-v6so2193278pfo.8; Sat, 27 Oct 2018 15:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=iVWQGJ3bCCqCwUs3j3M8t3E3KIQV6lc8Be7p8hhS8tg=; b=XHdhb/uOfLUro1Og8JCrTZ2X5cdKU1JqQYHkuonBag7ynCajY4KRdZakbs2MBunMSY WQE0xY0Y2rRDEeG9t6q+NDnQtSXT3XsYD19jiAqviE/IC/wh5K0AOwpsryEgxFx5a4YH 6ER3YN85mF/ZOVt11mhSOWtDKninHGce/TC76EQebQKYxabz8kpjyVsGdmcB1+r58Lcz MB48LNNzX/XHtscSaQ0Rn7TMWDvDwpxcfp6OhPD25aFVB9smBV6SI4uKre/qQFncsiDs PbbSqiiAOB/z3hVUSniKUWCP8GP9TevyRYTWI4LLN+0CwSFHcYZVAiXTObnDDpRB7/wa CzjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=iVWQGJ3bCCqCwUs3j3M8t3E3KIQV6lc8Be7p8hhS8tg=; b=uPAnoGGvNMZk0jIb9oqcWgmZTFlxsX1UrKvYgri2nvpnMAvsQ2QVqOhQepqWWMnNgH GWSPNrbtvMa54jcoemtyEqUedyIHJgede+EgdgjRbB0HnGLL9KVe8uXP4IQbw5X7C5km VvoaFYrTpsEgKQgpHvooaeBpIyO/8pUEsXOuAtHFMHFhRc+bhDPaTvUYw67/GiSRwKUx KXVASteSCbsgWNlAAEByRdMqAuxNakaPlnd2RffIZHicLbz8SbeePA2Ba4P53t/S1oC9 9amqimDIu4XSKtuL8vWoHr+8u1hqqnIf5WtXE8MjJb0YnAoOSrqeaHocyLh2jkcEKYWQ ssXg== X-Gm-Message-State: AGRZ1gL5B2i7eyMjtOuZSeVGKNsXFCjRAPUqnCH93850OEyAM54bvsGt PpeOkA3LFEtaDtuZDph36Jc= X-Google-Smtp-Source: AJdET5fQu3RfgAsQoMAlP+MYqIQoR+0y4u3Gr/Iyu88RyhUtBS18ifYhageIBmjdC0o8iQGE95UdBQ== X-Received: by 2002:a63:4c6:: with SMTP id 189mr8475271pge.391.1540679662673; Sat, 27 Oct 2018 15:34:22 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id h25-v6sm13690204pgv.27.2018.10.27.15.34.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 15:34:21 -0700 (PDT) To: Przemyslaw Krol , spring@ietf.org Cc: Bruno Decraene , draft-ietf-spring-segment-routing-mpls@ietf.org, chrisbowers.ietf@gmail.com References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: <95e89b1f-eeeb-7e06-4b55-701b75a0540d@gmail.com> Date: Sat, 27 Oct 2018 15:34:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0EF9BB0345B54C97F6C0EFE0" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 22:34:28 -0000 This is a multi-part message in MIME format. --------------0EF9BB0345B54C97F6C0EFE0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit #Ahmed: The setting of the P and "E" flags translate to just one of the 3 operations: "continue", "push", or  "next". So there is really no need to cover this particular setting/clearing of flags since the setting/clearing of protocol flags are strictly control layer functionalities On 6/9/18 12:29 PM, Przemyslaw Krol wrote: > Greetings, > > In terms of UHP, draft-ietf-isis-segment-routing-extensions-16 >  describes > 2 cases: >  - P set, E unset >  - P set, E set > > However it looks that draft-ietf-spring-segment-routing-15 >  doesn't > make that distinction and doesn't seem to cover the latter case: > >    o  A remote node M MUST maintain the following FIB entry for any >       learned Prefix-SID SID-R attached to IP prefix R: > >      Incoming Active Segment: SID-R >      Ingress Operation: >         If the next-hop of R is the originator of R >         and instructed to remove the active segment: NEXT > *        Else: CONTINUE* >      Egress interface: the interface towards the next-hop along the >                        path computed using the algorithm advertised with >                        the SID toward prefix R. > > > Would it make sense to also describe the 2nd option (E+P) given ISIS > draft brings this up as a use case? > > thanks, > pk > > > > On Sat, Jun 9, 2018 at 12:01 AM Przemyslaw Krol > wrote: > > Greetings, > > Few minor, cosmetic/editorial suggestions: > > 2.5. Incoming Label Collision > [...] > *(Endpoint, Color)* representing an SR policy [I.D. > filsfils-spring-segment-routing-policy] > > (Color, Endpoint) is the ordering used by the policy draft. If the > decision is to correct it, there is few references in the draft > > 2.5.1. Tie-breaking Rules > [...] >        o The Color ID is encoded using *16 bits* > * > * > should be 32 bits > (https://tools.ietf.org/html/rfc5512#section-4.3.1 && > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-00#section-2.1) > > > 2.6. Outgoing Label Collision > [...] > In the general case, the ingress node may not have exactly > *have* the same data of the receiving node > > 2.7. PUSH, CONTINUE, and NEXT > PUSH, NEXT, and CONTINUE are operations applied by the forwarding > plan*e*. > [...] > > 2.8. MPLS Label downloaded to FIB corresponding to Global and > Local SIDs > [...] > an IGP with SR extensions > *[*I-D.ietf-isis-segment-routing-extensions, > I-D.ietf-ospf-segment-routing-extensions] > > ^^^ missing '[' or alternatively both references should be > enclosed in their own [] > > > thanks, > pk > > On Fri, Jun 8, 2018 at 11:14 AM Chris Bowers > > > wrote: > > SPRING WG, > > I generally support publication of > draft-ietf-spring-segment-routing-mpls. However, I think > that the text in sections 2.5 and 2.6 (on incoming label > collisions) > needs some work before publication. This text was added to > the draft a few months ago, and has not gotten much review > from the WG as a whole. The review and proposed text below > focuses on these sections. > > As I understand the current text of the draft, the general > approach to resolving incoming label collisions seems > well-reasoned and complete.  However, it is possible that > my interpretation of these tie-breaking rules is > not what the authors intended. > > I'd like to propose the examples below to be included > in the draft to help clarify the tie-breaking rules > for incoming label collisions described in section 2.5. > I have highlighted several cases in these examples, > where I think the rules in section 2.5 need > to be clarified in order to unambiguously determine > the winning FEC in an example. > > It may also be the case that the authors or other > WG participants will disagree with the interpretation of the > rules used to choose a winning FEC in some of these > examples.  In that case, we should discuss > what is the correct interpretation, and clarify the > text in the draft to make the correct interpretation > clear. > > > Incoming label collision examples > ========= > > Node A > OSPF default admin distance for implementation=50 > ISIS default admin distance for implementation=60 > > ========= > Example incoming label conflict for label=1005 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.5/32 > with index=5 > OSPF SRGB on node A = [1000,1999] > Incoming label=1005 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.105/32 > with index=5 > ISIS SRGB on node A = [1000,1999] > Incoming label=1005 > > FEC1 and FEC2 both use dynamic SID assignment.  Since neither of > the FEC types is SR Policy, we use the default admin distances > of 50 > and 60 to break the tie.  So FEC1 wins. > > ========= > Example incoming label conflict for label=1006 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.6/32 > with index=6 > OSPF SRGB on node A = [1000,1999] > Incoming label=1006 > > FEC2) > ISIS adjacency sid advertisement from node A with label=1006 > Incoming label=1006 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC1 and FEC2 both use dynamic SID assignment.  Since neither of > the FEC types is SR Policy, we use the default admin distances > of 50 > and 60 to break the tie.  So FEC1 wins. > > ========= > Example incoming label conflict for label=1007 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100.7/32 > with index=7 > OSPF SRGB on node A = [1000,1999] > Incoming label=1007 > > FEC2) > ISIS adjacency sid advertisement from node A with label=1007 > Incoming label=1007 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID > assignment. So FEC2 wins. > > ========= > Example incoming label conflict for label=1008 on node A > > FEC1) > OSPF prefix sid advertisement from node B for 198.51.100..8/32 > with index=8 > OSPF SRGB on node A = [1000,1999] > Incoming label=1008 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint = 192.0.2.208, color = 100, SID-List = > Binding-SID label = 1008 > > FEC1 and FEC2 both use dynamic SID assignment. > Since one of the FEC types is SR Policy, default admin > distance is not used to break the tie. > /* The text in Section 2.5.1 needs to be clarified to specify > whether SR Policy always loses or always wins in this case. */ > > ========= > Example incoming label conflict for label=1009 on node A > > FEC1) > OSPF adjacency sid advertisement by node A with label=1009 > Incoming label=1009 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC2) > ISIS adjacency sid advertisement by node A with label=1009 > Incoming label=1009 > Node A assigns this adjacency SID explicitly via configuration, > so the adjacency SID survives router reboots. > > FEC1 and FEC2 both use explicit SID assignment.  This kind of > incoming label collision should never occur, since an > implement of explicit SID assignment MUST guarantee > collision freeness on the same router. > > ======== > Example incoming label conflict for label=1010 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.110/32 > with index=10 > ISIS SRGB on node A = [1000,1999] > Incoming label=1010 > > FEC2) > ISIS adjacency sid advertisement by node A with label=1010 > Incoming label=1010 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  FEC1 has FEC type > code-point=120, while FEC2 has FEC type code-point=130. > Therefore, FEC1 wins. > > ========= > Example incoming label conflict for label=1011 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.111/32 > with index=11 > ISIS SRGB on node A = [1000,1999] > Incoming label=1011 > > FEC2) > ISIS prefix sid advertisement from node C for > 2001:DB8:1000::11/128 with index=11 > ISIS SRGB on node A = [1000,1999] > Incoming label=1011 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Since IPv4 is > preferred over IPv6, FEC1 wins. > > ========= > Example incoming label conflict for label=1012 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.112/32 > with index=12 > ISIS SRGB on node A = [1000,1999] > Incoming label=1012 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.128/30 > with index=12 > ISIS SRGB on node A = [1000,1999] > Incoming label=1012 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Both are IPv4 > address > family, so we compare prefix length.  FEC1 has prefix length=32, > and FEC2 has prefix length=30, so FEC2 wins. > > ========= > Example incoming label conflict for label=1013 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.113/32 > with index=13 > ISIS SRGB on node A = [1000,1999] > Incoming label=1013 > > FEC2) > ISIS prefix sid advertisement from node C for > 203.0.113..213/32 with index=13 > ISIS SRGB on node A = [1000,1999] > Incoming label=1013 > > FEC1 and FEC2 both use dynamic SID assignment. Since both FECs > are from the same MCC, they have the same default admin distance. > So we compare FEC type code-point.  Both FECs have FEC type > code-point=120. So we compare address family.  Both are IPv4 > address > family, so we compare prefix length.  Prefix lengths are the same, > so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins.. > > ========= > Example incoming label conflict for label=1014 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.114/32 > with index=14 > Routing Instance ID = 1000 > ISIS SRGB on node A = [1000,1999] > Incoming label=1014 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.114/32 > with index=14 > Routing Instance ID = 2000 > ISIS SRGB on node A = [1000,1999] > Incoming label=1014 > > These two FECs match all the way through the prefix length and > prefix. > So Routing Instance ID breaks the tie, with FEC1 winning. > > ========= > Example incoming label conflict for label=1015 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.115/32 > with index=15 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > ISIS SRGB on node A = [1000,1999] > Incoming label=1015 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.115/32 > with index=15 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 40 > ISIS SRGB on node A = [1000,1999] > Incoming label=1015 > > These two FECs match all the way through the prefix length, > prefix, and > Routing Instance ID.  We compare ISIS Multi-topology ID, so > FEC2 wins. > > /* There appears to be a typo in section 2.5.1, with two > different > orderings shown for a prefix-based FEC: > Prefix, Routing Instance, Topology, Algorithm > and > (Prefix Length, Prefix, SR Algorithm, routing_instance_id, > Topology) > This needs to be corrected. */ > > ========= > Example incoming label conflict for label=1016 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.116/32 > with index=16 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > SR algorithm = 0 > ISIS SRGB on node A = [1000,1999] > Incoming label=1016 > > FEC2) > ISIS prefix sid advertisement from node C for > 203..0.113.116/32 with index=16 > Routing Instance ID = 1000 > ISIS Multi-topology ID = 50 > SR algorithm = 22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1016 > > These two FECs match all the way through the prefix length, > prefix, and > Routing Instance ID, and Multi-topology ID. We compare SR > algorithm ID, so > FEC1 wins. > > ========= > Example incoming label conflict for label=1017 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.117/32 > with index=17 > ISIS SRGB on node A = [1000,1999] > Incoming label=1017 > > FEC2) > ISIS mapping server advertisement (SID/Label Binding TLV) from > node D: > Range=100, Prefix = 203.0.113.1/32 > This mapping server advertisment generates 100 mappings, one > of which > maps 203.0.113.17/32 to index=17. > ISIS SRGB on node A = [1000,1999] > Incoming label=1017 > > The fact that FEC1 comes from a normal prefix sid > advertisement and > FEC2 is generated from a mapping server advertisement is not > used as a tie-breaking parameter. Both FECs use dynamic SID > assignment, > are from the same MCC, have the same FEC type code-point=120. > Their prefix > lengths are the same as well.  FEC2 wins based on lower > numerical prefix value, > since 203.0.113.17 is less than 203.0.113.117. > > ========= > Example incoming label conflict for label=1018 on node A > > FEC1) > ISIS IPv4 adjacency sid advertisement from node A with label=1018 > corresponding to next-hop interface address=192.0.2.100, > outgoing interface ID=5 > Incoming label=1018 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC2) > ISIS IPv6 adjacency sid advertisement from node A with label=1018 > corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6. > Incoming label=1018 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > Both FECs use dynamic SID assignment, are from the same MCC, > and have the same FEC type code-point=130.  FEC1 wins > because IPv4 address family is preferred over IPv6. > > ========= > Example incoming label conflict for label=1019 on node A > > FEC1) > ISIS IPv4 adjacency sid advertisement from node A with label=1019 > corresponding to next-hop interface address=192.0.2.220, > outgoing interface ID=7 > Incoming label=1019 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > FEC2) > ISIS IPv4 adjacency sid advertisement from node A with label=1019 > corresponding to next-hop interface address=192.0.2.230, > outgoing interface ID=8 > Incoming label=1019 > Node A allocates this adjacency SID dynamically, > and it may differ across router reboots. > > Both FECs use dynamic SID assignment, are from the same MCC, > and have the same FEC type code-point=130. Both FECs have to > same address family.  FEC1 wins based on having the lowest > next-hop > interface address. > > /* It is not clear how to construct an example that > would result in using the outgoing interface ID as a tie-breaker. > It would be useful to understand why this is and clarify > it in the text. */ > ========= > Example incoming label conflict for label=1020 on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=2001:DB8:3000::100, color=100, SID-List= > Binding-SID label=1020 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.60, color=100, SID-List= > Binding-SID label=1020 > > The FECs match through the tie-breaks up to and including > having the same FEC type code-point=140. > FEC2 wins based on IPv4 address family being preferred > over IPv6. > > ========= > Example incoming label conflict for label=1021 on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.70, color=100, SID-List= > Binding-SID label=1021 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.71, color=100, SID-List= > Binding-SID label=1021 > > The FECs match through the tie-breaks up to and including > having the same address family. FEC1 wins by having the > lower numerical endpoint address value. > > ========= > > I'd like to propose the examples below to be included > in the draft to help clarify section 2.6 > (currently entitled "Outgoing Label Collision"). > > > Examples of the Effect Incoming Label Collision on Outgoing > Label Programming > ==================================== > > Example of effect of incoming label collision for label=1022 > on outgoing label programming on node A > > FEC1) > ISIS prefix sid advertisement from node B for 203.0.113.122/32 > with index=22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1022 > > FEC2) > ISIS prefix sid advertisement from node C for 203.0.113.222/32 > with index=22 > ISIS SRGB on node A = [1000,1999] > Incoming label=1022 > > FEC1 wins based on lowest numerical prefix value.  This means > that node A > installs a transit MPLS forwarding entry to SWAP incoming > label=1022, with outgoing label N, > and use outgoing interace I. N is determined by the index > associated with FEC1 (index=22) and > the SRGB advertised by the next-hop node on the shortest path > to reach > 203.0.113.122/32 . > > Node A will generally also install an ingress MPLS forwarding > entry corresponding to FEC1 for > incoming prefix=203.0.113.122/32 > pushing outgoing label N, and using outgoing interace I. > > The rule in section 2.6 means that node A MUST NOT install an > ingress MPLS forwarding entry > corresponding to FEC2 ( which would be for incoming > prefix=203.0.113.222/32 ). > ======== > > Example of effect of incoming label collision for label=1023 > on outgoing label programming on node A > > FEC1) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.80, color=100, SID-List= > Binding-SID label=1023 > > FEC2) > SR Policy advertisement from controller to node A > Endpoint address=192.0.2.81, color=100, SID-List= > Binding-SID label=1023 > > FEC1 wins by having the lower numerical endpoint address > value. This means that node A > installs a transit MPLS forwarding entry to SWAP incoming > label=1023, with outgoing labels > and outgoing interface determined by the SID-List for FEC1. > Node A will generally also install an ingress MPLS forwarding > entry corresponding to FEC1 for > incoming prefix=192.0.2.80/32 pushing > outgoing labels and using the outgoing interface > determined by the SID-List for FEC1. > > The rule in section 2.6 means that node A MUST NOT install an > ingress MPLS forwarding entry > corresponding to FEC2 ( which would be for incoming > prefix=192.0.2.81/32 ). > > ======== > > General comment: > > section 2.6 title: > existing: > Outgoing Label Collision: > proposed: > Effect of Incoming Label Collision on Outgoing Label Programming : > -------------------------------------- > > > Thanks, > Chris > > > On Thu, May 24, 2018 at 12:14 PM, > wrote: > > Hello Working Group, > > This email starts a Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-13 [1] which is > considered mature and ready for a final working group review. > > Please read this document if you haven't read the most > recent version yet, and send your comments to the list, no > later than *June 08*. > > As a reminder, this document had already passed a WGLC > more than a year ago on version -06 [2], had been sent to > the AD but then returned to the WG. > > Since then, the document has significantly changed, so > please read it again. In particular, it now includes the > resolution in case of incoming label collision. Hence it > killed draft-ietf-spring-conflict-resolution. > > Both co-chairs co-author this document, hence: > > - Shraddha has agreed to be the document shepherd... Thank > you Shraddha. > > - Martin, our AD, has agreed to evaluate the WG consensus. > > Thank you, > > Bruno, Rob > > [1] > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 > > [2] > https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y > > _________________________________________________________________________________________________________________________ > > 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 > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > -- > Przemyslaw "PK" Krol |  Strategic Network Engineer ing > |pkrol@google.com > > > > -- > Przemyslaw "PK" Krol |  Strategic Network Engineer ing > |pkrol@google.com > --------------0EF9BB0345B54C97F6C0EFE0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

#Ahmed:
The setting of the P and "E" flags translate to just one of the 3
operations: "continue", "push", or  "next". So there is really no need to
cover this particular setting/clearing of flags since the
setting/clearing of protocol flags are strictly control layer functionalities



On 6/9/18 12:29 PM, Przemyslaw Krol wrote:
Greetings,

In terms of UHP, draft-ietf-isis-segment-routing-extensions-16 describes 2 cases: 
 - P set, E unset
 - P set, E set

However it looks that draft-ietf-spring-segment-routing-15 doesn't make that distinction and doesn't seem to cover the latter case:

   o  A remote node M MUST maintain the following FIB entry for any
      learned Prefix-SID SID-R attached to IP prefix R:

     Incoming Active Segment: SID-R
     Ingress Operation:
        If the next-hop of R is the originator of R
        and instructed to remove the active segment: NEXT
        Else: CONTINUE
     Egress interface: the interface towards the next-hop along the
                       path computed using the algorithm advertised with
                       the SID toward prefix R.


Would it make sense to also describe the 2nd option (E+P) given ISIS draft brings this up as a use case?

thanks,
pk



On Sat, Jun 9, 2018 at 12:01 AM Przemyslaw Krol <pkrol@google.com> wrote:
Greetings,

Few minor, cosmetic/editorial suggestions:

2.5. Incoming Label Collision
[...]
(Endpoint, Color) representing an SR policy [I.D. filsfils-spring-segment-routing-policy]

(Color, Endpoint) is the ordering used by the policy draft. If the decision is to correct it, there is few references in the draft

2.5.1. Tie-breaking Rules
[...]
       o The Color ID is encoded using 16 bits

should be 32 bits 


2.6. Outgoing Label Collision
[...]
In the general case, the ingress node may not have exactly have the same data of the receiving node

2.7. PUSH, CONTINUE, and NEXT
PUSH, NEXT, and CONTINUE are operations applied by the forwarding plane.
[...]

2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs
[...]
an IGP with SR extensions [I-D.ietf-isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-extensions]

^^^ missing '[' or alternatively both references should be enclosed in their own []


thanks,
pk

On Fri, Jun 8, 2018 at 11:14 AM Chris Bowers <chrisbowers.ietf@gmail.com> wrote:
SPRING WG,

I generally support publication of
draft-ietf-spring-segment-routing-mpls. However, I think
that the text in sections 2.5 and 2.6 (on incoming label collisions)
needs some work before publication. This text was added to
the draft a few months ago, and has not gotten much review
from the WG as a whole. The review and proposed text below
focuses on these sections.

As I understand the current text of the draft, the general
approach to resolving incoming label collisions seems
well-reasoned and complete.  However, it is possible that
my interpretation of these tie-breaking rules is
not what the authors intended.

I'd like to propose the examples below to be included
in the draft to help clarify the tie-breaking rules
for incoming label collisions described in section 2.5.
I have highlighted several cases in these examples,
where I think the rules in section 2.5 need
to be clarified in order to unambiguously determine
the winning FEC in an example.

It may also be the case that the authors or other
WG participants will disagree with the interpretation of the
rules used to choose a winning FEC in some of these
examples.  In that case, we should discuss
what is the correct interpretation, and clarify the
text in the draft to make the correct interpretation
clear.


Incoming label collision examples
=========

Node A
OSPF default admin distance for implementation=50
ISIS default admin distance for implementation=60

=========
Example incoming label conflict for label=1005 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.5/32 with index=5
OSPF SRGB on node A = [1000,1999]
Incoming label=1005

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.105/32 with index=5
ISIS SRGB on node A = [1000,1999]
Incoming label=1005

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1006 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.6/32 with index=6
OSPF SRGB on node A = [1000,1999]
Incoming label=1006

FEC2)
ISIS adjacency sid advertisement from node A with label=1006
Incoming label=1006
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1007 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.7/32 with index=7
OSPF SRGB on node A = [1000,1999]
Incoming label=1007

FEC2)
ISIS adjacency sid advertisement from node A with label=1007
Incoming label=1007
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
assignment. So FEC2 wins.

=========
Example incoming label conflict for label=1008 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100..8/32 with index=8
OSPF SRGB on node A = [1000,1999]
Incoming label=1008

FEC2)
SR Policy advertisement from controller to node A
Endpoint = 192.0.2.208, color = 100, SID-List = <S1, S2>
Binding-SID label = 1008

FEC1 and FEC2 both use dynamic SID assignment. 
Since one of the FEC types is SR Policy, default admin
distance is not used to break the tie. 
/* The text in Section 2.5.1 needs to be clarified to specify
whether SR Policy always loses or always wins in this case. */

=========
Example incoming label conflict for label=1009 on node A

FEC1)
OSPF adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC2)
ISIS adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 and FEC2 both use explicit SID assignment.  This kind of
incoming label collision should never occur, since an
implement of explicit SID assignment MUST guarantee
collision freeness on the same router.

========
Example incoming label conflict for label=1010 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.110/32 with index=10
ISIS SRGB on node A = [1000,1999]
Incoming label=1010

FEC2)
ISIS adjacency sid advertisement by node A with label=1010
Incoming label=1010
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  FEC1 has FEC type
code-point=120, while FEC2 has FEC type code-point=130.
Therefore, FEC1 wins. 

=========
Example incoming label conflict for label=1011 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.111/32 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC2)
ISIS prefix sid advertisement from node C for 2001:DB8:1000::11/128 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Since IPv4 is
preferred over IPv6, FEC1 wins.

=========
Example incoming label conflict for label=1012 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.112/32 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.128/30 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  FEC1 has prefix length=32,
and FEC2 has prefix length=30, so FEC2 wins.

=========
Example incoming label conflict for label=1013 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.113/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113..213/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  Prefix lengths are the same,
so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins..

=========
Example incoming label conflict for label=1014 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.114/32 with index=14
Routing Instance ID = 1000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.114/32 with index=14
Routing Instance ID = 2000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

These two FECs match all the way through the prefix length and prefix.
So Routing Instance ID breaks the tie, with FEC1 winning.

=========
Example incoming label conflict for label=1015 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 40
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID.  We compare ISIS Multi-topology ID, so FEC2 wins.

/* There appears to be a typo in section 2.5.1, with two different
orderings shown for a prefix-based FEC:
Prefix, Routing Instance, Topology, Algorithm
and
(Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology)
This needs to be corrected. */

=========
Example incoming label conflict for label=1016 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 0
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

FEC2)
ISIS prefix sid advertisement from node C for 203..0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 22
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so
FEC1 wins.

=========
Example incoming label conflict for label=1017 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.117/32 with index=17
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

FEC2)
ISIS mapping server advertisement (SID/Label Binding TLV) from node D:
Range=100, Prefix = 203.0.113.1/32
This mapping server advertisment generates 100 mappings, one of which
maps 203.0.113.17/32 to index=17.
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

The fact that FEC1 comes from a normal prefix sid advertisement and
FEC2 is generated from a mapping server advertisement is not
used as a tie-breaking parameter. Both FECs use dynamic SID assignment,
are from the same MCC, have the same FEC type code-point=120. Their prefix
lengths are the same as well.  FEC2 wins based on lower numerical prefix value,
since 203.0.113.17 is less than 203.0.113.117.

=========
Example incoming label conflict for label=1018 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1018
corresponding to next-hop interface address=192.0.2.100, outgoing interface ID=5
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv6 adjacency sid advertisement from node A with label=1018
corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6.
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130.  FEC1 wins
because IPv4 address family is preferred over IPv6.

=========
Example incoming label conflict for label=1019 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.220, outgoing interface ID=7
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.230, outgoing interface ID=8
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130. Both FECs have to
same address family.  FEC1 wins based on having the lowest next-hop
interface address. 

/* It is not clear how to construct an example that
would result in using the outgoing interface ID as a tie-breaker.
It would be useful to understand why this is and clarify
it in the text. */
=========
Example incoming label conflict for label=1020 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>
Binding-SID label=1020

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>
Binding-SID label=1020

The FECs match through the tie-breaks up to and including
having the same FEC type code-point=140.
FEC2 wins based on IPv4 address family being preferred
over IPv6.  

=========
Example incoming label conflict for label=1021 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2>
Binding-SID label=1021

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4>
Binding-SID label=1021

The FECs match through the tie-breaks up to and including
having the same address family. FEC1 wins by having the
lower numerical endpoint address value.

=========

I'd like to propose the examples below to be included
in the draft to help clarify section 2.6
(currently entitled "Outgoing Label Collision").


Examples of the Effect Incoming Label Collision on Outgoing Label Programming
====================================

Example of effect of incoming label collision for label=1022
on outgoing label programming on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.122/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.222/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC1 wins based on lowest numerical prefix value.  This means that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1022, with outgoing label N,
and use outgoing interace I. N is determined by the index associated with FEC1 (index=22) and
the SRGB advertised by the next-hop node on the shortest path to reach
203.0.113.122/32.

Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for
incoming prefix=203.0.113.122/32 pushing outgoing label N, and using outgoing interace I.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=203.0.113.222/32). 
========

Example of effect of incoming label collision for label=1023
on outgoing label programming on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>
Binding-SID label=1023

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4>
Binding-SID label=1023

FEC1 wins by having the lower numerical endpoint address value. This means that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1023, with outgoing labels
and outgoing interface determined by the SID-List for FEC1.
Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for
incoming prefix=192.0.2.80/32 pushing outgoing labels and using the outgoing interface
determined by the SID-List for FEC1.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=192.0.2.81/32). 

========

General comment:

section 2.6 title:
existing:
Outgoing Label Collision:
proposed:
Effect of Incoming Label Collision on Outgoing Label Programming :
--------------------------------------


Thanks,
Chris


On Thu, May 24, 2018 at 12:14 PM, <bruno..decraene@orange.com> wrote:
Hello Working Group,
    
This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review.
    
Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*.
 
As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG.
Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd... Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
_________________________________________________________________________________________________________________________

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


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


--
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | pkrol@google.com 


--
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | pkrol@google.com 

--------------0EF9BB0345B54C97F6C0EFE0-- From nobody Sat Oct 27 15:42:06 2018 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 A309D130DDA; Sat, 27 Oct 2018 15:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8jeseumGSXFO; Sat, 27 Oct 2018 15:42:01 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 7CF19126F72; Sat, 27 Oct 2018 15:42:01 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id p5-v6so2060406plq.8; Sat, 27 Oct 2018 15:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=iVe89Q9kXtz8/AEz7Rs2P/CdFb42fP8XalaD9ipvtx8=; b=PdYG8N3rnPzIIgd/hsMYAT5MpO8g6E5Hlv71v3UzZbikaC2//AeQddiihmEIrOoaZJ 3d3uodt9VDdW6iFcqwJrIAYOv3JKOGJJpTxBne9KWstg/ndccYyPzOywNJflZUWQyXll cKVSynY/owUygLFzprIQKGJz0cEwRapglCeM5PbTXtRDRY2RvzD7TZIGQiA/Vh1XMsME +1P9QRrJMxLMP0llA6B/Nv9z7yriMr8Y0SBInfPq1j/OjxLnqLCfaWpjTEAxdn2Ul+Zf ethwhEFepQg7NhNd/CAo2liZAUUXMH+Wft3VaHiezRf9yBg5kXFV0PB3vSoa4FdyJTwQ H7dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=iVe89Q9kXtz8/AEz7Rs2P/CdFb42fP8XalaD9ipvtx8=; b=PtcZ8BrSp8I7UIK8JPr7d7vnMC612YFblPFzf/AzFYHtZa3WQpB/GBKq2BdPQVqtRh NYDZS2tZ/UFcIiSwo2wDOF0F2/9kCnjfk7Nq+1fFeELI+3HLXrcQqOMgY6naM9lIKW3n k75zOrrq+RnzJUwh/ftSZxliMbqejslqw+Bja6IzP0OMQb2zndOHGmDgYD/0SYXPj6SJ GoXCNP2TngU6N7zr8Oj/hJEWZHyaD0co+eqPzrFL6eRrvITrOJ6B5SDQnDWN2eHGsnHk sLzlsoHZjV5ieqlj8x7agvWXbexPfF4j3oJvYKoy3iR+YaALlHDzz7WIZdX/iOeAM8zM 44qw== X-Gm-Message-State: AGRZ1gIBtPcKpypMcZwTfYPs+uYrd53zjU2q0snbcPnG21YtSTGCllwu FVm5cJ5zpf5LvRXFVZQyIHg= X-Google-Smtp-Source: AJdET5cl0M0emg3U+5QQ+2xxFl6gBRflGrNdkx2Kof1TNcgxeNTHS7/boRfJkxXJnVf8a/qN56prGw== X-Received: by 2002:a17:902:7785:: with SMTP id o5-v6mr8382282pll.200.1540680120894; Sat, 27 Oct 2018 15:42:00 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id x189-v6sm8444929pfb.162.2018.10.27.15.41.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 15:42:00 -0700 (PDT) To: Ruediger.Geib@telekom.de, draft-ietf-spring-segment-routing-mpls@ietf.org Cc: bruno.decraene@orange.com, spring@ietf.org References: From: Ahmed Bashandy Message-ID: Date: Sat, 27 Oct 2018 15:41:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5E11F2C38CCDC3CF1C967C55" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-14 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 22:42:05 -0000 This is a multi-part message in MIME format. --------------5E11F2C38CCDC3CF1C967C55 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks a lot for the comments I uploaded version 15 of the draft on Oct/23 See my response to your comments "#Ahmed" On 6/13/18 2:32 AM, Ruediger.Geib@telekom.de wrote: > > Dear authors, > > I’ve read the document and have one minor comment and 3 > editorials/nits, see below. As a general comment from a non-native > speaker I’d suggest a review by a native speaker (noting that one of > the authors is a native speaker). I went through that with some of the > informational rfcs I’ve edited and I think it helps to improve > readability of a standards track rfc. > > I appreciate, that the tie-break section is part of the draft. I admit > that I hardly can judge whether that is the right way of doing things. > Here I rely on the judgement of the authors and contributors. > > Related to contents, I think the editor & authors did a good job and > the draft is ready for publication. > > Regards, > > Ruediger > > Comments: > > Section 2.4 > >    Local segments MAY be allocated from the Segment Routing Local Block > >    (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as > >    long as it does not use a reserved label. The SRLB consists of the > >    range of local labels reserved by the node for certain local > >    segments. > > Would that read better, if the SRLB is defined before label allocation > is specified, i.e., switch sentences: > >    The SRLB consists of the > >    range of local labels reserved by the node for certain local > >    segments. Local segments MAY be allocated from the Segment Routing > Local Block > >    (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as > >    long as it does not use a reserved label. > #Ahmed: I have changed the wording of this paragraph based on comments from others. I hope the new wording is good > > ################# > > 2.6. Outgoing Label Collision > > 2^nd section > > the ingress node may not have exactly have the > >    same data > > Delete the second “have”. > #Ahmed: Done > > ################## > > 3.1. Example 1 > > Last para, last sentence > > The ECMP-awareness ensures that the traffic be load-shared between any > ECMP > >    path, in this case the two north and south links between R2 and R3. > > R2 has two links to R2 and R3, one of which is the north link, while > the other is the south link. Suggest to rewrite to: > > …ECMP path, in this case the two links between R2 and R3. > #Ahmed: Version 15 of the draft uses this wording (thanks). Just be aware that all examples have been moved to appendix > > Or > > …ECMP path, in this case the north and south links between R2 and R3. > > ################### > > 3.2. Example 2 > > Suppose the right most router R0 wants….. > > R0 is the leftmost router > #Ahmed: We got rid  of example 2 based on received comments > > #################### > > *Von:*spring [mailto:spring-bounces@ietf.org] *Im Auftrag von > *bruno.decraene@orange.com > *Gesendet:* Donnerstag, 7. Juni 2018 18:52 > *An:* SPRING WG List > *Cc:* draft-ietf-spring-segment-routing-mpls@ietf.org > *Betreff:* Re: [spring] WG Last Call for > draft-ietf-spring-segment-routing-mpls-13 > > Hi all, > > A quick update on the status of this WGLC: > > - All the authors have responded about IPR (thank you!). Still missing > replies from some contributors (Wim, Edward, Igor, Saku). I’ve sent > them a reminder this Monday. > > - Two people (Zafar, Adrian) have responded supporting publication. > > - No opposition. > > - Two persons have sent comments (Adrian, myself). Thanks Adrian. > > - Authors have not replied to any comment so far. > > - The WGLC period was scheduled to end tomorrow. > > I wish we had more support, reviews, and authors’ involvement to reply > to reviews. > > The WGLC is extended by a week. Please review the document and send > your comments to the list, no later than **June 15** > > Thank you, > > --Bruno > > *From:*bruno.decraene@orange.com > [mailto:bruno.decraene@orange.com] > *Sent:* Thursday, May 24, 2018 7:14 PM > *To:* SPRING WG List > *Cc:* draft-ietf-spring-segment-routing-mpls@ietf.org > > *Subject:* WG Last Call for draft-ietf-spring-segment-routing-mpls-13 > > Hello Working Group, > This email starts a Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-13 [1] which is considered > mature and ready for a final working group review. > Please read this document if you haven't read the most recent version > yet, and send your comments to the list, no later than *June 08*. > As a reminder, this document had already passed a WGLC more than a > year ago on version -06 [2], had been sent to the AD but then returned > to the WG. > Since then, the document has significantly changed, so please read it > again. In particular, it now includes the resolution in case of > incoming label collision. Hence it killed > draft-ietf-spring-conflict-resolution. > Both co-chairs co-author this document, hence: > - Shraddha has agreed to be the document shepherd... Thank you Shraddha. > - Martin, our AD, has agreed to evaluate the WG consensus. > Thank you, > Bruno, Rob > [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 > [2] > https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y > _________________________________________________________________________________________________________________________ > 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 --------------5E11F2C38CCDC3CF1C967C55 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Thanks a lot for the comments

I uploaded version 15 of the draft on Oct/23

See my response to your comments "#Ahmed"


On 6/13/18 2:32 AM, Ruediger.Geib@telekom.de wrote:

Dear authors,

 

I’ve read the document and have one minor comment and 3 editorials/nits, see below. As a general comment from a non-native speaker I’d suggest a review by a native speaker (noting that one of the authors is a native speaker). I went through that with some of the informational rfcs I’ve edited and I think it helps to improve readability of a standards track rfc.

 

I appreciate, that the tie-break section is part of the draft. I admit that I hardly can judge whether that is the right way of doing things. Here I rely on the judgement of the authors and contributors.

 

Related to contents, I think the editor & authors did a good job and the draft is ready for publication.

 

Regards,

 

Ruediger

 

 

Comments:

 

Section 2.4

 

   Local segments MAY be allocated from the Segment Routing Local Block

   (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as

   long as it does not use a reserved label. The SRLB consists of the

   range of local labels reserved by the node for certain local

   segments. 

 

Would that read better, if the SRLB is defined before label allocation is specified, i.e., switch sentences:

 

   The SRLB consists of the

   range of local labels reserved by the node for certain local

   segments. Local segments MAY be allocated from the Segment Routing Local Block

   (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as

   long as it does not use a reserved label.

 

#Ahmed:
I have changed the wording of this paragraph based on comments from others. I hope the new wording is good

#################

 

2.6. Outgoing Label Collision

 

2nd section

the ingress node may not have exactly have the

   same data

 

Delete the second “have”.

#Ahmed:
Done

 

##################

 

3.1. Example 1

 

Last para, last sentence

 

The ECMP-awareness ensures that the traffic be load-shared between any ECMP

   path, in this case the two north and south links between R2 and R3.

 

R2 has two links to R2 and R3, one of which is the north link, while the other is the south link. Suggest to rewrite to:

 

…ECMP path, in this case the two links between R2 and R3.

#Ahmed:
Version 15 of the draft uses this wording (thanks). Just be aware that all examples have been moved to appendix

 

Or

 

…ECMP path, in this case the north and south links between R2 and R3.

 

###################

 

3.2. Example 2

 

Suppose the right most router R0 wants…..

 

R0 is the leftmost router

 

#Ahmed:
We got rid  of example 2 based on received comments

####################

 

Von: spring [mailto:spring-bounces@ietf.org] Im Auftrag von bruno.decraene@orange.com
Gesendet: Donnerstag, 7. Juni 2018 18:52
An: SPRING WG List <spring@ietf.org>
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Betreff: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13

 

Hi all,

 

A quick update on the status of this WGLC:

 

- All the authors have responded about IPR (thank you!). Still missing replies from some contributors (Wim, Edward, Igor, Saku). I’ve sent them a reminder this Monday.

- Two people (Zafar, Adrian) have responded supporting publication.

- No opposition.

- Two persons have sent comments (Adrian, myself). Thanks Adrian.

- Authors have not replied to any comment so far.

- The WGLC period was scheduled to end tomorrow.

 

I wish we had more support, reviews, and authors’ involvement to reply to reviews.

 

The WGLC is extended by a week. Please review the document and send your comments to the list, no later than *June 15*

 

Thank you,

--Bruno

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

 

Hello Working Group,
    
This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review.
    
Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*.
 
As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG.
Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd... Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
_________________________________________________________________________________________________________________________
 
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

--------------5E11F2C38CCDC3CF1C967C55-- From nobody Sat Oct 27 16:01:21 2018 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 1AC7B1288BD; Sat, 27 Oct 2018 16:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 042c5BPXKvaO; Sat, 27 Oct 2018 16:00:56 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 04ACD126F72; Sat, 27 Oct 2018 16:00:56 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id bb7-v6so2059822plb.13; Sat, 27 Oct 2018 16:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=idb9Re8HvUjMotAbt3V39Fuj8bDVg3PiiEL349bwzi0=; b=sALDkbUj8XSCAIicLZ5qnUYOFS+PYd3/VFpLk50JWTJ/PLxw+IrsS36HXHXaGhTxqW C53rUGrRXV/hkSxCVMq8YQTHTxIsCm7JuEFz7WLp5NHkzhKQVpiD8JQZklwHGcpfZR+D qVF0qFukDUymLeIkUs4z+IvoSktDXHZfbK6AfMMBYU6bxNJKycnFl0AQlljH54Ql9zUb nQwazq2vG5K8LCMwt/mrTSw8JGuywtxQcI0JbeAxfKAzaNayAeNbWD+1hwGK8UZrrDTK zShuqIW+k/uEwNDciWbMYPlhWY2SsAnTwFw1f+0zA0A68fS6fLpFIiCbucZjGd9Mu5o6 YJzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=idb9Re8HvUjMotAbt3V39Fuj8bDVg3PiiEL349bwzi0=; b=IYBehxmIeeA22yvuMIB2nZp9u4n+0XOWBaX81teFFXMfoefpzHvMQU86Ud0eRDic7+ jAuNWQkPLXhu8Bvl00XZ4fcW2hGRDQf/eh88vyrT8VOIrBGAIbuUzZh9ori4KOHFumqb 7LcXUksqv158LKxzQn2SH2UJ6rqM9cBlTEEa5WzJxqU5ZnVxmKMUFZW2nXRM5/esHY8R KX4wwkBH4FHgJnjjN+AwWrREBQ5Y4bWjHHiYUq44gQ0QNVOXDVBXP11BSPXNPi//lZ49 9JijtTNnwn7Sj4q09BtIIWUR9+Tj9FmIVYKIH23wYIBnflnEh9bvFYGPL2Q8ndvnkpXg Dxnw== X-Gm-Message-State: AGRZ1gKLd+McCpcdzi4nHvKbaHKJDW1AoL3I1aX1v0f/3IgWTBJ5Ar4O Gu+SIo80bMTUzb+mI4WbiDg= X-Google-Smtp-Source: AJdET5fFWftVuG4ytu5337iW8EScUnMqxv8ERZWz0tUz7ZtJqhLo23+d3rwWSbJt7TwImCFqkvIZNg== X-Received: by 2002:a17:902:a717:: with SMTP id w23-v6mr8700148plq.24.1540681255264; Sat, 27 Oct 2018 16:00:55 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id o9-v6sm22602586pgn.30.2018.10.27.16.00.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 16:00:54 -0700 (PDT) To: Shraddha Hegde , Alexander Vainshtein Cc: "rtg-dir@ietf.org" , "'mpls@ietf.org'" , "'adrian@olddog.co.uk'" , "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" References: <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> From: Ahmed Bashandy Message-ID: Date: Sat, 27 Oct 2018 16:00:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FBDDA2F1CF0EC7364EEAFD08" Content-Language: en-US Archived-At: Subject: Re: [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 23:01:04 -0000 This is a multi-part message in MIME format. --------------FBDDA2F1CF0EC7364EEAFD08 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the comments While it is a clear violation of the SR architecture RFC (8402), more than one node advertising the same IPv4/6 PREFIX and both have the same prefix-SID value with "N" flag is not an incoming label collision because the label is associated with the same FEC, which is the prefix. Hence handling such violation is not an SR-MPLS problem because there is no incoming label collision and hence it it is outside the scope of this draft The second issue is which SID to choose for an SR-policy (be it a policy for TE, ti-lfa, uloop avoidance, security,..., etc). That is strictly a control layer functionality and is not specific to SR-MPLS. Hence it is outside the scope of this draft The third issue is the case where an anycast prefix is advertised with a prefix-SID sub-TLV by some (but not all) of the nodes that advertise that prefix. Again this is not an incoming label collision because the label is associated with a single FEC, which is the anycast prefix. On 7/19/18 8:30 PM, Shraddha Hegde wrote: > > Hi Ahmed, > > The Node-SIDs are expected to be unique to a node. > > “ > >    An IGP Node-SID MUST NOT be associated with a prefix that is owned by > >    more than one router within the same routing domain.†> > If two different nodes advertise same Node-SID, > > For Example Node A and B both advertise prefix 1.1.1.1 and associate a >  SID 1000 with N bit set. > > There is an anomaly here and IMO, this draft should address how to > handle this anomaly and whether TI-LFA and other > > Applications can use this SID as a Node-SID. > > Another slight variation of this case is a scenario where A and B both > advertise a prefix 1.1.1.1 and A assigns a Node-Sid > > Of 1000 and B does not assign any SID. > > Rgds > > Shraddha > > *From:*Alexander Vainshtein > *Sent:* Thursday, July 19, 2018 10:05 PM > *To:* Ahmed Bashandy > *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; > 'adrian@olddog.co.uk' ; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com) ; > Shraddha Hegde ; spring@ietf.org; > spring-chairs@ietf.org; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > *Subject:* RE: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Ahmed hi! > > Lots of thanks for your response. > > Of course Node SIDs are not different from any other Prefix SIDs when > it comes to the MPLS forwarding plane. > > But, IMHO, strictly speaking, this is correct for any other SID as well. > > You seem to ignore the difference between SR-MPLS and SRv6 with regard > to the life span of prefix SIDs in general and Node SIDs in > particular. From my POV this difference should be discussed in the draft. > > So it seems that we can only “agree to disagree†on the need to say > something specific about Node SIDs in the draft, and let the WG to > decide what to do about it. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] > *Sent:* Thursday, July 19, 2018 7:13 PM > *To:* Alexander Vainshtein > > *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org' > >; 'adrian@olddog.co.uk' > >; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com > ) > >; shraddha@juniper.net > ; spring@ietf.org > ; spring-chairs@ietf.org > ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Subject:* Re: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Thanks for the reply > > See inline > > Ahmed > > On 7/12/18 12:22 AM, Alexander Vainshtein wrote: > > Ahmed and all, > > I would like to expand on my comments (and your responses) about > the role of Node SIDs in SR-MPLS. > > I would like to bring your attention two points: > > 1.Node SIDs (and, in general, Prefix SIDs) in MPLS-SR are > different from the same in SRv6 because they require explicit > configuration action by the operator of SR domain. I.e., it is not > enough for a node to own some /32 or /128 prefix that is > advertised by IGP. The operator must explicitly configure the node > to use such a prefix as  Node SID and to assign to it a specific > index that is unique in the SR domain. From my POV, this > difference alone would qualify Node SIDs as a topic to be > discussed in the MPLS-SR Architecture > > draft. > > #Ahmed: I disagree with your POV. From the forwarding plane > perspective it does not make any difference whether a the label at the > top of an MPLS packet (representing the prefix-SID) identifies a node > or not. So from the SR-mpls forwarding point of view there is no > difference between a prefix-SID and a node-SID. If there is any place > in the SR-mpls draft where there is a need to handle a node-SID > different from a prefix SID, it would be great to point it out > > > 2.In addition, quite a few constructs associated with > SR-MPLS implicitly assume that each node in the SR-MPLS > domain is assigned with at least one Node SID. One example > can be found in the TI-LFA > > draft. This draft says in Section 4.2: > > > 4.2 > . > The repair node is a PQ node > >    When the repair node is in P(S,X), the repair list is made of a > >    single node segment to the repair node. > > In the scope of this section, the repair node is not adjacent to > the PLR, and therefore, to the best of my understanding,  “a > single node segment to the repair node†can be only the Node SID > of the repair node. Since repair nodes are computed dynamically, > this entire scheme depends on all nodes in the MPLS=SR domain >  having at least one Node SID each > > #Ahmed: The choice of the SID to identify an intermediate or exit > node(s) in an SR-policy is a control plane behavior, irrespective of > reason such policy is created (be it ti-lfa explicit path, uloop > avoidance explicit path, or some SR-TE explicit path). SR-Policy as > well as Ti-LFA and uloop avoidance are handled in separate drafts. So > just like the response to your previous comment, from forwarding plane > perspective it does not make any difference whether the label at the > top of an MPLS packet identifies a single or multiple nodes. > > . > > Hopefully these notes clarify my position on the subject. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*Alexander Vainshtein > *Sent:* Wednesday, July 11, 2018 12:02 PM > *To:* Ahmed Bashandy > > *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org > ' ; > 'adrian@olddog.co.uk ' > ; Jonathan > Hardwick (Jonathan.Hardwick@metaswitch.com > ) > > ; shraddha@juniper.net > ; spring@ietf.org > ; spring-chairs@ietf.org > ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Subject:* RE: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Ahmed, and all, > > Lots of thanks for a detailed response to my comments. > > Please see */inline below/*my position on each of them. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] > *Sent:* Wednesday, July 11, 2018 4:42 AM > *To:* Alexander Vainshtein >; spring-chairs@ietf.org > ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org > ' >; > 'adrian@olddog.co.uk ' > >; Jonathan > Hardwick (Jonathan.Hardwick@metaswitch.com > ) > >; shraddha@juniper.net > ; spring@ietf.org > > *Subject:* Re: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Thanks for thorough (and VERY clear) the review > > See inline #Ahmed > > Ahmed > > On 6/15/18 11:08 PM, Alexander Vainshtein wrote: > > Re-sending to  correct SPRING WG list. > > Sincere apologies for the delay caused by a typo. > > Thumb typed by Sasha Vainshtein > > ------------------------------------------------------------------------ > > *From:* Alexander Vainshtein > *Sent:* Sunday, June 10, 2018 10:43:52 AM > *To:* spring-chairs@ietf.org ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Cc:* spring@ietf.com ; > rtg-dir@ietf.org ; 'mpls@ietf.org > '; 'adrian@olddog.co.uk > '; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com > ); > shraddha@juniper.net > *Subject:* RE: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Explicitly adding Shraddha  who is the shepherd of this draft. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:* Alexander Vainshtein > *Sent:* Friday, June 8, 2018 5:43 PM > *To:* 'spring-chairs@ietf.org ' > ; > 'draft-ietf-spring-segment-routing-mpls.authors@ietf.org > ' > > > *Cc:* 'spring@ietf.com ' > ; rtg-dir@ietf.org > ; mpls@ietf.org > ; 'adrian@olddog.co.uk > ' > > *Subject:* RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Hello, > > I have been selected to do a routing directorate “early†> review of this draft: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > > > The routing directorate will, on request from the working > group chair, perform an “early†review of a draft before it is > submitted for publication to the IESG. The early review can be > performed at any time during the draft’s lifetime as a working > group document. The purpose of the early review depends on the > stage that the document has reached. As this document is > currently in the WG Last call, my focus for the review was to > determine whether the document is ready to be published. > Please consider my comments along with the other working group > last call comments. > > For more information about the Routing Directorate, please see > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > *Document*: draft-ietf-spring-segment-routing-mpls-13 > > *Reviewer*: Alexander (“Sashaâ€) Vainshtein > (alexander.vainshtein@ecitele.com > ) > > *Review Date*: 08-Jun-18 > > *Intended Status*: Proposed Standard. > > *Summary*: > > I have some minor concerns about this document that I think > should be resolved before it is submitted to the IESG. > > *Comments*: > > I consider this draft as an important  companion document to > the Segment Routing Architecture > > draft that, ideally, should augment definitions of the Segment > Routing (SR) notions and constructs given there with details > specific for the SR instantiation that uses the MPLS data > plane (SR-MPLS).  Many issues raised in my review reflect > either gaps that should be, but have not been, closed, or > inconsistencies between the two drafts. > > Since RFC 8287 > > is already published as a Standards Track RFC, I expect such > augmentation to be backward compatible with this document (or > to provide clear indications of required updates to this > document). And I include the MPLS WG into distribution list. > > This draft was not easy reading for me. In particular, the > style of Section 2.5 that discusses at length and in some > detail multiple “corner cases†resulting, presumably, from > misconfiguration, before it explains the basic (and relatively > simple) “normal†behavior, looks problematic to me. > > The WG Last Call has been extended by one week. Nevertheless, > I am sending out my comments > > *Major Issues*: None found > > #Ahmed: thanks a lot > > *Minor Issues*: Quite a few but, hopefully, easy to resolve. > > 1.*Encapsulation of SR-MPLS packets*: > > a.RFC 3032 (referenced by the draft) and RFC 5332 (*/not > mentioned in the draft/*) depend two encapsulations of labeled > packets - one for Downstream-allocated labels and another for > Upstream-allocated ones. > > #Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of > draft-ietf-spring-segment-routing-15, multicast is outside the > scope of SR. Hence the RFC was not referred to in the SR-MPLS draft > > */[[Sasha]] I would be satisfied with this response, would it not > be for the following text I see in Section 2.2 of the/**/SR Policy > Architecture > > /**/draft:/* > >    A variation of SR Policy can be used for packet replication.  A > >    candidate path could comprise multiple SID-Lists; one for each > >    replication path.  In such a scenario, packets are actually > >    replicated through each SID List of the SR Policy to realize a > point- > >    to-multipoint service delivery. > > */This looks to me as being very much multicast in SR, and, unless > you want to say that it is limited to SRv6, makes my question > relevant IMHO./* > > b.From my POV the ST-MPLS only uses Downstream-allocated > labels – but I expect the draft to state that explicitly, one > way or another. (If Upstream-allocated labels are relevant for > SR-MPLS, I would see it as a major gap, so I hope that this is > not the case). > > #Ahmed: I will add a statement in section 2.2 to mention that it > is down-stream allocated as you mentioned > > */[[Sasha]] This is quite unambiguous and, once added, would > resolve my comment in full – the previous comment notwithstanding. > In particular, it would imply that even labels representing BSIDs > of a SR Replication policies will be downstream-allocated. /* > > 2.*Label spaces in SR-MPLS*: > > a.RFC 3031 (referenced by the draft) defines per-platform and > per-interface label spaces, and RFC 5331 (*/not mentioned in > the draft/*) adds context-specific label spaces and context > labels. > > b.The draft does not say which of these are or are not > relevant for SR-MPLS > > c.From my POV: > > i.Labels representing all kinds of SIDs mentioned in the draft > MUST be allocated from the per-platform label space only > > ii.At the same time, instantiation of Mirror Segment IDs > defined in Section 5.1 of the Segment Routing Architecture > draft using MPLS data plane clearly calls for context labels > and context-specific label spaces > > d.I expect the draft to provide a clear-cut position on these > aspects of SR-MPLS. > > #Ahmed: I will add a statement to section 2.2 to say that the it > is per-platform. Regarding the function "mirroring", SR attaches a > *function* to each SID. The "mirroring" function is already > described in Section 5.1 of draft-ietf-spring-segment-routing and > is not specific to the MPLS forwarding plane. Hence there is no > need to re-mention it here because this document is trying to be > as specific as possible to the MPLS forwarding plane. General > functions attached to SID are described in the segment routing > architecture document or future documents. Furture documents > proposing new SR function must be as specific and clear as possible > > */[[Sasha]] Looks OK to me./* > > 3.*SR-MPLS and hierarchical LSPs*: > > a.SR LSPs that include more than one segment are hierarchical > LSPs from the POV of the MPLS data plane. Therefore some > (possibly, all) of the models for handling TTL and TC bits > that have been defined in RFC 3443 (*/not mentioned in the > draft/*) should apply to SR-MPLS > > b.RFC 8287 (*/not referenced in the draft/*) specifically > discussed operation of the LSP Traceroute function for SR LSPs > in the case when Pipe/Short Pipe model for TTL handling is used > > c.I expect the draft to provide at least some guidelines > regarding applicability of each specific model defined in RFC > 3443 (separately for TTL and TC bits) to SR-MPLS. > > #Ahmed: BY design, the instantiation of SR over the MPLS > forwarding plane (and hence this draft) does not modify the MPLS > forwarding plan behavior as it is mentioned in the first sentence > in Section 1. So the TTL behavior specified in rfc3443 is already > implied and there is no need to re-mention it here just like all > aspects of MPLS forwarding. RFC8287 is OAM-specific. SR-OAM is > handled in a separate document so is outside the scope of this draft > > */[[Sasha]] Unfortunately I do not think this is good enough. Let > me ask a specific question reflecting my concerns:/* > > */The head-end node sends SR-MPLS packets across a path defined by > an ordered set of SIDs with more than one SID in the list. Each > SID is represented by a label stack entry (LSE) in the MPLS label > stack, and the label field in each LSE is the label that matches > the corresponding SID. However, each LSE also includes the TTL and > TC fields. How does the head-end node set these fields in each of > the LSEs following the top one? This clearly depends on the model > (Uniform vs. Pipe/Short Pipe) implemented in each node that that > performs Next operation on the packet along the path – but the > head-end node usually is not aware of that. /* > > */RFC 8287 is relevant as an example here IMHO because it > recommends the following setting of TTL in Traceroute packets:/* > > -*/Set the TTL of all the labels above one that represents the > segment you are currently tracing to maximum/* > > -*/Set the TTL of the label one that represents the segment you > are currently tracing to the desired value (to be incremented > until end of segment is reached/* > > -*/Set the TTL of all the labels below one that represents the > segment you are currently tracing to 0./* > > */I expect the draft to provide some recommendations for traffic > (non-OAM) packets as well./* > > 4.*Inferring network layer protocol in SR-MPLS*: > > a.I wonder if the draft could provide any details on the > situation when a label that represents some kind of SID is the > bottom-of-stack label to be popped by the egress LER > > #ahmed: This is part of the "Next" function. It is described in > detail in this document. > > */[[Sasha]] NEXT function is mentioned in several places in the > document. Can you please point to the specific text that is > relevant for my question?/* > > b.For the reference, RFC 3032 says that “the identity of the > network layer protocol  must be inferable from the value of > the label which is popped from  the bottom of the stack, > possibly along with the contents  of the network layer header > itself†> > c.From my POV the following scenario indicates relevance of > this expectation for SR-MPLS: > > i.IS-IS is used for distributing both IPv4 and IPv6 > reachability in a given domain > > ii.An IS-IS adjacency over some dual-stack link is > established, and a single Adj-SID for this adjacency is advertised > > iii.The node that has assigned and advertised this Adj-SID > receives a labeled packet with the label representing this > Adj-SID being both the top and bottom-of-stack label > > iv.The implementers must be given unambiguous instructions for > forwarding the unlabeled packet via the dual-stack link as an > Ipv4 or an IPv6 packet. > > #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 > drafts, you will see all 3 protocol advertise different adj-SIDS > for IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the > "F-Flag" (section 2.2.1 in > draft-ietf-isis-segment-routing-extensions-18) to specify whether > the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft > attaches a prefix-SID to the prefix advertisement and hence > implies the identity of the protocol underneath the bottom most > label. For any other "function" attached to a SID, it is part of > the specification of this function to describe what happens when > the SID is represented by a label in the MPLS forwarding plane and > this label is the bottom most label > > */[[Sasha]] OK, got it. This issue is resolved./* > > 5.*Resolution**of Conflicts*: Are the > > a.Are the conflict resolution procedures listed in section 2.5 > mandatory to implement? > > b.If they are mandatory to implement, are they also mandatory > to deploy, or can the operators simply treat any detected > conflict as requiring human intervention and preventing normal > operation of SR-MPLS? > > #Ahmed: They are recommended. I will modify the paragraph after > the first 3 bullets in Section 2.5 to say that it is recommeded. > > */[[Sasha]] OK. However, it would be nice if you could refer > separately for “RECOMMENDED to implement†and “RECOMMENDED to > deployâ€.  The latter probably requires a configuration knob for > enabling conflict resolution rules (if they are implemented). /* > > c.For the reference, the IETF capitalized MUST appears just in > a few places in Section 2.5, and each appearance has very > narrow context: > > i.For MCCs where the "Topology" and/or "Algorithm" fields are > not defined, the numerical value of zero MUST be used for > these two fields > > ii.If the same set of FECs are attached to the same label > "L1", then the tie-breaking rules MUST always select the same > FEC irrespective of the order in which the FECs and the label > "L1" are received. In other words, the tie-breaking rule MUST > be deterministic. > > iii.An implementation of explicit SID assignment MUST > guarantee collision freeness on the same router > > From my POV, it is not possible to infer the answer to my > question from these statements. Some explicit statement is > required. > > #Ahmed: I agree with you POV and as mentioned in my reply to items > (a) and (b), I will modify the paragraph to say that it is > RECOMMENDED to answer you questions in items (a) and (b) > > d.The tie-breaking rules in section 2.5.1 include some > specific values for encoding FEC types and address families – > but these values are not supposed to appear in any IANA > registries (because the draft does not request any IANA > actions). Can you please clarify what is so special about > these values? > > #Ahmed: There is no significance to the values but there is a > significance to the order among them. I will modify the text to > clarify that > > */[[Sasha]] OK. /* > > e.I also doubt that comparison of FECs that represent IPv4 and > IPv6 prefix SIDs makes much sense (for conflict resolution or > else), because, among other things, there are valid scenarios > when an IPv4 /32 prefix is embedded in an IPv6 /128 one. > > #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that > embeds an IPv4 prefix is different from the IPv4 prefix. The > specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP > treat IPv4 and IPv6 prefixes separately, including the IPV6 > prefixes with embedded IPv4 ones. Besides not all IPv6 prefixes > embed IPv4 prefix in them. Hence the distinction between IPv4 and > IPv6 prefixes is quite clear > > */[[Sasha]] My concern was mainly about IPv4-mapped IPv6 > addresses. Quoting from RFC 4291:/* > > > *2.5.5.2* > *.  > IPv4-Mapped IPv6 Address* > >    A second type of IPv6 address that holds an embedded IPv4 > address is > >    defined. This address type is used to represent the addresses of > > IPv4 nodes as IPv6 addresses. > > *//* > > */From my POV this means that a /128 prefix associated with an > IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 > address that was mapped to this IPv6 address represent the same > entity. This understanding fully matches usage of IPv4-mapped IPv6 > addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC > 4798. However, the comparison rules you have defined will treat > them as two different prefixes.  I wonder if these rules, in the > case of a conflict, could result in preferring the IPv6 prefix to > an IPv4 one and therefore loosing MPLS connectivity for the > ingress PE of a 6VPE service to its egress PE?/* > > f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not > sure all SID types defined in the Segment Routing Architecture > draft can be unambiguously mapped to one of these types. > Problematic examples include at least the following: > > i.Parallel Adjacency SID > > ii.Mirror SID > > Explicit mapping of SID types to SR-MPLS FEC types would be > most useful IMO. If some SID types cannot be mapped to SR-MPLS > FECs, this must be explicitly stated in the draft. > > #Ahmed: > Parallel adjacency SID are handled in the type "(next-hop, > outgoing interface)" > > */[[Sasha]] OK/* > > > Mirror SID is a type of binding-SID as mentioned in Section 5.1 in > the SR architecture draft (draft-ietf-spring-segment-routing-15). > Also as described in Section 2.4 > draft-ietf-isis-segment-routing-extensions-18 (also see the > equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is > identified by a prefix. Hence it is covered by the type "(Prefix, > Routing Instance, Topology, Algorithm)" > > */[[Sasha]] I respectfully disagree. There is definitely no > mention of Algorithm in the definition of the Mirror SID. /* > > 6.*Node SIDs in SR-MPLS*: > > a.Node SIDs are explicitly defined and discussed in the > Segment Routing Architecture draft but are not mentioned even > once in this draft > > b.AFAIK, the common implementation practice today includes > assignment of at least one Node SID to every node in the > SR-MPLS domain > > c.Is there a requirement to assign at least one Node SID per > {routing instance, topology, algorithm} in SR-MPLS? If not, > can the authors explain expected behavior of such a node? (See > also my comment about routing instances below). > > #Ahmed: A Node-SID is a special case of prefix-SID. So there > nothing specific about it from the MPLS forwarding plane point of > view. Similarly from a standard tracks draft point of view, there > is no requirement to assign a SID to every prefix just like there > is no requirement to bind every prefix to an LDP label. Common > and/or recommended practices or description of deployment > scenarios are more befitting to BCP or informational drafts. This > draft is a standards track draft > > */[[Sasha]] Well, you’ve just said that conflict resolution rules > are RECOMMENDED, and this is quite common in the Standards Track > RFCs. /* > > > If a {routing instance, topology, algorithm} is not assigned a > SID, then this FEC is totally irrelavant to this draft and hence > describing how a node treats it is totally outside the scope of > this draft > > */[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs > mention routing instances that can be associated with the prefix, > so I think that your reference to it is incorrect./* > > */What’s more I suspect that Node SIDs represent the most used > special case of Prefix SIDs with Anycast SIDs being quite behind. >  Therefore some recommendation pertaining to the usage of Node > SIDs would be very much in place IMHO. /* > > 7.*SRGB Size in SR-MPLS*: > > a.The draft correctly treats the situation when an index > assigned to some global SID cannot be mapped to a label using > the procedure in Section 2.4 as a conflict. > > b.At the same time the draft does not define any minimum size > of SRGB (be it defined as a single contiguous block or as a > sequence of such blocks) that MUST be implemented by all > SR-capable nodes > > c.I suspect that lack of such a definition could be > detrimental to interoperability of SR-MPLS solutions. AFAIK, > the IETF has been following, for quite some time, a policy > that some reasonable MUST-to-implement defaults should be > assigned for all configurable parameters exactly in order to > prevent this. > > #Ahmed: This document specifies how the SRGB is used and the > behavior of routers when a prefix-SID index maps to a label inside > and/or outside the SRGB. The actual size of the SRGB is a task in > partitioning the label space, which is very specific to a > particular deployment scenario. So IMO it is outside the scope of > a standards track document. Now that SR-MPLS is deployed in many > places, I expect the community to gain sufficient experience to > recommend (or not recommend) a particular minimum/maximum size for > the SRGB is some future informational or BCP draft/RFC > > */[[Sasha]] My reading of your response is that minimum size of > SRGB is an issue for future study. Can you please just add this to > the draft?/* > > 8.*Algorithms and Prefix SIDs*: > > a.The draft mentions Algorithms (as part of SR-MPLS Prefix > FEC) in, but it does not explicitly link them with the > Prefix-SID algorithms defined in section 3.1.1 of the Segment > Routing Architecture draft > > #Ahmed: I will just add the reference > [I-D.ietf-spring-segment-routing] right beside the first time > "Algorithm" is mentioned > > */[[Sasha]] OK/* > > b.From my POV, the draft should explicitly state that the > default Prefix-SID algorithm MUST be implemented in all > SR-MPLS-compliant routers. > > #Ahmed: The specification of what path calculation method should > or must be supported is a routing protocol property not a > forwarding plane property. In fact, the choice of a path > calculation method or algorithm is completely orthogonal to the > routed protocol. Hence mandating the support of a particular > routing algorithm is beyond the scope of this document. > > */[[Sasha]] OK/* > > c.The Segment Routing Architecture draft states (in section > 3.1.3) that “Support of multiple algorithms applies to SRv6â€. > But neither draft states whether multiple algorithms apply to > SR-MPLS. Can you please clarify this point? > > #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in > draft-ietf-spring-segment-routing-15 discusses the support of > multiple algorithms. So it is implied that the concept of > algorithm applies to SR-MPLS. Hence there is no need to re-mention > it here > > */[[Sasha]] The paragraph to which you refer only says that if a > packet with the active Prefix-SID that is associated with a > specific algorithm is received by a node that does not support > this algorithm, this packet will be discarded. If this is the only > type of support for multiple algorithms SR provides, it is not > very useful IMHO/**/. /* > > 9.*Routing instances and the context for Prefix-SIDs*: > > a.The Segment Routing Architecture draft states in Section 3.1 > that the “context for an IGP-Prefix segment includes the > prefix, topology, and algorithm†> > b.This draft seems to define (in section 2.5) the context for > the Prefix SID as “Prefix, Routing Instance, Topology, > Algorithm†where â€a routing instance is identified by a single > incoming label downloader to FIB†(but the notion of the label > downloader to FIB is not defined). > > c.These two definitions look different to me. > > d.At the very least I would expect alignment between the > definitions of context for the Prefix-SID between the two > drafts. Preferably, the definition given in the Segment > Routing Architecture draft should be used in both drafts. > > #Ahmed: The context of the section 2.5 is limited to the > resolution of local label collision. The use of "routing instance" > in section 2.5 is just there for tie-breaking if there is local > label collision. > > */[[Sasha]] I have already mentioned that “routing instances†are > not defined in any the drafts dealing with SR Extensions for IGPs. > So I do not understand how the conflict resolution procedure is > supposed to use this. And in any case the difference between two > definitions of the context of Prefix-SID requires some explanation./* > > > > 10.*Example of PUSH operation in Section 2.10.1*: > > a.The first para of this section begins with the sentence > “Suppose an MCC on a router "R0" determines that PUSH or > CONTINUE   operation is to be applied to an incoming packet > whose active SID is the global SID "Si"â€. In the context of > SR-MPLS this means (to me) that the incoming packet is a > labeled packet and its top label matches the global SID “Siâ€. > > b.However, the example for PUSH operation in the next para of > this section is the case of an (unlabeled) IP packet with the > destination address covered by the IP prefix for which “Si†> has been assigned. > > c.From my POV: > > i.Mapping unlabeled packets to SIDs is indeed out of scope of > the draft. Therefore an example of a PUSH operation that is > applied to a labeled packet (with the active SID inferred from > the top label in the stack) is preferable. > > ii.Valid examples of  PUSH operation applied to a labeled > incoming packet can be found in Sections 4.2 or 4.3 of the > TI-LFA > > draft > > #Ahmed: I do not understand your concern here:) > > */[[Sasha]] I think it is pretty clear: can you provide an example > of a PUSH operation applied to a labeled packet instead of your > current example?/* > > *Nits*: > > 1.I concur with Adrian regarding numerous nits he has reported > in his WG LC Comment > . > I would like to thank Adrian for an excellent review that have > saved me lots of hard work. > > #Ahmed: I also agree that Adrian's review is exceptional. I > believe I addressed all his comments in the latest version. > > 2.In addition, I’d like to report the following nits: > > a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA > > draft) > > #Ahmed: Already done in the latest version*/[[Sasha]] OK/* > > b.TI-LFA draft is referenced in the text of Section 2.11.1, > but there is no matching reference in the “References†section > (probably, Informational) > > #Ahmed: Already done in the latest version*/[[Sasha]] OK/* > > c.“zero Algorithm†in Section 2.5 (immediately above Section > 2.5.1) must be replaced with “default algorithmâ€. Similarly, > “non-zero Algorithm†should be replaced with “non-default > algorithm†> > #Ahmed: Will be done in the next version*/[[Sasha]] /* OK > > 3.I think that RFC 3443 and RFC 5332 should be listed as > Normative references in this draft while RFC 5331 and RFC 8277 > should be listed as Informative references. This would improve > the readability of the draft without any impact on its > advancement. > > #Ahmed RFC5331 describes upstream label assignment. As you > mentioned above (and I will modify the draft to indicate that) > SR-MPLS behavior is similar to downstream label assignment. RFC > 3443 describes TTL behavior. This is an MPLS forwarding behavior. > As mentioned in the draft, SR-MPLS does not modify at the MPLS > forwarding behavior > > */[[Sasha]] Regarding RFC 5331 – you may skip this reference if > you state (as discussed below) that SR-MPLS only allocates labels > from the per-platform label space. Regarding RFC 3443 – I do not > think that you can fully avoid discussion of Uniform and > Pipe/Short Pipe models, and therefore you will need this reference./* > > > > Hopefully, these comments will be useful. > > #Ahmed: They are certainly quite useful. Thanks a lot > > Regards, > > Sasha > > Office: +972-39266302 > > Cell:      +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If > you have received this > transmission in error, please inform us by e-mail, phone or > fax, and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this > transmission in error, please inform us by e-mail, phone or fax, > and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ > --------------FBDDA2F1CF0EC7364EEAFD08 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks for the comments

While it is a clear violation of the SR architecture RFC (8402), more than one node advertising the same IPv4/6 PREFIX and both have the same prefix-SID value with "N" flag is not an incoming label collision because the label is associated with the same FEC, which is the prefix. 

Hence handling such violation is not an SR-MPLS problem because there is no incoming label collision and hence it it is outside the scope of this draft


The second issue is which SID to choose for an SR-policy (be it a policy for TE, ti-lfa, uloop avoidance, security,..., etc). That is strictly a control layer functionality and is not specific to SR-MPLS. Hence it is outside the scope of this draft


The third issue is the case where an anycast prefix is advertised with a prefix-SID sub-TLV by some (but not all) of the nodes that advertise that prefix. Again this is not an incoming label collision because the label is associated with a single FEC, which is the anycast prefix.


On 7/19/18 8:30 PM, Shraddha Hegde wrote:

Hi Ahmed,

 

The Node-SIDs are expected to be unique to a node. 

“

   An IGP Node-SID MUST NOT be associated with a prefix that is owned by

   more than one router within the same routing domain.â€

 

If two different nodes advertise same Node-SID,

         For Example Node A and B both advertise prefix 1.1.1.1 and associate a  SID 1000 with N bit set.

There is an anomaly here and IMO, this draft should address how to handle this anomaly and whether TI-LFA and other

Applications can use this SID as a Node-SID.

Another slight variation of this case is a scenario where A and B both advertise a prefix 1.1.1.1 and A assigns a Node-Sid

Of 1000 and B does not assign any SID.

 

Rgds

Shraddha

 

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Sent: Thursday, July 19, 2018 10:05 PM
To: Ahmed Bashandy <abashandy.ietf@gmail.com>
Cc: rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; 'adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; Shraddha Hegde <shraddha@juniper.net>; spring@ietf.org; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Ahmed hi!

Lots of thanks for your response.

Of course Node SIDs are not different from any other Prefix SIDs when it comes to the MPLS forwarding plane.

But, IMHO, strictly speaking, this is correct for any other SID as well.

You seem to ignore the difference between SR-MPLS and SRv6 with regard to the life span of prefix SIDs in general and Node SIDs in particular. From my POV this difference should be discussed in the draft.

So it seems that we can only “agree to disagree†on the need to say something specific about Node SIDs in the draft, and let the WG to decide what to do about it.

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Thursday, July 19, 2018 7:13 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; 'adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Thanks for the reply

See inline

Ahmed

 

On 7/12/18 12:22 AM, Alexander Vainshtein wrote:

Ahmed and all,

I would like to expand on my comments (and your responses) about the role of Node SIDs in SR-MPLS.

I would like to bring your attention two points:

1.       Node SIDs (and, in general, Prefix SIDs) in MPLS-SR are different from the same in SRv6 because they require explicit configuration action by the operator of SR domain. I.e., it is not enough for a node to own some /32 or /128 prefix that is advertised by IGP. The operator must explicitly configure the node to use such a prefix as  Node SID and to assign to it a specific index that is unique in the SR domain. From my POV, this difference alone would qualify Node SIDs as a topic to be discussed in the MPLS-SR Architecture draft.

#Ahmed: I disagree with your POV. From the forwarding plane perspective it does not make any difference whether a the label at the top of an MPLS packet (representing the prefix-SID) identifies a node or not. So from the SR-mpls forwarding point of view there is no difference between a prefix-SID and a node-SID. If there is any place in the SR-mpls draft where there is a need to handle a node-SID different from a prefix SID, it would be great to point it out

2.      In addition, quite a few constructs associated with SR-MPLS implicitly assume that each node in the SR-MPLS domain is assigned with at least one Node SID. One example can be found in the TI-LFA draft. This draft says in Section 4.2:

 

4.2. The repair node is a PQ node

 
 
   When the repair node is in P(S,X), the repair list is made of a
   single node segment to the repair node.

In the scope of this section, the repair node is not adjacent to the PLR, and therefore, to the best of my understanding,  “a single node segment to the repair node†can be only the Node SID of the repair node. Since repair nodes are computed dynamically, this entire scheme depends on all nodes in the MPLS=SR domain  having at least one Node SID each

#Ahmed: The choice of the SID to identify an intermediate or exit node(s) in an SR-policy is a control plane behavior, irrespective of reason such policy is created (be it ti-lfa explicit path, uloop avoidance explicit path, or some SR-TE explicit path). SR-Policy as well as Ti-LFA and uloop avoidance are handled in separate drafts. So just like the response to your previous comment, from forwarding plane perspective it does not make any difference whether the label at the top of an MPLS packet identifies a single or multiple nodes.

.

 

Hopefully these notes clarify my position on the subject.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Alexander Vainshtein
Sent: Wednesday, July 11, 2018 12:02 PM
To: Ahmed Bashandy <abashandy.ietf@gmail.com>
Cc: rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; 'adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Ahmed, and all,

Lots of thanks for a detailed response to my comments.

Please see inline below my position on each of them.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Wednesday, July 11, 2018 4:42 AM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Cc: rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; 'adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; shraddha@juniper.net; spring@ietf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Thanks for thorough (and VERY clear) the review

See inline #Ahmed

 

Ahmed

 

 

On 6/15/18 11:08 PM, Alexander Vainshtein wrote:

Re-sending to  correct SPRING WG list.

Sincere apologies for the delay caused by a typo.

Thumb typed by Sasha Vainshtein

 

From: Alexander Vainshtein
Sent: Sunday, June 10, 2018 10:43:52 AM
To: spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Cc: spring@ietf.com; rtg-dir@ietf.org; 'mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Explicitly adding Shraddha  who is the shepherd of this draft.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

 

Hello,

I have been selected to do a routing directorate “early†review of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

 

The routing directorate will, on request from the working group chair, perform an “early†review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is currently in the WG Last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

 

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

 

Document: draft-ietf-spring-segment-routing-mpls-13

Reviewer: Alexander (“Sashaâ€) Vainshtein (alexander.vainshtein@ecitele.com)

Review Date: 08-Jun-18

Intended Status: Proposed Standard.

 

Summary:

 

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

 

Comments:

 

I consider this draft as an important  companion document to the Segment Routing Architecture draft that, ideally, should augment definitions of the Segment Routing (SR) notions and constructs given there with details specific for the SR instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised in my review reflect either gaps that should be, but have not been, closed, or inconsistencies between the two drafts.

 

 

Since RFC 8287 is already published as a Standards Track RFC, I expect such augmentation to be backward compatible with this document (or to provide clear indications of required updates to this document). And I include the MPLS WG into distribution list.

 

This draft was not easy reading for me. In particular, the style of Section 2.5 that discusses at length and in some detail multiple “corner cases†resulting, presumably, from misconfiguration, before it explains the basic (and relatively simple) “normal†behavior, looks problematic to me.

 

The WG Last Call has been extended by one week. Nevertheless, I am sending out my comments

 

Major Issues: None found

#Ahmed: thanks a lot

 

Minor Issues: Quite a few but, hopefully, easy to resolve.

 

1.    Encapsulation of SR-MPLS packets:

a.    RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned in the draft) depend two encapsulations of labeled packets - one for Downstream-allocated labels and another for Upstream-allocated ones.

#Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of draft-ietf-spring-segment-routing-15, multicast is outside the scope of SR. Hence the RFC was not referred to in the SR-MPLS draft

[[Sasha]] I would be satisfied with this response, would it not be for the following text I see in Section 2.2 of the SR Policy Architecture draft:

   A variation of SR Policy can be used for packet replication.  A

   candidate path could comprise multiple SID-Lists; one for each

   replication path.  In such a scenario, packets are actually

   replicated through each SID List of the SR Policy to realize a point-

   to-multipoint service delivery.

 

This looks to me as being very much multicast in SR, and, unless you want to say that it is limited to SRv6, makes my question relevant IMHO.

b.    From my POV the ST-MPLS only uses Downstream-allocated labels – but I expect the draft to state that explicitly, one way or another. (If Upstream-allocated labels are relevant for SR-MPLS, I would see it as a major gap, so I hope that this is not the case).

#Ahmed: I will add a statement in section 2.2 to mention that it is down-stream allocated as you mentioned

[[Sasha]] This is quite unambiguous and, once added, would resolve my comment in full – the previous comment notwithstanding. In particular, it would imply that even labels representing BSIDs of a SR Replication policies will be downstream-allocated.

 

2.    Label spaces in SR-MPLS:

a.    RFC 3031 (referenced by the draft) defines per-platform and per-interface label spaces, and RFC 5331 (not mentioned in the draft) adds context-specific label spaces and context labels.

b.    The draft does not say which of these are or are not relevant for SR-MPLS

c.    From my POV:

                                         i.    Labels representing all kinds of SIDs mentioned in the draft MUST be allocated from the per-platform label space only

                                        ii.    At the same time, instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment Routing Architecture draft using MPLS data plane clearly calls for context labels and context-specific label spaces

d.    I expect the draft to provide a clear-cut position on these aspects of SR-MPLS.

#Ahmed: I will add a statement to section 2.2 to say that the it is per-platform. Regarding the function "mirroring", SR attaches a *function* to each SID. The "mirroring" function is already described in Section 5.1 of draft-ietf-spring-segment-routing and is not specific to the MPLS forwarding plane. Hence there is no need to re-mention it here because this document is trying to be as specific as possible to the MPLS forwarding plane. General functions attached to SID are described in the segment routing architecture document or future documents. Furture documents proposing new SR function must be as specific and clear as possible

[[Sasha]] Looks OK to me.

 

3.    SR-MPLS and hierarchical LSPs:

a.    SR LSPs that include more than one segment are hierarchical LSPs from the POV of the MPLS data plane. Therefore some (possibly, all) of the models for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned in the draft) should apply to SR-MPLS

b.    RFC 8287 (not referenced in the draft) specifically discussed operation of the LSP Traceroute function for SR LSPs in the case when Pipe/Short Pipe model for TTL handling is used

c.    I expect the draft to provide at least some guidelines regarding applicability of each specific model defined in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.

#Ahmed: BY design, the instantiation of SR over the MPLS forwarding plane (and hence this draft) does not modify the MPLS forwarding plan behavior as it is mentioned in the first sentence in Section 1. So the TTL behavior specified in rfc3443 is already implied and there is no need to re-mention it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specific.  SR-OAM is handled in a separate document so is outside the scope of this draft

[[Sasha]] Unfortunately I do not think this is good enough. Let me ask a specific question reflecting my concerns:

The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.

RFC 8287 is relevant as an example here IMHO because it recommends the following setting of TTL in Traceroute packets:

-          Set the TTL of all the labels above one that represents the segment you are currently tracing to maximum

-          Set the TTL of the label one that represents the segment you are currently tracing to the desired value (to be incremented until end of segment is reached

-          Set the TTL of all the labels below one that represents the segment you are currently tracing to 0.

I expect the draft to provide some recommendations for traffic (non-OAM) packets as well.

 

4.    Inferring network layer protocol in SR-MPLS:

a.    I wonder if the draft could provide any details on the situation when a label that represents some kind of SID is the bottom-of-stack label to be popped by the egress LER

#ahmed: This is part of the "Next" function. It is described in detail in this document.

[[Sasha]] NEXT function is mentioned in several places in the document. Can you please point to the specific text that is relevant for my question?

 

b.    For the reference, RFC 3032 says that “the identity of the network layer protocol  must be inferable from the value of the label which is popped from  the bottom of the stack, possibly along with the contents  of the network layer header itselfâ€

c.    From my POV the following scenario indicates relevance of this expectation for SR-MPLS:

                                         i.    IS-IS is used for distributing both IPv4 and IPv6 reachability in a given domain

                                        ii.    An IS-IS adjacency over some dual-stack link is established, and a single Adj-SID for this adjacency is advertised

                                       iii.    The node that has assigned and advertised this Adj-SID receives a labeled packet with the label representing this Adj-SID being both the top and bottom-of-stack label

                                       iv.    The implementers must be given unambiguous instructions for forwarding the unlabeled packet via the dual-stack link as an Ipv4 or an IPv6 packet.

#Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to specify whether the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a prefix-SID to the prefix advertisement and hence implies the identity of the protocol underneath the bottom most label. For any other "function" attached to a SID, it is part of the specification of this function to describe what happens when the SID is represented by a label in the MPLS forwarding plane and this label is the bottom most label

[[Sasha]] OK, got it. This issue is resolved.

 

5.    Resolution of Conflicts: Are the

a.    Are the conflict resolution procedures listed in section 2.5 mandatory to implement?

b.    If they are mandatory to implement, are they also mandatory to deploy, or can the operators simply treat any detected conflict as requiring human intervention and preventing normal operation of SR-MPLS?

#Ahmed: They are recommended. I will modify the paragraph after the first 3 bullets in Section 2.5 to say that it is recommeded.  

[[Sasha]] OK. However, it would be nice if you could refer separately for “RECOMMENDED to implement†and “RECOMMENDED to deployâ€.  The latter probably requires a configuration knob for enabling conflict resolution rules (if they are implemented).

c.    For the reference, the IETF capitalized MUST appears just in a few places in Section 2.5, and each appearance has very narrow context:

                                         i.    For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zero MUST be used for these two fields

                                        ii.    If the same set of FECs are attached to the same label "L1", then the tie-breaking rules MUST always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic.

                                       iii.    An implementation of explicit SID assignment MUST guarantee collision freeness on the same router

From my POV, it is not possible to infer the answer to my question from these statements. Some explicit statement is required.

#Ahmed: I agree with you POV and as mentioned in my reply to items (a) and (b), I will modify the paragraph to say that it is RECOMMENDED to answer you questions in items (a) and (b)

d.    The tie-breaking rules in section 2.5.1 include some specific values for encoding FEC types and address families – but these values are not supposed to appear in any IANA registries (because the draft does not request any IANA actions). Can you please clarify what is so special about these values?

#Ahmed: There is no significance to the values but there is a significance to the order among them. I will modify the text to clarify that

[[Sasha]] OK.

 

e.    I also doubt that comparison of FECs that represent IPv4 and IPv6 prefix SIDs makes much sense (for conflict resolution or else), because, among other things, there are valid scenarios when an IPv4 /32 prefix is embedded in an IPv6 /128 one.

#Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that embeds an IPv4 prefix is different from the IPv4 prefix. The specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately, including the IPV6 prefixes with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix in them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear

[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. Quoting from RFC 4291:

2.5.5.2.  IPv4-Mapped IPv6 Address

 

 

   A second type of IPv6 address that holds an embedded IPv4 address is

   defined.  This address type is used to represent the addresses of

   IPv4 nodes as IPv6 addresses.

 

From my POV this means that a /128 prefix associated with an IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 address that was mapped to this IPv6 address represent the same entity. This understanding fully matches usage of IPv4-mapped IPv6 addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. However, the comparison rules you have defined will treat them as two different prefixes.  I wonder if these rules, in the case of a conflict, could result in preferring the IPv6 prefix to an IPv4 one and therefore loosing MPLS connectivity for the ingress PE of a 6VPE service to its egress PE?

 

f.     Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure all SID types defined in the Segment Routing Architecture draft can be unambiguously mapped to one of these types. Problematic examples include at least the following:

                                         i.    Parallel Adjacency SID

                                        ii.    Mirror SID

Explicit mapping of SID types to SR-MPLS FEC types would be most useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, this must be explicitly stated in the draft.

#Ahmed:
Parallel adjacency SID are handled in the type "(next-hop, outgoing interface)"

[[Sasha]] OK


Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR architecture draft (draft-ietf-spring-segment-routing-15). Also as described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18 (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is identified by a prefix. Hence it is covered by the type "(Prefix, Routing Instance, Topology, Algorithm)"

[[Sasha]] I respectfully disagree. There is definitely no mention of Algorithm in the definition of the Mirror SID.

 

6.    Node SIDs in SR-MPLS:

a.    Node SIDs are explicitly defined and discussed in the Segment Routing Architecture draft but are not mentioned even once in this draft

b.    AFAIK, the common implementation practice today includes assignment of at least one Node SID to every node in the SR-MPLS domain

c.    Is there a requirement to assign at least one Node SID per {routing instance, topology, algorithm} in SR-MPLS? If not, can the authors explain expected behavior of such a node? (See also my comment about routing instances below).

#Ahmed: A Node-SID is a special case of prefix-SID. So there nothing specific about it from the MPLS forwarding plane point of view. Similarly from a standard tracks draft point of view, there is no requirement to assign a SID to every prefix just like there is no requirement to bind every prefix to an LDP label. Common and/or recommended practices or description of deployment scenarios are more befitting to BCP or informational drafts. This draft is a standards track draft

[[Sasha]] Well, you’ve just said that conflict resolution rules are RECOMMENDED, and this is quite common in the Standards Track RFCs.


If a {routing instance, topology, algorithm} is not assigned a SID, then this FEC is totally irrelavant to this draft and hence describing how a node treats it is totally outside the scope of this draft

[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention routing instances that can be associated with the prefix, so I think that your reference to it is incorrect.

What’s more I suspect that Node SIDs represent the most used special case of Prefix SIDs with Anycast SIDs being quite behind.  Therefore some recommendation pertaining to the usage of Node SIDs would be very much in place IMHO.

 

7.    SRGB Size in SR-MPLS:

a.    The draft correctly treats the situation when an index assigned to some global SID cannot be mapped to a label using the procedure in Section 2.4 as a conflict.

b.    At the same time the draft does not define any minimum size of SRGB (be it defined as a single contiguous block or as a sequence of such blocks) that MUST be implemented by all SR-capable nodes

c.    I suspect that lack of such a definition could be detrimental to interoperability of SR-MPLS solutions. AFAIK, the IETF has been following, for quite some time, a policy that some reasonable MUST-to-implement defaults should be assigned for all configurable parameters exactly in order to prevent this.

#Ahmed: This document specifies how the SRGB is used and the behavior of routers when a prefix-SID index maps to a label inside and/or outside the SRGB. The actual size of the SRGB is a task in partitioning the label space, which is very specific to a particular deployment scenario. So IMO it is outside the scope of a standards track document. Now that SR-MPLS is deployed in many places, I expect the community to gain sufficient experience to recommend (or not recommend) a particular minimum/maximum size for the SRGB is some future informational or BCP draft/RFC

[[Sasha]] My reading of your response is that minimum size of SRGB is an issue for future study. Can you please just add this to the draft?

 

8.    Algorithms and Prefix SIDs:

a.    The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, but it does not explicitly link them with the Prefix-SID algorithms defined in section 3.1.1 of the Segment Routing Architecture draft

#Ahmed: I will just add the reference [I-D.ietf-spring-segment-routing] right beside the first time "Algorithm" is mentioned

[[Sasha]] OK

 

b.    From my POV, the draft should explicitly state that the default Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.

#Ahmed: The specification of what path calculation method should or must be supported is a routing protocol property not a forwarding plane property. In fact, the choice of a path calculation method or algorithm is completely orthogonal to the routed protocol. Hence mandating the support of a particular routing algorithm is beyond the scope of this document.

[[Sasha]] OK

 

c.    The Segment Routing Architecture draft states (in section 3.1.3) that “Support of multiple algorithms applies to SRv6â€. But neither draft states whether multiple algorithms apply to SR-MPLS. Can you please clarify this point?

#Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in draft-ietf-spring-segment-routing-15 discusses the support of multiple algorithms. So it is implied that the concept of algorithm applies to SR-MPLS. Hence there is no need to re-mention it here

[[Sasha]] The paragraph to which you refer only says that if a packet with the active Prefix-SID that is associated with a specific algorithm is received by a node that does not support this algorithm, this packet will be discarded. If this is the only type of support for multiple algorithms SR provides, it is not very useful IMHO.

 

9.    Routing instances and the context for Prefix-SIDs:

a.    The Segment Routing Architecture draft states in Section 3.1 that the “context for an IGP-Prefix segment includes the prefix, topology, and algorithmâ€

b.    This draft seems to define (in section 2.5) the context for the Prefix SID as “Prefix, Routing Instance, Topology, Algorithm†where â€a routing instance is identified by a single incoming label downloader to FIB†(but the notion of the label downloader to FIB is not defined).

c.    These two definitions look different to me.

d.    At the very least I would expect alignment between the definitions of context for the Prefix-SID between the two drafts. Preferably, the definition given in the Segment Routing Architecture draft should be used in both drafts.

#Ahmed: The context of the section 2.5 is limited to the resolution of local label collision. The use of "routing instance" in section 2.5 is just there for tie-breaking if there is local label collision.

[[Sasha]] I have already mentioned that “routing instances†are not defined in any the drafts dealing with SR Extensions for IGPs. So I do not understand how the conflict resolution procedure is supposed to use this. And in any case the difference between two definitions of the context of Prefix-SID requires some explanation.



10. Example of PUSH operation in Section 2.10.1:

a.    The first para of this section begins with the sentence “Suppose an MCC on a router "R0" determines that PUSH or CONTINUE   operation is to be applied to an incoming packet whose active SID is the global SID "Si"â€. In the context of SR-MPLS this means (to me) that the incoming packet is a labeled packet and its top label matches the global SID “Siâ€.

b.    However, the example for PUSH operation in the next para of this section is the case of an (unlabeled) IP packet with the destination address covered by the IP prefix for which “Si†has been assigned.

c.    From my POV:

                                         i.    Mapping unlabeled packets to SIDs is indeed out of scope of the draft. Therefore an example of a PUSH operation that is applied to a labeled packet (with the active SID inferred from the top label in the stack) is preferable.

                                        ii.    Valid examples of  PUSH operation applied to a labeled incoming packet can be found in Sections 4.2 or 4.3 of the TI-LFA draft

 

#Ahmed: I do not understand your concern here:)

[[Sasha]] I think it is pretty clear: can you provide an example of a PUSH operation applied to a labeled packet instead of your current example?

 

Nits:

1.    I concur with Adrian regarding numerous nits he has reported in his WG LC Comment. I would like to thank Adrian for an excellent review that have saved me lots of hard work.

#Ahmed: I also agree that Adrian's review is exceptional. I believe I addressed all his comments in the latest version.

2.    In addition, I’d like to report the following nits:

a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA draft)

#Ahmed: Already done in the latest version[[Sasha]] OK

b.    TI-LFA draft is referenced in the text of Section 2.11.1, but there is no matching reference in the “References†section (probably, Informational)

#Ahmed: Already done in the latest version[[Sasha]] OK

c.    “zero Algorithm†in Section 2.5 (immediately above Section 2.5.1) must be replaced with “default algorithmâ€. Similarly, “non-zero Algorithm†should be replaced with “non-default algorithmâ€

#Ahmed: Will be done in the next version[[Sasha]]  OK

3.    I think that RFC 3443 and RFC 5332 should be listed as Normative references in this draft while RFC 5331 and RFC 8277 should be listed as Informative references. This would improve the readability of the draft without any impact on its advancement.

 

#Ahmed RFC5331 describes upstream label assignment. As you mentioned above (and I will modify the draft to indicate that) SR-MPLS behavior is similar to downstream label assignment. RFC 3443 describes TTL behavior. This is an MPLS forwarding behavior. As mentioned in the draft, SR-MPLS does not modify at the MPLS forwarding behavior

[[Sasha]] Regarding RFC 5331 – you may skip this reference if you state (as discussed below) that SR-MPLS only allocates labels from the per-platform label space. Regarding RFC 3443 – I do not think that you can fully avoid discussion of Uniform and Pipe/Short Pipe models, and therefore you will need this reference.



Hopefully, these comments will be useful.

#Ahmed: They are certainly quite useful. Thanks a lot

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________


--------------FBDDA2F1CF0EC7364EEAFD08-- From nobody Sat Oct 27 18:02:57 2018 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 84181126DBF for ; Sat, 27 Oct 2018 18:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 g6Eju7sqXyCN for ; Sat, 27 Oct 2018 18:02:48 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 61353126CB6 for ; Sat, 27 Oct 2018 18:02:47 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id 23-v6so2197107pgc.8 for ; Sat, 27 Oct 2018 18:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0q/UVSlDVKafNhAayiso7YZaNq4CqCZZrh+c6BCjuWw=; b=BtN099OMI7zAnR73tK12f4mmB3mefAkAmNhp+JEzLSP1a/rlEHdOvU1+oo2Zg8C+zd nKMSCOrHiEDmsHiYXIN1AqiAM+aLytT5fnv1u0FMEM2y4Cz4DsYk6SWaWRvMKI2S6YdV M969KdIk0rMWY9OBv41snL+dW7jSaqniUzT1koJ5cC08VGF0xPPE3As3zG//lzGqdEKg Pa2VU1PbVxT7wbvdkVZUw11nEc/vkXCHfGGbAnVOPNTfZSO7EeMt7Lp37AkRQqA1gmr8 +MN0J7cBwKXP9O7QMeyiW0Yf7GXhu1dTSeN4gECJ5hU94HVCRCbKBqvFe9h6cNGVRP37 t6zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0q/UVSlDVKafNhAayiso7YZaNq4CqCZZrh+c6BCjuWw=; b=pJFb11hsKMU+X6NcjrTchE9prJp38XM2b/s1e1LEH+DWW8YPdKr9Fjo8CMMBODDFJY nCXnyYxaqqnrpqs3fueJQalc9FGcZMK7HKH4Lhb+TUMmPJj1EQ1odV+2BZm3QNpZ2gck NFwD5dJh8wDBaz3w6pO5VQlkOikrzE8Cc8gv9WNvYKelIH0ZrpFQvD5TnXxWN3gaWgQj 1uTF15JJgY6u4QguzqgV+tKxjfjpnTPQN0Lck3Dyghcj+B+Q2Vy9R7+//jmFqLT+gly5 kYNU1rlMY1ddv8LAO3lc9VlzVOIsTBNQ9d9yLjJWwgn2UKNpX/Lvn3Hghiouml+aMmws iIVg== X-Gm-Message-State: AGRZ1gJIQNbhEIL/MdyrA57ie/QazvRXBIk/W1m3+dMak3WDReYxBmq0 cWJlMrBGlhHx+QgIFfb5YCc= X-Google-Smtp-Source: AJdET5cgWU9xM2wlxv0lvDHL52QtBKz/ZDXMYPu1P2/FZQKJbgJylM/9sSq3yg4ixHppf8fmMrLIhw== X-Received: by 2002:a63:e505:: with SMTP id r5-v6mr8585720pgh.170.1540688567072; Sat, 27 Oct 2018 18:02:47 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id s2-v6sm16382802pgo.90.2018.10.27.18.02.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 18:02:46 -0700 (PDT) To: Alexander Vainshtein , "stephane.litkowski@orange.com" Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" , "shraddha@juniper.net" , "spring@ietf.org" References: <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> <8f6b91d0-27de-f92e-6908-598977a05e0d@gmail.com> <32502_1531913237_5B4F2415_32502_461_3_9E32478DFA9976438E7A22F69B08FF924B1FF359@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: Date: Sat, 27 Oct 2018 18:02:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E8F683FE2F33848379AE9D42" Content-Language: en-US Archived-At: Subject: Re: [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 01:02:55 -0000 This is a multi-part message in MIME format. --------------E8F683FE2F33848379AE9D42 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sasha I uploaded version 15. But I was not sure how to best address your concern So Please propose the wording/modifications that looks reasonable to you and I will be more than happy to incorporate them Ahmed (I replied to this email a little while ago but I am replying to it again with a cutdown on the list of receipts because the mailing list said the email is being held) On 7/25/18 12:20 AM, Alexander Vainshtein wrote: > > Stephane, > > Lots of thanks for your email, and apologies for a long delayed response. > > Regarding you reference to “BGP 3107 label over an LDP label over an > RSVP label to build an end-to-end transportâ€, I have looked up RFC > 8277  that has replaced RFC > 3107, and found there the following */explicit/* statement: > >    When pushing labels onto a packet's label stack, the Time-to-Live >    (TTL) field ([RFC3032 ], > [RFC3443 ]) and the Traffic Class > (TC) field >    ([RFC3032 ], [RFC5462 > ]) of each label stack entry > must, of course, be >    set.  This document does not specify any set of rules for setting >    these fields; that is a matter of local policy. > > No equivalent of this statement could be found in RFC 3107 – probably > because RFC 3443 has not yet been published then. > > From my POV including the same (or equivalent) explicit statement in > the draft would be sufficient to resolve the issue. > > Hope this helps. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:*stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > *Sent:* Wednesday, July 18, 2018 2:27 PM > *To:* Ahmed Bashandy ; Alexander Vainshtein > > *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; > 'adrian@olddog.co.uk' ; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com) ; > shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > *Subject:* RE: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Hi Sasha, > > >*/The head-end node sends SR-MPLS packets across a path defined by an > ordered set of SIDs with more than one SID in the list. Each SID is > represented by a label stack entry (LSE) in the MPLS label stack, and > the label field in each LSE is the label that matches the > corresponding SID. However, each LSE also includes the TTL and TC > fields. How does the head-end node set these fields in each of the > LSEs following the top one? This clearly depends on the model (Uniform > vs. Pipe/Short Pipe) implemented in each node that that performs Next > operation on the packet along the path – but the head-end node usually > is not aware of that. /* > > Why do you think this is different from a nested MPLS tunnel that > exists today ? I completely agree with you that the head end does not > know the behavior of the tail-end in term of TTL/TC processing. But > that’s already the case today, and it’s the job of engineers to ensure > that all nodes in the network are operating in the same mode (uniform > vs pipe/short pipe). > > We can already stack today a BGP 3107 label over an LDP label over an > RSVP label to build an end-to-end transport, the TTL processing should > not be essentially different. > > Could you pin point the difference that you see ? > > Brgds, > > Stephane > > *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] > *Sent:* Monday, July 16, 2018 22:03 > *To:* Alexander Vainshtein > *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org'; > 'adrian@olddog.co.uk'; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com > ); shraddha@juniper.net > ; spring@ietf.org > ; spring-chairs@ietf.org > ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Subject:* Re: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Thanks a lot for the reply > > See inline "##Ahmed" > > On 7/11/18 2:02 AM, Alexander Vainshtein wrote: > > Ahmed, and all, > > Lots of thanks for a detailed response to my comments. > > Please see */inline below/*my position on each of them. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] > *Sent:* Wednesday, July 11, 2018 4:42 AM > *To:* Alexander Vainshtein > ; spring-chairs@ietf.org > ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org > ' ; > 'adrian@olddog.co.uk ' > ; Jonathan > Hardwick (Jonathan.Hardwick@metaswitch.com > ) > > ; shraddha@juniper.net > ; spring@ietf.org > > *Subject:* Re: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Thanks for thorough (and VERY clear) the review > > See inline #Ahmed > > Ahmed > > On 6/15/18 11:08 PM, Alexander Vainshtein wrote: > > Re-sending to  correct SPRING WG list. > > Sincere apologies for the delay caused by a typo. > > Thumb typed by Sasha Vainshtein > > ------------------------------------------------------------------------ > > *From:* Alexander Vainshtein > *Sent:* Sunday, June 10, 2018 10:43:52 AM > *To:* spring-chairs@ietf.org ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Cc:* spring@ietf.com ; > rtg-dir@ietf.org ; 'mpls@ietf.org > '; 'adrian@olddog.co.uk > '; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com > ); > shraddha@juniper.net > *Subject:* RE: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Explicitly adding Shraddha  who is the shepherd of this draft. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:* Alexander Vainshtein > *Sent:* Friday, June 8, 2018 5:43 PM > *To:* 'spring-chairs@ietf.org ' > ; > 'draft-ietf-spring-segment-routing-mpls.authors@ietf.org > ' > > > *Cc:* 'spring@ietf.com ' > ; rtg-dir@ietf.org > ; mpls@ietf.org > ; 'adrian@olddog.co.uk > ' > > *Subject:* RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Hello, > > I have been selected to do a routing directorate “early†> review of this draft: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > > The routing directorate will, on request from the working > group chair, perform an “early†review of a draft before it is > submitted for publication to the IESG. The early review can be > performed at any time during the draft’s lifetime as a working > group document. The purpose of the early review depends on the > stage that the document has reached. As this document is > currently in the WG Last call, my focus for the review was to > determine whether the document is ready to be published. > Please consider my comments along with the other working group > last call comments. > > For more information about the Routing Directorate, please see > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > *Document*: draft-ietf-spring-segment-routing-mpls-13 > > *Reviewer*: Alexander (“Sashaâ€) Vainshtein > (alexander.vainshtein@ecitele.com > ) > > *Review Date*: 08-Jun-18 > > *Intended Status*: Proposed Standard. > > *Summary*: > > I have some minor concerns about this document that I think > should be resolved before it is submitted to the IESG. > > *Comments*: > > I consider this draft as an important  companion document to > the Segment Routing Architecture > > draft that, ideally, should augment definitions of the Segment > Routing (SR) notions and constructs given there with details > specific for the SR instantiation that uses  the MPLS data > plane (SR-MPLS).  Many issues raised in my review reflect > either gaps that should be, but have not been, closed, or > inconsistencies between the two drafts. > > Since RFC 8287 is > already published as a Standards Track RFC, I expect such > augmentation to be backward compatible with this document (or > to provide clear indications of required updates to this > document). And I include the MPLS WG into distribution list. > > This draft was not easy reading for me. In particular, the > style of Section 2.5 that discusses at length and in some > detail multiple “corner cases†resulting, presumably, from > misconfiguration, before it explains the basic (and relatively > simple) “normal†behavior, looks problematic to me. > > The WG Last Call has been extended by one week. Nevertheless, > I am sending out my comments > > *Major Issues*: None found > > #Ahmed: thanks a lot > > > > *Minor Issues*: Quite a few but, hopefully, easy to resolve. > > 1.*Encapsulation of SR-MPLS packets*: > > a.RFC 3032 (referenced by the draft) and RFC 5332 (*/not > mentioned in the draft/*) depend two encapsulations of labeled > packets - one for Downstream-allocated labels and another for > Upstream-allocated ones. > > #Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of > draft-ietf-spring-segment-routing-15, multicast is outside the > scope of SR. Hence the RFC was not referred to in the SR-MPLS draft > > */[[Sasha]] I would be satisfied with this response, would it not > be for the following text I see in Section 2.2 of the/**/SR Policy > Architecture > > /**/draft:/* > >    A variation of SR Policy can be used for packet replication.  A > >    candidate path could comprise multiple SID-Lists; one for each > >    replication path.  In such a scenario, packets are actually > >    replicated through each SID List of the SR Policy to realize a > point- > >    to-multipoint service delivery. > > */This looks to me as being very much multicast in SR, and, unless > you want to say that it is limited to SRv6, makes my question > relevant IMHO./* > > ##Ahmed: The main reference for this draft is the sr-architecture, > which clearly states that multicast is out of SR scope. SR-MPLS, being > an MPLS instantiation of the SR-architecture, follows the > SR-architecture as close as possible. If another draft proposes > something related to SR, then it is the responsibility of the other > draft to mention any extensions/restrictions in relation to the basic > draft-ietf-spring-segment-routing and/or SR-MPLS, or to specifically > say that it does not apply to SR-MPLS. > > > b.From my POV the ST-MPLS only uses Downstream-allocated labels – > but I expect the draft to state that explicitly, one way or > another. (If Upstream-allocated labels are relevant for SR-MPLS, I > would see it as a major gap, so I hope that this is not the case). > > #Ahmed: I will add a statement in section 2.2 to mention that it is > down-stream allocated as you mentioned > > */[[Sasha]] This is quite unambiguous and, once added, would resolve > my comment in full – the previous comment notwithstanding. In > particular, it would imply that even labels representing BSIDs of a SR > Replication policies will be downstream-allocated. /* > > */#Ahmed: Binding SID is just a special case of a SID. So what applies > to a SID applies to a binding SID/* > > > 2.*Label spaces in SR-MPLS*: > > a.RFC 3031 (referenced by the draft) defines per-platform and > per-interface label spaces, and RFC 5331 (*/not mentioned in the > draft/*) adds context-specific label spaces and context labels. > > b.The draft does not say which of these are or are not relevant > for SR-MPLS > > c.From my POV: > > i.Labels representing all kinds of SIDs mentioned in the draft > MUST be allocated from the per-platform label space only > > ii.At the same time, instantiation of Mirror Segment IDs defined > in Section 5.1 of the Segment Routing Architecture draft using > MPLS data plane clearly calls for context labels and > context-specific label spaces > > d.I expect the draft to provide a clear-cut position on these > aspects of SR-MPLS. > > #Ahmed: I will add a statement to section 2.2 to say that the it is > per-platform. Regarding the function "mirroring", SR attaches a > *function* to each SID. The "mirroring" function is already described > in Section 5.1 of draft-ietf-spring-segment-routing and is not > specific to the MPLS forwarding plane. Hence there is no need to > re-mention it here because this document is trying to be as specific > as possible to the MPLS forwarding plane. General functions attached > to SID are described in the segment routing architecture document or > future documents. Furture documents proposing new SR function must be > as specific and clear as possible > > */[[Sasha]] Looks OK to me./* > > > > > > 3.*SR-MPLS and hierarchical LSPs*: > > a.SR LSPs that include more than one segment are hierarchical LSPs > from the POV of the MPLS data plane. Therefore some (possibly, > all) of the models for handling TTL and TC bits that have been > defined in RFC 3443 (*/not mentioned in the draft/*) should apply > to SR-MPLS > > b.RFC 8287 (*/not referenced in the draft/*) specifically > discussed operation of the LSP Traceroute function for SR LSPs in > the case when Pipe/Short Pipe model for TTL handling is used > > c.I expect the draft to provide at least some guidelines regarding > applicability of each specific model defined in RFC 3443 > (separately for TTL and TC bits) to SR-MPLS. > > #Ahmed: BY design, the instantiation of SR over the MPLS forwarding > plane (and hence this draft) does not modify the MPLS forwarding plan > behavior as it is mentioned in the first sentence in Section 1. So the > TTL behavior specified in rfc3443 is already implied and there is no > need to re-mention it here just like all aspects of MPLS forwarding. > RFC8287 is OAM-specific.  SR-OAM is handled in a separate document so > is outside the scope of this draft > > */[[Sasha]] Unfortunately I do not think this is good enough. Let me > ask a specific question reflecting my concerns:/* > > */The head-end node sends SR-MPLS packets across a path defined by an > ordered set of SIDs with more than one SID in the list. Each SID is > represented by a label stack entry (LSE) in the MPLS label stack, and > the label field in each LSE is the label that matches the > corresponding SID. However, each LSE also includes the TTL and TC > fields. How does the head-end node set these fields in each of the > LSEs following the top one? This clearly depends on the model (Uniform > vs. Pipe/Short Pipe) implemented in each node that that performs Next > operation on the packet along the path – but the head-end node usually > is not aware of that. /* > > */RFC 8287 is relevant as an example here IMHO because it recommends > the following setting of TTL in Traceroute packets:/* > > -*/Set the TTL of all the labels above one that represents the segment > you are currently tracing to maximum/* > > -*/Set the TTL of the label one that represents the segment you are > currently tracing to the desired value (to be incremented until end of > segment is reached/* > > -*/Set the TTL of all the labels below one that represents the segment > you are currently tracing to 0./* > > */I expect the draft to provide some recommendations for traffic > (non-OAM) packets as well./* > > */##Ahmed: The setting of the TTL for non-OAM packets are subject to > the policy that constructed the label stack. SR-policy is handled in a > separate draft /* > > > > > > > 4.*Inferring network layer protocol in SR-MPLS*: > > a.I wonder if the draft could provide any details on the situation > when a label that represents some kind of SID is the > bottom-of-stack label to be popped by the egress LER > > #ahmed: This is part of the "Next" function. It is described in detail > in this document. > > */[[Sasha]] NEXT function is mentioned in several places in the > document. Can you please point to the specific text that is relevant > for my question?/* > > */##Ahmed: Part (a) here is a statement not a question. What is the > question?/* > > > > > > > b.For the reference, RFC 3032 says that “the identity of the > network layer protocol  must be inferable from the value of the > label which is popped from  the bottom of the stack, possibly > along with the contents  of the network layer header itself†> > c.From my POV the following scenario indicates relevance of this > expectation for SR-MPLS: > > i.IS-IS is used for distributing both IPv4 and IPv6 reachability > in a given domain > > ii.An IS-IS adjacency over some dual-stack link is established, > and a single Adj-SID for this adjacency is advertised > > iii.The node that has assigned and advertised this Adj-SID > receives a labeled packet with the label representing this Adj-SID > being both the top and bottom-of-stack label > > iv.The implementers must be given unambiguous instructions for > forwarding the unlabeled packet via the dual-stack link as an Ipv4 > or an IPv6 packet. > > #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 > drafts, you will see all 3 protocol advertise different adj-SIDS for > IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" > (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to > specify whether the adj-SID is for IPv4 and IPv6. Similarly, the > SR-ISIS draft attaches a prefix-SID to the prefix advertisement and > hence implies the identity of the protocol underneath the bottom most > label. For any other "function" attached to a SID, it is part of the > specification of this function to describe what happens when the SID > is represented by a label in the MPLS forwarding plane and this label > is the bottom most label > > */[[Sasha]] OK, got it. This issue is resolved./* > > > > > > 5.*Resolution**of Conflicts*: Are the > > a.Are the conflict resolution procedures listed in section 2.5 > mandatory to implement? > > b.If they are mandatory to implement, are they also mandatory to > deploy, or can the operators simply treat any detected conflict as > requiring human intervention and preventing normal operation of > SR-MPLS? > > #Ahmed: They are recommended. I will modify the paragraph after the > first 3 bullets in Section 2.5 to say that it is recommeded. > > > > */[[Sasha]] OK. However, it would be nice if you could refer > separately for “RECOMMENDED to implement†and “RECOMMENDED to deployâ€. >  The latter probably requires a configuration knob for enabling > conflict resolution rules (if they are implemented). /* > > c.For the reference, the IETF capitalized MUST appears just in a > few places in Section 2.5, and each appearance has very narrow > context: > > i.For MCCs where the "Topology" and/or "Algorithm" fields are not > defined, the numerical value of zero MUST be used for these two fields > > ii.If the same set of FECs are attached to the same label "L1", > then the tie-breaking rules MUST always select the same FEC > irrespective of the order in which the FECs and the label "L1" are > received. In other words, the tie-breaking rule MUST be > deterministic. > > iii.An implementation of explicit SID assignment MUST guarantee > collision freeness on the same router > > From my POV, it is not possible to infer the answer to my question > from these statements. Some explicit statement is required. > > #Ahmed: I agree with you POV and as mentioned in my reply to items (a) > and (b), I will modify the paragraph to say that it is RECOMMENDED to > answer you questions in items (a) and (b) > > > > d.The tie-breaking rules in section 2.5.1 include some specific > values for encoding FEC types and address families – but these > values are not supposed to appear in any IANA registries (because > the draft does not request any IANA actions). Can you please > clarify what is so special about these values? > > #Ahmed: There is no significance to the values but there is a > significance to the order among them. I will modify the text to > clarify that > > */[[Sasha]] OK. /* > > > > > > e.I also doubt that comparison of FECs that represent IPv4 and > IPv6 prefix SIDs makes much sense (for conflict resolution or > else), because, among other things, there are valid scenarios when > an IPv4 /32 prefix is embedded in an IPv6 /128 one. > > #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that > embeds an IPv4 prefix is different from the IPv4 prefix. The > specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat > IPv4 and IPv6 prefixes separately, including the IPV6 prefixes with > embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix in > them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear > > */[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. > Quoting from RFC 4291:/* > > > *2.5.5.2* > *.  > IPv4-Mapped IPv6 Address* > >    A second type of IPv6 address that holds an embedded IPv4 address is > >    defined. This address type is used to represent the addresses of > > IPv4 nodes as IPv6 addresses. > > *//* > > */From my POV this means that a /128 prefix associated with an > IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 > address that was mapped to this IPv6 address represent the same > entity. This understanding fully matches usage of IPv4-mapped IPv6 > addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. > However, the comparison rules you have defined will treat them as two > different prefixes.  I wonder if these rules, in the case of a > conflict, could result in preferring the IPv6 prefix to an IPv4 one > and therefore loosing MPLS connectivity for the ingress PE of a 6VPE > service to its egress PE?/* > > */##Ahmed: The basic MPLS architecture does not forbid assigning > different labels to the same prefix, nonetheless to different prefixes > belonging to the same node or the same interface on the same node. One > of the fundamental concepts of SR-MPLS is that the same prefix-SID > must not be assigned to two different prefixes. So for the particular > scenario of embedding IPv4 in IPv6, the operator must assign different > SIDs to the IPv4 address and the IPv4-mapped IPv6 address that embeds > it, otherwise the label will be subject to the incoming label > collision resolution > > > > /* > > > > > > f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure > all SID types defined in the Segment Routing Architecture draft > can be unambiguously mapped to one of these types. Problematic > examples include at least the following: > > i.Parallel Adjacency SID > > ii.Mirror SID > > Explicit mapping of SID types to SR-MPLS FEC types would be most > useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, > this must be explicitly stated in the draft. > > #Ahmed: > Parallel adjacency SID are handled in the type "(next-hop, outgoing > interface)" > > */[[Sasha]] OK/* > > > Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the > SR architecture draft (draft-ietf-spring-segment-routing-15). Also as > described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18 > (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding > SID is identified by a prefix. Hence it is covered by the type > "(Prefix, Routing Instance, Topology, Algorithm)" > > */[[Sasha]] I respectfully disagree. There is definitely no mention of > Algorithm in the definition of the Mirror SID. /* > > */##Ahmed: > The last paragraph in Section 2 of > draft-ietf-spring-segment-routing-14 says/* > >    We call "MPLS Control Plane Client (MCC)" any control plane entity >    installing forwarding entries in the MPLS data plane. > > */The sentence starting at the 5th line of the first bullet of Section > 2.5 of draft-ietf-spring-segment-routing-14 says/* > > For MCCs where the "Topology" and/or "Algorithm" >       fields are not defined, the numerical value of zero MUST be used >       for these two fields. > > */If a binding-SID is downloaded to the forwarding plane, then it must > be associated with an MCC and hence it either has an "algorithm" or > the value zero is assumed for the "algorithm" field. If the > binding-SID is not downloaded to the forwarding plane, then it is > irrelevant to the entire draft not only to incoming label collision/* > > > > > > 6.*Node SIDs in SR-MPLS*: > > a.Node SIDs are explicitly defined and discussed in the Segment > Routing Architecture draft but are not mentioned even once in this > draft > > b.AFAIK, the common implementation practice today includes > assignment of at least one Node SID to every node in the SR-MPLS > domain > > c.Is there a requirement to assign at least one Node SID per > {routing instance, topology, algorithm} in SR-MPLS? If not, can > the authors explain expected behavior of such a node? (See also my > comment about routing instances below). > > #Ahmed: A Node-SID is a special case of prefix-SID. So there nothing > specific about it from the MPLS forwarding plane point of view. > Similarly from a standard tracks draft point of view, there is no > requirement to assign a SID to every prefix just like there is no > requirement to bind every prefix to an LDP label. Common and/or > recommended practices or description of deployment scenarios are more > befitting to BCP or informational drafts. This draft is a standards > track draft > > */[[Sasha]] Well, you’ve just said that conflict resolution rules are > RECOMMENDED, and this is quite common in the Standards Track RFCs. /* > > */##Ahmed: OK., I think we are in agreement here:)/* > > > > If a {routing instance, topology, algorithm} is not assigned a SID, > then this FEC is totally irrelavant to this draft and hence describing > how a node treats it is totally outside the scope of this draft > > */[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention > routing instances that can be associated with the prefix, so I think > that your reference to it is incorrect./* > > */What’s more I suspect that Node SIDs represent the most used special > case of Prefix SIDs with Anycast SIDs being quite behind.  Therefore > some recommendation pertaining to the usage of Node SIDs would be very > much in place IMHO. /* > > */##Ahmed: The  term "routing instance" within the context of incoming > label collision is defined in the first bullet in Section 2.5. > As for any recommendation for useage of node-SID, anycast-SID,...,etc > , it is out of the scope of this draft because it is a matter of of > deployment/informational/BCP draft > > > /* > > > > > > 7.*SRGB Size in SR-MPLS*: > > a.The draft correctly treats the situation when an index assigned > to some global SID cannot be mapped to a label using the procedure > in Section 2.4 as a conflict. > > b.At the same time the draft does not define any minimum size of > SRGB (be it defined as a single contiguous block or as a sequence > of such blocks) that MUST be implemented by all SR-capable nodes > > c.I suspect that lack of such a definition could be detrimental to > interoperability of SR-MPLS solutions. AFAIK, the IETF has been > following, for quite some time, a policy that some reasonable > MUST-to-implement defaults should be assigned for all configurable > parameters exactly in order to prevent this. > > #Ahmed: This document specifies how the SRGB is used and the behavior > of routers when a prefix-SID index maps to a label inside and/or > outside the SRGB. The actual size of the SRGB is a task in > partitioning the label space, which is very specific to a particular > deployment scenario. So IMO it is outside the scope of a standards > track document. Now that SR-MPLS is deployed in many places, I expect > the community to gain sufficient experience to recommend (or not > recommend) a particular minimum/maximum size for the SRGB is some > future informational or BCP draft/RFC > > */[[Sasha]] My reading of your response is that minimum size of SRGB > is an issue for future study. Can you please just add this to the draft?/* > > */##Ahmed: OK. Added a sentence to the last paragraph of section 2.3/* > > > > > > > 8.*Algorithms and Prefix SIDs*: > > a.The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) > in, but it does not explicitly link them with the Prefix-SID > algorithms defined in section 3.1.1 of the Segment Routing > Architecture draft > > #Ahmed: I will just add the reference > [I-D.ietf-spring-segment-routing]right beside the first time > "Algorithm" is mentioned > > */[[Sasha]] OK/* > > > > > > b.From my POV, the draft should explicitly state that the default > Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant > routers. > > #Ahmed: The specification of what path calculation method should or > must be supported is a routing protocol property not a forwarding > plane property. In fact, the choice of a path calculation method or > algorithm is completely orthogonal to the routed protocol. Hence > mandating the support of a particular routing algorithm is beyond the > scope of this document. > > */[[Sasha]] OK/* > > > > > > c.The Segment Routing Architecture draft states (in section 3.1.3) > that “Support of multiple algorithms applies to SRv6â€. But neither > draft states whether multiple algorithms apply to SR-MPLS. Can you > please clarify this point? > > #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in > draft-ietf-spring-segment-routing-15 discusses the support of multiple > algorithms. So it is implied that the concept of algorithm applies to > SR-MPLS. Hence there is no need to re-mention it here > > */[[Sasha]] The paragraph to which you refer only says that if a > packet with the active Prefix-SID that is associated with a specific > algorithm is received by a node that does not support this algorithm, > this packet will be discarded. If this is the only type of support for > multiple algorithms SR provides, it is not very useful IMHO/**/. /* > > */##Ahmed: The SR-MPLS draft that we are discussing here does not > attempt to modify the SR-architecture draft. Any concerns related to > the SR-architecture should be addressed to the SR-architecture draft > not to this draft. /* > > > > > > 9.*Routing instances and the context for Prefix-SIDs*: > > a.The Segment Routing Architecture draft states in Section 3.1 > that the “context for an IGP-Prefix segment includes the prefix, > topology, and algorithm†> > b.This draft seems to define (in section 2.5) the context for the > Prefix SID as “Prefix, Routing Instance, Topology, Algorithm†> where â€a routing instance is identified by a single incoming label > downloader to FIB†(but the notion of the label downloader to FIB > is not defined). > > c.These two definitions look different to me. > > d.At the very least I would expect alignment between the > definitions of context for the Prefix-SID between the two drafts. > Preferably, the definition given in the Segment Routing > Architecture draft should be used in both drafts. > > #Ahmed: The context of the section 2.5 is limited to the resolution of > local label collision. The use of "routing instance" in section 2.5 is > just there for tie-breaking if there is local label collision. > > */[[Sasha]] I have already mentioned that “routing instances†are not > defined in any the drafts dealing with SR Extensions for IGPs. So I do > not understand how the conflict resolution procedure is supposed to > use this. And in any case the difference between two definitions of > the context of Prefix-SID requires some explanation./* > > */##Ahmed: incoming label collision defines what is a routing instance > within its context. I do not understand what explanation you are > looking for/* > > > > > > > > 10.*Example of PUSH operation in Section 2.10.1*: > > a.The first para of this section begins with the sentence “Suppose > an MCC on a router "R0" determines that PUSH or CONTINUE   > operation is to be applied to an incoming packet whose active SID > is the global SID "Si"â€. In the context of SR-MPLS this means (to > me) that the incoming packet is a labeled packet and its top label > matches the global SID “Siâ€. > > b.However, the example for PUSH operation in the next para of this > section is the case of an (unlabeled) IP packet with the > destination address covered by the IP prefix for which “Si†has > been assigned. > > c.From my POV: > > i.Mapping unlabeled packets to SIDs is indeed out of scope of the > draft. Therefore an example of a PUSH operation that is applied to > a labeled packet (with the active SID inferred from the top label > in the stack) is preferable. > > ii.Valid examples of  PUSH operation applied to a labeled incoming > packet can be found in Sections 4.2 or 4.3 of the TI-LFA > > draft > > #Ahmed: I do not understand your concern here:) > > > > */[[Sasha]] I think it is pretty clear: can you provide an example of > a PUSH operation applied to a labeled packet instead of your current > example?/* > > */##Ahmed: The example in the draft is included to clarify the concept > of a prefix SID attached to a prefix. As mentioned more than once, > SR-MPLS does not modify MPLS forwarding including pushing a label on a > labeled packet. It is something that has been done by routers and > switches for 20+ years. So including it here is redundant/* > > > *Nits*: > > 1.I concur with Adrian regarding numerous nits he has reported in > his WG LC Comment > . > I would like to thank Adrian for an excellent review that have > saved me lots of hard work. > > #Ahmed: I also agree that Adrian's review is exceptional. I believe I > addressed all his comments in the latest version. > > > > 2.In addition, I’d like to report the following nits: > > a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA > > draft) > > #Ahmed: Already done in the latest version*/[[Sasha]] OK/* > > > > b.TI-LFA draft is referenced in the text of Section 2.11.1, but > there is no matching reference in the “References†section > (probably, Informational) > > #Ahmed: Already done in the latest version*/[[Sasha]] OK/* > > > > c.“zero Algorithm†in Section 2.5 (immediately above Section > 2.5.1) must be replaced with “default algorithmâ€. Similarly, > “non-zero Algorithm†should be replaced with “non-default algorithm†> > #Ahmed: Will be done in the next version*/[[Sasha]] /* OK > > > > 3.I think that RFC 3443 and RFC 5332 should be listed as Normative > references in this draft while RFC 5331 and RFC 8277 should be > listed as Informative references. This would improve the > readability of the draft without any impact on its advancement. > > #Ahmed RFC5331 describes upstream label assignment. As you mentioned > above (and I will modify the draft to indicate that) SR-MPLS behavior > is similar to downstream label assignment. RFC 3443 describes TTL > behavior. This is an MPLS forwarding behavior. As mentioned in the > draft, SR-MPLS does not modify at the MPLS forwarding behavior > > */[[Sasha]] Regarding RFC 5331 – you may skip this reference if you > state (as discussed below) that SR-MPLS only allocates labels from the > per-platform label space. Regarding RFC 3443 – I do not think that you > can fully avoid discussion of Uniform and Pipe/Short Pipe models, and > therefore you will need this reference./* > > */##Ahmed: I did not add rfc5331 as a reference . Again pushing > multiple labels on top of a packet is a matter of SR-policy, which is > handled in a separate draft. /* > > > > > > > > Hopefully, these comments will be useful. > > #Ahmed: They are certainly quite useful. Thanks a lot > > > > Regards, > > Sasha > > Office: +972-39266302 > > Cell:      +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this > transmission in error, please inform us by e-mail, phone or fax, > and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ > > _________________________________________________________________________________________________________________________ > 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. > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ --------------E8F683FE2F33848379AE9D42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sasha

I uploaded version 15. But I was not sure how to best address your concern

So Please propose the wording/modifications that looks reasonable to you and I will be more than happy to incorporate them

Ahmed

(I replied to this email a little while ago but I am replying to it again with a cutdown on the list of receipts because the mailing list said the email is being held)



On 7/25/18 12:20 AM, Alexander Vainshtein wrote:

Stephane,

Lots of thanks for your email, and apologies for a long delayed response.

Regarding you reference to “BGP 3107 label over an LDP label over an RSVP label to build an end-to-end transportâ€, I have looked up RFC 8277  that has replaced RFC 3107, and found there the following explicit statement:

   When pushing labels onto a packet's label stack, the Time-to-Live
   (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field
   ([RFC3032], [RFC5462]) of each label stack entry must, of course, be
   set.  This document does not specify any set of rules for setting
   these fields; that is a matter of local policy.

 

No equivalent of this statement could be found in RFC 3107 – probably because RFC 3443 has not yet been published then.

From my POV including the same (or equivalent) explicit statement in the draft would be sufficient to resolve the issue.

Hope this helps.

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

Hi Sasha,

> The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.

Why do you think this is different from a nested MPLS tunnel that exists today ? I completely agree with you that the head end does not know the behavior of the tail-end in term of TTL/TC processing. But that’s already the case today, and it’s the job of engineers to ensure that all nodes in the network are operating in the same mode (uniform vs pipe/short pipe).

We can already stack today a BGP 3107 label over an LDP label over an RSVP label to build an end-to-end transport, the TTL processing should not be essentially different.

Could you pin point the difference that you see ?

 

Brgds,

 

Stephane

 

 

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Monday, July 16, 2018 22:03
To: Alexander Vainshtein
Cc: rtg-dir@ietf.org; 'mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Thanks a lot for the reply

See inline "##Ahmed"

 

On 7/11/18 2:02 AM, Alexander Vainshtein wrote:

Ahmed, and all,

Lots of thanks for a detailed response to my comments.

Please see inline below my position on each of them.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

Thanks for thorough (and VERY clear) the review

See inline #Ahmed

 

Ahmed

 

 

On 6/15/18 11:08 PM, Alexander Vainshtein wrote:

Re-sending to  correct SPRING WG list.

Sincere apologies for the delay caused by a typo.

Thumb typed by Sasha Vainshtein

 

From: Alexander Vainshtein
Sent: Sunday, June 10, 2018 10:43:52 AM
To: spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Cc: spring@ietf.com; rtg-dir@ietf.org; 'mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Explicitly adding Shraddha  who is the shepherd of this draft.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

 

Hello,

I have been selected to do a routing directorate “early†review of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

 

The routing directorate will, on request from the working group chair, perform an “early†review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is currently in the WG Last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

 

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

 

Document: draft-ietf-spring-segment-routing-mpls-13

Reviewer: Alexander (“Sashaâ€) Vainshtein (alexander.vainshtein@ecitele.com)

Review Date: 08-Jun-18

Intended Status: Proposed Standard.

 

Summary:

 

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

 

Comments:

 

I consider this draft as an important  companion document to the Segment Routing Architecture draft that, ideally, should augment definitions of the Segment Routing (SR) notions and constructs given there with details specific for the SR instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised in my review reflect either gaps that should be, but have not been, closed, or inconsistencies between the two drafts.

 

 

Since RFC 8287 is already published as a Standards Track RFC, I expect such augmentation to be backward compatible with this document (or to provide clear indications of required updates to this document). And I include the MPLS WG into distribution list.

 

This draft was not easy reading for me. In particular, the style of Section 2.5 that discusses at length and in some detail multiple “corner cases†resulting, presumably, from misconfiguration, before it explains the basic (and relatively simple) “normal†behavior, looks problematic to me.

 

The WG Last Call has been extended by one week. Nevertheless, I am sending out my comments

 

Major Issues: None found

#Ahmed: thanks a lot



 

Minor Issues: Quite a few but, hopefully, easy to resolve.

 

1.    Encapsulation of SR-MPLS packets:

a.    RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned in the draft) depend two encapsulations of labeled packets - one for Downstream-allocated labels and another for Upstream-allocated ones.

#Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of draft-ietf-spring-segment-routing-15, multicast is outside the scope of SR. Hence the RFC was not referred to in the SR-MPLS draft

[[Sasha]] I would be satisfied with this response, would it not be for the following text I see in Section 2.2 of the SR Policy Architecture draft:

   A variation of SR Policy can be used for packet replication.  A

   candidate path could comprise multiple SID-Lists; one for each

   replication path.  In such a scenario, packets are actually

   replicated through each SID List of the SR Policy to realize a point-

   to-multipoint service delivery.

 

This looks to me as being very much multicast in SR, and, unless you want to say that it is limited to SRv6, makes my question relevant IMHO.

##Ahmed: The main reference for this draft is the sr-architecture, which clearly states that multicast is out of SR scope. SR-MPLS, being an MPLS instantiation of the SR-architecture, follows the SR-architecture as close as possible. If another draft proposes something related to SR, then it is the responsibility of the other draft to mention any extensions/restrictions in relation to the basic draft-ietf-spring-segment-routing and/or SR-MPLS, or to specifically say that it does not apply to SR-MPLS.


b.    From my POV the ST-MPLS only uses Downstream-allocated labels – but I expect the draft to state that explicitly, one way or another. (If Upstream-allocated labels are relevant for SR-MPLS, I would see it as a major gap, so I hope that this is not the case).

#Ahmed: I will add a statement in section 2.2 to mention that it is down-stream allocated as you mentioned

[[Sasha]] This is quite unambiguous and, once added, would resolve my comment in full – the previous comment notwithstanding. In particular, it would imply that even labels representing BSIDs of a SR Replication policies will be downstream-allocated.

#Ahmed: Binding SID is just a special case of a SID. So what applies to a SID applies to a binding SID


 

2.    Label spaces in SR-MPLS:

a.    RFC 3031 (referenced by the draft) defines per-platform and per-interface label spaces, and RFC 5331 (not mentioned in the draft) adds context-specific label spaces and context labels.

b.    The draft does not say which of these are or are not relevant for SR-MPLS

c.    From my POV:

                                         i.    Labels representing all kinds of SIDs mentioned in the draft MUST be allocated from the per-platform label space only

                                        ii.    At the same time, instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment Routing Architecture draft using MPLS data plane clearly calls for context labels and context-specific label spaces

d.    I expect the draft to provide a clear-cut position on these aspects of SR-MPLS.

#Ahmed: I will add a statement to section 2.2 to say that the it is per-platform. Regarding the function "mirroring", SR attaches a *function* to each SID. The "mirroring" function is already described in Section 5.1 of draft-ietf-spring-segment-routing and is not specific to the MPLS forwarding plane. Hence there is no need to re-mention it here because this document is trying to be as specific as possible to the MPLS forwarding plane. General functions attached to SID are described in the segment routing architecture document or future documents. Furture documents proposing new SR function must be as specific and clear as possible

[[Sasha]] Looks OK to me.





3.    SR-MPLS and hierarchical LSPs:

a.    SR LSPs that include more than one segment are hierarchical LSPs from the POV of the MPLS data plane. Therefore some (possibly, all) of the models for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned in the draft) should apply to SR-MPLS

b.    RFC 8287 (not referenced in the draft) specifically discussed operation of the LSP Traceroute function for SR LSPs in the case when Pipe/Short Pipe model for TTL handling is used

c.    I expect the draft to provide at least some guidelines regarding applicability of each specific model defined in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.

#Ahmed: BY design, the instantiation of SR over the MPLS forwarding plane (and hence this draft) does not modify the MPLS forwarding plan behavior as it is mentioned in the first sentence in Section 1. So the TTL behavior specified in rfc3443 is already implied and there is no need to re-mention it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specific.  SR-OAM is handled in a separate document so is outside the scope of this draft

[[Sasha]] Unfortunately I do not think this is good enough. Let me ask a specific question reflecting my concerns:

The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.

RFC 8287 is relevant as an example here IMHO because it recommends the following setting of TTL in Traceroute packets:

-          Set the TTL of all the labels above one that represents the segment you are currently tracing to maximum

-          Set the TTL of the label one that represents the segment you are currently tracing to the desired value (to be incremented until end of segment is reached

-          Set the TTL of all the labels below one that represents the segment you are currently tracing to 0.

I expect the draft to provide some recommendations for traffic (non-OAM) packets as well.

##Ahmed: The setting of the TTL for non-OAM packets are subject to the policy that constructed the label stack. SR-policy is handled in a separate draft 






4.    Inferring network layer protocol in SR-MPLS:

a.    I wonder if the draft could provide any details on the situation when a label that represents some kind of SID is the bottom-of-stack label to be popped by the egress LER

#ahmed: This is part of the "Next" function. It is described in detail in this document.

[[Sasha]] NEXT function is mentioned in several places in the document. Can you please point to the specific text that is relevant for my question?

##Ahmed: Part (a) here is a statement not a question. What is the question?






b.    For the reference, RFC 3032 says that “the identity of the network layer protocol  must be inferable from the value of the label which is popped from  the bottom of the stack, possibly along with the contents  of the network layer header itselfâ€

c.    From my POV the following scenario indicates relevance of this expectation for SR-MPLS:

                                         i.    IS-IS is used for distributing both IPv4 and IPv6 reachability in a given domain

                                        ii.    An IS-IS adjacency over some dual-stack link is established, and a single Adj-SID for this adjacency is advertised

                                       iii.    The node that has assigned and advertised this Adj-SID receives a labeled packet with the label representing this Adj-SID being both the top and bottom-of-stack label

                                       iv.    The implementers must be given unambiguous instructions for forwarding the unlabeled packet via the dual-stack link as an Ipv4 or an IPv6 packet.

#Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to specify whether the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a prefix-SID to the prefix advertisement and hence implies the identity of the protocol underneath the bottom most label. For any other "function" attached to a SID, it is part of the specification of this function to describe what happens when the SID is represented by a label in the MPLS forwarding plane and this label is the bottom most label

[[Sasha]] OK, got it. This issue is resolved.





5.    Resolution of Conflicts: Are the

a.    Are the conflict resolution procedures listed in section 2.5 mandatory to implement?

b.    If they are mandatory to implement, are they also mandatory to deploy, or can the operators simply treat any detected conflict as requiring human intervention and preventing normal operation of SR-MPLS?

#Ahmed: They are recommended. I will modify the paragraph after the first 3 bullets in Section 2.5 to say that it is recommeded.  



[[Sasha]] OK. However, it would be nice if you could refer separately for “RECOMMENDED to implement†and “RECOMMENDED to deployâ€.  The latter probably requires a configuration knob for enabling conflict resolution rules (if they are implemented).

c.    For the reference, the IETF capitalized MUST appears just in a few places in Section 2.5, and each appearance has very narrow context:

                                         i.    For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zero MUST be used for these two fields

                                        ii.    If the same set of FECs are attached to the same label "L1", then the tie-breaking rules MUST always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic.

                                       iii.    An implementation of explicit SID assignment MUST guarantee collision freeness on the same router

From my POV, it is not possible to infer the answer to my question from these statements. Some explicit statement is required.

#Ahmed: I agree with you POV and as mentioned in my reply to items (a) and (b), I will modify the paragraph to say that it is RECOMMENDED to answer you questions in items (a) and (b)



d.    The tie-breaking rules in section 2.5.1 include some specific values for encoding FEC types and address families – but these values are not supposed to appear in any IANA registries (because the draft does not request any IANA actions). Can you please clarify what is so special about these values?

#Ahmed: There is no significance to the values but there is a significance to the order among them. I will modify the text to clarify that

[[Sasha]] OK.





e.    I also doubt that comparison of FECs that represent IPv4 and IPv6 prefix SIDs makes much sense (for conflict resolution or else), because, among other things, there are valid scenarios when an IPv4 /32 prefix is embedded in an IPv6 /128 one.

#Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that embeds an IPv4 prefix is different from the IPv4 prefix. The specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately, including the IPV6 prefixes with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix in them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear

[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. Quoting from RFC 4291:

2.5.5.2.  IPv4-Mapped IPv6 Address

 

 

   A second type of IPv6 address that holds an embedded IPv4 address is

   defined.  This address type is used to represent the addresses of

   IPv4 nodes as IPv6 addresses.

 

From my POV this means that a /128 prefix associated with an IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 address that was mapped to this IPv6 address represent the same entity. This understanding fully matches usage of IPv4-mapped IPv6 addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. However, the comparison rules you have defined will treat them as two different prefixes.  I wonder if these rules, in the case of a conflict, could result in preferring the IPv6 prefix to an IPv4 one and therefore loosing MPLS connectivity for the ingress PE of a 6VPE service to its egress PE?

##Ahmed: The basic MPLS architecture does not forbid assigning different labels to the same prefix, nonetheless to different prefixes belonging to the same node or the same interface on the same node. One of the fundamental concepts of SR-MPLS is that the same prefix-SID must not be assigned to two different prefixes. So for the particular scenario of embedding IPv4 in IPv6, the operator must assign different SIDs to the IPv4 address and the IPv4-mapped IPv6 address that embeds it, otherwise the label will be subject to the incoming label collision resolution







f.     Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure all SID types defined in the Segment Routing Architecture draft can be unambiguously mapped to one of these types. Problematic examples include at least the following:

                                         i.    Parallel Adjacency SID

                                        ii.    Mirror SID

Explicit mapping of SID types to SR-MPLS FEC types would be most useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, this must be explicitly stated in the draft.

#Ahmed:
Parallel adjacency SID are handled in the type "(next-hop, outgoing interface)"

[[Sasha]] OK


Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR architecture draft (draft-ietf-spring-segment-routing-15). Also as described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18 (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is identified by a prefix. Hence it is covered by the type "(Prefix, Routing Instance, Topology, Algorithm)"

[[Sasha]] I respectfully disagree. There is definitely no mention of Algorithm in the definition of the Mirror SID.

##Ahmed:
The last paragraph in Section 2 of draft-ietf-spring-segment-routing-14 says

   We call "MPLS Control Plane Client (MCC)" any control plane entity
   installing forwarding entries in the MPLS data plane.

The sentence starting at the 5th line of the first bullet of Section 2.5 of draft-ietf-spring-segment-routing-14 says

For MCCs where the "Topology" and/or "Algorithm"
      fields are not defined, the numerical value of zero MUST be used
      for these two fields.

If a binding-SID is downloaded to the forwarding plane, then it must be associated with an MCC and hence it either has an "algorithm" or the value zero is assumed for the "algorithm" field. If the binding-SID is not downloaded to the forwarding plane, then it is irrelevant to the entire draft not only to incoming label collision





6.    Node SIDs in SR-MPLS:

a.    Node SIDs are explicitly defined and discussed in the Segment Routing Architecture draft but are not mentioned even once in this draft

b.    AFAIK, the common implementation practice today includes assignment of at least one Node SID to every node in the SR-MPLS domain

c.    Is there a requirement to assign at least one Node SID per {routing instance, topology, algorithm} in SR-MPLS? If not, can the authors explain expected behavior of such a node? (See also my comment about routing instances below).

#Ahmed: A Node-SID is a special case of prefix-SID. So there nothing specific about it from the MPLS forwarding plane point of view. Similarly from a standard tracks draft point of view, there is no requirement to assign a SID to every prefix just like there is no requirement to bind every prefix to an LDP label. Common and/or recommended practices or description of deployment scenarios are more befitting to BCP or informational drafts. This draft is a standards track draft

[[Sasha]] Well, you’ve just said that conflict resolution rules are RECOMMENDED, and this is quite common in the Standards Track RFCs.

##Ahmed: OK., I think we are in agreement here:)



If a {routing instance, topology, algorithm} is not assigned a SID, then this FEC is totally irrelavant to this draft and hence describing how a node treats it is totally outside the scope of this draft

[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention routing instances that can be associated with the prefix, so I think that your reference to it is incorrect.

What’s more I suspect that Node SIDs represent the most used special case of Prefix SIDs with Anycast SIDs being quite behind.  Therefore some recommendation pertaining to the usage of Node SIDs would be very much in place IMHO.

##Ahmed: The  term "routing instance" within the context of incoming label collision is defined in the first bullet in Section 2.5.
As for any recommendation for useage of node-SID, anycast-SID,...,etc , it is out of the scope of this draft because it is a matter of of deployment/informational/BCP draft






7.    SRGB Size in SR-MPLS:

a.    The draft correctly treats the situation when an index assigned to some global SID cannot be mapped to a label using the procedure in Section 2.4 as a conflict.

b.    At the same time the draft does not define any minimum size of SRGB (be it defined as a single contiguous block or as a sequence of such blocks) that MUST be implemented by all SR-capable nodes

c.    I suspect that lack of such a definition could be detrimental to interoperability of SR-MPLS solutions. AFAIK, the IETF has been following, for quite some time, a policy that some reasonable MUST-to-implement defaults should be assigned for all configurable parameters exactly in order to prevent this.

#Ahmed: This document specifies how the SRGB is used and the behavior of routers when a prefix-SID index maps to a label inside and/or outside the SRGB. The actual size of the SRGB is a task in partitioning the label space, which is very specific to a particular deployment scenario. So IMO it is outside the scope of a standards track document. Now that SR-MPLS is deployed in many places, I expect the community to gain sufficient experience to recommend (or not recommend) a particular minimum/maximum size for the SRGB is some future informational or BCP draft/RFC

[[Sasha]] My reading of your response is that minimum size of SRGB is an issue for future study. Can you please just add this to the draft?

##Ahmed: OK. Added a sentence to the last paragraph of section 2.3






8.    Algorithms and Prefix SIDs:

a.    The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, but it does not explicitly link them with the Prefix-SID algorithms defined in section 3.1.1 of the Segment Routing Architecture draft

#Ahmed: I will just add the reference [I-D.ietf-spring-segment-routing] right beside the first time "Algorithm" is mentioned

[[Sasha]] OK





b.    From my POV, the draft should explicitly state that the default Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.

#Ahmed: The specification of what path calculation method should or must be supported is a routing protocol property not a forwarding plane property. In fact, the choice of a path calculation method or algorithm is completely orthogonal to the routed protocol. Hence mandating the support of a particular routing algorithm is beyond the scope of this document.

[[Sasha]] OK





c.    The Segment Routing Architecture draft states (in section 3.1.3) that “Support of multiple algorithms applies to SRv6â€. But neither draft states whether multiple algorithms apply to SR-MPLS. Can you please clarify this point?

#Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in draft-ietf-spring-segment-routing-15 discusses the support of multiple algorithms. So it is implied that the concept of algorithm applies to SR-MPLS. Hence there is no need to re-mention it here

[[Sasha]] The paragraph to which you refer only says that if a packet with the active Prefix-SID that is associated with a specific algorithm is received by a node that does not support this algorithm, this packet will be discarded. If this is the only type of support for multiple algorithms SR provides, it is not very useful IMHO.

##Ahmed: The SR-MPLS draft that we are discussing here does not attempt to modify the SR-architecture draft. Any concerns related to the SR-architecture should be addressed to the SR-architecture draft not to this draft.





9.    Routing instances and the context for Prefix-SIDs:

a.    The Segment Routing Architecture draft states in Section 3.1 that the “context for an IGP-Prefix segment includes the prefix, topology, and algorithmâ€

b.    This draft seems to define (in section 2.5) the context for the Prefix SID as “Prefix, Routing Instance, Topology, Algorithm†where â€a routing instance is identified by a single incoming label downloader to FIB†(but the notion of the label downloader to FIB is not defined).

c.    These two definitions look different to me.

d.    At the very least I would expect alignment between the definitions of context for the Prefix-SID between the two drafts. Preferably, the definition given in the Segment Routing Architecture draft should be used in both drafts.

#Ahmed: The context of the section 2.5 is limited to the resolution of local label collision. The use of "routing instance" in section 2.5 is just there for tie-breaking if there is local label collision.

[[Sasha]] I have already mentioned that “routing instances†are not defined in any the drafts dealing with SR Extensions for IGPs. So I do not understand how the conflict resolution procedure is supposed to use this. And in any case the difference between two definitions of the context of Prefix-SID requires some explanation.

##Ahmed: incoming label collision defines what is a routing instance within its context. I do not understand what explanation you are looking for







10. Example of PUSH operation in Section 2.10.1:

a.    The first para of this section begins with the sentence “Suppose an MCC on a router "R0" determines that PUSH or CONTINUE   operation is to be applied to an incoming packet whose active SID is the global SID "Si"â€. In the context of SR-MPLS this means (to me) that the incoming packet is a labeled packet and its top label matches the global SID “Siâ€.

b.    However, the example for PUSH operation in the next para of this section is the case of an (unlabeled) IP packet with the destination address covered by the IP prefix for which “Si†has been assigned.

c.    From my POV:

                                         i.    Mapping unlabeled packets to SIDs is indeed out of scope of the draft. Therefore an example of a PUSH operation that is applied to a labeled packet (with the active SID inferred from the top label in the stack) is preferable.

                                        ii.    Valid examples of  PUSH operation applied to a labeled incoming packet can be found in Sections 4.2 or 4.3 of the TI-LFA draft

 

#Ahmed: I do not understand your concern here:)



[[Sasha]] I think it is pretty clear: can you provide an example of a PUSH operation applied to a labeled packet instead of your current example?

##Ahmed: The example in the draft is included to clarify the concept of a prefix SID attached to a prefix. As mentioned more than once, SR-MPLS does not modify MPLS forwarding including pushing a label on a labeled packet. It is something that has been done by routers and switches for 20+ years. So including it here is redundant


Nits:

1.    I concur with Adrian regarding numerous nits he has reported in his WG LC Comment. I would like to thank Adrian for an excellent review that have saved me lots of hard work.

#Ahmed: I also agree that Adrian's review is exceptional. I believe I addressed all his comments in the latest version.



2.    In addition, I’d like to report the following nits:

a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA draft)

#Ahmed: Already done in the latest version[[Sasha]] OK



b.    TI-LFA draft is referenced in the text of Section 2.11.1, but there is no matching reference in the “References†section (probably, Informational)

#Ahmed: Already done in the latest version[[Sasha]] OK



c.    “zero Algorithm†in Section 2.5 (immediately above Section 2.5.1) must be replaced with “default algorithmâ€. Similarly, “non-zero Algorithm†should be replaced with “non-default algorithmâ€

#Ahmed: Will be done in the next version[[Sasha]]  OK



3.    I think that RFC 3443 and RFC 5332 should be listed as Normative references in this draft while RFC 5331 and RFC 8277 should be listed as Informative references. This would improve the readability of the draft without any impact on its advancement.

 

#Ahmed RFC5331 describes upstream label assignment. As you mentioned above (and I will modify the draft to indicate that) SR-MPLS behavior is similar to downstream label assignment. RFC 3443 describes TTL behavior. This is an MPLS forwarding behavior. As mentioned in the draft, SR-MPLS does not modify at the MPLS forwarding behavior

[[Sasha]] Regarding RFC 5331 – you may skip this reference if you state (as discussed below) that SR-MPLS only allocates labels from the per-platform label space. Regarding RFC 3443 – I do not think that you can fully avoid discussion of Uniform and Pipe/Short Pipe models, and therefore you will need this reference.

##Ahmed: I did not add rfc5331 as a reference . Again pushing multiple labels on top of a packet is a matter of SR-policy, which is handled in a separate draft.







Hopefully, these comments will be useful.

#Ahmed: They are certainly quite useful. Thanks a lot



 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 

_________________________________________________________________________________________________________________________
 
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.

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

--------------E8F683FE2F33848379AE9D42-- From nobody Sat Oct 27 20:16:02 2018 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 B39D71277D2 for ; Sat, 27 Oct 2018 20:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 YUhP1CmK1u63 for ; Sat, 27 Oct 2018 20:15:52 -0700 (PDT) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5468124BAA for ; Sat, 27 Oct 2018 20:15:51 -0700 (PDT) Received: from [46.226.52.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-west-1.aws.symcld.net id 81/66-09000-5E925DB5; Sun, 28 Oct 2018 03:15:49 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTfUgTYRzHfXa3u6tcnNP0l2jURWjZTScFCwr 8q0YvVBJEhdQtr20059pNmgVl2otoRYZW2otahljDykIqWn/Yq5q9TGVmms00S/9IMRkhRXd7 7O2/z/P7fu/3/d7xHENoR6lYRnS7RKddsHHUdHLJvLQMfnBh57aUO/Wk4YoHDMdPJBm6+r2E4 dnrSWSY8AbUaWrjvYpe2lhT811l9Od30sYnby8SxsOfmqkN6q1qq92U7d6htvge+0nHoaEZbn 9wiMhDNe0zitB0hmQvE1B3MkgqBy17RgX+H3fV+PARwaPWAroITWModgU0XO+lFI5is6GsvyQ 0J9jbCL6/2adwJLsGTr/vQtizFupGGknMu+FTaZBQmGQXQM9Xn0phDSvA4LsJCodNkNBzbCT0 8DQ5rK7ZE2LERkOwxaPCYTHQPVAZYmBZqHnwisA8C758/KnGfhP0DVYjPOfA31dNY44HX2UxU sKAfUtBlWdcjQUeRsvKphatg0uPO+RGjMzz4c7nDOxvR+D/1kFhz2K4N/luyu+AsQvjFDbdRF B7uo/Ewhy4diJAYqGTAG/ry6lKcfCm/cWUUEjD+Osj6BTiK/55Pcx2OF9STVSEvlMENJcPkBV yK4JdCDfuJ2PLPCgtDtCYE+HIhYv0v/MqRF9DBpPTara4sgSrjdenpPB6fSqvX7aET01dqhP2 8YJOzOH3ipKL1+uEvZJOys3aacvU2UVXA5JvX6ajKXAXvaw1N6HZjIqbpfFHd27TzjRlZ+ZaB Mmy3ZljE6UmFMcwHGg2JspahFM0i+5dVpt8hX/LwIRzUZqniqyRHEKWZDVjqQXxzOdzhecILW nPtouxMZoWxcQqJkuO/c+K3z+CD8XHRmpQWFiYNtwhOrOsrv/1YRTDIC5SU6tsCbfaXX+ShuU SKrnEFW2HUsIl/JVi81ACkbwDVXY9XF9YPvZhV1xBgCHPWya2nJrdnRc+Mpmm9yXv2f/gIHN1 tCP9eX0iN/fss7ijm9dcfR9WHvSYh6pMmc7cvPhNVEl+Uu/KFVX729qSxrrbyl+5G5fTt2vrf qxsONbeuCqB5AbyDxTnlhb03/IWHR12RvuIvp7V6V1FXo6ULIJ+EeGUhF/R5A9RAwQAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-267.messagelabs.com!1540696544!1406660!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 26414 invoked from network); 28 Oct 2018 03:15:47 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-9.tower-267.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Oct 2018 03:15:47 -0000 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:X-MS-Exchange-SenderADCheck; bh=dFgXiD65balDl6tsNPwcnI25KPiL9p+kGL69KhAGRtI=; b=NoyOffOAc+ucNmTYKOwL70aXHVYIpMvtqYjc0WA3JzEV+T+oq6zQ5RF9srWp4qJdC0Hh+FuvW+aWJ8XF2Sv38LwAWE96/C5k4vPZUiqkfpn7AcsdS4H9zNvJiEDuDS2g7P/UbIh1GOPHBW3b6ozrmdyP+MqvnYRUKmVxi0Iag1I= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1894.eurprd03.prod.outlook.com (10.167.226.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.26; Sun, 28 Oct 2018 03:15:40 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::d0bc:f20c:94cf:f479]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::d0bc:f20c:94cf:f479%2]) with mapi id 15.20.1273.025; Sun, 28 Oct 2018 03:15:39 +0000 From: Alexander Vainshtein To: "stephane.litkowski@orange.com" , Ahmed Bashandy CC: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" , "shraddha@juniper.net" , "spring@ietf.org" Thread-Topic: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 Thread-Index: AdP43xrNCf1Jfn1vTC6lobk7r4STVgHrz2WgASqJaLgE3/VOgAAMAhfgARXqXAAAUpCzAAFXFCSwEpzVyIAABKQQ6A== Date: Sun, 28 Oct 2018 03:15:38 +0000 Message-ID: References: <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> <8f6b91d0-27de-f92e-6908-598977a05e0d@gmail.com> <32502_1531913237_5B4F2415_32502_461_3_9E32478DFA9976438E7A22F69B08FF924B1FF359@OPEXCLILMA4.corporate.adroot.infra.ftgroup> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.142.119.228] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB1894; 6:KXNs9Cb14jamM6xkbjySi+xVtk3Qxt/DhDIwJZt1KWVOdkumN8f/vpSBfFRkhXHT3qndSbRDlrqNHz8i2/hTzmJQc7ihICaX0yu5Miw32A3p/cLY4RtiUW5X6YLyYnmQveWs117a7GKvHfZf2SBhgI4iBggGAC6X8lCUIxlRY2oX48+J1SqNUpfnTmlvcnDDDZl/Fhr5Qfi3mk6WWTMOuTB7DJSU7qI1czSHRAs5b8k/2fnZ9CEI0ujPdPuMmD0c0XiO6QqOeVwmYoifx5FFn7lTn8KUcsyepB3HnFrT9FenvmhGxyZJ97COG9G637mPHFQk48AquKdf6danfjsy/o/hD3MQRMXSKZ6AhXlyonXYI4TqkzwHx3qBc92su/Xe3u3csLnF+dqhCnuWkjtUtMJh1HB7eDBrnr4ybHLPW4kXvQZURqNkdWh3yp1rTc/x1OPW2632hvKev9m3EarA/g==; 5:sdpuVjAmTPsvJjo3B+ert4Ou1TrrMFOtYXdR+LIKXayGOSiSKNJ4lPSOtfkbt8WU2rI/vOWEYyoo0uSwQqCUFI8SdsgWQ8WIhoMaHMXLs18gbOFKO5JsLfhO9yAyX3Fn+b4ECTdkH2EQsZ90djKxmXxt41mEXUxvQ+D6ju41r4Q=; 7:5w1+6Y7vI4QYFGN8e9uBpiX1HN1XROxZYKhGvY2JALxNYmpocUALns2uXQzoyc5GiKhKEoCN9Yxc17K7Q8O1QR04NGhOENSD3JBII7K5RQCnAHQlWlufa7PXzltwnI/YJsDZxHKmuhDww7mwDzhFyg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5e9303eb-ff8a-4682-c02e-08d63c83a2e2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1894; x-ms-traffictypediagnostic: DB5PR0301MB1894: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(161740460382875)(18271650672692)(138986009662008)(279101305709854)(120809045254105)(269456686620040)(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DB5PR0301MB1894; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1894; x-forefront-prvs: 0839D067E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39850400004)(396003)(136003)(54094003)(252514010)(51444003)(189003)(199004)(129404003)(37854004)(6116002)(25786009)(3846002)(236005)(54896002)(6306002)(6436002)(33656002)(5660300001)(606006)(14454004)(966005)(71190400001)(5024004)(2501003)(71200400001)(14444005)(86362001)(256004)(476003)(11346002)(53936002)(446003)(55016002)(97736004)(9686003)(53946003)(486006)(66066001)(5250100002)(186003)(6246003)(478600001)(99286004)(102836004)(53546011)(7696005)(39060400002)(72206003)(76176011)(110136005)(26005)(316002)(54906003)(6506007)(93886005)(4744004)(8676002)(8936002)(74316002)(81166006)(81156014)(68736007)(105586002)(2900100001)(229853002)(106356001)(2906002)(4326008)(7736002)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1894; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: O6hCvEP8NJCFjsRMt8j8Qr19Y5gfLapZ2o1OeyO4GwqIGgsy3eIf6f8tFjZ/lswe4B+qs8CXpfYXcVxourwrU8XWU9PoheMY3CaZo3G8VB69T34hiFwREmtD1HjpuYMnb2qPqvUGI9K9++CRaUlX5rulbgfW3mjRCEhM6YnwYy1GYZyskL+QhvbhnAcTbcwXfIo25GlF3b43ORWLdEhl3RFk65XeYq0vPSBYIxQTYvrV7aNwtgjX6yNG1tDqA5Bx5s+WEblN2JRbP9IiS5HaIzw+LVNxoUqK6MaYtucNoFtDFQu3zvdJ3GIYQ9wv2VDN3e4syJHsWDYwOfWKGYB/6lKyRlIvCdtD+Cm5uoD53T4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB190941EA048FE7B26F8E96639DF20DB5PR0301MB1909_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e9303eb-ff8a-4682-c02e-08d63c83a2e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2018 03:15:38.7953 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1894 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 03:15:59 -0000 --_000_DB5PR0301MB190941EA048FE7B26F8E96639DF20DB5PR0301MB1909_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWhtZWQgYW5kIGFsbCwKSSBhbSBvbiB2YWNhdGlvbiB0aGlzIHdlZWsgd2l0aCBqdXN0IG15IGNl bGwgcGhvbmUgdG8gc2VlIG15IGVtYWlscy4KCkkgd2lsbCBwcm92aWRlIHNvbWUgd29yZGluZyBv bmNlIEkgYW0gYmFjay4KCk1lYW53aGlsZSwgYXBvbG9naWVzIGZvciB0aGUgZGVsYXksClNhc2hh CgpUaHVtYiB0eXBlZCBieSBTYXNoYSBWYWluc2h0ZWluCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpGcm9tOiBBaG1lZCBCYXNoYW5keSA8YWJhc2hhbmR5LmlldGZAZ21haWwuY29t PgpTZW50OiBTdW5kYXksIE9jdG9iZXIgMjgsIDIwMTggMzowMjo0NSBBTQpUbzogQWxleGFuZGVy IFZhaW5zaHRlaW47IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tCkNjOiBKb25hdGhhbiBI YXJkd2ljayAoSm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20pOyBzaHJhZGRoYUBqdW5p cGVyLm5ldDsgc3ByaW5nQGlldGYub3JnClN1YmplY3Q6IFJlOiBSdGdEaXIgRWFybHkgcmV2aWV3 OiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMwoKU2FzaGEKCkkgdXBs b2FkZWQgdmVyc2lvbiAxNS4gQnV0IEkgd2FzIG5vdCBzdXJlIGhvdyB0byBiZXN0IGFkZHJlc3Mg eW91ciBjb25jZXJuCgpTbyBQbGVhc2UgcHJvcG9zZSB0aGUgd29yZGluZy9tb2RpZmljYXRpb25z IHRoYXQgbG9va3MgcmVhc29uYWJsZSB0byB5b3UgYW5kIEkgd2lsbCBiZSBtb3JlIHRoYW4gaGFw cHkgdG8gaW5jb3Jwb3JhdGUgdGhlbQoKQWhtZWQKCihJIHJlcGxpZWQgdG8gdGhpcyBlbWFpbCBh IGxpdHRsZSB3aGlsZSBhZ28gYnV0IEkgYW0gcmVwbHlpbmcgdG8gaXQgYWdhaW4gd2l0aCBhIGN1 dGRvd24gb24gdGhlIGxpc3Qgb2YgcmVjZWlwdHMgYmVjYXVzZSB0aGUgbWFpbGluZyBsaXN0IHNh aWQgdGhlIGVtYWlsIGlzIGJlaW5nIGhlbGQpCgoKCk9uIDcvMjUvMTggMTI6MjAgQU0sIEFsZXhh bmRlciBWYWluc2h0ZWluIHdyb3RlOgpTdGVwaGFuZSwKTG90cyBvZiB0aGFua3MgZm9yIHlvdXIg ZW1haWwsIGFuZCBhcG9sb2dpZXMgZm9yIGEgbG9uZyBkZWxheWVkIHJlc3BvbnNlLgpSZWdhcmRp bmcgeW91IHJlZmVyZW5jZSB0byDigJxCR1AgMzEwNyBsYWJlbCBvdmVyIGFuIExEUCBsYWJlbCBv dmVyIGFuIFJTVlAgbGFiZWwgdG8gYnVpbGQgYW4gZW5kLXRvLWVuZCB0cmFuc3BvcnTigJ0sIEkg aGF2ZSBsb29rZWQgdXAgUkZDIDgyNzc8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgy Nzc+ICB0aGF0IGhhcyByZXBsYWNlZCBSRkMgMzEwNywgYW5kIGZvdW5kIHRoZXJlIHRoZSBmb2xs b3dpbmcgZXhwbGljaXQgc3RhdGVtZW50OgoKICAgV2hlbiBwdXNoaW5nIGxhYmVscyBvbnRvIGEg cGFja2V0J3MgbGFiZWwgc3RhY2ssIHRoZSBUaW1lLXRvLUxpdmUKCiAgIChUVEwpIGZpZWxkIChb UkZDMzAzMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzAzMj5dLCBbUkZDMzQ0Mzxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzQ0Mz5dKSBhbmQgdGhlIFRyYWZmaWMgQ2xh c3MgKFRDKSBmaWVsZAoKICAgKFtSRkMzMDMyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzMDMyPl0sIFtSRkM1NDYyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDYyPl0p IG9mIGVhY2ggbGFiZWwgc3RhY2sgZW50cnkgbXVzdCwgb2YgY291cnNlLCBiZQoKICAgc2V0LiAg VGhpcyBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IGFueSBzZXQgb2YgcnVsZXMgZm9yIHNldHRp bmcKCiAgIHRoZXNlIGZpZWxkczsgdGhhdCBpcyBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kuCgpO byBlcXVpdmFsZW50IG9mIHRoaXMgc3RhdGVtZW50IGNvdWxkIGJlIGZvdW5kIGluIFJGQyAzMTA3 IOKAkyBwcm9iYWJseSBiZWNhdXNlIFJGQyAzNDQzIGhhcyBub3QgeWV0IGJlZW4gcHVibGlzaGVk IHRoZW4uCkZyb20gbXkgUE9WIGluY2x1ZGluZyB0aGUgc2FtZSAob3IgZXF1aXZhbGVudCkgZXhw bGljaXQgc3RhdGVtZW50IGluIHRoZSBkcmFmdCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIHJlc29s dmUgdGhlIGlzc3VlLgpIb3BlIHRoaXMgaGVscHMuClJlZ2FyZHMsClNhc2hhCgpPZmZpY2U6ICs5 NzItMzkyNjYzMDIKQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMgpFbWFpbDogICBBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20+CgpGcm9tOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb20+IFttYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb21dClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxOCwgMjAxOCAyOjI3IFBNClRvOiBBaG1lZCBC YXNoYW5keSA8YWJhc2hhbmR5LmlldGZAZ21haWwuY29tPjxtYWlsdG86YWJhc2hhbmR5LmlldGZA Z21haWwuY29tPjsgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPjxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+CkNjOiBy dGctZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPjsgJ21wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+JyA8bXBsc0BpZXRmLm9yZz48bWFpbHRvOm1wbHNAaWV0Zi5v cmc+OyAnYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4nIDxh ZHJpYW5Ab2xkZG9nLmNvLnVrPjxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az47IEpvbmF0aGFu IEhhcmR3aWNrIChKb25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbTxtYWlsdG86Sm9uYXRo YW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+KSA8am9uYXRoYW4uaGFyZHdpY2tAbWV0YXN3aXRj aC5jb20+PG1haWx0bzpqb25hdGhhbi5oYXJkd2lja0BtZXRhc3dpdGNoLmNvbT47IHNocmFkZGhh QGp1bmlwZXIubmV0PG1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldD47IHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPjsgc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmc+ClN1YmplY3Q6IFJFOiBSdGdEaXIgRWFybHkg cmV2aWV3OiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMwoKSGkgU2Fz aGEsCj4gVGhlIGhlYWQtZW5kIG5vZGUgc2VuZHMgU1ItTVBMUyBwYWNrZXRzIGFjcm9zcyBhIHBh dGggZGVmaW5lZCBieSBhbiBvcmRlcmVkIHNldCBvZiBTSURzIHdpdGggbW9yZSB0aGFuIG9uZSBT SUQgaW4gdGhlIGxpc3QuIEVhY2ggU0lEIGlzIHJlcHJlc2VudGVkIGJ5IGEgbGFiZWwgc3RhY2sg ZW50cnkgKExTRSkgaW4gdGhlIE1QTFMgbGFiZWwgc3RhY2ssIGFuZCB0aGUgbGFiZWwgZmllbGQg aW4gZWFjaCBMU0UgaXMgdGhlIGxhYmVsIHRoYXQgbWF0Y2hlcyB0aGUgY29ycmVzcG9uZGluZyBT SUQuIEhvd2V2ZXIsIGVhY2ggTFNFIGFsc28gaW5jbHVkZXMgdGhlIFRUTCBhbmQgVEMgZmllbGRz LiBIb3cgZG9lcyB0aGUgaGVhZC1lbmQgbm9kZSBzZXQgdGhlc2UgZmllbGRzIGluIGVhY2ggb2Yg dGhlIExTRXMgZm9sbG93aW5nIHRoZSB0b3Agb25lPyBUaGlzIGNsZWFybHkgZGVwZW5kcyBvbiB0 aGUgbW9kZWwgKFVuaWZvcm0gdnMuIFBpcGUvU2hvcnQgUGlwZSkgaW1wbGVtZW50ZWQgaW4gZWFj aCBub2RlIHRoYXQgdGhhdCBwZXJmb3JtcyBOZXh0IG9wZXJhdGlvbiBvbiB0aGUgcGFja2V0IGFs b25nIHRoZSBwYXRoIOKAkyBidXQgdGhlIGhlYWQtZW5kIG5vZGUgdXN1YWxseSBpcyBub3QgYXdh cmUgb2YgdGhhdC4KV2h5IGRvIHlvdSB0aGluayB0aGlzIGlzIGRpZmZlcmVudCBmcm9tIGEgbmVz dGVkIE1QTFMgdHVubmVsIHRoYXQgZXhpc3RzIHRvZGF5ID8gSSBjb21wbGV0ZWx5IGFncmVlIHdp dGggeW91IHRoYXQgdGhlIGhlYWQgZW5kIGRvZXMgbm90IGtub3cgdGhlIGJlaGF2aW9yIG9mIHRo ZSB0YWlsLWVuZCBpbiB0ZXJtIG9mIFRUTC9UQyBwcm9jZXNzaW5nLiBCdXQgdGhhdOKAmXMgYWxy ZWFkeSB0aGUgY2FzZSB0b2RheSwgYW5kIGl04oCZcyB0aGUgam9iIG9mIGVuZ2luZWVycyB0byBl bnN1cmUgdGhhdCBhbGwgbm9kZXMgaW4gdGhlIG5ldHdvcmsgYXJlIG9wZXJhdGluZyBpbiB0aGUg c2FtZSBtb2RlICh1bmlmb3JtIHZzIHBpcGUvc2hvcnQgcGlwZSkuCldlIGNhbiBhbHJlYWR5IHN0 YWNrIHRvZGF5IGEgQkdQIDMxMDcgbGFiZWwgb3ZlciBhbiBMRFAgbGFiZWwgb3ZlciBhbiBSU1ZQ IGxhYmVsIHRvIGJ1aWxkIGFuIGVuZC10by1lbmQgdHJhbnNwb3J0LCB0aGUgVFRMIHByb2Nlc3Np bmcgc2hvdWxkIG5vdCBiZSBlc3NlbnRpYWxseSBkaWZmZXJlbnQuCkNvdWxkIHlvdSBwaW4gcG9p bnQgdGhlIGRpZmZlcmVuY2UgdGhhdCB5b3Ugc2VlID8KCkJyZ2RzLAoKU3RlcGhhbmUKCgpGcm9t OiBBaG1lZCBCYXNoYW5keSBbbWFpbHRvOmFiYXNoYW5keS5pZXRmQGdtYWlsLmNvbV0KU2VudDog TW9uZGF5LCBKdWx5IDE2LCAyMDE4IDIyOjAzClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbgpDYzog cnRnLWRpckBpZXRmLm9yZzxtYWlsdG86cnRnLWRpckBpZXRmLm9yZz47ICdtcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPic7ICdhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJp YW5Ab2xkZG9nLmNvLnVrPic7IEpvbmF0aGFuIEhhcmR3aWNrIChKb25hdGhhbi5IYXJkd2lja0Bt ZXRhc3dpdGNoLmNvbTxtYWlsdG86Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+KTsg c2hyYWRkaGFAanVuaXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pjsgc3ByaW5n QGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBzcHJpbmctY2hhaXJzQGlldGYub3Jn PG1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLW1wbHMuYXV0aG9yc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmct c2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0aG9yc0BpZXRmLm9yZz4KU3ViamVjdDogUmU6IFJ0Z0Rp ciBFYXJseSByZXZpZXc6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTEz CgoKVGhhbmtzIGEgbG90IGZvciB0aGUgcmVwbHkKClNlZSBpbmxpbmUgIiMjQWhtZWQiCgpPbiA3 LzExLzE4IDI6MDIgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOgpBaG1lZCwgYW5kIGFs bCwKTG90cyBvZiB0aGFua3MgZm9yIGEgZGV0YWlsZWQgcmVzcG9uc2UgdG8gbXkgY29tbWVudHMu ClBsZWFzZSBzZWUgaW5saW5lIGJlbG93IG15IHBvc2l0aW9uIG9uIGVhY2ggb2YgdGhlbS4KClJl Z2FyZHMsClNhc2hhCgpPZmZpY2U6ICs5NzItMzkyNjYzMDIKQ2VsbDogICAgICArOTcyLTU0OTI2 NjMwMgpFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+CgpGcm9tOiBBaG1lZCBCYXNoYW5keSBbbWFp bHRvOmFiYXNoYW5keS5pZXRmQGdtYWlsLmNvbV0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDExLCAy MDE4IDQ6NDIgQU0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT48bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPjsg c3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz47IGRy YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5v cmc+CkNjOiBydGctZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPjsgJ21wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+JyA8bXBsc0BpZXRmLm9yZz48bWFpbHRvOm1w bHNAaWV0Zi5vcmc+OyAnYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5j by51az4nIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az47 IEpvbmF0aGFuIEhhcmR3aWNrIChKb25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbTxtYWls dG86Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+KSA8am9uYXRoYW4uaGFyZHdpY2tA bWV0YXN3aXRjaC5jb20+PG1haWx0bzpqb25hdGhhbi5oYXJkd2lja0BtZXRhc3dpdGNoLmNvbT47 IHNocmFkZGhhQGp1bmlwZXIubmV0PG1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldD47IHNwcmlu Z0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPgpTdWJqZWN0OiBSZTogUnRnRGlyIEVh cmx5IHJldmlldzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTMKCgpU aGFua3MgZm9yIHRob3JvdWdoIChhbmQgVkVSWSBjbGVhcikgdGhlIHJldmlldwoKU2VlIGlubGlu ZSAjQWhtZWQKCgoKQWhtZWQKCgoKT24gNi8xNS8xOCAxMTowOCBQTSwgQWxleGFuZGVyIFZhaW5z aHRlaW4gd3JvdGU6ClJlLXNlbmRpbmcgdG8gIGNvcnJlY3QgU1BSSU5HIFdHIGxpc3QuClNpbmNl cmUgYXBvbG9naWVzIGZvciB0aGUgZGVsYXkgY2F1c2VkIGJ5IGEgdHlwby4KVGh1bWIgdHlwZWQg YnkgU2FzaGEgVmFpbnNodGVpbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJv bTogQWxleGFuZGVyIFZhaW5zaHRlaW4KU2VudDogU3VuZGF5LCBKdW5lIDEwLCAyMDE4IDEwOjQz OjUyIEFNClRvOiBzcHJpbmctY2hhaXJzQGlldGYub3JnPG1haWx0bzpzcHJpbmctY2hhaXJzQGll dGYub3JnPjsgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0aG9yc0Bp ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0 aG9yc0BpZXRmLm9yZz4KQ2M6IHNwcmluZ0BpZXRmLmNvbTxtYWlsdG86c3ByaW5nQGlldGYuY29t PjsgcnRnLWRpckBpZXRmLm9yZzxtYWlsdG86cnRnLWRpckBpZXRmLm9yZz47ICdtcGxzQGlldGYu b3JnPG1haWx0bzptcGxzQGlldGYub3JnPic7ICdhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzph ZHJpYW5Ab2xkZG9nLmNvLnVrPic7IEpvbmF0aGFuIEhhcmR3aWNrIChKb25hdGhhbi5IYXJkd2lj a0BtZXRhc3dpdGNoLmNvbTxtYWlsdG86Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+ KTsgc2hyYWRkaGFAanVuaXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0PgpTdWJq ZWN0OiBSRTogUnRnRGlyIEVhcmx5IHJldmlldzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLW1wbHMtMTMKCkV4cGxpY2l0bHkgYWRkaW5nIFNocmFkZGhhICB3aG8gaXMgdGhlIHNo ZXBoZXJkIG9mIHRoaXMgZHJhZnQuCgpSZWdhcmRzLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2 MzAyCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPgoK RnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4KU2VudDogRnJpZGF5LCBKdW5lIDgsIDIwMTggNTo0 MyBQTQpUbzogJ3NwcmluZy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc+JyA8c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz48bWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc+OyAnZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0aG9yc0Bp ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0 aG9yc0BpZXRmLm9yZz4nIDxkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy5h dXRob3JzQGlldGYub3JnPjxtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LW1wbHMuYXV0aG9yc0BpZXRmLm9yZz4KQ2M6ICdzcHJpbmdAaWV0Zi5jb208bWFpbHRvOnNwcmlu Z0BpZXRmLmNvbT4nIDxzcHJpbmdAaWV0Zi5jb20+PG1haWx0bzpzcHJpbmdAaWV0Zi5jb20+OyBy dGctZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz47ICdhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5A b2xkZG9nLmNvLnVrPicgPGFkcmlhbkBvbGRkb2cuY28udWs+PG1haWx0bzphZHJpYW5Ab2xkZG9n LmNvLnVrPgpTdWJqZWN0OiBSdGdEaXIgRWFybHkgcmV2aWV3OiBkcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctbXBscy0xMwoKCkhlbGxvLApJIGhhdmUgYmVlbiBzZWxlY3RlZCB0byBk byBhIHJvdXRpbmcgZGlyZWN0b3JhdGUg4oCcZWFybHnigJ0gcmV2aWV3IG9mIHRoaXMgZHJhZnQ6 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1tcGxzLwoKVGhlIHJvdXRpbmcgZGlyZWN0b3JhdGUgd2lsbCwgb24gcmVxdWVz dCBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIGNoYWlyLCBwZXJmb3JtIGFuIOKAnGVhcmx54oCdIHJl dmlldyBvZiBhIGRyYWZ0IGJlZm9yZSBpdCBpcyBzdWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIHRv IHRoZSBJRVNHLiBUaGUgZWFybHkgcmV2aWV3IGNhbiBiZSBwZXJmb3JtZWQgYXQgYW55IHRpbWUg ZHVyaW5nIHRoZSBkcmFmdOKAmXMgbGlmZXRpbWUgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 LiBUaGUgcHVycG9zZSBvZiB0aGUgZWFybHkgcmV2aWV3IGRlcGVuZHMgb24gdGhlIHN0YWdlIHRo YXQgdGhlIGRvY3VtZW50IGhhcyByZWFjaGVkLiBBcyB0aGlzIGRvY3VtZW50IGlzIGN1cnJlbnRs eSBpbiB0aGUgV0cgTGFzdCBjYWxsLCBteSBmb2N1cyBmb3IgdGhlIHJldmlldyB3YXMgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4gUGxl YXNlIGNvbnNpZGVyIG15IGNvbW1lbnRzIGFsb25nIHdpdGggdGhlIG90aGVyIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGNvbW1lbnRzLgoKRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJv dXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcgoKRG9jdW1lbnQ6IGRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1tcGxzLTEzClJldmlld2VyOiBBbGV4YW5kZXIgKOKAnFNhc2hh4oCd KSBWYWluc2h0ZWluIChhbGV4YW5kZXIudmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86YWxl eGFuZGVyLnZhaW5zaHRlaW5AZWNpdGVsZS5jb20+KQpSZXZpZXcgRGF0ZTogMDgtSnVuLTE4Cklu dGVuZGVkIFN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQuCgpTdW1tYXJ5OgoKSSBoYXZlIHNvbWUg bWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJl IHJlc29sdmVkIGJlZm9yZSBpdCBpcyBzdWJtaXR0ZWQgdG8gdGhlIElFU0cuCgpDb21tZW50czoK CkkgY29uc2lkZXIgdGhpcyBkcmFmdCBhcyBhbiBpbXBvcnRhbnQgIGNvbXBhbmlvbiBkb2N1bWVu dCB0byB0aGUgU2VnbWVudCBSb3V0aW5nIEFyY2hpdGVjdHVyZTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTE1PiBkcmFmdCB0aGF0 LCBpZGVhbGx5LCBzaG91bGQgYXVnbWVudCBkZWZpbml0aW9ucyBvZiB0aGUgU2VnbWVudCBSb3V0 aW5nIChTUikgbm90aW9ucyBhbmQgY29uc3RydWN0cyBnaXZlbiB0aGVyZSB3aXRoIGRldGFpbHMg c3BlY2lmaWMgZm9yIHRoZSBTUiBpbnN0YW50aWF0aW9uIHRoYXQgdXNlcyAgdGhlIE1QTFMgZGF0 YSBwbGFuZSAoU1ItTVBMUykuICBNYW55IGlzc3VlcyByYWlzZWQgaW4gbXkgcmV2aWV3IHJlZmxl Y3QgZWl0aGVyIGdhcHMgdGhhdCBzaG91bGQgYmUsIGJ1dCBoYXZlIG5vdCBiZWVuLCBjbG9zZWQs IG9yIGluY29uc2lzdGVuY2llcyBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzLgoKClNpbmNlIFJGQyA4 Mjg3PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4Mjg3PiBpcyBhbHJlYWR5IHB1Ymxp c2hlZCBhcyBhIFN0YW5kYXJkcyBUcmFjayBSRkMsIEkgZXhwZWN0IHN1Y2ggYXVnbWVudGF0aW9u IHRvIGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCB0aGlzIGRvY3VtZW50IChvciB0byBwcm92 aWRlIGNsZWFyIGluZGljYXRpb25zIG9mIHJlcXVpcmVkIHVwZGF0ZXMgdG8gdGhpcyBkb2N1bWVu dCkuIEFuZCBJIGluY2x1ZGUgdGhlIE1QTFMgV0cgaW50byBkaXN0cmlidXRpb24gbGlzdC4KClRo aXMgZHJhZnQgd2FzIG5vdCBlYXN5IHJlYWRpbmcgZm9yIG1lLiBJbiBwYXJ0aWN1bGFyLCB0aGUg c3R5bGUgb2YgU2VjdGlvbiAyLjUgdGhhdCBkaXNjdXNzZXMgYXQgbGVuZ3RoIGFuZCBpbiBzb21l IGRldGFpbCBtdWx0aXBsZSDigJxjb3JuZXIgY2FzZXPigJ0gcmVzdWx0aW5nLCBwcmVzdW1hYmx5 LCBmcm9tIG1pc2NvbmZpZ3VyYXRpb24sIGJlZm9yZSBpdCBleHBsYWlucyB0aGUgYmFzaWMgKGFu ZCByZWxhdGl2ZWx5IHNpbXBsZSkg4oCcbm9ybWFs4oCdIGJlaGF2aW9yLCBsb29rcyBwcm9ibGVt YXRpYyB0byBtZS4KClRoZSBXRyBMYXN0IENhbGwgaGFzIGJlZW4gZXh0ZW5kZWQgYnkgb25lIHdl ZWsuIE5ldmVydGhlbGVzcywgSSBhbSBzZW5kaW5nIG91dCBteSBjb21tZW50cwoKTWFqb3IgSXNz dWVzOiBOb25lIGZvdW5kCiNBaG1lZDogdGhhbmtzIGEgbG90CgoKCgpNaW5vciBJc3N1ZXM6IFF1 aXRlIGEgZmV3IGJ1dCwgaG9wZWZ1bGx5LCBlYXN5IHRvIHJlc29sdmUuCgoKMS4gICAgRW5jYXBz dWxhdGlvbiBvZiBTUi1NUExTIHBhY2tldHM6CgphLiAgICBSRkMgMzAzMiAocmVmZXJlbmNlZCBi eSB0aGUgZHJhZnQpIGFuZCBSRkMgNTMzMiAobm90IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQpIGRl cGVuZCB0d28gZW5jYXBzdWxhdGlvbnMgb2YgbGFiZWxlZCBwYWNrZXRzIC0gb25lIGZvciBEb3du c3RyZWFtLWFsbG9jYXRlZCBsYWJlbHMgYW5kIGFub3RoZXIgZm9yIFVwc3RyZWFtLWFsbG9jYXRl ZCBvbmVzLgojQWhtZWQ6IFJGQzUzMzIgaXMgZm9yIG11bHRpY2FzdC4gQXMgbWVudGlvbmVkIGlu IFNlY3Rpb24gNiBvZiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMTUsIG11bHRp Y2FzdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBTUi4gSGVuY2UgdGhlIFJGQyB3YXMgbm90IHJl ZmVycmVkIHRvIGluIHRoZSBTUi1NUExTIGRyYWZ0CltbU2FzaGFdXSBJIHdvdWxkIGJlIHNhdGlz ZmllZCB3aXRoIHRoaXMgcmVzcG9uc2UsIHdvdWxkIGl0IG5vdCBiZSBmb3IgdGhlIGZvbGxvd2lu ZyB0ZXh0IEkgc2VlIGluIFNlY3Rpb24gMi4yIG9mIHRoZSBTUiBQb2xpY3kgQXJjaGl0ZWN0dXJl PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmctcG9saWN5LTAxPiBkcmFmdDoKICAgQSB2YXJpYXRpb24gb2YgU1IgUG9saWN5IGNhbiBi ZSB1c2VkIGZvciBwYWNrZXQgcmVwbGljYXRpb24uICBBCiAgIGNhbmRpZGF0ZSBwYXRoIGNvdWxk IGNvbXByaXNlIG11bHRpcGxlIFNJRC1MaXN0czsgb25lIGZvciBlYWNoCiAgIHJlcGxpY2F0aW9u IHBhdGguICBJbiBzdWNoIGEgc2NlbmFyaW8sIHBhY2tldHMgYXJlIGFjdHVhbGx5CiAgIHJlcGxp Y2F0ZWQgdGhyb3VnaCBlYWNoIFNJRCBMaXN0IG9mIHRoZSBTUiBQb2xpY3kgdG8gcmVhbGl6ZSBh IHBvaW50LQogICB0by1tdWx0aXBvaW50IHNlcnZpY2UgZGVsaXZlcnkuCgpUaGlzIGxvb2tzIHRv IG1lIGFzIGJlaW5nIHZlcnkgbXVjaCBtdWx0aWNhc3QgaW4gU1IsIGFuZCwgdW5sZXNzIHlvdSB3 YW50IHRvIHNheSB0aGF0IGl0IGlzIGxpbWl0ZWQgdG8gU1J2NiwgbWFrZXMgbXkgcXVlc3Rpb24g cmVsZXZhbnQgSU1ITy4KIyNBaG1lZDogVGhlIG1haW4gcmVmZXJlbmNlIGZvciB0aGlzIGRyYWZ0 IGlzIHRoZSBzci1hcmNoaXRlY3R1cmUsIHdoaWNoIGNsZWFybHkgc3RhdGVzIHRoYXQgbXVsdGlj YXN0IGlzIG91dCBvZiBTUiBzY29wZS4gU1ItTVBMUywgYmVpbmcgYW4gTVBMUyBpbnN0YW50aWF0 aW9uIG9mIHRoZSBTUi1hcmNoaXRlY3R1cmUsIGZvbGxvd3MgdGhlIFNSLWFyY2hpdGVjdHVyZSBh cyBjbG9zZSBhcyBwb3NzaWJsZS4gSWYgYW5vdGhlciBkcmFmdCBwcm9wb3NlcyBzb21ldGhpbmcg cmVsYXRlZCB0byBTUiwgdGhlbiBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIG90aGVy IGRyYWZ0IHRvIG1lbnRpb24gYW55IGV4dGVuc2lvbnMvcmVzdHJpY3Rpb25zIGluIHJlbGF0aW9u IHRvIHRoZSBiYXNpYyBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmcgYW5kL29yIFNS LU1QTFMsIG9yIHRvIHNwZWNpZmljYWxseSBzYXkgdGhhdCBpdCBkb2VzIG5vdCBhcHBseSB0byBT Ui1NUExTLgoKCgpiLiAgICBGcm9tIG15IFBPViB0aGUgU1QtTVBMUyBvbmx5IHVzZXMgRG93bnN0 cmVhbS1hbGxvY2F0ZWQgbGFiZWxzIOKAkyBidXQgSSBleHBlY3QgdGhlIGRyYWZ0IHRvIHN0YXRl IHRoYXQgZXhwbGljaXRseSwgb25lIHdheSBvciBhbm90aGVyLiAoSWYgVXBzdHJlYW0tYWxsb2Nh dGVkIGxhYmVscyBhcmUgcmVsZXZhbnQgZm9yIFNSLU1QTFMsIEkgd291bGQgc2VlIGl0IGFzIGEg bWFqb3IgZ2FwLCBzbyBJIGhvcGUgdGhhdCB0aGlzIGlzIG5vdCB0aGUgY2FzZSkuCiNBaG1lZDog SSB3aWxsIGFkZCBhIHN0YXRlbWVudCBpbiBzZWN0aW9uIDIuMiB0byBtZW50aW9uIHRoYXQgaXQg aXMgZG93bi1zdHJlYW0gYWxsb2NhdGVkIGFzIHlvdSBtZW50aW9uZWQKW1tTYXNoYV1dIFRoaXMg aXMgcXVpdGUgdW5hbWJpZ3VvdXMgYW5kLCBvbmNlIGFkZGVkLCB3b3VsZCByZXNvbHZlIG15IGNv bW1lbnQgaW4gZnVsbCDigJMgdGhlIHByZXZpb3VzIGNvbW1lbnQgbm90d2l0aHN0YW5kaW5nLiBJ biBwYXJ0aWN1bGFyLCBpdCB3b3VsZCBpbXBseSB0aGF0IGV2ZW4gbGFiZWxzIHJlcHJlc2VudGlu ZyBCU0lEcyBvZiBhIFNSIFJlcGxpY2F0aW9uIHBvbGljaWVzIHdpbGwgYmUgZG93bnN0cmVhbS1h bGxvY2F0ZWQuCiNBaG1lZDogQmluZGluZyBTSUQgaXMganVzdCBhIHNwZWNpYWwgY2FzZSBvZiBh IFNJRC4gU28gd2hhdCBhcHBsaWVzIHRvIGEgU0lEIGFwcGxpZXMgdG8gYSBiaW5kaW5nIFNJRAoK CgoKMi4gICAgTGFiZWwgc3BhY2VzIGluIFNSLU1QTFM6CgphLiAgICBSRkMgMzAzMSAocmVmZXJl bmNlZCBieSB0aGUgZHJhZnQpIGRlZmluZXMgcGVyLXBsYXRmb3JtIGFuZCBwZXItaW50ZXJmYWNl IGxhYmVsIHNwYWNlcywgYW5kIFJGQyA1MzMxIChub3QgbWVudGlvbmVkIGluIHRoZSBkcmFmdCkg YWRkcyBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBhbmQgY29udGV4dCBsYWJlbHMuCgpi LiAgICBUaGUgZHJhZnQgZG9lcyBub3Qgc2F5IHdoaWNoIG9mIHRoZXNlIGFyZSBvciBhcmUgbm90 IHJlbGV2YW50IGZvciBTUi1NUExTCgpjLiAgICBGcm9tIG15IFBPVjoKCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgTGFiZWxzIHJlcHJlc2VudGluZyBhbGwg a2luZHMgb2YgU0lEcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0IE1VU1QgYmUgYWxsb2NhdGVkIGZy b20gdGhlIHBlci1wbGF0Zm9ybSBsYWJlbCBzcGFjZSBvbmx5CgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaWkuICAgIEF0IHRoZSBzYW1lIHRpbWUsIGluc3RhbnRpYXRp b24gb2YgTWlycm9yIFNlZ21lbnQgSURzIGRlZmluZWQgaW4gU2VjdGlvbiA1LjEgb2YgdGhlIFNl Z21lbnQgUm91dGluZyBBcmNoaXRlY3R1cmUgZHJhZnQgdXNpbmcgTVBMUyBkYXRhIHBsYW5lIGNs ZWFybHkgY2FsbHMgZm9yIGNvbnRleHQgbGFiZWxzIGFuZCBjb250ZXh0LXNwZWNpZmljIGxhYmVs IHNwYWNlcwoKZC4gICAgSSBleHBlY3QgdGhlIGRyYWZ0IHRvIHByb3ZpZGUgYSBjbGVhci1jdXQg cG9zaXRpb24gb24gdGhlc2UgYXNwZWN0cyBvZiBTUi1NUExTLgojQWhtZWQ6IEkgd2lsbCBhZGQg YSBzdGF0ZW1lbnQgdG8gc2VjdGlvbiAyLjIgdG8gc2F5IHRoYXQgdGhlIGl0IGlzIHBlci1wbGF0 Zm9ybS4gUmVnYXJkaW5nIHRoZSBmdW5jdGlvbiAibWlycm9yaW5nIiwgU1IgYXR0YWNoZXMgYSAq ZnVuY3Rpb24qIHRvIGVhY2ggU0lELiBUaGUgIm1pcnJvcmluZyIgZnVuY3Rpb24gaXMgYWxyZWFk eSBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjEgb2YgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nIGFuZCBpcyBub3Qgc3BlY2lmaWMgdG8gdGhlIE1QTFMgZm9yd2FyZGluZyBwbGFuZS4g SGVuY2UgdGhlcmUgaXMgbm8gbmVlZCB0byByZS1tZW50aW9uIGl0IGhlcmUgYmVjYXVzZSB0aGlz IGRvY3VtZW50IGlzIHRyeWluZyB0byBiZSBhcyBzcGVjaWZpYyBhcyBwb3NzaWJsZSB0byB0aGUg TVBMUyBmb3J3YXJkaW5nIHBsYW5lLiBHZW5lcmFsIGZ1bmN0aW9ucyBhdHRhY2hlZCB0byBTSUQg YXJlIGRlc2NyaWJlZCBpbiB0aGUgc2VnbWVudCByb3V0aW5nIGFyY2hpdGVjdHVyZSBkb2N1bWVu dCBvciBmdXR1cmUgZG9jdW1lbnRzLiBGdXJ0dXJlIGRvY3VtZW50cyBwcm9wb3NpbmcgbmV3IFNS IGZ1bmN0aW9uIG11c3QgYmUgYXMgc3BlY2lmaWMgYW5kIGNsZWFyIGFzIHBvc3NpYmxlCltbU2Fz aGFdXSBMb29rcyBPSyB0byBtZS4KCgoKCgozLiAgICBTUi1NUExTIGFuZCBoaWVyYXJjaGljYWwg TFNQczoKCmEuICAgIFNSIExTUHMgdGhhdCBpbmNsdWRlIG1vcmUgdGhhbiBvbmUgc2VnbWVudCBh cmUgaGllcmFyY2hpY2FsIExTUHMgZnJvbSB0aGUgUE9WIG9mIHRoZSBNUExTIGRhdGEgcGxhbmUu IFRoZXJlZm9yZSBzb21lIChwb3NzaWJseSwgYWxsKSBvZiB0aGUgbW9kZWxzIGZvciBoYW5kbGlu ZyBUVEwgYW5kIFRDIGJpdHMgdGhhdCBoYXZlIGJlZW4gZGVmaW5lZCBpbiBSRkMgMzQ0MyAobm90 IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQpIHNob3VsZCBhcHBseSB0byBTUi1NUExTCgpiLiAgICBS RkMgODI4NyAobm90IHJlZmVyZW5jZWQgaW4gdGhlIGRyYWZ0KSBzcGVjaWZpY2FsbHkgZGlzY3Vz c2VkIG9wZXJhdGlvbiBvZiB0aGUgTFNQIFRyYWNlcm91dGUgZnVuY3Rpb24gZm9yIFNSIExTUHMg aW4gdGhlIGNhc2Ugd2hlbiBQaXBlL1Nob3J0IFBpcGUgbW9kZWwgZm9yIFRUTCBoYW5kbGluZyBp cyB1c2VkCgpjLiAgICBJIGV4cGVjdCB0aGUgZHJhZnQgdG8gcHJvdmlkZSBhdCBsZWFzdCBzb21l IGd1aWRlbGluZXMgcmVnYXJkaW5nIGFwcGxpY2FiaWxpdHkgb2YgZWFjaCBzcGVjaWZpYyBtb2Rl bCBkZWZpbmVkIGluIFJGQyAzNDQzIChzZXBhcmF0ZWx5IGZvciBUVEwgYW5kIFRDIGJpdHMpIHRv IFNSLU1QTFMuCiNBaG1lZDogQlkgZGVzaWduLCB0aGUgaW5zdGFudGlhdGlvbiBvZiBTUiBvdmVy IHRoZSBNUExTIGZvcndhcmRpbmcgcGxhbmUgKGFuZCBoZW5jZSB0aGlzIGRyYWZ0KSBkb2VzIG5v dCBtb2RpZnkgdGhlIE1QTFMgZm9yd2FyZGluZyBwbGFuIGJlaGF2aW9yIGFzIGl0IGlzIG1lbnRp b25lZCBpbiB0aGUgZmlyc3Qgc2VudGVuY2UgaW4gU2VjdGlvbiAxLiBTbyB0aGUgVFRMIGJlaGF2 aW9yIHNwZWNpZmllZCBpbiByZmMzNDQzIGlzIGFscmVhZHkgaW1wbGllZCBhbmQgdGhlcmUgaXMg bm8gbmVlZCB0byByZS1tZW50aW9uIGl0IGhlcmUganVzdCBsaWtlIGFsbCBhc3BlY3RzIG9mIE1Q TFMgZm9yd2FyZGluZy4gUkZDODI4NyBpcyBPQU0tc3BlY2lmaWMuICBTUi1PQU0gaXMgaGFuZGxl ZCBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IHNvIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZHJhZnQKW1tTYXNoYV1dIFVuZm9ydHVuYXRlbHkgSSBkbyBub3QgdGhpbmsgdGhpcyBpcyBnb29k IGVub3VnaC4gTGV0IG1lIGFzayBhIHNwZWNpZmljIHF1ZXN0aW9uIHJlZmxlY3RpbmcgbXkgY29u Y2VybnM6ClRoZSBoZWFkLWVuZCBub2RlIHNlbmRzIFNSLU1QTFMgcGFja2V0cyBhY3Jvc3MgYSBw YXRoIGRlZmluZWQgYnkgYW4gb3JkZXJlZCBzZXQgb2YgU0lEcyB3aXRoIG1vcmUgdGhhbiBvbmUg U0lEIGluIHRoZSBsaXN0LiBFYWNoIFNJRCBpcyByZXByZXNlbnRlZCBieSBhIGxhYmVsIHN0YWNr IGVudHJ5IChMU0UpIGluIHRoZSBNUExTIGxhYmVsIHN0YWNrLCBhbmQgdGhlIGxhYmVsIGZpZWxk IGluIGVhY2ggTFNFIGlzIHRoZSBsYWJlbCB0aGF0IG1hdGNoZXMgdGhlIGNvcnJlc3BvbmRpbmcg U0lELiBIb3dldmVyLCBlYWNoIExTRSBhbHNvIGluY2x1ZGVzIHRoZSBUVEwgYW5kIFRDIGZpZWxk cy4gSG93IGRvZXMgdGhlIGhlYWQtZW5kIG5vZGUgc2V0IHRoZXNlIGZpZWxkcyBpbiBlYWNoIG9m IHRoZSBMU0VzIGZvbGxvd2luZyB0aGUgdG9wIG9uZT8gVGhpcyBjbGVhcmx5IGRlcGVuZHMgb24g dGhlIG1vZGVsIChVbmlmb3JtIHZzLiBQaXBlL1Nob3J0IFBpcGUpIGltcGxlbWVudGVkIGluIGVh Y2ggbm9kZSB0aGF0IHRoYXQgcGVyZm9ybXMgTmV4dCBvcGVyYXRpb24gb24gdGhlIHBhY2tldCBh bG9uZyB0aGUgcGF0aCDigJMgYnV0IHRoZSBoZWFkLWVuZCBub2RlIHVzdWFsbHkgaXMgbm90IGF3 YXJlIG9mIHRoYXQuClJGQyA4Mjg3IGlzIHJlbGV2YW50IGFzIGFuIGV4YW1wbGUgaGVyZSBJTUhP IGJlY2F1c2UgaXQgcmVjb21tZW5kcyB0aGUgZm9sbG93aW5nIHNldHRpbmcgb2YgVFRMIGluIFRy YWNlcm91dGUgcGFja2V0czoKCi0gICAgICAgICAgU2V0IHRoZSBUVEwgb2YgYWxsIHRoZSBsYWJl bHMgYWJvdmUgb25lIHRoYXQgcmVwcmVzZW50cyB0aGUgc2VnbWVudCB5b3UgYXJlIGN1cnJlbnRs eSB0cmFjaW5nIHRvIG1heGltdW0KCi0gICAgICAgICAgU2V0IHRoZSBUVEwgb2YgdGhlIGxhYmVs IG9uZSB0aGF0IHJlcHJlc2VudHMgdGhlIHNlZ21lbnQgeW91IGFyZSBjdXJyZW50bHkgdHJhY2lu ZyB0byB0aGUgZGVzaXJlZCB2YWx1ZSAodG8gYmUgaW5jcmVtZW50ZWQgdW50aWwgZW5kIG9mIHNl Z21lbnQgaXMgcmVhY2hlZAoKLSAgICAgICAgICBTZXQgdGhlIFRUTCBvZiBhbGwgdGhlIGxhYmVs cyBiZWxvdyBvbmUgdGhhdCByZXByZXNlbnRzIHRoZSBzZWdtZW50IHlvdSBhcmUgY3VycmVudGx5 IHRyYWNpbmcgdG8gMC4KSSBleHBlY3QgdGhlIGRyYWZ0IHRvIHByb3ZpZGUgc29tZSByZWNvbW1l bmRhdGlvbnMgZm9yIHRyYWZmaWMgKG5vbi1PQU0pIHBhY2tldHMgYXMgd2VsbC4KIyNBaG1lZDog VGhlIHNldHRpbmcgb2YgdGhlIFRUTCBmb3Igbm9uLU9BTSBwYWNrZXRzIGFyZSBzdWJqZWN0IHRv IHRoZSBwb2xpY3kgdGhhdCBjb25zdHJ1Y3RlZCB0aGUgbGFiZWwgc3RhY2suIFNSLXBvbGljeSBp cyBoYW5kbGVkIGluIGEgc2VwYXJhdGUgZHJhZnQKCgoKCgoKCjQuICAgIEluZmVycmluZyBuZXR3 b3JrIGxheWVyIHByb3RvY29sIGluIFNSLU1QTFM6CgphLiAgICBJIHdvbmRlciBpZiB0aGUgZHJh ZnQgY291bGQgcHJvdmlkZSBhbnkgZGV0YWlscyBvbiB0aGUgc2l0dWF0aW9uIHdoZW4gYSBsYWJl bCB0aGF0IHJlcHJlc2VudHMgc29tZSBraW5kIG9mIFNJRCBpcyB0aGUgYm90dG9tLW9mLXN0YWNr IGxhYmVsIHRvIGJlIHBvcHBlZCBieSB0aGUgZWdyZXNzIExFUgojYWhtZWQ6IFRoaXMgaXMgcGFy dCBvZiB0aGUgIk5leHQiIGZ1bmN0aW9uLiBJdCBpcyBkZXNjcmliZWQgaW4gZGV0YWlsIGluIHRo aXMgZG9jdW1lbnQuCltbU2FzaGFdXSBORVhUIGZ1bmN0aW9uIGlzIG1lbnRpb25lZCBpbiBzZXZl cmFsIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQuIENhbiB5b3UgcGxlYXNlIHBvaW50IHRvIHRoZSBz cGVjaWZpYyB0ZXh0IHRoYXQgaXMgcmVsZXZhbnQgZm9yIG15IHF1ZXN0aW9uPwojI0FobWVkOiBQ YXJ0IChhKSBoZXJlIGlzIGEgc3RhdGVtZW50IG5vdCBhIHF1ZXN0aW9uLiBXaGF0IGlzIHRoZSBx dWVzdGlvbj8KCgoKCgoKCmIuICAgIEZvciB0aGUgcmVmZXJlbmNlLCBSRkMgMzAzMiBzYXlzIHRo YXQg4oCcdGhlIGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIGxheWVyIHByb3RvY29sICBtdXN0IGJl IGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2ggaXMgcG9wcGVkIGZy b20gIHRoZSBib3R0b20gb2YgdGhlIHN0YWNrLCBwb3NzaWJseSBhbG9uZyB3aXRoIHRoZSBjb250 ZW50cyAgb2YgdGhlIG5ldHdvcmsgbGF5ZXIgaGVhZGVyIGl0c2VsZuKAnQoKYy4gICAgRnJvbSBt eSBQT1YgdGhlIGZvbGxvd2luZyBzY2VuYXJpbyBpbmRpY2F0ZXMgcmVsZXZhbmNlIG9mIHRoaXMg ZXhwZWN0YXRpb24gZm9yIFNSLU1QTFM6CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGkuICAgIElTLUlTIGlzIHVzZWQgZm9yIGRpc3RyaWJ1dGluZyBib3RoIElQdjQg YW5kIElQdjYgcmVhY2hhYmlsaXR5IGluIGEgZ2l2ZW4gZG9tYWluCgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaWkuICAgIEFuIElTLUlTIGFkamFjZW5jeSBvdmVyIHNv bWUgZHVhbC1zdGFjayBsaW5rIGlzIGVzdGFibGlzaGVkLCBhbmQgYSBzaW5nbGUgQWRqLVNJRCBm b3IgdGhpcyBhZGphY2VuY3kgaXMgYWR2ZXJ0aXNlZAoKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaWlpLiAgICBUaGUgbm9kZSB0aGF0IGhhcyBhc3NpZ25lZCBhbmQgYWR2 ZXJ0aXNlZCB0aGlzIEFkai1TSUQgcmVjZWl2ZXMgYSBsYWJlbGVkIHBhY2tldCB3aXRoIHRoZSBs YWJlbCByZXByZXNlbnRpbmcgdGhpcyBBZGotU0lEIGJlaW5nIGJvdGggdGhlIHRvcCBhbmQgYm90 dG9tLW9mLXN0YWNrIGxhYmVsCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpdi4gICAgVGhlIGltcGxlbWVudGVycyBtdXN0IGJlIGdpdmVuIHVuYW1iaWd1b3VzIGluc3Ry dWN0aW9ucyBmb3IgZm9yd2FyZGluZyB0aGUgdW5sYWJlbGVkIHBhY2tldCB2aWEgdGhlIGR1YWwt c3RhY2sgbGluayBhcyBhbiBJcHY0IG9yIGFuIElQdjYgcGFja2V0LgojQWhtZWQ6IElmIHlvdSB0 YWtlIGEgbG9vayBhdCB0aGUgU1ItSVNJUyAsIFNSLU9TUEZ2MiBhbmQgU1ItT1NGdjMgZHJhZnRz LCB5b3Ugd2lsbCBzZWUgYWxsIDMgcHJvdG9jb2wgYWR2ZXJ0aXNlIGRpZmZlcmVudCBhZGotU0lE UyBmb3IgSVB2NCBuZXh0LWhvcCBhbmQgSVB2NiBuZXh0LWhvcC4gRm9yIGV4YW1wbGUsIElTSVMg dXNlcyB0aGUgIkYtRmxhZyIgKHNlY3Rpb24gMi4yLjEgaW4gZHJhZnQtaWV0Zi1pc2lzLXNlZ21l bnQtcm91dGluZy1leHRlbnNpb25zLTE4KSB0byBzcGVjaWZ5IHdoZXRoZXIgdGhlIGFkai1TSUQg aXMgZm9yIElQdjQgYW5kIElQdjYuIFNpbWlsYXJseSwgdGhlIFNSLUlTSVMgZHJhZnQgYXR0YWNo ZXMgYSBwcmVmaXgtU0lEIHRvIHRoZSBwcmVmaXggYWR2ZXJ0aXNlbWVudCBhbmQgaGVuY2UgaW1w bGllcyB0aGUgaWRlbnRpdHkgb2YgdGhlIHByb3RvY29sIHVuZGVybmVhdGggdGhlIGJvdHRvbSBt b3N0IGxhYmVsLiBGb3IgYW55IG90aGVyICJmdW5jdGlvbiIgYXR0YWNoZWQgdG8gYSBTSUQsIGl0 IGlzIHBhcnQgb2YgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhpcyBmdW5jdGlvbiB0byBkZXNjcmli ZSB3aGF0IGhhcHBlbnMgd2hlbiB0aGUgU0lEIGlzIHJlcHJlc2VudGVkIGJ5IGEgbGFiZWwgaW4g dGhlIE1QTFMgZm9yd2FyZGluZyBwbGFuZSBhbmQgdGhpcyBsYWJlbCBpcyB0aGUgYm90dG9tIG1v c3QgbGFiZWwKW1tTYXNoYV1dIE9LLCBnb3QgaXQuIFRoaXMgaXNzdWUgaXMgcmVzb2x2ZWQuCgoK CgoKNS4gICAgUmVzb2x1dGlvbiBvZiBDb25mbGljdHM6IEFyZSB0aGUKCmEuICAgIEFyZSB0aGUg Y29uZmxpY3QgcmVzb2x1dGlvbiBwcm9jZWR1cmVzIGxpc3RlZCBpbiBzZWN0aW9uIDIuNSBtYW5k YXRvcnkgdG8gaW1wbGVtZW50PwoKYi4gICAgSWYgdGhleSBhcmUgbWFuZGF0b3J5IHRvIGltcGxl bWVudCwgYXJlIHRoZXkgYWxzbyBtYW5kYXRvcnkgdG8gZGVwbG95LCBvciBjYW4gdGhlIG9wZXJh dG9ycyBzaW1wbHkgdHJlYXQgYW55IGRldGVjdGVkIGNvbmZsaWN0IGFzIHJlcXVpcmluZyBodW1h biBpbnRlcnZlbnRpb24gYW5kIHByZXZlbnRpbmcgbm9ybWFsIG9wZXJhdGlvbiBvZiBTUi1NUExT PwojQWhtZWQ6IFRoZXkgYXJlIHJlY29tbWVuZGVkLiBJIHdpbGwgbW9kaWZ5IHRoZSBwYXJhZ3Jh cGggYWZ0ZXIgdGhlIGZpcnN0IDMgYnVsbGV0cyBpbiBTZWN0aW9uIDIuNSB0byBzYXkgdGhhdCBp dCBpcyByZWNvbW1lZGVkLgoKCgpbW1Nhc2hhXV0gT0suIEhvd2V2ZXIsIGl0IHdvdWxkIGJlIG5p Y2UgaWYgeW91IGNvdWxkIHJlZmVyIHNlcGFyYXRlbHkgZm9yIOKAnFJFQ09NTUVOREVEIHRvIGlt cGxlbWVudOKAnSBhbmQg4oCcUkVDT01NRU5ERUQgdG8gZGVwbG954oCdLiAgVGhlIGxhdHRlciBw cm9iYWJseSByZXF1aXJlcyBhIGNvbmZpZ3VyYXRpb24ga25vYiBmb3IgZW5hYmxpbmcgY29uZmxp Y3QgcmVzb2x1dGlvbiBydWxlcyAoaWYgdGhleSBhcmUgaW1wbGVtZW50ZWQpLgoKYy4gICAgRm9y IHRoZSByZWZlcmVuY2UsIHRoZSBJRVRGIGNhcGl0YWxpemVkIE1VU1QgYXBwZWFycyBqdXN0IGlu IGEgZmV3IHBsYWNlcyBpbiBTZWN0aW9uIDIuNSwgYW5kIGVhY2ggYXBwZWFyYW5jZSBoYXMgdmVy eSBuYXJyb3cgY29udGV4dDoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgaS4gICAgRm9yIE1DQ3Mgd2hlcmUgdGhlICJUb3BvbG9neSIgYW5kL29yICJBbGdvcml0aG0i IGZpZWxkcyBhcmUgbm90IGRlZmluZWQsIHRoZSBudW1lcmljYWwgdmFsdWUgb2YgemVybyBNVVNU IGJlIHVzZWQgZm9yIHRoZXNlIHR3byBmaWVsZHMKCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBpaS4gICAgSWYgdGhlIHNhbWUgc2V0IG9mIEZFQ3MgYXJlIGF0dGFjaGVk IHRvIHRoZSBzYW1lIGxhYmVsICJMMSIsIHRoZW4gdGhlIHRpZS1icmVha2luZyBydWxlcyBNVVNU IGFsd2F5cyBzZWxlY3QgdGhlIHNhbWUgRkVDIGlycmVzcGVjdGl2ZSBvZiB0aGUgb3JkZXIgaW4g d2hpY2ggdGhlIEZFQ3MgYW5kIHRoZSBsYWJlbCAiTDEiIGFyZSByZWNlaXZlZC4gSW4gb3RoZXIg d29yZHMsIHRoZSB0aWUtYnJlYWtpbmcgcnVsZSBNVVNUIGJlIGRldGVybWluaXN0aWMuCgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpaWkuICAgIEFuIGltcGxlbWVudGF0 aW9uIG9mIGV4cGxpY2l0IFNJRCBhc3NpZ25tZW50IE1VU1QgZ3VhcmFudGVlIGNvbGxpc2lvbiBm cmVlbmVzcyBvbiB0aGUgc2FtZSByb3V0ZXIKRnJvbSBteSBQT1YsIGl0IGlzIG5vdCBwb3NzaWJs ZSB0byBpbmZlciB0aGUgYW5zd2VyIHRvIG15IHF1ZXN0aW9uIGZyb20gdGhlc2Ugc3RhdGVtZW50 cy4gU29tZSBleHBsaWNpdCBzdGF0ZW1lbnQgaXMgcmVxdWlyZWQuCiNBaG1lZDogSSBhZ3JlZSB3 aXRoIHlvdSBQT1YgYW5kIGFzIG1lbnRpb25lZCBpbiBteSByZXBseSB0byBpdGVtcyAoYSkgYW5k IChiKSwgSSB3aWxsIG1vZGlmeSB0aGUgcGFyYWdyYXBoIHRvIHNheSB0aGF0IGl0IGlzIFJFQ09N TUVOREVEIHRvIGFuc3dlciB5b3UgcXVlc3Rpb25zIGluIGl0ZW1zIChhKSBhbmQgKGIpCgoKCgpk LiAgICBUaGUgdGllLWJyZWFraW5nIHJ1bGVzIGluIHNlY3Rpb24gMi41LjEgaW5jbHVkZSBzb21l IHNwZWNpZmljIHZhbHVlcyBmb3IgZW5jb2RpbmcgRkVDIHR5cGVzIGFuZCBhZGRyZXNzIGZhbWls aWVzIOKAkyBidXQgdGhlc2UgdmFsdWVzIGFyZSBub3Qgc3VwcG9zZWQgdG8gYXBwZWFyIGluIGFu eSBJQU5BIHJlZ2lzdHJpZXMgKGJlY2F1c2UgdGhlIGRyYWZ0IGRvZXMgbm90IHJlcXVlc3QgYW55 IElBTkEgYWN0aW9ucykuIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkgd2hhdCBpcyBzbyBzcGVjaWFs IGFib3V0IHRoZXNlIHZhbHVlcz8KI0FobWVkOiBUaGVyZSBpcyBubyBzaWduaWZpY2FuY2UgdG8g dGhlIHZhbHVlcyBidXQgdGhlcmUgaXMgYSBzaWduaWZpY2FuY2UgdG8gdGhlIG9yZGVyIGFtb25n IHRoZW0uIEkgd2lsbCBtb2RpZnkgdGhlIHRleHQgdG8gY2xhcmlmeSB0aGF0CltbU2FzaGFdXSBP Sy4KCgoKCgplLiAgICBJIGFsc28gZG91YnQgdGhhdCBjb21wYXJpc29uIG9mIEZFQ3MgdGhhdCBy ZXByZXNlbnQgSVB2NCBhbmQgSVB2NiBwcmVmaXggU0lEcyBtYWtlcyBtdWNoIHNlbnNlIChmb3Ig Y29uZmxpY3QgcmVzb2x1dGlvbiBvciBlbHNlKSwgYmVjYXVzZSwgYW1vbmcgb3RoZXIgdGhpbmdz LCB0aGVyZSBhcmUgdmFsaWQgc2NlbmFyaW9zIHdoZW4gYW4gSVB2NCAvMzIgcHJlZml4IGlzIGVt YmVkZGVkIGluIGFuIElQdjYgLzEyOCBvbmUuCiNBaG1lZDogQSBwcmVmaXgtU0lEIGlzIGFzc2ln bmVkIHRvIGEgcHJlZml4LiBBbiBJUHY2IHByZWZpeCB0aGF0IGVtYmVkcyBhbiBJUHY0IHByZWZp eCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgSVB2NCBwcmVmaXguIFRoZSBzcGVjaWZpY2F0aW9ucyBv ZiBTUiBleHRlbnNpb25zIHRvIElTSVMsIE9TUEZ2MiwgT1NQRnYzLCBhbmQgQkdQIHRyZWF0IElQ djQgYW5kIElQdjYgcHJlZml4ZXMgc2VwYXJhdGVseSwgaW5jbHVkaW5nIHRoZSBJUFY2IHByZWZp eGVzIHdpdGggZW1iZWRkZWQgSVB2NCBvbmVzLiBCZXNpZGVzIG5vdCBhbGwgSVB2NiBwcmVmaXhl cyBlbWJlZCBJUHY0IHByZWZpeCBpbiB0aGVtLiBIZW5jZSB0aGUgZGlzdGluY3Rpb24gYmV0d2Vl biBJUHY0IGFuZCBJUHY2IHByZWZpeGVzIGlzIHF1aXRlIGNsZWFyCltbU2FzaGFdXSBNeSBjb25j ZXJuIHdhcyBtYWlubHkgYWJvdXQgSVB2NC1tYXBwZWQgSVB2NiBhZGRyZXNzZXMuIFF1b3Rpbmcg ZnJvbSBSRkMgNDI5MToKMi41LjUuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI5 MSNzZWN0aW9uLTIuNS41LjI+LiAgSVB2NC1NYXBwZWQgSVB2NiBBZGRyZXNzCgoKICAgQSBzZWNv bmQgdHlwZSBvZiBJUHY2IGFkZHJlc3MgdGhhdCBob2xkcyBhbiBlbWJlZGRlZCBJUHY0IGFkZHJl c3MgaXMKICAgZGVmaW5lZC4gIFRoaXMgYWRkcmVzcyB0eXBlIGlzIHVzZWQgdG8gcmVwcmVzZW50 IHRoZSBhZGRyZXNzZXMgb2YKICAgSVB2NCBub2RlcyBhcyBJUHY2IGFkZHJlc3Nlcy4KCkZyb20g bXkgUE9WIHRoaXMgbWVhbnMgdGhhdCBhIC8xMjggcHJlZml4IGFzc29jaWF0ZWQgd2l0aCBhbiBJ UHY0LW1hcHBlZCBJUHY2IGFkZHJlc3MgYW5kIGEgLzMyIHByZWZpeCBhc3NvY2lhdGVkIHdpdGgg dGhlIElQdjQgYWRkcmVzcyB0aGF0IHdhcyBtYXBwZWQgdG8gdGhpcyBJUHY2IGFkZHJlc3MgcmVw cmVzZW50IHRoZSBzYW1lIGVudGl0eS4gVGhpcyB1bmRlcnN0YW5kaW5nIGZ1bGx5IG1hdGNoZXMg dXNhZ2Ugb2YgSVB2NC1tYXBwZWQgSVB2NiBhZGRyZXNzZXMgYXMgQkdQIE5leHQgSG9wcyBvZiBW UE4tSVB2NiBhZGRyZXNzZXMgZGVmaW5lZCBpbiBSRkMgNDc5OC4gSG93ZXZlciwgdGhlIGNvbXBh cmlzb24gcnVsZXMgeW91IGhhdmUgZGVmaW5lZCB3aWxsIHRyZWF0IHRoZW0gYXMgdHdvIGRpZmZl cmVudCBwcmVmaXhlcy4gIEkgd29uZGVyIGlmIHRoZXNlIHJ1bGVzLCBpbiB0aGUgY2FzZSBvZiBh IGNvbmZsaWN0LCBjb3VsZCByZXN1bHQgaW4gcHJlZmVycmluZyB0aGUgSVB2NiBwcmVmaXggdG8g YW4gSVB2NCBvbmUgYW5kIHRoZXJlZm9yZSBsb29zaW5nIE1QTFMgY29ubmVjdGl2aXR5IGZvciB0 aGUgaW5ncmVzcyBQRSBvZiBhIDZWUEUgc2VydmljZSB0byBpdHMgZWdyZXNzIFBFPwojI0FobWVk OiBUaGUgYmFzaWMgTVBMUyBhcmNoaXRlY3R1cmUgZG9lcyBub3QgZm9yYmlkIGFzc2lnbmluZyBk aWZmZXJlbnQgbGFiZWxzIHRvIHRoZSBzYW1lIHByZWZpeCwgbm9uZXRoZWxlc3MgdG8gZGlmZmVy ZW50IHByZWZpeGVzIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBub2RlIG9yIHRoZSBzYW1lIGludGVy ZmFjZSBvbiB0aGUgc2FtZSBub2RlLiBPbmUgb2YgdGhlIGZ1bmRhbWVudGFsIGNvbmNlcHRzIG9m IFNSLU1QTFMgaXMgdGhhdCB0aGUgc2FtZSBwcmVmaXgtU0lEIG11c3Qgbm90IGJlIGFzc2lnbmVk IHRvIHR3byBkaWZmZXJlbnQgcHJlZml4ZXMuIFNvIGZvciB0aGUgcGFydGljdWxhciBzY2VuYXJp byBvZiBlbWJlZGRpbmcgSVB2NCBpbiBJUHY2LCB0aGUgb3BlcmF0b3IgbXVzdCBhc3NpZ24gZGlm ZmVyZW50IFNJRHMgdG8gdGhlIElQdjQgYWRkcmVzcyBhbmQgdGhlIElQdjQtbWFwcGVkIElQdjYg YWRkcmVzcyB0aGF0IGVtYmVkcyBpdCwgb3RoZXJ3aXNlIHRoZSBsYWJlbCB3aWxsIGJlIHN1Ympl Y3QgdG8gdGhlIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbiByZXNvbHV0aW9uCgoKCgoKCgoKZi4g ICAgIFNlY3Rpb24gMi41LjEgZGVmaW5lcyAzIHR5cGVzIG9mIFNSLU1QTFMgRkVDcywgYnV0IEkg YW0gbm90IHN1cmUgYWxsIFNJRCB0eXBlcyBkZWZpbmVkIGluIHRoZSBTZWdtZW50IFJvdXRpbmcg QXJjaGl0ZWN0dXJlIGRyYWZ0IGNhbiBiZSB1bmFtYmlndW91c2x5IG1hcHBlZCB0byBvbmUgb2Yg dGhlc2UgdHlwZXMuIFByb2JsZW1hdGljIGV4YW1wbGVzIGluY2x1ZGUgYXQgbGVhc3QgdGhlIGZv bGxvd2luZzoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAg UGFyYWxsZWwgQWRqYWNlbmN5IFNJRAoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGlpLiAgICBNaXJyb3IgU0lECkV4cGxpY2l0IG1hcHBpbmcgb2YgU0lEIHR5cGVzIHRv IFNSLU1QTFMgRkVDIHR5cGVzIHdvdWxkIGJlIG1vc3QgdXNlZnVsIElNTy4gSWYgc29tZSBTSUQg dHlwZXMgY2Fubm90IGJlIG1hcHBlZCB0byBTUi1NUExTIEZFQ3MsIHRoaXMgbXVzdCBiZSBleHBs aWNpdGx5IHN0YXRlZCBpbiB0aGUgZHJhZnQuCiNBaG1lZDoKUGFyYWxsZWwgYWRqYWNlbmN5IFNJ RCBhcmUgaGFuZGxlZCBpbiB0aGUgdHlwZSAiKG5leHQtaG9wLCBvdXRnb2luZyBpbnRlcmZhY2Up IgpbW1Nhc2hhXV0gT0sKCk1pcnJvciBTSUQgaXMgYSB0eXBlIG9mIGJpbmRpbmctU0lEIGFzIG1l bnRpb25lZCBpbiBTZWN0aW9uIDUuMSBpbiB0aGUgU1IgYXJjaGl0ZWN0dXJlIGRyYWZ0IChkcmFm dC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMTUpLiBBbHNvIGFzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDIuNCBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMtMTgg KGFsc28gc2VlIHRoZSBlcXVpdmFsZW50IGluIHRoZSBPU1BGdjIgYW5kIE9TUEZ2MyBkcmFmdCks IGEgYmluZGluZyBTSUQgaXMgaWRlbnRpZmllZCBieSBhIHByZWZpeC4gSGVuY2UgaXQgaXMgY292 ZXJlZCBieSB0aGUgdHlwZSAiKFByZWZpeCwgUm91dGluZyBJbnN0YW5jZSwgVG9wb2xvZ3ksIEFs Z29yaXRobSkiCltbU2FzaGFdXSBJIHJlc3BlY3RmdWxseSBkaXNhZ3JlZS4gVGhlcmUgaXMgZGVm aW5pdGVseSBubyBtZW50aW9uIG9mIEFsZ29yaXRobSBpbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUg TWlycm9yIFNJRC4KIyNBaG1lZDoKVGhlIGxhc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24gMiBvZiBk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMTQgc2F5cwoKICAgV2UgY2FsbCAiTVBM UyBDb250cm9sIFBsYW5lIENsaWVudCAoTUNDKSIgYW55IGNvbnRyb2wgcGxhbmUgZW50aXR5Cgog ICBpbnN0YWxsaW5nIGZvcndhcmRpbmcgZW50cmllcyBpbiB0aGUgTVBMUyBkYXRhIHBsYW5lLgpU aGUgc2VudGVuY2Ugc3RhcnRpbmcgYXQgdGhlIDV0aCBsaW5lIG9mIHRoZSBmaXJzdCBidWxsZXQg b2YgU2VjdGlvbiAyLjUgb2YgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTE0IHNh eXMKCkZvciBNQ0NzIHdoZXJlIHRoZSAiVG9wb2xvZ3kiIGFuZC9vciAiQWxnb3JpdGhtIgoKICAg ICAgZmllbGRzIGFyZSBub3QgZGVmaW5lZCwgdGhlIG51bWVyaWNhbCB2YWx1ZSBvZiB6ZXJvIE1V U1QgYmUgdXNlZAoKICAgICAgZm9yIHRoZXNlIHR3byBmaWVsZHMuCklmIGEgYmluZGluZy1TSUQg aXMgZG93bmxvYWRlZCB0byB0aGUgZm9yd2FyZGluZyBwbGFuZSwgdGhlbiBpdCBtdXN0IGJlIGFz c29jaWF0ZWQgd2l0aCBhbiBNQ0MgYW5kIGhlbmNlIGl0IGVpdGhlciBoYXMgYW4gImFsZ29yaXRo bSIgb3IgdGhlIHZhbHVlIHplcm8gaXMgYXNzdW1lZCBmb3IgdGhlICJhbGdvcml0aG0iIGZpZWxk LiBJZiB0aGUgYmluZGluZy1TSUQgaXMgbm90IGRvd25sb2FkZWQgdG8gdGhlIGZvcndhcmRpbmcg cGxhbmUsIHRoZW4gaXQgaXMgaXJyZWxldmFudCB0byB0aGUgZW50aXJlIGRyYWZ0IG5vdCBvbmx5 IHRvIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbgoKCgoKCgo2LiAgICBOb2RlIFNJRHMgaW4gU1It TVBMUzoKCmEuICAgIE5vZGUgU0lEcyBhcmUgZXhwbGljaXRseSBkZWZpbmVkIGFuZCBkaXNjdXNz ZWQgaW4gdGhlIFNlZ21lbnQgUm91dGluZyBBcmNoaXRlY3R1cmUgZHJhZnQgYnV0IGFyZSBub3Qg bWVudGlvbmVkIGV2ZW4gb25jZSBpbiB0aGlzIGRyYWZ0CgpiLiAgICBBRkFJSywgdGhlIGNvbW1v biBpbXBsZW1lbnRhdGlvbiBwcmFjdGljZSB0b2RheSBpbmNsdWRlcyBhc3NpZ25tZW50IG9mIGF0 IGxlYXN0IG9uZSBOb2RlIFNJRCB0byBldmVyeSBub2RlIGluIHRoZSBTUi1NUExTIGRvbWFpbgoK Yy4gICAgSXMgdGhlcmUgYSByZXF1aXJlbWVudCB0byBhc3NpZ24gYXQgbGVhc3Qgb25lIE5vZGUg U0lEIHBlciB7cm91dGluZyBpbnN0YW5jZSwgdG9wb2xvZ3ksIGFsZ29yaXRobX0gaW4gU1ItTVBM Uz8gSWYgbm90LCBjYW4gdGhlIGF1dGhvcnMgZXhwbGFpbiBleHBlY3RlZCBiZWhhdmlvciBvZiBz dWNoIGEgbm9kZT8gKFNlZSBhbHNvIG15IGNvbW1lbnQgYWJvdXQgcm91dGluZyBpbnN0YW5jZXMg YmVsb3cpLgojQWhtZWQ6IEEgTm9kZS1TSUQgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgcHJlZml4LVNJ RC4gU28gdGhlcmUgbm90aGluZyBzcGVjaWZpYyBhYm91dCBpdCBmcm9tIHRoZSBNUExTIGZvcndh cmRpbmcgcGxhbmUgcG9pbnQgb2Ygdmlldy4gU2ltaWxhcmx5IGZyb20gYSBzdGFuZGFyZCB0cmFj a3MgZHJhZnQgcG9pbnQgb2YgdmlldywgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdG8gYXNzaWdu IGEgU0lEIHRvIGV2ZXJ5IHByZWZpeCBqdXN0IGxpa2UgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQg dG8gYmluZCBldmVyeSBwcmVmaXggdG8gYW4gTERQIGxhYmVsLiBDb21tb24gYW5kL29yIHJlY29t bWVuZGVkIHByYWN0aWNlcyBvciBkZXNjcmlwdGlvbiBvZiBkZXBsb3ltZW50IHNjZW5hcmlvcyBh cmUgbW9yZSBiZWZpdHRpbmcgdG8gQkNQIG9yIGluZm9ybWF0aW9uYWwgZHJhZnRzLiBUaGlzIGRy YWZ0IGlzIGEgc3RhbmRhcmRzIHRyYWNrIGRyYWZ0CltbU2FzaGFdXSBXZWxsLCB5b3XigJl2ZSBq dXN0IHNhaWQgdGhhdCBjb25mbGljdCByZXNvbHV0aW9uIHJ1bGVzIGFyZSBSRUNPTU1FTkRFRCwg YW5kIHRoaXMgaXMgcXVpdGUgY29tbW9uIGluIHRoZSBTdGFuZGFyZHMgVHJhY2sgUkZDcy4KIyNB aG1lZDogT0suLCBJIHRoaW5rIHdlIGFyZSBpbiBhZ3JlZW1lbnQgaGVyZTopCgoKCklmIGEge3Jv dXRpbmcgaW5zdGFuY2UsIHRvcG9sb2d5LCBhbGdvcml0aG19IGlzIG5vdCBhc3NpZ25lZCBhIFNJ RCwgdGhlbiB0aGlzIEZFQyBpcyB0b3RhbGx5IGlycmVsYXZhbnQgdG8gdGhpcyBkcmFmdCBhbmQg aGVuY2UgZGVzY3JpYmluZyBob3cgYSBub2RlIHRyZWF0cyBpdCBpcyB0b3RhbGx5IG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQKW1tTYXNoYV1dIEFGQUlLLCBuZWl0aGVyIG9mIHRoZSBT UiBleHRlbnNpb24gZHJhZnRzIGZvciBJR1BzIG1lbnRpb24gcm91dGluZyBpbnN0YW5jZXMgdGhh dCBjYW4gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBwcmVmaXgsIHNvIEkgdGhpbmsgdGhhdCB5b3Vy IHJlZmVyZW5jZSB0byBpdCBpcyBpbmNvcnJlY3QuCldoYXTigJlzIG1vcmUgSSBzdXNwZWN0IHRo YXQgTm9kZSBTSURzIHJlcHJlc2VudCB0aGUgbW9zdCB1c2VkIHNwZWNpYWwgY2FzZSBvZiBQcmVm aXggU0lEcyB3aXRoIEFueWNhc3QgU0lEcyBiZWluZyBxdWl0ZSBiZWhpbmQuICBUaGVyZWZvcmUg c29tZSByZWNvbW1lbmRhdGlvbiBwZXJ0YWluaW5nIHRvIHRoZSB1c2FnZSBvZiBOb2RlIFNJRHMg d291bGQgYmUgdmVyeSBtdWNoIGluIHBsYWNlIElNSE8uCiMjQWhtZWQ6IFRoZSAgdGVybSAicm91 dGluZyBpbnN0YW5jZSIgd2l0aGluIHRoZSBjb250ZXh0IG9mIGluY29taW5nIGxhYmVsIGNvbGxp c2lvbiBpcyBkZWZpbmVkIGluIHRoZSBmaXJzdCBidWxsZXQgaW4gU2VjdGlvbiAyLjUuCkFzIGZv ciBhbnkgcmVjb21tZW5kYXRpb24gZm9yIHVzZWFnZSBvZiBub2RlLVNJRCwgYW55Y2FzdC1TSUQs Li4uLGV0YyAsIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdCBiZWNhdXNlIGl0 IGlzIGEgbWF0dGVyIG9mIG9mIGRlcGxveW1lbnQvaW5mb3JtYXRpb25hbC9CQ1AgZHJhZnQKCgoK CgoKCjcuICAgIFNSR0IgU2l6ZSBpbiBTUi1NUExTOgoKYS4gICAgVGhlIGRyYWZ0IGNvcnJlY3Rs eSB0cmVhdHMgdGhlIHNpdHVhdGlvbiB3aGVuIGFuIGluZGV4IGFzc2lnbmVkIHRvIHNvbWUgZ2xv YmFsIFNJRCBjYW5ub3QgYmUgbWFwcGVkIHRvIGEgbGFiZWwgdXNpbmcgdGhlIHByb2NlZHVyZSBp biBTZWN0aW9uIDIuNCBhcyBhIGNvbmZsaWN0LgoKYi4gICAgQXQgdGhlIHNhbWUgdGltZSB0aGUg ZHJhZnQgZG9lcyBub3QgZGVmaW5lIGFueSBtaW5pbXVtIHNpemUgb2YgU1JHQiAoYmUgaXQgZGVm aW5lZCBhcyBhIHNpbmdsZSBjb250aWd1b3VzIGJsb2NrIG9yIGFzIGEgc2VxdWVuY2Ugb2Ygc3Vj aCBibG9ja3MpIHRoYXQgTVVTVCBiZSBpbXBsZW1lbnRlZCBieSBhbGwgU1ItY2FwYWJsZSBub2Rl cwoKYy4gICAgSSBzdXNwZWN0IHRoYXQgbGFjayBvZiBzdWNoIGEgZGVmaW5pdGlvbiBjb3VsZCBi ZSBkZXRyaW1lbnRhbCB0byBpbnRlcm9wZXJhYmlsaXR5IG9mIFNSLU1QTFMgc29sdXRpb25zLiBB RkFJSywgdGhlIElFVEYgaGFzIGJlZW4gZm9sbG93aW5nLCBmb3IgcXVpdGUgc29tZSB0aW1lLCBh IHBvbGljeSB0aGF0IHNvbWUgcmVhc29uYWJsZSBNVVNULXRvLWltcGxlbWVudCBkZWZhdWx0cyBz aG91bGQgYmUgYXNzaWduZWQgZm9yIGFsbCBjb25maWd1cmFibGUgcGFyYW1ldGVycyBleGFjdGx5 IGluIG9yZGVyIHRvIHByZXZlbnQgdGhpcy4KI0FobWVkOiBUaGlzIGRvY3VtZW50IHNwZWNpZmll cyBob3cgdGhlIFNSR0IgaXMgdXNlZCBhbmQgdGhlIGJlaGF2aW9yIG9mIHJvdXRlcnMgd2hlbiBh IHByZWZpeC1TSUQgaW5kZXggbWFwcyB0byBhIGxhYmVsIGluc2lkZSBhbmQvb3Igb3V0c2lkZSB0 aGUgU1JHQi4gVGhlIGFjdHVhbCBzaXplIG9mIHRoZSBTUkdCIGlzIGEgdGFzayBpbiBwYXJ0aXRp b25pbmcgdGhlIGxhYmVsIHNwYWNlLCB3aGljaCBpcyB2ZXJ5IHNwZWNpZmljIHRvIGEgcGFydGlj dWxhciBkZXBsb3ltZW50IHNjZW5hcmlvLiBTbyBJTU8gaXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUg b2YgYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQuIE5vdyB0aGF0IFNSLU1QTFMgaXMgZGVwbG95 ZWQgaW4gbWFueSBwbGFjZXMsIEkgZXhwZWN0IHRoZSBjb21tdW5pdHkgdG8gZ2FpbiBzdWZmaWNp ZW50IGV4cGVyaWVuY2UgdG8gcmVjb21tZW5kIChvciBub3QgcmVjb21tZW5kKSBhIHBhcnRpY3Vs YXIgbWluaW11bS9tYXhpbXVtIHNpemUgZm9yIHRoZSBTUkdCIGlzIHNvbWUgZnV0dXJlIGluZm9y bWF0aW9uYWwgb3IgQkNQIGRyYWZ0L1JGQwpbW1Nhc2hhXV0gTXkgcmVhZGluZyBvZiB5b3VyIHJl c3BvbnNlIGlzIHRoYXQgbWluaW11bSBzaXplIG9mIFNSR0IgaXMgYW4gaXNzdWUgZm9yIGZ1dHVy ZSBzdHVkeS4gQ2FuIHlvdSBwbGVhc2UganVzdCBhZGQgdGhpcyB0byB0aGUgZHJhZnQ/CiMjQWht ZWQ6IE9LLiBBZGRlZCBhIHNlbnRlbmNlIHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9u IDIuMwoKCgoKCgoKOC4gICAgQWxnb3JpdGhtcyBhbmQgUHJlZml4IFNJRHM6CgphLiAgICBUaGUg ZHJhZnQgbWVudGlvbnMgQWxnb3JpdGhtcyAoYXMgcGFydCBvZiBTUi1NUExTIFByZWZpeCBGRUMp IGluLCBidXQgaXQgZG9lcyBub3QgZXhwbGljaXRseSBsaW5rIHRoZW0gd2l0aCB0aGUgUHJlZml4 LVNJRCBhbGdvcml0aG1zIGRlZmluZWQgaW4gc2VjdGlvbiAzLjEuMSBvZiB0aGUgU2VnbWVudCBS b3V0aW5nIEFyY2hpdGVjdHVyZSBkcmFmdAojQWhtZWQ6IEkgd2lsbCBqdXN0IGFkZCB0aGUgcmVm ZXJlbmNlIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nXSByaWdodCBiZXNpZGUgdGhl IGZpcnN0IHRpbWUgIkFsZ29yaXRobSIgaXMgbWVudGlvbmVkCltbU2FzaGFdXSBPSwoKCgoKCmIu ICAgIEZyb20gbXkgUE9WLCB0aGUgZHJhZnQgc2hvdWxkIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCB0 aGUgZGVmYXVsdCBQcmVmaXgtU0lEIGFsZ29yaXRobSBNVVNUIGJlIGltcGxlbWVudGVkIGluIGFs bCBTUi1NUExTLWNvbXBsaWFudCByb3V0ZXJzLgojQWhtZWQ6IFRoZSBzcGVjaWZpY2F0aW9uIG9m IHdoYXQgcGF0aCBjYWxjdWxhdGlvbiBtZXRob2Qgc2hvdWxkIG9yIG11c3QgYmUgc3VwcG9ydGVk IGlzIGEgcm91dGluZyBwcm90b2NvbCBwcm9wZXJ0eSBub3QgYSBmb3J3YXJkaW5nIHBsYW5lIHBy b3BlcnR5LiBJbiBmYWN0LCB0aGUgY2hvaWNlIG9mIGEgcGF0aCBjYWxjdWxhdGlvbiBtZXRob2Qg b3IgYWxnb3JpdGhtIGlzIGNvbXBsZXRlbHkgb3J0aG9nb25hbCB0byB0aGUgcm91dGVkIHByb3Rv Y29sLiBIZW5jZSBtYW5kYXRpbmcgdGhlIHN1cHBvcnQgb2YgYSBwYXJ0aWN1bGFyIHJvdXRpbmcg YWxnb3JpdGhtIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KW1tTYXNoYV1d IE9LCgoKCgoKYy4gICAgVGhlIFNlZ21lbnQgUm91dGluZyBBcmNoaXRlY3R1cmUgZHJhZnQgc3Rh dGVzIChpbiBzZWN0aW9uIDMuMS4zKSB0aGF0IOKAnFN1cHBvcnQgb2YgbXVsdGlwbGUgYWxnb3Jp dGhtcyBhcHBsaWVzIHRvIFNSdjbigJ0uIEJ1dCBuZWl0aGVyIGRyYWZ0IHN0YXRlcyB3aGV0aGVy IG11bHRpcGxlIGFsZ29yaXRobXMgYXBwbHkgdG8gU1ItTVBMUy4gQ2FuIHlvdSBwbGVhc2UgY2xh cmlmeSB0aGlzIHBvaW50PwojQWhtZWQ6IFRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDMu MS4yIHRpdGxlZCBTUi1NUExTIGluIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy0x NSBkaXNjdXNzZXMgdGhlIHN1cHBvcnQgb2YgbXVsdGlwbGUgYWxnb3JpdGhtcy4gU28gaXQgaXMg aW1wbGllZCB0aGF0IHRoZSBjb25jZXB0IG9mIGFsZ29yaXRobSBhcHBsaWVzIHRvIFNSLU1QTFMu IEhlbmNlIHRoZXJlIGlzIG5vIG5lZWQgdG8gcmUtbWVudGlvbiBpdCBoZXJlCltbU2FzaGFdXSBU aGUgcGFyYWdyYXBoIHRvIHdoaWNoIHlvdSByZWZlciBvbmx5IHNheXMgdGhhdCBpZiBhIHBhY2tl dCB3aXRoIHRoZSBhY3RpdmUgUHJlZml4LVNJRCB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCBhIHNw ZWNpZmljIGFsZ29yaXRobSBpcyByZWNlaXZlZCBieSBhIG5vZGUgdGhhdCBkb2VzIG5vdCBzdXBw b3J0IHRoaXMgYWxnb3JpdGhtLCB0aGlzIHBhY2tldCB3aWxsIGJlIGRpc2NhcmRlZC4gSWYgdGhp cyBpcyB0aGUgb25seSB0eXBlIG9mIHN1cHBvcnQgZm9yIG11bHRpcGxlIGFsZ29yaXRobXMgU1Ig cHJvdmlkZXMsIGl0IGlzIG5vdCB2ZXJ5IHVzZWZ1bCBJTUhPLgojI0FobWVkOiBUaGUgU1ItTVBM UyBkcmFmdCB0aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgZG9lcyBub3QgYXR0ZW1wdCB0byBt b2RpZnkgdGhlIFNSLWFyY2hpdGVjdHVyZSBkcmFmdC4gQW55IGNvbmNlcm5zIHJlbGF0ZWQgdG8g dGhlIFNSLWFyY2hpdGVjdHVyZSBzaG91bGQgYmUgYWRkcmVzc2VkIHRvIHRoZSBTUi1hcmNoaXRl Y3R1cmUgZHJhZnQgbm90IHRvIHRoaXMgZHJhZnQuCgoKCgoKOS4gICAgUm91dGluZyBpbnN0YW5j ZXMgYW5kIHRoZSBjb250ZXh0IGZvciBQcmVmaXgtU0lEczoKCmEuICAgIFRoZSBTZWdtZW50IFJv dXRpbmcgQXJjaGl0ZWN0dXJlIGRyYWZ0IHN0YXRlcyBpbiBTZWN0aW9uIDMuMSB0aGF0IHRoZSDi gJxjb250ZXh0IGZvciBhbiBJR1AtUHJlZml4IHNlZ21lbnQgaW5jbHVkZXMgdGhlIHByZWZpeCwg dG9wb2xvZ3ksIGFuZCBhbGdvcml0aG3igJ0KCmIuICAgIFRoaXMgZHJhZnQgc2VlbXMgdG8gZGVm aW5lIChpbiBzZWN0aW9uIDIuNSkgdGhlIGNvbnRleHQgZm9yIHRoZSBQcmVmaXggU0lEIGFzIOKA nFByZWZpeCwgUm91dGluZyBJbnN0YW5jZSwgVG9wb2xvZ3ksIEFsZ29yaXRobeKAnSB3aGVyZSDi gJ1hIHJvdXRpbmcgaW5zdGFuY2UgaXMgaWRlbnRpZmllZCBieSBhIHNpbmdsZSBpbmNvbWluZyBs YWJlbCBkb3dubG9hZGVyIHRvIEZJQuKAnSAoYnV0IHRoZSBub3Rpb24gb2YgdGhlIGxhYmVsIGRv d25sb2FkZXIgdG8gRklCIGlzIG5vdCBkZWZpbmVkKS4KCmMuICAgIFRoZXNlIHR3byBkZWZpbml0 aW9ucyBsb29rIGRpZmZlcmVudCB0byBtZS4KCmQuICAgIEF0IHRoZSB2ZXJ5IGxlYXN0IEkgd291 bGQgZXhwZWN0IGFsaWdubWVudCBiZXR3ZWVuIHRoZSBkZWZpbml0aW9ucyBvZiBjb250ZXh0IGZv ciB0aGUgUHJlZml4LVNJRCBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzLiBQcmVmZXJhYmx5LCB0aGUg ZGVmaW5pdGlvbiBnaXZlbiBpbiB0aGUgU2VnbWVudCBSb3V0aW5nIEFyY2hpdGVjdHVyZSBkcmFm dCBzaG91bGQgYmUgdXNlZCBpbiBib3RoIGRyYWZ0cy4KI0FobWVkOiBUaGUgY29udGV4dCBvZiB0 aGUgc2VjdGlvbiAyLjUgaXMgbGltaXRlZCB0byB0aGUgcmVzb2x1dGlvbiBvZiBsb2NhbCBsYWJl bCBjb2xsaXNpb24uIFRoZSB1c2Ugb2YgInJvdXRpbmcgaW5zdGFuY2UiIGluIHNlY3Rpb24gMi41 IGlzIGp1c3QgdGhlcmUgZm9yIHRpZS1icmVha2luZyBpZiB0aGVyZSBpcyBsb2NhbCBsYWJlbCBj b2xsaXNpb24uCltbU2FzaGFdXSBJIGhhdmUgYWxyZWFkeSBtZW50aW9uZWQgdGhhdCDigJxyb3V0 aW5nIGluc3RhbmNlc+KAnSBhcmUgbm90IGRlZmluZWQgaW4gYW55IHRoZSBkcmFmdHMgZGVhbGlu ZyB3aXRoIFNSIEV4dGVuc2lvbnMgZm9yIElHUHMuIFNvIEkgZG8gbm90IHVuZGVyc3RhbmQgaG93 IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIHByb2NlZHVyZSBpcyBzdXBwb3NlZCB0byB1c2UgdGhp cy4gQW5kIGluIGFueSBjYXNlIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdHdvIGRlZmluaXRpb25z IG9mIHRoZSBjb250ZXh0IG9mIFByZWZpeC1TSUQgcmVxdWlyZXMgc29tZSBleHBsYW5hdGlvbi4K IyNBaG1lZDogaW5jb21pbmcgbGFiZWwgY29sbGlzaW9uIGRlZmluZXMgd2hhdCBpcyBhIHJvdXRp bmcgaW5zdGFuY2Ugd2l0aGluIGl0cyBjb250ZXh0LiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQg ZXhwbGFuYXRpb24geW91IGFyZSBsb29raW5nIGZvcgoKCgoKCgoKCjEwLiBFeGFtcGxlIG9mIFBV U0ggb3BlcmF0aW9uIGluIFNlY3Rpb24gMi4xMC4xOgoKYS4gICAgVGhlIGZpcnN0IHBhcmEgb2Yg dGhpcyBzZWN0aW9uIGJlZ2lucyB3aXRoIHRoZSBzZW50ZW5jZSDigJxTdXBwb3NlIGFuIE1DQyBv biBhIHJvdXRlciAiUjAiIGRldGVybWluZXMgdGhhdCBQVVNIIG9yIENPTlRJTlVFICAgb3BlcmF0 aW9uIGlzIHRvIGJlIGFwcGxpZWQgdG8gYW4gaW5jb21pbmcgcGFja2V0IHdob3NlIGFjdGl2ZSBT SUQgaXMgdGhlIGdsb2JhbCBTSUQgIlNpIuKAnS4gSW4gdGhlIGNvbnRleHQgb2YgU1ItTVBMUyB0 aGlzIG1lYW5zICh0byBtZSkgdGhhdCB0aGUgaW5jb21pbmcgcGFja2V0IGlzIGEgbGFiZWxlZCBw YWNrZXQgYW5kIGl0cyB0b3AgbGFiZWwgbWF0Y2hlcyB0aGUgZ2xvYmFsIFNJRCDigJxTaeKAnS4K CmIuICAgIEhvd2V2ZXIsIHRoZSBleGFtcGxlIGZvciBQVVNIIG9wZXJhdGlvbiBpbiB0aGUgbmV4 dCBwYXJhIG9mIHRoaXMgc2VjdGlvbiBpcyB0aGUgY2FzZSBvZiBhbiAodW5sYWJlbGVkKSBJUCBw YWNrZXQgd2l0aCB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBjb3ZlcmVkIGJ5IHRoZSBJUCBwcmVm aXggZm9yIHdoaWNoIOKAnFNp4oCdIGhhcyBiZWVuIGFzc2lnbmVkLgoKYy4gICAgRnJvbSBteSBQ T1Y6CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGkuICAgIE1hcHBp bmcgdW5sYWJlbGVkIHBhY2tldHMgdG8gU0lEcyBpcyBpbmRlZWQgb3V0IG9mIHNjb3BlIG9mIHRo ZSBkcmFmdC4gVGhlcmVmb3JlIGFuIGV4YW1wbGUgb2YgYSBQVVNIIG9wZXJhdGlvbiB0aGF0IGlz IGFwcGxpZWQgdG8gYSBsYWJlbGVkIHBhY2tldCAod2l0aCB0aGUgYWN0aXZlIFNJRCBpbmZlcnJl ZCBmcm9tIHRoZSB0b3AgbGFiZWwgaW4gdGhlIHN0YWNrKSBpcyBwcmVmZXJhYmxlLgoKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlpLiAgICBWYWxpZCBleGFtcGxlcyBv ZiAgUFVTSCBvcGVyYXRpb24gYXBwbGllZCB0byBhIGxhYmVsZWQgaW5jb21pbmcgcGFja2V0IGNh biBiZSBmb3VuZCBpbiBTZWN0aW9ucyA0LjIgb3IgNC4zIG9mIHRoZSBUSS1MRkE8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhc2hhbmR5LXJ0Z3dnLXNlZ21lbnQtcm91dGluZy10 aS1sZmEtMDQ+IGRyYWZ0CgojQWhtZWQ6IEkgZG8gbm90IHVuZGVyc3RhbmQgeW91ciBjb25jZXJu IGhlcmU6KQoKCgpbW1Nhc2hhXV0gSSB0aGluayBpdCBpcyBwcmV0dHkgY2xlYXI6IGNhbiB5b3Ug cHJvdmlkZSBhbiBleGFtcGxlIG9mIGEgUFVTSCBvcGVyYXRpb24gYXBwbGllZCB0byBhIGxhYmVs ZWQgcGFja2V0IGluc3RlYWQgb2YgeW91ciBjdXJyZW50IGV4YW1wbGU/CiMjQWhtZWQ6IFRoZSBl eGFtcGxlIGluIHRoZSBkcmFmdCBpcyBpbmNsdWRlZCB0byBjbGFyaWZ5IHRoZSBjb25jZXB0IG9m IGEgcHJlZml4IFNJRCBhdHRhY2hlZCB0byBhIHByZWZpeC4gQXMgbWVudGlvbmVkIG1vcmUgdGhh biBvbmNlLCBTUi1NUExTIGRvZXMgbm90IG1vZGlmeSBNUExTIGZvcndhcmRpbmcgaW5jbHVkaW5n IHB1c2hpbmcgYSBsYWJlbCBvbiBhIGxhYmVsZWQgcGFja2V0LiBJdCBpcyBzb21ldGhpbmcgdGhh dCBoYXMgYmVlbiBkb25lIGJ5IHJvdXRlcnMgYW5kIHN3aXRjaGVzIGZvciAyMCsgeWVhcnMuIFNv IGluY2x1ZGluZyBpdCBoZXJlIGlzIHJlZHVuZGFudAoKCk5pdHM6CgoxLiAgICBJIGNvbmN1ciB3 aXRoIEFkcmlhbiByZWdhcmRpbmcgbnVtZXJvdXMgbml0cyBoZSBoYXMgcmVwb3J0ZWQgaW4gaGlz IFdHIExDIENvbW1lbnQ8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJp bmcvRlJoTzJsZ1I4cjRWbEtQMlpOMmRad0hVNUJZPi4gSSB3b3VsZCBsaWtlIHRvIHRoYW5rIEFk cmlhbiBmb3IgYW4gZXhjZWxsZW50IHJldmlldyB0aGF0IGhhdmUgc2F2ZWQgbWUgbG90cyBvZiBo YXJkIHdvcmsuCiNBaG1lZDogSSBhbHNvIGFncmVlIHRoYXQgQWRyaWFuJ3MgcmV2aWV3IGlzIGV4 Y2VwdGlvbmFsLiBJIGJlbGlldmUgSSBhZGRyZXNzZWQgYWxsIGhpcyBjb21tZW50cyBpbiB0aGUg bGF0ZXN0IHZlcnNpb24uCgoKCgoyLiAgICBJbiBhZGRpdGlvbiwgSeKAmWQgbGlrZSB0byByZXBv cnQgdGhlIGZvbGxvd2luZyBuaXRzOgoKYS4gICAgVGktTEZBIGluIFNlY3Rpb24gMi4xMS4xIHNo b3VsZCBiZSBUSS1MRkEgKGFzIGluIHRoZSBUSS1MRkE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJhc2hhbmR5LXJ0Z3dnLXNlZ21lbnQtcm91dGluZy10aS1sZmEtMDQ+IGRyYWZ0 KQojQWhtZWQ6IEFscmVhZHkgZG9uZSBpbiB0aGUgbGF0ZXN0IHZlcnNpb25bW1Nhc2hhXV0gT0sK CgoKCmIuICAgIFRJLUxGQSBkcmFmdCBpcyByZWZlcmVuY2VkIGluIHRoZSB0ZXh0IG9mIFNlY3Rp b24gMi4xMS4xLCBidXQgdGhlcmUgaXMgbm8gbWF0Y2hpbmcgcmVmZXJlbmNlIGluIHRoZSDigJxS ZWZlcmVuY2Vz4oCdIHNlY3Rpb24gKHByb2JhYmx5LCBJbmZvcm1hdGlvbmFsKQojQWhtZWQ6IEFs cmVhZHkgZG9uZSBpbiB0aGUgbGF0ZXN0IHZlcnNpb25bW1Nhc2hhXV0gT0sKCgoKCmMuICAgIOKA nHplcm8gQWxnb3JpdGht4oCdIGluIFNlY3Rpb24gMi41IChpbW1lZGlhdGVseSBhYm92ZSBTZWN0 aW9uIDIuNS4xKSBtdXN0IGJlIHJlcGxhY2VkIHdpdGgg4oCcZGVmYXVsdCBhbGdvcml0aG3igJ0u IFNpbWlsYXJseSwg4oCcbm9uLXplcm8gQWxnb3JpdGht4oCdIHNob3VsZCBiZSByZXBsYWNlZCB3 aXRoIOKAnG5vbi1kZWZhdWx0IGFsZ29yaXRobeKAnQojQWhtZWQ6IFdpbGwgYmUgZG9uZSBpbiB0 aGUgbmV4dCB2ZXJzaW9uW1tTYXNoYV1dICBPSwoKCgoKMy4gICAgSSB0aGluayB0aGF0IFJGQyAz NDQzIGFuZCBSRkMgNTMzMiBzaG91bGQgYmUgbGlzdGVkIGFzIE5vcm1hdGl2ZSByZWZlcmVuY2Vz IGluIHRoaXMgZHJhZnQgd2hpbGUgUkZDIDUzMzEgYW5kIFJGQyA4Mjc3IHNob3VsZCBiZSBsaXN0 ZWQgYXMgSW5mb3JtYXRpdmUgcmVmZXJlbmNlcy4gVGhpcyB3b3VsZCBpbXByb3ZlIHRoZSByZWFk YWJpbGl0eSBvZiB0aGUgZHJhZnQgd2l0aG91dCBhbnkgaW1wYWN0IG9uIGl0cyBhZHZhbmNlbWVu dC4KCiNBaG1lZCBSRkM1MzMxIGRlc2NyaWJlcyB1cHN0cmVhbSBsYWJlbCBhc3NpZ25tZW50LiBB cyB5b3UgbWVudGlvbmVkIGFib3ZlIChhbmQgSSB3aWxsIG1vZGlmeSB0aGUgZHJhZnQgdG8gaW5k aWNhdGUgdGhhdCkgU1ItTVBMUyBiZWhhdmlvciBpcyBzaW1pbGFyIHRvIGRvd25zdHJlYW0gbGFi ZWwgYXNzaWdubWVudC4gUkZDIDM0NDMgZGVzY3JpYmVzIFRUTCBiZWhhdmlvci4gVGhpcyBpcyBh biBNUExTIGZvcndhcmRpbmcgYmVoYXZpb3IuIEFzIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQsIFNS LU1QTFMgZG9lcyBub3QgbW9kaWZ5IGF0IHRoZSBNUExTIGZvcndhcmRpbmcgYmVoYXZpb3IKW1tT YXNoYV1dIFJlZ2FyZGluZyBSRkMgNTMzMSDigJMgeW91IG1heSBza2lwIHRoaXMgcmVmZXJlbmNl IGlmIHlvdSBzdGF0ZSAoYXMgZGlzY3Vzc2VkIGJlbG93KSB0aGF0IFNSLU1QTFMgb25seSBhbGxv Y2F0ZXMgbGFiZWxzIGZyb20gdGhlIHBlci1wbGF0Zm9ybSBsYWJlbCBzcGFjZS4gUmVnYXJkaW5n IFJGQyAzNDQzIOKAkyBJIGRvIG5vdCB0aGluayB0aGF0IHlvdSBjYW4gZnVsbHkgYXZvaWQgZGlz Y3Vzc2lvbiBvZiBVbmlmb3JtIGFuZCBQaXBlL1Nob3J0IFBpcGUgbW9kZWxzLCBhbmQgdGhlcmVm b3JlIHlvdSB3aWxsIG5lZWQgdGhpcyByZWZlcmVuY2UuCiMjQWhtZWQ6IEkgZGlkIG5vdCBhZGQg cmZjNTMzMSBhcyBhIHJlZmVyZW5jZSAuIEFnYWluIHB1c2hpbmcgbXVsdGlwbGUgbGFiZWxzIG9u IHRvcCBvZiBhIHBhY2tldCBpcyBhIG1hdHRlciBvZiBTUi1wb2xpY3ksIHdoaWNoIGlzIGhhbmRs ZWQgaW4gYSBzZXBhcmF0ZSBkcmFmdC4KCgoKCgoKCkhvcGVmdWxseSwgdGhlc2UgY29tbWVudHMg d2lsbCBiZSB1c2VmdWwuCiNBaG1lZDogVGhleSBhcmUgY2VydGFpbmx5IHF1aXRlIHVzZWZ1bC4g VGhhbmtzIGEgbG90CgoKCgpSZWdhcmRzLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNl bGw6ICAgICAgKzk3Mi01NDkyNjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPgoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJl Y2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcwpDT05GSURFTlRJ QUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcwp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMg YnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwKYW5k IGFsbCBjb3BpZXMgdGhlcmVvZi4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9u bHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzCkNPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzCnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWws IHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbAphbmQgYWxsIGNvcGll cyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgoKCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwoKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCgpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgoKClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7Cgp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgoK QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgoKVGhhbmsg eW91LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVk IGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlz CkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29t LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzCnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNl IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBv cmlnaW5hbAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSBy ZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgCkNPTkZJREVO VElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIAp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0g dXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwg CmFuZCBhbGwgY29waWVzIHRoZXJlb2YuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= --_000_DB5PR0301MB190941EA048FE7B26F8E96639DF20DB5PR0301MB1909_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD11dGYtOCI+CjwvaGVhZD4KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+CjxkaXYgZGlyPSJhdXRv IiBzdHlsZT0iZGlyZWN0aW9uOmx0cjsgbWFyZ2luOjA7IHBhZGRpbmc6MDsgZm9udC1mYW1pbHk6 c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4KQWhtZWQgYW5kIGFsbCw8 YnI+CjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IG1hcmdpbjow OyBwYWRkaW5nOjA7IGZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBjb2xv cjpibGFjayI+CkkgYW0gb24gdmFjYXRpb24gdGhpcyB3ZWVrIHdpdGgganVzdCBteSBjZWxsIHBo b25lIHRvIHNlZSBteSBlbWFpbHMuPGJyPgo8YnI+CjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byIgc3R5 bGU9ImRpcmVjdGlvbjpsdHI7IG1hcmdpbjowOyBwYWRkaW5nOjA7IGZvbnQtZmFtaWx5OnNhbnMt c2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBjb2xvcjpibGFjayI+Ckkgd2lsbCBwcm92aWRlIHNvbWUg d29yZGluZyBvbmNlIEkgYW0gYmFjay48YnI+Cjxicj4KPC9kaXY+CjxkaXYgZGlyPSJhdXRvIiBz dHlsZT0iZGlyZWN0aW9uOmx0cjsgbWFyZ2luOjA7IHBhZGRpbmc6MDsgZm9udC1mYW1pbHk6c2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4KTWVhbndoaWxlLCBhcG9sb2dp ZXMgZm9yIHRoZSBkZWxheSw8YnI+CjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVj dGlvbjpsdHI7IG1hcmdpbjowOyBwYWRkaW5nOjA7IGZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7IGZv bnQtc2l6ZToxMXB0OyBjb2xvcjpibGFjayI+ClNhc2hhPGJyPgo8YnI+CjwvZGl2Pgo8ZGl2IGRp cj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IG1hcmdpbjowOyBwYWRkaW5nOjA7IGZvbnQt ZmFtaWx5OnNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBjb2xvcjpibGFjayI+CjxkaXYgZGly PSJhdXRvIiBzdHlsZT0iZGlyZWN0aW9uOmx0cjsgbWFyZ2luOjA7IHBhZGRpbmc6MDsgZm9udC1m YW1pbHk6c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4KVGh1bWIgdHlw ZWQgYnkgU2FzaGEgVmFpbnNodGVpbjwvZGl2Pgo8YnI+CjwvZGl2Pgo8aHIgdGFiaW5kZXg9Ii0x IiBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+CjxkaXYgaWQ9ImRpdlJw bHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xv cj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gQWhtZWQgQmFz aGFuZHkgJmx0O2FiYXNoYW5keS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+CjxiPlNlbnQ6PC9iPiBT dW5kYXksIE9jdG9iZXIgMjgsIDIwMTggMzowMjo0NSBBTTxicj4KPGI+VG86PC9iPiBBbGV4YW5k ZXIgVmFpbnNodGVpbjsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208YnI+CjxiPkNjOjwv Yj4gSm9uYXRoYW4gSGFyZHdpY2sgKEpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tKTsg c2hyYWRkaGFAanVuaXBlci5uZXQ7IHNwcmluZ0BpZXRmLm9yZzxicj4KPGI+U3ViamVjdDo8L2I+ IFJlOiBSdGdEaXIgRWFybHkgcmV2aWV3OiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctbXBscy0xMzwvZm9udD4KPGRpdj4mbmJzcDs8L2Rpdj4KPC9kaXY+CjxkaXY+U2FzaGE8YnI+ Cjxicj4KSSB1cGxvYWRlZCB2ZXJzaW9uIDE1LiBCdXQgSSB3YXMgbm90IHN1cmUgaG93IHRvIGJl c3QgYWRkcmVzcyB5b3VyIGNvbmNlcm48YnI+Cjxicj4KU28gUGxlYXNlIHByb3Bvc2UgdGhlIHdv cmRpbmcvbW9kaWZpY2F0aW9ucyB0aGF0IGxvb2tzIHJlYXNvbmFibGUgdG8geW91IGFuZCBJIHdp bGwgYmUgbW9yZSB0aGFuIGhhcHB5IHRvIGluY29ycG9yYXRlIHRoZW08YnI+Cjxicj4KQWhtZWQ8 YnI+Cjxicj4KKEkgcmVwbGllZCB0byB0aGlzIGVtYWlsIGEgbGl0dGxlIHdoaWxlIGFnbyBidXQg SSBhbSByZXBseWluZyB0byBpdCBhZ2FpbiB3aXRoIGEgY3V0ZG93biBvbiB0aGUgbGlzdCBvZiBy ZWNlaXB0cyBiZWNhdXNlIHRoZSBtYWlsaW5nIGxpc3Qgc2FpZCB0aGUgZW1haWwgaXMgYmVpbmcg aGVsZCk8YnI+Cjxicj4KPGJyPgo8YnI+CjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24g Ny8yNS8xOCAxMjoyMCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6PGJyPgo8L2Rpdj4K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkCiAgICAgICAgbWVkaXVtKSI+CjxzdHlsZT4KPCEt LQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCJ9CkBmb250LWZhY2UKCXtm b250LWZhbWlseToiQ2FsaWJyaSBMaWdodCJ9CkBmb250LWZhY2UKCXtmb250LWZhbWlseTpDYWxp YnJpfQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6VmVyZGFuYX0KQGZvbnQtZmFjZQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYX0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbAoJ e21hcmdpbi10b3A6MGNtOwoJbWFyZ2luLXJpZ2h0OjBjbTsKCW1hcmdpbi1ib3R0b206MTIuMHB0 OwoJbWFyZ2luLWxlZnQ6MjEuNnB0OwoJbGluZS1oZWlnaHQ6MTIuMHB0OwoJZm9udC1zaXplOjEy LjBwdDsKCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Cgljb2xvcjpibGFja30KaDUKCXttYXJn aW4tdG9wOjIuMHB0OwoJbWFyZ2luLXJpZ2h0OjBjbTsKCW1hcmdpbi1ib3R0b206MGNtOwoJbWFy Z2luLWxlZnQ6MjEuNnB0OwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJbGluZS1oZWlnaHQ6MTIu MHB0OwoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZh bWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsKCWNvbG9yOiMyRTc0QjU7Cglmb250LXdl aWdodDpub3JtYWx9CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsKCXtjb2xvcjojMDU2M0MxOwoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkCgl7Y29sb3I6Izk1NEY3MjsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9CnAKCXtt YXJnaW4tcmlnaHQ6MGNtOwoJbWFyZ2luLWxlZnQ6MjEuNnB0OwoJbGluZS1oZWlnaHQ6MTIuMHB0 OwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Cgljb2xvcjpi bGFja30KcHJlCgl7bWFyZ2luOjBjbTsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWxpbmUtaGVp Z2h0Om5vcm1hbDsKCWZvbnQtc2l6ZToxMC4wcHQ7Cglmb250LWZhbWlseToiQ291cmllciBOZXci OwoJY29sb3I6d2luZG93dGV4dH0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaAoJe21hcmdpbi10b3A6MGNtOwoJbWFyZ2luLXJpZ2h0 OjBjbTsKCW1hcmdpbi1ib3R0b206MGNtOwoJbWFyZ2luLWxlZnQ6MzYuMHB0OwoJbWFyZ2luLWJv dHRvbTouMDAwMXB0OwoJbGluZS1oZWlnaHQ6bm9ybWFsOwoJZm9udC1zaXplOjExLjBwdDsKCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwoJY29sb3I6YmxhY2t9CnNwYW4uSGVhZGlu ZzVDaGFyCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7Cgljb2xvcjoj MkU3NEI1fQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3In0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMAoJe21hcmdp bi1yaWdodDowY207CgltYXJnaW4tbGVmdDowY207CglsaW5lLWhlaWdodDpub3JtYWw7Cglmb250 LXNpemU6MTIuMHB0OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7Cgljb2xv cjpibGFja30KcC5tc29ub3JtYWwwMCwgbGkubXNvbm9ybWFsMDAsIGRpdi5tc29ub3JtYWwwMAoJ e21hcmdpbi1yaWdodDowY207CgltYXJnaW4tbGVmdDowY207CglsaW5lLWhlaWdodDpub3JtYWw7 Cglmb250LXNpemU6MTIuMHB0OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 Cgljb2xvcjpibGFja30KcC5tc29jaHBkZWZhdWx0LCBsaS5tc29jaHBkZWZhdWx0LCBkaXYubXNv Y2hwZGVmYXVsdAoJe21hcmdpbi1yaWdodDowY207CgltYXJnaW4tbGVmdDoyMS42cHQ7CglsaW5l LWhlaWdodDoxMi4wcHQ7Cglmb250LXNpemU6MTAuMHB0OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7Cgljb2xvcjpibGFja30KcC5SRkNMaXN0QnVsbGV0LCBsaS5SRkNMaXN0 QnVsbGV0LCBkaXYuUkZDTGlzdEJ1bGxldAoJe21hcmdpbi10b3A6MGNtOwoJbWFyZ2luLXJpZ2h0 OjBjbTsKCW1hcmdpbi1ib3R0b206MTIuMHB0OwoJbWFyZ2luLWxlZnQ6NDMuMnB0OwoJdGV4dC1p bmRlbnQ6LTIxLjZwdDsKCWxpbmUtaGVpZ2h0OjEyLjBwdDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglm b250LWZhbWlseToiQ291cmllciBOZXciOwoJY29sb3I6YmxhY2t9CnNwYW4uZW1haWxzdHlsZTE5 Cgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Cgljb2xvcjp3aW5kb3d0ZXh0fQpz cGFuLmVtYWlsc3R5bGUyMAoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwoJY29s b3I6IzFGNDk3RH0Kc3Bhbi5FbWFpbFN0eWxlMjgKCXtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsKCWNvbG9yOiMxRjQ5N0R9CnNwYW4uRW1haWxTdHlsZTI5Cgl7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7Cgljb2xvcjojMUY0OTdEfQpzcGFuLkVtYWlsU3R5bGUzMAoJ e2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwoJY29sb3I6IzFGNDk3RH0KLk1zb0No cERlZmF1bHQKCXtmb250LXNpemU6MTAuMHB0fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXttYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0fQpkaXYuV29yZFNlY3Rpb24xCgl7fQotLT4KPC9z dHlsZT4KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+U3Rl cGhhbmUsPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+TG90cyBvZiB0aGFua3MgZm9y IHlvdXIgZW1haWwsIGFuZCBhcG9sb2dpZXMgZm9yIGEgbG9uZyBkZWxheWVkIHJlc3BvbnNlLjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowY20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPlJlZ2FyZGluZyB5b3UgcmVmZXJlbmNlIHRv IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEOyBiYWNrZ3JvdW5kOnll bGxvdyI+QkdQCiAzMTA3IGxhYmVsIG92ZXIgYW4gTERQIGxhYmVsIG92ZXIgYW4gUlNWUCBsYWJl bCB0byBidWlsZCBhbiBlbmQtdG8tZW5kIHRyYW5zcG9ydDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm OyBjb2xvcjojMUY0OTdEIj7igJ0sIEkgaGF2ZSBsb29rZWQgdXAKPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzgyNzciPlJGQyA4Mjc3PC9hPiAmbmJzcDt0aGF0IGhhcyBy ZXBsYWNlZCBSRkMgMzEwNywgYW5kIGZvdW5kIHRoZXJlIHRoZSBmb2xsb3dpbmcKPGI+PGk+ZXhw bGljaXQ8L2k+PC9iPiBzdGF0ZW1lbnQ6PC9zcGFuPjwvcD4KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBXaGVuIHB1c2hpbmcgbGFiZWxzIG9udG8gYSBwYWNrZXQn cyBsYWJlbCBzdGFjaywgdGhlIFRpbWUtdG8tTGl2ZTwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoVFRMKSBmaWVsZCAoWzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMDMyIiB0aXRsZT0iJnF1b3Q7TVBMUyBMYWJl bCBTdGFjayBFbmNvZGluZyZxdW90OyI+UkZDMzAzMjwvYT5dLCBbPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzM0NDMiIHRpdGxlPSImcXVvdDtUaW1lIFRvIExpdmUgKFRU TCkgUHJvY2Vzc2luZyBpbiBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIE5l dHdvcmtzJnF1b3Q7Ij5SRkMzNDQzPC9hPl0pIGFuZCB0aGUgVHJhZmZpYyBDbGFzcyAoVEMpIGZp ZWxkPC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IChbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMwMzIiIHRpdGxl PSImcXVvdDtNUExTIExhYmVsIFN0YWNrIEVuY29kaW5nJnF1b3Q7Ij5SRkMzMDMyPC9hPl0sIFs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ2MiIgdGl0bGU9IiZxdW90 O011bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSBMYWJlbCBTdGFjayBFbnRyeTog JnF1b3Q7Ij5SRkM1NDYyPC9hPl0pIG9mIGVhY2ggbGFiZWwgc3RhY2sgZW50cnkgbXVzdCwgb2Yg Y291cnNlLCBiZTwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBzZXQuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZG9lcyBub3Qgc3BlY2lmeSBhbnkg c2V0IG9mIHJ1bGVzIGZvciBzZXR0aW5nPC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZXNlIGZpZWxkczsgdGhhdCBpcyBhIG1hdHRlciBv ZiBsb2NhbCBwb2xpY3kuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwv cHJlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjoj MUY0OTdEIj5ObyBlcXVpdmFsZW50IG9mIHRoaXMgc3RhdGVtZW50IGNvdWxkIGJlIGZvdW5kIGlu IFJGQyAzMTA3IOKAkyBwcm9iYWJseSBiZWNhdXNlIFJGQyAzNDQzIGhhcyBub3QgeWV0IGJlZW4g cHVibGlzaGVkIHRoZW4uCjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPkZyb20gbXkg UE9WIGluY2x1ZGluZyB0aGUgc2FtZSAob3IgZXF1aXZhbGVudCkgZXhwbGljaXQgc3RhdGVtZW50 IGluIHRoZSBkcmFmdCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIHJlc29sdmUgdGhlIGlzc3VlLjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowY20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPkhvcGUgdGhpcyBoZWxwcy48L3NwYW4+PC9w Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJv dHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+ CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPlNhc2hhPC9zcGFuPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsg bGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1h cmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZjsgY29sb3I6IzFGNDk3RCI+T2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAx cHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0Qi PkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4t Ym90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNv bG9yOiMxRjQ5N0QiPkVtYWlsOiZuYnNwOyZuYnNwOwo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFi YnJldmlhdGVkIiBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20i PgpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT48L3NwYW4+PC9wPgo8L2Rpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6 c29saWQgI0UxRTFFMQogICAgICAgICAgICAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9t Oi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjp3aW5k b3d0ZXh0Ij4KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRv OnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIj5zdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbTwvYT4gWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Im1haWx0bzpz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSI+bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tPC9hPl0KPGJyPgo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDE4 IDI6MjcgUE08YnI+CjxiPlRvOjwvYj4gQWhtZWQgQmFzaGFuZHkgPGEgY2xhc3M9Im1vei10eHQt bGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmFiYXNoYW5keS5pZXRmQGdtYWlsLmNvbSI+CiZs dDthYmFzaGFuZHkuaWV0ZkBnbWFpbC5jb20mZ3Q7PC9hPjsgQWxleGFuZGVyIFZhaW5zaHRlaW4g PGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tIj4KJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tJmd0OzwvYT48YnI+CjxiPkNjOjwvYj4gPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZp YXRlZCIgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+ OyAnPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+Jwo8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIz OTZFIiBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9h PjsgJzxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzphZHJp YW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPicKPGEgY2xhc3M9Im1vei10 eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPiZsdDth ZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OzwvYT47IEpvbmF0aGFuIEhhcmR3aWNrICg8YSBjbGFzcz0i bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86Sm9uYXRoYW4uSGFyZHdpY2tA bWV0YXN3aXRjaC5jb20iPkpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tPC9hPikKPGEg Y2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmpvbmF0aGFuLmhhcmR3 aWNrQG1ldGFzd2l0Y2guY29tIj4mbHQ7am9uYXRoYW4uaGFyZHdpY2tAbWV0YXN3aXRjaC5jb20m Z3Q7PC9hPjsKPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRv OnNocmFkZGhhQGp1bmlwZXIubmV0Ij5zaHJhZGRoYUBqdW5pcGVyLm5ldDwvYT47CjxhIGNsYXNz PSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmci PnNwcmluZ0BpZXRmLm9yZzwvYT47CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnIj5zcHJpbmctY2hhaXJzQGlldGYu b3JnPC9hPjsKPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRv OmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmci PgpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy5hdXRob3JzQGlldGYub3Jn PC9hPjxicj4KPGI+U3ViamVjdDo8L2I+IFJFOiBSdGdEaXIgRWFybHkgcmV2aWV3OiBkcmFmdC1p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMzwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj5IaSBTYXNoYSw8L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4mZ3Q7PC9z cGFuPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAiPiBUaGUgaGVhZC1lbmQg bm9kZSBzZW5kcyBTUi1NUExTIHBhY2tldHMgYWNyb3NzIGEgcGF0aCBkZWZpbmVkCiBieSBhbiBv cmRlcmVkIHNldCBvZiBTSURzIHdpdGggbW9yZSB0aGFuIG9uZSBTSUQgaW4gdGhlIGxpc3QuIEVh Y2ggU0lEIGlzIHJlcHJlc2VudGVkIGJ5IGEgbGFiZWwgc3RhY2sgZW50cnkgKExTRSkgaW4gdGhl IE1QTFMgbGFiZWwgc3RhY2ssIGFuZCB0aGUgbGFiZWwgZmllbGQgaW4gZWFjaCBMU0UgaXMgdGhl IGxhYmVsIHRoYXQgbWF0Y2hlcyB0aGUgY29ycmVzcG9uZGluZyBTSUQuIEhvd2V2ZXIsIGVhY2gg TFNFIGFsc28gaW5jbHVkZXMgdGhlCiBUVEwgYW5kIFRDIGZpZWxkcy4gSG93IGRvZXMgdGhlIGhl YWQtZW5kIG5vZGUgc2V0IHRoZXNlIGZpZWxkcyBpbiBlYWNoIG9mIHRoZSBMU0VzIGZvbGxvd2lu ZyB0aGUgdG9wIG9uZT8gVGhpcyBjbGVhcmx5IGRlcGVuZHMgb24gdGhlIG1vZGVsIChVbmlmb3Jt IHZzLiBQaXBlL1Nob3J0IFBpcGUpIGltcGxlbWVudGVkIGluIGVhY2ggbm9kZSB0aGF0IHRoYXQg cGVyZm9ybXMgTmV4dCBvcGVyYXRpb24gb24gdGhlIHBhY2tldCBhbG9uZyB0aGUgcGF0aAog4oCT IGJ1dCB0aGUgaGVhZC1lbmQgbm9kZSB1c3VhbGx5IGlzIG5vdCBhd2FyZSBvZiB0aGF0LiA8L3Nw YW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNv bG9yOiMxRjQ5N0QiPldoeSBkbyB5b3UgdGhpbmsgdGhpcyBpcyBkaWZmZXJlbnQgZnJvbSBhIG5l c3RlZCBNUExTIHR1bm5lbCB0aGF0IGV4aXN0cyB0b2RheSA/IEkgY29tcGxldGVseSBhZ3JlZSB3 aXRoIHlvdSB0aGF0IHRoZSBoZWFkIGVuZCBkb2VzIG5vdCBrbm93IHRoZSBiZWhhdmlvciBvZgog dGhlIHRhaWwtZW5kIGluIHRlcm0gb2YgVFRML1RDIHByb2Nlc3NpbmcuIEJ1dCB0aGF04oCZcyBh bHJlYWR5IHRoZSBjYXNlIHRvZGF5LCBhbmQgaXTigJlzIHRoZSBqb2Igb2YgZW5naW5lZXJzIHRv IGVuc3VyZSB0aGF0IGFsbCBub2RlcyBpbiB0aGUgbmV0d29yayBhcmUgb3BlcmF0aW5nIGluIHRo ZSBzYW1lIG1vZGUgKHVuaWZvcm0gdnMgcGlwZS9zaG9ydCBwaXBlKS48L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj5XZSBjYW4g YWxyZWFkeSBzdGFjayB0b2RheSBhIEJHUCAzMTA3IGxhYmVsIG92ZXIgYW4gTERQIGxhYmVsIG92 ZXIgYW4gUlNWUCBsYWJlbCB0byBidWlsZCBhbiBlbmQtdG8tZW5kIHRyYW5zcG9ydCwgdGhlIFRU TCBwcm9jZXNzaW5nIHNob3VsZCBub3QgYmUgZXNzZW50aWFsbHkKIGRpZmZlcmVudC48L3NwYW4+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdE Ij5Db3VsZCB5b3UgcGluIHBvaW50IHRoZSBkaWZmZXJlbmNlIHRoYXQgeW91IHNlZSA/PC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZjsgY29sb3I6IzFGNDk3RCI+QnJnZHMsPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+U3RlcGhhbmU8 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmOyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPgo8ZGl2Pgo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjQjVDNERGCiAgICAgICAgICAgIDEuMHB0 OyBwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmOyBjb2xvcjp3aW5kb3d0ZXh0Ij4gQWhtZWQgQmFzaGFuZHkgWzxhIGhyZWY9 Im1haWx0bzphYmFzaGFuZHkuaWV0ZkBnbWFpbC5jb20iPm1haWx0bzphYmFzaGFuZHkuaWV0ZkBn bWFpbC5jb208L2E+XQo8YnI+CjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMTYsIDIwMTggMjI6 MDM8YnI+CjxiPlRvOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW48YnI+CjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+OyAnPGEg Y2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5v cmciPm1wbHNAaWV0Zi5vcmc8L2E+JzsgJzxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0 ZWQiIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVr PC9hPic7IEpvbmF0aGFuCiBIYXJkd2ljayAoPGEgaHJlZj0ibWFpbHRvOkpvbmF0aGFuLkhhcmR3 aWNrQG1ldGFzd2l0Y2guY29tIj5Kb25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbTwvYT4p Owo8YSBocmVmPSJtYWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQiPnNocmFkZGhhQGp1bmlwZXIu bmV0PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+CnNwcmluZ0BpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnIj5zcHJpbmctY2hh aXJzQGlldGYub3JnPC9hPjsKPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmciPmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmc8L2E+PGJyPgo8Yj5TdWJqZWN0OjwvYj4g UmU6IFJ0Z0RpciBFYXJseSByZXZpZXc6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1tcGxzLTEzPC9zcGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8L3A+CjxwPlRoYW5rcyBhIGxvdCBmb3IgdGhlIHJlcGx5PC9wPgo8cD5TZWUgaW5saW5l ICZxdW90OyMjQWhtZWQmcXVvdDs8L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4K PGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNy8xMS8xOCAyOjAyIEFNLCBBbGV4YW5kZXIg VmFpbnNodGVpbiB3cm90ZTo8L3A+CjwvZGl2Pgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPkFobWVk LCBhbmQgYWxsLDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPkxvdHMgb2YgdGhhbmtz IGZvciBhIGRldGFpbGVkIHJlc3BvbnNlIHRvIG15IGNvbW1lbnRzLgo8L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm OyBjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlCjwvc3Bhbj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm OyBjb2xvcjojMDBCMDUwIj5pbmxpbmUgYmVsb3c8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmOyBjb2xvcjojMUY0OTdEIj4gbXkgcG9zaXRpb24gb24gZWFjaCBvZiB0aGVtLjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjwvcD4KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGlu ZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+U2FzaGE8 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2lu LWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwi Pgo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj5PZmZpY2U6ICYjNDM7OTcyLTM5MjY2 MzAyPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1h cmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZjsgY29sb3I6IzFGNDk3RCI+Q2VsbDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 Mzs5NzItNTQ5MjY2MzAyPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+RW1haWw6Jm5ic3A7Jm5ic3A7CjxhIGhyZWY9 Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSI+QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb208L2E+PC9zcGFuPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+Cjxk aXY+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNvbGlkICNFMUUxRTEKICAg ICAgICAgICAgICAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+CjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUt aGVpZ2h0Om5vcm1hbCI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjp3aW5kb3d0ZXh0Ij4gQWhtZWQg QmFzaGFuZHkgWzxhIGhyZWY9Im1haWx0bzphYmFzaGFuZHkuaWV0ZkBnbWFpbC5jb20iPm1haWx0 bzphYmFzaGFuZHkuaWV0ZkBnbWFpbC5jb208L2E+XQo8YnI+CjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEp1bHkgMTEsIDIwMTggNDo0MiBBTTxicj4KPGI+VG86PC9iPiBBbGV4YW5kZXIgVmFpbnNo dGVpbiA8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iPgom bHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFp bHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmciPnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L2E+Owo8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0 aG9yc0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0 aG9yc0BpZXRmLm9yZzwvYT48YnI+CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJA aWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+OyAnPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0 Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+Jwo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+ Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9hPjsgJzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9n LmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPicKPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWsiPiZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OzwvYT47IEpvbmF0aGFuIEhh cmR3aWNrICg8YSBocmVmPSJtYWlsdG86Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20i PkpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tPC9hPikKPGEgaHJlZj0ibWFpbHRvOmpv bmF0aGFuLmhhcmR3aWNrQG1ldGFzd2l0Y2guY29tIj4mbHQ7am9uYXRoYW4uaGFyZHdpY2tAbWV0 YXN3aXRjaC5jb20mZ3Q7PC9hPjsKPGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0 Ij5zaHJhZGRoYUBqdW5pcGVyLm5ldDwvYT47IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciPgpzcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPgo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJ0Z0RpciBF YXJseSByZXZpZXc6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTEzPC9z cGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+Cjxw PlRoYW5rcyBmb3IgdGhvcm91Z2ggKGFuZCBWRVJZIGNsZWFyKSB0aGUgcmV2aWV3PC9wPgo8cD5T ZWUgaW5saW5lICNBaG1lZDwvcD4KPHA+Jm5ic3A7PC9wPgo8cD5BaG1lZDwvcD4KPHA+Jm5ic3A7 PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDYvMTUvMTggMTE6MDggUE0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOjwv cD4KPC9kaXY+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90 dG9tOjUuMHB0Ij4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlLXNlbmRpbmcgdG8mbmJzcDsg Y29ycmVjdCBTUFJJTkcgV0cgbGlzdC48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPlNpbmNlcmUgYXBvbG9naWVzIGZvciB0aGUgZGVsYXkgY2F1c2VkIGJ5IGEgdHlw by48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPlRodW1iIHR5cGVkIGJ5IFNhc2hhIFZhaW5zaHRlaW48L3NwYW4+PC9wPgo8L2Rpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoyMS42cHQ7IG1hcmdpbi1ib3R0b206MTIuMHB0Ij4KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAw MXB0OyB0ZXh0LWFsaWduOmNlbnRlciI+CjxzcGFuIHN0eWxlPSIiPgo8aHIgYWxpZ249ImNlbnRl ciIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSI+Cjwvc3Bhbj48L2Rpdj4KPC9kaXY+CjxkaXYgaWQ9ImRp dlJwbHlGd2RNc2ciPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQWxleGFuZGVy IFZhaW5zaHRlaW48YnI+CjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1bmUgMTAsIDIwMTggMTA6NDM6 NTIgQU08YnI+CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5v cmciPnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0aG9yc0BpZXRmLm9yZyI+CmRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmc8L2E+PGJyPgo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5jb20iPnNwcmluZ0BpZXRmLmNv bTwvYT47IDxhIGhyZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj4KcnRnLWRpckBpZXRmLm9y ZzwvYT47ICc8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4n OyAnPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28u dWs8L2E+JzsgSm9uYXRoYW4gSGFyZHdpY2sgKDxhIGhyZWY9Im1haWx0bzpKb25hdGhhbi5IYXJk d2lja0BtZXRhc3dpdGNoLmNvbSI+Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb208L2E+ KTsKPGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Ij5zaHJhZGRoYUBqdW5pcGVy Lm5ldDwvYT48YnI+CjxiPlN1YmplY3Q6PC9iPiBSRTogUnRnRGlyIEVhcmx5IHJldmlldzogZHJh ZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTM8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4KPC9zcGFuPjwvcD4KPGRp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7PC9zcGFuPjwvcD4K PC9kaXY+CjwvZGl2Pgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+RXhwbGljaXRseSBhZGRpbmcgU2hyYWRkaGEgJm5ic3A7d2hvIGlz IHRoZSBzaGVwaGVyZCBvZiB0aGlzIGRyYWZ0Lgo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4KPGRpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlNhc2hhPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PZmZpY2U6ICYjNDM7OTcyLTM5MjY2MzAyPC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNlbGw6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbWFp bDombmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tIj4KQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PC9zcGFuPjwvcD4K PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PC9wPgo8ZGl2Pgo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxCiAgICAgICAgICAgICAgICAgICAgMS4wcHQ7IHBhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQWxleGFuZGVy IFZhaW5zaHRlaW4gPGJyPgo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDgsIDIwMTggNTo0MyBQ TTxicj4KPGI+VG86PC9iPiAnPGEgaHJlZj0ibWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmci PnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L2E+JyA8YSBocmVmPSJtYWlsdG86c3ByaW5nLWNoYWly c0BpZXRmLm9yZyI+CiZsdDtzcHJpbmctY2hhaXJzQGlldGYub3JnJmd0OzwvYT47ICc8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0aG9yc0Bp ZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuYXV0aG9yc0Bp ZXRmLm9yZzwvYT4nCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmctbXBscy5hdXRob3JzQGlldGYub3JnIj4mbHQ7ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLW1wbHMuYXV0aG9yc0BpZXRmLm9yZyZndDs8L2E+PGJyPgo8Yj5DYzo8L2I+ICc8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYuY29tIj5zcHJpbmdAaWV0Zi5jb208L2E+JyA8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYuY29tIj4KJmx0O3NwcmluZ0BpZXRmLmNvbSZndDs8L2E+ OyA8YSBocmVmPSJtYWlsdG86cnRnLWRpckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj4KbXBsc0BpZXRmLm9yZzwvYT47ICc8YSBo cmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT4n CjxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj4mbHQ7YWRyaWFuQG9sZGRvZy5j by51ayZndDs8L2E+PGJyPgo8Yj5TdWJqZWN0OjwvYj4gUnRnRGlyIEVhcmx5IHJldmlldzogZHJh ZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTM8L3A+CjwvZGl2Pgo8L2Rpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5IZWxsbyw8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCB0byBkbyBhIHJvdXRpbmcgZGlyZWN0 b3JhdGUg4oCcZWFybHnigJ0gcmV2aWV3IG9mIHRoaXMgZHJhZnQ6CjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1tcGxzLyI+Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLzwvYT48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgcm91dGluZyBkaXJlY3RvcmF0ZSB3aWxsLCBvbiBy ZXF1ZXN0IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXIsIHBlcmZvcm0gYW4g4oCcZWFybHni gJ0gcmV2aWV3IG9mIGEgZHJhZnQgYmVmb3JlIGl0IGlzIHN1Ym1pdHRlZCBmb3IgcHVibGljYXRp b24gdG8gdGhlIElFU0cuIFRoZSBlYXJseSByZXZpZXcKIGNhbiBiZSBwZXJmb3JtZWQgYXQgYW55 IHRpbWUgZHVyaW5nIHRoZSBkcmFmdOKAmXMgbGlmZXRpbWUgYXMgYSB3b3JraW5nIGdyb3VwIGRv Y3VtZW50LiBUaGUgcHVycG9zZSBvZiB0aGUgZWFybHkgcmV2aWV3IGRlcGVuZHMgb24gdGhlIHN0 YWdlIHRoYXQgdGhlIGRvY3VtZW50IGhhcyByZWFjaGVkLiBBcyB0aGlzIGRvY3VtZW50IGlzIGN1 cnJlbnRseSBpbiB0aGUgV0cgTGFzdCBjYWxsLCBteSBmb2N1cyBmb3IgdGhlIHJldmlldyB3YXMg dG8gZGV0ZXJtaW5lCiB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBwdWJsaXNo ZWQuIFBsZWFzZSBjb25zaWRlciBteSBjb21tZW50cyBhbG9uZyB3aXRoIHRoZSBvdGhlciB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBjb21tZW50cy48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91 dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAizwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9h cmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPgo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Eb2N1bWVudDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+OiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMzwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlJldmlld2VyPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj46IEFsZXhhbmRlciAo4oCcU2FzaGHigJ0pIFZhaW5z aHRlaW4gKDxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIudmFpbnNodGVpbkBlY2l0ZWxlLmNvbSI+ YWxleGFuZGVyLnZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+KTwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlJldmlldyBEYXRlPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj46IDA4LUp1bi0xODwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkludGVuZGVkIFN0YXR1czwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+OiBQcm9wb3NlZCBTdGFuZGFyZC48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5TdW1tYXJ5PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj46PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+SSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkg dGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBpdCBpcyBzdWJtaXR0ZWQgdG8gdGhlIElF U0cuPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ Q29tbWVudHM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JIGNvbnNpZGVyIHRoaXMgZHJhZnQgYXMg YW4gaW1wb3J0YW50ICZuYnNwO2NvbXBhbmlvbiBkb2N1bWVudCB0byB0aGUKPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy0xNSI+U2VnbWVudCBSb3V0aW5nIEFyY2hpdGVjdHVyZTwvYT4gZHJhZnQgdGhhdCwgaWRlYWxs eSwgc2hvdWxkIGF1Z21lbnQgZGVmaW5pdGlvbnMgb2YgdGhlIFNlZ21lbnQgUm91dGluZyAoU1Ip IG5vdGlvbnMgYW5kIGNvbnN0cnVjdHMgZ2l2ZW4gdGhlcmUgd2l0aCBkZXRhaWxzIHNwZWNpZmlj IGZvciB0aGUgU1IgaW5zdGFudGlhdGlvbgogdGhhdCB1c2VzJm5ic3A7IHRoZSBNUExTIGRhdGEg cGxhbmUgKFNSLU1QTFMpLiZuYnNwOyBNYW55IGlzc3VlcyByYWlzZWQgaW4gbXkgcmV2aWV3IHJl ZmxlY3QgZWl0aGVyIGdhcHMgdGhhdCBzaG91bGQgYmUsIGJ1dCBoYXZlIG5vdCBiZWVuLCBjbG9z ZWQsIG9yIGluY29uc2lzdGVuY2llcyBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzLgo8L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5TaW5jZQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODI4NyI+UkZDIDgyODc8L2E+IGlzIGFscmVh ZHkgcHVibGlzaGVkIGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJGQywgSSBleHBlY3Qgc3VjaCBhdWdt ZW50YXRpb24gdG8gYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIHRoaXMgZG9jdW1lbnQgKG9y IHRvIHByb3ZpZGUgY2xlYXIgaW5kaWNhdGlvbnMgb2YgcmVxdWlyZWQgdXBkYXRlcyB0byB0aGlz IGRvY3VtZW50KS4gQW5kIEkgaW5jbHVkZQogdGhlIE1QTFMgV0cgaW50byBkaXN0cmlidXRpb24g bGlzdC4gPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ VGhpcyBkcmFmdCB3YXMgbm90IGVhc3kgcmVhZGluZyBmb3IgbWUuIEluIHBhcnRpY3VsYXIsIHRo ZSBzdHlsZSBvZiBTZWN0aW9uIDIuNSB0aGF0IGRpc2N1c3NlcyBhdCBsZW5ndGggYW5kIGluIHNv bWUgZGV0YWlsIG11bHRpcGxlIOKAnGNvcm5lciBjYXNlc+KAnSByZXN1bHRpbmcsIHByZXN1bWFi bHksCiBmcm9tIG1pc2NvbmZpZ3VyYXRpb24sIGJlZm9yZSBpdCBleHBsYWlucyB0aGUgYmFzaWMg KGFuZCByZWxhdGl2ZWx5IHNpbXBsZSkg4oCcbm9ybWFs4oCdIGJlaGF2aW9yLCBsb29rcyBwcm9i bGVtYXRpYyB0byBtZS48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj5UaGUgV0cgTGFzdCBDYWxsIGhhcyBiZWVuIGV4dGVuZGVkIGJ5IG9uZSB3ZWVrLiBO ZXZlcnRoZWxlc3MsIEkgYW0gc2VuZGluZyBvdXQgbXkgY29tbWVudHMKPC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+TWFqb3IgSXNzdWVzPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj46IE5vbmUgZm91bmQ8L3NwYW4+PC9wPgo8L2Rpdj4KPC9k aXY+CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+I0Fo bWVkOiB0aGFua3MgYSBsb3Q8YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4K PGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+TWlub3IgSXNz dWVzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj46IFF1aXRlIGEgZmV3IGJ1dCwgaG9wZWZ1 bGx5LCBlYXN5IHRvIHJlc29sdmUuPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4xLjwvc3Bh bj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPkVuY2Fwc3VsYXRpb24gb2YgU1ItTVBMUyBwYWNrZXRzPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj46Cjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5hLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPlJGQyAzMDMyIChyZWZlcmVuY2VkIGJ5IHRoZSBkcmFmdCkgYW5kIFJG QyA1MzMyICg8Yj48aT5ub3QgbWVudGlvbmVkIGluIHRoZSBkcmFmdDwvaT48L2I+KSBkZXBlbmQg dHdvIGVuY2Fwc3VsYXRpb25zIG9mIGxhYmVsZWQgcGFja2V0cyAtIG9uZSBmb3IgRG93bnN0cmVh bS1hbGxvY2F0ZWQgbGFiZWxzIGFuZCBhbm90aGVyCiBmb3IgVXBzdHJlYW0tYWxsb2NhdGVkIG9u ZXMuPC9zcGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSIiPiNBaG1lZDogUkZDNTMzMiBpcyBmb3IgbXVsdGljYXN0LiBB cyBtZW50aW9uZWQgaW4gU2VjdGlvbiA2IG9mIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91 dGluZy0xNSwgbXVsdGljYXN0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNSLiBIZW5jZSB0aGUg UkZDIHdhcyBub3QgcmVmZXJyZWQgdG8gaW4gdGhlIFNSLU1QTFMgZHJhZnQ8L3NwYW4+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMDBCMDUw Ij5bW1Nhc2hhXV0gSSB3b3VsZCBiZSBzYXRpc2ZpZWQgd2l0aCB0aGlzIHJlc3BvbnNlLCB3b3Vs ZCBpdCBub3QgYmUgZm9yIHRoZSBmb2xsb3dpbmcgdGV4dCBJIHNlZSBpbiBTZWN0aW9uIDIuMiBv ZiB0aGU8L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdE Ij4KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDEiPgpTUiBQb2xpY3kgQXJjaGl0ZWN0dXJlPC9hPiA8 L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMDBCMDUwIj5kcmFm dDo8L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgQSB2YXJpYXRpb24gb2YgU1IgUG9s aWN5IGNhbiBiZSB1c2VkIGZvciBwYWNrZXQgcmVwbGljYXRpb24uJm5ic3A7IEE8L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTou MDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jm5ic3A7Jm5ic3A7IGNhbmRpZGF0ZSBwYXRoIGNvdWxkIGNvbXByaXNlIG11bHRpcGxlIFNJ RC1MaXN0czsgb25lIGZvciBlYWNoPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFs Ij4KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyByZXBsaWNhdGlv biBwYXRoLiZuYnNwOyBJbiBzdWNoIGEgc2NlbmFyaW8sIHBhY2tldHMgYXJlIGFjdHVhbGx5PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1i b3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyByZXBsaWNhdGVkIHRocm91Z2ggZWFjaCBTSUQgTGlzdCBv ZiB0aGUgU1IgUG9saWN5IHRvIHJlYWxpemUgYSBwb2ludC08L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5l LWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5i c3A7IHRvLW11bHRpcG9pbnQgc2VydmljZSBkZWxpdmVyeS4gPC9zcGFuPjwvcD4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmOyBjb2xvcjojMDBCMDUwIj5UaGlzIGxvb2tzIHRvIG1lIGFzIGJlaW5nIHZlcnkg bXVjaCBtdWx0aWNhc3QgaW4gU1IsIGFuZCwgdW5sZXNzIHlvdSB3YW50IHRvIHNheSB0aGF0IGl0 IGlzIGxpbWl0ZWQgdG8gU1J2NiwgbWFrZXMgbXkgcXVlc3Rpb24gcmVsZXZhbnQgSU1ITy48L3Nw YW4+PC9pPjwvYj48L3A+CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+IyNBaG1lZDogVGhlIG1haW4gcmVmZXJlbmNlIGZvciB0aGlzIGRyYWZ0IGlzIHRoZSBzci1h cmNoaXRlY3R1cmUsIHdoaWNoIGNsZWFybHkgc3RhdGVzIHRoYXQgbXVsdGljYXN0IGlzIG91dCBv ZiBTUiBzY29wZS4gU1ItTVBMUywgYmVpbmcgYW4gTVBMUyBpbnN0YW50aWF0aW9uIG9mIHRoZSBT Ui1hcmNoaXRlY3R1cmUsIGZvbGxvd3MgdGhlIFNSLWFyY2hpdGVjdHVyZQogYXMgY2xvc2UgYXMg cG9zc2libGUuIElmIGFub3RoZXIgZHJhZnQgcHJvcG9zZXMgc29tZXRoaW5nIHJlbGF0ZWQgdG8g U1IsIHRoZW4gaXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBvdGhlciBkcmFmdCB0byBt ZW50aW9uIGFueSBleHRlbnNpb25zL3Jlc3RyaWN0aW9ucyBpbiByZWxhdGlvbiB0byB0aGUgYmFz aWMgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nIGFuZC9vciBTUi1NUExTLCBvciB0 byBzcGVjaWZpY2FsbHkgc2F5CiB0aGF0IGl0IGRvZXMgbm90IGFwcGx5IHRvIFNSLU1QTFMuPGJy Pgo8YnI+Cjxicj4KPC9zcGFuPjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7IG1hcmdpbi1ib3R0b206NS4wcHQiPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZiI+Yi48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tIG15IFBPViB0aGUgU1QtTVBMUyBvbmx5 IHVzZXMgRG93bnN0cmVhbS1hbGxvY2F0ZWQgbGFiZWxzIOKAkyBidXQgSSBleHBlY3QgdGhlIGRy YWZ0IHRvIHN0YXRlIHRoYXQgZXhwbGljaXRseSwgb25lIHdheSBvciBhbm90aGVyLiAoSWYgVXBz dHJlYW0tYWxsb2NhdGVkIGxhYmVscyBhcmUgcmVsZXZhbnQgZm9yIFNSLU1QTFMsCiBJIHdvdWxk IHNlZSBpdCBhcyBhIG1ham9yIGdhcCwgc28gSSBob3BlIHRoYXQgdGhpcyBpcyBub3QgdGhlIGNh c2UpLjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iIj4jQWhtZWQ6IEkgd2lsbCBhZGQgYSBzdGF0ZW1lbnQgaW4g c2VjdGlvbiAyLjIgdG8gbWVudGlvbiB0aGF0IGl0IGlzIGRvd24tc3RyZWFtIGFsbG9jYXRlZCBh cyB5b3UgbWVudGlvbmVkPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+W1tTYXNoYV1dIFRoaXMgaXMgcXVpdGUgdW5h bWJpZ3VvdXMgYW5kLCBvbmNlIGFkZGVkLCB3b3VsZCByZXNvbHZlIG15IGNvbW1lbnQgaW4gZnVs bCDigJMgdGhlIHByZXZpb3VzIGNvbW1lbnQgbm90d2l0aHN0YW5kaW5nLiBJbiBwYXJ0aWN1bGFy LCBpdCB3b3VsZAogaW1wbHkgdGhhdCBldmVuIGxhYmVscyByZXByZXNlbnRpbmcgQlNJRHMgb2Yg YSBTUiBSZXBsaWNhdGlvbiBwb2xpY2llcyB3aWxsIGJlIGRvd25zdHJlYW0tYWxsb2NhdGVkLgo8 L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNt OyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxiPjxpPjxzcGFu IHN0eWxlPSIiPiNBaG1lZDogQmluZGluZyBTSUQgaXMganVzdCBhIHNwZWNpYWwgY2FzZSBvZiBh IFNJRC4gU28gd2hhdCBhcHBsaWVzIHRvIGEgU0lEIGFwcGxpZXMgdG8gYSBiaW5kaW5nIFNJRDwv c3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSIiPiZuYnNwOzwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPGRpdj4KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj4yLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsK PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkxhYmVsIHNwYWNlcyBpbiBTUi1NUExTPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPmEuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNw Owo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+UkZDIDMwMzEgKHJlZmVyZW5jZWQgYnkgdGhlIGRy YWZ0KSBkZWZpbmVzIHBlci1wbGF0Zm9ybSBhbmQgcGVyLWludGVyZmFjZSBsYWJlbCBzcGFjZXMs IGFuZCBSRkMgNTMzMSAoPGI+PGk+bm90IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQ8L2k+PC9iPikg YWRkcyBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBhbmQgY29udGV4dAogbGFiZWxzLiA8 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Yi48L3NwYW4+ PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm Ij5UaGUgZHJhZnQgZG9lcyBub3Qgc2F5IHdoaWNoIG9mIHRoZXNlIGFyZSBvciBhcmUgbm90IHJl bGV2YW50IGZvciBTUi1NUExTPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPmMuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbSBteSBQT1Y6PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0OyB0ZXh0LWluZGVudDot MTA4LjBwdCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5pLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPkxhYmVscyByZXByZXNlbnRpbmcgYWxsIGtpbmRzIG9mIFNJRHMgbWVu dGlvbmVkIGluIHRoZSBkcmFmdCBNVVNUIGJlIGFsbG9jYXRlZCBmcm9tIHRoZSBwZXItcGxhdGZv cm0gbGFiZWwgc3BhY2Ugb25seQo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7IHRleHQtaW5kZW50Oi0xMDguMHB0Ij48c3Bh biBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmlpLjwvc3Bhbj48c3Bh biBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkF0 IHRoZSBzYW1lIHRpbWUsIGluc3RhbnRpYXRpb24gb2YgTWlycm9yIFNlZ21lbnQgSURzIGRlZmlu ZWQgaW4gU2VjdGlvbiA1LjEgb2YgdGhlIFNlZ21lbnQgUm91dGluZyBBcmNoaXRlY3R1cmUgZHJh ZnQgdXNpbmcgTVBMUyBkYXRhIHBsYW5lIGNsZWFybHkgY2FsbHMgZm9yIGNvbnRleHQgbGFiZWxz IGFuZCBjb250ZXh0LXNwZWNpZmljCiBsYWJlbCBzcGFjZXM8L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6 LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ZC48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JIGV4cGVjdCB0aGUgZHJhZnQg dG8gcHJvdmlkZSBhIGNsZWFyLWN1dCBwb3NpdGlvbiBvbiB0aGVzZSBhc3BlY3RzIG9mIFNSLU1Q TFMuPC9zcGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSIiPiNBaG1lZDogSSB3aWxsIGFkZCBhIHN0YXRlbWVudCB0byBz ZWN0aW9uIDIuMiB0byBzYXkgdGhhdCB0aGUgaXQgaXMgcGVyLXBsYXRmb3JtLiBSZWdhcmRpbmcg dGhlIGZ1bmN0aW9uICZxdW90O21pcnJvcmluZyZxdW90OywgU1IgYXR0YWNoZXMgYSAqZnVuY3Rp b24qIHRvIGVhY2ggU0lELiBUaGUgJnF1b3Q7bWlycm9yaW5nJnF1b3Q7IGZ1bmN0aW9uIGlzIGFs cmVhZHkgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xIG9mIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZwogYW5kIGlzIG5vdCBzcGVjaWZpYyB0byB0aGUgTVBMUyBmb3J3YXJkaW5nIHBs YW5lLiBIZW5jZSB0aGVyZSBpcyBubyBuZWVkIHRvIHJlLW1lbnRpb24gaXQgaGVyZSBiZWNhdXNl IHRoaXMgZG9jdW1lbnQgaXMgdHJ5aW5nIHRvIGJlIGFzIHNwZWNpZmljIGFzIHBvc3NpYmxlIHRv IHRoZSBNUExTIGZvcndhcmRpbmcgcGxhbmUuIEdlbmVyYWwgZnVuY3Rpb25zIGF0dGFjaGVkIHRv IFNJRCBhcmUgZGVzY3JpYmVkIGluIHRoZSBzZWdtZW50IHJvdXRpbmcKIGFyY2hpdGVjdHVyZSBk b2N1bWVudCBvciBmdXR1cmUgZG9jdW1lbnRzLiBGdXJ0dXJlIGRvY3VtZW50cyBwcm9wb3Npbmcg bmV3IFNSIGZ1bmN0aW9uIG11c3QgYmUgYXMgc3BlY2lmaWMgYW5kIGNsZWFyIGFzIHBvc3NpYmxl PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsg Y29sb3I6IzAwQjA1MCI+W1tTYXNoYV1dIExvb2tzIE9LIHRvIG1lLjwvc3Bhbj48L2k+PC9iPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+PGJyPgo8YnI+Cjxicj4KPGJy Pgo8L3NwYW4+PC9wPgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2lu LWJvdHRvbTo1LjBwdCI+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+My48L3NwYW4+PHNw YW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm Ij5TUi1NUExTIGFuZCBoaWVyYXJjaGljYWwgTFNQczwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+Ojwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5hLjwv c3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPlNSIExTUHMgdGhhdCBpbmNsdWRlIG1vcmUgdGhhbiBvbmUgc2VnbWVudCBhcmUgaGll cmFyY2hpY2FsIExTUHMgZnJvbSB0aGUgUE9WIG9mIHRoZSBNUExTIGRhdGEgcGxhbmUuIFRoZXJl Zm9yZSBzb21lIChwb3NzaWJseSwgYWxsKSBvZiB0aGUgbW9kZWxzIGZvciBoYW5kbGluZyBUVEwg YW5kIFRDIGJpdHMgdGhhdCBoYXZlCiBiZWVuIGRlZmluZWQgaW4gUkZDIDM0NDMgKDxiPjxpPm5v dCBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0PC9pPjwvYj4pIHNob3VsZCBhcHBseSB0byBTUi1NUExT PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmIuPC9zcGFu PjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+UkZDIDgyODcgKDxiPjxpPm5vdCByZWZlcmVuY2VkIGluIHRoZSBkcmFmdDwvaT48L2I+KSBz cGVjaWZpY2FsbHkgZGlzY3Vzc2VkIG9wZXJhdGlvbiBvZiB0aGUgTFNQIFRyYWNlcm91dGUgZnVu Y3Rpb24gZm9yIFNSIExTUHMgaW4gdGhlIGNhc2Ugd2hlbiBQaXBlL1Nob3J0IFBpcGUgbW9kZWwg Zm9yIFRUTCBoYW5kbGluZwogaXMgdXNlZDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj5jLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJz cDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZXhwZWN0IHRoZSBkcmFmdCB0byBwcm92aWRl IGF0IGxlYXN0IHNvbWUgZ3VpZGVsaW5lcyByZWdhcmRpbmcgYXBwbGljYWJpbGl0eSBvZiBlYWNo IHNwZWNpZmljIG1vZGVsIGRlZmluZWQgaW4gUkZDIDM0NDMgKHNlcGFyYXRlbHkgZm9yIFRUTCBh bmQgVEMgYml0cykgdG8gU1ItTVBMUy48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxvY2tx dW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+I0FobWVkOiBCWSBkZXNp Z24sIHRoZSBpbnN0YW50aWF0aW9uIG9mIFNSIG92ZXIgdGhlIE1QTFMgZm9yd2FyZGluZyBwbGFu ZSAoYW5kIGhlbmNlIHRoaXMgZHJhZnQpIGRvZXMgbm90IG1vZGlmeSB0aGUgTVBMUyBmb3J3YXJk aW5nIHBsYW4gYmVoYXZpb3IgYXMgaXQgaXMgbWVudGlvbmVkIGluIHRoZSBmaXJzdCBzZW50ZW5j ZSBpbiBTZWN0aW9uIDEuIFNvIHRoZSBUVEwgYmVoYXZpb3IKIHNwZWNpZmllZCBpbiByZmMzNDQz IGlzIGFscmVhZHkgaW1wbGllZCBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byByZS1tZW50aW9uIGl0 IGhlcmUganVzdCBsaWtlIGFsbCBhc3BlY3RzIG9mIE1QTFMgZm9yd2FyZGluZy4gUkZDODI4NyBp cyBPQU0tc3BlY2lmaWMuJm5ic3A7IFNSLU9BTSBpcyBoYW5kbGVkIGluIGEgc2VwYXJhdGUgZG9j dW1lbnQgc28gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdDwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAi PltbU2FzaGFdXSBVbmZvcnR1bmF0ZWx5IEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgZ29vZCBlbm91 Z2guIExldCBtZSBhc2sgYSBzcGVjaWZpYyBxdWVzdGlvbiByZWZsZWN0aW5nIG15IGNvbmNlcm5z Ojwvc3Bhbj48L2k+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjsgY29sb3I6IzAwQjA1MCI+VGhlIGhlYWQtZW5kIG5vZGUgc2VuZHMgU1ItTVBMUyBw YWNrZXRzIGFjcm9zcyBhIHBhdGggZGVmaW5lZCBieSBhbiBvcmRlcmVkIHNldCBvZiBTSURzIHdp dGggbW9yZSB0aGFuIG9uZSBTSUQgaW4gdGhlIGxpc3QuIEVhY2ggU0lEIGlzIHJlcHJlc2VudGVk IGJ5CiBhIGxhYmVsIHN0YWNrIGVudHJ5IChMU0UpIGluIHRoZSBNUExTIGxhYmVsIHN0YWNrLCBh bmQgdGhlIGxhYmVsIGZpZWxkIGluIGVhY2ggTFNFIGlzIHRoZSBsYWJlbCB0aGF0IG1hdGNoZXMg dGhlIGNvcnJlc3BvbmRpbmcgU0lELiBIb3dldmVyLCBlYWNoIExTRSBhbHNvIGluY2x1ZGVzIHRo ZSBUVEwgYW5kIFRDIGZpZWxkcy4gSG93IGRvZXMgdGhlIGhlYWQtZW5kIG5vZGUgc2V0IHRoZXNl IGZpZWxkcyBpbiBlYWNoIG9mIHRoZSBMU0VzIGZvbGxvd2luZwogdGhlIHRvcCBvbmU/IFRoaXMg Y2xlYXJseSBkZXBlbmRzIG9uIHRoZSBtb2RlbCAoVW5pZm9ybSB2cy4gUGlwZS9TaG9ydCBQaXBl KSBpbXBsZW1lbnRlZCBpbiBlYWNoIG5vZGUgdGhhdCB0aGF0IHBlcmZvcm1zIE5leHQgb3BlcmF0 aW9uIG9uIHRoZSBwYWNrZXQgYWxvbmcgdGhlIHBhdGgg4oCTIGJ1dCB0aGUgaGVhZC1lbmQgbm9k ZSB1c3VhbGx5IGlzIG5vdCBhd2FyZSBvZiB0aGF0Lgo8L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAiPlJG QyA4Mjg3IGlzIHJlbGV2YW50IGFzIGFuIGV4YW1wbGUgaGVyZSBJTUhPIGJlY2F1c2UgaXQgcmVj b21tZW5kcyB0aGUgZm9sbG93aW5nIHNldHRpbmcgb2YgVFRMIGluIFRyYWNlcm91dGUgcGFja2V0 czo8L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzkuNnB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwQjA1MCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj5TZXQgdGhlIFRUTCBvZiBhbGwgdGhlIGxhYmVscyBhYm92ZSBvbmUg dGhhdCByZXByZXNlbnRzIHRoZSBzZWdtZW50IHlvdSBhcmUgY3VycmVudGx5IHRyYWNpbmcgdG8g bWF4aW11bTwvc3Bhbj48L2k+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDozOS42cHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDBCMDUwIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMEIwNTAiPlNldCB0aGUgVFRMIG9mIHRoZSBsYWJlbCBvbmUgdGhhdCBy ZXByZXNlbnRzIHRoZSBzZWdtZW50IHlvdSBhcmUgY3VycmVudGx5IHRyYWNpbmcgdG8gdGhlIGRl c2lyZWQgdmFsdWUgKHRvIGJlIGluY3JlbWVudGVkIHVudGlsIGVuZCBvZiBzZWdtZW50IGlzIHJl YWNoZWQ8L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzkuNnB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwQjA1MCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDBCMDUwIj5TZXQgdGhlIFRUTCBvZiBhbGwgdGhlIGxhYmVscyBiZWxvdyBv bmUgdGhhdCByZXByZXNlbnRzIHRoZSBzZWdtZW50IHlvdSBhcmUgY3VycmVudGx5IHRyYWNpbmcg dG8gMC48L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9y OiMwMEIwNTAiPkkgZXhwZWN0IHRoZSBkcmFmdCB0byBwcm92aWRlIHNvbWUgcmVjb21tZW5kYXRp b25zIGZvciB0cmFmZmljIChub24tT0FNKSBwYWNrZXRzIGFzIHdlbGwuPC9zcGFuPjwvaT48L2I+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRv bTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8Yj48aT48c3BhbiBzdHlsZT0iIj4jI0Fo bWVkOiBUaGUgc2V0dGluZyBvZiB0aGUgVFRMIGZvciBub24tT0FNIHBhY2tldHMgYXJlIHN1Ympl Y3QgdG8gdGhlIHBvbGljeSB0aGF0IGNvbnN0cnVjdGVkIHRoZSBsYWJlbCBzdGFjay4gU1ItcG9s aWN5IGlzIGhhbmRsZWQgaW4gYSBzZXBhcmF0ZSBkcmFmdCZuYnNwOwo8L3NwYW4+PC9pPjwvYj48 c3BhbiBzdHlsZT0iIj48YnI+Cjxicj4KPGJyPgo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iIj48YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRp dj4KPGRpdj4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkluZmVycmluZyBuZXR3b3Jr IGxheWVyIHByb3RvY29sIGluIFNSLU1QTFM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjo8 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+YS48L3NwYW4+ PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm Ij5JIHdvbmRlciBpZiB0aGUgZHJhZnQgY291bGQgcHJvdmlkZSBhbnkgZGV0YWlscyBvbiB0aGUg c2l0dWF0aW9uIHdoZW4gYSBsYWJlbCB0aGF0IHJlcHJlc2VudHMgc29tZSBraW5kIG9mIFNJRCBp cyB0aGUgYm90dG9tLW9mLXN0YWNrIGxhYmVsIHRvIGJlIHBvcHBlZCBieSB0aGUgZWdyZXNzIExF Ujwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iIj4jYWhtZWQ6IFRoaXMgaXMgcGFydCBvZiB0aGUgJnF1b3Q7TmV4 dCZxdW90OyBmdW5jdGlvbi4gSXQgaXMgZGVzY3JpYmVkIGluIGRldGFpbCBpbiB0aGlzIGRvY3Vt ZW50Lgo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmOyBjb2xvcjojMDBCMDUwIj5bW1Nhc2hhXV0gTkVYVCBmdW5jdGlvbiBpcyBtZW50aW9uZWQg aW4gc2V2ZXJhbCBwbGFjZXMgaW4gdGhlIGRvY3VtZW50LiBDYW4geW91IHBsZWFzZSBwb2ludCB0 byB0aGUgc3BlY2lmaWMgdGV4dCB0aGF0IGlzIHJlbGV2YW50IGZvciBteSBxdWVzdGlvbj88L3Nw YW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBt YXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxiPjxpPjxzcGFuIHN0 eWxlPSIiPiMjQWhtZWQ6IFBhcnQgKGEpIGhlcmUgaXMgYSBzdGF0ZW1lbnQgbm90IGEgcXVlc3Rp b24uIFdoYXQgaXMgdGhlIHF1ZXN0aW9uPzwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4KPGJyPgo8YnI+ Cjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjxicj4KPGJy Pgo8YnI+Cjxicj4KPC9zcGFuPjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7IG1hcmdpbi1ib3R0b206NS4wcHQiPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZiI+Yi48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgdGhlIHJlZmVyZW5jZSwgUkZDIDMwMzIg c2F5cyB0aGF0IOKAnHRoZSBpZGVudGl0eSBvZiB0aGUgbmV0d29yayBsYXllciBwcm90b2NvbCZu YnNwOyBtdXN0IGJlIGluZmVyYWJsZSBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgbGFiZWwgd2hpY2gg aXMgcG9wcGVkIGZyb20mbmJzcDsgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIHBvc3NpYmx5CiBh bG9uZyB3aXRoIHRoZSBjb250ZW50cyZuYnNwOyBvZiB0aGUgbmV0d29yayBsYXllciBoZWFkZXIg aXRzZWxm4oCdPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYi PmMuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+RnJvbSBteSBQT1YgdGhlIGZvbGxvd2luZyBzY2VuYXJpbyBpbmRpY2F0ZXMg cmVsZXZhbmNlIG9mIHRoaXMgZXhwZWN0YXRpb24gZm9yIFNSLU1QTFM6PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0OyB0ZXh0 LWluZGVudDotMTA4LjBwdCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5pLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsK PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPklTLUlTIGlzIHVzZWQgZm9yIGRpc3RyaWJ1dGluZyBi b3RoIElQdjQgYW5kIElQdjYgcmVhY2hhYmlsaXR5IGluIGEgZ2l2ZW4gZG9tYWluPC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0 OyB0ZXh0LWluZGVudDotMTA4LjBwdCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5paS48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5BbiBJUy1JUyBhZGphY2VuY3kgb3ZlciBzb21lIGR1 YWwtc3RhY2sgbGluayBpcyBlc3RhYmxpc2hlZCwgYW5kIGEgc2luZ2xlIEFkai1TSUQgZm9yIHRo aXMgYWRqYWNlbmN5IGlzIGFkdmVydGlzZWQ8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7IHRleHQtaW5kZW50Oi0xMDguMHB0 Ij48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmlpaS48L3NwYW4+PHNw YW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5U aGUgbm9kZSB0aGF0IGhhcyBhc3NpZ25lZCBhbmQgYWR2ZXJ0aXNlZCB0aGlzIEFkai1TSUQgcmVj ZWl2ZXMgYSBsYWJlbGVkIHBhY2tldCB3aXRoIHRoZSBsYWJlbCByZXByZXNlbnRpbmcgdGhpcyBB ZGotU0lEIGJlaW5nIGJvdGggdGhlIHRvcCBhbmQgYm90dG9tLW9mLXN0YWNrIGxhYmVsPC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDgu MHB0OyB0ZXh0LWluZGVudDotMTA4LjBwdCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj5pdi48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgaW1wbGVtZW50ZXJzIG11c3QgYmUgZ2l2ZW4gdW5h bWJpZ3VvdXMgaW5zdHJ1Y3Rpb25zIGZvciBmb3J3YXJkaW5nIHRoZSB1bmxhYmVsZWQgcGFja2V0 IHZpYSB0aGUgZHVhbC1zdGFjayBsaW5rIGFzIGFuIElwdjQgb3IgYW4gSVB2NiBwYWNrZXQuPC9z cGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSIiPiNBaG1lZDogSWYgeW91IHRha2UgYSBsb29rIGF0IHRoZSBTUi1JU0lT ICwgU1ItT1NQRnYyIGFuZCBTUi1PU0Z2MyBkcmFmdHMsIHlvdSB3aWxsIHNlZSBhbGwgMyBwcm90 b2NvbCBhZHZlcnRpc2UgZGlmZmVyZW50IGFkai1TSURTIGZvciBJUHY0IG5leHQtaG9wIGFuZCBJ UHY2IG5leHQtaG9wLiBGb3IgZXhhbXBsZSwgSVNJUyB1c2VzIHRoZSAmcXVvdDtGLUZsYWcmcXVv dDsgKHNlY3Rpb24gMi4yLjEgaW4KIGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9ucy0xOCkgdG8gc3BlY2lmeSB3aGV0aGVyIHRoZSBhZGotU0lEIGlzIGZvciBJUHY0IGFu ZCBJUHY2LiBTaW1pbGFybHksIHRoZSBTUi1JU0lTIGRyYWZ0IGF0dGFjaGVzIGEgcHJlZml4LVNJ RCB0byB0aGUgcHJlZml4IGFkdmVydGlzZW1lbnQgYW5kIGhlbmNlIGltcGxpZXMgdGhlIGlkZW50 aXR5IG9mIHRoZSBwcm90b2NvbCB1bmRlcm5lYXRoIHRoZSBib3R0b20gbW9zdCBsYWJlbC4KIEZv ciBhbnkgb3RoZXIgJnF1b3Q7ZnVuY3Rpb24mcXVvdDsgYXR0YWNoZWQgdG8gYSBTSUQsIGl0IGlz IHBhcnQgb2YgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhpcyBmdW5jdGlvbiB0byBkZXNjcmliZSB3 aGF0IGhhcHBlbnMgd2hlbiB0aGUgU0lEIGlzIHJlcHJlc2VudGVkIGJ5IGEgbGFiZWwgaW4gdGhl IE1QTFMgZm9yd2FyZGluZyBwbGFuZSBhbmQgdGhpcyBsYWJlbCBpcyB0aGUgYm90dG9tIG1vc3Qg bGFiZWwKPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjsgY29sb3I6IzAwQjA1MCI+W1tTYXNoYV1dIE9LLCBnb3QgaXQuIFRoaXMgaXNzdWUgaXMg cmVzb2x2ZWQuPC9zcGFuPjwvaT48L2I+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iIj48YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPGRpdj4KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj41Ljwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsK PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlJlc29sdXRpb248L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPgo8Yj5vZiBDb25mbGljdHM8L2I+OiBBcmUgdGhlPC9zcGFuPjwvcD4KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmEuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZu YnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+QXJlIHRoZSBjb25mbGlj dCByZXNvbHV0aW9uIHByb2NlZHVyZXMgbGlzdGVkIGluIHNlY3Rpb24gMi41IG1hbmRhdG9yeSB0 byBpbXBsZW1lbnQ/Cjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5iLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPklmIHRoZXkgYXJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQsIGFyZSB0 aGV5IGFsc28gbWFuZGF0b3J5IHRvIGRlcGxveSwgb3IgY2FuIHRoZSBvcGVyYXRvcnMgc2ltcGx5 IHRyZWF0IGFueSBkZXRlY3RlZCBjb25mbGljdCBhcyByZXF1aXJpbmcgaHVtYW4gaW50ZXJ2ZW50 aW9uIGFuZCBwcmV2ZW50aW5nIG5vcm1hbCBvcGVyYXRpb24KIG9mIFNSLU1QTFM/PC9zcGFuPjwv cD4KPC9kaXY+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSIiPiNBaG1lZDogVGhleSBhcmUgcmVjb21tZW5kZWQuIEkgd2lsbCBtb2RpZnkgdGhl IHBhcmFncmFwaCBhZnRlciB0aGUgZmlyc3QgMyBidWxsZXRzIGluIFNlY3Rpb24gMi41IHRvIHNh eSB0aGF0IGl0IGlzIHJlY29tbWVkZWQuICZuYnNwOwo8YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9y OiMwMEIwNTAiPltbU2FzaGFdXSBPSy4gSG93ZXZlciwgaXQgd291bGQgYmUgbmljZSBpZiB5b3Ug Y291bGQgcmVmZXIgc2VwYXJhdGVseSBmb3Ig4oCcUkVDT01NRU5ERUQgdG8gaW1wbGVtZW504oCd IGFuZCDigJxSRUNPTU1FTkRFRCB0byBkZXBsb3nigJ0uICZuYnNwO1RoZSBsYXR0ZXIgcHJvYmFi bHkKIHJlcXVpcmVzIGEgY29uZmlndXJhdGlvbiBrbm9iIGZvciBlbmFibGluZyBjb25mbGljdCBy ZXNvbHV0aW9uIHJ1bGVzIChpZiB0aGV5IGFyZSBpbXBsZW1lbnRlZCkuCjwvc3Bhbj48L2k+PC9i PjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7IG1hcmdpbi1ib3R0b206 NS4wcHQiPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ Yy48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj5Gb3IgdGhlIHJlZmVyZW5jZSwgdGhlIElFVEYgY2FwaXRhbGl6ZWQgTVVTVCBh cHBlYXJzIGp1c3QgaW4gYSBmZXcgcGxhY2VzIGluIFNlY3Rpb24gMi41LCBhbmQgZWFjaCBhcHBl YXJhbmNlIGhhcyB2ZXJ5IG5hcnJvdyBjb250ZXh0Ojwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDsgdGV4dC1pbmRlbnQ6LTEw OC4wcHQiPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+aS48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5Gb3IgTUNDcyB3aGVyZSB0aGUgJnF1b3Q7VG9wb2xvZ3kmcXVvdDsgYW5k L29yICZxdW90O0FsZ29yaXRobSZxdW90OyBmaWVsZHMgYXJlIG5vdCBkZWZpbmVkLCB0aGUgbnVt ZXJpY2FsIHZhbHVlIG9mIHplcm8gTVVTVCBiZSB1c2VkIGZvciB0aGVzZSB0d28gZmllbGRzPC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDox MDguMHB0OyB0ZXh0LWluZGVudDotMTA4LjBwdCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmIj5paS48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JZiB0aGUgc2FtZSBzZXQgb2YgRkVDcyBh cmUgYXR0YWNoZWQgdG8gdGhlIHNhbWUgbGFiZWwgJnF1b3Q7TDEmcXVvdDssIHRoZW4gdGhlIHRp ZS1icmVha2luZyBydWxlcyBNVVNUIGFsd2F5cyBzZWxlY3QgdGhlIHNhbWUgRkVDIGlycmVzcGVj dGl2ZSBvZiB0aGUgb3JkZXIgaW4gd2hpY2ggdGhlIEZFQ3MgYW5kIHRoZSBsYWJlbCAmcXVvdDtM MSZxdW90OyBhcmUKIHJlY2VpdmVkLiBJbiBvdGhlciB3b3JkcywgdGhlIHRpZS1icmVha2luZyBy dWxlIE1VU1QgYmUgZGV0ZXJtaW5pc3RpYy4gPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0OyB0ZXh0LWluZGVudDotMTA4LjBw dCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5paWkuPC9zcGFuPjxz cGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ QW4gaW1wbGVtZW50YXRpb24gb2YgZXhwbGljaXQgU0lEIGFzc2lnbm1lbnQgTVVTVCBndWFyYW50 ZWUgY29sbGlzaW9uIGZyZWVuZXNzIG9uIHRoZSBzYW1lIHJvdXRlcjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb20gbXkgUE9WLCBpdCBpcyBub3QgcG9zc2libGUgdG8gaW5mZXIgdGhlIGFuc3dlciB0 byBteSBxdWVzdGlvbiBmcm9tIHRoZXNlIHN0YXRlbWVudHMuIFNvbWUgZXhwbGljaXQgc3RhdGVt ZW50IGlzIHJlcXVpcmVkLjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj4jQWhtZWQ6IEkgYWdyZWUgd2l0aCB5 b3UgUE9WIGFuZCBhcyBtZW50aW9uZWQgaW4gbXkgcmVwbHkgdG8gaXRlbXMgKGEpIGFuZCAoYiks IEkgd2lsbCBtb2RpZnkgdGhlIHBhcmFncmFwaCB0byBzYXkgdGhhdCBpdCBpcyBSRUNPTU1FTkRF RCB0byBhbnN3ZXIgeW91IHF1ZXN0aW9ucyBpbiBpdGVtcyAoYSkgYW5kIChiKTxicj4KPGJyPgo8 YnI+Cjxicj4KPC9zcGFuPjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 IG1hcmdpbi1ib3R0b206NS4wcHQiPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+ZC48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgdGllLWJyZWFraW5nIHJ1bGVzIGluIHNlY3Rp b24gMi41LjEgaW5jbHVkZSBzb21lIHNwZWNpZmljIHZhbHVlcyBmb3IgZW5jb2RpbmcgRkVDIHR5 cGVzIGFuZCBhZGRyZXNzIGZhbWlsaWVzIOKAkyBidXQgdGhlc2UgdmFsdWVzIGFyZSBub3Qgc3Vw cG9zZWQgdG8gYXBwZWFyIGluIGFueSBJQU5BIHJlZ2lzdHJpZXMgKGJlY2F1c2UKIHRoZSBkcmFm dCBkb2VzIG5vdCByZXF1ZXN0IGFueSBJQU5BIGFjdGlvbnMpLiBDYW4geW91IHBsZWFzZSBjbGFy aWZ5IHdoYXQgaXMgc28gc3BlY2lhbCBhYm91dCB0aGVzZSB2YWx1ZXM/Cjwvc3Bhbj48L3A+Cjwv ZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iIj4jQWhtZWQ6IFRoZXJlIGlzIG5vIHNpZ25pZmljYW5jZSB0byB0aGUgdmFsdWVzIGJ1dCB0 aGVyZSBpcyBhIHNpZ25pZmljYW5jZSB0byB0aGUgb3JkZXIgYW1vbmcgdGhlbS4gSSB3aWxsIG1v ZGlmeSB0aGUgdGV4dCB0byBjbGFyaWZ5IHRoYXQ8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMDBCMDUwIj5bW1Nhc2hhXV0gT0su Cjwvc3Bhbj48L2k+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IiI+ PGJyPgo8YnI+Cjxicj4KPGJyPgo8L3NwYW4+PC9wPgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDot MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5lLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWxzbyBkb3VidCB0aGF0IGNv bXBhcmlzb24gb2YgRkVDcyB0aGF0IHJlcHJlc2VudCBJUHY0IGFuZCBJUHY2IHByZWZpeCBTSURz IG1ha2VzIG11Y2ggc2Vuc2UgKGZvciBjb25mbGljdCByZXNvbHV0aW9uIG9yIGVsc2UpLCBiZWNh dXNlLCBhbW9uZyBvdGhlciB0aGluZ3MsIHRoZXJlIGFyZSB2YWxpZCBzY2VuYXJpb3MKIHdoZW4g YW4gSVB2NCAvMzIgcHJlZml4IGlzIGVtYmVkZGVkIGluIGFuIElQdjYgLzEyOCBvbmUuPC9zcGFu PjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSIiPiNBaG1lZDogQSBwcmVmaXgtU0lEIGlzIGFzc2lnbmVkIHRvIGEgcHJlZml4 LiBBbiBJUHY2IHByZWZpeCB0aGF0IGVtYmVkcyBhbiBJUHY0IHByZWZpeCBpcyBkaWZmZXJlbnQg ZnJvbSB0aGUgSVB2NCBwcmVmaXguIFRoZSBzcGVjaWZpY2F0aW9ucyBvZiBTUiBleHRlbnNpb25z IHRvIElTSVMsIE9TUEZ2MiwgT1NQRnYzLCBhbmQgQkdQIHRyZWF0IElQdjQgYW5kIElQdjYgcHJl Zml4ZXMKIHNlcGFyYXRlbHksIGluY2x1ZGluZyB0aGUgSVBWNiBwcmVmaXhlcyB3aXRoIGVtYmVk ZGVkIElQdjQgb25lcy4gQmVzaWRlcyBub3QgYWxsIElQdjYgcHJlZml4ZXMgZW1iZWQgSVB2NCBw cmVmaXggaW4gdGhlbS4gSGVuY2UgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gSVB2NCBhbmQgSVB2 NiBwcmVmaXhlcyBpcyBxdWl0ZSBjbGVhcgo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMDBCMDUwIj5bW1Nhc2hhXV0gTXkgY29u Y2VybiB3YXMgbWFpbmx5IGFib3V0IElQdjQtbWFwcGVkIElQdjYgYWRkcmVzc2VzLiBRdW90aW5n IGZyb20gUkZDIDQyOTE6PC9zcGFuPjwvaT48L2I+PC9wPgo8aDUgc3R5bGU9IiI+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQyOTEjc2VjdGlvbi0yLjUuNS4yIj48Yj48 c3BhbiBzdHlsZT0iIj4yLjUuNS4yPC9zcGFuPjwvYj48L2E+PGEgbmFtZT0ic2VjdGlvbi0yLjUu NS4yIj48L2E+PGI+PHNwYW4gc3R5bGU9IiI+LiZuYnNwOyBJUHY0LU1hcHBlZCBJUHY2IEFkZHJl c3M8L3NwYW4+PC9iPjwvaDU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNt OyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpu b3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAw MDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZuYnNwOyZuYnNwOyBBIHNlY29uZCB0eXBlIG9mIElQdjYgYWRkcmVzcyB0aGF0IGhvbGRzIGFu IGVtYmVkZGVkIElQdjQgYWRkcmVzcyBpczwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5v cm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgZGVmaW5l ZC4mbmJzcDsgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5UaGlzIGFkZHJlc3MgdHlw ZSBpcyB1c2VkIHRvIHJlcHJlc2VudCB0aGUgYWRkcmVzc2VzIG9mPC9zcGFuPjwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4w MDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 OyBiYWNrZ3JvdW5kOnllbGxvdyI+Jm5ic3A7Jm5ic3A7IElQdjQgbm9kZXMgYXMgSVB2NiBhZGRy ZXNzZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAiPkZyb20gbXkgUE9WIHRoaXMgbWVhbnMgdGhh dCBhIC8xMjggcHJlZml4IGFzc29jaWF0ZWQgd2l0aCBhbiBJUHY0LW1hcHBlZCBJUHY2IGFkZHJl c3MgYW5kIGEgLzMyIHByZWZpeCBhc3NvY2lhdGVkIHdpdGggdGhlIElQdjQgYWRkcmVzcyB0aGF0 IHdhcyBtYXBwZWQKIHRvIHRoaXMgSVB2NiBhZGRyZXNzIHJlcHJlc2VudCB0aGUgc2FtZSBlbnRp dHkuIFRoaXMgdW5kZXJzdGFuZGluZyBmdWxseSBtYXRjaGVzIHVzYWdlIG9mIElQdjQtbWFwcGVk IElQdjYgYWRkcmVzc2VzIGFzIEJHUCBOZXh0IEhvcHMgb2YgVlBOLUlQdjYgYWRkcmVzc2VzIGRl ZmluZWQgaW4gUkZDIDQ3OTguIEhvd2V2ZXIsIHRoZSBjb21wYXJpc29uIHJ1bGVzIHlvdSBoYXZl IGRlZmluZWQgd2lsbCB0cmVhdCB0aGVtIGFzIHR3byBkaWZmZXJlbnQKIHByZWZpeGVzLiAmbmJz cDtJIHdvbmRlciBpZiB0aGVzZSBydWxlcywgaW4gdGhlIGNhc2Ugb2YgYSBjb25mbGljdCwgY291 bGQgcmVzdWx0IGluIHByZWZlcnJpbmcgdGhlIElQdjYgcHJlZml4IHRvIGFuIElQdjQgb25lIGFu ZCB0aGVyZWZvcmUgbG9vc2luZyBNUExTIGNvbm5lY3Rpdml0eSBmb3IgdGhlIGluZ3Jlc3MgUEUg b2YgYSA2VlBFIHNlcnZpY2UgdG8gaXRzIGVncmVzcyBQRT88L3NwYW4+PC9pPjwvYj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAx cHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxiPjxpPjxzcGFuIHN0eWxlPSIiPiMjQWhtZWQ6IFRo ZSBiYXNpYyBNUExTIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBmb3JiaWQgYXNzaWduaW5nIGRpZmZl cmVudCBsYWJlbHMgdG8gdGhlIHNhbWUgcHJlZml4LCBub25ldGhlbGVzcyB0byBkaWZmZXJlbnQg cHJlZml4ZXMgYmVsb25naW5nIHRvIHRoZSBzYW1lIG5vZGUgb3IgdGhlIHNhbWUgaW50ZXJmYWNl IG9uIHRoZSBzYW1lIG5vZGUuIE9uZSBvZiB0aGUgZnVuZGFtZW50YWwgY29uY2VwdHMgb2YKIFNS LU1QTFMgaXMgdGhhdCB0aGUgc2FtZSBwcmVmaXgtU0lEIG11c3Qgbm90IGJlIGFzc2lnbmVkIHRv IHR3byBkaWZmZXJlbnQgcHJlZml4ZXMuIFNvIGZvciB0aGUgcGFydGljdWxhciBzY2VuYXJpbyBv ZiBlbWJlZGRpbmcgSVB2NCBpbiBJUHY2LCB0aGUgb3BlcmF0b3IgbXVzdCBhc3NpZ24gZGlmZmVy ZW50IFNJRHMgdG8gdGhlIElQdjQgYWRkcmVzcyBhbmQgdGhlIElQdjQtbWFwcGVkIElQdjYgYWRk cmVzcyB0aGF0IGVtYmVkcyBpdCwgb3RoZXJ3aXNlCiB0aGUgbGFiZWwgd2lsbCBiZSBzdWJqZWN0 IHRvIHRoZSBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gcmVzb2x1dGlvbjxicj4KPGJyPgo8YnI+ Cjxicj4KPC9zcGFuPjwvaT48L2I+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iIj48YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPGRpdj4KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmYuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+U2VjdGlvbiAy LjUuMSBkZWZpbmVzIDMgdHlwZXMgb2YgU1ItTVBMUyBGRUNzLCBidXQgSSBhbSBub3Qgc3VyZSBh bGwgU0lEIHR5cGVzIGRlZmluZWQgaW4gdGhlIFNlZ21lbnQgUm91dGluZyBBcmNoaXRlY3R1cmUg ZHJhZnQgY2FuIGJlIHVuYW1iaWd1b3VzbHkgbWFwcGVkIHRvIG9uZSBvZiB0aGVzZSB0eXBlcy4g UHJvYmxlbWF0aWMKIGV4YW1wbGVzIGluY2x1ZGUgYXQgbGVhc3QgdGhlIGZvbGxvd2luZzo8L3Nw YW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEw OC4wcHQ7IHRleHQtaW5kZW50Oi0xMDguMHB0Ij48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsK PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmkuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZu YnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+UGFyYWxsZWwgQWRqYWNlbmN5IFNJ RDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTA4LjBwdDsgdGV4dC1pbmRlbnQ6LTEwOC4wcHQiPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+aWkuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZu YnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+TWlycm9yIFNJRDwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPkV4cGxpY2l0IG1hcHBpbmcgb2YgU0lEIHR5cGVzIHRvIFNSLU1QTFMgRkVDIHR5 cGVzIHdvdWxkIGJlIG1vc3QgdXNlZnVsIElNTy4gSWYgc29tZSBTSUQgdHlwZXMgY2Fubm90IGJl IG1hcHBlZCB0byBTUi1NUExTIEZFQ3MsIHRoaXMgbXVzdCBiZSBleHBsaWNpdGx5CiBzdGF0ZWQg aW4gdGhlIGRyYWZ0Ljwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0 OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4jQWhtZWQ6IDxicj4KUGFyYWxsZWwgYWRqYWNlbmN5 IFNJRCBhcmUgaGFuZGxlZCBpbiB0aGUgdHlwZSAmcXVvdDsobmV4dC1ob3AsIG91dGdvaW5nIGlu dGVyZmFjZSkmcXVvdDsgPC9zcGFuPgo8L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3Jt YWwiPgo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMDBCMDUwIj5bW1Nhc2hhXV0gT0s8 L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNt OyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4KTWly cm9yIFNJRCBpcyBhIHR5cGUgb2YgYmluZGluZy1TSUQgYXMgbWVudGlvbmVkIGluIFNlY3Rpb24g NS4xIGluIHRoZSBTUiBhcmNoaXRlY3R1cmUgZHJhZnQgKGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy0xNSkuIEFsc28gYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi40IGRyYWZ0LWll dGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0xOCAoYWxzbyBzZWUgdGhlIGVxdWl2 YWxlbnQgaW4gdGhlIE9TUEZ2MiBhbmQgT1NQRnYzCiBkcmFmdCksIGEgYmluZGluZyBTSUQgaXMg aWRlbnRpZmllZCBieSBhIHByZWZpeC4gSGVuY2UgaXQgaXMgY292ZXJlZCBieSB0aGUgdHlwZSAm cXVvdDsoUHJlZml4LCBSb3V0aW5nIEluc3RhbmNlLCBUb3BvbG9neSwgQWxnb3JpdGhtKSZxdW90 Ozwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBj bTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmOyBjb2xvcjojMDBCMDUwIj5bW1Nhc2hhXV0gSSByZXNwZWN0ZnVsbHkgZGlz YWdyZWUuIFRoZXJlIGlzIGRlZmluaXRlbHkgbm8gbWVudGlvbiBvZiBBbGdvcml0aG0gaW4gdGhl IGRlZmluaXRpb24gb2YgdGhlIE1pcnJvciBTSUQuCjwvc3Bhbj48L2k+PC9iPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsg bGluZS1oZWlnaHQ6bm9ybWFsIj4KPGI+PGk+PHNwYW4gc3R5bGU9IiI+IyNBaG1lZDogPGJyPgpU aGUgbGFzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiAyIG9mIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy0xNCBzYXlzPC9zcGFuPjwvaT48L2I+PC9wPgo8cHJlPiZuYnNwOyZuYnNwOyBX ZSBjYWxsICZxdW90O01QTFMgQ29udHJvbCBQbGFuZSBDbGllbnQgKE1DQykmcXVvdDsgYW55IGNv bnRyb2wgcGxhbmUgZW50aXR5PC9wcmU+CjxwcmU+Jm5ic3A7Jm5ic3A7IGluc3RhbGxpbmcgZm9y d2FyZGluZyBlbnRyaWVzIGluIHRoZSBNUExTIGRhdGEgcGxhbmUuIDwvcHJlPgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5l LWhlaWdodDpub3JtYWwiPgo8Yj48aT48c3BhbiBzdHlsZT0iIj5UaGUgc2VudGVuY2Ugc3RhcnRp bmcgYXQgdGhlIDV0aCBsaW5lIG9mIHRoZSBmaXJzdCBidWxsZXQgb2YgU2VjdGlvbiAyLjUgb2Yg ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTE0IHNheXM8L3NwYW4+PC9pPjwvYj48 L3A+CjxwcmU+Rm9yIE1DQ3Mgd2hlcmUgdGhlICZxdW90O1RvcG9sb2d5JnF1b3Q7IGFuZC9vciAm cXVvdDtBbGdvcml0aG0mcXVvdDs8L3ByZT4KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZmllbGRzIGFyZSBub3QgZGVmaW5lZCwgdGhlIG51bWVyaWNhbCB2YWx1ZSBvZiB6ZXJv IE1VU1QgYmUgdXNlZDwvcHJlPgo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBm b3IgdGhlc2UgdHdvIGZpZWxkcy4gPC9wcmU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+Cjxi PjxpPjxzcGFuIHN0eWxlPSIiPklmIGEgYmluZGluZy1TSUQgaXMgZG93bmxvYWRlZCB0byB0aGUg Zm9yd2FyZGluZyBwbGFuZSwgdGhlbiBpdCBtdXN0IGJlIGFzc29jaWF0ZWQgd2l0aCBhbiBNQ0Mg YW5kIGhlbmNlIGl0IGVpdGhlciBoYXMgYW4gJnF1b3Q7YWxnb3JpdGhtJnF1b3Q7IG9yIHRoZSB2 YWx1ZSB6ZXJvIGlzIGFzc3VtZWQgZm9yIHRoZSAmcXVvdDthbGdvcml0aG0mcXVvdDsgZmllbGQu IElmIHRoZSBiaW5kaW5nLVNJRCBpcyBub3QgZG93bmxvYWRlZCB0byB0aGUgZm9yd2FyZGluZwog cGxhbmUsIHRoZW4gaXQgaXMgaXJyZWxldmFudCB0byB0aGUgZW50aXJlIGRyYWZ0IG5vdCBvbmx5 IHRvIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4KPGJyPgo8 YnI+Cjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBt YXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4KPGJyPgo8 YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJn aW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj42Ljwvc3Bhbj48c3BhbiBz dHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPk5v ZGUgU0lEcyBpbiBTUi1NUExTPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7 IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmEuPC9zcGFuPjxzcGFuIHN0 eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Tm9kZSBT SURzIGFyZSBleHBsaWNpdGx5IGRlZmluZWQgYW5kIGRpc2N1c3NlZCBpbiB0aGUgU2VnbWVudCBS b3V0aW5nIEFyY2hpdGVjdHVyZSBkcmFmdCBidXQgYXJlIG5vdCBtZW50aW9uZWQgZXZlbiBvbmNl IGluIHRoaXMgZHJhZnQ8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+Yi48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj5BRkFJSywgdGhlIGNvbW1vbiBpbXBsZW1lbnRhdGlvbiBwcmFjdGlj ZSB0b2RheSBpbmNsdWRlcyBhc3NpZ25tZW50IG9mIGF0IGxlYXN0IG9uZSBOb2RlIFNJRCB0byBl dmVyeSBub2RlIGluIHRoZSBTUi1NUExTIGRvbWFpbjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTgu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5jLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPklzIHRoZXJlIGEgcmVxdWlyZW1lbnQg dG8gYXNzaWduIGF0IGxlYXN0IG9uZSBOb2RlIFNJRCBwZXIge3JvdXRpbmcgaW5zdGFuY2UsIHRv cG9sb2d5LCBhbGdvcml0aG19IGluIFNSLU1QTFM/IElmIG5vdCwgY2FuIHRoZSBhdXRob3JzIGV4 cGxhaW4gZXhwZWN0ZWQgYmVoYXZpb3Igb2Ygc3VjaCBhIG5vZGU/IChTZWUgYWxzbwogbXkgY29t bWVudCBhYm91dCByb3V0aW5nIGluc3RhbmNlcyBiZWxvdykuPC9zcGFuPjwvcD4KPC9kaXY+Cjwv YmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdp bi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+I0FobWVkOiBBIE5vZGUt U0lEIGlzIGEgc3BlY2lhbCBjYXNlIG9mIHByZWZpeC1TSUQuIFNvIHRoZXJlIG5vdGhpbmcgc3Bl Y2lmaWMgYWJvdXQgaXQgZnJvbSB0aGUgTVBMUyBmb3J3YXJkaW5nIHBsYW5lIHBvaW50IG9mIHZp ZXcuIFNpbWlsYXJseSBmcm9tIGEgc3RhbmRhcmQgdHJhY2tzIGRyYWZ0IHBvaW50IG9mIHZpZXcs IHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50CiB0byBhc3NpZ24gYSBTSUQgdG8gZXZlcnkgcHJlZml4 IGp1c3QgbGlrZSB0aGVyZSBpcyBubyByZXF1aXJlbWVudCB0byBiaW5kIGV2ZXJ5IHByZWZpeCB0 byBhbiBMRFAgbGFiZWwuIENvbW1vbiBhbmQvb3IgcmVjb21tZW5kZWQgcHJhY3RpY2VzIG9yIGRl c2NyaXB0aW9uIG9mIGRlcGxveW1lbnQgc2NlbmFyaW9zIGFyZSBtb3JlIGJlZml0dGluZyB0byBC Q1Agb3IgaW5mb3JtYXRpb25hbCBkcmFmdHMuIFRoaXMgZHJhZnQgaXMgYSBzdGFuZGFyZHMKIHRy YWNrIGRyYWZ0PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+Cjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAiPltbU2FzaGFdXSBXZWxsLCB5b3Xi gJl2ZSBqdXN0IHNhaWQgdGhhdCBjb25mbGljdCByZXNvbHV0aW9uIHJ1bGVzIGFyZSBSRUNPTU1F TkRFRCwgYW5kIHRoaXMgaXMgcXVpdGUgY29tbW9uIGluIHRoZSBTdGFuZGFyZHMgVHJhY2sgUkZD cy4KPC9zcGFuPjwvaT48L2I+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8Yj48aT48 c3BhbiBzdHlsZT0iIj4jI0FobWVkOiBPSy4sIEkgdGhpbmsgd2UgYXJlIGluIGFncmVlbWVudCBo ZXJlOik8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+Cjxicj4KPGJyPgo8L3NwYW4+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBs aW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+CklmIGEge3JvdXRpbmcgaW5zdGFuY2UsIHRvcG9s b2d5LCBhbGdvcml0aG19IGlzIG5vdCBhc3NpZ25lZCBhIFNJRCwgdGhlbiB0aGlzIEZFQyBpcyB0 b3RhbGx5IGlycmVsYXZhbnQgdG8gdGhpcyBkcmFmdCBhbmQgaGVuY2UgZGVzY3JpYmluZyBob3cg YSBub2RlIHRyZWF0cyBpdCBpcyB0b3RhbGx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZHJh ZnQ8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTow Y207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjsgY29sb3I6IzAwQjA1MCI+W1tTYXNoYV1dIEFGQUlLLCBuZWl0aGVyIG9m IHRoZSBTUiBleHRlbnNpb24gZHJhZnRzIGZvciBJR1BzIG1lbnRpb24gcm91dGluZyBpbnN0YW5j ZXMgdGhhdCBjYW4gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBwcmVmaXgsIHNvIEkgdGhpbmsgdGhh dCB5b3VyIHJlZmVyZW5jZSB0byBpdCBpcyBpbmNvcnJlY3QuPC9zcGFuPjwvaT48L2I+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207IG1hcmdpbi1ib3R0 b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsg Y29sb3I6IzAwQjA1MCI+V2hhdOKAmXMgbW9yZSBJIHN1c3BlY3QgdGhhdCBOb2RlIFNJRHMgcmVw cmVzZW50IHRoZSBtb3N0IHVzZWQgc3BlY2lhbCBjYXNlIG9mIFByZWZpeCBTSURzIHdpdGggQW55 Y2FzdCBTSURzIGJlaW5nIHF1aXRlIGJlaGluZC4gJm5ic3A7VGhlcmVmb3JlIHNvbWUgcmVjb21t ZW5kYXRpb24gcGVydGFpbmluZyB0bwogdGhlIHVzYWdlIG9mIE5vZGUgU0lEcyB3b3VsZCBiZSB2 ZXJ5IG11Y2ggaW4gcGxhY2UgSU1ITy4gPC9zcGFuPjwvaT48L2I+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhl aWdodDpub3JtYWwiPgo8Yj48aT48c3BhbiBzdHlsZT0iIj4jI0FobWVkOiBUaGUmbmJzcDsgdGVy bSAmcXVvdDtyb3V0aW5nIGluc3RhbmNlJnF1b3Q7IHdpdGhpbiB0aGUgY29udGV4dCBvZiBpbmNv bWluZyBsYWJlbCBjb2xsaXNpb24gaXMgZGVmaW5lZCBpbiB0aGUgZmlyc3QgYnVsbGV0IGluIFNl Y3Rpb24gMi41Lgo8YnI+CkFzIGZvciBhbnkgcmVjb21tZW5kYXRpb24gZm9yIHVzZWFnZSBvZiBu b2RlLVNJRCwgYW55Y2FzdC1TSUQsLi4uLGV0YyAsIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2Yg dGhpcyBkcmFmdCBiZWNhdXNlIGl0IGlzIGEgbWF0dGVyIG9mIG9mIGRlcGxveW1lbnQvaW5mb3Jt YXRpb25hbC9CQ1AgZHJhZnQ8YnI+Cjxicj4KPGJyPgo8L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7 IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4KPGJyPgo8YnI+Cjxicj4KPC9zcGFuPjwvcD4K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7IG1hcmdpbi1ib3R0b206NS4wcHQi Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjcuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZu YnNwOyZuYnNwOwo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+U1JHQiBTaXplIGluIFNSLU1Q TFM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjoKPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5kZW50Oi0x OC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmEuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZu YnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGRyYWZ0IGNvcnJlY3RseSB0 cmVhdHMgdGhlIHNpdHVhdGlvbiB3aGVuIGFuIGluZGV4IGFzc2lnbmVkIHRvIHNvbWUgZ2xvYmFs IFNJRCBjYW5ub3QgYmUgbWFwcGVkIHRvIGEgbGFiZWwgdXNpbmcgdGhlIHByb2NlZHVyZSBpbiBT ZWN0aW9uIDIuNCBhcyBhIGNvbmZsaWN0Ljwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj5iLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJz cDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkF0IHRoZSBzYW1lIHRpbWUgdGhlIGRyYWZ0IGRv ZXMgbm90IGRlZmluZSBhbnkgbWluaW11bSBzaXplIG9mIFNSR0IgKGJlIGl0IGRlZmluZWQgYXMg YSBzaW5nbGUgY29udGlndW91cyBibG9jayBvciBhcyBhIHNlcXVlbmNlIG9mIHN1Y2ggYmxvY2tz KSB0aGF0IE1VU1QgYmUgaW1wbGVtZW50ZWQgYnkgYWxsIFNSLWNhcGFibGUKIG5vZGVzPC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmMuPC9zcGFuPjxzcGFu IHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SSBz dXNwZWN0IHRoYXQgbGFjayBvZiBzdWNoIGEgZGVmaW5pdGlvbiBjb3VsZCBiZSBkZXRyaW1lbnRh bCB0byBpbnRlcm9wZXJhYmlsaXR5IG9mIFNSLU1QTFMgc29sdXRpb25zLiBBRkFJSywgdGhlIElF VEYgaGFzIGJlZW4gZm9sbG93aW5nLCBmb3IgcXVpdGUgc29tZSB0aW1lLCBhIHBvbGljeSB0aGF0 IHNvbWUgcmVhc29uYWJsZQogTVVTVC10by1pbXBsZW1lbnQgZGVmYXVsdHMgc2hvdWxkIGJlIGFz c2lnbmVkIGZvciBhbGwgY29uZmlndXJhYmxlIHBhcmFtZXRlcnMgZXhhY3RseSBpbiBvcmRlciB0 byBwcmV2ZW50IHRoaXMuPC9zcGFuPjwvcD4KPC9kaXY+CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGlu ZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+I0FobWVkOiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cg dGhlIFNSR0IgaXMgdXNlZCBhbmQgdGhlIGJlaGF2aW9yIG9mIHJvdXRlcnMgd2hlbiBhIHByZWZp eC1TSUQgaW5kZXggbWFwcyB0byBhIGxhYmVsIGluc2lkZSBhbmQvb3Igb3V0c2lkZSB0aGUgU1JH Qi4gVGhlIGFjdHVhbCBzaXplIG9mIHRoZSBTUkdCIGlzIGEgdGFzayBpbiBwYXJ0aXRpb25pbmcK IHRoZSBsYWJlbCBzcGFjZSwgd2hpY2ggaXMgdmVyeSBzcGVjaWZpYyB0byBhIHBhcnRpY3VsYXIg ZGVwbG95bWVudCBzY2VuYXJpby4gU28gSU1PIGl0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIGEg c3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50LiBOb3cgdGhhdCBTUi1NUExTIGlzIGRlcGxveWVkIGlu IG1hbnkgcGxhY2VzLCBJIGV4cGVjdCB0aGUgY29tbXVuaXR5IHRvIGdhaW4gc3VmZmljaWVudCBl eHBlcmllbmNlIHRvIHJlY29tbWVuZCAob3Igbm90CiByZWNvbW1lbmQpIGEgcGFydGljdWxhciBt aW5pbXVtL21heGltdW0gc2l6ZSBmb3IgdGhlIFNSR0IgaXMgc29tZSBmdXR1cmUgaW5mb3JtYXRp b25hbCBvciBCQ1AgZHJhZnQvUkZDPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0 Om5vcm1hbCI+CjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAiPltbU2FzaGFd XSBNeSByZWFkaW5nIG9mIHlvdXIgcmVzcG9uc2UgaXMgdGhhdCBtaW5pbXVtIHNpemUgb2YgU1JH QiBpcyBhbiBpc3N1ZSBmb3IgZnV0dXJlIHN0dWR5LiBDYW4geW91IHBsZWFzZSBqdXN0IGFkZCB0 aGlzIHRvIHRoZSBkcmFmdD88L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5v cm1hbCI+CjxiPjxpPjxzcGFuIHN0eWxlPSIiPiMjQWhtZWQ6IE9LLiBBZGRlZCBhIHNlbnRlbmNl IHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDIuMzwvc3Bhbj48L2k+PC9iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxi cj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxi cj4KPGJyPgo8YnI+Cjxicj4KPC9zcGFuPjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7IG1hcmdpbi1ib3R0b206NS4wcHQiPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjgu PC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+QWxnb3JpdGhtcyBhbmQgUHJlZml4IFNJRHM8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPjo8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+YS48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgZHJhZnQgbWVudGlvbnMgQWxnb3JpdGhtcyAoYXMgcGFydCBvZiBT Ui1NUExTIFByZWZpeCBGRUMpIGluLCBidXQgaXQgZG9lcyBub3QgZXhwbGljaXRseSBsaW5rIHRo ZW0gd2l0aCB0aGUgUHJlZml4LVNJRCBhbGdvcml0aG1zIGRlZmluZWQgaW4gc2VjdGlvbiAzLjEu MSBvZiB0aGUgU2VnbWVudCBSb3V0aW5nIEFyY2hpdGVjdHVyZQogZHJhZnQ8L3NwYW4+PC9wPgo8 L2Rpdj4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBj bTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4jQWhtZWQ6 IEkgd2lsbCBqdXN0IGFkZCB0aGUgcmVmZXJlbmNlCjwvc3Bhbj48c3BhbiBzdHlsZT0iIj5bSS1E LmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ108L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+IHJpZ2h0IGJlc2lkZSB0aGUg Zmlyc3QgdGltZSAmcXVvdDtBbGdvcml0aG0mcXVvdDsgaXMgbWVudGlvbmVkPC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtOyBtYXJnaW4tYm90 dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 IGNvbG9yOiMxRjQ5N0QiPltbU2FzaGFdXSBPSzwvc3Bhbj48L2k+PC9iPjwvcD4KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGlu ZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPgo8YnI+Cjxicj4KPGJyPgo8L3NwYW4+PC9wPgo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+Cjxk aXY+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0 OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5iLjwvc3Bhbj48c3BhbiBz dHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb20g bXkgUE9WLCB0aGUgZHJhZnQgc2hvdWxkIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCB0aGUgZGVmYXVs dCBQcmVmaXgtU0lEIGFsZ29yaXRobSBNVVNUIGJlIGltcGxlbWVudGVkIGluIGFsbCBTUi1NUExT LWNvbXBsaWFudCByb3V0ZXJzLjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7 IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiNBaG1lZDogVGhlIHNwZWNpZmljYXRpb24gb2Ygd2hh dCBwYXRoIGNhbGN1bGF0aW9uIG1ldGhvZCBzaG91bGQgb3IgbXVzdCBiZSBzdXBwb3J0ZWQgaXMg YSByb3V0aW5nIHByb3RvY29sIHByb3BlcnR5IG5vdCBhIGZvcndhcmRpbmcgcGxhbmUgcHJvcGVy dHkuIEluIGZhY3QsIHRoZSBjaG9pY2Ugb2YgYSBwYXRoIGNhbGN1bGF0aW9uIG1ldGhvZCBvciBh bGdvcml0aG0KIGlzIGNvbXBsZXRlbHkgb3J0aG9nb25hbCB0byB0aGUgcm91dGVkIHByb3RvY29s LiBIZW5jZSBtYW5kYXRpbmcgdGhlIHN1cHBvcnQgb2YgYSBwYXJ0aWN1bGFyIHJvdXRpbmcgYWxn b3JpdGhtIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48L3NwYW4+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207IG1hcmdpbi1ib3R0 b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsg Y29sb3I6IzFGNDk3RCI+W1tTYXNoYV1dIE9LPC9zcGFuPjwvaT48L2I+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5l LWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRp dj4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7 IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmMuPC9zcGFuPjxzcGFuIHN0 eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhlIFNl Z21lbnQgUm91dGluZyBBcmNoaXRlY3R1cmUgZHJhZnQgc3RhdGVzIChpbiBzZWN0aW9uIDMuMS4z KSB0aGF0IOKAnFN1cHBvcnQgb2YgbXVsdGlwbGUgYWxnb3JpdGhtcyBhcHBsaWVzIHRvIFNSdjbi gJ0uIEJ1dCBuZWl0aGVyIGRyYWZ0IHN0YXRlcyB3aGV0aGVyIG11bHRpcGxlIGFsZ29yaXRobXMg YXBwbHkgdG8gU1ItTVBMUy4KIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkgdGhpcyBwb2ludD88L3Nw YW4+PC9wPgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij4jQWhtZWQ6IFRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDMuMS4yIHRpdGxlZCBTUi1N UExTIGluIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy0xNSBkaXNjdXNzZXMgdGhl IHN1cHBvcnQgb2YgbXVsdGlwbGUgYWxnb3JpdGhtcy4gU28gaXQgaXMgaW1wbGllZCB0aGF0IHRo ZSBjb25jZXB0IG9mIGFsZ29yaXRobSBhcHBsaWVzIHRvIFNSLU1QTFMuCiBIZW5jZSB0aGVyZSBp cyBubyBuZWVkIHRvIHJlLW1lbnRpb24gaXQgaGVyZTwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBs aW5lLWhlaWdodDpub3JtYWwiPgo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMDBCMDUw Ij5bW1Nhc2hhXV0gVGhlIHBhcmFncmFwaCB0byB3aGljaCB5b3UgcmVmZXIgb25seSBzYXlzIHRo YXQgaWYgYSBwYWNrZXQgd2l0aCB0aGUgYWN0aXZlIFByZWZpeC1TSUQgdGhhdCBpcyBhc3NvY2lh dGVkIHdpdGggYSBzcGVjaWZpYyBhbGdvcml0aG0gaXMgcmVjZWl2ZWQgYnkgYSBub2RlIHRoYXQg ZG9lcwogbm90IHN1cHBvcnQgdGhpcyBhbGdvcml0aG0sIHRoaXMgcGFja2V0IHdpbGwgYmUgZGlz Y2FyZGVkLiBJZiB0aGlzIGlzIHRoZSBvbmx5IHR5cGUgb2Ygc3VwcG9ydCBmb3IgbXVsdGlwbGUg YWxnb3JpdGhtcyBTUiBwcm92aWRlcywgaXQgaXMgbm90IHZlcnkgdXNlZnVsIElNSE88L3NwYW4+ PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4uCjwvc3Bhbj48 L2k+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdp bi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPGI+PGk+PHNwYW4gc3R5bGU9 IiI+IyNBaG1lZDogVGhlIFNSLU1QTFMgZHJhZnQgdGhhdCB3ZSBhcmUgZGlzY3Vzc2luZyBoZXJl IGRvZXMgbm90IGF0dGVtcHQgdG8gbW9kaWZ5IHRoZSBTUi1hcmNoaXRlY3R1cmUgZHJhZnQuIEFu eSBjb25jZXJucyByZWxhdGVkIHRvIHRoZSBTUi1hcmNoaXRlY3R1cmUgc2hvdWxkIGJlIGFkZHJl c3NlZCB0byB0aGUgU1ItYXJjaGl0ZWN0dXJlIGRyYWZ0IG5vdCB0byB0aGlzIGRyYWZ0Lgo8L3Nw YW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBt YXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4KPGJyPgo8 YnI+Cjxicj4KPC9zcGFuPjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 IG1hcmdpbi1ib3R0b206NS4wcHQiPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjkuPC9zcGFuPjxz cGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+Um91dGluZyBpbnN0YW5jZXMgYW5kIHRoZSBjb250ZXh0IGZvciBQcmVmaXgtU0lEczwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj5hLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJz cDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBTZWdtZW50IFJvdXRpbmcgQXJjaGl0ZWN0 dXJlIGRyYWZ0IHN0YXRlcyBpbiBTZWN0aW9uIDMuMSB0aGF0IHRoZSDigJxjb250ZXh0IGZvciBh biBJR1AtUHJlZml4IHNlZ21lbnQgaW5jbHVkZXMgdGhlIHByZWZpeCwgdG9wb2xvZ3ksIGFuZCBh bGdvcml0aG3igJ08L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+Yi48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGlzIGRyYWZ0IHNlZW1zIHRvIGRlZmluZSAoaW4gc2VjdGlvbiAyLjUp IHRoZSBjb250ZXh0IGZvciB0aGUgUHJlZml4IFNJRCBhcyDigJxQcmVmaXgsIFJvdXRpbmcgSW5z dGFuY2UsIFRvcG9sb2d5LCBBbGdvcml0aG3igJ0gd2hlcmUg4oCdYSByb3V0aW5nIGluc3RhbmNl IGlzIGlkZW50aWZpZWQgYnkgYSBzaW5nbGUgaW5jb21pbmcKIGxhYmVsIGRvd25sb2FkZXIgdG8g RklC4oCdIChidXQgdGhlIG5vdGlvbiBvZiB0aGUgbGFiZWwgZG93bmxvYWRlciB0byBGSUIgaXMg bm90IGRlZmluZWQpLjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5jLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoZXNlIHR3byBkZWZpbml0aW9ucyBsb29rIGRpZmZlcmVudCB0byBt ZS4KPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmQuPC9z cGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+QXQgdGhlIHZlcnkgbGVhc3QgSSB3b3VsZCBleHBlY3QgYWxpZ25tZW50IGJldHdlZW4g dGhlIGRlZmluaXRpb25zIG9mIGNvbnRleHQgZm9yIHRoZSBQcmVmaXgtU0lEIGJldHdlZW4gdGhl IHR3byBkcmFmdHMuIFByZWZlcmFibHksIHRoZSBkZWZpbml0aW9uIGdpdmVuIGluIHRoZSBTZWdt ZW50IFJvdXRpbmcgQXJjaGl0ZWN0dXJlCiBkcmFmdCBzaG91bGQgYmUgdXNlZCBpbiBib3RoIGRy YWZ0cy48L3NwYW4+PC9wPgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpu b3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4jQWhtZWQ6IFRoZSBjb250ZXh0IG9mIHRoZSBzZWN0aW9uIDIuNSBpcyBsaW1p dGVkIHRvIHRoZSByZXNvbHV0aW9uIG9mIGxvY2FsIGxhYmVsIGNvbGxpc2lvbi4gVGhlIHVzZSBv ZiAmcXVvdDtyb3V0aW5nIGluc3RhbmNlJnF1b3Q7IGluIHNlY3Rpb24gMi41IGlzIGp1c3QgdGhl cmUgZm9yIHRpZS1icmVha2luZyBpZiB0aGVyZSBpcyBsb2NhbCBsYWJlbCBjb2xsaXNpb24uPC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtOyBt YXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAiPltbU2FzaGFdXSBJIGhhdmUgYWxyZWFkeSBtZW50aW9u ZWQgdGhhdCDigJxyb3V0aW5nIGluc3RhbmNlc+KAnSBhcmUgbm90IGRlZmluZWQgaW4gYW55IHRo ZSBkcmFmdHMgZGVhbGluZyB3aXRoIFNSIEV4dGVuc2lvbnMgZm9yIElHUHMuIFNvIEkgZG8gbm90 IHVuZGVyc3RhbmQgaG93IHRoZSBjb25mbGljdAogcmVzb2x1dGlvbiBwcm9jZWR1cmUgaXMgc3Vw cG9zZWQgdG8gdXNlIHRoaXMuIEFuZCBpbiBhbnkgY2FzZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu IHR3byBkZWZpbml0aW9ucyBvZiB0aGUgY29udGV4dCBvZiBQcmVmaXgtU0lEIHJlcXVpcmVzIHNv bWUgZXhwbGFuYXRpb24uPC9zcGFuPjwvaT48L2I+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3Jt YWwiPgo8Yj48aT48c3BhbiBzdHlsZT0iIj4jI0FobWVkOiBpbmNvbWluZyBsYWJlbCBjb2xsaXNp b24gZGVmaW5lcyB3aGF0IGlzIGEgcm91dGluZyBpbnN0YW5jZSB3aXRoaW4gaXRzIGNvbnRleHQu IEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCBleHBsYW5hdGlvbiB5b3UgYXJlIGxvb2tpbmcgZm9y PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+PGJyPgo8YnI+Cjxicj4KPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1o ZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+PGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+Cjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4K PGRpdj4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4xMC48L3NwYW4+PHNwYW4gc3R5bGU9IiI+Cjwvc3Bhbj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmIj5FeGFtcGxlIG9mIFBVU0ggb3BlcmF0aW9uIGluIFNlY3Rpb24g Mi4xMC4xPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvcD4KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5kZW50 Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmEuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNw OyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGZpcnN0IHBhcmEgb2Yg dGhpcyBzZWN0aW9uIGJlZ2lucyB3aXRoIHRoZSBzZW50ZW5jZSDigJxTdXBwb3NlIGFuIE1DQyBv biBhIHJvdXRlciAmcXVvdDtSMCZxdW90OyBkZXRlcm1pbmVzIHRoYXQgUFVTSCBvciBDT05USU5V RSZuYnNwOyZuYnNwOyBvcGVyYXRpb24gaXMgdG8gYmUgYXBwbGllZCB0byBhbiBpbmNvbWluZyBw YWNrZXQgd2hvc2UgYWN0aXZlCiBTSUQgaXMgdGhlIGdsb2JhbCBTSUQgJnF1b3Q7U2kmcXVvdDvi gJ0uIEluIHRoZSBjb250ZXh0IG9mIFNSLU1QTFMgdGhpcyBtZWFucyAodG8gbWUpIHRoYXQgdGhl IGluY29taW5nIHBhY2tldCBpcyBhIGxhYmVsZWQgcGFja2V0IGFuZCBpdHMgdG9wIGxhYmVsIG1h dGNoZXMgdGhlIGdsb2JhbCBTSUQg4oCcU2nigJ0uCjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0LWluZGVudDotMTgu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5iLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkhvd2V2ZXIsIHRoZSBleGFtcGxlIGZv ciBQVVNIIG9wZXJhdGlvbiBpbiB0aGUgbmV4dCBwYXJhIG9mIHRoaXMgc2VjdGlvbiBpcyB0aGUg Y2FzZSBvZiBhbiAodW5sYWJlbGVkKSBJUCBwYWNrZXQgd2l0aCB0aGUgZGVzdGluYXRpb24gYWRk cmVzcyBjb3ZlcmVkIGJ5IHRoZSBJUCBwcmVmaXggZm9yIHdoaWNoIOKAnFNp4oCdIGhhcwogYmVl biBhc3NpZ25lZC4gPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDo3Mi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWYiPmMuPC9zcGFuPjxzcGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+RnJvbSBteSBQT1Y6PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0OyB0ZXh0LWluZGVudDotMTA4LjBw dCI+PHNwYW4gc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5p Ljwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPk1hcHBpbmcgdW5sYWJlbGVkIHBhY2tldHMgdG8gU0lEcyBpcyBpbmRlZWQgb3V0 IG9mIHNjb3BlIG9mIHRoZSBkcmFmdC4gVGhlcmVmb3JlIGFuIGV4YW1wbGUgb2YgYSBQVVNIIG9w ZXJhdGlvbiB0aGF0IGlzIGFwcGxpZWQgdG8gYSBsYWJlbGVkIHBhY2tldCAod2l0aCB0aGUgYWN0 aXZlIFNJRCBpbmZlcnJlZCBmcm9tIHRoZQogdG9wIGxhYmVsIGluIHRoZSBzdGFjaykgaXMgcHJl ZmVyYWJsZS48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEwOC4wcHQ7IHRleHQtaW5kZW50Oi0xMDguMHB0Ij48c3BhbiBzdHlsZT0iIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmlpLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4m bmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlZhbGlkIGV4YW1wbGVz IG9mJm5ic3A7IFBVU0ggb3BlcmF0aW9uIGFwcGxpZWQgdG8gYSBsYWJlbGVkIGluY29taW5nIHBh Y2tldCBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbnMgNC4yIG9yIDQuMyBvZiB0aGUKPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhc2hhbmR5LXJ0Z3dnLXNlZ21lbnQt cm91dGluZy10aS1sZmEtMDQiPgpUSS1MRkE8L2E+IGRyYWZ0PC9zcGFuPjwvcD4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvcD4KPC9kaXY+Cjwv YmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdp bi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+I0FobWVkOiBJIGRvIG5v dCB1bmRlcnN0YW5kIHlvdXIgY29uY2VybiBoZXJlOik8YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTsgbWFy Z2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmOyBjb2xvcjojMDBCMDUwIj5bW1Nhc2hhXV0gSSB0aGluayBpdCBpcyBwcmV0dHkgY2xl YXI6IGNhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIGEgUFVTSCBvcGVyYXRpb24gYXBwbGll ZCB0byBhIGxhYmVsZWQgcGFja2V0IGluc3RlYWQgb2YgeW91ciBjdXJyZW50IGV4YW1wbGU/PC9z cGFuPjwvaT48L2I+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsg bWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8Yj48aT48c3BhbiBz dHlsZT0iIj4jI0FobWVkOiBUaGUgZXhhbXBsZSBpbiB0aGUgZHJhZnQgaXMgaW5jbHVkZWQgdG8g Y2xhcmlmeSB0aGUgY29uY2VwdCBvZiBhIHByZWZpeCBTSUQgYXR0YWNoZWQgdG8gYSBwcmVmaXgu IEFzIG1lbnRpb25lZCBtb3JlIHRoYW4gb25jZSwgU1ItTVBMUyBkb2VzIG5vdCBtb2RpZnkgTVBM UyBmb3J3YXJkaW5nIGluY2x1ZGluZyBwdXNoaW5nIGEgbGFiZWwgb24gYSBsYWJlbGVkIHBhY2tl dC4gSXQgaXMgc29tZXRoaW5nCiB0aGF0IGhhcyBiZWVuIGRvbmUgYnkgcm91dGVycyBhbmQgc3dp dGNoZXMgZm9yIDIwJiM0MzsgeWVhcnMuIFNvIGluY2x1ZGluZyBpdCBoZXJlIGlzIHJlZHVuZGFu dDwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Tml0czwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj4KPC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjEuPC9zcGFuPjxz cGFuIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ SSBjb25jdXIgd2l0aCBBZHJpYW4gcmVnYXJkaW5nIG51bWVyb3VzIG5pdHMgaGUgaGFzIHJlcG9y dGVkIGluIGhpcwo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3NwcmluZy9GUmhPMmxnUjhyNFZsS1AyWk4yZFp3SFU1QlkiPgpXRyBMQyBDb21tZW50PC9hPi4g SSB3b3VsZCBsaWtlIHRvIHRoYW5rIEFkcmlhbiBmb3IgYW4gZXhjZWxsZW50IHJldmlldyB0aGF0 IGhhdmUgc2F2ZWQgbWUgbG90cyBvZiBoYXJkIHdvcmsuPC9zcGFuPjwvcD4KPC9kaXY+CjwvYmxv Y2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1i b3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+I0FobWVkOiBJIGFsc28gYWdy ZWUgdGhhdCBBZHJpYW4ncyByZXZpZXcgaXMgZXhjZXB0aW9uYWwuIEkgYmVsaWV2ZSBJIGFkZHJl c3NlZCBhbGwgaGlzIGNvbW1lbnRzIGluIHRoZSBsYXRlc3QgdmVyc2lvbi48YnI+Cjxicj4KPGJy Pgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0OyBt YXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4yLjwvc3Bhbj48c3Bh biBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPklu IGFkZGl0aW9uLCBJ4oCZZCBsaWtlIHRvIHJlcG9ydCB0aGUgZm9sbG93aW5nIG5pdHM6PC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmEuPC9zcGFuPjxzcGFu IHN0eWxlPSIiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGkt TEZBIGluIFNlY3Rpb24gMi4xMS4xIHNob3VsZCBiZSBUSS1MRkEgKGFzIGluIHRoZQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFzaGFuZHktcnRnd2ctc2VnbWVu dC1yb3V0aW5nLXRpLWxmYS0wNCI+ClRJLUxGQTwvYT4gZHJhZnQpPC9zcGFuPjwvcD4KPC9kaXY+ CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207IG1h cmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+I0FobWVkOiBBbHJl YWR5IGRvbmUgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uPC9zcGFuPjxiPjxpPltbU2FzaGFdXSBPSzwv aT48L2I+CjxzcGFuIHN0eWxlPSIiPjxicj4KPGJyPgo8YnI+Cjxicj4KPC9zcGFuPjwvcD4KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7IG1hcmdpbi1ib3R0b206NS4wcHQiPgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Yi48L3NwYW4+PHNwYW4g c3R5bGU9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5USS1M RkEgZHJhZnQgaXMgcmVmZXJlbmNlZCBpbiB0aGUgdGV4dCBvZiBTZWN0aW9uIDIuMTEuMSwgYnV0 IHRoZXJlIGlzIG5vIG1hdGNoaW5nIHJlZmVyZW5jZSBpbiB0aGUg4oCcUmVmZXJlbmNlc+KAnSBz ZWN0aW9uIChwcm9iYWJseSwgSW5mb3JtYXRpb25hbCk8L3NwYW4+PC9wPgo8L2Rpdj4KPC9ibG9j a3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJv dHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4jQWhtZWQ6IEFscmVhZHkgZG9u ZSBpbiB0aGUgbGF0ZXN0IHZlcnNpb248L3NwYW4+PGI+PGk+W1tTYXNoYV1dIE9LPC9pPjwvYj4K PHNwYW4gc3R5bGU9IiI+PGJyPgo8YnI+Cjxicj4KPGJyPgo8L3NwYW4+PC9wPgo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxkaXY+Cjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0OyB0ZXh0 LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5jLjwvc3Bhbj48c3BhbiBzdHlsZT0i Ij4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnHplcm8gQWxn b3JpdGht4oCdIGluIFNlY3Rpb24gMi41IChpbW1lZGlhdGVseSBhYm92ZSBTZWN0aW9uIDIuNS4x KSBtdXN0IGJlIHJlcGxhY2VkIHdpdGgg4oCcZGVmYXVsdCBhbGdvcml0aG3igJ0uIFNpbWlsYXJs eSwg4oCcbm9uLXplcm8gQWxnb3JpdGht4oCdIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIOKAnG5v bi1kZWZhdWx0IGFsZ29yaXRobeKAnTwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAx cHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiNBaG1lZDogV2lsbCBiZSBkb25lIGluIHRoZSBu ZXh0IHZlcnNpb248L3NwYW4+PGI+PGk+W1tTYXNoYV1dCjwvaT48L2I+Jm5ic3A7T0s8c3BhbiBz dHlsZT0iIj48YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhhdCBSRkMgMzQ0MyBhbmQgUkZDIDUzMzIgc2hv dWxkIGJlIGxpc3RlZCBhcyBOb3JtYXRpdmUgcmVmZXJlbmNlcyBpbiB0aGlzIGRyYWZ0IHdoaWxl IFJGQyA1MzMxIGFuZCBSRkMgODI3NyBzaG91bGQgYmUgbGlzdGVkIGFzIEluZm9ybWF0aXZlIHJl ZmVyZW5jZXMuIFRoaXMgd291bGQgaW1wcm92ZSB0aGUKIHJlYWRhYmlsaXR5IG9mIHRoZSBkcmFm dCB3aXRob3V0IGFueSBpbXBhY3Qgb24gaXRzIGFkdmFuY2VtZW50LiA8L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxp bmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPiNBaG1lZCBSRkM1MzMxIGRlc2NyaWJlcyB1cHN0cmVhbSBs YWJlbCBhc3NpZ25tZW50LiBBcyB5b3UgbWVudGlvbmVkIGFib3ZlIChhbmQgSSB3aWxsIG1vZGlm eSB0aGUgZHJhZnQgdG8gaW5kaWNhdGUgdGhhdCkgU1ItTVBMUyBiZWhhdmlvciBpcyBzaW1pbGFy IHRvIGRvd25zdHJlYW0gbGFiZWwgYXNzaWdubWVudC4gUkZDIDM0NDMgZGVzY3JpYmVzIFRUTCBi ZWhhdmlvci4KIFRoaXMgaXMgYW4gTVBMUyBmb3J3YXJkaW5nIGJlaGF2aW9yLiBBcyBtZW50aW9u ZWQgaW4gdGhlIGRyYWZ0LCBTUi1NUExTIGRvZXMgbm90IG1vZGlmeSBhdCB0aGUgTVBMUyBmb3J3 YXJkaW5nIGJlaGF2aW9yPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1h bCI+CjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMwMEIwNTAiPltbU2FzaGFdXSBSZWdh cmRpbmcgUkZDIDUzMzEg4oCTIHlvdSBtYXkgc2tpcCB0aGlzIHJlZmVyZW5jZSBpZiB5b3Ugc3Rh dGUgKGFzIGRpc2N1c3NlZCBiZWxvdykgdGhhdCBTUi1NUExTIG9ubHkgYWxsb2NhdGVzIGxhYmVs cyBmcm9tIHRoZSBwZXItcGxhdGZvcm0gbGFiZWwgc3BhY2UuIFJlZ2FyZGluZwogUkZDIDM0NDMg 4oCTIEkgZG8gbm90IHRoaW5rIHRoYXQgeW91IGNhbiBmdWxseSBhdm9pZCBkaXNjdXNzaW9uIG9m IFVuaWZvcm0gYW5kIFBpcGUvU2hvcnQgUGlwZSBtb2RlbHMsIGFuZCB0aGVyZWZvcmUgeW91IHdp bGwgbmVlZCB0aGlzIHJlZmVyZW5jZS48L3NwYW4+PC9pPjwvYj48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVp Z2h0Om5vcm1hbCI+CjxiPjxpPjxzcGFuIHN0eWxlPSIiPiMjQWhtZWQ6IEkgZGlkIG5vdCBhZGQg cmZjNTMzMSBhcyBhIHJlZmVyZW5jZSAuIEFnYWluIHB1c2hpbmcgbXVsdGlwbGUgbGFiZWxzIG9u IHRvcCBvZiBhIHBhY2tldCBpcyBhIG1hdHRlciBvZiBTUi1wb2xpY3ksIHdoaWNoIGlzIGhhbmRs ZWQgaW4gYSBzZXBhcmF0ZSBkcmFmdC4KPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9IiI+PGJy Pgo8YnI+Cjxicj4KPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9ybWFsIj4KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJy Pgo8YnI+Cjxicj4KPGJyPgo8YnI+Cjwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0OyBtYXJnaW4tYm90dG9tOjUuMHB0Ij4KPGRpdj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SG9wZWZ1bGx5LCB0aGVzZSBjb21tZW50cyB3aWxsIGJlIHVzZWZ1bC48L3A+CjwvZGl2 Pgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtOyBt YXJnaW4tYm90dG9tOi4wMDAxcHQ7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+CjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiNBaG1lZDogVGhl eSBhcmUgY2VydGFpbmx5IHF1aXRlIHVzZWZ1bC4gVGhhbmtzIGEgbG90PGJyPgo8YnI+Cjxicj4K PGJyPgo8L3NwYW4+PC9wPgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFy Z2luLWJvdHRvbTo1LjBwdCI+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNh c2hhPC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9mZmljZTogJiM0Mzs5NzItMzkyNjYzMDI8L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNl bGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RW1haWw6Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb208L2E+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+CjwvZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAw MXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnIgY2xlYXI9ImFsbCI+Cl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4KPGJyPgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUg cmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzCjxicj4KQ09O RklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMKPGJyPgp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFz ZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUg b3JpZ2luYWwKPGJyPgphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjwvcD4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOjBjbTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBj bTsgbWFyZ2luLWJvdHRvbTouMDAwMXB0OyBsaW5lLWhlaWdodDpub3JtYWwiPgo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnIgY2xl YXI9ImFsbCI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KPGJyPgpUaGlzIGUtbWFpbCBtZXNzYWdl IGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHdoaWNoIGlzCjxicj4KQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRh cnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMKPGJyPgp0cmFuc21p c3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgs IGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwKPGJyPgphbmQgYWxsIGNvcGllcyB0aGVyZW9m Ljxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjowY207IG1hcmdpbi1ib3R0b206LjAwMDFwdDsgbGluZS1oZWlnaHQ6bm9y bWFsIj4KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvcD4KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9wcmU+CjxwcmU+Jm5ic3A7 PC9wcmU+CjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jPC9wcmU+CjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8L3ByZT4KPHByZT5hIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvcHJlPgo8 cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3ByZT4KPHByZT4mbmJzcDs8 L3ByZT4KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3OzwvcHJlPgo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvcHJlPgo8cHJlPklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvcHJlPgo8cHJlPkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48L3ByZT4KPHBy ZT5UaGFuayB5b3UuPC9wcmU+CjwvZGl2Pgo8YnIgY2xlYXI9ImFsbCI+Cl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4KPGJyPgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVj aXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzCjxicj4KQ09ORklE RU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMKPGJyPgp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3Jp Z2luYWwKPGJyPgphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPgo8L2Jsb2NrcXVvdGU+Cjxicj4KPC9kaXY+CjxiciBjbGVhcj0iYm90aCI+Cl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxCUj4KPEJSPgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0 aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIDxCUj4K Q09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20u IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgPEJSPgp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBs ZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0 aGUgb3JpZ2luYWwgPEJSPgphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxCUj4KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPEJSPgo8L2JvZHk+CjwvaHRtbD4KCg== --_000_DB5PR0301MB190941EA048FE7B26F8E96639DF20DB5PR0301MB1909_-- From nobody Sun Oct 28 08:35:33 2018 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 75C7A127333 for ; Sun, 28 Oct 2018 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 PxGb3LKELxY6 for ; Sun, 28 Oct 2018 08:35:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CEE124D68 for ; Sun, 28 Oct 2018 08:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=89081; q=dns/txt; s=iport; t=1540740929; x=1541950529; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MIb4dkB9t/WrHYPDgAm2pkPkRevPfybnjwE0s7fSLsY=; b=ZgUbYMfWKbR4BwMwS0IhYggqLN24Ed5dKRZm9zvDuwIkfjiM6W4aoOb7 PQSqfhueRyj3OzFIl0Pc2gXC4k/dzEg+jwPdDAuM+Qja2GdcAEf7Z3LQI KOAbQBwgswLPYQHy3dy+t1n1idLb+Bh7CFlViPHcDWtYMek3d5tD3H+Xj I=; X-Files: image001.png, image002.gif : 45993, 134 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC51dVb/4YNJK1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENd2Z/KAqMA4wVgg2IOY5nFIEQA1M?= =?us-ascii?q?IAQIBASOESQKDGCE0DQ0BAwEBAgEBAm0cDIU6AQEBBAUBHwIGATYCExACAQg?= =?us-ascii?q?RBAEBBgEBARgHBwIFEAYJDBQJCAEBBAENBAEIBoJdN4IBD6UggX8eM4oCD4p?= =?us-ascii?q?KgR0XggAmagGCQiIugxALAQEBgSMKARIBByQLCgUGCggJhRQCiF4BGYVSY4U?= =?us-ascii?q?/g2mBLQE2g06BAgkChgMBZId1K4FyIIFSTIQriFaBKIdNjygCERSBJh04NDB?= =?us-ascii?q?xcBU7gmwJgh0Xg0hzhCGFPm8BigoNF4EIgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,436,1534809600"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="462202949" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2018 15:35:27 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9SFZQPt013026 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 28 Oct 2018 15:35:27 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 28 Oct 2018 10:35:26 -0500 Received: from xch-aln-011.cisco.com ([173.36.7.21]) by XCH-ALN-011.cisco.com ([173.36.7.21]) with mapi id 15.00.1395.000; Sun, 28 Oct 2018 10:35:26 -0500 From: "Siva Sivabalan (msiva)" To: "bruno.decraene@orange.com" , "spring@ietf.org" CC: "pamattes@microsoft.com" , "Alex Bogdanov (bogdanov@google.com)" , "Clarence Filsfils (cfilsfil)" , "Voyer, Daniel" Thread-Topic: New version of SR policy draft Thread-Index: AdRqQnbjsUeXKJSnQVaEXVM/NGjF7ABXk2FwAMyw7MA= Date: Sun, 28 Oct 2018 15:35:26 +0000 Message-ID: <597c3199271343c380f5f66e601c969b@XCH-ALN-011.cisco.com> References: <397b0297a95b4b659553cbc27b9cbd18@XCH-ALN-011.cisco.com> <25221_1540389247_5BD0797F_25221_242_1_53C29892C857584299CBF5D05346208A47F65A26@OPEXCNORM2F.corporate.adroot.infra.ftgroup> In-Reply-To: <25221_1540389247_5BD0797F_25221_242_1_53C29892C857584299CBF5D05346208A47F65A26@OPEXCNORM2F.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.251.201] Content-Type: multipart/related; boundary="_005_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] New version of SR policy draft X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 15:35:32 -0000 --_005_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_ Content-Type: multipart/alternative; boundary="_000_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_" --_000_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi SPRING-WG: Here are the high-level changes included in version 2 of the SR policy draf= t. * Removed the text on packet replication as this aspect is handled i= n "draft-voyer-spring-sr-p2mp-policy-xx" * Updated the tie-breaker rules under section 2.9 such that the rule= includes a configurable option. Also, the override option specified in the= previous version has been removed to make the behavior deterministic. * Mandated the use of only the active candidate path in Section 2.11= . * Added text to provide clarity on SR-DB in Section 3. * Mandated the generation of alert message when specified BSID is no= t available in Section 6.2. * Specified options for path protection in Section 9.3. * Cosmetic changes, e.g., SID-List --> Segment-List. Additional review and comments are appreciated. Thanks, Siva [banner12] Siva Sivabalan PRINCIPAL ENGINEER.ENGINEERING msiva@cisco.com Tel: +1 613 254 3782 Cisco Systems, Inc. 2000 Innovation Drive KANATA K2K 3E8 Canada cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before y= ou print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: bruno.decraene@orange.com Sent: Wednesday, October 24, 2018 9:54 AM To: Siva Sivabalan (msiva) Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com) ; Clarence Filsfils (cfilsfil) ; Voyer, Danie= l ; spring@ietf.org Subject: RE: New version of SR policy draft Hi Siva, Thanks for the updated draft. May be providing a high level description of the changes would help getting= review and comments on the document. Thanks, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Siva Sivabalan (= msiva) Sent: Monday, October 22, 2018 10:10 PM To: spring@ietf.org Cc: pamattes@microsoft.com; Alex Bogdanov (b= ogdanov@google.com); Clarence Filsfils (cfilsfi= l); Voyer, Daniel Subject: [spring] New version of SR policy draft Hi All, We have posted a new version of SR policy draft: https://www.ietf.org/id/draft-ietf-spring-segment-routing-policy-02.txt Additional reviews and comments will be appreciated. Thanks, Siva ___________________________________________________________________________= ______________________________________________ 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_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi SPRING-WG:

Here are the high= -level changes included in version 2 of the SR policy draft.

·    &n= bsp;   Removed the text on pack= et replication as this aspect is handled in “draft-voyer-spring-sr-p2mp-policy-xx”

·    &n= bsp;   Updated the tie-breaker = rules under section 2.9 such that the rule includes a configurable option. = Also, the override option specified in the previous version has been removed to make the behavior deterministic.

·    &n= bsp;   Mandated the use of only= the active candidate path in Section 2.11.

·    &n= bsp;   Added text to provide cl= arity on SR-DB in Section 3.<= /span>

·    &n= bsp;   Mandated the generation = of alert message when specified BSID is not available in Section 6.2.

·    &n= bsp;   Specified options for pa= th protection in Section 9.3.=

·        Cosmetic ch= anges, e.g., SID-List à Segment-List.

 

Additional review a= nd comments are appreciated.

 

Thanks,<= /span>

Siva

 

3D"banner12"

 

Siva Sivabalan

PRINCIPAL ENGINEER.ENGINEERING

msiva@cisco.com

Tel: +1 613 254 3782

Cisco Systems, Inc.=

2000 Innovation Drive
KANATA
K2K 3E8
Canada
cisco.com

&= nbsp;

3D"http://www.cisco.com/assets/swa/img/=Think before you print.

This email may contain confidential and = privileged material for the sole use of the intended recipient. Any review,= use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized = to receive for the recipient), please contact the sender by reply email and= delete all copies of this message.

Please click here for Company Registratio= n Information.

 

From: bruno.decraene@orange.com <bruno.dec= raene@orange.com>
Sent: Wednesday, October 24, 2018 9:54 AM
To: Siva Sivabalan (msiva) <msiva@cisco.com>
Cc: pamattes@microsoft.com; Alex Bogdanov (bogdanov@google.com) <= bogdanov@google.com>; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.co= m>; Voyer, Daniel <daniel.voyer@bell.ca>; spring@ietf.org
Subject: RE: New version of SR policy draft

 

Hi Siva,

 

Thanks for the updated draft.<= /span>

May be providing a high level description= of the changes would help getting review and comments on the document.

 

Thanks,

--Bruno

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Siva Sivabalan (msiva)
Sent: Monday, October 22, 2018 10:10 PM
To: spring@ietf.org
Cc: pamattes@microsoft.com= ; Alex Bogdanov (bogdanov@google= .com); Clarence Filsfils (cfilsfil); Voyer, Daniel
Subject: [spring] New version of SR policy draft

 

Hi All,

 

We have posted a new version of SR policy draft:

 

https://www.ietf.org/id/draft-ietf-spring-s= egment-routing-policy-02.txt

 

Additional reviews and comments will be appreciated.=

 

Thanks,

Siva

____________________________________________________=
_____________________________________________________________________<=
/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_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_-- --_005_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=45993; creation-date="Sun, 28 Oct 2018 15:35:25 GMT"; modification-date="Sun, 28 Oct 2018 15:35:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAh8AAABGCAIAAADjIWGQAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAA2hpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0 NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1N Ok9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDpDMUM5NDYyMkNDMjA2ODExOEY2MkY3QTkyOUE0 QUI4OSIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDo5M0Q5MzZGRTI4QTExMUU1QTE1QkZENEY0 MTMxOUU0NiIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo5M0Q5MzZGRDI4QTExMUU1QTE1QkZE NEY0MTMxOUU0NiIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M2IChNYWNpbnRv c2gpIj4gPHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6MDY4MDEx NzQwNzIwNjgxMTgwODNFOEVCQ0EyNjU1Q0MiIHN0UmVmOmRvY3VtZW50SUQ9InhtcC5kaWQ6OEI1 Nzg1MjlBNzI0MTFFMzg2MDZEMEU2QkY4MzAzMDMiLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRm OlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz5rdg3dAACv10lEQVR42nS9WbBk 13Uldva5NzPfUPOIoYBCFeaZAEQREEVSQ0tmU1a3ZavdYckK2R9yqz86wp/+cUR/doQ/Hf3hH0e7 O2y32221w1KLIkWKEwQSxIxCFVCoQs3z/Gp672Xee7bP2dPZNx9VIIFX+TJv3uGcPay99trtj978 OJQ/QP+ElBJiiBEw/8mvAgQM5aWAADG/oU8pv5zfkN+OmH/Ovy/vKp/NH8xvL2/OL+aDRP0LYnlL ORwmBH1P08T8XywHLL/PB019yl8S6VvzYctBoHxL/ktDX1k+SEfKx2oa4OOUL0rIJ5LPo3y8nDqf tp5cPrfy2fLGRKfDXwLyLfQ2Og36KPJX0Efzp5ryYvmylC+9fCryOYRyanxKdJ1NeR30doZyp+S+ 8n2Ahs40Il0X3Y9Ab6Pf5+PEJkDC1NOFN3Qbg5yqHDi/M9+h/GJKPV9feVaBLoXeS/cEI93GoM+I zoN+JVcWer5bfAfpgfXlRpSnyLcglPfSGii3OuZ1Efj+o3xNKqslnwy0+ddQbmosZ0PfRTeFvpmf d7mEfNz8fr47iH2M8qDodPgL6R7JdQZaB+WLyjONEfQmYbCT5hOXzyZ6HHzi/AZ6sTyEppxWuQG0 dpp8JpHWXU/XlM8xQbmW/L8mr6pyVmUflKXSo6wiOhry+wPwzc3/7bq+z4sW5CKaRpZ94KXLa5VO KOkyjrTaYtlEQX+bepSfE8o30gYpdxbRLidfXaS3Y92eukYaXZP5Ndqk5Unky9BnKPtGVwgv7LIE 6jYpDzQ0bRw1TeRVNfxjW0PuOYL7TcD6o/8I73f5mfco/1XuDQ4Ob9YD/JHkCtSO4MZT40fj/1ZP gJ7c4JQCgjtf+Yd3GT0rWYToT8GfKPKpBH0IwH/Nx6DnItZu+BH5WRaS2M35X9qZ6VXKK6nea7Db qB8GuUNiJlAWKtgT5B0op1Z+sutH23VoxoDW/3CDmYmTTShXh/wQ9W6ohar2vp12fD/L59mp5OXf d2jXQg4AIy3esuEglo2SEtAuKa+V3wL7iZ5NIX1F1/HK1j1AmyLS7iK7U3amWxH5izpdJvnYUQ7G ZwBihEEspuxeWXFsmKNYRIjyaHj1AvmDRH9nJ2I3UW+DX2/qXegovBMjdPWm6kmwjQj1tqtBobXV 0FXqu+V8+Ff896aYTDofZI9VTGAxB+WHpuVHHslJZ+OVX5clJKa73M3It4RMTiiLplgS4C1K5izI v+UmIi9KXkd85+h58mLiiyqfjshOk5dpMcE9JJT9ksRf8kW15CHIIJaz68g69km2pzwaOWM1ieLt s+nk70iyPtjjymMD9lsB7CHyfZOnEvgbg/g6erryJFBDB6A4g31il5eWGrOU/2YPDlGdvDzeWd+B 2oByaYm/SBYoe+7ygV6sUT6l7FzVg2Df52WPtvPBLCjIbi9v6On7KRYjw8GPSAIO1DChRAB9yu+X wAQ5YqNwpHhDCRdsU6eEodreyBsuaEgXJTiTU6oRUFl3+r0QxuPsWJoYB27D/tCr0V6M4D2Keo2h W6C1hhHUQUjcEOy2Rg2OxAny6fkdyneHQkENLNXE6BdqkGVOzE4Y7LzlZTEDwZyRPm6wE6773KLC oR/QeDVwbCqrAiHxhgxqb6pbDfIj70dxXXwT9H6xuwa9G3I6yV1vCXqgBjr2BWrDUlLXVMNARL3w hPKcE1Q3YREAn7y7f+D9dHVE5vv4NXmy5tDUMfM+zlsjQl+8QDFl9AvgBy/WkT6Twxk+W94AtMDE qNKqFctLbyu2JtLG7qsXl1XTk5Eqy7yJamiQwl213hqll/82TdlFFCWXkE3MUNnw+Ys4i4qU6WRX lyPOct+S+PQS/NOT8QaLTB89uFhcUUIxTOUQGuIA5W3mmTk06PIXxeIwkHI7ejf0PfkCxJbMpBlo OuFySzt9JJLORFkKvJ2yDcOes5uSUJXTnoWu73Tfkt2h20dBbh98ZBY0WUpydPIW1U8ENIscOdYp MSyojUK5TF3BsidKtqTeUR1xif2zuckPLhvN/EZNJyiNK4ftbO1xxsDxeEpBAzpOByV/4TiMlhZ0 06RRjgStelFobpmyTHZCEg7yCZfgw+0rSSVTebK6N2sYUaMkZ/tolbILFMvPgUVQ52QhCKid4U3B q5++AjWfADsZTUlrThCjCwkx6JUgtJGvtC35ao1zNKihrVuCtpKj82EjRD33xswHrfaUl6jL/6pX 4zuj8VX5fTejLwJQXx9iFG+cH3QxB9U30sqiI7ZtU5woObycrZErsywGwsCaY6jZiZobzXRsydnj BJdGWWKNg0AOh25gcJ0bnB9wGG6GU0w5OGeCLgnTuyiGWn2LOJWBER5mZD4TCRaVgl07Z7AKheht Ao2Awd+6mujUVWo5WzXzKeiH1a3IZk/2s+bCurDt6OwD1BhaOqerzrKOoTNUTyMReA0XQNPhxDm7 e1ySzvGyKdl6Wb5NKn9KjIMC+RSbTt9Tdq2FAbwNIuNOEDQ4JtiBziZK2Eo5WOSQQz5X8h8Oi+k8 WlBvjRoSyWclOqBbk/LHOMbm5zhqy2FzUDdqOUDDtpUQuSkZT7FHseFrjfJUaM9IhFFAg1BMKzkY fqZqnbKriIZEdTl5ym9sgG1+YtCwbGYk5xRAtxMDYrRny5f2HL8ThJi/r08SyGQvkd8Z6SZH9ql0 Uqm8qYAZSVIGWX3qt+XnUDEN0DjaLQy1UDUsdVE8H5YeLlIkC5rRJ3axSQAo0EWO5mAsbGeg0ja9 ODOsL9AXF2SIvod9OWhQove/hkY+jy5fzSYLBNOjE+abGhWEIRfAjxUQzSI07FTo2OrgJRsPA5CT vDkF8S3laRHAgmYNbxokTyzfAkPbJX6dI7C8zBq6nUkdp+VVWAFC2i4MjIE6J4qoJMwDdXJyJ6PY 95L+loWVTX6M7HPBTOI8SpP/29M642Qo9WyDZMsQWoC0NyM21aCwxyrnRwkLL99h1gLjcZvP6cr1 G+cvXFm9v7rvob07dmzdsmmp69Ns1ulJwxyYVQ8zNDwwZzTNQwYD+visatRsps1MsWZIto7AZcmG lCiIBAYnDYFUlypplOC9moZi6jHUHYDDAdHlV3Ij5EzQg30D6BDV/gt4XjERqKlghXzEu1OOXZBl ATDFxQAH1PJxDNU10Vlo3UJuB5rrVt+DUL2aAW6aDwTZMOY/B3AfWGbmL04TF/HmtHJL7FyeaI9S UyGYouJwfIf4cw07DPYiNcQLBkbRx8v/OIzlZWGxjrt6LrXw9khQ80UwoIJ+QHA3KEjCQRedkgOe 5PbmbVvwELLsEjhjVJgHxHJpikOgNlu3cq6RwwN2P5KUlV/nwI2ta8N4O73eRFl4xS3EiGjPK5EH SYx4sbkt0SYFnrwsivvJLgsEe2FYQ58uEHBfYx1KtgTsA8vcyzOhpE1LQwbOYrA8hrPvpBfIFqbc iD5htWdBqhocU2iwTpBXSgYKSJlEMzqymKFm9LJ/S54XevlQcWa0/MW46arUcIXBHKnViZGvoEHi s2KPSxmPPDpka25YC9cqkiFs4rx5w0S9D1IuoUIUxFgjRbtAw/40JKouOVU8umDCgbNdMODXanuS p0uYFbWmAzVuMog0SMpV3qDPLRI6nb0KlWfiZDLKP9+7d//e+nRhMs5/uq7Lb1pcmDDCktde6hlx RA4LkcKZ7EKSRgSowawAYeoJoCRF7Mx4sYthTRqHj0fjfLyTZ87/4K33z1y4unJnLX/7qG22bdn0 4jMHvvLqcw/t3VWqTn2vSYmPg8EZeC1kWr6iqL93QvVHNKgK612FDRWVmnBiNXWKb4cwwHc0awIE tKSmmnK241xJ9h93GY4VIFzBBAw3QkEFvBHXzFKTBrXOmmZgdS2yYsCcqnhPq6CIo+R1iwYKY80q 0BeecJBiMWgbqj2xWA2tEBDqCvfOOVhZRW+hJYGGGCe6WLaWvXyco/wAP3rzoz6hotnlC7pS14Wm 1ShMyn0JwG5CCXOwTxocSQKSGJGg7+EQjML9coSewCUgsytQhhlQNotQrRtfpFg68R1aojK7olAW WZwCT5XvClaOqyCmB8HlPKloFMyeSbQfqeafYpBAGLTEESz+p6dsJRxel1hwuZIrlW2mZSdLFDTN RD5sIqPJkCtFponDk8jeTcrqfOH6ZkPdQC2yq82y9eSnQywJVI+ALnV3cTf6SE3eFdWfVyYHosFH inFZ4SWKP0hqSiWQCmx5YQiMVPDLhz+1GAi8TsREgwVrWEt4XJUx/FKjTtR6mS9EKm6P+sSwBmN6 XVTVI99TlkEyaMKsI8cHdrZ05orFBb/F9EFLtg3sSyie6DWSK7lpY5ZFw2ZFz5JAHTlJbrjmEciv TPKRT5w698nRk0ePn1lbny0sTDYtL66vz7JPePqJR+/eW3v44T0P792xeXk5O54Fen+p65RqZcyx S2L3khJaTcPSKaJpaBypDAVnmUY5XWri+UuXf/r2hz//8Fip9I9GvNHoK3BtfTpp4e997ZVf/+qr SwvjfHrgCvvg7JpLrxHDXHW9vrkG8EMoCjegUTj4qLcNYviDW+Ebv3aQ9gUDmHRR6ipyAJJ9RZrj DBg6KsVLO9RGaoNRf9y3W/nEmbRKHdlw7uB4BL/oBhqOT3GVewyoxaHBSTk3ok5Dr1niKseUELDE 2RF+QxSzL1QXdFmO7M0fvXmoL7UHZJibXWtZ4mWNJqa92LHUE1DRNYILZiVwFmOhEA2bJ6pVALNY DN7RiEHRMavnmwNwhBhUM5fQlqJV6eX9ik3BHE/Dw+hzKR5qChWggpg4oMYEse9GcQnq/dXmQi3+ DZJH/qCWlwT/IQZEg5oeEXOhmDiuWfjYkWExTlwqIUxgNInrgysPVGAxpTCoWBoIL+4YNQFi/h4B T2L6JEsNUnAUFEndGxMCEiqRIjCclfQOV65I8Diw+4tmsZLBeK5YqLX0wDvEE1HMW5ibtPeQfQdF QTFYFkF2X79OARaL4SCkCiRaYUZqJ4GxLLdQqeaB/mpcXbckqpypGMYeawm9WgdNfIOVQiP/kzOU tuWUZTwe5d98euzEj3/28emzV7oEo2LZJVBTDgUvkjQZNVs3LS5O2tdfez4vja1btz64Z9d0ur51 y7bCqEzY9YnTV92OwafFQzvNAGx2bOPrN2/95ff/9tCRU7M+tKNxo/yxhLUUkfrsY9YeeXDbf/bN rz795IHZLHu0meUeFYHS6GrI7oI50xmGvK5BeQU3MMIC1soHgkBRgmUFixqNq4NDt+CNrFBYXa4w /56at8wx3HhNmlmvkY8dwqhf4IzexlJOdTwQfMUjhTnqljlio48Or8r4vZXcAQPw3P08z38IRl6o z0pNuq/T1CeEFbEIdu6OJ0Cb+3s//Iggh9BrLTQUZgKgEjEIvogGVQpJQAwTcJE81Mxb80Ha1k2M Fv0lda2Vq+USWS2mce2n4YXOF2XwkQUIsjppizHW1VORvZFir75TQXCGWYRWOwQQLdvg3dtIDlTO nF1WVLoh1OQDDDNx31VDEYW557BJyavEXbmHTN7FKA/81Ir76Ps0l1hEYCBpjpuJoKwai8aoxsWm 3xt6/g9nGBGHASJfqFTgDdqte4utT6ClUs1rrbej0JOMUqZl7Qi1VE9hSs08mSrmWKt1MYfKQnW+ ypEmayXSao9DzEFzXy0ss01NCT3oX6kkwSMylWtuGRWA36DGAwR5Jgkd7RuVmm0WKVoJS1dvWZOx gVH2K02pmWcvkr/z9Omzb7790eHj5yGOJuNxJeqh85GG2RCLmtZpakblRu/ZuXXzUjseTZ48+HCf 0lMHD+ZPLC0uZk+Ql/TS0mJJy7hYRAEiR368cvMJTKfTQ59+/hd//dMbd9YXxpMovhCSkBfSXC4x nc2a0P3Ob/7Sqy89s2P7jtW1Vc+V2ugLgl+mRuTdSEw2OiAMjJquEZ97Dwo43jU46BdxQEaeZxu7 lAUHTsU5g41v8B81f+L/ig4g8D4FBqfmj+oyGPvG2olgn61mPSiCIsyvgAPyOCK4+2WEWHtGoLk1 OM/gvUvlnku9p1pCq/AHx4aody4WKCZ7lw/Z3gmrM9Z9Xjs1wJ635PhBqFzclQLRvTMwrp1Q7C8j BkQvHtRGh8m4MLUqTzHa3lcYLBmZ1YcUTBHh+F/NilXCY1LYvrqRYI4Bw8YwAoVqXM6Efk6Y5uyY YC95W3K/jiHJiAPkZ1AhdGZJDdzAoqrRjNbfYJZXyunR4CPdoVpojFDRYnqE6FAdrNhXsKYjBfkk J6U9miSshlo7Bs3bKhHaWps4M0DQTBdSDRnBsTPiRrTcTgutOjfwH7L6omMxEE6lZK1hMiokFqu+ 6R7zgJ7bZ+axmCwwiOx+QXeCpXqW79d7qxVojiakFoWo9EB5fFaw1u/ljDByLb2wtEq6kF8+debC D95858SZy12K2a/w9RBRJSm7LnKiRsx+5WcRS7N8TyG/pFnXNbRUcu6SN92W5cW2hT17dty+fbfr 0tZNy7t3bt730J787fv2PXT//v2lxYX7q2uLC5PRaHzh8rUfvvX+0RMXxuNJwxm2wwKN8M0ot4HY +a/ra6s7ti7+3re+/qUXnl6fTul8/85b+osaaGDjZsRBVL8RJtv4L1d2qUDRoE3HfpqvvVdnYPmt Q98HzmS+kq35USXEhwq3uYDPoVjgKADViWBIDvzwQK77ZvBhpaJKzspriGtEvWQ7HaSwg9UpQxym TLKxjf5s/AlFdfy+U26tNru4TN0iA/jrH3yIdcsj9cV51C6Ai7qMXmk8DVCupJQ9wAAk0NgZQq3N BClCh3lHg4OWrmK4JWK3djLD0PT5R4fGEDOYaRUVFZRfkYfJB7TqhXV0AiHvPf5iUGsAAxu30opp Q5zHk2fsszF4ImTwVHEYXvKwHWnAEAR3WxzFpb5e3V4YECUl5RKjLC8yW0yxR8GXlAMmXhOFa165 Ohx6qGvSBFf6PbTyyIiooPkcGhuVwGx9YVIImW4OCaC1ByVjQ5/WuvpNqBxiAAN8uEHVO4n6fn8J WtWLXF2LTa3IDreNL54Fz5MP9dEPesZQe6ycCQPhAgM3P9SDFpYHdUPRvyeTSfYBp89e+Nuff3T8 5AXCTVsFhso6bmNkdItSW6KTNJHCGiTgGqzoWujkIIQXUI4t5fSlGBMFRYBuVio341G7sNCurq5v 3bKUvUtOn/L7b67cS9hkx9ZxLFgY52Gk6CLSajfgQaxB4jJqnE5nqZ/+o9/92tfeeGU67fIfb/A3 xnG1IGHUyY2NmZZtiH9P+k6sH1GGquSdtVvGuj2spF8N33z3J9Yuzg3ImPcwA5YmGl3L+ZwBrxjm mn/Rk4+H3DP7akD9j8KFFWbzDDSsxkRWZU/F3eTPB6ytEo2XpmUS4WQi13tpi8ZSlg+ufcVR+W2f uPTK8Y7CXH+PnNZffu8DqG+U9nPGxJjdFEGsLW1LbnMTDMRogjAoAFCKQ6VOJWtpdpMcOZQgNWQC cWHxJu7eT6IFYMg7WOsGZUu1FBZrNSzF4GNSJe3ROxk0IypOnCvAcPdJ3zMCrp17CnkFw8EqYRKU 5gQa2mtVVpkIQiqdYxbWPCX5Pgqj+YK10gZpbtAoiIv/Uh53DCisnpIfDJ+ARAAD18UXouHGwIwG h/WFgbtSap90ng+2rpczmEMflN9iFCJMCn7ztwfPUvA9YS5FqswIcX6hVv7JYeSH1WvZVhJocVFp w1N2PVVq0KLAs4HrJYqASZc8OOaXc2kCFzOjj2v+Qg7Uwr5toRjbJqcMSkgxaI6DpVJkGWWvEbNx P3nm3HsfHTl6/GyIowlVzvOBk96HoRBEYLA0NpCP3uWf6OT7RK0VzJpJmg6C1mi1qMmMR5QIIHDv c+l1K1FCXgN9PmBOpbg5yZjxyluXVjt0PT28lnsslBbplQ2hm62/+My+//x3fmPXjm1r69OeiPlz VhrnauPDho+wYVXNIcwKK5m2Q71WDbEGaBb+Qp+FgzK/1PNdb/z8Wwcf+IVuCK1vEbThP5Ctt9YB ixwrlKtWKjCN0+2+IH2+3osYHCZdmODvGygBucIzkHBDgcboSB5Lkdbe2oylVBAAj4BtSOIsZMSK Q1b+HlLPSaC4npirzJNUg2JyAkQqKy3OzFVFH6fXr6TCgGPjC/MZlemepCHIau9I8heRUjDOs/uO +wdDXusS8elzCNxu7TKYnvtU6Lam2oGPTJEzNA+Y4GtNG45LVghyXeLSkTQnSpknceahTRgCTwM1 eOYXKKBLqvoiXZyxBry6+6TFoTQjGHMBlAZW7S9B8B434u4hwceEySDNwNb9YQfhe1cLTnzfDC5j u+xLpGwB+TkS3a7XyrylRxEq0ubycQ31DVoamgYNLSyxS5SNMFIXBkyKmryFQeqAvkLoMj8pLElY 1ZlzdXwBDqId3wwEUnLNYPmUS19RCUciP2XpaaiKKmAYRIDguBuCTGrzuOuCZn6j9CRm3zGKJCfj cylaO9njNOvT2cqdu9du3Lh24/Ynhz+/ePlW/sB4vCRkFq7iBA0U6BnRFyVteSyqNrRXmcccmKbd gILbczIdFCBak4TVORgl4V5bXh7ZYzEPsBemYlJAI+U0K3Uc/DUGofOtA31ORVwHYDyefHD4zPVb f/6VV597+vH927ZumownyN1cZZG5fvkNBfZ6531JH1TFQAtaaM3C1iYJ2ZkHlrxJRroPztOEQcOM t9dh7gQ2FGRwg7+zTeB9JjoSgTQClsijco4HxLnKPInJ8JhQ2Vl8ibWr3zXV+6SKzB54Fo7vLE3S I4gbtXn81fjUpLLewEyfsEe1Aq0JUDJopMopeM/OsDN8+/sfgHUpR0cwMkwgBXPtjWAdNenjxmlT 11GeWNSIGJWZAwqJJwqIo7CbbK1wVwGUVxIJxOSrYwZz2TmF2o8xuE6f4InwYNJhkdqJg3Z41j5h 6xpWoKKIk/UoITkBPuwPmgiex6sFDvSdhZ4w5sNLAN8RbDIoNYQMVXENPJdQeASuiQe1AaLsSs5b yZobTdlCqNr27HRHbDfFmh2nUPv6Kz3PhDCqppzQB2KNDuqFx0Hibb6/JunSicYt7fY2IQG7yx8y TDG6I8eKhrqeea2cW6a/sSY/aOLTqDdVsMgUU7gxK3q4I1ifkF2ynKUV3qTLByAM1OO4+BXJe5Qa VCMqYTGOJEdZy+nxjZs3Dh394vy5q9dv3b5/f7106bf59yMmwCh/jc25KtjggPdsve6S6DO/X+ED dqXqXytAR0T5sIE8KX2XmKSpSXjwQ9mxoCw1PpoyOYVgkri0yWmcyDtRBtPN8pcuL42fePSB/fse 2Llj68MP7dm0vJyvN8hvk2WsOF+Hsb7GoiPStm2p60xn+e0jur1dVxIibghiv7g2na7cuTdqm8mo HU/GOVrqZh19hS/C+6RkjsKGtQtyAITVs0sbMSysVXdMyk32dHtOqZNnooUwrKgjDkEyrBCuB4RM gc0L0riytLse1XushOw5Xt7QV1a9rLk2o7+DJmd/s7Z/5hxpGAwegyhLsyBjFRYj1SNhdlV7Qf38 0Qkcyd1lM9dziEr5ODAazgJKmqmBSF5WC8uVFcE3rCFBGGKB5ZhMmC9/Q9nV7DFDcFgZsIBgMc2S /qsypkjIqANI0kBXzS/AQBOTupujEniFnMo3XHvtCsOz4yaJmjlELbmo5whDJpphlbQz9T5I1STm XK3n1j/trjBfZrW72lNGtFvtvmQfUNnSkHxO5rX/OPvx3RXRTHXddXqoqr7Gy5cBw6TIm9W3y9Og DVwb9wlRyR9uWpG8rISSgVQI1IxqDlDVHhdTTMHaaAXcpa+b12u4hdr0DAMNQMJiI0szhJp2WJ0t DpAEUzmQNYMGyjmVUbAqLsOk2aO01B0SCVbiXKItLzYrt++cOnf+/MVrp8+eX5t1a+vr91ZnDZRP gDT10tZSCTlpPk2WE6BK2mgZn6XP2HIl1+ldaXIKTQoeVVEKtgKlYFPIxL121fZaZaToTSmXVAOL 5sakm6pUgPoGwHriuTonIkMqyYqehkWBUT7Sls1LO3due/aJR3Zs3/bwgw9s2bxMEmrFUwxbS+QA +ZbmO3T56o1jX5w+d/n6tWsr+dw2b1p68uC+Jw8+kn3yxctXL1y+fuvmnQf3bP/o05M3b69OmjgZ N5s3Lz/68N6Xnn98x/at2cfMZl2yhhL8u6GxmklXErPnQyd0rRRqY/XUDV0IYW7H4pCo7HMdHLpX bcXUtPUXFXe8F3J1eJfyBccfcy7Ek9EGLZe1zMMYkkF1qVJWROsFreZTVsWgkGntJHOyFmXtfvt7 71vY4oDOoAREqEWOyh4AbtTSVwckaO1HU+kCKUKIap/iTvWt0eieIOk4I3OJeVnc7cEd7+JdBnp/ 6CnNZmFAtDrUntTuHKtyc6ZDO01CWhZ+thiZeFAJpPuh55Y6dqVSgaAr9gEFyxIThBoapThJkKUw S88ix1ppNC9OGiSkU5x/wKRukbsyQYA4CL5MIQJpKB2aVIYlrToV8mS/laRgw/ifaUGFVH0YksbY sK0EncYEiQcrshigNjNKg2kc9G9W5qJ3JC6hEkZfzwiky1rcm9CiPiP4GXGAYWUnVSvJWa2yq5dS rUgcqBaWxdWwZJwLJEVxa2iIvEqYakFSsaU4kOIpRtboXuLr0Sjf7kuXr5w5d+mn731yY+Vufp7j 8ZgfHEnSlW+ZznowWlLiqKhhNReuG6a6lwWIiVbbQyaFK2RJ0NWAtmR9WuK/A6uJi4CvyB8kiRpo R1BsRSR4Wmbl6ujWdH1J5ckZpaYoVkhwZAgbVNxClBZ6AsI0mU3McMtGPp//4rjNv3vqiUefe+bg ZDTau2f39q2b823MbgAlQkhtITXAjZXbb/78w48Pn+hmaFraXY7Fui4/9uzNc7JStknixV8eRHHx grnC1q1LLz138PmnHnvogd2zafFhqvgzVzsB194aUo3jjUzouvRdB3cylemEqqcStMRo7sF1egog HHDex3nfUL0cqqFXwi5ubM+EuQaTDbUrS7m8O2EeY3IgtETJGhzzMu6S9eiULFpQDOMODxq5BqWi IX4Y4K++/4H0VTTR2p0T1QlMdcrJAKGi7VVUAKIrVJHhYt1vFjURfl/SjhgNEDl9kbYwxUAca7Yc vpceydqYKcJwWuGXUr9UMtgC0qNnaA6UzRxMCpek04DvWnIdduKBJBwwjUvllTE5k6WnDDa2kAhU 4Ihvek/djsqvc8iNyQtoNlBkCmk/Ux9GcDq20WpUQteCmsKG6v5ROhyHYk8ge0BEHQNEywbYENG3 Ryd6b8zGaJCv77SH4Wqq8LmQL+QgpVvIDQOwngYHiNUqC4fqZtkbWn6s9CqJcqqYmOHC/Cus6IS0 KDroMjj9GvTpzLyIk8nXkLNkrpoXv3Q0wqqGzfcwFtRrXFyCBDMFBMvR/RenTv/Nj9+9fP1GNpil HEA3BJwMk0s1in3Pn+/5KqRNlfUXojMHNeW2hm2rrkngrHvHV/7Aaf+WYj4JFFE5M7EObZHtoY3f 8EJiSM2xiZIQSQrfPBuESMIxBWdzoExshPKQRO6aCsJJQ80kgLkpxo5Ho0gkgrzUJ+PxgUcf2PfQ rldfeo4NxGRhcv36zTffOXTyzIW19b7Ahohr0/JHOtK0P1SUjYaMTQ7FsqMp27/rNy+Ofv1XX331 5WeWlpayj0kkbevA6hAG2XX1CHPKwAGrmIizywNaAnolf1U19T2btS3HNaV57N1QMsPSNwgRzDcS 1ZDiF/AU5qow9Q0pgCqwyJlYxbNRVLtPPtcYiENL/X/AmvTNRsH1sSH8xXffYxaI4CpRgyoqwySq dpiCpKdvN9aL7tkHirFwT6LpDZtXQRy0tszxcfPaNb6WBKeBu/3RtFXAC9AxXFYE0YuJ1TSJwLpG NVSi6c1URZ188uS6SuemKXGh47MGJ2YTwRZgYs1ihv1ESL+mEq6MgSroGIIV1U0YUTvMo1fQCQ60 sm6mxo7gSgrWYVdK0+qEbBloFB+di5LsUBmlJZjlIojob7JSV+mcCKSfJiqLxeGVvgcWSOPXTUEH XJcXkDAQi4Vq+4XAVkDiOqESChw5zemFb9D3reJLripKwtLFJRuTRHt0EjGggiMmmIgROghxXtQK Rbkd1FJbo9UQ0gNrWS1qLc2oIeCf08dsMfu+++zYF598dvLk6QvrM5yMR0mJcdmeR1DCCAvT6aGi dATLVZDxxAhe5HzAhjVAteJgJgVkeuvA9Zge6mnHnonDiN2sNxRUa86h0fIkokeEyrHYSo7bUWmj abQuaJg5oLBqaLf3tSqTWHnCWj6SSt4CV1MEZuf9nR7Ysz0VDnP+ivbu/bX1LjWjNh+ym87yW6Zd H0O0iiA4hUuXqtJvU6XkkIp532A4+NiDr7701JdffTGf/3Q6c7baIDkJQF2hXoW0g2jTW0cJuj5O HHKc0YSjgq9cK/rkOhNRilhYLTOY/lwAb6ndcBD55YbubD9pxkuJGrQz3+eoSleJaYS6vqU0IEjt sCXI8FVdmrXD3knacFMBOk0m+PPvvFNV/6qMbpGT4k4uMExJREZA9D+sXRkDj4TgtmGKcax8qsUA t62dYlscBMJWUCVMn4IpdA3OlRqUfFEEB7r0UEvftOt66epw3XlojX60xZD9KYq8DResxMKyniHX 1VHazp34LggYVTYeC5AhCw2wlj7kcJbbzUAdh+l5sCO3AV9WalYFSWXtSdeIUgOi3ig/A4IffO3R Aa+k4JV/zGcPhtzojBibEcfN9TlIJOVNK59LQ6v2dlRX6kgEqM0uKdQJOaAq1CCsKN1jXOqnJ4Um oMkX4npxPO1LIvTKG1bz4D0V1w9EIWawBYJrrnRC8wOZ8QGTW+nVwgZrRw3XV/gZkazk7P0Pj3x0 +POL127lS8meRrGWGpIEhaW4BZI5BtkbR4EqsZCyWM8iMb0lhQEaAg5IVu0Z3YB8DxMj5zRipqXJ caz0zNmJBSizWV8Z27IGUMYMYarTVepMEJEi4J3S07QZ1hFkKdJ8M7LHKoEm0w2I/Q+6OblJxw8s sXFNNushn890fYosKUtOqG0brvcMAmaWwOkTCbpHbS9X/aqElQ6HlYuU/7Y+neUbuv/hPd/6ra++ 8PyTs2n+Z5bQW+GhMArWiN42GDgJyxS86LL5GXE2rnozrMk7z2OG2+E9v1ihDHGeQjM4yLC/4heo WCJ66Yt6srVERlZd9lGtTkEYpEsl6HRScaiKUxyUSJebyi7SEBaxQ80f/vGfhirRBTrso8oTJtc1 CYMhPqKkq+393A0Aw7wMapZtmrKxlBBrr7m7U2CsnqruKZedMPmmLH6aRQ62kt4TAw5mvqtuhSIp HEPZGUad0SSSADZwE2zGioAGicJ84rAFLSwJwsRV9qDEX4ig2ax6Ke1Aqkw30ZAnEApTcCIEqHK/ lSCPVl4eKDQwG8pyQU4WKyMLa5MER0nipVxniiUeSapz6v3ZoiJ4XUibaAAmxkuOmYXbZdoZENgj JaHIQRjLdoEogUmrelLVfa+ZH2XSSNCSiY0bCFaUc81AVUSNlmj00y/8lCkryTh6RcUgq1cDR0wu 9woMCC+4fvYbBQrjgjxMJuNsBN//8NCff+dHH3126va92Wg8aSWrisrTDaARwOIkh+NNnzZoA0SW 5JE0SxuXgeUP0JOldcvl4ySBXmNFS1WFmaMirloWKW5lmXISy7m8ynFKNVV3GMrng7KtZIITsQCw dMRU6QQVkuG12dJUWRxy80qfAAYjoW1UdTRdPEqmWz590EkNSVEhaZoO0ntHYCOy5lNUfRwbsOQH XIkqU3G1zZUbtz/9/MSVa1fzg3tw756mhIAwjCTA/7+K0LuxkVYaib52jY48DwPRtsFczcFfYI5x 7yUi528VzPOmbbaCQuQ6yAGcWFFF6uuXK/sm8IRYvrdgyuQ83YqYBYqAiU2AwWikyqSxO1VvoZLn GBJp/uiP/2kbBY5hUApEqaK2AQpahVClp8GBwbo3eCoXB2eiFRaprdKGoOhNoTgl2cp25wvm73ny BAc1op4i1AYNYBN6gFiz8rm+FjEWJFVuARFLAXLR2xROSnGitL/YEGh09d4qM1NFL4U1QbtcpwRK vsUAV6yjVNGVHyBZiuo06ZxIfaxFNxVgsVGJHuMiIxm93omBUUHo4zbzWLHpOviEog9dexTbMok4 DTXPa1HdjJgW9hnoi2kw28s5r/IGwu0FLK1C+GCDCbRmG3XbeAQQHIjGQtRB6/zgnIdF+NrGCu70 1NAbycB7Vg2QBlp+OuSCjW/TtqPxmKv3fMCFhcnJU2e+/b2fvPPh0fvrXXY7lLvHYKJ/WIWQ848L k3bHpnDj0mcLCwvteGE6SxbAcH8WfV0MurGNhCDcPB3IzT3+wdUgufTV68TQIrsnM4+KN5kVnNlI FrLY2gZM1YX9fo9JAVqeMoq0V2guEbnDUhZPyO0x0cZVSXOVGBJeSzU7IdTCajwsMUCN2KXhiFMW zw0JbqCZjphy1DMtR+lQaVUz0kHrbAeipjJg655uaWnEGbX5Ik6cuvThoaM3bt5aWBjnE1xaXCAW Rpqb4DPsKgEYNMcA1DRBZPfVwPv34fwxbYCed2W6KB07Cqx67mMkGMz3Qpj7Dq/uEqqMh1MQAWk4 cQeM4JyKztGIpjNt2krUvFxvqTL0pSMPrVEZ6qQFFPcB3/neu0r8kFlSpZoQejqDJulwTu/ASLOv H4S1dtu1jhdlmSfDkZjEjzYTkITri2B42caNKr5ruqBM6qia99IljTp+olAPkjA7k6WiQlEjIj/S rExpYEzJJJyF7GHiNA112IGA0YmFOsoO6xPPe05uOGKE2titRDUJa7gpVcVCQJQFlDWgH4x15Kmq c0bNKlVzxVQPS79pDKyP0seBnCLYqFcwLRItBZoiC+jcUG4rtDhE2/TQTYQLpig8GBFtTRIYrJoq 1FUpVvl5mEEZAaKIhbXhVDVpSMeBcVQbBa2VT4WKtFeHteygdm0JH3Cgkc7+tfJNMMwVqRgKUG03 nYRdByoPAhH9h5o5IDuVtpTrG77CnK+MRu2RI0f/7Ns/6lIzmYxEoiQJB4HxwIRzpbIwW7+/bblv yszS2Iw3rc/alXvr+R2TUcssZkW6TM1VoiJMAesVQZWFblQiGkxtQYug9Kyol784JM5pGZvT6+2D 1PkLdFYGkJP1ZynovCW1klG2GA2ZLd9RquUypCsSSFXq/BSXlm0463sbZsGSUKjxlwi6aU2ZZ9w2 NHiNc8repvgluu3CGU3SwVr8X3kntTCgZaYy1YI/l1LbxNpWD1HCKEf85TWZSvfM+uJkvHXz0qMP P/CVX37pwP6H2rbNd4mHoc1RlQeCkq5tH53eEjrtdH6CvVO1HPTADJQ2PQW66ne7sgVu5Ji5ik5l Ww2bU6HOQnYikZUYpQg1VkeFfk5lUkjD9+sPIEGtJoG/Mhci6wD40Pzxf/tPRb4+shSenAqj67x8 lOJewpqo7SZ8FFF8YYOVFLjnejJZuAOP7X31pYPTaXfn7qokTjFoP40Ol6DSgwIoIcqqwZqalWpq +cZtW5Ze/6Wnt2xeuHb9Ns9X5rdFmZVczj8beZJiCoENWeSoAUGDxUhTLPmKOITi8Dz/qm0alkIg BhRfHdIsjAJWSPpF1TA+gm77os9RJ8DX7FhMvAnRMAe3UXoC53pGs+bjNToYhgN0RtEZb4+ggjYD FYmBSHDUL1NatlY6BEKPpngl1l9yBrmcaEEPuOTBSbfY8AZHFATfcCqxRR29pMRzYOEv2QNJpwzW cUbaGGvKHNqoI3XsqHhhxbZ1doWK8UBtRwmqmsNCOQP1HXCtr+6dTv+YWGHlD6Mo+c/i4sLa6uq3 v/uDH/7sI2gmrWi9SOODY6VHZr5F5fGXZdOM1roxxsV8qPV7VzcvNwcefahL6fadVestKx8kJxiI Hg4RBsMeYQC7N1S4IN4jj+Ys94pVxVIV+FfdPycazUA6m46epFpYPa8hHRhVfYVeS51JhSJs0BGN vUYdrqq7t/hNEP63SgxEdQVRhzpL7AUMCPt2QuONaJOT60mOAF4iqOJQXmM1hGqIuHEEa/uaDnso n88PLi/E+9Pu4rVbR46ePHP2/PGTpzcvL+7etQMGOJ7rphpMX54fWKqGxcicc2G3xP51Oxn9sEbt IcxDYxZqOItSD2ygV7S7BMMFzPZfwQao+gChiqpaz4zS3sAPmPCTjHR4q15jHawKXCbQfnZRbiW2 SEHG/lRRfmgam7raSHc3VBE0K6MZ5gCqT1XViHlMt8MhXnh2/2Q8WlqaXLh4vfYZKpXLmkXFIKpA MstOKDc/mML8Iw/v2rVzy+ZNiydPX/I1iUZGlnEXZ7IeMZNxjOIMgiAYIiY4VxAQTTHm1YCUl0Hb YEB1KWKwVk0rXmtLs/KUgoxtMcNaWbNo1DAOGIW6bemsDAuMMiIzyqAn8VRBRQlMG4TaTmWsIR+N h9n635JdJ4mqxo+i168S089LVatp7KY03wNU98eDXtx1gZYqBlLU1WnFKhvDPSXC3+PLN0emY6Sj TiLQ/BpQ7355clS94MGKcvNV+YougCsMsTWWFxoGUK6mqdrMPLu+8hrALqqUN0al0sI3P6cs43F7 /PiJP//Oj46evNyOF1sbvIpuVJqS0BzBRLK5JL33cb3Lp7C4troG/drTBx/a/8ie+/dWV1buM4U9 qHRtLSEBGpvFpu9IaARevDzoZo2OUFm5nvoUuKDLVUyCppPsl1aonNbOEOOwymwCsvlEOxkGKNPS QpKaWcDKgodqt2RCjhT5tHskGxku3lj5LflIX5AtbYtudJpThA0SxQL5sB/qU4IBjMQ67sGm7lpk zCn49Vt3r1xdOfLZFzl02L5t8+ZNy5zwQV3DfP80t3RSG8F7APA4rgSLsVZDLIJjh8Cio6akE6IT F9FKBYATvVNl0uAFOAxmqDO0FYIDXwQCB2zbaFQD0GoLXKirpk5BloES4A5h5tD915oNpHGj5Poc l/gBUAYda9afxNuVTdyQlr76HqY+0yZiXEjnDShBC0PONxcXxvnfdZIg88elzgqVlhY05ed2r9Tr WdmsLc5eQ86E0JreQSoxQVyLDphRYl/CnpeR3fCiAZNfTV1xolFb87T5NWcsnrTOgzijUEhSHeDh 4pScywSuzSgUxEKC0qNFkaYEldqARqlYuUppeEw2I1AHFdeBVyxYK/ov7AHr1KwoQSpThfkZ0sn3 MVbbTcACY6XJxrQkiW3RRKUIuI+VUUncnrJdaW31qRc1qmDCWjFgHxC8DWqYR2BGVutHtmOYfiiS BwwMBost5dLzomsaCwPZl4v/ZU9piBmDbkSFTNycwSUqm5raRjaCnPRbasV8DagKAlU7J7YjaZNk GeNbN2/9zY9/+unxs9nITRYXjVrEVHslhRNbQWuHJmxqjc0NtVoV6Kl8aMvV293Nj48/sHvrl557 uOvCkWMXLl29Mx5PYuvID9QjkndEzzNeeatF6Y1lkLngWgyDE6JVpnQzlku+rSdkLYqPKnsh/8Sz iiOLVcvN0uHqmOTgdPeI8xU9lUaEAwydxDIuPbLvAKF7yX1VlVXa0QiDEfTRprcpsBxcwVUUf6nA pklJQonPxLQO+paMzUHcaN6OlSdM8QUklI7kxHvZaaDk052l8JO3D7330WcH9u395ddeOPjkgVAw tE7zZxn15ofaofed81MvA/gbCzDQFR7+O9aZPdZfKzbeOq3CnPRsUNF750AqA03JEabIZtJikSfB 6xwik+LWFBAhhDlCHfuYpFWZZEKFNlPYDYNC19WR39laZxSqkJSo/CsMxwm7F/qzBldRAgi0wkL0 wD3iUJPZS/yiKChbKRZZosaJNpYd1RMcXIZgtFRlTGE4+szk0LM/sPYlXcosaaNZkYk8uv6jIKrG ASqvW0b41VFvaEJVrNmO2rnHeEIBto02SU5LCpj5HHohVbOIJYIS5TlDwNTbeAaSaLKiF5v+ZJkm Lbam1H55k4XYK9kDWSkd3MwUm4hMtVmQEqkBY6CjqMQdS/uKPs9o+ql1sIrNIecsilXnTC6yOCDq 1Se7UxmAaBLoArnqDuDV0TROA5sT7Yrvokj9ajOF8PA1kGqiq3FyOzoxqmv76qAIi6qhWevtEkzX 5iKZC8PRgrqWIhvW9d3b73zw0/cO3763tjBZBH0w5eGGqm8U5qwM3YqQDFSsADsPPCKTNZqF0elL dy9fO7LvwV1ffvmxtfXus+MXz1662Y4mLZcMzYcpMZMalZhyidglI9owItczG6hccV8HOXMYQa6F wzbKMBoSBOud7g71ThEwO+uRHYswUAZzr0RlRtjMOf+gxc26HUklp3yvLtamWoOqkgk0iMSc1OQl j9UyvrQNsIqlBEplDUppudwNrTH0VCLKvyyaAiLwRalSVYqTXuwiQJUctQxwOp3lq15YmKzN8MOj Z05fuLZ//6fPPf34U4/vX1xYmOaQlkpTPhHAMK9vWVU4wSvGwrxwi5GZfb3CjSCskgweMfMzWLB2 9lq9pTYxB0cCQyOYO74yGA/TUY8VH0queINVTzk4rslg7Ozc3LPkcMRSwP/DP/qT2rjgZETRuzAn ZGT97eikErgQl33M3t1bR6N2fX1mqNrDD+5cmIxW16bnL1zX3B9379q6aXnh3r11RkJCpZFWyZns J7Zv27Rty/Kdu6vGStq+ddPOHZvzSjpz7pq6Q9i8aSG/8+69NZsdY5ShoPO4jJSkwy0lHxeGLZpi zUAE1bLi6Ih2qn5muSmaOE6oQ+clcojAen9S+9EML1gbEPUQGE6FoerOVvgVBV7nnrIQTbBTZ1UF 5XEGBaklQ6pNMKxRgH3ll6vWAmfqni+tvODoVCqT6szzPW8FABW3quPjEgFW4PlfoszmxgUb+5bf 0Sg9wT2BQGhejfCYHSfFCYcL8yEawRUreOvPAaXgDzKtoG4Oy2YNdSkNK+xaJpPx+vr6n/1/f/X+ oWMdxvyqpDvBrDnfbTSRPeZWMB3AAAjr/x9gKfRzqd41oy40N26vnj13YTwKLz1/4PFH9967t3rt 5t0CbjZNHY0qKRz23IWYElZtMcl1kioqy/akAiZBXIlLMqaDV+hgfR1uCYXoLCXIvHG7nhn2tWsg OlKgBCISIAoBTGgFNEQDk87KVQYnY68l9qLwJsrD1UpOuQ8kcsoBTRCeUvbvISX2PUzTJzBbpECk +M8qt0Kfk6mD1JbPwW4/lzDIjIZgI4ga0Oyh7MQ+tePxNIWLl28cOvLF6TPnSzPpqF1eWgzzc6nq 2G5fFYGaDGtGDhXCQgBfHZhjHtc2BNCzVnfrGcmejhYrcuq5x2gMEayzqL1chacZbygmOWJlhd3M P9mEl1qy5TKqgYHWKRVaU/znZBptdgUNk+BJwEHbjHPAFilMMB6naR3mB75j++aXXzyY//q9H36U 1y400bu2AonmlDzGTcuLX6K3/eStw9nrcEAFzqiyrckP9cuvPMmzj67duMNyrnNCOnzmeU8uLo6X liYnT1+mNkwwjDoqLG1tEtJoFoQnVjsry4qkdFZojxgGxWbWvU8UzutiaNxsNzqcqUXw9otasspr ngUDg5/YEZiJEIMytm0OG4MPUVSTBdQupo20brSxiid7uLQb0IPtDacaVfhCpNOsYsT+iEZ36BxF CDUeZ9Aj1vlUcj94Trb2JFGpQ3Jf07PU7INjTRhM/g06aVXEfrhYFZOr0PLeYNZ1U7JYRXrcBOVa GBUC3WB0WC3aoyaLVbAnmno/VgHvYo3aUWnCz3/G4/Hhw0feeueja7fuTxaXiJErZZmU0KEU2qnN v6f1EL3WgEpoF3hOe+pYcyhp2aCUgkbtLI0/P33r8xMXD+7b+/U3nsvx2dvvHT176VY+pREJfHVJ Qj7rMCVhBRAfQ9BbEmGLPkhRgYRepDtT5Jf4uSflOQFJH4DCjvlWd6S8p4ruktPI3AfVPSIkTLQG qJgXkzLOy6QyaMiPBOMWJqJf5utnjYyowlW8Holf14iRsaZf7unm7QbUSZ4oy69wSLCiaSXG6t5E aoazCElolILlylUgCFhGfAQaypBv53Sak9aF8ST/6vSF6yfP/nBx3P7D3/m1l154qszAqSBKHds7 nDhMs3BcCmG4FgyFlw2rteHEThUfBpM2694OdabWQG4M/GQiPwIZXdpgjYBVLQmCH89sCBuib/Kv Q8EkT64iSmGhxUkbbq5Vv5Q4HCestGjxUficqFMsEEWYW+GQufDMVJRclX8VTb5CeuV4iU8mI6vc pqih4nB2e36eeQvzXxYWxqs5y7G++sTS4wJ5NXoT82GJfAx2a6rIFHW68RsXF8ZSU01KTykrTOoD praiPVJKvxPZ4MgNB+WV4lPjgKJajtQRMibyZcof6Gm0Jc8sLd/ZJ8YSWegsUHGJjWJS6hMMZ1XE WEf/Vp3tRtOFMGgqV0mbZFNSgo0rDtrcLkqFonZDNL8ogpqlmMH4HqMTkY14MuNcZw4G5oGAxWO+ tqwjhmQmnMxyqNMXJR/UgW4QnFi1a5tC0z8G1mJ184hot9vIGd1i1TEHm/bllG/AVHVqqMJCL+jG GNfyaRQ51rINWq7hj8soe/zZu+//4CfvQjNuxxOuPegMxcCsP5BdJA22RgUOQ1EzL/bFIxSQhRuk ypVUUiyfQD7OJEF77PS1oye/++pLT33zN17LWftbPz/8xdlrWKTomxEVvTSg5SyOKL5a3qdkqOmV REA1MxGaYLZLT7VSowIzfaLruhzJ5ffPihcNczTDSq3GYMUeFRTg2j0gS6UWPWrMroYVLEhETfuK SbRCBGEUQWJdVIa/qD+0sZo7P0NWjEWZQMoQp4SeRA2VKAdrlVfCI2rbSdz+hNy3EGnOTQQT7ePM ntdYz+ISoS97PG/16RQLxblIXWf7MkP8D//xR5989sVjj+x5+bmnF5eWptPOSWVs0LdnhRwWihWB eqhSLnV6bdVulk4+CIO56a6VXzsuqhqX9WyhJVXBK8XAUJhfSzVKF3Y85uAJeAheglxdNVT+mcQY Ug0Ks7xgOi45B9NOk9pKCEXPpyiYRjUF9BNHPSR71wXSXuCxd8iouCa1SwvjtfUpI7HcgEJqEAlQ BC1scLQ1hRVzpuoU9DmrAIac09y7v2a6j2iihH2qcKFpcCVhVVqbZMFGwYRScGEy6pnLHyzhRGv5 1jIUSxN5gRGkJZvqvEipXDWIjBXEpMPsg/QPF2+QCLKI2hRmJHvex6gKKczqoZvCXINSk1HAsFom yRcVEOG7KoicwohsFs1zVPlioU4Q9OFGeujYSmEvUdlcBA4KIYcuVCWatAVPE2YbXmmT90o4Do7k 4yWPEmMARAcQWqG2c9YyUVKBgMFQZ1CCc/RC6ca7FIVH5uKqqpVX3VA8NFlUh8NUV+SvlLTCink0 RyTfycXFxVOnz/zorXcuXb/VThZ5pROHtYwfFmk5LyjqJgZWrXJjqbKIPY+/LCGUkjnJpDUIJkNH olgixB9HS303evujk4c+O/XlV57/nd9+49btu+99fPzshesrd6eT8YiyBpkVZr1lwvtqmLZusXsv ulsmfNH3m+PaShpB00qjYt8XajUXZ1LSWUJav45Gua+DZKShlR0PkfQ7SUBLzUNdUTRxel6iTJTn ngclm5lyYNlB1KPTS4Mnbfn8i44oA0xGBxY6o9XYtkI9jCRCwyhfyZmQykBRs/TESR13DnWc1TFB QOpTIlQomu687/IXlNnNpSEvkkpDmQSaH8fHn5348KOjf+/X33ji4GP5S9eLExI7a9zXOj4BVNFL FXRdWgAVc6SliqGqX0MYKtr7xsaa5tQfB/UgN03c0NlgVBo/tgbqMBc/2CWq0K4SATjqC7XpzYnp 5o/MigB2aCyJZyEAnXxYoqHWIosQE0tCaahW4gse88C4GYX6jLh/+ZUntm/b9OGhk1eu3dSJqAN4 Isp0o6FwtGuNlio1/e2RfbuefeqRc+evHTl61jT8fQ+2GFN7kX6KlF3VYW08oC7G5aWFN7789Nr6 7M2ffsriVwk9UZy8awmXhMyqkn5uTL1MNlSFQaxYqKhtS9zaq0i+2VZU1fc6CEDoSjKzLmiLe+A5 Z0z9Z5Yx6QhImSmyXoUAlaI8SL2fkm1pnd9GPWI01RmImt+yLlujjQquttTLiGvy3zQWt2hBhtTX 0qQOVrbhK6yMWUcbuHBNyjWo6rhl9F4iWcwYSMW9RmsCTNvYc4QU6hQ0Jqq6seXFZKJvtQmxQsGW I3E5HStJOmlhoDZYDsI5pvPl7L2NTbu0tPjRx4e//+OfrXU4Hk84LUDr/ycTIjZImG6gVjeomAXa GB4/7LbcwKjqfCDsXBPOEo25UMW/8v0aL2ye9v0PfvrJW+8cfv2Xnv/9f/CNvND+j//n+0e/uNTm kyNJ/7YBIykyDtYEXhQ94S6owAHLgZdHsG15/E/+8Jv/87/+3sr91PJI8yLHSW/gNeza/0xvJLkR cxwoaAZTh+vkH9tRQyOLkvRS65g+hsxEgZ3hsjJ2hwcMoo5XRdvggDZVTyegaS2ZWIux1XYxgguq clLfJTaiMVjHPjNEqUtaO2ptWJ/MXrQcgSVNU3FDdD/70sJcUsG8GHAyGudHfeby7f/t333nmcf3 vfalZ594fP9o0q6trRNwG5WjWiWfEHRrmycIQ4XW6otc5+/cNMlBow9WfswG3kBwwh/g8xKnglyx OjeszPV0Or4BESCTqi7atGmxCSxlpQTdWdJ6EBovv5x26wwoBxSRJLYZtxX1WaR23IhRJ3kUc5Nd S/5h544tl67c5BJdrzelZ8bUQJBGHbCjfimfunzfg3u255/27N52+LMzoBixyWrJWsEaNqr6EDOI PJGsXOHmzcul/W1hzIAzJz+NlD2DSdzRsqRbRSZbpRoERvAN6KZwbnLsuh0sexD9JdOHEDmMUMkd 3LGi2HtQyXQ2/1p/4/ymscxJ5pbTPmlY/pkBxhKqMfalov089kOy/kYeVN9TtEhupZLNdM1zGMW3 ummh8G1Y4pikORnQT1AlMRkodjQS7fvh25qUmKZ8iOKryhc7QTleBEQ8tulYKFtPFKUqodil9aZN laSUFXUihyhSJBDtAJbST9If0yT00zNT1YFhXDIHp5OFvu/+9q233/7gkz7mv+r0aFAp1iTC2qyN UiFW7qCKdfwoqASDIUst9dlGmVAgg1gKt54GZ5V3olDYU21AJXGztlmIm2fd9Ic/PfTz94/sf3DH N3/zK1//lbW33z3y+ckrsxQnC2OoSmukFC5aR0kUuwr2oMgZhrXV1a9+45e2bN925+5qbEpdoSmK xW2SFSXqTUnFVyiDqdMKLSfjNJqn/jVGEy6JRbn77NqpdCjqTTz6TCI/WgvF7uSbGWLtgecuVNAZ KaEOiJL+ZYLNmtKXo2x6YjbQrJAoUEdD0+K8lgOLIEm1zIRKA89W1xYTVk5KpNEenNQhHwvXp+uj fHWkhDYej/JNPvT52U8+P31g/4OvvvDki889OZqMp7NOcskqbg04BJ3CBpVJx9ry4squkxF9ag4b xtMELxeNToS8dvM7cXt0AtBgczA9DmbOiLl2SUxY1S3ToefK2qjaAxZ2Byec2SYENDjUlO5Ei5Cn KQAN6ilUeZQclRt9S+Y462T8FnWwW7U1yozL+ZFqokdpV8yaynlZzQqEFfJDEh/ko0zu1/DjcjnR oqUYa9uJCGqhNi3LZqMIgqfFEBzU9KjqeLwIaLQRq/sB1nKsSUBS4NOwOgdHN1BbgnTUs8B0aHwQ 1S4R1XqZuelavFhOQIAfk8mQ3WrqulVbVfjHSosi8WYtesgk0MrwECVQSoBSlbEJNqnSNiHlQ01V +1ZBfDSGo46HAuMtEcSfguqvkF+JlE+xYC33S6Oqr3Cvhk3FAT/FHqBOJMM6pQZ1KprK9qi4JinM h8GcPTZ0sUrb1lJTjW1S8rAiNzk17WiU//azd949de785WsrZSKLjhgo/lXl0awLIDFVQbWASj0y JFJUFDmipKGPdQ0RlSsZDbRj+a4kqqOhMvGqnj4g14rKJszbY7K4JYfon5+89OkXf/bSi09987fe +PXVe2/+7JNDRy90oVlYmKhKoHSY9DrChKshvGOyM9u6ZfE3v/HKf/zeO2tTXN4Ue0KSU6mT01L3 zGMN5tB0XFyIqJCjEPCKdWisza4U+YkcHGcq7w1dVzpFEqGajQyOq2Pgk+wRKdf1ugfFiVC9neDV AvuNGn7SGAlNVZEnUgKkTZ1PpWzzFGVBibYtU1a491PYDcozlBDHjZE3MiywgcpuW7p1G/5I9jH5 0k6cvnzixPnDR469/pVXHn/8wKzMNutq+aIqLHtxGbf/pcXKSf87dvDgPX4Ksm4iY8xWdTLXNVRh aiEZczZdx2uik0Pm3CTqtyUn/lFZBDZ6rnZwGO/DiaSDHzcd2l5sCq3mIm0tFNs+cYQIqnhPK5+7 alH6zDkhYNNvzD+ZChXmVd16Ia5EczrVOGqj/njUJlKXaqrgJ50D6J53LidfZ0tuhtkExW30Yuz4 qxudUay3R8apuNkkYm+EB4AeW2a/IqeQVK4x9La1ohXYQi95D/fEWHMSKmXc8f41jyFQrifGJHgp HzVDmEQsnTsTJYhjyChhcPIYphKmlZUaxAjYqwGHwq/6kk1wlD4GHVMN4Ea4oIq1WPVF+pZUM8Yi syonSkGoDeOqcg9WaeB1JZ3PwnITl6rdxoFHR3pCGFjDRPAMZimpwwbB1qDTUQfaHPS9rPLSts3f /PDHH376BZS/jJQAFkzv1GbmIUn+CuSlxJiGUa9eO8kRbaaAQUnAY3hKOSAxn5i9ipDFZbxeCTBK 8aBP2kYJNE4Nqd23TCh+YO/ee2uzI5+fO3vuykvPH/za1175xldf/Pn7x947dPruLE3Go4W2ndGx s32flTZAm8VQuJpr99d/4zde3rxp6d0PPl+cjCPDeaRwnTQnNZHTZPkoPfSe+Q86Zk6qosXcSxyT 0yxylgVfy/eplC3p4bTl9RKaSVGQ6vYsx6kMaZG7kLvClDZhg9GsM6ilhGha3IIjFgNCOTpDjCU1 lA3FzfbMXZTiegzSuczBYmQwjpN1mokp0k469lu6vEm/s5xQl2Yx5i3ZiqZHSuO2kP2Onrx8/NRf vfD0Y2+8/vJD+x7KPju7GUypaoZZKOqKJbbF/JQHn95Usq2bcjc4jOHhtSZTay5ogm/BzdYMnm/m O/+4d2/DUGindyaUGZ0Jx5wSLWBb50RIIjMoMV/zB3/030VVweWqQK9t+lq/NQ+RrAIv6EQTj524 uD6d8UKZrndbtixdv3Hn0pUVVZOLjz5M/S6rs/MXbzDXqev6zZsX769Oz5y7zsTavK3ur842Ly+c Ont15fYqm5zZrF9YGJOy6eVORurBtq3Lu3ZuoX6X68KBBOlB+eLE5Rl1h1GFP23ZvHhz5d6V67eD ylew6UQj77PolpqPqEIjjY3UjdZCKirzXCbnsiQm8RCgKv1Qhumy3KhpjwrfnZBZ1nCTNgL1C0Eb S21wPasPgNAHyDoJeUZQLFlJrNOkMwUk1OhTqktNDYFo0zKDjroI59lopuM/N/rE1b2YTcTNJamS ihDQqSKLDCdC1SurRJY6oUeooSLuIMydYFJg9oykJy9WGQrwk1w52hUFklBtOsikmQhOlybqFxc5 /VE7GY+vXL325ls/P/LF6cnCIkH59DzFN0icxIF1L6PwonHqgk43kMZJZOVvkVKy9DUqMYRp98as k3VitHCweKUyAlKyLrhyj9e77uG9W9ZnuLqO5y5c++zoqRwqv/LSE7/8ypMt9Feu3lhdnyaibW9a GuXdlL1lUnnu/OzGDf7pf/OtQ4ePf+8nRxYWF5V3F9k7sgkrWgB626LK+KieWHBDw1RKhxd4AzyM rmFNAWMVCoSeGPnQ0hUlIgQ5Rup2YEGErsgHgAlyE0qmlehSGI7FlBuMQetJBl4w60f9HAHysTZv art7EbQFrmjyFm6q/onm8bZGgdnWULMM0nBLKiFtPWDEYqf5pOcuXD3+xZmVW7eWFtrl5cVRYR76 PMIVUQKCbxbxGwMGg/VgKI6s3SdKKFJJe9Oi0txBqHNq40V7Zk7iH2rwiELCMcpnFRgccAHYj8Q6 4YJwZ1E5kaEkVcGPLdlf/vX7wUqQFEOVrEUgR6yzxNX3cTCIIikoXZaoouiqWCiJeV4l3/jqc0uL kzt3137ysyMqDawgiLR3lrc2StQFAb7Y1YnWshWpnjjwwBMHH8jL6Ls/+Cg4d282sY7AGnAnhJUE lWEp6A1ha6KJG9yMWYUszMGDC5tsClm0LIGlJnh2oTKGq+qwRvoSySSrLnKhGOYY8RRTcjimcyx0 CCeImCPWlnRTg0H0Kne1vJjk6aAf1+i6Hat903MJNl4X3YQxrmfQAHjqU1HrWafURZA5VqB619E3 99bO9ugEEmy+JD2mPkaoDGBF7QWaUk5B6RFR2qc1pxo/u4pw1u9G0VMrgxHLrJZjX3zxvR++OcPS 40IzpwkZUjZjrzBanyQdkdwdeWJKUTv12hMkGBGTFU0S2jhCuZPGOA+M3IqqMd9kUzNoOBiUWQkC VHKjWP7ebZsne3du+vz0tRLHlIBrumVT+8JzB1949mA2nu9++PkP3/oEsGvahXF2IIvjW7dX2RLf uXP/N3/lmX/2J//gf/wX/+rwsauLiws21TGyeL7olpvxlIKrQBHUxRJsZp1MmCVhqCaOiIJcMgk1 wazIymXJ/MqIxpvyZA7WIBcJc+6Hw8I04/iJh49hcp6lTKnpiXdh0RfOZNYTMFZceASBpJ1VNVZx gLLoWfYmf55n0thU3MCpVZ8qeOWmTEXOv5GZdGiCWmV9FnXnMGoIqeAuWtqYhZHWdeM2Hnz0wa9+ 9dWtW7Zs27alZ25An4ZjhAMOQDH0SsxewLtqMFeVOZvcPKg7JCfn6Qeaoh9bOxzAia4bByrNUljI yaTkrbmTWXA62s5yjCEfW4imvJBaWhYl5G8Lny+kWWpklmpiCWQzzURQJgofzSdGa86iphNp/I7D 8ekh3Lx1L3uXy1dvST1UIBFObKnHipj5RWLVBtpTzxRDB4UXyPksXcDN2/fy8e/cXe2ROY9VX0Ja mksWXCoNXWA9HS5cq5C5lzkRgD70rI8SWepTm3tJ9xtUw1pEFdk0KJeF5xagDgvgS+5TbfhLQvAP AoIFmbcZVTuIeeTcL8m7i0oayK2dLY/ukGZPtLGSdUgnhdvMCKL3BIPs7CkwwSnJ9UXjKJqcnFgY nWYl8abUAEG1mgSgysfpOlRtf/BSUbwXeW31Ko7ARfHyKKkQB24kXZDpIBg1R6cVKX6FkQXuopSE PLCrLmfLjwbEecv10P2BWnZXxdxIKBOHmTlryav3R2++9cHhz9vxZKQkVw6GOdtm6ItyNdSJc4Qv 2XgF6acKPPGBlfG4mqiT3oPydBE1cmRYptg7yrhaarNgih0PKZXBjsGyJVkVbOLHMa6srO/csrRv 79bT526OF0apn6zc637+3pGzZ87t3bv35Rcef+2lxz/68PBf//CjTUuTazfuluElOFtd63ZtXfj9 3/3VY1+cPXri8mRhyUZBc0JstPVyetbiTl+aT6MLqeUJRnXgCYzH3B0qzknacilFTiom0tOIjdoC QhNnudao3l81SjQv1Jxa7ETPXTuaKuYb3ffsDjhSYkKTdMUHaoFoG+Ccj24rLYASByQbQxC1DDZi mI7hnRLGBVMYqP0lOiWdNwXbQF6aPa9+mUrHVSWI43F+/bOT589dvbkwHh185IEvv/ZCTmWWlpeZ dJ7dTwBXqFcwGI2wJMISaOGsl/OGUKexaZaPxmVNGmxHrIPRbBKlb35hw+jobENxlyqzDFCDarRp 7nXTOfIb1+CMjCPs6v/3O+8xyYcjEG4A5rJ52ZYMtlQeMbu1IvoyKjSO4syJAdLIIGuKfpPMWBb9 uy2blldu3yc7LiUHiSICUUd6kUioLQtRGi+kqM6KiUGkD5eXF+6vzXLs1srcTY5asSHZcNKwK/+s d11LEXvnZpawiSw2nPlFSVR4Ub10tLhAkh9pXWzJDMksSNCNkF8vDoBB4cj6UdyO1pByJaZKFSdj EcSXQNB5nUGFKIAFx9hsisI1SrGol8KjSFTxCUeTd1SuAVo3hkXNMdJgGCGNFQSjrzVDHSqq415k mg6HtEMB7uDGTIvIJrrRqE5wNaAWHnSqKS8bGlVSW4qQWxBklqKOshD+L0ox2vRpowlbufHYcisU C4jaQSV1X+ZIt22JkEgtP6yu3r90+eqRY1+cPHtpMploJlR4d9ER4WT6Vu/XjQsSZUKizKDmYVtB SehcDChijn2fDNmMIEw/a18PJhkrlSVfZ+We0yR2Deyi8gdns/WXn3vk1Nkr99Z6lq7ouin2051b Jg2uBhj94R/83v59O3/69qG//JsPz1+5nS9i2/L4v/+T333pxcf/1//9O3/x/UOLixPSfIhuEkzf RtEjb4iQwFiTedNCqKaFNBq11oPFMKzEiOyr6AF0PVbUlM45m4aOVx2FQcwuy0cbt61VNmtYxpk9 cS76rgdSMh2VTKHo09DukqY6/lzXJR3GnY/Zka4B9xik2i1ILA9Ot4v4SF+a7knah9XUpDRY2oO0 uKjkF2XxNNy8JURHVBEg1eW2KSFNUpmJfOjZbLpleWHbtuUnntifD/70Ewcf2/8IZTJI7TQIfgZM GEyO9SUQV0IXSy64lO/uD9WeCB+iAq86akcXtxOpdKNilKaU6tDCGnJqLwtaI7QBPRby5v91wgLV F//Dd95lPJRHgzAJmZtg1WkPlab1WtsGTGssFspzsSnUHiwsAFdEQj6atohHVntk/S5WpLa5WWZK FMYRUzMecUxfZoKVXd0L/Y9lJxhrIhwDdGiJMuRk7qIxxsHq0nxnGnHjaFIp4AT2hWQszf+SiJT1 TaFpbFnr2ESloszJqoMwJJ+QqpdMaqkykahkvvzxUelOojISuaGeB2VAfQOLvxLLFEcqoMZGkHAB igxSsvkNpinG1BcVesQNwkJsHqMOAzPpCavqKURDYsNFAzGhNSYylqWJuFQmDP3zOkZeQ8WmoOoM 3Qo6y6AgGao8P3ZVHFF0UDKqeIRDqCON5ymdd6NxXjfvf/DB0RNnbt+f5udW+kVkcijhwCFyt7lU RAS3lgZwqQ9jnUpOJEd5fMW6GZQeRGcnboxPeRAWRO35kGYj5phkg0ttv1iHCgovNrEqq/j7CLOu WxjDC0/te++Tk11iCALv3Vv96mtPLcKd/OSPfvr5rgce+k9++9cefeSBI5+feOtnh37r1375+Wce vXZj5Z//T//2zipT1eu0YM5uG9mEoj7H3W1JVAlK7EjIUpnQ1bESSsJkwy/aVm4N5Rr8NKXATtER UZ+lj5e5yB0lEyQS2keY62QCDVBi6hIbpMm4tOXN9M1Sw6JHI4LNtBq5g60Uj5QgiFU4tThREqrI x8wOpqsWFOoAEQHrVFSiNk6UoQN9rZLIyIPSJ81lWvavhstxXYex1uJosJz5ti3LD+ze/vzzT+3Y uW33rp2RVNNmxc0kzf9Q8LgKZA3oyyaWpFUQho687os1+qsncM0zWPsehF2GgxK+9AQkdHOebeys TAHWXzHUqY7KKkkyKUygmdCmOvycK73izRqwMQyB9x65dWbtlqdWCI1U2iawSE6iozsdelN/lnI0 uSIeaS7rjxxYASvzOUeXTAXgDY/a7kQSTey0uLeVhoqzRwkFYajpLSVbRaimFPeS1eW0XAp+Dhty N2bAOo+e+0ZBGxjr9KrgxnCRGB8FMoEDIsOjCbwSVCWxip7mKMo3r61LZnoqwyzfUibl0FFlurXx lZkFrmIXxdAztqbVI6m90+gT0T6RjC8fVhKWqH1CXM4x/xZptIBNncI61IhU36ULnWYUhlhHa6q5 79HEh4gRiKBs2xC9n2bYg3ZgDh+juhbhTegoU6gzsG1EQK2rWR+fxiKmVSF1C0kXSvt9UQzL37Zy 89alyxc/PPx5D23RqWxUF7is4WQbmWlsUdZnNNkhmXuCpf1QNHxApMUg1M4XIuiXOLYPWIXEbW4o 93AEmHGrKspovDQr5qklLTWfJBpgZKkkLYYC5K7cXb95d/WxR3Z/evxSDuqR4P425kD53h/+wX81 m669+eOf/pt/9a/yMvjaN37lj/7xb2/dsjkv1xMnz5+/eH1p8zbiNUigFVVOnzqsooxTKu0Iec0w iISMg3E/zXoRTy40NpQOSqAOyuwaSSyjZ4FIErIkFDj/LnvNSI8jcR8+xmRd1UzspNo+Kikg1OZ2 aEbSsklVn8jB7qzraUZGYvgupyBUk2Ltb346yc1U0D4GqvewgSPpqIZ5BEypVz8aVRM6tcpq47in VIlCVPxISGiGG9PsNPY9RbyAbsWMR2RlL5P/GZdpQ+Hu/bXPvjh7/NT5vDIffnB3M2r27trx8ovP blpeGo8n09m08q3UkURRXtHiBxilzinI+Lq/vpk1phpSmzWWcME5O6mM8RACrC0zGLX2bBXxKuRH +QPQvzUJD1Xj0nIdDRKsetf8/n/9TxhP7IOMHc2eoENF8YKpBNbhKMocAJmjRaWHliZYxWBa8NJR HS0CdYRrrr1wv6KQDpJkGxGqDCh/1KZxaLlYeJNGjLCREqiJTqUNVB6qFAr9FDkLMIVXzaLCFkKi xZLG9gmcM1UNYERhM+hARpkfrtVsboYJNsZGhl8N5qkGHRlk+iVcbPFUK+7o1kaLoJJAQLGk7NWq V821B6jj2TXDAKlk1LqxLSdwbo5nl6GbKB5RMPrgDlmHVCXpzgHBuUTOhYMd6CTT4VUZE8g+Ym0q rtwkncroepw8qBjDXO+Um1MoMr2UqhS/MioSUbdu3jx16lS+Ox8fPvLZ8dMdkuJwUIVXJQmxGhEq GZvWQBP82AgKu5tGiBGqF8bCOTKXQSFpYCHItmmsaYl1RykQqW0BDSmGMSetoQMma8CNlcdfAOdS 6Szxfp/EEWerdO3m7V3bN9+9c2992q+urv/Ka0/9F//pG8888wRL6z/5zJO/9vXX9+7c9P67b3/7 u98fTxb37H141uELzzx25969q9duzmZ9PoEgLHbWfArE4BIlDlRhx3w5Cwttrz281KqDvPPLDSmX Btw3nYhLPR6PGAKQ8ojRsbR/D5X53tjMOqAhS8TfEWIoc+upWlaUvshYRdXt1gnTKPc2iROnrlWO 7nTGDyfcbjQcW5Z82MloZHpaNAxCBmfooHdq8A9VsFynPSQOrYCrxZiYMqUwiQpEIvf8JqxTc1Av MfL0qxu37ly/efvkmYufHjvx6WfH8+H279+nJzCAFgAccR8GOkRSlKewMj9QmhxR/kW9Gd3q2tr1 mzfPnb948vSZU6fPnj13Pp9G9mQL43FS7Q3lANpBuQro6y/CSLL5Gn7sALhISOfQyKQfkXH4v7/z vvb3S2G7wGdlDTUOl6p9LS3N0OlFv4c3IS1WavHOJ39g3+5Ny5N8mPXp7MTZqzdu3c+vb9u6eOCR PflJHDp6puuForBj2/Jj+3YtLUzyV66uzY5+cXF1bSrNEKWLuHnqwN7Nywv5TKez7vzlW5ev3jaD m1/fv2/npsVJPsl7q9Pzl25ev3W3MEx6bKEoYsioIKjq7kb8FYEWNzkelQUPOr1OQi0dnST1ZydB zxhRS2EUvQ4ynCpIFsUd+MoUtNZYVAnIKhLHwaP0M0vtkSSq6jn4rpJg7/GMBifFjyZMYqKNMh9M h2aiKhHYyHMtJiWnJC6WwCZLghtdGGVk0HAChY6epDG4ou/cxKDaylWUSxIj0UDkzkTp9pTxiaAj V6SiC1WHyXVi0sBNCb7bJlp/zaefHT32xYk7q+sLk8nq+mytDPBoZFKkAuesY69dWRCN/RWb3ilK cIjDbgNU8KbrBT1G1XbUgcSR5eYKHMTVUxAZLiBv0RG/wjP3CMsktpXImtL6oTwsSr9F2bXrs45r VH0pY/TLk/aZgw+9/cHxrZvG/8M/+z1yZ4Fmu5VUprAAJpPFxcmFcxev3rz3L//l/zLtmm/+/W89 ++xja+uzjw6d/ODQyZt3VnPIXLIfLOXDfNXdrGduPVdccoYzGhenmu9epFXNpajxqJC+iMgjkhac PDCBKkn+gVR8SjIXkEiAnA3ojWq8umhSgj6Nqms44GtbbtTtTWi1ULDyfaDYTVA1o6EKIa2sPRaW jQ7Y1al8BdUYtXGxiJPmA6TptG9IJGvWpdGopQxSTQSLHZumNZWftYtLQmgS8O6pUtVbHI6gdQju daKOAh6B0RAZIjr8M9/yWd/n1ObZp/e//MJTB/Y/OiqKojkVnfV9CtY853lgbsjKqAxOaNbW126s rNy+e/fS5av5Ieb07ubNW6vra+WB9nKD2G3t2Lb52acfP3hg/yj7GEJAZ91MaWhBZ/cEm5EISl8B JzVtdDfBwGU0n82rMfgswL//zjuksCBqvmyUI/lz0xasvCmadBdLP2yBzvJXz+gHHmn11KO7v/TM Po/mf3LswqcnLuVjHHh452vP78+vfPdvD2dnkI+yZ8emr772pH/ze4fPnL14nSaGxb27tr76/KNt a5yTcPHqyjsfneRbfPCRXS8+Pfii/OeLs1cPHT1v3YhNVKlylU2sQ7Y1xud8XzTng/T9gpGaMMRY VSC1nV5SN77PpB6dxBlobaNXKl2k0IZ0DIF75pEVf7E4J/5tGEyytgGi9gAFW29ijYyizjsFFfVL pj4bdHwZfZYbpy1XBp3kqGNUdT4gBAOFgr0SBrKhIJ09qY7WVmn+SL6pttzW+lnFiVGmn4hKggxI UQ6DTNIjuSGBkkUUQhvnTAuchbrLWA4CQmkqSUNV9FNnTs+6bhybo8e/uLVyb9OW5Zsr91MwDQVT AgteN6t2L/gJRjbzHfS2EbOi5RH25HRVFQbZCHB6QUuoyOvymzhTRCmYR6pb9CPuPSRLWrpSKPbv k5QTZPwdxXmFhZESp6ckzsgrs9jbrut279yyaXH85L5t3/rm69m0jEiMUkanQNMhXrh4/fipy//+ //o/z1+69fyzz966fi27kwce2v3G66/t3//I2XPX3nz7sxNnr+QMYXFhMsqerzCaYkdF7PyNZLhK cjMrtSoQum/A0bjN76TEpdj6fLFT9iJa/+K+0SaKoLh4/ByYd71gPVzQpZXZkEguo1uJMFUO1xZG oyK/Sy21qn8sySWPCOi7nvTdE9MKirEiG176w+jWUzWlV+HUQDKkhazBD4I3eAHuCEGaUSWG4yhG 6sD0gjWK6pMOPVPSGrtY0BbmWiTn7gGgvIzZp6LTgw0pfTINSvoTacusr6/njf7Q3t2P7X9w585t Bx59dMvm5Xym3Wzm9f05kyjfm73+bHrx0uUrl69euHTl+q3bqeeyRWSinaQKVW29bKPsS/Kz27q0 +MpLz+7aszO/bfOWLZGdGbMpMMyNn2YQufIvaqFTKjGi4aY6T8IoMCWYtmAVpSzfRK4bg3UqWWRM 8VNECL5fVEoxVJZ4cNdWcy2Xr9+5tzbdu2NzR3BQ/vT6TJxil6SH4PH9e5n78e4nZ/LbCody5f60 w3HbZL/6yy8f4Pffun3/5u37O7dvyskNP7ltW5fNtVy6lu9p/9DeolH2+CO7r9+6f/7KTak3Yyke SnWEeWlUF6FYUXV/eyFaxKBD62PVHVHlYMsZuD0b1Day2jEpLBKsxDad5AWj1S+Yd6DHFEoyS4g0 VFJBVE4Bh0KpF14DxRyEsyWo4vTCj1TKeGTegbbmyMzpVMUtkgB6dRxLVJqZ5tWhzg8V2xqVa+JH oglMIMNPNUOOUfXMibUKQqzw3Y8y8VQ4XSLoTfoHyILBMr+Sq4IgZixorxw3FmnW1xKMMmobTnBX bt0ajSfXz187c+7c6fOXxguTpx59OIfrS8vLd+6tW9Qnpp8LuCEoVRiUBcTAu5IRdCw5CRkjExGh 0VFBVA0iLCtB0BlC3ANImqrS31ngzU7GtuloOm75VFk/emrJ/FlqW3nWeUP2RPqP6ltLYUOrcNnP nT935sqlC8c+effXvv7aP/4X/3x9fVq0HUdtDsDvrnZXrq2cOn3l448/OXbs6GIb1tbap174xmq2 KXu3j2HtwoVL//rf/Lsdu3Z/7Vdf/y//4et3788++uTkh4dO3Lx1tx2PJgsL+dQauk1sGbtOo3Dq fi23iFGvpEODSJtHLKwW3NuG24uo06DU58tOY/4V7xYpCCvqK701tI9GpH0P1GDFFIRZ9mFUNWlI Ci07XFVjKtt53I5ytN7SFBwelo0dSquhQbcy20q4jr02WmbvzqUIumBBlFUDPfkuCx0DAKboGqHR im+qjbJSrBK4PNFED6UuCeun14FCSvBJNI5kki/q4rWb5y9fyx/dunl5+5ZNv/611w8eeJSYgSSp Sbf19v17t2/cuXDx0vkLl27cuIM9NXW24zLgh9VrpEVMOZYJdcxTYZwvjCf31rs33/6Q3Hp4cO/u vXt3Hziwf2FxQqp0PTpR+YRzDTRWE62bliVmkxaHtYJPzC8hugQbTRo6FAIJw8u8lhoVAaFpeX0S 98xBerlRzz3+AJ/B24dOnblwsyCTOT2nAa5N6boKrlUIUIVk8jFvrNy7vz4LMjC1PI9nDu7lN+e8 5+iJK1CUwLLXEaj6afptPsL7h0+fu5h9CW7fdvWrrz6eF+XLTz98/uqKYB484KTwNTogv8iasn1S 4gNRJ2mxShCurqS4ANL05bGpyB6hR+4px9rnrlY51QGLoPEa232KoLIlil6QhgI41iyyzCBK47+S UIVGJXNqIWqVD0R6ViiYybIrtLdBHXwZVJQaVGun6uMlqyopNmTyXzYJW6BzleUWUkmsdBodS64k eZ5fC5Vea1Rwm9Mm51a2ahKaFNOWoNaUqKmIx8iTRIToYedHPKbAPwdsZ86fL8HHzZsLi0srt+5e u3U3X+J6Nz1+9jI0o/VpVyfqadu5G6ckkLMMOlQZMB6UWfrsYkQdBBkY048ysZErL6qJgMFiY9EX KAyr0hIkIAn9FamhjygGJdbukw2/0acjzovE3stiaUclB+l4WFWvybE87iImv756e/vevZdurOV8 IFuWazduv/PBu6trcOr0ucuXr9y+deve3ZWXXnzm9n2MW5bZ/OWofS1uXty+3C7dQVz72zffeftn H+7ds/2VLz33xpe/tbq6fuzY2b9+83DeFps3LTXUkYOiDC0DxUVFVDqtaDxUMNUFreoSO59zvPyL UdQhTEzPo5vVU3qdo+jGtI6c7FNDNobQJGB9lt6kj5QTpJIaNOilfE35uum0l851VlUvHJOIgttI twqnxDYKXdoN6TOcqGVHyFpzhPIpYbyJoiNuE/NssBclNNZdyAL0lTWDMvOQ7yELn9PQk66cPBHl iTlFbUaAo9AwK3xtvT9z4dq//bNvP//s4wf3P/zIvoe2bN16/dbN4ydPnTx5bm1tSuqI7biZFMa3 Sj2DqnQbP6TvZBBWnZLJUDyNYMh29dS5y6fPXfr4k6MHHnno1ddeHo1HRXvFyGaV5FkRL8Pnpym0 xQUAt5oQYTVoK3nJVYrJ5WLyqAkk70hilNq7yo3z1Bom4qEUFhdguommOVBSy62bFylruX324k2d KZTW1kUryinxA3c8nb5wfff2TdkZ//2vP3/n/vqZizeOnb5CXH/ctX2ZKBbrn568bHM612eEJo/a PTu2FKDsysr5y7d5JeWk5+S56089tmcybjctjO+urjNBa0TRinRQkyekfU2zUcm8ClAvg6uaJAOs ZCSqEfJAWBM2J4X6/DU1KbOnpJFeJ1MCDbEhzr6JzaVCiJRUqVFuMH+qIb9aQCesw1lt5FCl9xhl 20alNBVa40evoiloM4Koo0M4TpJd1aoc1NyfVKIRVU8FvAJCLe+DsWhqK76lTTqSy4TFrWdeGZ8A thw0UeqFCI+qVCokRtoriQmHsZC9JuPR2tr9kxeuffLpZ7dWbtNQIi6U3stvLY0OdCtu373XUizD m79UOCtuSJKILFmhjNOoLWk6HFu4zklACxH+4do1hwG9xKpMkZNpItoZEKkBTINb07tjAy0zjCMz mrOJaakZVprWKUqL5L3L/iJzxaJVeYfNyNGQFm/atn3X8vKmV1984kvPHbxx/eaNlbXDh4/81bf/ anlp02y2vj6bjtrxG6+/cmNlfWU1LC6PpmtTqbFThrS0sH00gn5tZaFJ585f/tGb7+zYs/s3vvbl Z57Y94+2vnLx6v3jJy/fKBr9LRnkHBeTOQYpa0fLBEo61UnUmS08yS2zhiyVIgrCRtqxSLBw4Lp2 rwVRp9XIo9OLpaaRKlSzjPSPNKIWB1+U92jRjtqGh7gUgK4UPguEWG4UGS/kWJh3Mthqj1VSi1Fr eqEzFRn9BZfWJeyhn8Fga9IgxzoLUtrsOlpfGi2XOL5L2hbJaiNkBHpqBcrOwDDt1M0kDOXQw02A R0Ig8+Z4/+PP3v3g8AO7d+zctf3ajVt5PS4tLBYmGoWnQis3rSNtqGCcFYRZq6xKuhmsF6ytCjlT LEKu01n/SQ7kr934+q9+ZcvObevr64JuSIVaupujnptNtkyqBy8aZwpNUMkg/P9sfVuMZdlZ3rrs vc+pS1+mL3Of8XgMHhsbYuzhYjvYJEEoQpF4wokSokSKBM95y0Oe8xaJp7xEioIURSEgcQsYIwgO SkAGDHgc28ytp7tnenqmL1XVXV1V5+zLWln/9/3/2rtRBptpd1WdOmfvtf/rd2kI28iGk5VSC6IK beAgC84NgfKufMfeaXB0xnMQdZAGV3fbT0GVrGyq4vISfmZD1JJdDrq2/dgLV/Z2unO7q0997Jny e98UlQsDNytKRvfiOHO+ehiVBAvoukft4DdSq6rMfm0shGRDypU27cza5MuL53NWhGtwJsYFW8aE p0PF1V3VZ1ZypfNLV3enHQ1ZLqXnthJJlaOp7ZEmCmlIqJo4B5jNtKj3rPJfdV2/gE+bCFeY2Y2E t3mTfc1qOE8hOIuMarWSDfubKOtEVLfzs/EQJZYXGvJWitpglPMQEydPKpVhR3oGcJmhGUd+swRy 1RqxatGwPMY/tnmdiVPO1n3lAq7a9vTR8bdee+vtG+/2EkUEh9p01iwa50eI915JwVkDVk7z6IkR MZopplpISTns55Mj9ypP1ZMcHojq0ypTHVt78sW9TSmDrvonnB/YXJk3tnJWcq52QaRPCUkQ8z1o XCaW49Jop4niFNMwOkUz+s22L/+su/CR566+8rHnb9y83XX+8z/2Q3/w9W/8j1//bxefuPwTX/ry 5z73aqmJD+4/uHf/4OrlJ26+e+vhZr1/8emzs/7iXljFcW9dat1m6PvTs5P+VKq3B6Ed20svfeJq CdZf+6PXfutr//vcXvuZT738hc+9eLaN1949eO/24XY7luc0dFhHJOQ/4jQCufSzKJmo4ZcSioY5 wNhxTtBGRQFIGSotC5bzqn1nuFoiZ7Cm9na8aygkLZrnphyGzXYLIZmoeqayk5fLKw5wukLPVdmK Tq/GrJ8eW6NC7wUTDvTj3Co3geLSnI8GVa9Y6BajlcnqTaZ2GWIFsDi8dHpWgyXAlGQ2S2qODUga zHWYXctNKf9pZNOFwWpoKMcZm5Kz1+VXHTw8Kd15AGHzpNtgFBlo68jLOIEc0jWtuUIoHi8pWjaX ByeBxTlVs1FcgPI7GVO7rrtz8PCrX/vjn/mHX77wxIXNZmvutIhOJrZk9bEqF8+mcnT4cDWOIWh/ 5Z//YjaCgl+qaaKYjOZ/7k2FhNPCaLNjGLnKj7zw9KXSWOzudNduHciYGCBOVRZx7uL++nlsR96+ eafkyQZH4+Do5J1b9z64d3zp4l5pOy6d33vj+oflcXr2yQuCm+uae4ePMOLQ8UvC/PH5py+Wb95Z t9c/OOgnxUd+5pXn1lBK/s61D7CdSupxr7W+51tvIDQZQXaaUp2SYBWmi31vdbhzs6zkY7hyFcR0 1UDXT9kUlJ0p2y9W6HwGK/dxYetiIlRZUdeQVGpCvda2g+DIq5KKF9xCs/ANj4lOzkAMs0ezPmOm 4BN3u/iS45pniYYMVbWJ9z3bBsYQW+Zh5xWJ7KqHzazDaisV/rBVNiSd8VKEWU0wVDcC/AH6qun+ 3Tvf+LNvXnvvNlS85ezUR701ZERUHyxarHtudLkvVPVbjOJpEAAsQOBJBrzC08wmm5wA663INba5 pFRSqcr2GOaYKBid/ynCTJYWJVBGI5RUnl02coBYGcuRnmIMytEV6y3QxV2wAWkpKofSC7z47IUv ff4HvvKzP/GZTz535/bbb775Vsk0v/sHf3HvOD3z4iv7F67ee7hpQrr7wc2Pf/IHLlw4f+36rfff e+/Z5559cPyohBQvz41/cDocPRoPH00nfZzCOsed2K7Rm4mn8mpn//zFK936/M1bB6+/ee3+wYfP P7v32U+/dOHcXnkGt5vxbNu3ov7ZymJf4MuTnQBfl9uSehj06YJRqlcByLJGA8CaZRwGZd7M0c3i OoOWT90ZuS9cxXd4hWxCT9lscM0xm3RXPbeN2hox5pokp4Gt7F7o+zYrilBBhGg2FDWqvpmcoylA 3zU24tfeyFWtPwziUDv66hNo6qu09PXaaqtBGhj7E8TKPKPMlGyOZvpLWTVhZZ4meHr8diTxNIwl H0mqKD8lTpqT4ExKjhoH+afHlh7/fxqmqfzvcSz/HjXrwrxAylxISpQfJ0VF8IHD+M47N5+8dPHq k1fqJHupZ4k9pQp+qbiUq0+0WcCw8Sln6+f+2S/MEpbK1bQ4VtUyZRnjS5JD6a3A5WlRmzIwPXX5 XHkqPvrcJQGctO0rH32q3Ozjk025nOd2188/LdnlrRt3B5ksu/P7O4AA5rO+f+GpJ3bWXfn01969 U77ndDu++MwT5aVfevYyP9zHXrxyYX/n8OEpzFtTST/lyH3kmUvl4pzbW//Ip18sXy0/+OaNO3fu PWTEjbqaBpCEpiCenHa2KTLtmEOp6d1W8x/OkkM9iRZH8Oz4Kgdpi61AmeVgrcOsIxmCpeuQH0f7 mvwyDMXBgwqV9umrOOPM6l/4KCzpILMzSyWF1L+ftyzG/llu6Z06YGqGqNVWCPFxBW43K587p9eE b9KaJFdxdMb7IQEIs++aKqkFouDmsJBkDsp80pDKkzf121u3bv3FX7927fr1R5shNG0wPUvub1UR zNFiUU82W8kRAN8ogUm3QPpoa2/jVL7INGzMxcf4H4EL1FCl/gXf1bRqqZnMQsGpGl4jRQGlrHUC g8wCiXiuvIKKwzctNtPmu1WyVqnzyd1TOjDvAi7P2aaPPv3Lf/L3vvKzP3nliZ2v/+Hv/PIv/4dv //WfbrZnZ2fDtZt3rz79HLTphIx5eja89/6tB2ducKujg6P17uVzl5/sVufabuXCKsROmDJRaH0d 3hsY01UBQY6tvOcQ1+u9vXNXzvr49vUP3n77TZ+OP/rChZc/+ky5xMenpYkaDJZG5H3IKvg2zc6P cGxF+pRaYIBpkwq14ZBTVyabemxQu/ZMDqxIJieCU+UukBSbbSTL+oD8G1uQuGrnMC/wF2xo72oz o3plEaU/8pyWlM74yFofzQ+er6JdPKsRbITgqsEBa6JQ7YRDZktRRQpdRaBTE4VnFWsY1HNqSegJ gVMRhDwRil1lev3jhHy+2CjA6pF7HQV8mvhLucIlbSBzJCAJzE4JF5w3kfUQQadIbTJ52vbbmzdv jf323Lnd8rv3dvdmCHYFg9Yq189q29lsCYNCoJz/71/9c2kLoDPmTVtwMpL2ZJLLjxtrZmBppIn0 WA0FDMd//IdffurK+SVK+Ltvf/C9a7fLKzz/9KWSA8rf/O4ff+dM4PPuJ3/040+c311+82uv33rr vXvEgX/6+5/9vhevLL965/7xn37rHbIRv/CZl/7WLxJpy5PNH//Zm+XuyWyBUd5EvKaUF0qf3gBC CvPNOlILicxEW9BCrcPsftNU998K1MaEg7JsVEXw5iZjGBMdN9k6XXcqi5WGW8jlEHbh2T0tFY5z ZfpZntBRnSHQFuTCbNK2fs5zprnilppCVUfQV1UlF0xbxVQS5nftc21grfdwupCpakAmh2xMWKPp 6OBc1TUwV0m5pkn9jbJ1VbQ308TNm9ev3bh59+DhlK3L8LZVStkvkiYG8SGYup1ikDC2bWJkRzKz PmWKMjEXUltzMp/RBXkHEzSwC6vmnIx81T9SYKyQP5lV21FYymRMLRUclZVlgb/TdRRZmChB4bjE lm9AlM8lOkAbdOKyxxv2s1SmpU/4V//0py5fWP3hH/z+//r67xzcee+pJ5+M3bk3rh/dvf/wlR/8 wvmrLwPkOGmOLL3OZrOzt//yC5cO7h0N/dnhCUZGbQNP66iObpkI3awVPkaFUuolRfcGgF8miOWc nT4YNg+eutw998zVK5ef2Y7drQ8Pb989wk0rybLFoAIdoRqAqbBNI4O/OApvYyqJmdsv3krSiSbD iQkayim2IQBNy5V+eXMlRY1wORPkWD9G2T9JoQ1hZhmPY3gY6+3TEsEkTlieqwDgzBMBqjO77dBz hGdLP6VjK6w8CFGJTxNfVubbNkKgri2A1ImqyU4NnkOqD4/ndCfXlU9lv/OJBw1SAppXnI7Rw6eR hRQmIikYSIcbX9R30VdiqQYF9eL2Xp1t1X7cWoB5vlcNYZ1bamJ5Vx0KmMLlDpbT+8r3vfzCi889 9eTVtiv3Gl3SbG6wsFrGBZ4MM8NUEr/y878YiKqUBBh1lJLMSld1FZzKAFEb3um+1cryQOTojVsH 5VfsrFvUGrk01OVvjk+35e2su/bqE/vlwb5+674TJZVcuo2L53b4wU/Otm/dvPfm9TsqXpxLLnlU jg5Q+IFeL+/ePjw4POUB+uBOOdxuJT2zFHqlxHvv9uE3/++NaapSDaYIT+1LObcIW2pR4OoQzKlH yGN0JTbrS13phSGChZ88U+2y2mGpPL7xda1/WdxLUwi2KcpjfYZf6v1Yqx6ql6PNrypelnzX2ZzF MMn+8YWN0Ug1Zy7bKEw4XbURUweax+D1XE4rfox4bR04JDUEdroJryR+EBJnnTMjTrPbiPW4V7OA UFd0Ek0eHN7/69e+9fq1G8envcwy7SqFpYzCwiQmNtEMe7zRIUnbV9UHGEGi2s2zH0FA4pmqqT00 v5lZdbqF64lJsraqQtSN0aZjfp5b2viSb9WaJPlCI8w4QMajaR9Aahv1uHw7lvYYkmBjYfLmcun7 fvvlz7/y/S9e/bf/5l//0e//6rnd+MmPf6LPe9+7dvfg4ODVL/70+vzlO7ffPz3btqvd1WpHBiP9 lidcWO4hn51uQEQJdZ0G1qLLqkkhwbeJqmipDQkl5dVMM5fk0XW7e+cu99POh3ePP7zz4TRsX3jm /EeefxI01fFsM5SY24rJZ6NqHQwhlITx4oAZMBArv194gvQhFiBDmJ1CFEPvTFNZFtrMviQD0nqt HCrBd+AWtG1L4qqU/E1Ulzab4iZzUGBCDYuZZO1OEPXhZaktr9rVcAoWrX9RGQ6VgJpwo0P2BlZB ZQntBq6jo1q2L91WZjhMNOMlW7goHYEL+WA6Bnlh9hG4szSDD9JskkxQdQ8FELY1EODk1lV71dxz 1RHOmQ9LUiE1ZWVRilDZoKqlJECMEsNv3nr/zTeuvXvjVjldXdfs7+/JfigGzDC9dKjoUtlprrpy 62TzUG6QvM6v/d43VTgwEK6XfTVUYzmWlFxKA75gWD0YcZsxF1eapvyXaENHJHgpLauJiEVxLLjk uszqI272wHWmmFYX5mQsBlM8dErsIIoD+yF1BMBgxKT06M9hRH0VrHTmE6+aFrYE1nW6aQDb1Mct ldycSUYt7A3URVW1bbDvAXPK2TtU2wwD3Ca/dCjOytzMJvek2IF576KoYnWJnsU0CRnzkwnOU3JG pKjgIk7iS5XdDX9rRqzAktyCT15KssZEe1UTzJmZsJY8lVhV3cqBbfNLQ0hfLXLh/ZeSDrtU/ssc B7K1LOpkTHp0lBl9yOPwO7/3+4/6sVS72FXO77ZyehgZeWLYpAZlsagQKotfEh6tXwPrJYRkz2Fm o2ogb6L7vDqcypiqPF3jQNlEwAJjHNTrBYYlWSWlg0x+Bir883hES4cE2s7WYfDLGqFhVR7C8lOM JqVHmHBA4LAordQk4Hcx2evPHnzxcy+ea4f/9B///Y9/8Ut/9dq17731frda/+Bn/8HO7lo+TVxN ozs4eLCZ4rmLl/Z3d6ZxU672lSvnh+3p+Z32xvsPsoj3E0JNsFMymrBcla5rE+SnOAnknznZaaUv GQKUC8YprVfdlKazzWnM28vnm6cunWub1b2jzdnYHR1vyuO/kqAjr9KPI2iSMtoQMWAiNenNRtZ6 VsUXaCpj8ChJSN9AOQY7664fRF4hkYKIpgq48FkyQFSTx2kplRRBCE15Fs9npTiJJfHE0sGZFabC wQ0zHKLpVOaqD6ccZ6DR7Jxwf66A/Tx7PLK0rA+LwW1MVzs5soLyLNQIotyM+tVKMFBJQzE1AQB5 Hc/i7UIerQpRuqrk0bSdM3UstSnCq5XTR5cTTb5q1j558gFmGUuVHqjx2NxFvKm1irFzKfeff/7p C0+cc9ISbHZWq3LTV+t1eTp2d3fKTbp3dFRu4ZUrV077zd+8/rb/ta9+k7dK8m7KZD1yNwY9GNeo fiJqnEQ1NEEtW0s1+xTOIp1EAyo9tRxTQadN1GishCNwbTi0rUImBOkaonzp1Ml5u4qPeAoHOE57 aNOdzUYlVwOOsPR49tp9NkJcyIvohuif8PEN/jzRm67iqQw0OZv24GQAF1cdt3TGG+qwyMzQ2Gma bq5x54iKAWE7K1QiL43r/WMSK365QqlSsrVJN0M6V9UHFonEWVZTmcvqFxFMozxVTxIFHeaaKggo MOHfrC4CKoO29ABfLPug9Fodno22Yik5pVk0zNrBhEVFf3b6jT/78ztHDzxkuKzvn1G/M2eNaD11 gdPzB/MhHbijJdClSDYIC9GM2B2C+u7nqWK0rftoyvmrJg5jwlHJKsFgurJdi8w3jlBe0eV+BDKK K27WSYjLuXxbrRKg+aj6XZR+QTSnf56krgH7VVO88dvtsGr6n/n7nzo5PvqfX/+T3/yN31ivux/5 uz975flPPDw+Lm3ENJyc2+3W673ynfcOjh6dnq1We5efvPTxjzy9PTm6eOnitfcOP7x/Ghaq3Ui9 eH4jUUWeu13hMIbykYW213SdMuIAwSpfFSd57yXiA1Mqg8y0bdLmwk5+7vkXynt/cDwcnjhgcyUV 4aGWYnCEXSwbFRLja1Edkb/zEouFP4q5m6hBTwRGScKQ5CcwKkpDjlDNDNyuWXkOra14ttlWuCDl ZHpMcspd4BAsW0g1lIAOkLDU1vikZCbj2zLl52qzqu0uS2S1IHGgYYtbMwzLUTRMszaatilUlksK 9TQGWKb+hZ/3mrXhUWLNPN/ihM9xqBtg5GcFrkFs1M9I/a5UmMd8XM14cLEznycnvrq2L7SZvXq6 m78JFDunCsukDQ8pTaj+E3tT3UH++te+KQQuKcIkCoxgU8Y065eResEprcQaDB+B+lALM44mKcif tARX5pfqbpnHYTDPVMwWIYQcqU2U7e0+Rh0PhgjmLBU22qZ77ACJl1ulUbDxRlBRmXm+oILTq1ut W7w+rnIkHlH9gNVBhD64GWgOr95libRUN8tDGv0ERSdXsr5KLtMWhwY5eCcxpQrGZekUVGreL2zY q8mjGTbbMo32y9Jn+DwzVcxpRvVRPRfRxtVws7fWLD5X336jQKlcU7mbNftNkNu76mbDU5+8Oafh q3y9aF0OBQwSvq2ZP5dhTqrsm/kk8GAIymV7euOd62/euBngb09pTjMTmP31OE9ke6ASgggHgcJn Tifdg6mMVPKNKqKCeZOq5QU+OaQS1RNk0/dAAsC6TVameeFrHrQqirGi/TMW9dmI6PBpT9gV0+tF Doy49uIYlEoPnGupkQeh30v13ZdGLTYM4gOkowPkhdqSbAYB+eyu43bbs/GWeOpliXLWD2j7ytUe x+3Jqg175y+Up+n2uze3rvnISy+V9zGePbhy9crb1+8+9dSle0en5QHt2ubewUnbtVXMGAuGUO0B ZQMfg0k8Jy6TShMjb3hK1gpMAsyR8zzurkoucG2YhtPD0kKtL70skvLSEgnzfNKJFqV6kq94S45h Y9gC9cQQESlpjckpniOtxWXMhb5EQGheBjKb7cYBSawmI5gHgNgET3vcIC6QJmlbyl+O2AEhlU7U 6vT8IOj+JV4a1DPPqlwmFMzEUD5VA6QciNXUntHuxTY62gfVbQYLKVVRm+qzUg1ivMYVc3aiXBNO ZlL2S5jn6yqBgT6P743HuyoVJ7M6hZMTiENR1TqSugQ6w5ArpK3GMP0US91C45XPumZY2Nfs7Gez Iofckx532YCyBqIcXCAnjhI5yMuk+EkNOGEbo5QI0lno+KsWv3QJm1JlPyiTgOh44alMvmpT0qir xDP5+2zs75yraacWMHKeam6XtCkzPrICq4WUQ3+XzHFKg4g1rBgcVVvimVBi5ba5b7kmaIWgPRCu ockYGkA5U8KoToYiTkZS/8fkyEZWMxjYKZZHpsZQFo6eBGYlXNJzhfjdbA1MnjWZna+FngXYxY0z vHX5mxZlRaZQBS7+4Eh91/WmDo7MlNQM9TwfzmhKubVVnGsoNRV3bLMSjlRjPashEH1NZCTkiNxE dkbOUcPfhaOUXyKnyWk4PXl054Pb79+5l00j2VVI3qy9T4C1q2snsypTnWxTAIMJQYW6sbGw54i0 CbL2FubImkwpgNS1EatBtQ8xAw+DydkcVZ4uTBJEpcolYv+CyldoHROhLxCpxCeP+pSq11aY/cMk DopwlpyctQzNCDVQH8CHJ2PXrcvF7wdyFaYq+QPZ/KY7d6mkpoPDRxcvXvzcj7z64MHBg8P7P/rq pw4PV1/6/Od29/a/9Z23fuU3v/7p73vu3bun0XBZGCUBGicqUBDmaqFJLEML4at7AZilVeyg1SjP TYs0LEoE3u92TT+UQ9tu+vRoTE28tH9hV+jjseENGl3mTr48t1jSbBsxl5ys2csqaknUDPQIolrT yo0ap5G3pmvaEQ9nE9rSPI3wHjbClgp/QaIfDp6tT6rg70oqfdjLJ1uvOkhDioxmpnWj11YB4LTc gjMPSh8BQeUmpso/Y8ncNsHECFSlSblPC0EKpZKY4UTQWK8fc2GmZ0JMaoqS68hqpsKj0hRGqqeU J/SYFdGry3HoZ1Pn2bg1BGwlYo2nMHrVHEPiVoTLbJqstN+MtI2PpbBJO3tpGBKPhM4JdQ5gPu58 6My4U2vFrGAoCa2IUcGbBLLHxkJn3Gn2P2eFS1oA21JDLPhFnZytjpbkwekf1GTxgyAIRDAzQcuU eCh9JeqgGuvry5oemoKDq0gnry0g0ab4W0frlT7tCbObVALLV+KkV19UvHhQeWKXjVgIolgw80OV U6SEr4pjpWwoAA/ChnwYrJGdAl0cQYbVbM6rFQQSZaXMalaxjb4OZrI+Xd5VczMtii3gStpItZ3x et4ojzzZYYfmUlYJleyCqb0Hq8FdUCWYoLvrrNMcE73zi+AcFurMGHp5Xjs/4yNZ+dj6yYzxvM7c nFlQLwhGSrEMQOVMd++ITrhIENna/DGqJ5k3RkKMVNs0lxmvrZoyPVuYWU3VIlN+1wRxjUjYJfAg rTybU2YbkZWNEaqvcim0t4JQCva73DhMXSe2hg6LZZaoERbx1M0z3d+kIspQgZRRmA7xpARB/a7z N2ocJEHBdKBhymEU6n5SE6PcECcr/D4uqJRUgxKkEXg0+zZChGLbrh4+OPn2g6N/8XM/8fKLT119 8vLNm+/+5Wvf/cY3/rLk7f29ncOj9fWbhy+//DFRq3TMmvIpBinMEUTko6s1kSh9hVzyHB+3Po11 eNJGTU6yuYXAZvlmuc5dN419Y/AwLhHazoNjIHADsf9aIBKJzoKaRaJ+Eo5iQhmGvV1JDN0qQli6 vNR2u4X9tSStSS7hRJHgvh8azCpJRimfrjQrEFYfmD5Xa3mf4ossILRW9rgQDeVKiVNavufGQrBZ ggdTDVd3IqcSDA3nLrB8S9r2JxtImHOkORjKdk7c5akBIT5AOGWmgK5ILzY9yRKGS860oDharKYG 2WflLZIoKirSMEaT10zz5JiOJFh/ujSSihT9AqGtOY87IULDgw1BsmITqv63ufa5oLbkumSyPU2o Msuq9oLpBat19Bk6rxB7UdBIaSZD86ikImDcuKieVZ6tOE3WXnVwebZoG+w0FnNmQ99fhH4rwinl PWXVMvDq4kfT7IWfgQpw0VjUm+WjB3DYqVeHj9Vs2KgVfiaOpBlIpgUUfp2vdlXmsg5Uopw2NYsO poXg1dOLl8UD2iBl+pgqKJcAaJ/tcs7QMbsXyqyc25RqEKC+XgulFoiL4JgFFYiblxi4dmK+JjsG gnAp82yZLai0tS2IGK2sJcrzbFVfNjgzwsz0qgrLDVBVjlWRWOrF1fWVN6UTdRuoidN0TsyfwvKr HIiHDw4OD+/dvXswTBi34rCnVMnyaKbDLO6tSE1VQawCnb4W4+AkirYKh4TBL8yJcsXs5S01+bXL lHe7gfpFG6kyEjHugiACVGD7sQ9t49msILtUtw0d4ZJzwHOOAUC3ahTnDZIWBjt6AUotfbbpwaGJ lFmHYr8EC9k3VPiTblaNc453E2k15jMVq+hSTB5jSuM/+qlXX/3hT7z3/gf/9Vd+8//8yZ/cuvk3 ITY7e0/dvn147b27L7/yKhYnIx8KjMRR/4UaUCTQSLAmligLIgu7E5mcl9Jw2oxVyFkkD0Xyuc3q ZaL8edn/T+UmkALlhmGAfrN6jTOFaB+AlY8HLSYG+o9p0SKY73Eq13C77VGByKcs103UfHspwIVY K73RaGL2KpdA2BQ8wabd3ZXZ9JY3Lx0PTRMMLS91WOIEz7P50D0a3BycOgiU3yITSw8yo6pRaDzL aQQzPyoJyNQ562iJxbc8V8b7imrSmywR6EfG7l3FlQmt8nT0w4tMWlin+UiUfpeXxdGY2dn0TKY6 qGXp28ZnBx89tVgvV32FEefHU48RBmvqNruQfcPYMFRqGlzyTMLEFK3MV5hBWP7c4PXLAyO7x6Bs 86TsBxRQLWhNuiGj0Bt6zhFbwbpuyqZLXyWw1OQR4Ua955KwY7zq0VK7SZsM2wwrF9y4ApDkAejQ 6QImz7bkda9N/YiAwU9S9m/0prarEySkqwyspMrcVtV1V3fx1KacZaYpZJxS9VOJwVdX0az5KatR NdtytTl2lMbSZK69n9zNSO/Opbw+3YaJWmFLbgQjO0YKM7Nh2OwqXxtb7SCCrxjIbFv3VJNruSPc l5iIP000JRtZi1yX7cEM0Uwsw1cgL0GtCQpa0fyeo8gD6cQoZadKnMmE7YzV7Jf2oF4s4q/fuHHt 5ntbCGgLh67iYLzFUwBoggJ5MpDGemtVYFiqXzIntBnHWjqzOcP+Q8qRkTMEpXxylG/DfSn/x9PT 077frtfrNEhb0HjQIzGnHTbbTb/dbPpxTPSpvXz5id31DpV1qj4oZ7IQY0b32qo6CrfZVCGiDr8I ZDGMocfGilpSGPr7RKVLmECFrRsb21dLqSuweh1ZQDMsV8MuAV+N/Wd/6GNf+uJnfvu3vvpLv/Tv nnrmI223t7e/0zTrs+0wpPjxH/ix1e45cX/BiYeIJJWSqIEkrRhdjEUoCzC50vGMoreY1TyNMZoW 0TrHDvSINOBWVnQccGDSL47TTttw7wg9ITdIlnWt0GHiVjjkE7t/3RKryKS4l5ZP3ct3TBCtl/Qm UR4o2PL3TdcIfqBcK1GeaYSODnfk8rOrdRdamYsQq55T5K6iwT0Fz1/Ibujh5DUppKGZQNeWCssm iR9SLnGiJbRHNc1pXsQe2s/sRCblYO7djqh0akAEFewoH6YcqQbvmbiwEdpTOgZAfxzVJB6/XqCT cm9QFvi66QXShBskhTZH8JezU10AZ806WlU4QWSsmsQDR3rhbAO9JqgLVDWANLRbNjC0Yl8Tne3Z +yZhckKshD5ObhaH5RAF2TFxYDVmCwRIHgOustTFTmcp5V9jNhWrYPCt2ehvNg/UOCia5BNNztVg 0SukqBJ7/XIAgmjA0+y5jTBHuUVcX5pOiqYTjVV8NJeq4KrqKnRf1K7Y5ToQUqJ4suyYk0oDKR7B LnGyoYfuU5bUZvNbqzqXBgJEWaIfjWKUicU2AfGoZFmDm0PxjFBWEr9On9iBVslich41r6RaK1Up bI6LvOEXgmLVAiynlGgIa0igD5E2sItTKiLl7oKbJZmxjFSMb2ZQUwCJ4eiDn/FlCLFsnysJN1s1 FxYdZPn+k0fH3339zQ/u3jc1jmqhSgBhjhppYPbrFbpTbtMAQQuGdbanESgAVqSG/pGiGgaRUOSF DxtZMVn1KrVTL/fnZHN2fPyw74edHZF7ONtudqS+lM350YPj8koCQ8IH2Q6PWAenu3cvnD+/s9rp VqvywBveTD5JEo5IDKoyIkA4Qc1m+odn4ERCPww9uZleJXakHvSE56Kb8cLlkmg7yitQQKUEnM0w yFAIIWPdQsgL0xIBi6ZcMsH33nz/P/+X3/7kSxcuXdw/vPPtq09//92j8vJn693uE3/nSzl00zhQ hEbA6F0reKqk4iirrqV4s2xHcFTYvrNMjKqS4MjKpO18CRqNqxKlTsUfAVUoL9mCwrlqGwUXYuRG +H6A/h/LbXYPMehUE9YsAnAoz2O3kqeFutGTn/Cd8iNtG/teCrgBj0UsDU05E0jMgpBtw4Jj5FUA H+Qb7hVC43nRBMUwCs1I8IojVN1Ay91s+5XwbSJR6yUJ0QRT7h0SkjUEshehdjuTWICyNFKgzEgF IhHEHFp8c0z+sYFderm/gsfDxJauw3aE4cZdck0T3FK5HBMwmpnWaJugHYU9p+4OgFiYQDdzwE1q HBSdSjTrIxI5sM7sk9RiCUYJfiZm2FCd6LKZaCC/VKE2dd2SZo4KhZRyHqln6OI//vlfEOyQVwwA S3zuw1F9AqoS3JCJ0lXktbbr1bkvuOVYvY7d1Vk+2MI+VOa/dws7W5vs1W5DqeN15zpzUxAAfZj3 3NQUqqYLPFiVEWL6A2qM5tT3xGtdoZK9upLJ9rRXDQijBWSnEh3Omd+4rXwI4Ao1Vxl2wM/ijFVO xufZgFWXK/V/z/YnPkQT+o6mvFDddiy1khOZ6xDFmh4i/CzYoX1X8GUwwzxr+zTNcPg52cgLmZUK wsrBCfrWKQ3ts0EnidDLij7xwQbGdXGfkeYxFXAVcl4u0/37977z3dcPDg/dLMivn41XissKokXK syr/N44Pj4+HYTg5eXR6uim1ePlv6Sc2m235RwjhkDR3bpaxAdFkAkxfgjLMRr2vJQXu46NHjw6O jpJwUBq+fwHsQr3p7Oz00elGtP/UgzKrsCAmwKdnZ9ttv16vyn/ahmsdD2IZlVHIOuc4gs4ggS5h 5QW9iCpBQ2xMlWHAwqWjAKRKzacSRkdMejAKkxM42RpAsPX4UBHRinLuJdidnE3PPn3xp3/qp/f3 n/6rb73+N9/97vmLT3/2Cz8T2lVJarw+nB6Vt12u5+4agVTeYUxKsnNcwwDSJnth4j9ZHgdzxmaX WaJ5P8hQRVRkcOAbRZNXsW05BJxFU60tOHYPDpHcYXsx8XZXkS0VDA7lgjTQJhnaJqxK7gGrfzTO PGn8JXyjIXP7e2sMxrMiVrL6nbBSKS0yWDXUsFHF7nKFWyyNpNEBHzTq1ZBqBshYCSjKoEq6TKo/ zp15qlbkRDyhexDMVhNbbfU4dsZUf8GDKQ1WMAlEQhAD5AnUiWM2sSCQI9vvdUTjMBPQEYUqSmYQ 4gClV19Y5RWrwYcCK6qLM3GAcMdjPwQbQCtRVeVQ1/iK6UUryXmyvGA2t2kbXqmmsnzwX/29bwqa BdenEWKdPDxd8FiIO7BqI3ZXk9rnLJqU/88/2TYMlOzNXgH+yRBcKMyN9ebIrufVpzyzq9MRbrOx YmPS9uZ3mCssONsEP1ftZ+1zklI0Km6Ici3LIrpKciX7kUS5LWKHZjSXJbbZ5sD9LSb/oqMxlonh gnKeVcIUmJ2rTKnphRkkw5YtqkDiZgZMNrlJ9Xik2aabc67teGzGpVpVBGcD0WZcpNmoQZmTPj4G JVSeMGqZYLs1ODGYv9JCri6YP42zLdmkWUkFj+JM8pFC+OaN69duvFsinXEVTJcQ62LDZXoQtOU/ JX2UWlLQveKHqBuYXgpPYmgmU+r01mWi/42+TgXKH0oWKDe3VMEBk4oBerEloDw4Ph0R4tlUMtZX qafNOLLSJ7pJB4alpm5F3GVM06rr9vf29vd39nZ2JLu0kcWmmpNKkzXbT5UrUgIxYAIOEVOGPEkE ToZgtsuECJO7xzc8gc+csMpGHQ1gQJUQ7oeu66B7q/P+cvEv7K/K7S6fq9+elYvWrvYHXMmkbNAJ qjO5XJOSmDlD58CZ+1TGWT79E2QWbe4HqW/c1xKUB0z3GiCw6xPBUb6DgDFdgTEICoIOWBh+DmjR sl3q0syVWw/y5ijX0BNJKMXtetWVby6JfHeny6K3OOFSxElAFpLGyvdzM1S+Wi6XxAqodY1YdJe3 Wn6Ww3kzKJMMXX6RUM191bzWqa5QjoTlKmG0L/0RNyTIZEM/oijPRhjI6thYPiB0hnUXn1OlPTIP pWyPOMYm3OUo91lRZ4lmhSNOfNt2wBZm/RL+jb5dMc14WLxpjRt606kElBbSTCpB1fJZ/bhcZzZ5 GIcIdJ+r2oC6tfeqxxditb7NS41ji6epqoLibUEFKdsoMkPeRvYuAlPBZI9kKHkaetHtkFo1TRwW S8wlmJAg1+gX+LnHQqzzCzKOGaNTxxcnz6yaWUVSsZzbHgp654lGAOo1pPLmRvPnbiWo2DOpjIo+ UDZlVgCBdUBqeqNcQEMNmFWBq3h1zfBqq+UrG3cee2VXUQIVEs41GueS1ZKIT6bdeF9L6bmpwLOq g6XsDVXrKkp4xnXkef6kJs2VIlqp8aiV1AxDN8w6HzZOVqimrcmZz3CVPYp18Eg61EJZvvpF69LC Vecw9jw2qXSMmMvspOMI7F8oEVYajes33rn1/m3IGuo0j5gIbh3HaQD+oPxbhF0F05UmmbtPii/g Ly8/zkUFgMcIsjgzoJIouJiV9CjzMTnvJcSUO3VCOUVHmakkm5TJtjXD0MjiR/eWVBgE/Dq6PBcT GHS0ntJY2CHfPzp6ePLo/P7eqmuvXrqAx1e6H6fDPW8zTKW8TRw22f2cRl2ZYiQoTQVk65RrgpU3 NnpRQGu8CGlMtSIOQvmcutJA9EPCin7dtkcPN+U3lKZqGGLXrXvMqbiMZTgDv4dozEhRFjOmk2AI 1iFkPaccCeHTGUMm5z/gdSTByK2ZTCUlkRvG14qt9AolIu/trKpZPVf64sMIfPAgMl4ydyqpBc6M qSQMAjdFyS1owBWZslbeRvkg5R6td0UywK/aqowKrceEZKPUeqgewJdd1jqJLiUeXWkOjLyRHVjf T4IUANeSvm6jXCj5aCX4sl2Qpc5WzuOqVBX4bUFLuWyenRD2hbYQh4fmBehVECKDCKXw+pDdoq5S IRhPyBmnUqhmvFXDWNVEAE8RCPH6AO7SS009RLTINq8+UvIVcJvU6FOWbfzgXdNO2RA84og8hcCJ H2oUITShv5Sj4o3FoSlNkQ+mRCUs1yjoyDFN2TTW9EGbku3nM2YylOGDm3esAy8ILmVH1fEMb768 9Dp0C9s/01w00/Ks6IKRUwWjvlsx7irPB1ayMh8FGy7TWIPgzmB5qjI0g3IOdFFEK7qJQ0SC+Lxl FmvCZk9oXxfurrpFqRZLReDNzpFaJ+aqSuKqKr0JpdhRsIVTUiGAoADryvN3M0MrYTibq8r3wlFa cevMb0tB++Rmb4acaorIle28VBWrpi8mceBmimxdIc3gd8I90O16KjLQzRNsnjBTsXL1ezSdpIrw mEXQFAiicsglRty5f/ftt98+OTnhQgszDXkwT07PGphBlXrt5PRU4p3MSaSEVB+kpNKcqmXiScJt Jnb2k9hXybZABjIyycGWQuQYSkiCW73jnLcJ8XS77VrFEJfQJt0DF8ijxgAIF05ZCQM2wZA1AHdz uYPmocBzSZ9C4C6R6PDBwyCSxpv9vZ111w2SHyeRQGuomx4YbtSBW3lR0l40pG5oypS1s6oPqLmh lS8TNxsKYapMC30YCItv0NoBfiLdFZ7ccRgZmlngS1YAfSGGhg+m+qmgrGyQk7GvUnjK0s2IIQxY aokAGNklYLLlAGFtI+s2QtpAHnQYJiczLEkUOKZsNXTVGkHuxbC3u4bRRqInSYaaSyOIPrh7ZRUi XXUN362ac+NFoHmYQI1MpD3JiJS+GACQwQAgJJGgVMuAhOWHTCnBhhESq2akVFFIWBrpwStf7eG1 M1N0sZ2dwAA1yKX0Q86UTM3bWTF45YcmQmSpEZmoKqINXGkjgovJelzCr9H+KmGGIjcGmpiMCZc4 T8e9GKFSj4k6nYsqybMCOMXNYYzzNCWY+IVjiQMQIPoqrNw4tpl6VTnKEx16KHSWzSLBh0pFUTQP SEWGMWooxiWTk0QuB4G9cmGSaaoB3qd8Ga1LgVPwj8uU5KVsJqf+nhbW2Iv4PO+tSRECkQjVkAow MAezNlD2UTJ8FEIe3qPzC33IoMioXBG/ga66s6IznT9NphfpM5lOjE1FTVE4OJMa85VUUnUjcpox 0t5wEbMYfjJBMM79VEpdv5TdUjuHf5msxtfe0832YFUxJS9LBjcDmtWW281TM2dv0NuozeTJgwJn q09L9ZV3CzUXFhJqhkLNF+s8TVvRpUWi8rMBea765L72ztbe3blz953r1+/fv/fw+BGnuDyfrM1L WPHwVoKCe3mAB19riKoFh3vRtU02mR+iexn7vNpDQysB9kvMOh6GIhJTnJTAQnVER9I1Td+PGzHb hgKFASn4SI+Iv5zal4d/K2pXnNWXtz2JrwnzZZqaZjVh3wAQivyKB8fHm7PN3u5uhJtjyXDlLztZ QcuTSa94CvkJBgxDJw6+JdRCowsCM4nAbNXE9FZOSh7lDnzSwK2QPTGGgv0vJv5ZN8ZiNR9jXshw YdXRePXFacpPBZXAUdQuNEFl3U0F4lXb4rrJ/YLcgCjTRKCnyttwsuoi04uibdrZTPiRHm5+LQpk zgx47GUxJcSXEdiWUdQqpXyczKldH/qSR8qVl2iHvLre6cqHIrys3NahH+AaafrVSem6BK0Aiqw6 K2reXAqC7SC3vhOUmrgetOXji5UAZdZWq65cjUYgZRKpJxCAMCjzVP9PTSotDoX1MrouDoXkdkj3 BqWrJJpswPoFjuGqfxrqCll0salCC0thZDzmdFdrFLIbCT8ZsVcDemKicV9W+GjVlPKz1JPtlS0O yq/2TL0T1YmQOyZgrXX+7ExVnU9NaY5ZvyfxYpuoyYa3BI3HIFu6MPPgAC73WgABSgn+E1IOZ5Ll lzeEsvB1jYmZVbE9OeLspsfiatJldOW7LaKTs/GFgSS87g/wV1J+Bg55JcFivUFJIoweVXB4ZqOP ShoiO4m42rpRxqvyhlPM0Wy9hfacHnP9qhr3WTmYOZjbhBnWsnlzTdVWnpuXuloj0qHaYilCQJco i/bAjOgN2jzru3u3QL4l5SZWdvxMu9F5Ua5Dttki3lW508Wax81K+KbX5rTywXIvzlywpVBDrqoH 1tdUgef5e31QjZ8qzFONn3XvmBUsoX8JUpTErHt3P3zn2ju3PrhzePQQZAi2eq72Uol7V606GSsd 8TYkslAXy1sdYKQXfbTERFKXmSQzwdWKipNkkMQGIooS+/oxsXIoMUqW9ZPosji1TRK2NofFwG6Z ICYmDyS2l94I4C/ZM/dZBTI9FX+naYAJGAoOd7LZlC/t7Oy2Qs4Y9b2hciREitZkknjAlKdWCsWp JcZFlP88dWCPq1uJTbRA+w/smdgVceZM7Bl7fUdBRm0cE7UJxlGX8wxz0lStWigYQfFBehoKvMt6 I5qzvUjAAZym2yCFBQKY0DaUQ6aYU7U0prgOABGJ+he5atFHRSF2SF0mFezx9sYGeyYAbRN4P25n ZzWg/RqhTwytGlmHlN7QAxNIyZVKb+ixZeGEh8rKkGbIor8Ab7He5VUjzZnw9wXNVX6d3PrSc3Ik RcNQOWxRzfdKQirdlTRCIxMDqfsNkAiC6ldNTPzlIGbGynfm3oUDKxwP0/mIQc3WAaHh4JebVKi3 6HJ8ov2dryvmxD1CMFcMwORmpjnwQJzvUYtM+E8LpX3JfVk1Hml1jjjpVb0X1Q8We8pSxG8KOl8v H57zmLGOqemoxtZffrAk9UHt16IWwQ1w2J6TLrV3VWIHEd+mRkwQHo62CsB4q5DdLHyYYNSoa2sf lhaFbAYaaCgJOmUCbyv4QTJqrDRMsogrBowsAY2y7K3UcF6F5DzTgsV79TE2VqkRNfxC69gryd8C nCrIwa2ZaqgKzQUCk1MrhQxaruHwKQWTEsIsPVbJ00wySVqonkCAhMgZVbCoEMlo2BCdETodB81r LYUJOHNgNlfEXGVEuXdNubJJMGtWuTGd1C1mY27ezHAIkpRySOEKc6qpXsYqb6zSy+ExG+tsSG2c kyiwqLM33n772s2bhweHKuhdlcbIHhAuXiKCSPECuLlCYctqElw1i6qAgJuJrl5FX0rt3AbTEJeA xYQ00pMDNN1EwnJJPEGVm882PYWYJPAFse4LIP3o5MSkk5wIII7luMkwLbHnkrMnYrETBbhG4mvJ KyTL2gsVQ8iDJ8cnHKFsoVwJyqErtbMbFbIkjoGleEdWg/ywjFZKyNPiLDlzkXJsp7xjvZ+4teZN L/UmtKQjenFfojN+RryTx8FI5ujzJp3YyGHgwCqhMIca5wiBR06kJ2Qpid16tcUwgHgGuQs9KvTy iQUZnpKQThIBSJnPAtdRtpTOJgrO5bBCaaTAF6eysNluO8CjJRR6kWIuKamTjY7sWiC6HDDeUBvg vFAld9gYSfzCcXJV5Z5+xjEM5US1cJKfprWILpdL78ofMPuaqNeQCD6KXvmR4OKV7y/nChxJSeEo p8QFlSB+mRJNE7XpSJkoXbUIwWmLJjO9HjAQ6jqXJNbL7EtOeCutG3WftT6EGliEoJxy75Gnx4p5 JYgLs5ug5SbGIzQti/DtnrKsE7x22YAqsEL1LGUSh34mvyy/iToX2QBpke4hgBGVPnGzEc2dnd0V UPKjkicUFRg4BALOIAs3TO6FgCxAisfwLmtexBNdYUusGQGflgyseY+7wAC9KYkUI+KNX6h+qIsw Xctn9eusnPoEAoStV8CpSLD6cCbZAiar4rYJKfa0KFbYD0MhuapJdVMI0sTRVruIEQ86MQ9jymZp oKMtpcoSCabeZ447/KQCCzmpwDIJ82b9LVTZBUwZO4msSy15s9FQN14VhFIFL0XjDyXwdxpw76dq FuB1BsLQpltTDsSyqi8E45sCa6u6yGo1pnOwrNIFvioehWwS+hUI5hWR8ZjGl7UrOqilMo6JwCqo +rGN2tL0TP3n5Isnj47PTh/tn9s7uPPht7/3vQ/vHARsh0uYoJECwUh8iNUrWhdLiUNPIwCTY6Su g4S9kFFcAWOUhBhJn+UeLwPUkN1UBYZZlyiJPbRBgQlbSOZSwYXDomjiN2aXS6y8YK+lDVqvBow+ VDMm5xltITIkLTRYZGgACcsGOKjJDTQxm2BNNJQXXK3FjWjo81arWnHCyAqh8NtB0gwGMwguVGaG i0n5EoLN1HC4kcWmXhwTRMxfnhVAQq2tBKis0nghOhKJect2sxuM8jgxH61Ul4p1cibP09QCQgZH ylZxihuOqlIs7wF91iCjeQm9xPgNoyJ3ucru+4F+cUbUFD01JxxSmcPAQTljLSzHheuPEosFfyyL nLH6RUu+6hN1JBHZHcZrsFsDUYaDPsLGRBpZhHxEJ0bAUUE+k4yKHDtRyCdi+TeC7yKA9qDzdlin wGZWdJoliuzvrrlOKB8uhqYfKabZnpyIaFvLVywFRBBt0PL3ZnAcyJFUmR/4xJXKQ9mLTaMsfrkU I39k8uoNQwBXK0SfiYs0OFSAyVjRQWhwEmDHUkCYsKp8WBQZk1L8AiFHLisY0amFpTrJquUEYO8O CMDyeUoOFkAEDA64oqOUZI6RW1vg8uU3mEMCRDtK99aFir8VZWv6SdABx9nog2xPjfucQsj7RkAx 1vpkKgV1AwHoN4NUlN7Ez55aEYMRYb9nzv/I5pO6jNCPYBtyoo+oARdUw98tBWGQrlFsK2MeFBMN oIEmTRaZncoRIzrTb1T3GQBSYmElHz+rKP68R4pUJPOmPuzVOt5X1joq/ehoMaI6W14bBgAMFcWs VP5ozjkEjyclA/KMpJpHK2CcrPKlbWUwtqAzN3ubnAb2GG5hPF5FE1T72cBvxs2q/pgLBqyfrct8 qCsZatoI9F/JSyGcnRwHCSzttTffuH3nbvnM793+wEGosQSIXkYcrSgfo4YJpMtTdBpaRixFzZXW U1Ykm0WYeYYCDWg79sxVCicJVhebJ0Ag2L5qsnl1R4BrvQlfgoMpVWcbZRpcYsRq1Siz0qsZWhTm xEQup6ieSPANp8OoDtgz/M8zv5fSmL4VBLOOw1Aq1fVqfXp6Vrk75BwM237CIIvuD6uVEBs7CTHN hGpXwMHCaVdRFQCIE1slBXcI3iET9zUj3Ykiw8CNWGqFe+WKA0gkANEwjXRFx2qGJvCe0TliIpLW 4qRZHvZJhZ1MHwYrzwmky5UwCoPbWYmhSIlrQvxERYiRDLTUQJgLGLWhOZP2ZewHdZ3w2nyYERRN pj3JJDkN5f+X1OKRQclAyiDHZKT58gbK+dmOw85qpcL5KFmwbaKqHoaQPtNNBxUrDHTgHyjiMZLL TU/TB8yCBA/GEVwLIDXxKeWoJDXGpixALr0lqPXyRMlvdGHbb0UvABgEIK/kaRXZ7Ezhv9yBpipM oBC2yLVNFg2bbd+jJJ2Ieqd5jMfQEiMlhOKhtLOdIFwm5bQSBs0aQuV7xdylmaiIo9TmrIKgbBe5 J8YuLSnsV3eVUdH2eAqahjP6MUkv23ZQIHWqYyT3wsu8Ung2iowox8knp+M1vf2uqebfgsEYpgqE 5eOqUY8TEwgZ+1SHQR6Lj9lLq5o1+GjDcalDs+6X2ObTxpt6xwyKLWE5tqyqZgkMd+otFql471Nd j2CFo3JOCh+iNL1Lj6GG8xw5q+etXVWnW/ds4yZ564EfCgk+WBRhA1QCSA5qFFYzHOPXRJlPnZUR kcwFo+U4z9vqSaoLc8cASiYXWKnSLR3FxLJhzBRFo6+YMYeFyw4U8axLDEsdF1YnptK7AED42VtT ncJNX4uJhEpxJPowRst5KR19RLee06rZOTs9efjgsNRTb7z+Rl++1k9HDx9SbazBPR4mklikzsLi Ngc263oH1EmBcjI20PMKBlNqjELmgUamKHhVbPJVtpnPCWffquSZidhQt/AJAcVXWDBqFCnxEtp2 m+9N6rMkAJgIFluaaCsi7wGEeU92o0pGTlLDxmCzcsQdA3Blqk9CG1i8YfCoyfdg9VOuc2pzM0F1 UkJtSr3367VAA9Yl25SHP6Xj09OdnZ1yv/u+l6YkZHN0ruJs3POpw0VDkRVUN43QIZV7f0YfATo5 OmYdSDV7BGvEdGCUIykCA6bqa7F1cULKwYKHgAUiI4SUXsINRGdlWwvW52azXWO3JNNI3eup4I1A KbwKlapPtw4QSmSVyV5D17gS8RtPMofk4FLFS+ptyOODLJiOPcW/oOs8QVHB7+2sKLAfQqyY+JHc eCA1AUQUdPUIO5ImTSVG4zES3bNOUBgcEQXOqcpl6cF4KAUjMNzBNtBhiw+o9kAooIn0E73OaSr3 znCPVJmMTSuYaag4llq+awiiQ9Xc8n6ha1TIe8N2AEMCDOXKmQGeIhEnLdEpKXNF5M8H2fA16KVg z0bpxZDNoMiZUyo1KTFJFrHOiP6bamkqWIJY34aoTjAZBZzXNS2LCdZ/05CGknKID+SQjRgKNFkM n9ki6kBUIei9DbkXoMkFURKk9lm1rYWVFjkgCdKc8ipAeSo5QpFtaTD/xYxSgYeYup8zTIhy0QiQ fob/2joE0w92cUbsUhgxubsjI2aic1fmsI5rfPqxZ9X84PXKwTqVmYSC1G3/200agFSYoDx8bNVV 3dLN9o5KpqddVaS+C6HoOh4KVjuXl590Ac1i3+GmBlfByKa56p0q0xiTUldDCXA9lUDIqpzvbAil JjHaVvjqVVkH3eZd7Lk91lpBFxaKs3ALuWJLRHKHQG3vh37bb0777XYce6nHg79/9ODo4aPt6dlm s5GP70SAziO8BTViUY26bAuirODnmk8ViSB3uWIH1WStivmDBUlhauOHg5BIdZ+kQABVdeSiEDrc 8n7G2Fjfjc2xCUN4FnvkIlQuWBMp3CiXC4+09LGTxBFJKjs7nQy1ysUYRur+lZDUmMIsnW4V0Wmz sgwKoZSb4mgZyYskt0lN7aSmHtDph/KsDuDEyGrH5+1mW0rmbrU63W5OTk+lZIY8obQaeKy6blUq ReiuaDMR4B2ZjMEnVM2tWIxDJ1ixoQQuQtuxlPzABOMRkyJdwFvyDicABzBwk2vYo8FiK6kMTDwP JZF0wFmVcLlar4act9v+tPRobQdLFifcQ+0CA0bpJXrKkCrL6CmYgHEkRQwQiQlmXnKsJW9hoFae q9VORwt29fjBJ4V2QOwwZyvvu8FmiF0Lk99EqoW8gt9MI+9U22CYL8pv8kl212vOi1qZSea2iyK0 idGQWaIJ+q7JjAATc3MJ8STEyHYKtwO5cKq4+wBOvrjuwAEYcHmiGUPbenBFx6g0YbU2YEBTc0xA tqiTU+5CBydmQu+SbHdKzSFudXJyHPd6oes6fDUo/4k4WMCR+WBHTtgCsU6UseUWJDptI1gBO84e qScr0h1wNieKL6rYszzULYirXBlwDJvNTKwq9Sp/ixp/AIiP26GhYDKdmoLhTHtQ62H8IPyTDFNx +voxwGP3UHVIpKWIshKXGCeQfR+TPccqRAOFc9V8xtNvpiqIHdGZvrrPar1TTecUrGyzYJ1610EF O45qdqLu6wF2vtVS26xNIvAl89SLREyWGZwJpwqLVJxWWqQuZiDvKm1FFV6S+QQRjo7ymdLESYVr DCkmNB61mTeOpOO+PEH7MlAuc2bGkhmq3ZqrFpYpPwaGjhwFwSY9KUKxbpqqtIAJv1RNTApMQy+l tP4lqWw3p8P2rJR52fygyys/OH509/6RRMPs17v7FZQ4mQ9SNj5KFmr0oMALbJqE5wTupK+kHwiK steg2p25IEgEAfIoefUIcKDBuJnzTKsl1EycBaI+8MYLcZmOD/D+kglGqf5aAaHmsU7YBEzBXXNK gNtibuxYv5d+Zd3u7Kw8SrASF0Ay580KIKWqj4YQqjF9IgMBMz1VwSqXY9KRKJ8R2DrnAXsvDo7Q FuPQlny2AtCoRKCTbc9PepY37DnKHzgTK7H7BJd9d2dXhvtE+oqBmLztavaMmsxV6Te5PhjycNfC 5QG7+fIby68Q7SnxgfSnZ6dneRr6nrmE8DY6eZ1JXmkRwaX8aLBX4EpsxLe1nIxJGyHlKnXVGMTL P+B5AN7drkqy7NrVZBaNsk0XCJ+sdMCaTNJ34AAPsINUaaDgO4iwD0QmoDphSCkRTK4cyDe9qMUA BYA6Z+oTZIRyuaFYvYVMVBuZ5BP0vjwpRPKYSGGhrupqqYqGQ9QWpGAYZaAasS6Cnpg4AHGvXc5o KUn7MUFAW9DQw1ZYpqJVFxvI4iUyn1QQQE0i8ijj8qAbsmziSQnE3rbd212TElc+1waQAYo1RE41 pRpoyikvH1/ALPLBpq2I1wnYZIVL72QWR9F0YS/iRmAaIqqDnsr3konkv/K4lYekdIes+hqsxCFB IFoSHPGWV+iAIcmsVjFKnegfo6bvYeb24an5fwIMAG4E31ZGNGt/AAAAAElFTkSuQmCC --_005_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=134; creation-date="Sun, 28 Oct 2018 15:35:25 GMT"; modification-date="Sun, 28 Oct 2018 15:35:25 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEgATAIEAAAAAAP///wCZAP///yH/C05FVFNDQVBFMi4wAwEBAAAh+QQBAAADACwAAAAA EgATAAAIRAADCBxIsKDBgwEECEB4UKFChgYfQiTocOHEhBUtTqx4ESNHiBkddpQ4MKTJkAJPqgSp MmPEliRLwny5smBLhCZZKgwIADs= --_005_597c3199271343c380f5f66e601c969bXCHALN011ciscocom_-- From nobody Sun Oct 28 12:39:11 2018 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 2D0A612870E for ; Sun, 28 Oct 2018 12:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 kjZCC5ctiibS for ; Sun, 28 Oct 2018 12:39:01 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 8C2FD127332 for ; Sun, 28 Oct 2018 12:39:01 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id n10-v6so2806982pgv.10 for ; Sun, 28 Oct 2018 12:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IJj/5Jlvb6qpImAxDJbqjqgkvTZeFnjdq2rBSxueXDk=; b=E0ZUZGJM3JwVVQIXVS53i3Qz7G6R3XfscXwaNJjx64bhVibsOLbqfTuz4PT2LuOrrQ +bDSnyd1LqcVcDpr4OCwEYwCcG5KgiaMgG2mIzVC9nrE7N+9n87b8MKC44WjyfRUD0Ky eVIVY4TKbJZ3FetBuBb5G++kjA3VyFd9xyoWyTeASwxyTh93pgiwTaBIZHNEz0oSVGx6 iREwVAzv3YmwUNJUdkMLTwMsu85vWxwR5D/iRU0R20hFrJbf9gZTfXbLAUit52+Pv7ld d6YWRMBiqlhL20dtxCwd6yaT34RuES69kDW9V/2r1Ll6xWeFZHT99T++YdW95qV6oa5C XBnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IJj/5Jlvb6qpImAxDJbqjqgkvTZeFnjdq2rBSxueXDk=; b=bVd+1UHDxkhjI/PFL93iFvH+TOfFZ4AE6+CHbXZs7Hz3ELdwrNzOSmJrDDdAkhEweL hHwLH2PWuBS8JFvNvKVjy8mF5RH5kAN8AojGeA8otOQpJYasBkKAfUwAmjXj/r4oteNU cuIGUURMZMxLKSfYitVO18DHoMo+1sK908e5SEVHKvU1H+tiFvCFUNT/hXrj4UZxQOUI Upb/Ee44W/fuQMUMGNxwFJBB7UD5IWbDjxCWtJVUoI2elQs/pjqa7CzEPWtQKIoGLWJp QCDPHN8D9ddFZ7av70Mf/mpPZY7lOCZvhuH1EncDxDz+4zGo12Ko8OgEnE/iVz+BPu+A 68nw== X-Gm-Message-State: AGRZ1gJTYDVGBQ6gaajYBBLtMqfaNVRJ4+0BcPGUeAt3YxaZYQDwghP9 cuqiPTNBg6RZq+4DI9AqJZxkTb/u X-Google-Smtp-Source: AJdET5cMEWJed5L6U0EDhA7WNWOtdf1ADH1l9wKpoLAmixfDdoMlW3ZryhlPq2BsSmzo0hVf695srQ== X-Received: by 2002:a62:d148:: with SMTP id t8-v6mr11441090pfl.212.1540755540584; Sun, 28 Oct 2018 12:39:00 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id j187-v6sm26318008pfc.39.2018.10.28.12.38.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Oct 2018 12:38:59 -0700 (PDT) To: Alexander Vainshtein , "stephane.litkowski@orange.com" Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" , "shraddha@juniper.net" , "spring@ietf.org" References: <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> <8f6b91d0-27de-f92e-6908-598977a05e0d@gmail.com> <32502_1531913237_5B4F2415_32502_461_3_9E32478DFA9976438E7A22F69B08FF924B1FF359@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: Date: Sun, 28 Oct 2018 12:38:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C9D2DD0DBF0D0F68F788001B" Content-Language: en-US Archived-At: Subject: Re: [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 19:39:09 -0000 This is a multi-part message in MIME format. --------------C9D2DD0DBF0D0F68F788001B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks a lot I appreciate your help to close this draft Ahmed On 10/27/18 8:15 PM, Alexander Vainshtein wrote: > Ahmed and all, > I am on vacation this week with just my cell phone to see my emails. > > I will provide some wording once I am back. > > Meanwhile, apologies for the delay, > Sasha > > Thumb typed by Sasha Vainshtein > > ------------------------------------------------------------------------ > *From:* Ahmed Bashandy > *Sent:* Sunday, October 28, 2018 3:02:45 AM > *To:* Alexander Vainshtein; stephane.litkowski@orange.com > *Cc:* Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); > shraddha@juniper.net; spring@ietf.org > *Subject:* Re: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > Sasha > > I uploaded version 15. But I was not sure how to best address your concern > > So Please propose the wording/modifications that looks reasonable to > you and I will be more than happy to incorporate them > > Ahmed > > (I replied to this email a little while ago but I am replying to it > again with a cutdown on the list of receipts because the mailing list > said the email is being held) > > > > On 7/25/18 12:20 AM, Alexander Vainshtein wrote: >> >> Stephane, >> >> Lots of thanks for your email, and apologies for a long delayed response. >> >> Regarding you reference to “BGP 3107 label over an LDP label over an >> RSVP label to build an end-to-end transportâ€, I have looked up RFC >> 8277  that has replaced RFC >> 3107, and found there the following */explicit/* statement: >> >>    When pushing labels onto a packet's label stack, the Time-to-Live >>    (TTL) field ([RFC3032 ], >> [RFC3443 ]) and the Traffic >> Class (TC) field >>    ([RFC3032 ], [RFC5462 >> ]) of each label stack entry >> must, of course, be >>    set.  This document does not specify any set of rules for setting >>    these fields; that is a matter of local policy. >> >> No equivalent of this statement could be found in RFC 3107 – probably >> because RFC 3443 has not yet been published then. >> >> From my POV including the same (or equivalent) explicit statement in >> the draft would be sufficient to resolve the issue. >> >> Hope this helps. >> >> Regards, >> >> Sasha >> >> Office: +972-39266302 >> >> Cell:      +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> *From:*stephane.litkowski@orange.com >> [mailto:stephane.litkowski@orange.com] >> *Sent:* Wednesday, July 18, 2018 2:27 PM >> *To:* Ahmed Bashandy ; Alexander Vainshtein >> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; >> 'adrian@olddog.co.uk' ; Jonathan Hardwick >> (Jonathan.Hardwick@metaswitch.com) >> ; shraddha@juniper.net; >> spring@ietf.org; spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> *Subject:* RE: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> Hi Sasha, >> >> >*/The head-end node sends SR-MPLS packets across a path defined by an >> ordered set of SIDs with more than one SID in the list. Each SID is >> represented by a label stack entry (LSE) in the MPLS label stack, and >> the label field in each LSE is the label that matches the >> corresponding SID. However, each LSE also includes the TTL and TC >> fields. How does the head-end node set these fields in each of the >> LSEs following the top one? This clearly depends on the model >> (Uniform vs. Pipe/Short Pipe) implemented in each node that that >> performs Next operation on the packet along the path – but the >> head-end node usually is not aware of that. /* >> >> Why do you think this is different from a nested MPLS tunnel that >> exists today ? I completely agree with you that the head end does not >> know the behavior of the tail-end in term of TTL/TC processing. But >> that’s already the case today, and it’s the job of engineers to >> ensure that all nodes in the network are operating in the same mode >> (uniform vs pipe/short pipe). >> >> We can already stack today a BGP 3107 label over an LDP label over an >> RSVP label to build an end-to-end transport, the TTL processing >> should not be essentially different. >> >> Could you pin point the difference that you see ? >> >> Brgds, >> >> Stephane >> >> *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] >> *Sent:* Monday, July 16, 2018 22:03 >> *To:* Alexander Vainshtein >> *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org'; >> 'adrian@olddog.co.uk'; Jonathan Hardwick >> (Jonathan.Hardwick@metaswitch.com >> ); shraddha@juniper.net >> ; spring@ietf.org >> ; spring-chairs@ietf.org >> ; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> >> *Subject:* Re: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> Thanks a lot for the reply >> >> See inline "##Ahmed" >> >> On 7/11/18 2:02 AM, Alexander Vainshtein wrote: >> >> Ahmed, and all, >> >> Lots of thanks for a detailed response to my comments. >> >> Please see */inline below/*my position on each of them. >> >> Regards, >> >> Sasha >> >> Office: +972-39266302 >> >> Cell:      +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] >> *Sent:* Wednesday, July 11, 2018 4:42 AM >> *To:* Alexander Vainshtein >> ; spring-chairs@ietf.org >> ; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> >> *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org >> ' ; >> 'adrian@olddog.co.uk ' >> ; Jonathan >> Hardwick (Jonathan.Hardwick@metaswitch.com >> ) >> >> ; shraddha@juniper.net >> ; spring@ietf.org >> >> *Subject:* Re: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> Thanks for thorough (and VERY clear) the review >> >> See inline #Ahmed >> >> Ahmed >> >> On 6/15/18 11:08 PM, Alexander Vainshtein wrote: >> >> Re-sending to  correct SPRING WG list. >> >> Sincere apologies for the delay caused by a typo. >> >> Thumb typed by Sasha Vainshtein >> >> ------------------------------------------------------------------------ >> >> *From:* Alexander Vainshtein >> *Sent:* Sunday, June 10, 2018 10:43:52 AM >> *To:* spring-chairs@ietf.org ; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> >> *Cc:* spring@ietf.com ; >> rtg-dir@ietf.org ; 'mpls@ietf.org >> '; 'adrian@olddog.co.uk >> '; Jonathan Hardwick >> (Jonathan.Hardwick@metaswitch.com >> ); >> shraddha@juniper.net >> *Subject:* RE: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> Explicitly adding Shraddha  who is the shepherd of this draft. >> >> Regards, >> >> Sasha >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> *From:* Alexander Vainshtein >> *Sent:* Friday, June 8, 2018 5:43 PM >> *To:* 'spring-chairs@ietf.org >> ' >> ; >> 'draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> ' >> >> >> *Cc:* 'spring@ietf.com ' >> ; rtg-dir@ietf.org >> ; mpls@ietf.org >> ; 'adrian@olddog.co.uk >> ' >> >> *Subject:* RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> Hello, >> >> I have been selected to do a routing directorate “early†>> review of this draft: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >> >> The routing directorate will, on request from the working >> group chair, perform an “early†review of a draft before it >> is submitted for publication to the IESG. The early review >> can be performed at any time during the draft’s lifetime as a >> working group document. The purpose of the early review >> depends on the stage that the document has reached. As this >> document is currently in the WG Last call, my focus for the >> review was to determine whether the document is ready to be >> published. Please consider my comments along with the other >> working group last call comments. >> >> For more information about the Routing Directorate, please >> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> *Document*: draft-ietf-spring-segment-routing-mpls-13 >> >> *Reviewer*: Alexander (“Sashaâ€) Vainshtein >> (alexander.vainshtein@ecitele.com >> ) >> >> *Review Date*: 08-Jun-18 >> >> *Intended Status*: Proposed Standard. >> >> *Summary*: >> >> I have some minor concerns about this document that I think >> should be resolved before it is submitted to the IESG. >> >> *Comments*: >> >> I consider this draft as an important  companion document to >> the Segment Routing Architecture >> >> draft that, ideally, should augment definitions of the >> Segment Routing (SR) notions and constructs given there with >> details specific for the SR instantiation that uses  the MPLS >> data plane (SR-MPLS).  Many issues raised in my review >> reflect either gaps that should be, but have not been, >> closed, or inconsistencies between the two drafts. >> >> Since RFC 8287 is >> already published as a Standards Track RFC, I expect such >> augmentation to be backward compatible with this document (or >> to provide clear indications of required updates to this >> document). And I include the MPLS WG into distribution list. >> >> This draft was not easy reading for me. In particular, the >> style of Section 2.5 that discusses at length and in some >> detail multiple “corner cases†resulting, presumably, from >> misconfiguration, before it explains the basic (and >> relatively simple) “normal†behavior, looks problematic to me. >> >> The WG Last Call has been extended by one week. Nevertheless, >> I am sending out my comments >> >> *Major Issues*: None found >> >> #Ahmed: thanks a lot >> >> >> >> *Minor Issues*: Quite a few but, hopefully, easy to resolve. >> >> 1.*Encapsulation of SR-MPLS packets*: >> >> a.RFC 3032 (referenced by the draft) and RFC 5332 (*/not >> mentioned in the draft/*) depend two encapsulations of >> labeled packets - one for Downstream-allocated labels and >> another for Upstream-allocated ones. >> >> #Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of >> draft-ietf-spring-segment-routing-15, multicast is outside the >> scope of SR. Hence the RFC was not referred to in the SR-MPLS draft >> >> */[[Sasha]] I would be satisfied with this response, would it not >> be for the following text I see in Section 2.2 of the/**/SR >> Policy Architecture >> >> /**/draft:/* >> >>    A variation of SR Policy can be used for packet replication.  A >> >>    candidate path could comprise multiple SID-Lists; one for each >> >>    replication path.  In such a scenario, packets are actually >> >>    replicated through each SID List of the SR Policy to realize a >> point- >> >>    to-multipoint service delivery. >> >> */This looks to me as being very much multicast in SR, and, >> unless you want to say that it is limited to SRv6, makes my >> question relevant IMHO./* >> >> ##Ahmed: The main reference for this draft is the sr-architecture, >> which clearly states that multicast is out of SR scope. SR-MPLS, >> being an MPLS instantiation of the SR-architecture, follows the >> SR-architecture as close as possible. If another draft proposes >> something related to SR, then it is the responsibility of the other >> draft to mention any extensions/restrictions in relation to the basic >> draft-ietf-spring-segment-routing and/or SR-MPLS, or to specifically >> say that it does not apply to SR-MPLS. >> >> >> b.From my POV the ST-MPLS only uses Downstream-allocated labels – >> but I expect the draft to state that explicitly, one way or >> another. (If Upstream-allocated labels are relevant for SR-MPLS, >> I would see it as a major gap, so I hope that this is not the case). >> >> #Ahmed: I will add a statement in section 2.2 to mention that it is >> down-stream allocated as you mentioned >> >> */[[Sasha]] This is quite unambiguous and, once added, would resolve >> my comment in full – the previous comment notwithstanding. In >> particular, it would imply that even labels representing BSIDs of a >> SR Replication policies will be downstream-allocated. /* >> >> */#Ahmed: Binding SID is just a special case of a SID. So what >> applies to a SID applies to a binding SID/* >> >> >> 2.*Label spaces in SR-MPLS*: >> >> a.RFC 3031 (referenced by the draft) defines per-platform and >> per-interface label spaces, and RFC 5331 (*/not mentioned in the >> draft/*) adds context-specific label spaces and context labels. >> >> b.The draft does not say which of these are or are not relevant >> for SR-MPLS >> >> c.From my POV: >> >> i.Labels representing all kinds of SIDs mentioned in the draft >> MUST be allocated from the per-platform label space only >> >> ii.At the same time, instantiation of Mirror Segment IDs defined >> in Section 5.1 of the Segment Routing Architecture draft using >> MPLS data plane clearly calls for context labels and >> context-specific label spaces >> >> d.I expect the draft to provide a clear-cut position on these >> aspects of SR-MPLS. >> >> #Ahmed: I will add a statement to section 2.2 to say that the it is >> per-platform. Regarding the function "mirroring", SR attaches a >> *function* to each SID. The "mirroring" function is already described >> in Section 5.1 of draft-ietf-spring-segment-routing and is not >> specific to the MPLS forwarding plane. Hence there is no need to >> re-mention it here because this document is trying to be as specific >> as possible to the MPLS forwarding plane. General functions attached >> to SID are described in the segment routing architecture document or >> future documents. Furture documents proposing new SR function must be >> as specific and clear as possible >> >> */[[Sasha]] Looks OK to me./* >> >> >> >> >> >> 3.*SR-MPLS and hierarchical LSPs*: >> >> a.SR LSPs that include more than one segment are hierarchical >> LSPs from the POV of the MPLS data plane. Therefore some >> (possibly, all) of the models for handling TTL and TC bits that >> have been defined in RFC 3443 (*/not mentioned in the draft/*) >> should apply to SR-MPLS >> >> b.RFC 8287 (*/not referenced in the draft/*) specifically >> discussed operation of the LSP Traceroute function for SR LSPs in >> the case when Pipe/Short Pipe model for TTL handling is used >> >> c.I expect the draft to provide at least some guidelines >> regarding applicability of each specific model defined in RFC >> 3443 (separately for TTL and TC bits) to SR-MPLS. >> >> #Ahmed: BY design, the instantiation of SR over the MPLS forwarding >> plane (and hence this draft) does not modify the MPLS forwarding plan >> behavior as it is mentioned in the first sentence in Section 1. So >> the TTL behavior specified in rfc3443 is already implied and there is >> no need to re-mention it here just like all aspects of MPLS >> forwarding. RFC8287 is OAM-specific.  SR-OAM is handled in a separate >> document so is outside the scope of this draft >> >> */[[Sasha]] Unfortunately I do not think this is good enough. Let me >> ask a specific question reflecting my concerns:/* >> >> */The head-end node sends SR-MPLS packets across a path defined by an >> ordered set of SIDs with more than one SID in the list. Each SID is >> represented by a label stack entry (LSE) in the MPLS label stack, and >> the label field in each LSE is the label that matches the >> corresponding SID. However, each LSE also includes the TTL and TC >> fields. How does the head-end node set these fields in each of the >> LSEs following the top one? This clearly depends on the model >> (Uniform vs. Pipe/Short Pipe) implemented in each node that that >> performs Next operation on the packet along the path – but the >> head-end node usually is not aware of that. /* >> >> */RFC 8287 is relevant as an example here IMHO because it recommends >> the following setting of TTL in Traceroute packets:/* >> >> -*/Set the TTL of all the labels above one that represents the >> segment you are currently tracing to maximum/* >> >> -*/Set the TTL of the label one that represents the segment you are >> currently tracing to the desired value (to be incremented until end >> of segment is reached/* >> >> -*/Set the TTL of all the labels below one that represents the >> segment you are currently tracing to 0./* >> >> */I expect the draft to provide some recommendations for traffic >> (non-OAM) packets as well./* >> >> */##Ahmed: The setting of the TTL for non-OAM packets are subject to >> the policy that constructed the label stack. SR-policy is handled in >> a separate draft /* >> >> >> >> >> >> >> 4.*Inferring network layer protocol in SR-MPLS*: >> >> a.I wonder if the draft could provide any details on the >> situation when a label that represents some kind of SID is the >> bottom-of-stack label to be popped by the egress LER >> >> #ahmed: This is part of the "Next" function. It is described in >> detail in this document. >> >> */[[Sasha]] NEXT function is mentioned in several places in the >> document. Can you please point to the specific text that is relevant >> for my question?/* >> >> */##Ahmed: Part (a) here is a statement not a question. What is the >> question?/* >> >> >> >> >> >> >> b.For the reference, RFC 3032 says that “the identity of the >> network layer protocol  must be inferable from the value of the >> label which is popped from  the bottom of the stack, possibly >> along with the contents  of the network layer header itself†>> >> c.From my POV the following scenario indicates relevance of this >> expectation for SR-MPLS: >> >> i.IS-IS is used for distributing both IPv4 and IPv6 reachability >> in a given domain >> >> ii.An IS-IS adjacency over some dual-stack link is established, >> and a single Adj-SID for this adjacency is advertised >> >> iii.The node that has assigned and advertised this Adj-SID >> receives a labeled packet with the label representing this >> Adj-SID being both the top and bottom-of-stack label >> >> iv.The implementers must be given unambiguous instructions for >> forwarding the unlabeled packet via the dual-stack link as an >> Ipv4 or an IPv6 packet. >> >> #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 >> drafts, you will see all 3 protocol advertise different adj-SIDS for >> IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" >> (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to >> specify whether the adj-SID is for IPv4 and IPv6. Similarly, the >> SR-ISIS draft attaches a prefix-SID to the prefix advertisement and >> hence implies the identity of the protocol underneath the bottom most >> label. For any other "function" attached to a SID, it is part of the >> specification of this function to describe what happens when the SID >> is represented by a label in the MPLS forwarding plane and this label >> is the bottom most label >> >> */[[Sasha]] OK, got it. This issue is resolved./* >> >> >> >> >> >> 5.*Resolution**of Conflicts*: Are the >> >> a.Are the conflict resolution procedures listed in section 2.5 >> mandatory to implement? >> >> b.If they are mandatory to implement, are they also mandatory to >> deploy, or can the operators simply treat any detected conflict >> as requiring human intervention and preventing normal operation >> of SR-MPLS? >> >> #Ahmed: They are recommended. I will modify the paragraph after the >> first 3 bullets in Section 2.5 to say that it is recommeded. >> >> >> >> */[[Sasha]] OK. However, it would be nice if you could refer >> separately for “RECOMMENDED to implement†and “RECOMMENDED to >> deployâ€.  The latter probably requires a configuration knob for >> enabling conflict resolution rules (if they are implemented). /* >> >> c.For the reference, the IETF capitalized MUST appears just in a >> few places in Section 2.5, and each appearance has very narrow >> context: >> >> i.For MCCs where the "Topology" and/or "Algorithm" fields are not >> defined, the numerical value of zero MUST be used for these two >> fields >> >> ii.If the same set of FECs are attached to the same label "L1", >> then the tie-breaking rules MUST always select the same FEC >> irrespective of the order in which the FECs and the label "L1" >> are received. In other words, the tie-breaking rule MUST be >> deterministic. >> >> iii.An implementation of explicit SID assignment MUST guarantee >> collision freeness on the same router >> >> From my POV, it is not possible to infer the answer to my >> question from these statements. Some explicit statement is required. >> >> #Ahmed: I agree with you POV and as mentioned in my reply to items >> (a) and (b), I will modify the paragraph to say that it is >> RECOMMENDED to answer you questions in items (a) and (b) >> >> >> >> d.The tie-breaking rules in section 2.5.1 include some specific >> values for encoding FEC types and address families – but these >> values are not supposed to appear in any IANA registries (because >> the draft does not request any IANA actions). Can you please >> clarify what is so special about these values? >> >> #Ahmed: There is no significance to the values but there is a >> significance to the order among them. I will modify the text to >> clarify that >> >> */[[Sasha]] OK. /* >> >> >> >> >> >> e.I also doubt that comparison of FECs that represent IPv4 and >> IPv6 prefix SIDs makes much sense (for conflict resolution or >> else), because, among other things, there are valid scenarios >> when an IPv4 /32 prefix is embedded in an IPv6 /128 one. >> >> #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that >> embeds an IPv4 prefix is different from the IPv4 prefix. The >> specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP >> treat IPv4 and IPv6 prefixes separately, including the IPV6 prefixes >> with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 >> prefix in them. Hence the distinction between IPv4 and IPv6 prefixes >> is quite clear >> >> */[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. >> Quoting from RFC 4291:/* >> >> >> *2.5.5.2* >> *.  >> IPv4-Mapped IPv6 Address* >> >>    A second type of IPv6 address that holds an embedded IPv4 address is >> >>    defined. This address type is used to represent the addresses of >> >>    IPv4 nodes as IPv6 addresses. >> >> *//* >> >> */From my POV this means that a /128 prefix associated with an >> IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 >> address that was mapped to this IPv6 address represent the same >> entity. This understanding fully matches usage of IPv4-mapped IPv6 >> addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. >> However, the comparison rules you have defined will treat them as two >> different prefixes.  I wonder if these rules, in the case of a >> conflict, could result in preferring the IPv6 prefix to an IPv4 one >> and therefore loosing MPLS connectivity for the ingress PE of a 6VPE >> service to its egress PE?/* >> >> */##Ahmed: The basic MPLS architecture does not forbid assigning >> different labels to the same prefix, nonetheless to different >> prefixes belonging to the same node or the same interface on the same >> node. One of the fundamental concepts of SR-MPLS is that the same >> prefix-SID must not be assigned to two different prefixes. So for the >> particular scenario of embedding IPv4 in IPv6, the operator must >> assign different SIDs to the IPv4 address and the IPv4-mapped IPv6 >> address that embeds it, otherwise the label will be subject to the >> incoming label collision resolution >> >> >> >> /* >> >> >> >> >> >> f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not >> sure all SID types defined in the Segment Routing Architecture >> draft can be unambiguously mapped to one of these types. >> Problematic examples include at least the following: >> >> i.Parallel Adjacency SID >> >> ii.Mirror SID >> >> Explicit mapping of SID types to SR-MPLS FEC types would be most >> useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, >> this must be explicitly stated in the draft. >> >> #Ahmed: >> Parallel adjacency SID are handled in the type "(next-hop, outgoing >> interface)" >> >> */[[Sasha]] OK/* >> >> >> Mirror SID is a type of binding-SID as mentioned in Section 5.1 in >> the SR architecture draft (draft-ietf-spring-segment-routing-15). >> Also as described in Section 2.4 >> draft-ietf-isis-segment-routing-extensions-18 (also see the >> equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is >> identified by a prefix. Hence it is covered by the type "(Prefix, >> Routing Instance, Topology, Algorithm)" >> >> */[[Sasha]] I respectfully disagree. There is definitely no mention >> of Algorithm in the definition of the Mirror SID. /* >> >> */##Ahmed: >> The last paragraph in Section 2 of >> draft-ietf-spring-segment-routing-14 says/* >> >>    We call "MPLS Control Plane Client (MCC)" any control plane entity >>    installing forwarding entries in the MPLS data plane. >> >> */The sentence starting at the 5th line of the first bullet of >> Section 2.5 of draft-ietf-spring-segment-routing-14 says/* >> >> For MCCs where the "Topology" and/or "Algorithm" >>       fields are not defined, the numerical value of zero MUST be used >>       for these two fields. >> >> */If a binding-SID is downloaded to the forwarding plane, then it >> must be associated with an MCC and hence it either has an "algorithm" >> or the value zero is assumed for the "algorithm" field. If the >> binding-SID is not downloaded to the forwarding plane, then it is >> irrelevant to the entire draft not only to incoming label collision/* >> >> >> >> >> >> 6.*Node SIDs in SR-MPLS*: >> >> a.Node SIDs are explicitly defined and discussed in the Segment >> Routing Architecture draft but are not mentioned even once in >> this draft >> >> b.AFAIK, the common implementation practice today includes >> assignment of at least one Node SID to every node in the SR-MPLS >> domain >> >> c.Is there a requirement to assign at least one Node SID per >> {routing instance, topology, algorithm} in SR-MPLS? If not, can >> the authors explain expected behavior of such a node? (See also >> my comment about routing instances below). >> >> #Ahmed: A Node-SID is a special case of prefix-SID. So there nothing >> specific about it from the MPLS forwarding plane point of view. >> Similarly from a standard tracks draft point of view, there is no >> requirement to assign a SID to every prefix just like there is no >> requirement to bind every prefix to an LDP label. Common and/or >> recommended practices or description of deployment scenarios are more >> befitting to BCP or informational drafts. This draft is a standards >> track draft >> >> */[[Sasha]] Well, you’ve just said that conflict resolution rules are >> RECOMMENDED, and this is quite common in the Standards Track RFCs. /* >> >> */##Ahmed: OK., I think we are in agreement here:)/* >> >> >> >> If a {routing instance, topology, algorithm} is not assigned a SID, >> then this FEC is totally irrelavant to this draft and hence >> describing how a node treats it is totally outside the scope of this >> draft >> >> */[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs >> mention routing instances that can be associated with the prefix, so >> I think that your reference to it is incorrect./* >> >> */What’s more I suspect that Node SIDs represent the most used >> special case of Prefix SIDs with Anycast SIDs being quite behind. >>  Therefore some recommendation pertaining to the usage of Node SIDs >> would be very much in place IMHO. /* >> >> */##Ahmed: The  term "routing instance" within the context of >> incoming label collision is defined in the first bullet in Section 2.5. >> As for any recommendation for useage of node-SID, anycast-SID,...,etc >> , it is out of the scope of this draft because it is a matter of of >> deployment/informational/BCP draft >> >> >> /* >> >> >> >> >> >> 7.*SRGB Size in SR-MPLS*: >> >> a.The draft correctly treats the situation when an index assigned >> to some global SID cannot be mapped to a label using the >> procedure in Section 2.4 as a conflict. >> >> b.At the same time the draft does not define any minimum size of >> SRGB (be it defined as a single contiguous block or as a sequence >> of such blocks) that MUST be implemented by all SR-capable nodes >> >> c.I suspect that lack of such a definition could be detrimental >> to interoperability of SR-MPLS solutions. AFAIK, the IETF has >> been following, for quite some time, a policy that some >> reasonable MUST-to-implement defaults should be assigned for all >> configurable parameters exactly in order to prevent this. >> >> #Ahmed: This document specifies how the SRGB is used and the behavior >> of routers when a prefix-SID index maps to a label inside and/or >> outside the SRGB. The actual size of the SRGB is a task in >> partitioning the label space, which is very specific to a particular >> deployment scenario. So IMO it is outside the scope of a standards >> track document. Now that SR-MPLS is deployed in many places, I expect >> the community to gain sufficient experience to recommend (or not >> recommend) a particular minimum/maximum size for the SRGB is some >> future informational or BCP draft/RFC >> >> */[[Sasha]] My reading of your response is that minimum size of SRGB >> is an issue for future study. Can you please just add this to the >> draft?/* >> >> */##Ahmed: OK. Added a sentence to the last paragraph of section 2.3/* >> >> >> >> >> >> >> 8.*Algorithms and Prefix SIDs*: >> >> a.The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) >> in, but it does not explicitly link them with the Prefix-SID >> algorithms defined in section 3.1.1 of the Segment Routing >> Architecture draft >> >> #Ahmed: I will just add the reference >> [I-D.ietf-spring-segment-routing]right beside the first time >> "Algorithm" is mentioned >> >> */[[Sasha]] OK/* >> >> >> >> >> >> b.From my POV, the draft should explicitly state that the default >> Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant >> routers. >> >> #Ahmed: The specification of what path calculation method should or >> must be supported is a routing protocol property not a forwarding >> plane property. In fact, the choice of a path calculation method or >> algorithm is completely orthogonal to the routed protocol. Hence >> mandating the support of a particular routing algorithm is beyond the >> scope of this document. >> >> */[[Sasha]] OK/* >> >> >> >> >> >> c.The Segment Routing Architecture draft states (in section >> 3.1.3) that “Support of multiple algorithms applies to SRv6â€. But >> neither draft states whether multiple algorithms apply to >> SR-MPLS. Can you please clarify this point? >> >> #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in >> draft-ietf-spring-segment-routing-15 discusses the support of >> multiple algorithms. So it is implied that the concept of algorithm >> applies to SR-MPLS. Hence there is no need to re-mention it here >> >> */[[Sasha]] The paragraph to which you refer only says that if a >> packet with the active Prefix-SID that is associated with a specific >> algorithm is received by a node that does not support this algorithm, >> this packet will be discarded. If this is the only type of support >> for multiple algorithms SR provides, it is not very useful IMHO/**/. /* >> >> */##Ahmed: The SR-MPLS draft that we are discussing here does not >> attempt to modify the SR-architecture draft. Any concerns related to >> the SR-architecture should be addressed to the SR-architecture draft >> not to this draft. /* >> >> >> >> >> >> 9.*Routing instances and the context for Prefix-SIDs*: >> >> a.The Segment Routing Architecture draft states in Section 3.1 >> that the “context for an IGP-Prefix segment includes the prefix, >> topology, and algorithm†>> >> b.This draft seems to define (in section 2.5) the context for the >> Prefix SID as “Prefix, Routing Instance, Topology, Algorithm†>> where â€a routing instance is identified by a single incoming >> label downloader to FIB†(but the notion of the label downloader >> to FIB is not defined). >> >> c.These two definitions look different to me. >> >> d.At the very least I would expect alignment between the >> definitions of context for the Prefix-SID between the two drafts. >> Preferably, the definition given in the Segment Routing >> Architecture draft should be used in both drafts. >> >> #Ahmed: The context of the section 2.5 is limited to the resolution >> of local label collision. The use of "routing instance" in section >> 2.5 is just there for tie-breaking if there is local label collision. >> >> */[[Sasha]] I have already mentioned that “routing instances†are not >> defined in any the drafts dealing with SR Extensions for IGPs. So I >> do not understand how the conflict resolution procedure is supposed >> to use this. And in any case the difference between two definitions >> of the context of Prefix-SID requires some explanation./* >> >> */##Ahmed: incoming label collision defines what is a routing >> instance within its context. I do not understand what explanation you >> are looking for/* >> >> >> >> >> >> >> >> 10.*Example of PUSH operation in Section 2.10.1*: >> >> a.The first para of this section begins with the sentence >> “Suppose an MCC on a router "R0" determines that PUSH or >> CONTINUE   operation is to be applied to an incoming packet whose >> active SID is the global SID "Si"â€. In the context of SR-MPLS >> this means (to me) that the incoming packet is a labeled packet >> and its top label matches the global SID “Siâ€. >> >> b.However, the example for PUSH operation in the next para of >> this section is the case of an (unlabeled) IP packet with the >> destination address covered by the IP prefix for which “Si†has >> been assigned. >> >> c.From my POV: >> >> i.Mapping unlabeled packets to SIDs is indeed out of scope of the >> draft. Therefore an example of a PUSH operation that is applied >> to a labeled packet (with the active SID inferred from the top >> label in the stack) is preferable. >> >> ii.Valid examples of  PUSH operation applied to a labeled >> incoming packet can be found in Sections 4.2 or 4.3 of the TI-LFA >> >> draft >> >> #Ahmed: I do not understand your concern here:) >> >> >> >> */[[Sasha]] I think it is pretty clear: can you provide an example of >> a PUSH operation applied to a labeled packet instead of your current >> example?/* >> >> */##Ahmed: The example in the draft is included to clarify the >> concept of a prefix SID attached to a prefix. As mentioned more than >> once, SR-MPLS does not modify MPLS forwarding including pushing a >> label on a labeled packet. It is something that has been done by >> routers and switches for 20+ years. So including it here is redundant/* >> >> >> *Nits*: >> >> 1.I concur with Adrian regarding numerous nits he has reported in >> his WG LC Comment >> . >> I would like to thank Adrian for an excellent review that have >> saved me lots of hard work. >> >> #Ahmed: I also agree that Adrian's review is exceptional. I believe I >> addressed all his comments in the latest version. >> >> >> >> 2.In addition, I’d like to report the following nits: >> >> a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA >> >> draft) >> >> #Ahmed: Already done in the latest version*/[[Sasha]] OK/* >> >> >> >> b.TI-LFA draft is referenced in the text of Section 2.11.1, but >> there is no matching reference in the “References†section >> (probably, Informational) >> >> #Ahmed: Already done in the latest version*/[[Sasha]] OK/* >> >> >> >> c.“zero Algorithm†in Section 2.5 (immediately above Section >> 2.5.1) must be replaced with “default algorithmâ€. Similarly, >> “non-zero Algorithm†should be replaced with “non-default algorithm†>> >> #Ahmed: Will be done in the next version*/[[Sasha]] /* OK >> >> >> >> 3.I think that RFC 3443 and RFC 5332 should be listed as >> Normative references in this draft while RFC 5331 and RFC 8277 >> should be listed as Informative references. This would improve >> the readability of the draft without any impact on its advancement. >> >> #Ahmed RFC5331 describes upstream label assignment. As you mentioned >> above (and I will modify the draft to indicate that) SR-MPLS behavior >> is similar to downstream label assignment. RFC 3443 describes TTL >> behavior. This is an MPLS forwarding behavior. As mentioned in the >> draft, SR-MPLS does not modify at the MPLS forwarding behavior >> >> */[[Sasha]] Regarding RFC 5331 – you may skip this reference if you >> state (as discussed below) that SR-MPLS only allocates labels from >> the per-platform label space. Regarding RFC 3443 – I do not think >> that you can fully avoid discussion of Uniform and Pipe/Short Pipe >> models, and therefore you will need this reference./* >> >> */##Ahmed: I did not add rfc5331 as a reference . Again pushing >> multiple labels on top of a packet is a matter of SR-policy, which is >> handled in a separate draft. /* >> >> >> >> >> >> >> >> Hopefully, these comments will be useful. >> >> #Ahmed: They are certainly quite useful. Thanks a lot >> >> >> >> Regards, >> >> Sasha >> >> Office: +972-39266302 >> >> Cell:      +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> ___________________________________________________________________________ >> >> This e-mail message is intended for the recipient only and >> contains information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you >> have received this >> transmission in error, please inform us by e-mail, phone or fax, >> and then delete the original >> and all copies thereof. >> ___________________________________________________________________________ >> >> >> ___________________________________________________________________________ >> >> This e-mail message is intended for the recipient only and contains >> information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have >> received this >> transmission in error, please inform us by e-mail, phone or fax, and >> then delete the original >> and all copies thereof. >> ___________________________________________________________________________ >> >> _________________________________________________________________________________________________________________________ >> >> 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. >> >> ___________________________________________________________________________ >> >> This e-mail message is intended for the recipient only and contains >> information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have >> received this >> transmission in error, please inform us by e-mail, phone or fax, and >> then delete the original >> and all copies thereof. >> ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ --------------C9D2DD0DBF0D0F68F788001B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks a lot
I appreciate your help to close this draft
Ahmed

On 10/27/18 8:15 PM, Alexander Vainshtein wrote:
Ahmed and all,
I am on vacation this week with just my cell phone to see my emails.

I will provide some wording once I am back.

Meanwhile, apologies for the delay,
Sasha

Thumb typed by Sasha Vainshtein

From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Sent: Sunday, October 28, 2018 3:02:45 AM
To: Alexander Vainshtein; stephane.litkowski@orange.com
Cc: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net; spring@ietf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13
 
Sasha

I uploaded version 15. But I was not sure how to best address your concern

So Please propose the wording/modifications that looks reasonable to you and I will be more than happy to incorporate them

Ahmed

(I replied to this email a little while ago but I am replying to it again with a cutdown on the list of receipts because the mailing list said the email is being held)



On 7/25/18 12:20 AM, Alexander Vainshtein wrote:

Stephane,

Lots of thanks for your email, and apologies for a long delayed response.

Regarding you reference to “BGP 3107 label over an LDP label over an RSVP label to build an end-to-end transportâ€, I have looked up RFC 8277  that has replaced RFC 3107, and found there the following explicit statement:

   When pushing labels onto a packet's label stack, the Time-to-Live
   (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field
   ([RFC3032], [RFC5462]) of each label stack entry must, of course, be
   set.  This document does not specify any set of rules for setting
   these fields; that is a matter of local policy.

 

No equivalent of this statement could be found in RFC 3107 – probably because RFC 3443 has not yet been published then.

From my POV including the same (or equivalent) explicit statement in the draft would be sufficient to resolve the issue.

Hope this helps.

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

Hi Sasha,

> The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.

Why do you think this is different from a nested MPLS tunnel that exists today ? I completely agree with you that the head end does not know the behavior of the tail-end in term of TTL/TC processing. But that’s already the case today, and it’s the job of engineers to ensure that all nodes in the network are operating in the same mode (uniform vs pipe/short pipe).

We can already stack today a BGP 3107 label over an LDP label over an RSVP label to build an end-to-end transport, the TTL processing should not be essentially different.

Could you pin point the difference that you see ?

 

Brgds,

 

Stephane

 

 

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Monday, July 16, 2018 22:03
To: Alexander Vainshtein
Cc: rtg-dir@ietf.org; 'mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Thanks a lot for the reply

See inline "##Ahmed"

 

On 7/11/18 2:02 AM, Alexander Vainshtein wrote:

Ahmed, and all,

Lots of thanks for a detailed response to my comments.

Please see inline below my position on each of them.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

Thanks for thorough (and VERY clear) the review

See inline #Ahmed

 

Ahmed

 

 

On 6/15/18 11:08 PM, Alexander Vainshtein wrote:

Re-sending to  correct SPRING WG list.

Sincere apologies for the delay caused by a typo.

Thumb typed by Sasha Vainshtein

 

From: Alexander Vainshtein
Sent: Sunday, June 10, 2018 10:43:52 AM
To: spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Cc: spring@ietf.com; rtg-dir@ietf.org; 'mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Explicitly adding Shraddha  who is the shepherd of this draft.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

 

Hello,

I have been selected to do a routing directorate “early†review of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

 

The routing directorate will, on request from the working group chair, perform an “early†review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is currently in the WG Last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

 

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

 

Document: draft-ietf-spring-segment-routing-mpls-13

Reviewer: Alexander (“Sashaâ€) Vainshtein (alexander.vainshtein@ecitele.com)

Review Date: 08-Jun-18

Intended Status: Proposed Standard.

 

Summary:

 

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

 

Comments:

 

I consider this draft as an important  companion document to the Segment Routing Architecture draft that, ideally, should augment definitions of the Segment Routing (SR) notions and constructs given there with details specific for the SR instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised in my review reflect either gaps that should be, but have not been, closed, or inconsistencies between the two drafts.

 

 

Since RFC 8287 is already published as a Standards Track RFC, I expect such augmentation to be backward compatible with this document (or to provide clear indications of required updates to this document). And I include the MPLS WG into distribution list.

 

This draft was not easy reading for me. In particular, the style of Section 2.5 that discusses at length and in some detail multiple “corner cases†resulting, presumably, from misconfiguration, before it explains the basic (and relatively simple) “normal†behavior, looks problematic to me.

 

The WG Last Call has been extended by one week. Nevertheless, I am sending out my comments

 

Major Issues: None found

#Ahmed: thanks a lot



 

Minor Issues: Quite a few but, hopefully, easy to resolve.

 

1.    Encapsulation of SR-MPLS packets:

a.    RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned in the draft) depend two encapsulations of labeled packets - one for Downstream-allocated labels and another for Upstream-allocated ones.

#Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of draft-ietf-spring-segment-routing-15, multicast is outside the scope of SR. Hence the RFC was not referred to in the SR-MPLS draft

[[Sasha]] I would be satisfied with this response, would it not be for the following text I see in Section 2.2 of the SR Policy Architecture draft:

   A variation of SR Policy can be used for packet replication.  A

   candidate path could comprise multiple SID-Lists; one for each

   replication path.  In such a scenario, packets are actually

   replicated through each SID List of the SR Policy to realize a point-

   to-multipoint service delivery.

 

This looks to me as being very much multicast in SR, and, unless you want to say that it is limited to SRv6, makes my question relevant IMHO.

##Ahmed: The main reference for this draft is the sr-architecture, which clearly states that multicast is out of SR scope. SR-MPLS, being an MPLS instantiation of the SR-architecture, follows the SR-architecture as close as possible. If another draft proposes something related to SR, then it is the responsibility of the other draft to mention any extensions/restrictions in relation to the basic draft-ietf-spring-segment-routing and/or SR-MPLS, or to specifically say that it does not apply to SR-MPLS.


b.    From my POV the ST-MPLS only uses Downstream-allocated labels – but I expect the draft to state that explicitly, one way or another. (If Upstream-allocated labels are relevant for SR-MPLS, I would see it as a major gap, so I hope that this is not the case).

#Ahmed: I will add a statement in section 2.2 to mention that it is down-stream allocated as you mentioned

[[Sasha]] This is quite unambiguous and, once added, would resolve my comment in full – the previous comment notwithstanding. In particular, it would imply that even labels representing BSIDs of a SR Replication policies will be downstream-allocated.

#Ahmed: Binding SID is just a special case of a SID. So what applies to a SID applies to a binding SID


 

2.    Label spaces in SR-MPLS:

a.    RFC 3031 (referenced by the draft) defines per-platform and per-interface label spaces, and RFC 5331 (not mentioned in the draft) adds context-specific label spaces and context labels.

b.    The draft does not say which of these are or are not relevant for SR-MPLS

c.    From my POV:

                                         i.    Labels representing all kinds of SIDs mentioned in the draft MUST be allocated from the per-platform label space only

                                        ii.    At the same time, instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment Routing Architecture draft using MPLS data plane clearly calls for context labels and context-specific label spaces

d.    I expect the draft to provide a clear-cut position on these aspects of SR-MPLS.

#Ahmed: I will add a statement to section 2.2 to say that the it is per-platform. Regarding the function "mirroring", SR attaches a *function* to each SID. The "mirroring" function is already described in Section 5.1 of draft-ietf-spring-segment-routing and is not specific to the MPLS forwarding plane. Hence there is no need to re-mention it here because this document is trying to be as specific as possible to the MPLS forwarding plane. General functions attached to SID are described in the segment routing architecture document or future documents. Furture documents proposing new SR function must be as specific and clear as possible

[[Sasha]] Looks OK to me.





3.    SR-MPLS and hierarchical LSPs:

a.    SR LSPs that include more than one segment are hierarchical LSPs from the POV of the MPLS data plane. Therefore some (possibly, all) of the models for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned in the draft) should apply to SR-MPLS

b.    RFC 8287 (not referenced in the draft) specifically discussed operation of the LSP Traceroute function for SR LSPs in the case when Pipe/Short Pipe model for TTL handling is used

c.    I expect the draft to provide at least some guidelines regarding applicability of each specific model defined in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.

#Ahmed: BY design, the instantiation of SR over the MPLS forwarding plane (and hence this draft) does not modify the MPLS forwarding plan behavior as it is mentioned in the first sentence in Section 1. So the TTL behavior specified in rfc3443 is already implied and there is no need to re-mention it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specific.  SR-OAM is handled in a separate document so is outside the scope of this draft

[[Sasha]] Unfortunately I do not think this is good enough. Let me ask a specific question reflecting my concerns:

The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.

RFC 8287 is relevant as an example here IMHO because it recommends the following setting of TTL in Traceroute packets:

-          Set the TTL of all the labels above one that represents the segment you are currently tracing to maximum

-          Set the TTL of the label one that represents the segment you are currently tracing to the desired value (to be incremented until end of segment is reached

-          Set the TTL of all the labels below one that represents the segment you are currently tracing to 0.

I expect the draft to provide some recommendations for traffic (non-OAM) packets as well.

##Ahmed: The setting of the TTL for non-OAM packets are subject to the policy that constructed the label stack. SR-policy is handled in a separate draft 






4.    Inferring network layer protocol in SR-MPLS:

a.    I wonder if the draft could provide any details on the situation when a label that represents some kind of SID is the bottom-of-stack label to be popped by the egress LER

#ahmed: This is part of the "Next" function. It is described in detail in this document.

[[Sasha]] NEXT function is mentioned in several places in the document. Can you please point to the specific text that is relevant for my question?

##Ahmed: Part (a) here is a statement not a question. What is the question?






b.    For the reference, RFC 3032 says that “the identity of the network layer protocol  must be inferable from the value of the label which is popped from  the bottom of the stack, possibly along with the contents  of the network layer header itselfâ€

c.    From my POV the following scenario indicates relevance of this expectation for SR-MPLS:

                                         i.    IS-IS is used for distributing both IPv4 and IPv6 reachability in a given domain

                                        ii.    An IS-IS adjacency over some dual-stack link is established, and a single Adj-SID for this adjacency is advertised

                                       iii.    The node that has assigned and advertised this Adj-SID receives a labeled packet with the label representing this Adj-SID being both the top and bottom-of-stack label

                                       iv.    The implementers must be given unambiguous instructions for forwarding the unlabeled packet via the dual-stack link as an Ipv4 or an IPv6 packet.

#Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to specify whether the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a prefix-SID to the prefix advertisement and hence implies the identity of the protocol underneath the bottom most label. For any other "function" attached to a SID, it is part of the specification of this function to describe what happens when the SID is represented by a label in the MPLS forwarding plane and this label is the bottom most label

[[Sasha]] OK, got it. This issue is resolved.





5.    Resolution of Conflicts: Are the

a.    Are the conflict resolution procedures listed in section 2.5 mandatory to implement?

b.    If they are mandatory to implement, are they also mandatory to deploy, or can the operators simply treat any detected conflict as requiring human intervention and preventing normal operation of SR-MPLS?

#Ahmed: They are recommended. I will modify the paragraph after the first 3 bullets in Section 2.5 to say that it is recommeded.  



[[Sasha]] OK. However, it would be nice if you could refer separately for “RECOMMENDED to implement†and “RECOMMENDED to deployâ€.  The latter probably requires a configuration knob for enabling conflict resolution rules (if they are implemented).

c.    For the reference, the IETF capitalized MUST appears just in a few places in Section 2.5, and each appearance has very narrow context:

                                         i.    For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zero MUST be used for these two fields

                                        ii.    If the same set of FECs are attached to the same label "L1", then the tie-breaking rules MUST always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic.

                                       iii.    An implementation of explicit SID assignment MUST guarantee collision freeness on the same router

From my POV, it is not possible to infer the answer to my question from these statements. Some explicit statement is required.

#Ahmed: I agree with you POV and as mentioned in my reply to items (a) and (b), I will modify the paragraph to say that it is RECOMMENDED to answer you questions in items (a) and (b)



d.    The tie-breaking rules in section 2.5.1 include some specific values for encoding FEC types and address families – but these values are not supposed to appear in any IANA registries (because the draft does not request any IANA actions). Can you please clarify what is so special about these values?

#Ahmed: There is no significance to the values but there is a significance to the order among them. I will modify the text to clarify that

[[Sasha]] OK.





e.    I also doubt that comparison of FECs that represent IPv4 and IPv6 prefix SIDs makes much sense (for conflict resolution or else), because, among other things, there are valid scenarios when an IPv4 /32 prefix is embedded in an IPv6 /128 one.

#Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that embeds an IPv4 prefix is different from the IPv4 prefix. The specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately, including the IPV6 prefixes with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix in them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear

[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. Quoting from RFC 4291:

2.5.5.2.  IPv4-Mapped IPv6 Address

 

 

   A second type of IPv6 address that holds an embedded IPv4 address is

   defined.  This address type is used to represent the addresses of

   IPv4 nodes as IPv6 addresses.

 

From my POV this means that a /128 prefix associated with an IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 address that was mapped to this IPv6 address represent the same entity. This understanding fully matches usage of IPv4-mapped IPv6 addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. However, the comparison rules you have defined will treat them as two different prefixes.  I wonder if these rules, in the case of a conflict, could result in preferring the IPv6 prefix to an IPv4 one and therefore loosing MPLS connectivity for the ingress PE of a 6VPE service to its egress PE?

##Ahmed: The basic MPLS architecture does not forbid assigning different labels to the same prefix, nonetheless to different prefixes belonging to the same node or the same interface on the same node. One of the fundamental concepts of SR-MPLS is that the same prefix-SID must not be assigned to two different prefixes. So for the particular scenario of embedding IPv4 in IPv6, the operator must assign different SIDs to the IPv4 address and the IPv4-mapped IPv6 address that embeds it, otherwise the label will be subject to the incoming label collision resolution







f.     Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure all SID types defined in the Segment Routing Architecture draft can be unambiguously mapped to one of these types. Problematic examples include at least the following:

                                         i.    Parallel Adjacency SID

                                        ii.    Mirror SID

Explicit mapping of SID types to SR-MPLS FEC types would be most useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, this must be explicitly stated in the draft.

#Ahmed:
Parallel adjacency SID are handled in the type "(next-hop, outgoing interface)"

[[Sasha]] OK


Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR architecture draft (draft-ietf-spring-segment-routing-15). Also as described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18 (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is identified by a prefix. Hence it is covered by the type "(Prefix, Routing Instance, Topology, Algorithm)"

[[Sasha]] I respectfully disagree. There is definitely no mention of Algorithm in the definition of the Mirror SID.

##Ahmed:
The last paragraph in Section 2 of draft-ietf-spring-segment-routing-14 says

   We call "MPLS Control Plane Client (MCC)" any control plane entity
   installing forwarding entries in the MPLS data plane.

The sentence starting at the 5th line of the first bullet of Section 2.5 of draft-ietf-spring-segment-routing-14 says

For MCCs where the "Topology" and/or "Algorithm"
      fields are not defined, the numerical value of zero MUST be used
      for these two fields.

If a binding-SID is downloaded to the forwarding plane, then it must be associated with an MCC and hence it either has an "algorithm" or the value zero is assumed for the "algorithm" field. If the binding-SID is not downloaded to the forwarding plane, then it is irrelevant to the entire draft not only to incoming label collision





6.    Node SIDs in SR-MPLS:

a.    Node SIDs are explicitly defined and discussed in the Segment Routing Architecture draft but are not mentioned even once in this draft

b.    AFAIK, the common implementation practice today includes assignment of at least one Node SID to every node in the SR-MPLS domain

c.    Is there a requirement to assign at least one Node SID per {routing instance, topology, algorithm} in SR-MPLS? If not, can the authors explain expected behavior of such a node? (See also my comment about routing instances below).

#Ahmed: A Node-SID is a special case of prefix-SID. So there nothing specific about it from the MPLS forwarding plane point of view. Similarly from a standard tracks draft point of view, there is no requirement to assign a SID to every prefix just like there is no requirement to bind every prefix to an LDP label. Common and/or recommended practices or description of deployment scenarios are more befitting to BCP or informational drafts. This draft is a standards track draft

[[Sasha]] Well, you’ve just said that conflict resolution rules are RECOMMENDED, and this is quite common in the Standards Track RFCs.

##Ahmed: OK., I think we are in agreement here:)



If a {routing instance, topology, algorithm} is not assigned a SID, then this FEC is totally irrelavant to this draft and hence describing how a node treats it is totally outside the scope of this draft

[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention routing instances that can be associated with the prefix, so I think that your reference to it is incorrect.

What’s more I suspect that Node SIDs represent the most used special case of Prefix SIDs with Anycast SIDs being quite behind.  Therefore some recommendation pertaining to the usage of Node SIDs would be very much in place IMHO.

##Ahmed: The  term "routing instance" within the context of incoming label collision is defined in the first bullet in Section 2.5.
As for any recommendation for useage of node-SID, anycast-SID,...,etc , it is out of the scope of this draft because it is a matter of of deployment/informational/BCP draft






7.    SRGB Size in SR-MPLS:

a.    The draft correctly treats the situation when an index assigned to some global SID cannot be mapped to a label using the procedure in Section 2.4 as a conflict.

b.    At the same time the draft does not define any minimum size of SRGB (be it defined as a single contiguous block or as a sequence of such blocks) that MUST be implemented by all SR-capable nodes

c.    I suspect that lack of such a definition could be detrimental to interoperability of SR-MPLS solutions. AFAIK, the IETF has been following, for quite some time, a policy that some reasonable MUST-to-implement defaults should be assigned for all configurable parameters exactly in order to prevent this.

#Ahmed: This document specifies how the SRGB is used and the behavior of routers when a prefix-SID index maps to a label inside and/or outside the SRGB. The actual size of the SRGB is a task in partitioning the label space, which is very specific to a particular deployment scenario. So IMO it is outside the scope of a standards track document. Now that SR-MPLS is deployed in many places, I expect the community to gain sufficient experience to recommend (or not recommend) a particular minimum/maximum size for the SRGB is some future informational or BCP draft/RFC

[[Sasha]] My reading of your response is that minimum size of SRGB is an issue for future study. Can you please just add this to the draft?

##Ahmed: OK. Added a sentence to the last paragraph of section 2.3






8.    Algorithms and Prefix SIDs:

a.    The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, but it does not explicitly link them with the Prefix-SID algorithms defined in section 3.1.1 of the Segment Routing Architecture draft

#Ahmed: I will just add the reference [I-D.ietf-spring-segment-routing] right beside the first time "Algorithm" is mentioned

[[Sasha]] OK





b.    From my POV, the draft should explicitly state that the default Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.

#Ahmed: The specification of what path calculation method should or must be supported is a routing protocol property not a forwarding plane property. In fact, the choice of a path calculation method or algorithm is completely orthogonal to the routed protocol. Hence mandating the support of a particular routing algorithm is beyond the scope of this document.

[[Sasha]] OK





c.    The Segment Routing Architecture draft states (in section 3.1.3) that “Support of multiple algorithms applies to SRv6â€. But neither draft states whether multiple algorithms apply to SR-MPLS. Can you please clarify this point?

#Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in draft-ietf-spring-segment-routing-15 discusses the support of multiple algorithms. So it is implied that the concept of algorithm applies to SR-MPLS. Hence there is no need to re-mention it here

[[Sasha]] The paragraph to which you refer only says that if a packet with the active Prefix-SID that is associated with a specific algorithm is received by a node that does not support this algorithm, this packet will be discarded. If this is the only type of support for multiple algorithms SR provides, it is not very useful IMHO.

##Ahmed: The SR-MPLS draft that we are discussing here does not attempt to modify the SR-architecture draft. Any concerns related to the SR-architecture should be addressed to the SR-architecture draft not to this draft.





9.    Routing instances and the context for Prefix-SIDs:

a.    The Segment Routing Architecture draft states in Section 3.1 that the “context for an IGP-Prefix segment includes the prefix, topology, and algorithmâ€

b.    This draft seems to define (in section 2.5) the context for the Prefix SID as “Prefix, Routing Instance, Topology, Algorithm†where â€a routing instance is identified by a single incoming label downloader to FIB†(but the notion of the label downloader to FIB is not defined).

c.    These two definitions look different to me.

d.    At the very least I would expect alignment between the definitions of context for the Prefix-SID between the two drafts. Preferably, the definition given in the Segment Routing Architecture draft should be used in both drafts.

#Ahmed: The context of the section 2.5 is limited to the resolution of local label collision. The use of "routing instance" in section 2.5 is just there for tie-breaking if there is local label collision.

[[Sasha]] I have already mentioned that “routing instances†are not defined in any the drafts dealing with SR Extensions for IGPs. So I do not understand how the conflict resolution procedure is supposed to use this. And in any case the difference between two definitions of the context of Prefix-SID requires some explanation.

##Ahmed: incoming label collision defines what is a routing instance within its context. I do not understand what explanation you are looking for







10. Example of PUSH operation in Section 2.10.1:

a.    The first para of this section begins with the sentence “Suppose an MCC on a router "R0" determines that PUSH or CONTINUE   operation is to be applied to an incoming packet whose active SID is the global SID "Si"â€. In the context of SR-MPLS this means (to me) that the incoming packet is a labeled packet and its top label matches the global SID “Siâ€.

b.    However, the example for PUSH operation in the next para of this section is the case of an (unlabeled) IP packet with the destination address covered by the IP prefix for which “Si†has been assigned.

c.    From my POV:

                                         i.    Mapping unlabeled packets to SIDs is indeed out of scope of the draft. Therefore an example of a PUSH operation that is applied to a labeled packet (with the active SID inferred from the top label in the stack) is preferable.

                                        ii.    Valid examples of  PUSH operation applied to a labeled incoming packet can be found in Sections 4.2 or 4.3 of the TI-LFA draft

 

#Ahmed: I do not understand your concern here:)



[[Sasha]] I think it is pretty clear: can you provide an example of a PUSH operation applied to a labeled packet instead of your current example?

##Ahmed: The example in the draft is included to clarify the concept of a prefix SID attached to a prefix. As mentioned more than once, SR-MPLS does not modify MPLS forwarding including pushing a label on a labeled packet. It is something that has been done by routers and switches for 20+ years. So including it here is redundant


Nits:

1.    I concur with Adrian regarding numerous nits he has reported in his WG LC Comment. I would like to thank Adrian for an excellent review that have saved me lots of hard work.

#Ahmed: I also agree that Adrian's review is exceptional. I believe I addressed all his comments in the latest version.



2.    In addition, I’d like to report the following nits:

a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA draft)

#Ahmed: Already done in the latest version[[Sasha]] OK



b.    TI-LFA draft is referenced in the text of Section 2.11.1, but there is no matching reference in the “References†section (probably, Informational)

#Ahmed: Already done in the latest version[[Sasha]] OK



c.    “zero Algorithm†in Section 2.5 (immediately above Section 2.5.1) must be replaced with “default algorithmâ€. Similarly, “non-zero Algorithm†should be replaced with “non-default algorithmâ€

#Ahmed: Will be done in the next version[[Sasha]]  OK



3.    I think that RFC 3443 and RFC 5332 should be listed as Normative references in this draft while RFC 5331 and RFC 8277 should be listed as Informative references. This would improve the readability of the draft without any impact on its advancement.

 

#Ahmed RFC5331 describes upstream label assignment. As you mentioned above (and I will modify the draft to indicate that) SR-MPLS behavior is similar to downstream label assignment. RFC 3443 describes TTL behavior. This is an MPLS forwarding behavior. As mentioned in the draft, SR-MPLS does not modify at the MPLS forwarding behavior

[[Sasha]] Regarding RFC 5331 – you may skip this reference if you state (as discussed below) that SR-MPLS only allocates labels from the per-platform label space. Regarding RFC 3443 – I do not think that you can fully avoid discussion of Uniform and Pipe/Short Pipe models, and therefore you will need this reference.

##Ahmed: I did not add rfc5331 as a reference . Again pushing multiple labels on top of a packet is a matter of SR-policy, which is handled in a separate draft.







Hopefully, these comments will be useful.

#Ahmed: They are certainly quite useful. Thanks a lot



 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 

_________________________________________________________________________________________________________________________
 
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.

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

--------------C9D2DD0DBF0D0F68F788001B-- From nobody Mon Oct 29 00:53:31 2018 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 2504D126F72; Sat, 27 Oct 2018 15:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 IKTJeHVeoc9L; Sat, 27 Oct 2018 15:47:00 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 314CA130DDA; Sat, 27 Oct 2018 15:47:00 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id 30-v6so2056774plb.10; Sat, 27 Oct 2018 15:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=pXcoRvB5b7q1wG4kWJ8hm/cNeiJwojn6sA/cHHZKckY=; b=AFrBcga5z0XNXyczypBg7k1sLqj1uJK/Gtig63iENGL83EqX5J2tnKxk2WGGaf2bge 9cPGojdKXbD9F69LIlEpUcYlwZ+Yr8fI3/+Z2U1h0FPI46i0w0S0Vn+661XyeWtDaY68 ZhsGJ9lkF8YTKcQcvsJTrTeduTfcyKKEwYhbYbeE9g1la7szFnuQR0HYrHn+T4hestvw acacjlgV6rwKW0woPb6EFHnKqbDFFsh0kqJf7+iYOCHwMm63WtoSFBGqu/IhvoQxUo6b DGsaPPADXTeNq5eJhRWBSA7KCV7ASY/uaYV5rqdpoeSIyjfPHafZGIDDpBWpyCTZJiJ5 PP6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=pXcoRvB5b7q1wG4kWJ8hm/cNeiJwojn6sA/cHHZKckY=; b=cL6ro+SY0b8g9DsgBJ6ePSJbDC9J+1+aMvOYVTwE44bq8Qis8qPMnGfvF4MYYrFJKq Bzen2U3sWwR05HMUOEBYIUXkoQIbvGWMYt6M4SGrNhPgaFy6ZHSvj+q4di3GwV5XlR/e r0+kLmfasqljS8ZLQykCoQiiqGV5z6ivAUQJd6XDueNZrdqwO262B/C6McgpyuwMZ5HB vJMrOUW54UtLPzSjHZ2ABqlXlgLs5wHejwTF+ljwIhirIG3uLiGltgVzCkBYBdOfSfq0 fDzSLCvLzf9mv0rLAGwek7lExKHn9xeeD5Auw94Jdi0lbXcHJcB8gjhgSlqZVZAo85zt YYmA== X-Gm-Message-State: AGRZ1gIB/lmx31VUKqDGIlXqvP9QrZFrmL4/FDiYVAZW8ZzEEHBvqxSX N0jZa+PiDy4yPGFo4VPUkX4= X-Google-Smtp-Source: AJdET5c9u/K2AAB13YbRXcVmd6ak8jmePGiHEkgJQhusW2Vxxr0htsuoV2u3mNbVkr9W1RTXjcnHdg== X-Received: by 2002:a17:902:d88b:: with SMTP id b11-v6mr8589987plz.136.1540680419378; Sat, 27 Oct 2018 15:46:59 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id y88-v6sm102880pfd.104.2018.10.27.15.46.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 15:46:58 -0700 (PDT) To: Alexander Vainshtein , "stephane.litkowski@orange.com" Cc: "rtg-dir@ietf.org" , "'mpls@ietf.org'" , "'adrian@olddog.co.uk'" , "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" , "shraddha@juniper.net" , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" References: <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> <8f6b91d0-27de-f92e-6908-598977a05e0d@gmail.com> <32502_1531913237_5B4F2415_32502_461_3_9E32478DFA9976438E7A22F69B08FF924B1FF359@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Ahmed Bashandy Message-ID: <8f509a99-badd-fcd4-777b-51294fe344c0@gmail.com> Date: Sat, 27 Oct 2018 15:46:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------83F8216D09A2658E8EA73302" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Mon, 29 Oct 2018 00:53:30 -0700 Subject: Re: [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 22:47:08 -0000 This is a multi-part message in MIME format. --------------83F8216D09A2658E8EA73302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sasha I uploaded version 15. But I was not sure how to best address your concern So Please propose the wording/modifications that looks reasonable to you and I will be more than happy to incorporate them Ahmed On 7/25/18 12:20 AM, Alexander Vainshtein wrote: > > Stephane, > > Lots of thanks for your email, and apologies for a long delayed response. > > Regarding you reference to “BGP 3107 label over an LDP label over an > RSVP label to build an end-to-end transportâ€, I have looked up RFC > 8277  that has replaced RFC > 3107, and found there the following */explicit/* statement: > >    When pushing labels onto a packet's label stack, the Time-to-Live >    (TTL) field ([RFC3032 ], > [RFC3443 ]) and the Traffic Class > (TC) field >    ([RFC3032 ], [RFC5462 > ]) of each label stack entry > must, of course, be >    set.  This document does not specify any set of rules for setting >    these fields; that is a matter of local policy. > > No equivalent of this statement could be found in RFC 3107 – probably > because RFC 3443 has not yet been published then. > > From my POV including the same (or equivalent) explicit statement in > the draft would be sufficient to resolve the issue. > > Hope this helps. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:*stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > *Sent:* Wednesday, July 18, 2018 2:27 PM > *To:* Ahmed Bashandy ; Alexander Vainshtein > > *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; > 'adrian@olddog.co.uk' ; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com) ; > shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > *Subject:* RE: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Hi Sasha, > > >*/The head-end node sends SR-MPLS packets across a path defined by an > ordered set of SIDs with more than one SID in the list. Each SID is > represented by a label stack entry (LSE) in the MPLS label stack, and > the label field in each LSE is the label that matches the > corresponding SID. However, each LSE also includes the TTL and TC > fields. How does the head-end node set these fields in each of the > LSEs following the top one? This clearly depends on the model (Uniform > vs. Pipe/Short Pipe) implemented in each node that that performs Next > operation on the packet along the path – but the head-end node usually > is not aware of that. /* > > Why do you think this is different from a nested MPLS tunnel that > exists today ? I completely agree with you that the head end does not > know the behavior of the tail-end in term of TTL/TC processing. But > that’s already the case today, and it’s the job of engineers to ensure > that all nodes in the network are operating in the same mode (uniform > vs pipe/short pipe). > > We can already stack today a BGP 3107 label over an LDP label over an > RSVP label to build an end-to-end transport, the TTL processing should > not be essentially different. > > Could you pin point the difference that you see ? > > Brgds, > > Stephane > > *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] > *Sent:* Monday, July 16, 2018 22:03 > *To:* Alexander Vainshtein > *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org'; > 'adrian@olddog.co.uk'; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com > ); shraddha@juniper.net > ; spring@ietf.org > ; spring-chairs@ietf.org > ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Subject:* Re: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Thanks a lot for the reply > > See inline "##Ahmed" > > On 7/11/18 2:02 AM, Alexander Vainshtein wrote: > > Ahmed, and all, > > Lots of thanks for a detailed response to my comments. > > Please see */inline below/*my position on each of them. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] > *Sent:* Wednesday, July 11, 2018 4:42 AM > *To:* Alexander Vainshtein > ; spring-chairs@ietf.org > ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Cc:* rtg-dir@ietf.org ; 'mpls@ietf.org > ' ; > 'adrian@olddog.co.uk ' > ; Jonathan > Hardwick (Jonathan.Hardwick@metaswitch.com > ) > > ; shraddha@juniper.net > ; spring@ietf.org > > *Subject:* Re: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Thanks for thorough (and VERY clear) the review > > See inline #Ahmed > > Ahmed > > On 6/15/18 11:08 PM, Alexander Vainshtein wrote: > > Re-sending to  correct SPRING WG list. > > Sincere apologies for the delay caused by a typo. > > Thumb typed by Sasha Vainshtein > > ------------------------------------------------------------------------ > > *From:* Alexander Vainshtein > *Sent:* Sunday, June 10, 2018 10:43:52 AM > *To:* spring-chairs@ietf.org ; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org > > *Cc:* spring@ietf.com ; > rtg-dir@ietf.org ; 'mpls@ietf.org > '; 'adrian@olddog.co.uk > '; Jonathan Hardwick > (Jonathan.Hardwick@metaswitch.com > ); > shraddha@juniper.net > *Subject:* RE: RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Explicitly adding Shraddha  who is the shepherd of this draft. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:* Alexander Vainshtein > *Sent:* Friday, June 8, 2018 5:43 PM > *To:* 'spring-chairs@ietf.org ' > ; > 'draft-ietf-spring-segment-routing-mpls.authors@ietf.org > ' > > > *Cc:* 'spring@ietf.com ' > ; rtg-dir@ietf.org > ; mpls@ietf.org > ; 'adrian@olddog.co.uk > ' > > *Subject:* RtgDir Early review: > draft-ietf-spring-segment-routing-mpls-13 > > Hello, > > I have been selected to do a routing directorate “early†> review of this draft: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > > The routing directorate will, on request from the working > group chair, perform an “early†review of a draft before it is > submitted for publication to the IESG. The early review can be > performed at any time during the draft’s lifetime as a working > group document. The purpose of the early review depends on the > stage that the document has reached. As this document is > currently in the WG Last call, my focus for the review was to > determine whether the document is ready to be published. > Please consider my comments along with the other working group > last call comments. > > For more information about the Routing Directorate, please see > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > *Document*: draft-ietf-spring-segment-routing-mpls-13 > > *Reviewer*: Alexander (“Sashaâ€) Vainshtein > (alexander.vainshtein@ecitele.com > ) > > *Review Date*: 08-Jun-18 > > *Intended Status*: Proposed Standard. > > *Summary*: > > I have some minor concerns about this document that I think > should be resolved before it is submitted to the IESG. > > *Comments*: > > I consider this draft as an important  companion document to > the Segment Routing Architecture > > draft that, ideally, should augment definitions of the Segment > Routing (SR) notions and constructs given there with details > specific for the SR instantiation that uses  the MPLS data > plane (SR-MPLS).  Many issues raised in my review reflect > either gaps that should be, but have not been, closed, or > inconsistencies between the two drafts. > > Since RFC 8287 is > already published as a Standards Track RFC, I expect such > augmentation to be backward compatible with this document (or > to provide clear indications of required updates to this > document). And I include the MPLS WG into distribution list. > > This draft was not easy reading for me. In particular, the > style of Section 2.5 that discusses at length and in some > detail multiple “corner cases†resulting, presumably, from > misconfiguration, before it explains the basic (and relatively > simple) “normal†behavior, looks problematic to me. > > The WG Last Call has been extended by one week. Nevertheless, > I am sending out my comments > > *Major Issues*: None found > > #Ahmed: thanks a lot > > > > *Minor Issues*: Quite a few but, hopefully, easy to resolve. > > 1.*Encapsulation of SR-MPLS packets*: > > a.RFC 3032 (referenced by the draft) and RFC 5332 (*/not > mentioned in the draft/*) depend two encapsulations of labeled > packets - one for Downstream-allocated labels and another for > Upstream-allocated ones. > > #Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of > draft-ietf-spring-segment-routing-15, multicast is outside the > scope of SR. Hence the RFC was not referred to in the SR-MPLS draft > > */[[Sasha]] I would be satisfied with this response, would it not > be for the following text I see in Section 2.2 of the/**/SR Policy > Architecture > > /**/draft:/* > >    A variation of SR Policy can be used for packet replication.  A > >    candidate path could comprise multiple SID-Lists; one for each > >    replication path.  In such a scenario, packets are actually > >    replicated through each SID List of the SR Policy to realize a > point- > >    to-multipoint service delivery. > > */This looks to me as being very much multicast in SR, and, unless > you want to say that it is limited to SRv6, makes my question > relevant IMHO./* > > ##Ahmed: The main reference for this draft is the sr-architecture, > which clearly states that multicast is out of SR scope. SR-MPLS, being > an MPLS instantiation of the SR-architecture, follows the > SR-architecture as close as possible. If another draft proposes > something related to SR, then it is the responsibility of the other > draft to mention any extensions/restrictions in relation to the basic > draft-ietf-spring-segment-routing and/or SR-MPLS, or to specifically > say that it does not apply to SR-MPLS. > > > b.From my POV the ST-MPLS only uses Downstream-allocated labels – > but I expect the draft to state that explicitly, one way or > another. (If Upstream-allocated labels are relevant for SR-MPLS, I > would see it as a major gap, so I hope that this is not the case). > > #Ahmed: I will add a statement in section 2.2 to mention that it is > down-stream allocated as you mentioned > > */[[Sasha]] This is quite unambiguous and, once added, would resolve > my comment in full – the previous comment notwithstanding. In > particular, it would imply that even labels representing BSIDs of a SR > Replication policies will be downstream-allocated. /* > > */#Ahmed: Binding SID is just a special case of a SID. So what applies > to a SID applies to a binding SID/* > > > 2.*Label spaces in SR-MPLS*: > > a.RFC 3031 (referenced by the draft) defines per-platform and > per-interface label spaces, and RFC 5331 (*/not mentioned in the > draft/*) adds context-specific label spaces and context labels. > > b.The draft does not say which of these are or are not relevant > for SR-MPLS > > c.From my POV: > > i.Labels representing all kinds of SIDs mentioned in the draft > MUST be allocated from the per-platform label space only > > ii.At the same time, instantiation of Mirror Segment IDs defined > in Section 5.1 of the Segment Routing Architecture draft using > MPLS data plane clearly calls for context labels and > context-specific label spaces > > d.I expect the draft to provide a clear-cut position on these > aspects of SR-MPLS. > > #Ahmed: I will add a statement to section 2.2 to say that the it is > per-platform. Regarding the function "mirroring", SR attaches a > *function* to each SID. The "mirroring" function is already described > in Section 5.1 of draft-ietf-spring-segment-routing and is not > specific to the MPLS forwarding plane. Hence there is no need to > re-mention it here because this document is trying to be as specific > as possible to the MPLS forwarding plane. General functions attached > to SID are described in the segment routing architecture document or > future documents. Furture documents proposing new SR function must be > as specific and clear as possible > > */[[Sasha]] Looks OK to me./* > > > > > > 3.*SR-MPLS and hierarchical LSPs*: > > a.SR LSPs that include more than one segment are hierarchical LSPs > from the POV of the MPLS data plane. Therefore some (possibly, > all) of the models for handling TTL and TC bits that have been > defined in RFC 3443 (*/not mentioned in the draft/*) should apply > to SR-MPLS > > b.RFC 8287 (*/not referenced in the draft/*) specifically > discussed operation of the LSP Traceroute function for SR LSPs in > the case when Pipe/Short Pipe model for TTL handling is used > > c.I expect the draft to provide at least some guidelines regarding > applicability of each specific model defined in RFC 3443 > (separately for TTL and TC bits) to SR-MPLS. > > #Ahmed: BY design, the instantiation of SR over the MPLS forwarding > plane (and hence this draft) does not modify the MPLS forwarding plan > behavior as it is mentioned in the first sentence in Section 1. So the > TTL behavior specified in rfc3443 is already implied and there is no > need to re-mention it here just like all aspects of MPLS forwarding. > RFC8287 is OAM-specific.  SR-OAM is handled in a separate document so > is outside the scope of this draft > > */[[Sasha]] Unfortunately I do not think this is good enough. Let me > ask a specific question reflecting my concerns:/* > > */The head-end node sends SR-MPLS packets across a path defined by an > ordered set of SIDs with more than one SID in the list. Each SID is > represented by a label stack entry (LSE) in the MPLS label stack, and > the label field in each LSE is the label that matches the > corresponding SID. However, each LSE also includes the TTL and TC > fields. How does the head-end node set these fields in each of the > LSEs following the top one? This clearly depends on the model (Uniform > vs. Pipe/Short Pipe) implemented in each node that that performs Next > operation on the packet along the path – but the head-end node usually > is not aware of that. /* > > */RFC 8287 is relevant as an example here IMHO because it recommends > the following setting of TTL in Traceroute packets:/* > > -*/Set the TTL of all the labels above one that represents the segment > you are currently tracing to maximum/* > > -*/Set the TTL of the label one that represents the segment you are > currently tracing to the desired value (to be incremented until end of > segment is reached/* > > -*/Set the TTL of all the labels below one that represents the segment > you are currently tracing to 0./* > > */I expect the draft to provide some recommendations for traffic > (non-OAM) packets as well./* > > */##Ahmed: The setting of the TTL for non-OAM packets are subject to > the policy that constructed the label stack. SR-policy is handled in a > separate draft /* > > > > > > > 4.*Inferring network layer protocol in SR-MPLS*: > > a.I wonder if the draft could provide any details on the situation > when a label that represents some kind of SID is the > bottom-of-stack label to be popped by the egress LER > > #ahmed: This is part of the "Next" function. It is described in detail > in this document. > > */[[Sasha]] NEXT function is mentioned in several places in the > document. Can you please point to the specific text that is relevant > for my question?/* > > */##Ahmed: Part (a) here is a statement not a question. What is the > question?/* > > > > > > > b.For the reference, RFC 3032 says that “the identity of the > network layer protocol  must be inferable from the value of the > label which is popped from  the bottom of the stack, possibly > along with the contents  of the network layer header itself†> > c.From my POV the following scenario indicates relevance of this > expectation for SR-MPLS: > > i.IS-IS is used for distributing both IPv4 and IPv6 reachability > in a given domain > > ii.An IS-IS adjacency over some dual-stack link is established, > and a single Adj-SID for this adjacency is advertised > > iii.The node that has assigned and advertised this Adj-SID > receives a labeled packet with the label representing this Adj-SID > being both the top and bottom-of-stack label > > iv.The implementers must be given unambiguous instructions for > forwarding the unlabeled packet via the dual-stack link as an Ipv4 > or an IPv6 packet. > > #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 > drafts, you will see all 3 protocol advertise different adj-SIDS for > IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" > (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to > specify whether the adj-SID is for IPv4 and IPv6. Similarly, the > SR-ISIS draft attaches a prefix-SID to the prefix advertisement and > hence implies the identity of the protocol underneath the bottom most > label. For any other "function" attached to a SID, it is part of the > specification of this function to describe what happens when the SID > is represented by a label in the MPLS forwarding plane and this label > is the bottom most label > > */[[Sasha]] OK, got it. This issue is resolved./* > > > > > > 5.*Resolution**of Conflicts*: Are the > > a.Are the conflict resolution procedures listed in section 2.5 > mandatory to implement? > > b.If they are mandatory to implement, are they also mandatory to > deploy, or can the operators simply treat any detected conflict as > requiring human intervention and preventing normal operation of > SR-MPLS? > > #Ahmed: They are recommended. I will modify the paragraph after the > first 3 bullets in Section 2.5 to say that it is recommeded. > > > > */[[Sasha]] OK. However, it would be nice if you could refer > separately for “RECOMMENDED to implement†and “RECOMMENDED to deployâ€. >  The latter probably requires a configuration knob for enabling > conflict resolution rules (if they are implemented). /* > > c.For the reference, the IETF capitalized MUST appears just in a > few places in Section 2.5, and each appearance has very narrow > context: > > i.For MCCs where the "Topology" and/or "Algorithm" fields are not > defined, the numerical value of zero MUST be used for these two fields > > ii.If the same set of FECs are attached to the same label "L1", > then the tie-breaking rules MUST always select the same FEC > irrespective of the order in which the FECs and the label "L1" are > received. In other words, the tie-breaking rule MUST be > deterministic. > > iii.An implementation of explicit SID assignment MUST guarantee > collision freeness on the same router > > From my POV, it is not possible to infer the answer to my question > from these statements. Some explicit statement is required. > > #Ahmed: I agree with you POV and as mentioned in my reply to items (a) > and (b), I will modify the paragraph to say that it is RECOMMENDED to > answer you questions in items (a) and (b) > > > > d.The tie-breaking rules in section 2.5.1 include some specific > values for encoding FEC types and address families – but these > values are not supposed to appear in any IANA registries (because > the draft does not request any IANA actions). Can you please > clarify what is so special about these values? > > #Ahmed: There is no significance to the values but there is a > significance to the order among them. I will modify the text to > clarify that > > */[[Sasha]] OK. /* > > > > > > e.I also doubt that comparison of FECs that represent IPv4 and > IPv6 prefix SIDs makes much sense (for conflict resolution or > else), because, among other things, there are valid scenarios when > an IPv4 /32 prefix is embedded in an IPv6 /128 one. > > #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that > embeds an IPv4 prefix is different from the IPv4 prefix. The > specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat > IPv4 and IPv6 prefixes separately, including the IPV6 prefixes with > embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix in > them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear > > */[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. > Quoting from RFC 4291:/* > > > *2.5.5.2* > *.  > IPv4-Mapped IPv6 Address* > >    A second type of IPv6 address that holds an embedded IPv4 address is > >    defined. This address type is used to represent the addresses of > > IPv4 nodes as IPv6 addresses. > > *//* > > */From my POV this means that a /128 prefix associated with an > IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 > address that was mapped to this IPv6 address represent the same > entity. This understanding fully matches usage of IPv4-mapped IPv6 > addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. > However, the comparison rules you have defined will treat them as two > different prefixes.  I wonder if these rules, in the case of a > conflict, could result in preferring the IPv6 prefix to an IPv4 one > and therefore loosing MPLS connectivity for the ingress PE of a 6VPE > service to its egress PE?/* > > */##Ahmed: The basic MPLS architecture does not forbid assigning > different labels to the same prefix, nonetheless to different prefixes > belonging to the same node or the same interface on the same node. One > of the fundamental concepts of SR-MPLS is that the same prefix-SID > must not be assigned to two different prefixes. So for the particular > scenario of embedding IPv4 in IPv6, the operator must assign different > SIDs to the IPv4 address and the IPv4-mapped IPv6 address that embeds > it, otherwise the label will be subject to the incoming label > collision resolution > > > > /* > > > > > > f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure > all SID types defined in the Segment Routing Architecture draft > can be unambiguously mapped to one of these types. Problematic > examples include at least the following: > > i.Parallel Adjacency SID > > ii.Mirror SID > > Explicit mapping of SID types to SR-MPLS FEC types would be most > useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, > this must be explicitly stated in the draft. > > #Ahmed: > Parallel adjacency SID are handled in the type "(next-hop, outgoing > interface)" > > */[[Sasha]] OK/* > > > Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the > SR architecture draft (draft-ietf-spring-segment-routing-15). Also as > described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18 > (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding > SID is identified by a prefix. Hence it is covered by the type > "(Prefix, Routing Instance, Topology, Algorithm)" > > */[[Sasha]] I respectfully disagree. There is definitely no mention of > Algorithm in the definition of the Mirror SID. /* > > */##Ahmed: > The last paragraph in Section 2 of > draft-ietf-spring-segment-routing-14 says/* > >    We call "MPLS Control Plane Client (MCC)" any control plane entity >    installing forwarding entries in the MPLS data plane. > > */The sentence starting at the 5th line of the first bullet of Section > 2.5 of draft-ietf-spring-segment-routing-14 says/* > > For MCCs where the "Topology" and/or "Algorithm" >       fields are not defined, the numerical value of zero MUST be used >       for these two fields. > > */If a binding-SID is downloaded to the forwarding plane, then it must > be associated with an MCC and hence it either has an "algorithm" or > the value zero is assumed for the "algorithm" field. If the > binding-SID is not downloaded to the forwarding plane, then it is > irrelevant to the entire draft not only to incoming label collision/* > > > > > > 6.*Node SIDs in SR-MPLS*: > > a.Node SIDs are explicitly defined and discussed in the Segment > Routing Architecture draft but are not mentioned even once in this > draft > > b.AFAIK, the common implementation practice today includes > assignment of at least one Node SID to every node in the SR-MPLS > domain > > c.Is there a requirement to assign at least one Node SID per > {routing instance, topology, algorithm} in SR-MPLS? If not, can > the authors explain expected behavior of such a node? (See also my > comment about routing instances below). > > #Ahmed: A Node-SID is a special case of prefix-SID. So there nothing > specific about it from the MPLS forwarding plane point of view. > Similarly from a standard tracks draft point of view, there is no > requirement to assign a SID to every prefix just like there is no > requirement to bind every prefix to an LDP label. Common and/or > recommended practices or description of deployment scenarios are more > befitting to BCP or informational drafts. This draft is a standards > track draft > > */[[Sasha]] Well, you’ve just said that conflict resolution rules are > RECOMMENDED, and this is quite common in the Standards Track RFCs. /* > > */##Ahmed: OK., I think we are in agreement here:)/* > > > > If a {routing instance, topology, algorithm} is not assigned a SID, > then this FEC is totally irrelavant to this draft and hence describing > how a node treats it is totally outside the scope of this draft > > */[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention > routing instances that can be associated with the prefix, so I think > that your reference to it is incorrect./* > > */What’s more I suspect that Node SIDs represent the most used special > case of Prefix SIDs with Anycast SIDs being quite behind.  Therefore > some recommendation pertaining to the usage of Node SIDs would be very > much in place IMHO. /* > > */##Ahmed: The  term "routing instance" within the context of incoming > label collision is defined in the first bullet in Section 2.5. > As for any recommendation for useage of node-SID, anycast-SID,...,etc > , it is out of the scope of this draft because it is a matter of of > deployment/informational/BCP draft > > > /* > > > > > > 7.*SRGB Size in SR-MPLS*: > > a.The draft correctly treats the situation when an index assigned > to some global SID cannot be mapped to a label using the procedure > in Section 2.4 as a conflict. > > b.At the same time the draft does not define any minimum size of > SRGB (be it defined as a single contiguous block or as a sequence > of such blocks) that MUST be implemented by all SR-capable nodes > > c.I suspect that lack of such a definition could be detrimental to > interoperability of SR-MPLS solutions. AFAIK, the IETF has been > following, for quite some time, a policy that some reasonable > MUST-to-implement defaults should be assigned for all configurable > parameters exactly in order to prevent this. > > #Ahmed: This document specifies how the SRGB is used and the behavior > of routers when a prefix-SID index maps to a label inside and/or > outside the SRGB. The actual size of the SRGB is a task in > partitioning the label space, which is very specific to a particular > deployment scenario. So IMO it is outside the scope of a standards > track document. Now that SR-MPLS is deployed in many places, I expect > the community to gain sufficient experience to recommend (or not > recommend) a particular minimum/maximum size for the SRGB is some > future informational or BCP draft/RFC > > */[[Sasha]] My reading of your response is that minimum size of SRGB > is an issue for future study. Can you please just add this to the draft?/* > > */##Ahmed: OK. Added a sentence to the last paragraph of section 2.3/* > > > > > > > 8.*Algorithms and Prefix SIDs*: > > a.The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) > in, but it does not explicitly link them with the Prefix-SID > algorithms defined in section 3.1.1 of the Segment Routing > Architecture draft > > #Ahmed: I will just add the reference > [I-D.ietf-spring-segment-routing]right beside the first time > "Algorithm" is mentioned > > */[[Sasha]] OK/* > > > > > > b.From my POV, the draft should explicitly state that the default > Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant > routers. > > #Ahmed: The specification of what path calculation method should or > must be supported is a routing protocol property not a forwarding > plane property. In fact, the choice of a path calculation method or > algorithm is completely orthogonal to the routed protocol. Hence > mandating the support of a particular routing algorithm is beyond the > scope of this document. > > */[[Sasha]] OK/* > > > > > > c.The Segment Routing Architecture draft states (in section 3.1.3) > that “Support of multiple algorithms applies to SRv6â€. But neither > draft states whether multiple algorithms apply to SR-MPLS. Can you > please clarify this point? > > #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in > draft-ietf-spring-segment-routing-15 discusses the support of multiple > algorithms. So it is implied that the concept of algorithm applies to > SR-MPLS. Hence there is no need to re-mention it here > > */[[Sasha]] The paragraph to which you refer only says that if a > packet with the active Prefix-SID that is associated with a specific > algorithm is received by a node that does not support this algorithm, > this packet will be discarded. If this is the only type of support for > multiple algorithms SR provides, it is not very useful IMHO/**/. /* > > */##Ahmed: The SR-MPLS draft that we are discussing here does not > attempt to modify the SR-architecture draft. Any concerns related to > the SR-architecture should be addressed to the SR-architecture draft > not to this draft. /* > > > > > > 9.*Routing instances and the context for Prefix-SIDs*: > > a.The Segment Routing Architecture draft states in Section 3.1 > that the “context for an IGP-Prefix segment includes the prefix, > topology, and algorithm†> > b.This draft seems to define (in section 2.5) the context for the > Prefix SID as “Prefix, Routing Instance, Topology, Algorithm†> where â€a routing instance is identified by a single incoming label > downloader to FIB†(but the notion of the label downloader to FIB > is not defined). > > c.These two definitions look different to me. > > d.At the very least I would expect alignment between the > definitions of context for the Prefix-SID between the two drafts. > Preferably, the definition given in the Segment Routing > Architecture draft should be used in both drafts. > > #Ahmed: The context of the section 2.5 is limited to the resolution of > local label collision. The use of "routing instance" in section 2.5 is > just there for tie-breaking if there is local label collision. > > */[[Sasha]] I have already mentioned that “routing instances†are not > defined in any the drafts dealing with SR Extensions for IGPs. So I do > not understand how the conflict resolution procedure is supposed to > use this. And in any case the difference between two definitions of > the context of Prefix-SID requires some explanation./* > > */##Ahmed: incoming label collision defines what is a routing instance > within its context. I do not understand what explanation you are > looking for/* > > > > > > > > 10.*Example of PUSH operation in Section 2.10.1*: > > a.The first para of this section begins with the sentence “Suppose > an MCC on a router "R0" determines that PUSH or CONTINUE   > operation is to be applied to an incoming packet whose active SID > is the global SID "Si"â€. In the context of SR-MPLS this means (to > me) that the incoming packet is a labeled packet and its top label > matches the global SID “Siâ€. > > b.However, the example for PUSH operation in the next para of this > section is the case of an (unlabeled) IP packet with the > destination address covered by the IP prefix for which “Si†has > been assigned. > > c.From my POV: > > i.Mapping unlabeled packets to SIDs is indeed out of scope of the > draft. Therefore an example of a PUSH operation that is applied to > a labeled packet (with the active SID inferred from the top label > in the stack) is preferable. > > ii.Valid examples of  PUSH operation applied to a labeled incoming > packet can be found in Sections 4.2 or 4.3 of the TI-LFA > > draft > > #Ahmed: I do not understand your concern here:) > > > > */[[Sasha]] I think it is pretty clear: can you provide an example of > a PUSH operation applied to a labeled packet instead of your current > example?/* > > */##Ahmed: The example in the draft is included to clarify the concept > of a prefix SID attached to a prefix. As mentioned more than once, > SR-MPLS does not modify MPLS forwarding including pushing a label on a > labeled packet. It is something that has been done by routers and > switches for 20+ years. So including it here is redundant/* > > > *Nits*: > > 1.I concur with Adrian regarding numerous nits he has reported in > his WG LC Comment > . > I would like to thank Adrian for an excellent review that have > saved me lots of hard work. > > #Ahmed: I also agree that Adrian's review is exceptional. I believe I > addressed all his comments in the latest version. > > > > 2.In addition, I’d like to report the following nits: > > a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA > > draft) > > #Ahmed: Already done in the latest version*/[[Sasha]] OK/* > > > > b.TI-LFA draft is referenced in the text of Section 2.11.1, but > there is no matching reference in the “References†section > (probably, Informational) > > #Ahmed: Already done in the latest version*/[[Sasha]] OK/* > > > > c.“zero Algorithm†in Section 2.5 (immediately above Section > 2.5.1) must be replaced with “default algorithmâ€. Similarly, > “non-zero Algorithm†should be replaced with “non-default algorithm†> > #Ahmed: Will be done in the next version*/[[Sasha]] /* OK > > > > 3.I think that RFC 3443 and RFC 5332 should be listed as Normative > references in this draft while RFC 5331 and RFC 8277 should be > listed as Informative references. This would improve the > readability of the draft without any impact on its advancement. > > #Ahmed RFC5331 describes upstream label assignment. As you mentioned > above (and I will modify the draft to indicate that) SR-MPLS behavior > is similar to downstream label assignment. RFC 3443 describes TTL > behavior. This is an MPLS forwarding behavior. As mentioned in the > draft, SR-MPLS does not modify at the MPLS forwarding behavior > > */[[Sasha]] Regarding RFC 5331 – you may skip this reference if you > state (as discussed below) that SR-MPLS only allocates labels from the > per-platform label space. Regarding RFC 3443 – I do not think that you > can fully avoid discussion of Uniform and Pipe/Short Pipe models, and > therefore you will need this reference./* > > */##Ahmed: I did not add rfc5331 as a reference . Again pushing > multiple labels on top of a packet is a matter of SR-policy, which is > handled in a separate draft. /* > > > > > > > > Hopefully, these comments will be useful. > > #Ahmed: They are certainly quite useful. Thanks a lot > > > > Regards, > > Sasha > > Office: +972-39266302 > > Cell:      +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this > transmission in error, please inform us by e-mail, phone or fax, > and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ > > _________________________________________________________________________________________________________________________ > 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. > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ --------------83F8216D09A2658E8EA73302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sasha

I uploaded version 15. But I was not sure how to best address your concern

So Please propose the wording/modifications that looks reasonable to you and I will be more than happy to incorporate them

Ahmed


On 7/25/18 12:20 AM, Alexander Vainshtein wrote:

Stephane,

Lots of thanks for your email, and apologies for a long delayed response.

Regarding you reference to “BGP 3107 label over an LDP label over an RSVP label to build an end-to-end transportâ€, I have looked up RFC 8277  that has replaced RFC 3107, and found there the following explicit statement:

   When pushing labels onto a packet's label stack, the Time-to-Live
   (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field
   ([RFC3032], [RFC5462]) of each label stack entry must, of course, be
   set.  This document does not specify any set of rules for setting
   these fields; that is a matter of local policy.

 

No equivalent of this statement could be found in RFC 3107 – probably because RFC 3443 has not yet been published then.

From my POV including the same (or equivalent) explicit statement in the draft would be sufficient to resolve the issue.

Hope this helps.

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

Hi Sasha,

> The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.

Why do you think this is different from a nested MPLS tunnel that exists today ? I completely agree with you that the head end does not know the behavior of the tail-end in term of TTL/TC processing. But that’s already the case today, and it’s the job of engineers to ensure that all nodes in the network are operating in the same mode (uniform vs pipe/short pipe).

We can already stack today a BGP 3107 label over an LDP label over an RSVP label to build an end-to-end transport, the TTL processing should not be essentially different.

Could you pin point the difference that you see ?

 

Brgds,

 

Stephane

 

 

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Monday, July 16, 2018 22:03
To: Alexander Vainshtein
Cc: rtg-dir@ietf.org; 'mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Thanks a lot for the reply

See inline "##Ahmed"

 

On 7/11/18 2:02 AM, Alexander Vainshtein wrote:

Ahmed, and all,

Lots of thanks for a detailed response to my comments.

Please see inline below my position on each of them.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

Thanks for thorough (and VERY clear) the review

See inline #Ahmed

 

Ahmed

 

 

On 6/15/18 11:08 PM, Alexander Vainshtein wrote:

Re-sending to  correct SPRING WG list.

Sincere apologies for the delay caused by a typo.

Thumb typed by Sasha Vainshtein

 

From: Alexander Vainshtein
Sent: Sunday, June 10, 2018 10:43:52 AM
To: spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Cc: spring@ietf.com; rtg-dir@ietf.org; 'mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

 

Explicitly adding Shraddha  who is the shepherd of this draft.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

 

Hello,

I have been selected to do a routing directorate “early†review of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

 

The routing directorate will, on request from the working group chair, perform an “early†review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is currently in the WG Last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

 

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

 

Document: draft-ietf-spring-segment-routing-mpls-13

Reviewer: Alexander (“Sashaâ€) Vainshtein (alexander.vainshtein@ecitele.com)

Review Date: 08-Jun-18

Intended Status: Proposed Standard.

 

Summary:

 

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

 

Comments:

 

I consider this draft as an important  companion document to the Segment Routing Architecture draft that, ideally, should augment definitions of the Segment Routing (SR) notions and constructs given there with details specific for the SR instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised in my review reflect either gaps that should be, but have not been, closed, or inconsistencies between the two drafts.

 

 

Since RFC 8287 is already published as a Standards Track RFC, I expect such augmentation to be backward compatible with this document (or to provide clear indications of required updates to this document). And I include the MPLS WG into distribution list.

 

This draft was not easy reading for me. In particular, the style of Section 2.5 that discusses at length and in some detail multiple “corner cases†resulting, presumably, from misconfiguration, before it explains the basic (and relatively simple) “normal†behavior, looks problematic to me.

 

The WG Last Call has been extended by one week. Nevertheless, I am sending out my comments

 

Major Issues: None found

#Ahmed: thanks a lot



 

Minor Issues: Quite a few but, hopefully, easy to resolve.

 

1.    Encapsulation of SR-MPLS packets:

a.    RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned in the draft) depend two encapsulations of labeled packets - one for Downstream-allocated labels and another for Upstream-allocated ones.

#Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of draft-ietf-spring-segment-routing-15, multicast is outside the scope of SR. Hence the RFC was not referred to in the SR-MPLS draft

[[Sasha]] I would be satisfied with this response, would it not be for the following text I see in Section 2.2 of the SR Policy Architecture draft:

   A variation of SR Policy can be used for packet replication.  A

   candidate path could comprise multiple SID-Lists; one for each

   replication path.  In such a scenario, packets are actually

   replicated through each SID List of the SR Policy to realize a point-

   to-multipoint service delivery.

 

This looks to me as being very much multicast in SR, and, unless you want to say that it is limited to SRv6, makes my question relevant IMHO.

##Ahmed: The main reference for this draft is the sr-architecture, which clearly states that multicast is out of SR scope. SR-MPLS, being an MPLS instantiation of the SR-architecture, follows the SR-architecture as close as possible. If another draft proposes something related to SR, then it is the responsibility of the other draft to mention any extensions/restrictions in relation to the basic draft-ietf-spring-segment-routing and/or SR-MPLS, or to specifically say that it does not apply to SR-MPLS.


b.    From my POV the ST-MPLS only uses Downstream-allocated labels – but I expect the draft to state that explicitly, one way or another. (If Upstream-allocated labels are relevant for SR-MPLS, I would see it as a major gap, so I hope that this is not the case).

#Ahmed: I will add a statement in section 2.2 to mention that it is down-stream allocated as you mentioned

[[Sasha]] This is quite unambiguous and, once added, would resolve my comment in full – the previous comment notwithstanding. In particular, it would imply that even labels representing BSIDs of a SR Replication policies will be downstream-allocated.

#Ahmed: Binding SID is just a special case of a SID. So what applies to a SID applies to a binding SID


 

2.    Label spaces in SR-MPLS:

a.    RFC 3031 (referenced by the draft) defines per-platform and per-interface label spaces, and RFC 5331 (not mentioned in the draft) adds context-specific label spaces and context labels.

b.    The draft does not say which of these are or are not relevant for SR-MPLS

c.    From my POV:

                                         i.    Labels representing all kinds of SIDs mentioned in the draft MUST be allocated from the per-platform label space only

                                        ii.    At the same time, instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment Routing Architecture draft using MPLS data plane clearly calls for context labels and context-specific label spaces

d.    I expect the draft to provide a clear-cut position on these aspects of SR-MPLS.

#Ahmed: I will add a statement to section 2.2 to say that the it is per-platform. Regarding the function "mirroring", SR attaches a *function* to each SID. The "mirroring" function is already described in Section 5.1 of draft-ietf-spring-segment-routing and is not specific to the MPLS forwarding plane. Hence there is no need to re-mention it here because this document is trying to be as specific as possible to the MPLS forwarding plane. General functions attached to SID are described in the segment routing architecture document or future documents. Furture documents proposing new SR function must be as specific and clear as possible

[[Sasha]] Looks OK to me.





3.    SR-MPLS and hierarchical LSPs:

a.    SR LSPs that include more than one segment are hierarchical LSPs from the POV of the MPLS data plane. Therefore some (possibly, all) of the models for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned in the draft) should apply to SR-MPLS

b.    RFC 8287 (not referenced in the draft) specifically discussed operation of the LSP Traceroute function for SR LSPs in the case when Pipe/Short Pipe model for TTL handling is used

c.    I expect the draft to provide at least some guidelines regarding applicability of each specific model defined in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.

#Ahmed: BY design, the instantiation of SR over the MPLS forwarding plane (and hence this draft) does not modify the MPLS forwarding plan behavior as it is mentioned in the first sentence in Section 1. So the TTL behavior specified in rfc3443 is already implied and there is no need to re-mention it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specific.  SR-OAM is handled in a separate document so is outside the scope of this draft

[[Sasha]] Unfortunately I do not think this is good enough. Let me ask a specific question reflecting my concerns:

The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.

RFC 8287 is relevant as an example here IMHO because it recommends the following setting of TTL in Traceroute packets:

-          Set the TTL of all the labels above one that represents the segment you are currently tracing to maximum

-          Set the TTL of the label one that represents the segment you are currently tracing to the desired value (to be incremented until end of segment is reached

-          Set the TTL of all the labels below one that represents the segment you are currently tracing to 0.

I expect the draft to provide some recommendations for traffic (non-OAM) packets as well.

##Ahmed: The setting of the TTL for non-OAM packets are subject to the policy that constructed the label stack. SR-policy is handled in a separate draft 






4.    Inferring network layer protocol in SR-MPLS:

a.    I wonder if the draft could provide any details on the situation when a label that represents some kind of SID is the bottom-of-stack label to be popped by the egress LER

#ahmed: This is part of the "Next" function. It is described in detail in this document.

[[Sasha]] NEXT function is mentioned in several places in the document. Can you please point to the specific text that is relevant for my question?

##Ahmed: Part (a) here is a statement not a question. What is the question?






b.    For the reference, RFC 3032 says that “the identity of the network layer protocol  must be inferable from the value of the label which is popped from  the bottom of the stack, possibly along with the contents  of the network layer header itselfâ€

c.    From my POV the following scenario indicates relevance of this expectation for SR-MPLS:

                                         i.    IS-IS is used for distributing both IPv4 and IPv6 reachability in a given domain

                                        ii.    An IS-IS adjacency over some dual-stack link is established, and a single Adj-SID for this adjacency is advertised

                                       iii.    The node that has assigned and advertised this Adj-SID receives a labeled packet with the label representing this Adj-SID being both the top and bottom-of-stack label

                                       iv.    The implementers must be given unambiguous instructions for forwarding the unlabeled packet via the dual-stack link as an Ipv4 or an IPv6 packet.

#Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to specify whether the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a prefix-SID to the prefix advertisement and hence implies the identity of the protocol underneath the bottom most label. For any other "function" attached to a SID, it is part of the specification of this function to describe what happens when the SID is represented by a label in the MPLS forwarding plane and this label is the bottom most label

[[Sasha]] OK, got it. This issue is resolved.





5.    Resolution of Conflicts: Are the

a.    Are the conflict resolution procedures listed in section 2.5 mandatory to implement?

b.    If they are mandatory to implement, are they also mandatory to deploy, or can the operators simply treat any detected conflict as requiring human intervention and preventing normal operation of SR-MPLS?

#Ahmed: They are recommended. I will modify the paragraph after the first 3 bullets in Section 2.5 to say that it is recommeded.  



[[Sasha]] OK. However, it would be nice if you could refer separately for “RECOMMENDED to implement†and “RECOMMENDED to deployâ€.  The latter probably requires a configuration knob for enabling conflict resolution rules (if they are implemented).

c.    For the reference, the IETF capitalized MUST appears just in a few places in Section 2.5, and each appearance has very narrow context:

                                         i.    For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zero MUST be used for these two fields

                                        ii.    If the same set of FECs are attached to the same label "L1", then the tie-breaking rules MUST always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic.

                                       iii.    An implementation of explicit SID assignment MUST guarantee collision freeness on the same router

From my POV, it is not possible to infer the answer to my question from these statements. Some explicit statement is required.

#Ahmed: I agree with you POV and as mentioned in my reply to items (a) and (b), I will modify the paragraph to say that it is RECOMMENDED to answer you questions in items (a) and (b)



d.    The tie-breaking rules in section 2.5.1 include some specific values for encoding FEC types and address families – but these values are not supposed to appear in any IANA registries (because the draft does not request any IANA actions). Can you please clarify what is so special about these values?

#Ahmed: There is no significance to the values but there is a significance to the order among them. I will modify the text to clarify that

[[Sasha]] OK.





e.    I also doubt that comparison of FECs that represent IPv4 and IPv6 prefix SIDs makes much sense (for conflict resolution or else), because, among other things, there are valid scenarios when an IPv4 /32 prefix is embedded in an IPv6 /128 one.

#Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that embeds an IPv4 prefix is different from the IPv4 prefix. The specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately, including the IPV6 prefixes with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix in them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear

[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. Quoting from RFC 4291:

2.5.5.2.  IPv4-Mapped IPv6 Address

 

 

   A second type of IPv6 address that holds an embedded IPv4 address is

   defined.  This address type is used to represent the addresses of

   IPv4 nodes as IPv6 addresses.

 

From my POV this means that a /128 prefix associated with an IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 address that was mapped to this IPv6 address represent the same entity. This understanding fully matches usage of IPv4-mapped IPv6 addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. However, the comparison rules you have defined will treat them as two different prefixes.  I wonder if these rules, in the case of a conflict, could result in preferring the IPv6 prefix to an IPv4 one and therefore loosing MPLS connectivity for the ingress PE of a 6VPE service to its egress PE?

##Ahmed: The basic MPLS architecture does not forbid assigning different labels to the same prefix, nonetheless to different prefixes belonging to the same node or the same interface on the same node. One of the fundamental concepts of SR-MPLS is that the same prefix-SID must not be assigned to two different prefixes. So for the particular scenario of embedding IPv4 in IPv6, the operator must assign different SIDs to the IPv4 address and the IPv4-mapped IPv6 address that embeds it, otherwise the label will be subject to the incoming label collision resolution







f.     Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure all SID types defined in the Segment Routing Architecture draft can be unambiguously mapped to one of these types. Problematic examples include at least the following:

                                         i.    Parallel Adjacency SID

                                        ii.    Mirror SID

Explicit mapping of SID types to SR-MPLS FEC types would be most useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, this must be explicitly stated in the draft.

#Ahmed:
Parallel adjacency SID are handled in the type "(next-hop, outgoing interface)"

[[Sasha]] OK


Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR architecture draft (draft-ietf-spring-segment-routing-15). Also as described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18 (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is identified by a prefix. Hence it is covered by the type "(Prefix, Routing Instance, Topology, Algorithm)"

[[Sasha]] I respectfully disagree. There is definitely no mention of Algorithm in the definition of the Mirror SID.

##Ahmed:
The last paragraph in Section 2 of draft-ietf-spring-segment-routing-14 says

   We call "MPLS Control Plane Client (MCC)" any control plane entity
   installing forwarding entries in the MPLS data plane.

The sentence starting at the 5th line of the first bullet of Section 2.5 of draft-ietf-spring-segment-routing-14 says

For MCCs where the "Topology" and/or "Algorithm"
      fields are not defined, the numerical value of zero MUST be used
      for these two fields.

If a binding-SID is downloaded to the forwarding plane, then it must be associated with an MCC and hence it either has an "algorithm" or the value zero is assumed for the "algorithm" field. If the binding-SID is not downloaded to the forwarding plane, then it is irrelevant to the entire draft not only to incoming label collision





6.    Node SIDs in SR-MPLS:

a.    Node SIDs are explicitly defined and discussed in the Segment Routing Architecture draft but are not mentioned even once in this draft

b.    AFAIK, the common implementation practice today includes assignment of at least one Node SID to every node in the SR-MPLS domain

c.    Is there a requirement to assign at least one Node SID per {routing instance, topology, algorithm} in SR-MPLS? If not, can the authors explain expected behavior of such a node? (See also my comment about routing instances below).

#Ahmed: A Node-SID is a special case of prefix-SID. So there nothing specific about it from the MPLS forwarding plane point of view. Similarly from a standard tracks draft point of view, there is no requirement to assign a SID to every prefix just like there is no requirement to bind every prefix to an LDP label. Common and/or recommended practices or description of deployment scenarios are more befitting to BCP or informational drafts. This draft is a standards track draft

[[Sasha]] Well, you’ve just said that conflict resolution rules are RECOMMENDED, and this is quite common in the Standards Track RFCs.

##Ahmed: OK., I think we are in agreement here:)



If a {routing instance, topology, algorithm} is not assigned a SID, then this FEC is totally irrelavant to this draft and hence describing how a node treats it is totally outside the scope of this draft

[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention routing instances that can be associated with the prefix, so I think that your reference to it is incorrect.

What’s more I suspect that Node SIDs represent the most used special case of Prefix SIDs with Anycast SIDs being quite behind.  Therefore some recommendation pertaining to the usage of Node SIDs would be very much in place IMHO.

##Ahmed: The  term "routing instance" within the context of incoming label collision is defined in the first bullet in Section 2.5.
As for any recommendation for useage of node-SID, anycast-SID,...,etc , it is out of the scope of this draft because it is a matter of of deployment/informational/BCP draft






7.    SRGB Size in SR-MPLS:

a.    The draft correctly treats the situation when an index assigned to some global SID cannot be mapped to a label using the procedure in Section 2.4 as a conflict.

b.    At the same time the draft does not define any minimum size of SRGB (be it defined as a single contiguous block or as a sequence of such blocks) that MUST be implemented by all SR-capable nodes

c.    I suspect that lack of such a definition could be detrimental to interoperability of SR-MPLS solutions. AFAIK, the IETF has been following, for quite some time, a policy that some reasonable MUST-to-implement defaults should be assigned for all configurable parameters exactly in order to prevent this.

#Ahmed: This document specifies how the SRGB is used and the behavior of routers when a prefix-SID index maps to a label inside and/or outside the SRGB. The actual size of the SRGB is a task in partitioning the label space, which is very specific to a particular deployment scenario. So IMO it is outside the scope of a standards track document. Now that SR-MPLS is deployed in many places, I expect the community to gain sufficient experience to recommend (or not recommend) a particular minimum/maximum size for the SRGB is some future informational or BCP draft/RFC

[[Sasha]] My reading of your response is that minimum size of SRGB is an issue for future study. Can you please just add this to the draft?

##Ahmed: OK. Added a sentence to the last paragraph of section 2.3






8.    Algorithms and Prefix SIDs:

a.    The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, but it does not explicitly link them with the Prefix-SID algorithms defined in section 3.1.1 of the Segment Routing Architecture draft

#Ahmed: I will just add the reference [I-D.ietf-spring-segment-routing] right beside the first time "Algorithm" is mentioned

[[Sasha]] OK





b.    From my POV, the draft should explicitly state that the default Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.

#Ahmed: The specification of what path calculation method should or must be supported is a routing protocol property not a forwarding plane property. In fact, the choice of a path calculation method or algorithm is completely orthogonal to the routed protocol. Hence mandating the support of a particular routing algorithm is beyond the scope of this document.

[[Sasha]] OK





c.    The Segment Routing Architecture draft states (in section 3.1.3) that “Support of multiple algorithms applies to SRv6â€. But neither draft states whether multiple algorithms apply to SR-MPLS. Can you please clarify this point?

#Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in draft-ietf-spring-segment-routing-15 discusses the support of multiple algorithms. So it is implied that the concept of algorithm applies to SR-MPLS. Hence there is no need to re-mention it here

[[Sasha]] The paragraph to which you refer only says that if a packet with the active Prefix-SID that is associated with a specific algorithm is received by a node that does not support this algorithm, this packet will be discarded. If this is the only type of support for multiple algorithms SR provides, it is not very useful IMHO.

##Ahmed: The SR-MPLS draft that we are discussing here does not attempt to modify the SR-architecture draft. Any concerns related to the SR-architecture should be addressed to the SR-architecture draft not to this draft.





9.    Routing instances and the context for Prefix-SIDs:

a.    The Segment Routing Architecture draft states in Section 3.1 that the “context for an IGP-Prefix segment includes the prefix, topology, and algorithmâ€

b.    This draft seems to define (in section 2.5) the context for the Prefix SID as “Prefix, Routing Instance, Topology, Algorithm†where â€a routing instance is identified by a single incoming label downloader to FIB†(but the notion of the label downloader to FIB is not defined).

c.    These two definitions look different to me.

d.    At the very least I would expect alignment between the definitions of context for the Prefix-SID between the two drafts. Preferably, the definition given in the Segment Routing Architecture draft should be used in both drafts.

#Ahmed: The context of the section 2.5 is limited to the resolution of local label collision. The use of "routing instance" in section 2.5 is just there for tie-breaking if there is local label collision.

[[Sasha]] I have already mentioned that “routing instances†are not defined in any the drafts dealing with SR Extensions for IGPs. So I do not understand how the conflict resolution procedure is supposed to use this. And in any case the difference between two definitions of the context of Prefix-SID requires some explanation.

##Ahmed: incoming label collision defines what is a routing instance within its context. I do not understand what explanation you are looking for







10. Example of PUSH operation in Section 2.10.1:

a.    The first para of this section begins with the sentence “Suppose an MCC on a router "R0" determines that PUSH or CONTINUE   operation is to be applied to an incoming packet whose active SID is the global SID "Si"â€. In the context of SR-MPLS this means (to me) that the incoming packet is a labeled packet and its top label matches the global SID “Siâ€.

b.    However, the example for PUSH operation in the next para of this section is the case of an (unlabeled) IP packet with the destination address covered by the IP prefix for which “Si†has been assigned.

c.    From my POV:

                                         i.    Mapping unlabeled packets to SIDs is indeed out of scope of the draft. Therefore an example of a PUSH operation that is applied to a labeled packet (with the active SID inferred from the top label in the stack) is preferable.

                                        ii.    Valid examples of  PUSH operation applied to a labeled incoming packet can be found in Sections 4.2 or 4.3 of the TI-LFA draft

 

#Ahmed: I do not understand your concern here:)



[[Sasha]] I think it is pretty clear: can you provide an example of a PUSH operation applied to a labeled packet instead of your current example?

##Ahmed: The example in the draft is included to clarify the concept of a prefix SID attached to a prefix. As mentioned more than once, SR-MPLS does not modify MPLS forwarding including pushing a label on a labeled packet. It is something that has been done by routers and switches for 20+ years. So including it here is redundant


Nits:

1.    I concur with Adrian regarding numerous nits he has reported in his WG LC Comment. I would like to thank Adrian for an excellent review that have saved me lots of hard work.

#Ahmed: I also agree that Adrian's review is exceptional. I believe I addressed all his comments in the latest version.



2.    In addition, I’d like to report the following nits:

a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA draft)

#Ahmed: Already done in the latest version[[Sasha]] OK



b.    TI-LFA draft is referenced in the text of Section 2.11.1, but there is no matching reference in the “References†section (probably, Informational)

#Ahmed: Already done in the latest version[[Sasha]] OK



c.    “zero Algorithm†in Section 2.5 (immediately above Section 2.5.1) must be replaced with “default algorithmâ€. Similarly, “non-zero Algorithm†should be replaced with “non-default algorithmâ€

#Ahmed: Will be done in the next version[[Sasha]]  OK



3.    I think that RFC 3443 and RFC 5332 should be listed as Normative references in this draft while RFC 5331 and RFC 8277 should be listed as Informative references. This would improve the readability of the draft without any impact on its advancement.

 

#Ahmed RFC5331 describes upstream label assignment. As you mentioned above (and I will modify the draft to indicate that) SR-MPLS behavior is similar to downstream label assignment. RFC 3443 describes TTL behavior. This is an MPLS forwarding behavior. As mentioned in the draft, SR-MPLS does not modify at the MPLS forwarding behavior

[[Sasha]] Regarding RFC 5331 – you may skip this reference if you state (as discussed below) that SR-MPLS only allocates labels from the per-platform label space. Regarding RFC 3443 – I do not think that you can fully avoid discussion of Uniform and Pipe/Short Pipe models, and therefore you will need this reference.

##Ahmed: I did not add rfc5331 as a reference . Again pushing multiple labels on top of a packet is a matter of SR-policy, which is handled in a separate draft.







Hopefully, these comments will be useful.

#Ahmed: They are certainly quite useful. Thanks a lot



 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 

_________________________________________________________________________________________________________________________
 
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.

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

--------------83F8216D09A2658E8EA73302-- From nobody Mon Oct 29 08:12:26 2018 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 AF772131047; Mon, 29 Oct 2018 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vTOu05LSR9Xr; Mon, 29 Oct 2018 08:12:07 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 98FA6130FF8; Mon, 29 Oct 2018 08:12:06 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id z2-v6so1591638pfe.2; Mon, 29 Oct 2018 08:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wPK8g9/bGWWK2gHshFmnJW4JZxvpfteXI0uY5NYcoT0=; b=HIX4COSW/MEf5tmR0Ncp61SxVP1me2DwIQToYBa3d1rRAa5GHQSmTcs8VrCUG2C8Vu VLvhOBlLUMYsXmtOZl0tPOVeFqEzX7bxjROGp0emfnbLOst5va2jcT9CuANuXF9Tasby lHpylPjvEpNYjOXPrx/UwvgacbJlFvXLvvie0dALyqHImBJsvS6NA+qsi6+qro+PjjY5 4b/gF+z644EpXdMCCLH4k7uiY82caLh/Pc43WBZSSQrZ+crGQFTz3M9eun6/XzZSo/Xk W4ZxTR9RBV+FIdOU4LCbM2HTRWwtDV39ce/fOfHOPkrIMY/HbCilVBdR5CZ9ivPwoT4u 6oaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wPK8g9/bGWWK2gHshFmnJW4JZxvpfteXI0uY5NYcoT0=; b=UNROYFhwBvFeCt9WkikNf4ZUfpoDZQV6gAZOWDUDYv/UY9skcvRlMP5QsQS9fgy+ZB slFMV0a07QtGbW2stYHXlyO9EObKd1qPMTekvZG35qyghduIkEUa+gK5B+FoW0ESVu+A sRXw8Aq3UuWMd/U9lWcShGuskEFTaT2EmwZS7jmmNv2+72kfccShoV34SxIUI3yCmyAt i1VYCan1Ochqxp+t+Zu2pP+MzPafvEl2vYnrGb81Fh3j4cP1e8zPmDeSaJ3mKIkkXl0J lZNjJggHVUmntadatoGyoHqbRXU9hVyQRb3jIR+XjDbNaE3qYxjCUQtM/DKsIAg335la RwOQ== X-Gm-Message-State: AGRZ1gKjaClrJaSKBUKlYWjJoq4f1DMtFAWQFZSSb4aDPtwhFag/H7sm qKlQ45MOMFQinXzLW90U9rWjIWfe X-Google-Smtp-Source: AJdET5d24DUU2UgmhjfxsrsIQnYdCSwfb/jRXPxuIXx7gOLy/T0YIu+lIT8xoppiTz8G3BT7FadrFg== X-Received: by 2002:a62:7e93:: with SMTP id z141-v6mr13351776pfc.241.1540825925631; Mon, 29 Oct 2018 08:12:05 -0700 (PDT) Received: from ?IPv6:2601:646:9300:4fc9:206b:d327:ba4b:67ad? ([2601:646:9300:4fc9:206b:d327:ba4b:67ad]) by smtp.gmail.com with ESMTPSA id l16-v6sm31957452pfj.179.2018.10.29.08.12.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 08:12:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6D3ECD89-F252-4B06-962C-2E71AADBC003 Mime-Version: 1.0 (1.0) From: Gaurav Dawra X-Mailer: iPhone Mail (15F79) In-Reply-To: <870b223b-5fa7-e5f3-919f-f36521d69d68@kuehlewind.net> Date: Mon, 29 Oct 2018 08:12:01 -0700 Cc: Martin Stiemerling , SPRING WG , tsv-art@ietf.org, Alvaro Retana Content-Transfer-Encoding: 7bit Message-Id: References: <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> <870b223b-5fa7-e5f3-919f-f36521d69d68@kuehlewind.net> To: =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= Archived-At: Subject: Re: [spring] [Tsv-art] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 15:12:18 -0000 --Apple-Mail-6D3ECD89-F252-4B06-962C-2E71AADBC003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, Thanks again for working with us on these comments. Since we have done few revisions to address these comments. I am pasting sec= tion 7.1 revised text. Please see if this makes sense. I will make the neces= sary edits. =E2=80=9CLarge, long-lived "elephant" flows may affect each other=E2=80=99s p= erformance or that of smaller, short-lived "mouse" flows when left to normal= per-flow ECMP load-sharing. The host which is originating an =E2=80=9Celeph= ant=E2=80=9D flow may share its application observations with a centralized a= gent by indicating its bandwidth requirements and the destination for the fl= ow, that enables the latter to keep up-to-date network bandwidth demand maps= for such flows correlated with the actual utilization of the paths in the n= etwork. The end host may receive updated information from the centralized ag= ent, published via external mechanisms, of specific paths with their bandwid= th availability on which to steer its flow. =20 For example, an application A.1 is informed about an explicit paths to Z {16= 006, 16011} which has bandwidth availability such as not to degrade other fl= ows. The centralized agent may similarly pin =E2=80=9Celephant=E2=80=9D flow= s on other disjoint explicit paths. Over a period of time, or once the =E2=80= =9Celephant=E2=80=9D flow is gone (as reported by the application), then the= centralized agent updates the hosts to revert back to their normal per-flow= ECMP based hashing for load-sharing. This allows for solving the "elephant f= low" problem in the data-center and avoiding link imbalances.=E2=80=9D Gaurav Sent from my iPhone > On Oct 18, 2018, at 3:25 AM, Mirja K=C3=BChlewind (IETF) wrote: >=20 > Hi Gaurav, >=20 > thanks for your edits but unfortunately they don't address my concerns.=20= >=20 > Saying that a flowlet is per 5-tuple is just a clarification of what a flo= wlet is but doeen't change anything about what the text says. >=20 > Please consider removing section 7 entirely because this is really beyond t= he doc of this document and would need further discussion in one or multiple= separate documents. Why is that not an option for the authors? Why do you t= hink that section 7 is important for this document? >=20 > Mirja >=20 >=20 >> On 16.10.18 07:45, Gaurav Dawra wrote: >> Hi MIrja, >>=20 >> I have posted a new version. Please do let me know if we need to discuss f= urther. We can do it over the phone. >>=20 >> Cheers, >>=20 >> Gaurav >>=20 >>=20 >>> On Mon, Sep 3, 2018 at 4:29 AM Gaurav Dawra wrot= e: >>> Hi Mirja, >>>=20 >>> Please see inline...[Gaurav2] >>>=20 >>>> On Thu, Aug 9, 2018 at 8:30 AM Mirja K=C3=BChlewind wrote: >>>> Hi Gaurav, >>>>=20 >>>> please see inline. >>>>=20 >>>>> On 03.08.2018 07:20, Gaurav Dawra wrote: >>>>> Hey Mirja, >>>>>=20 >>>>> Sorry for the long delay. I was traveling constantly since IETF and bi= t lost in my mailbox and discussion with Authors. Please see my response inl= ine[Gaurav] >>>>>=20 >>>>> I think with your changes you addressed explicit problems Martin calle= d out, however, I still have high level concerns about these sections as the= y are mostly giving speculative recommendation which are not clear to me to w= ork in practice. >>>>>=20 >>>>> Regarding section 7.1, you say >>>>> "A flowlet is defined as a burst of packets from the same flow followe= d by an idle interval." >>>>> but then you say >>>>> "...then the application can break the elephant flow F into flowlets F1= , F2, F3, F4..." >>>>>=20 >>>>> This sounds like you would just divide an elephant flow mostly randoml= y into flowlets which can interact badly with the congestion control. If you= actually have chunks of data that are transmitted with large enough idle in= terval in between (as you define flowlets in the first sentence), that is no= t an elephant flow anymore and it will not help you to "spread the load of t= he elephant flow through all the ECMP paths". In summary I actually don't se= e how the concept of flowlets can be helpful to address the problem you have= at all, and I still advise you to remove section 7.1 entirely. >>>>>=20 >>>>> [Gaurav] Hi Mirja, Thanks for the review. The proposal here is no diff= erent that current ECMP hashing at flowlet level. The only difference which i= s being pointed out here is that if we use SR, we could leverage on the abil= ity of be aware of multiple disjoint paths rather than the hashing. It=E2=80= =99s pins the flowlets to particular paths which is basic SR operations. >>>>>=20 >>>>=20 >>>> Yes the problem is that we usually don't recommend ECMP hashing on flow= let level because it can interact badly with the end-end mechanisms of that f= low. As I said, I don't see how the notion of flowlets help you problem and t= herefore I still recommend to remove that paragraph. >>>> [Gaurav2] OK. It took sometime to get to consensus with authors. Will u= pdate the text to use 5-tuple flows instead of flowlets. Would that suffice?= I will update the text shortly. >>>>>=20 >>>>> Regarding section 7.2, I also still skeptical about any benefits that c= an be achieved. Given you are in a data center, the controller should alread= y know about static parameters such as the maximum bandwidth per link. >>>>>=20 >>>>> For dynamic parameters, e.g. like loss rate, measuring them on a per-f= low bases is the wrong thing to do. What I mean is you can ask a router abou= t the average loss rate that it observes and that might give you some valuab= le, however, if you ask a TCP flow about the average loss rate the answer wi= ll mainly depend on the congestion controller used and the currently availab= le bandwidth, which is a very dynamic property and not a link characteristic= . So this information is not usable for performance aware routing. A flow co= uld give you information about the observed RTT (min/max) on a certain path,= or the maximum available bandwidth on a path, but as I said, given you are i= n a data center environment these are information that the controller alread= y should have anyway. >>>>>=20 >>>>> [Gaurav] They are two separate mechanisms. Most DCs have some sort of d= ata-plane/ECMP aware tracing mechanism to detect the loss/delays and can be c= ombined with Application back-off to detect issue. All this section is sugge= sting is that SR can be used to pin the path to particular set of ECMP paths= instead of relying on ECMP hashing. >>>>>=20 >>>>=20 >>>> This is not quite what the text says. If that is the statement you want= to make, that is fine but then you don't need to talk about performance awa= re routing at all. >>> [Gaurav2] I will update the text here with statement i mentioned above. I= MHO, it's performance aware routing wrt to end-host traffic. =20 >>>>=20 >>>>>=20 >>>>> Your example with detecting a faulty path due to losses does not work w= ith TCP as you never know if these loses are due to a problem on the path, s= elf-induced or by a competing flow. And even if you don't use TCP and e.g. s= end constant bit rate traffic, there may be a large number of competing TCP f= lows that can induce the loses. Try to steer traffic "away" on a time-scale t= hat is slower than TCP dynamics or even your flow dynamic (when flows start o= r end) in case you have a lot of very short flow, in the best case doesn't w= ork and in the worst case leads to oscillation. >>>>>=20 >>>>> [Gaurav] As I said above, there are other mechanisms to detect loss an= d trace the path on which loss is seen. This is a common mechanism = used in MSDCs. >>>>>=20 >>>> I think this is beyond the scope of the document. =20 >>> [Gaurav2] Will update the text. >>>>=20 >>>>> =20 >>>>>=20 >>>>> I am happy to discuss further over the phone to try to explain the tho= ught process. I will also do check again with Authors to update the text or s= omething else based on our conversation. >>>>>=20 >>>>=20 >>>> Maybe see if some update can be made to the text first and then we can h= ave another discussion if needed. >>>> [Gaurav2] Sounds good. Will update the text shortly and then we can dis= cuss if needed. >>>=20 >>> Cheers, >>>=20 >>> Gaurav=20 >>>>> =20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Gaurav >>>>>=20 >>>>> If you want to make TCP use for handover situation where one path migh= t go away or become unusable, it's best to use Multipath TCP (with coupled c= ongestion control) instead because that works on the right time scale. Again= , I don't think this is a use case for SR and I would recommend to remove th= e section entirely. >>>>>=20 >>>>> Mirja >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra wrote: >>>>>> Hi Mirja, >>>>>>=20 >>>>>> Ack. Let me work with authors to close ASAP. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Gaurav >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Jul 5, 2018, at 10:06 AM, Mirja K=C3=BChlewind wrote: >>>>>>=20 >>>>>>> Hi Gaurav, >>>>>>>=20 >>>>>>> sorry for my very long delay but this got somehow a bit lost in my m= ailbox. >>>>>>>=20 >>>>>>> I think with your changes you addressed explicit problems Martin cal= led out, however, I still have high level concerns about these sections as t= hey are mostly giving speculative recommendation which are not clear to me t= o work in practice. >>>>>>>=20 >>>>>>> Regarding section 7.1, you say >>>>>>> "A flowlet is defined as a burst of packets from the same flow follo= wed by an idle interval." >>>>>>> but then you say >>>>>>> "...then the application can break the elephant flow F into flowlets= F1, F2, F3, F4..." >>>>>>>=20 >>>>>>> This sounds like you would just divide an elephant flow mostly rando= mly into flowlets which can interact badly with the congestion control. If y= ou actually have chunks of data that are transmitted with large enough idle i= nterval in between (as you define flowlets in the first sentence), that is n= ot an elephant flow anymore and it will not help you to "spread the load of t= he elephant flow through all the ECMP paths". In summary I actually don't se= e how the concept of flowlets can be helpful to address the problem you have= at all, and I still advise you to remove section 7.1 entirely. >>>>>>>=20 >>>>>>> Regarding section 7.2, I also still skeptical about any benefits tha= t can be achieved. Given you are in a data center, the controller should alr= eady know about static parameters such as the maximum bandwidth per link. Fo= r dynamic parameters, e.g. like loss rate, = measuring them on a per-flow bases is the wrong thing to do. What I m= ean is you can ask a router about the average loss rate that it observes and= that might give you some valuable, however, if you ask a TCP flow about the= average loss rate the answer will mainly depend on the congestion controlle= r used and the currently available bandwidth, which is a very dynamic proper= ty and not a link characteristic. So this information is not usable for perf= ormance aware routing. A flow could give you information about the observed R= TT (min/max) on a certain path, or the maximum available bandwidth on a path= , but as I said, given you are in a data center environment these are inform= ation that the controller already should have anyway. >>>>>>>=20 >>>>>>> Your example with detecting a faulty path due to losses does not wor= k with TCP as you never know if these loses are due to a problem on the path= , self-induced or by a competing flow. And even if you don't use TCP and e.g= . send constant bit rate traffic, there may be a large number of competing T= CP flows that can induce the loses. Try to steer traffic "away" on a time-sc= ale that is slower than TCP dynamics or even your flow dynamic (when flows s= tart or end) in case you have a lot of very short flow, in the best case doe= sn't work and in the worst case leads to oscillation. >>>>>>>=20 >>>>>>> If you want to make TCP use for handover situation where one path mi= ght go away or become unusable, it's best to use Multipath TCP (with coupled= congestion control) instead because that works on the right time scale. Aga= in, I don't think this is a use case for SR and I would recommend to remove t= he section entirely. >>>>>>>=20 >>>>>>> Mirja >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 05.07.2018 04:08, Gaurav Dawra wrote: >>>>>>>> Hey Alvaro, Mirja,=20 >>>>>>>>=20 >>>>>>>> Friendly reminder to further progress this document. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Gaurav >>>>>>>>=20 >>>>>>>>> On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra wrote: >>>>>>>>> Hi Alvaro, Mirja=20 >>>>>>>>>=20 >>>>>>>>> Any feedback or next steps to close this? >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>> Gaurav >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Jun 12, 2018, at 7:06 AM, Gaurav Dawra w= rote: >>>>>>>>>=20 >>>>>>>>>> Hi Mirja, >>>>>>>>>>=20 >>>>>>>>>> Friendly Reminder...Could you please also advice if there is anyt= hing further to DISCUSS on this document which was also related to TCP updat= es below? >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>>=20 >>>>>>>>>> Gaurav >>>>>>>>>>=20 >>>>>>>>>>> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana wrote: >>>>>>>>>>> Thanks Martin! >>>>>>>>>>>=20 >>>>>>>>>>>> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@gma= il.com) wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Alvaro, all,=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks for addressing my concerns.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> This version is good to go from my side.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Kind regards,=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> ;Martin=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Am 30.05.18 um 21:55 schrieb Alvaro Retana:=20 >>>>>>>>>>>> > Martin:=20 >>>>>>>>>>>> > br/>> Hi!! How are you?=20 >>>>>>>>>>>> > br/>> Gaurav just posted a revision. Please takke a look and= let us know if br/>> the changes address your concerrns or not.=20 >>>>>>>>>>>> > br/>> https://www.ietf.org/rfcdiff??url2=3Ddraft-ietf-spring-= segment-routing-msdc-09=20 >>>>>>>>>>>> > br/>> Thanks!!!=20 >>>>>>>>>>>> > br/>> Alvaro. <=20 >>>>>>>>>>>> > br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((gdawra.i= etf@gmail.com br/>> ) wrote:=20 >>>>>>>>>>>> > br/>>> Hi Martin, <=20 >>>>>>>>>>>> >>=20 >>>>>>>>>>>> >> Thanks for review. I will post the new version. Hopefully, i= t will br/>>> address all your comments and we can close thhis review.=20 >>>>>>>>>>>> >>=20 >>>>>>>>>>>> >> Any updates on below response?=20 >>>>>>>>>>>> >>=20 >>>>>>>>>>>> >> Cheers,=20 >>>>>>>>>>>> >>=20 >>>>>>>>>>>> >> Gaurav=20 >>>>>>>>>>>> >>=20 >>>>>>>>>>>> >> Sent from my iPhone=20 >>>>>>>>>>>> >>=20 >>>>>>>>>>>> >> On May 23, 2018, at 4:17 AM, Gaurav Dawra >> > wrote:=20 >>>>>>>>>>>> >>=20 >>>>>>>>>>>> >>> Hi Martin,=20 >>>>>>>>>>>> >>>=20 >>>>>>>>>>>> >>> Thanks for the review. Any further comments here ? I will p= ost the br/>>>> new version soon. <=20 >>>>>>>>>>>> >>>=20 >>>>>>>>>>>> >>> Cheers,=20 >>>>>>>>>>>> >>>=20 >>>>>>>>>>>> >>> Gaurav=20 >>>>>>>>>>>> >>>=20 >>>>>>>>>>>> >>> Sent from my iPhone=20 >>>>>>>>>>>> >>>=20 >>>>>>>>>>>> >>> On May 16, 2018, at 7:44 PM, Gaurav Dawra >>> > wrote:=20 >>>>>>>>>>>> >>>=20 >>>>>>>>>>>> >>>> Hi Martin,=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>> Apologies from my end we had few internal authors conversa= tions on br/>>>>> the points you have raised. <=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>> Please find below my response. I will be happy to discuss = further, br/>>>>> i= f needed. <=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>> inline...=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling >>>>> > wrote:=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> Hi Gaurav,=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> This got lost on my end, sorry for this. The filter just m= oved br/>>>>>> these messages out of my sight... :-/=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:=20 >>>>>>>>>>>> >>>>>> Hey Martin,=20 >>>>>>>>>>>> >>>>>> Sorry for late reply. Please see some comments inline[Ga= urav] =20 >>>>>>>>>>>> >>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>= >>> br/>>>>>>>>; > wrote:=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> Hi all,=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> I've reviewed this document as part of the transport ar= ea review br/>>>>>>>> team's ongoing effort to review key IETF documents. Th= ese br/>>>>t;>>>> comments were written primarily for the transport area d= irectors, br/>>>>>>>> but are copied to the doocument's authors for their in= formation br/>>>>>>>&> and to allow them to address any issues raised. When d= one at the=20 >>>>>>>>>>>> >>>>>>> time of IETF Last Call, the authors should consider thi= s review br/>>>>>>>> together with any other last-call comments they receive= . Please br/>>>&>>>>> always CC tsv-art@=E2=80=A6 if you reply to or forward= this review.=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> Summary:=20 >>>>>>>>>>>> >>>>>>> This draft has serious issues in Section 7..1, 7.2 and i= n one part br/>>>>>>>> of Secction3, described in the review, and needs to b= e rethought. br/>>&>>>>>> The other sections are good AFAIK.=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> Technicals:=20 >>>>>>>>>>>> >>>>>>> The overall draft looks ok, but the three points below l= ook br/>>>>>>>> strange and need a fix before publication IMHO:=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but= not well br/>>>>>>>> proven funcationality and not even safe to use functio= nality. br/>>>&>>>>> Both are some sort discussing that different paths in t= he network br/>>>>>>>> could be used by the eend host traffic. This sounds p= retty much br/>>>>>>>t;> like the Path Aware Networking Proposed Research G= roup br/>>t;>>>>>> (https://irtf.org/panrg) and hints to the fact that the= re is no br/>>>>>>>> commonly understannd and accepted engineering solution i= n this space.=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> Section 7.1:=20 >>>>>>>>>>>> >>>>>>> [KANDULA04] is a really old reference that hasn't been f= ollowed br/>>>>>>>> up iin recent times and even worse there is no evidence t= hat this br/>>t;>>>>>> is going to work good enough or stable enough under= real Internet br/>>>>>>>> traffic. Additioonally, it is more than unclear h= ow any modern TCP br/>>>>&ggt;>>> implementation will react to this=20 >>>>>>>>>>>> >>>>>> [Gaurav] Will get back on this.=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> I will reply to the other email dicussing this.=20 >>>>>>>>>>>> >>>> I have replied to other thread.=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> Section 7.2:=20 >>>>>>>>>>>> >>>>>>> This section describes an idea without detailing too mu= ch about br/>>>>>>>> any furtther aspects. Further it changes the commonly a= ccepted br/>>>;>>>>> = notion of what an end host can do with the network. At best this br/>>>>>= >>> would require a good ddefinition of what an end host in your br/>>>>>>>&= ggt; setting is, e.g., a highly modified piece of (at least) software=20 >>>>>>>>>>>> >>>>>>> that usually not found in OS availble on the market (ye= t?)=20 >>>>>>>>>>>> >>>>>>> Further communicating instantaneous path characteristic= s to a br/>>>>>>>> central point is potentially a bad idea, as the data is a= lready br/>>>;>>>>> outdated when reported by any node.=20 >>>>>>>>>>>> >>>>>> [Gaurav] I believe Authors are trying to highlight that H= ost which br/>>>>>>> is defineed in br/>>>>>>> (https://tools.ietf.org/html/= draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the traffic= based on the Calculations locally or br/>>>t;>>>> jointly with the contro= ller. Implementations can decide how much br/>>>>>>> Centralized -vs- locali= zed coontrol is allowed at Host based on br/>>>>>>> perfoormance data collec= tion.=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> Performance data collection (monitoring?) isn't crucial w= hen it br/>>>>>> comes to timely (actuaally real-time) reaction. However, th= is br/>>>>>> secttion isn't just about performance data collection as it is a= bout br/>>>>>>> "Performance-aware routing" this seems to try to interact in= br/>>>>>> real-time with the network behhavior of TCP. This isn't even clos= e br/>>>>>> to acceeptable.=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> I would be ok to say that it is useful to collect perform= ance data br/>>>>>> for offline analysis and improvement of the data network= . However, br/>>>>>&ggt; this is at completely different magnitues of time s= cales.=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> I would recommend to remove the TCP part from this sectio= n entirely.=20 >>>>>>>>>>>> >>>> Ack, will update in next rev:=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>> Section will read like this:=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>> ;=20 >>>>>>>>>>>> >>>> /Knowing the path associated with flows/packets, the end h= ost may/=20 >>>>>>>>>>>> >>>> /deduce certain characteristics of the path on its own, an= d/=20 >>>>>>>>>>>> >>>> /additionally use the information supplied with path infor= mation/=20 >>>>>>>>>>>> >>>> /pushed from the controller or received via pull request. T= he host/=20 >>>>>>>>>>>> >>>> /may further share its path observations with the centrali= zed agent,/=20 >>>>>>>>>>>> >>>> /so that the latter may keep up-to-date network health map= to assist/=20 >>>>>>>>>>>> >>>> /other hosts with this information./=20 >>>>>>>>>>>> >>>> //=20 >>>>>>>>>>>> >>>> /For example, an application A.1 at HostA may pin a flow d= estined/=20 >>>>>>>>>>>> >>>> /to HostZ via Spine node Node5 using label stack {16005, 1= 6011}. The/=20 >>>>>>>>>>>> >>>> /application A.1 may collect information on packet loss, d= educed from/=20 >>>>>>>>>>>> >>>> /Other offline mechanisms. [There are some pingMesh mechan= isms which /=20 >>>>>>>>>>>> >>>> /Can be used here]/=20 >>>>>>>>>>>> >>>> /Through these mechanisms information to a centralized age= nt, e.g./=20 >>>>>>>>>>>> >>>> /after a flow completes, or periodically for longer lived f= lows./=20 >>>>>>>>>>>> >>>> /Next, using both local and/or global performance data, ap= plication/=20 >>>>>>>>>>>> >>>> /A.1 as well as other applications sharing the same resour= ces in the/=20 >>>>>>>>>>>> >>>> /DC fabric may pick up the best path for the new flow, or u= pdate an/=20 >>>>>>>>>>>> >>>> /existing path (e.g.: when informed of congestion on an ex= isting/=20 >>>>>>>>>>>> >>>> /path)./=20 >>>>>>>>>>>> >>>> ;=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>>>>=20 >>>>>>>>>>>> >>>>>>> Section 3, 3rd bullet point:=20 >>>>>>>>>>>> >>>>>>> It is the foundation of TCP that the network is regarde= d as a br/>>>>>>>> black box and that you infer from the transmission of pac= kets br/>>>>;>>>> what the current state of the network path is. Inferring n= etwork br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea= , as br/>>>>>>>>; this would required that all paths exhibit this and if not= what br//>>>>>>>> is going to happen?=20 >>>>>>>>>>>> >>>>>>> It could be an interesting research field to change man= y points br/>>>>>>>> in TCP'ss behavior, but this once again points = to the fact that br/>>>&>>= >>> this not the IETF works but IRTF or elsewhere.=20 >>>>>>>>>>>> >>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP i= s rightly br/>>>>>>> treating Network as Black Box. Authors are implying per= path br/>>>>;>>> performance metrics as not cached. Is there some change in= text br/>>>>>>> you are suggesting??=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> I would recommend to remove the 3rd bullet point complete= y. TCP br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is= br/>>>>>> something the network could decide, e.g., rerouting TCP flows br/= >&ggt;>>>> within the network or changing the forwarding path in the network= br/>>>>>> for particular flows (if it is not routed).=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>> Ack, after discussion, we will remove the Section= 3 - 3rd br/>>>>> bullet point. Willl update in next rev - coming shortly.=20= >>>>>>>>>>>> >>>>=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> Kind regards,=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>> Martin=20 >>>>>>>>>>>> >>>>>=20 >>>>>>>>>>>> >>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Tsv-art mailing list >>>>>>>> Tsv-art@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/tsv-art >>>>>>>=20 >>>>>=20 >>>>=20 >>=20 >>=20 >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art >=20 --Apple-Mail-6D3ECD89-F252-4B06-962C-2E71AADBC003 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mirja,

Thanks again f= or working with us on these comments.

Since we have= done few revisions to address these comments. I am pasting section 7.1 revi= sed text. Please see if this makes sense. I will make the necessary edits.

=E2=80=9CLarge, long-lived "elephant" flows may affect each other=E2=80= =99s performance or that of smaller, short-lived "mouse" flows when left to n= ormal per-flow ECMP load-sharing. The host which is originating an =E2=80=9C= elephant=E2=80=9D flow may share its application observations with a central= ized agent by indicating its bandwidth requirements and the destination for t= he flow, that enables the latter to keep up-to-date network bandwidth demand= maps for such flows correlated with the actual utilization of the paths in t= he network. The end host may receive updated information from the centralize= d agent, published via external mechanisms, of specific paths with their ban= dwidth availability on which to steer its flow.
=

 
For example, an application A=
.1 is informed about an explicit paths to Z {16006, 16011} which has bandwid=
th availability such as not to degrade other flows. The centralized agent ma=
y similarly pin =E2=80=9Celephant=E2=80=9D flows on other disjoint explicit p=
aths. Over a period of time, or once the =E2=80=9Celephant=E2=80=9D flow is g=
one (as reported by the application), then the centralized agent updates the=
 hosts to revert back to their normal per-flow ECMP based hashing for load-s=
haring. This allows for solving the "elephant flow" problem in the data-cent=
er and avoiding link imbalances.=E2=80=9D

=

Gaurav

Sent from my iPhone

On Oct 18, 2018, at 3:25 AM, Mirja K=C3= =BChlewind (IETF) <ietf@kuehlewind= .net> wrote:

=20 =20 =20 Hi Gaurav,

thanks for your edits but unfortunately they don't address my concerns.

Saying that a flowlet is per 5-tuple is just a clarification of what a flowlet is but doeen't change anything about what the text says.

Please consider removing section 7 entirely because this is really beyond the doc of this document and would need further discussion in one or multiple separate documents. Why is that not an option for the authors? Why do you think that section 7 is important for this document?

Mirja


On 16.10.18 07:45, Gaurav Dawra wrote:
Hi MIrja,

I have posted a new version. Please do let me know if we need to discuss further. We can do it over the phone.

Cheers,

Gaurav


On Mon, Sep 3, 2018 at 4:29 AM Gaurav Dawra <gdawra.ietf@gm= ail.com> wrote:
Hi Mirja,

Please see inline...[Gaurav2]

On Thu, Aug 9, 2018 at 8:30 AM Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
Hi Gaurav,

please see inline.

On 03.08.2018 07:20, Gaurav Dawra wrote:
Hey Mirja,

Sorry for the long delay. I was traveling constantly since IETF and bit lost in my mailbox and discussion with Authors. Please see my response inline[Gaurav]


I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.

Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the application can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow through all the ECMP paths". In summary I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.

[Gaura= v] Hi Mirja, Thanks for the review. = The proposal here is no different that current ECMP hashing at flowlet level. The only difference which is being pointed out here is that if we use SR, we could leverage on the ability of be aware of multiple disjoint paths rather than the hashing. It=E2=80=99s pins the flowlets to particular p= aths which is basic SR operations.


Yes the problem is that we usually don't recommend ECMP hashing on flowlet level because it can interact badly with the end-end mechanisms of that flow. As I said, I don't see how the notion of flowlets help you problem and therefore I still recommend to remove that paragraph.
[Gaurav2] OK. It took sometime to get to consensus with authors. Will update the text to use 5-tuple flows instead of flowlets. Would that suffice? I will update the text shortly.


Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link.

For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.<= /p>

[Gaura= v] They are two separate mechanisms. Most DCs have some sort of data-plane/ECMP aware tracing mechanism to detect the loss/delays and can be combined with Application back-off to detect issue. All this section is suggesting is that SR can be used to pin the path to particular set of ECMP paths instead of relying on ECMP hashing.


This is not quite what the text says. If that is the statement you want to make, that is fine but then you don't need to talk about performance aware routing at all.
[Gaurav2] I will update the text here with statement i mentioned above. IMHO, it's performance aware routing wrt to end-host traffic.   


Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away" on a time-scale that is slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.

[Gaura= v] As I said above, there are other mechanisms to detect loss and trace the path on which loss is seen. This is a common mechanism used in MSDCs.

I think this is beyond the scope of the document. 
[Gaurav2] Will update the text.

 

I am happy to discuss further over the phone to try to explain the thought process. I will also do check again with Authors to update the text or something else based on our conversation.


Maybe see if some update can be made to the text first and then we can have another discussion if needed.
[Gaurav2] Sounds good. Will update the text shortly and then we can discuss if needed.

Cheers,

Gaurav 

 

Cheers,

 

Gaurav

If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for SR and I would recommend to remove the section entirely.

Mirja<= /span>

 



On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Mirja,

Ack. Let me work with authors to close ASAP.

Cheers,

Gaurav

Sent from my iPhone

On Jul 5, 2018, at 10:06 AM, Mirja K=C3=BChlewind <ietf@kuehlewi= nd.net> wrote:

Hi Gaurav,

sorry for my very long delay but this got somehow a bit lost in my mailbox.

I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.
=
Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the application can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow through all the ECMP paths". In summary I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.

Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link. For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.

Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away" on a time-scale that is slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.
=
If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for SR and I would recommend to remove the section entirely.

Mirja


On 05.07.2018 04:08, Gaurav Dawra wrote:
Hey Alvaro, Mirja, 

Friendly reminder to further progress this document.

Cheers,

Gaurav

On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Alvaro, Mirja 

Any feedback or next steps to close this?

Cheers,

Gaurav

Sent from my iPhone
=

On Jun 12, 2018, at 7:06 AM, Gaurav Dawra <gd= awra.ietf@gmail.com> wrote:

H= i Mirja,

Friendly Reminder...Could you please also advice if there is anything further to DISCUSS on this document which was also related to TCP updates below?

Cheers,
=

Gaurav

On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:

Thanks Martin!

=

On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (= mls.ietf@gmail.com) wrote:
Hi Alvaro, all,

Thanks for addressing my concerns.

This version is good to go from my side.

Kind regards,

;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> br/>> Hi!!  How are= you?
> br/>> Gaurav just posted a revision.  Please takke a look and let us know if br/>> the changes address your concerrns or not.
> br/>> https://www.ietf.org/rfc= diff??url2=3Ddraft-ietf-spring-segment-routing-msdc-09
> br/>> Thanks!!!
> br/>> Alvaro. <
> br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((gd= awra.ietf@gmail.com br/>> <mailto:gdawra.i= etf@@gmail.com>) wrote:
> br/>>> Hi Martin, <
>>
>> Thanks for review. I will post the new version. Hopefully, it will br/>>> address all your comments and we can close thhis review.
>>
>> Any updates on below response?
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>&= gt; On May 23, 2018, at 4:17 AM, Gaurav Dawra <gd= awra.ietf@gmail.com br/>>> <mailto:gdawra.i= etf@@gmail.com>> wrote:
>>
>>> Hi Martin,
>>>
>>>= ; Thanks for the review. Any further comments here ? I will post the br/>>>>= ; new version soon. <
>>>=
>>> Cheers,
>>>
>>> Gaurav
>>>
>>> Sent from my iPhone
>>>
>&= gt;> On May 16, 2018, at 7:44 PM, Gaurav Dawra <gd= awra.ietf@gmail.com br/>>>>= ; <mailto:gdawra.i= etf@@gmail..com>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>= ;> Apologies from my end we had few internal authors conversations on br/>>>>= ;> the points you have raised. <
>>>>
>>>> Please find below my response. I will be happy to discuss further, br/>>>>= ;> if needed. <
>>>>
>>>> <Gaurav> inline...
>>>= >
>>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <mls.ietf@gmail.com br/>>>>>> <mailto:mls.iietf@gmail.com>>= wrote:
>>>>>
>>>>> Hi Gaurav,
>>>>>
>>>= ;>> This got lost on my end, sorry for this. The filter just moved br/>>>>= ;>> these messages out of my sight... :-/
>>>= >>
>>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
>>>>>> Hey Martin,
>>>>>> Sorry for late reply. Please see some comments inline[Gaurav]
>&= gt;>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>= ;>>>> <mls.ietf@@gmail.co= m <mailto:ml= s.ietf@gmail.com> br/>>>>>>>>; <mailto:mls.ietf@gmail.com&= gt;> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>= ;>>>> I've reviewed this document as part of the transport area review br/>>>>= ;>>>> team's ongoing effort to review key IETF documents. These br/>>>&am= p;gtt;>>>> comments were written primarily for the transport area directors, br/>>>>= ;>>>> but are copied to the doocument's authors for their information br/>>>>= ;>>>&> and to allow them to address any issues raised. When done at the
>>>>>>> time of IETF Last Call, the authors should consider this review br/>>>>= ;>>>> together with any other last-call comments they receive. Please br/>>>&am= p;>>>>> always CC tsv-art@=E2=80=A6 i= f you reply to or forward this review.
>>>>>>>
>>>>>>> Summary:
>>>>>>> This draft has serious issues in Section 7..1, 7.2 and in one part br/>>>>= ;>>>> of Secction3, described in the review, and needs to be rethought. br/>>&>>>>>> The other sections are good AFAIK.
>>>>>>>
>>>>>>>
>>>>>>> Technicals:
>>>>>>> The overall draft looks ok, but the three points below look br/>>>>= ;>>>> strange and need a fix before publication IMHO:
>>>>>>>
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well br/>>>>= ;>>>> proven funcationality and not even safe to use functionality. br/>>>&>>>>> Both are some sort discussing that different paths in the network br/>>>>= ;>>>> could be used by the eend host traffic. This sounds pretty much br/>>>>>>&gtt;> like the Path Aware Networking Proposed Research Group br/>&gtt;>>>>>> (https://irtf.org/panrg) and hints to the fact that there is no br/>>>>= ;>>>> commonly understannd and accepted engineering solution in this space.
>>>>>>>
>>>>>>> Section 7.1:
>>>>>>> [KANDULA04] is a really old reference that hasn't been followed br/>>>>= ;>>>> up iin recent times and even worse there is no evidence that this br/>&gtt;&g= t;>>>>> is going to work good enough or stable enough under real Internet br/>>>>= ;>>>> traffic. Additioonally, it is more than unclear how any modern TCP br/>>>>= ;&ggt;>>> implementation will react to this
>>>= >>> [Gaurav] Will get back on this.
>>>>>
>>>>> I will reply to the other email dicussing this.
>>>> <Gaurav> I have replied to other thread.
>>>>>
>>>>>>>
>>>>>>> Section 7.2:
>>>= ;>>>> This section describes an idea without detailing too much about br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted br/>>>;&g= t;>>>> notion of what an end host can do with the network. At best this br/>>>>= ;>>>> would require a good ddefinition of what an end host in your br/>>>>= ;>>>&ggt; setting is, e.g., a highly modified piece of (at least) software
>>>= >>>> that usually not found in OS availble on the market (yet?)
>>>= ;>>>> Further communicating instantaneous path characteristics to a br/>>>>= ;>>>> central point is potentially a bad idea, as the data is already br/>>>;>>>>> outdated when reported by any node.
>>>>>> [Gaurav] I believe Authors are trying to highlight that Host which br/>>>>= ;>>> is defineed in br/>>>>>>> (https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the traffic based on the Calculations locally or br/>>&gt= t;>>>> jointly with the controller. Implementations can decide how much br/>>>>= ;>>> Centralized -vs- localized coontrol is allowed at Host based on br/>>>>>>> perfoormance data collection.
>>>>>
>>>>> Performance data collection (monitoring?) isn't crucial when it br/>>>>= ;>> comes to timely (actuaally real-time) reaction. However, this br/>>>>>> secttion isn't just about performance data collection as it is about br/>>>>= ;>>> "Performance-aware routing" this seems to try to interact in br/>>>>= ;>> real-time with the network behhavior of TCP. This isn't even close br/>>>>= ;>> to acceeptable.
>>>>>
>>>>> I would be ok to say that it is useful to collect performance data br/>>>>= ;>> for offline analysis and improvement of the data network. However, br/>>>>= ;>&ggt; this is at completely different magnitues of time scales.
>>>= >>
>>>>> I would recommend to remove the TCP part from this section entirely.
>>>> <Gaurav>Ack, will update in next rev:
>>>>
>>>> Section will read like this:
>>>>
>>>> ;
>>>> /Knowing the path associated with flows/packets, the end host may/
>>>> /deduce certain characteristics of the path on its own, and/
>>>> /additionally use the information supplied with path information/
>>>> /pushed from the controller or received via pull request. The host/
>>>> /may further share its path observations with the centralized agent,/
>>>> /so that the latter may keep up-to-date network health map to assist/
>>>> /other hosts with this information./
>>>> //
>>>> /For example, an application A.1 at HostA may pin a flow destined/
>>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/
>>>> /application A.1 may collect information on packet loss, deduced from/
>>>> /Other offline mechanisms. [There are some pingMesh mechanisms which /
>>>> /Can be used here]/
>>>> /Through these mechanisms information to a centralized agent, e.g./
>>>> /after a flow completes, or periodically for longer lived flows./
>>>> /Next, using both local and/or global performance data, application/
>>>> /A.1 as well as other applications sharing the same resources in the/
>>>> /DC fabric may pick up the best path for the new flow, or update an/
>>>> /existing path (e.g.: when informed of congestion on an existing/
>>>> /path)./
>>>> ;
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> Section 3, 3rd bullet point:
>>>= ;>>>> It is the foundation of TCP that the network is regarded as a br/>>>>>>>> black box and that you infer from the transmission of packets br/>>>>;>>>> what the current state of the network path is. Inferring network br/>>>>= ;>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as br/>>>>= ;>>>>; this would required that all paths exhibit this and if not what br//>>>&g= t;>>>> is going to happen?
>>>>>>> It could be an interesting research field to change many points br/>>>>= ;>>>> in TCP'ss behavior, but this once again points to the fact that br/>>>&am= p;>>>>> this not the IETF works but IRTF or elsewhere.
>>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly br/>>>>= ;>>> treating Network as Black Box. Authors are implying per path br/>>>>= ;;>>> performance metrics as not cached. Is there some change in text br/>>>>>>> you are suggesting??
>>>>>
>>>>>
>>>>> I would recommend to remove the 3rd bullet point completey. TCP br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is br/>>>>>> something the network could decide, e.g., rerouting TCP flows br/>&ggt;&g= t;>>> within the network or changing the forwarding path in the network br/>>>>= ;>> for particular flows (if it is not routed).
>>>>
>>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd br/>>>>= ;> bullet point. Willl update in next rev - coming shortly.
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>>  Martin
>>>>>
>>>> 




_____________________________=
__________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/li=
stinfo/tsv-art





_______________________________=
________________
Tsv-art mailing list
Tsv-a=
rt@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

=20
= --Apple-Mail-6D3ECD89-F252-4B06-962C-2E71AADBC003-- From nobody Mon Oct 29 08:34:20 2018 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 63AB7130DF9; Mon, 29 Oct 2018 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 9Jxvl6bksWrW; Mon, 29 Oct 2018 08:34:14 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 3192B130FB1; Mon, 29 Oct 2018 08:34:14 -0700 (PDT) Received: from 200116b82c3f460055e5bc077b676807.dip.versatel-1u1.de ([2001:16b8:2c3f:4600:55e5:bc07:7b67:6807]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gH9YR-000492-47; Mon, 29 Oct 2018 16:34:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 29 Oct 2018 16:34:09 +0100 Cc: Martin Stiemerling , SPRING WG , tsv-art@ietf.org, Alvaro Retana Content-Transfer-Encoding: quoted-printable Message-Id: References: <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> <870b223b-5fa7-e5f3-919f-f36521d69d68@kuehlewind.net> To: Gaurav Dawra X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1540827254;83bba635; X-HE-SMSGID: 1gH9YR-000492-47 Archived-At: Subject: Re: [spring] [Tsv-art] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 15:34:18 -0000 Hi Gaurav, this still sounds very much like inventing a new mechanism which seem a = bit out of scope for this document. However, after all bandwidth = requirements might not be known or are very dynamic because of = congestion control or adaption mechanism in the application (e.g. = adaptive video traffic), and therefore there it is still the same = problem that it is no reasonable to make decision based on this very = dynamic metric.=20 The text below sounds like you are rather interested to a) distinguish = elephant from mice flows and b) understand if the elephant flow has a = maximum bandwidth cap (because it's application-limited). These are = different information and might be more useful for your case. However, I = still think having this discussion in this level of details goes beyond = the scope of the document. What=E2=80=99s about just saying something like, a central host can = collect per-flow information, either from the host directly or = measurement on the path, and use this information to impact routing. I = would, however, also like to see a note/warning in this context that = metrics that are changing very dynamically should not be used as input = for routing decisions. Mirja > Am 29.10.2018 um 16:12 schrieb Gaurav Dawra : >=20 > Hi Mirja, >=20 > Thanks again for working with us on these comments. >=20 > Since we have done few revisions to address these comments. I am = pasting section 7.1 revised text. Please see if this makes sense. I will = make the necessary edits. >=20 > =E2=80=9CLarge, long-lived "elephant" flows may affect each other=E2=80=99= s performance or that of smaller, short-lived "mouse" flows when left to = normal per-flow ECMP load-sharing. The host which is originating an = =E2=80=9Celephant=E2=80=9D flow may share its application observations = with a centralized agent by indicating its bandwidth requirements and = the destination for the flow, that enables the latter to keep up-to-date = network bandwidth demand maps for such flows correlated with the actual = utilization of the paths in the network. The end host may receive = updated information from the centralized agent, published via external = mechanisms, of specific paths with their bandwidth availability on which = to steer its flow. > =20 > For example, an application A.1 is informed about an explicit paths to = Z {16006, 16011} which has bandwidth availability such as not to degrade = other flows. The centralized agent may similarly pin =E2=80=9Celephant=E2=80= =9D flows on other disjoint explicit paths. Over a period of time, or = once the =E2=80=9Celephant=E2=80=9D flow is gone (as reported by the = application), then the centralized agent updates the hosts to revert = back to their normal per-flow ECMP based hashing for load-sharing. This = allows for solving the "elephant flow" problem in the data-center and = avoiding link imbalances.=E2=80=9D >=20 > Gaurav >=20 > Sent from my iPhone >=20 > On Oct 18, 2018, at 3:25 AM, Mirja K=C3=BChlewind (IETF) = wrote: >=20 >> Hi Gaurav, >>=20 >> thanks for your edits but unfortunately they don't address my = concerns.=20 >>=20 >> Saying that a flowlet is per 5-tuple is just a clarification of what = a flowlet is but doeen't change anything about what the text says. >>=20 >> Please consider removing section 7 entirely because this is really = beyond the doc of this document and would need further discussion in one = or multiple separate documents. Why is that not an option for the = authors? Why do you think that section 7 is important for this document? >>=20 >> Mirja >>=20 >>=20 >> On 16.10.18 07:45, Gaurav Dawra wrote: >>> Hi MIrja, >>>=20 >>> I have posted a new version. Please do let me know if we need to = discuss further. We can do it over the phone. >>>=20 >>> Cheers, >>>=20 >>> Gaurav >>>=20 >>>=20 >>> On Mon, Sep 3, 2018 at 4:29 AM Gaurav Dawra = wrote: >>> Hi Mirja, >>>=20 >>> Please see inline...[Gaurav2] >>>=20 >>> On Thu, Aug 9, 2018 at 8:30 AM Mirja K=C3=BChlewind = wrote: >>> Hi Gaurav, >>>=20 >>> please see inline. >>>=20 >>> On 03.08.2018 07:20, Gaurav Dawra wrote: >>>> Hey Mirja, >>>>=20 >>>> Sorry for the long delay. I was traveling constantly since IETF and = bit lost in my mailbox and discussion with Authors. Please see my = response inline[Gaurav] >>>>=20 >>>> I think with your changes you addressed explicit problems Martin = called out, however, I still have high level concerns about these = sections as they are mostly giving speculative recommendation which are = not clear to me to work in practice. >>>>=20 >>>> Regarding section 7.1, you say >>>> "A flowlet is defined as a burst of packets from the same flow = followed by an idle interval." >>>> but then you say >>>> "...then the application can break the elephant flow F into = flowlets F1, F2, F3, F4..." >>>>=20 >>>> This sounds like you would just divide an elephant flow mostly = randomly into flowlets which can interact badly with the congestion = control. If you actually have chunks of data that are transmitted with = large enough idle interval in between (as you define flowlets in the = first sentence), that is not an elephant flow anymore and it will not = help you to "spread the load of the elephant flow through all the ECMP = paths". In summary I actually don't see how the concept of flowlets can = be helpful to address the problem you have at all, and I still advise = you to remove section 7.1 entirely. >>>>=20 >>>> [Gaurav] Hi Mirja, Thanks for the review. The proposal here is no = different that current ECMP hashing at flowlet level. The only = difference which is being pointed out here is that if we use SR, we = could leverage on the ability of be aware of multiple disjoint paths = rather than the hashing. It=E2=80=99s pins the flowlets to particular = paths which is basic SR operations. >>>>=20 >>>=20 >>> Yes the problem is that we usually don't recommend ECMP hashing on = flowlet level because it can interact badly with the end-end mechanisms = of that flow. As I said, I don't see how the notion of flowlets help you = problem and therefore I still recommend to remove that paragraph. >>> [Gaurav2] OK. It took sometime to get to consensus with authors. = Will update the text to use 5-tuple flows instead of flowlets. Would = that suffice? I will update the text shortly. >>>>=20 >>>> Regarding section 7.2, I also still skeptical about any benefits = that can be achieved. Given you are in a data center, the controller = should already know about static parameters such as the maximum = bandwidth per link. >>>>=20 >>>> For dynamic parameters, e.g. like loss rate, measuring them on a = per-flow bases is the wrong thing to do. What I mean is you can ask a = router about the average loss rate that it observes and that might give = you some valuable, however, if you ask a TCP flow about the average loss = rate the answer will mainly depend on the = congestion controller used and the currently available bandwidth, which = is a very dynamic property and not a link characteristic. So this = information is not usable for performance aware routing. A flow could = give you information about the observed RTT (min/max) on a certain path, = or the maximum available bandwidth on a path, but as I said, given you = are in a data center environment these are information that the = controller already should have anyway. >>>>=20 >>>> [Gaurav] They are two separate mechanisms. Most DCs have some sort = of data-plane/ECMP aware tracing mechanism to detect the loss/delays and = can be combined with Application back-off to detect issue. All this = section is suggesting is that SR can be used to pin the path to = particular set of ECMP paths instead of relying on ECMP hashing. >>>>=20 >>>=20 >>> This is not quite what the text says. If that is the statement you = want to make, that is fine but then you don't need to talk about = performance aware routing at all. >>> [Gaurav2] I will update the text here with statement i mentioned = above. IMHO, it's performance aware routing wrt to end-host traffic. =20= >>>=20 >>>>=20 >>>> Your example with detecting a faulty path due to losses does not = work with TCP as you never know if these loses are due to a problem on = the path, self-induced or by a competing flow. And even if you don't use = TCP and e.g. send constant bit rate traffic, there may be a large number = of competing TCP flows that can induce the loses. Try to steer traffic = "away" on a time-scale that is slower than TCP dynamics or even your = flow dynamic (when flows start or end) in case you have a lot of very = short flow, in the best case doesn't work and in the worst case leads to = oscillation. >>>>=20 >>>> [Gaurav] As I said above, there are other mechanisms to detect loss = and trace the path on which loss is seen. This is a common mechanism = used in MSDCs. >>>>=20 >>> I think this is beyond the scope of the document.=20 >>> [Gaurav2] Will update the text. >>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> I am happy to discuss further over the phone to try to explain the = thought process. I will also do check again with Authors to update the = text or something else based on our conversation. >>>>=20 >>>=20 >>> Maybe see if some update can be made to the text first and then we = can have another discussion if needed. >>> [Gaurav2] Sounds good. Will update the text shortly and then we can = discuss if needed. >>>=20 >>> Cheers, >>>=20 >>> Gaurav=20 >>>>=20 >>>> =20 >>>>=20 >>>> Cheers, >>>>=20 >>>> =20 >>>>=20 >>>> Gaurav >>>>=20 >>>> If you want to make TCP use for handover situation where one path = might go away or become unusable, it's best to use Multipath TCP (with = coupled congestion control) instead because that works on the right time = scale. Again, I don't think this is a use case for SR and I would = recommend to remove the section entirely. >>>>=20 >>>> Mirja >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra = wrote: >>>> Hi Mirja, >>>>=20 >>>> Ack. Let me work with authors to close ASAP. >>>>=20 >>>> Cheers, >>>>=20 >>>> Gaurav >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Jul 5, 2018, at 10:06 AM, Mirja K=C3=BChlewind = wrote: >>>>=20 >>>>> Hi Gaurav, >>>>>=20 >>>>> sorry for my very long delay but this got somehow a bit lost in my = mailbox. >>>>>=20 >>>>> I think with your changes you addressed explicit problems Martin = called out, however, I still have high level concerns about these = sections as they are mostly giving speculative recommendation which are = not clear to me to work in practice. >>>>>=20 >>>>> Regarding section 7.1, you say >>>>> "A flowlet is defined as a burst of packets from the same flow = followed by an idle interval." >>>>> but then you say >>>>> "...then the application can break the elephant flow F into = flowlets F1, F2, F3, F4..." >>>>>=20 >>>>> This sounds like you would just divide an elephant flow mostly = randomly into flowlets which can interact badly with the congestion = control. If you actually have chunks of data that are transmitted with = large enough idle interval in between (as you define flowlets in the = first sentence), that is not an elephant flow anymore and it will not = help you to "spread the load of the elephant flow through all the ECMP = paths". In summary I actually don't see how the concept of flowlets can = be helpful to address the problem you have at all, and I still advise = you to remove section 7.1 entirely. >>>>>=20 >>>>> Regarding section 7.2, I also still skeptical about any benefits = that can be achieved. Given you are in a data center, the controller = should already know about static parameters such as the maximum = bandwidth per link. For dynamic parameters, e.g. like loss rate, = measuring them on a per-flow bases is the wrong thing to do. What I mean = is you can ask a router about the average loss rate that it observes and = that might give you some valuable, however, if you ask a TCP flow about = the average loss rate the answer will mainly depend on the congestion = controller used and the currently available bandwidth, which is a very = dynamic property and not a link characteristic. So this information is = not usable for performance aware routing. A flow could give you = information about the observed RTT (min/max) on a certain path, or the = maximum available bandwidth on a path, but as I said, given you are in a = data center environment these are information that the controller = already should have anyway. >>>>>=20 >>>>> Your example with detecting a faulty path due to losses does not = work with TCP as you never know if these loses are due to a problem on = the path, self-induced or by a competing flow. And even if you don't use = TCP and e.g. send constant bit rate traffic, there may be a large number = of competing TCP flows that can induce the loses. Try to steer traffic = "away" on a time-scale that is slower than TCP dynamics or even your = flow dynamic (when flows start or end) in case you have a lot of very = short flow, in the best case doesn't work and in the worst case leads to = oscillation. >>>>>=20 >>>>> If you want to make TCP use for handover situation where one path = might go away or become unusable, it's best to use Multipath TCP (with = coupled congestion control) instead because that works on the right time = scale. Again, I don't think this is a use case for SR and I would = recommend to remove the section entirely. >>>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>> On 05.07.2018 04:08, Gaurav Dawra wrote: >>>>>> Hey Alvaro, Mirja,=20 >>>>>>=20 >>>>>> Friendly reminder to further progress this document. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Gaurav >>>>>>=20 >>>>>> On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra = wrote: >>>>>> Hi Alvaro, Mirja=20 >>>>>>=20 >>>>>> Any feedback or next steps to close this? >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Gaurav >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Jun 12, 2018, at 7:06 AM, Gaurav Dawra = wrote: >>>>>>=20 >>>>>>> Hi Mirja, >>>>>>>=20 >>>>>>> Friendly Reminder...Could you please also advice if there is = anything further to DISCUSS on this document which was also related to = TCP updates below? >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Gaurav >>>>>>>=20 >>>>>>> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana = wrote: >>>>>>> Thanks Martin! >>>>>>>=20 >>>>>>> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling = (mls.ietf@gmail.com) wrote: >>>>>>>=20 >>>>>>>> Hi Alvaro, all,=20 >>>>>>>>=20 >>>>>>>> Thanks for addressing my concerns.=20 >>>>>>>>=20 >>>>>>>> This version is good to go from my side.=20 >>>>>>>>=20 >>>>>>>> Kind regards,=20 >>>>>>>>=20 >>>>>>>> ;Martin=20 >>>>>>>>=20 >>>>>>>> Am 30.05.18 um 21:55 schrieb Alvaro Retana:=20 >>>>>>>> > Martin:=20 >>>>>>>> > br/>> Hi!! How are you?=20 >>>>>>>> > br/>> Gaurav just posted a revision. Please takke a look and = let us know if br/>> the changes address your concerrns or not.=20 >>>>>>>> > br/>> = https://www.ietf.org/rfcdiff??url2=3Ddraft-ietf-spring-segment-routing-msd= c-09=20 >>>>>>>> > br/>> Thanks!!!=20 >>>>>>>> > br/>> Alvaro. <=20 >>>>>>>> > br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra = ((gdawra.ietf@gmail.com br/>> ) wrote:=20 >>>>>>>> > br/>>> Hi Martin, <=20 >>>>>>>> >>=20 >>>>>>>> >> Thanks for review. I will post the new version. Hopefully, = it will br/>>> address all your comments and we can close thhis review.=20= >>>>>>>> >>=20 >>>>>>>> >> Any updates on below response?=20 >>>>>>>> >>=20 >>>>>>>> >> Cheers,=20 >>>>>>>> >>=20 >>>>>>>> >> Gaurav=20 >>>>>>>> >>=20 >>>>>>>> >> Sent from my iPhone=20 >>>>>>>> >>=20 >>>>>>>> >> On May 23, 2018, at 4:17 AM, Gaurav Dawra = >> > wrote:=20 >>>>>>>> >>=20 >>>>>>>> >>> Hi Martin,=20 >>>>>>>> >>>=20 >>>>>>>> >>> Thanks for the review. Any further comments here ? I will = post the br/>>>> new version soon. <=20 >>>>>>>> >>>=20 >>>>>>>> >>> Cheers,=20 >>>>>>>> >>>=20 >>>>>>>> >>> Gaurav=20 >>>>>>>> >>>=20 >>>>>>>> >>> Sent from my iPhone=20 >>>>>>>> >>>=20 >>>>>>>> >>> On May 16, 2018, at 7:44 PM, Gaurav Dawra = >>> > wrote:=20= >>>>>>>> >>>=20 >>>>>>>> >>>> Hi Martin,=20 >>>>>>>> >>>>=20 >>>>>>>> >>>> Apologies from my end we had few internal authors = conversations on br/>>>>> the points you have raised. <=20 >>>>>>>> >>>>=20 >>>>>>>> >>>> Please find below my response. I will be happy to discuss = further, br/>>>>> if needed. <=20 >>>>>>>> >>>>=20 >>>>>>>> >>>> inline...=20 >>>>>>>> >>>>=20 >>>>>>>> >>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling = >>>>> > wrote:=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> Hi Gaurav,=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> This got lost on my end, sorry for this. The filter just = moved br/>>>>>> these messages out of my sight... :-/=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:=20 >>>>>>>> >>>>>> Hey Martin,=20 >>>>>>>> >>>>>> Sorry for late reply. Please see some comments = inline[Gaurav]=20 >>>>>>>> >>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling = br/>>>>>>>> = br/>>>>>>>>; > wrote:=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> Hi all,=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> I've reviewed this document as part of the transport = area review br/>>>>>>>> team's ongoing effort to review key IETF = documents. These br/>>>>t;>>>> comments were written primarily for the = transport area directors, br/>>>>>>>> but are copied to the doocument's = authors for their information br/>>>>>>>&> and to allow them to address = any issues raised. When done at the=20 >>>>>>>> >>>>>>> time of IETF Last Call, the authors should consider = this review br/>>>>>>>> together with any other last-call comments they = receive. Please br/>>>&>>>>> always CC tsv-art@=E2=80=A6 if you reply to = or forward this review.=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> Summary:=20 >>>>>>>> >>>>>>> This draft has serious issues in Section 7..1, 7.2 and = in one part br/>>>>>>>> of Secction3, described in the review, and needs = to be rethought. br/>>&>>>>>> The other sections are good AFAIK.=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> Technicals:=20 >>>>>>>> >>>>>>> The overall draft looks ok, but the three points below = look br/>>>>>>>> strange and need a fix before publication IMHO:=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but = not well br/>>>>>>>> proven funcationality and not even safe to use = functionality. br/>>>&>>>>> Both are some sort discussing that different = paths in the network br/>>>>>>>> could be used by the eend host traffic. = This sounds pretty much br/>>>>>>>t;> like the Path Aware Networking = Proposed Research Group br/>>t;>>>>>> (https://irtf.org/panrg) and = hints to the fact that there is no br/>>>>>>>> commonly understannd and = accepted engineering solution in this space.=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> Section 7.1:=20 >>>>>>>> >>>>>>> [KANDULA04] is a really old reference that hasn't been = followed br/>>>>>>>> up iin recent times and even worse there is no = evidence that this br/>>t;>>>>>> is going to work good enough or = stable enough under real Internet br/>>>>>>>> traffic. Additioonally, it = is more than unclear how any modern TCP br/>>>>&ggt;>>> implementation = will react to this=20 >>>>>>>> >>>>>> [Gaurav] Will get back on this.=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> I will reply to the other email dicussing this.=20 >>>>>>>> >>>> I have replied to other thread.=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> Section 7.2:=20 >>>>>>>> >>>>>>> This section describes an idea without detailing too = much about br/>>>>>>>> any furtther aspects. Further it changes the = commonly accepted br/>>>;>>>>> notion of what an end host can do with = the network. At best this br/>>>>>>>> would require a good ddefinition = of what an end host in your br/>>>>>>>&ggt; setting is, e.g., a highly = modified piece of (at least) software=20 >>>>>>>> >>>>>>> that usually not found in OS availble on the market = (yet?)=20 >>>>>>>> >>>>>>> Further communicating instantaneous path = characteristics to a br/>>>>>>>> central point is potentially = a bad idea, as the data = is already br/>>>;>>>>> outdated when reported by any node.=20 >>>>>>>> >>>>>> [Gaurav] I believe Authors are trying to highlight that = Host which br/>>>>>>> is defineed in br/>>>>>>> = (https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) = br/>>>>>>> can innfluence the traffic based on the Calculations locally = or br/>>>t;>>>> jointly with the controller. Implementations can = decide how much br/>>>>>>> Centralized -vs- localized coontrol is = allowed at Host based on br/>>>>>>> perfoormance data collection.=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> Performance data collection (monitoring?) isn't crucial = when it br/>>>>>> comes to timely (actuaally real-time) reaction. = However, this br/>>>>>> secttion isn't just about performance data = collection as it is about br/>>>>>>> "Performance-aware routing" this = seems to try to interact in br/>>>>>> real-time with the network = behhavior of TCP. This isn't even close br/>>>>>> to acceeptable.=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> I would be ok to say that it is useful to collect = performance data br/>>>>>> for offline analysis and improvement of the = data network. However, br/>>>>>&ggt; this is at completely different = magnitues of time scales.=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> I would recommend to remove the TCP part from this = section entirely.=20 >>>>>>>> >>>> Ack, will update in next rev:=20 >>>>>>>> >>>>=20 >>>>>>>> >>>> Section will read like this:=20 >>>>>>>> >>>>=20 >>>>>>>> >>>> ;=20 >>>>>>>> >>>> /Knowing the path associated with flows/packets, the end = host may/=20 >>>>>>>> >>>> /deduce certain characteristics of the path on its own, = and/=20 >>>>>>>> >>>> /additionally use the information supplied with path = information/=20 >>>>>>>> >>>> /pushed from the controller or received via pull request. = The host/=20 >>>>>>>> >>>> /may further share its path observations with the = centralized agent,/=20 >>>>>>>> >>>> /so that the latter may keep up-to-date network health map = to assist/=20 >>>>>>>> >>>> /other hosts with this information./=20 >>>>>>>> >>>> //=20 >>>>>>>> >>>> /For example, an application A.1 at HostA may pin a flow = destined/=20 >>>>>>>> >>>> /to HostZ via Spine node Node5 using label stack {16005, = 16011}. The/=20 >>>>>>>> >>>> /application A.1 may collect information on packet loss, = deduced from/=20 >>>>>>>> >>>> /Other offline mechanisms. [There are some pingMesh = mechanisms which /=20 >>>>>>>> >>>> /Can be used here]/=20 >>>>>>>> >>>> /Through these mechanisms information to a centralized = agent, e.g./=20 >>>>>>>> >>>> /after a flow completes, or periodically for longer lived = flows./=20 >>>>>>>> >>>> /Next, using both local and/or global performance data, = application/=20 >>>>>>>> >>>> /A.1 as well as other applications sharing the same = resources in the/=20 >>>>>>>> >>>> /DC fabric may pick up the best path for the new flow, or = update an/=20 >>>>>>>> >>>> /existing path (e.g.: when informed of congestion on an = existing/=20 >>>>>>>> >>>> /path)./=20 >>>>>>>> >>>> ;=20 >>>>>>>> >>>>=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>>>>=20 >>>>>>>> >>>>>>> Section 3, 3rd bullet point:=20 >>>>>>>> >>>>>>> It is the foundation of TCP that the network is = regarded as a br/>>>>>>>> black box and that you infer from the = transmission of packets br/>>>>;>>>> what the current state of the = network path is. Inferring network br/>>>>>>>> path metrics (you mention = SRTT, MSS, CWND ) is a bad idea, as = br/>>>>>>>>; this would required that all paths = exhibit this and if not what br//>>>>>>>> is going to happen?=20 >>>>>>>> >>>>>>> It could be an interesting research field to change = many points br/>>>>>>>> in TCP'ss behavior, but this once again points = to the fact that br/>>>&>>>>> this not the IETF works but IRTF or = elsewhere.=20 >>>>>>>> >>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP = is rightly br/>>>>>>> treating Network as Black Box. Authors are = implying per path br/>>>>;>>> performance metrics as not cached. Is = there some change in text br/>>>>>>> you are suggesting??=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> I would recommend to remove the 3rd bullet point = completey. TCP br/>>>>>> isn't the place to rememmber "good" or "bad" = paths. This is br/>>>>>> something the network could decide, e.g., = rerouting TCP flows br/>&ggt;>>>> within the network or changing the = forwarding path in the network br/>>>>>> for particular flows (if it is = not routed).=20 >>>>>>>> >>>>=20 >>>>>>>> >>>> Ack, after discussion, we will remove the Section = 3 - 3rd br/>>>>> bullet point. Willl update in next rev - coming = shortly.=20 >>>>>>>> >>>>=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> Kind regards,=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>> Martin=20 >>>>>>>> >>>>>=20 >>>>>>>> >>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Tsv-art mailing list >>>>>>=20 >>>>>> Tsv-art@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tsv-art >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Tsv-art mailing list >>>=20 >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art >>=20 From nobody Mon Oct 29 12:41:40 2018 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 531DB13107B; Mon, 29 Oct 2018 12:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 7w_3nHr100-b; Mon, 29 Oct 2018 12:41:37 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 86B16131074; Mon, 29 Oct 2018 12:41:37 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id r127-v6so6505322oie.3; Mon, 29 Oct 2018 12:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Dtkxh4DSpQl301axXUTYH3gqHaOahOd6SEVTxdTIuN0=; b=EIRSqTT2iR1DgaHBocXUIg2NAWu8D9bDNrJxYh2L0m8htIhpeSDjdVy67ljB2lAfvp Y8/IKNxdizCDDzTiOojzcnCkAde3apgbHlNQ9j/EYN3OKk/9jYodhpH4DM6gFmrYr7i4 O6DKVxB+xJEGl8cJy3lFuH0L5LyxZ8BBdL2wr/3R+OkXEltLd5OZAycbtFgb/z9muK0k BIeGoAEQSRJgkwea9GfBT/xYF6eZbsYPKBRotct3wSGtSWchVWm2G9ZolM2dc05TB6hU 6TpAGWpEXJxc36vFQwj/DlgwBUOWCNhRhEQcOy7XTY64Lnmhwkk0+7KnyR/QoovP30gI z+nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Dtkxh4DSpQl301axXUTYH3gqHaOahOd6SEVTxdTIuN0=; b=NyCKoOO0IEP1FGbKd1ZEtjvpakBeYv+i5Mw0WJSn9CwIp74Zhtx1spcuyjLLn879tv WCCt7+fWTSjafLC07suK4d1uuBBEYFWh2tN4ePH1r83nmbK+51ddbCKsuBjw5gqDpY2e iQs5DjRAQP6dWrkNQfgrw13QE0BqD3ljxGH4YmYFAgnZeH8UmITEZJYVqYwGs7k+NbGR fuJijnNFxKo+NA+VGnq19kFfCIk2wckBbuqEdqcUil8qgxh9M37q/5Ln+HNZlV6mtAad syPSXBh/WJBx5ctl4052fFlQU3RUbSJiwUCCqyaXAVyeV66QaYQfxHcF6R++LcZsfJn/ KlpA== X-Gm-Message-State: AGRZ1gKjjyDW/gGwEpDa7Fpnpk/u3Iu+DzX4G8M79SdWXFBc+f1wtK2b n1nk6HXuVwlr2OnVKBjDvV6vzEuj6ii0cGC6R/o= X-Google-Smtp-Source: AJdET5etwgnOukop4sGR0K5Jlu0BZCUpQHCBC3ZP69yqUv5W73sb8gX37av17z7rur39JWZ4KZTa0ia0+qkDDjkUPE8= X-Received: by 2002:aca:b157:: with SMTP id a84-v6mr9864521oif.289.1540842096757; Mon, 29 Oct 2018 12:41:36 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 29 Oct 2018 15:41:35 -0400 From: Alvaro Retana In-Reply-To: References: <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> <870b223b-5fa7-e5f3-919f-f36521d69d68@kuehlewind.net> X-Mailer: Airmail (527) MIME-Version: 1.0 Date: Mon, 29 Oct 2018 15:41:35 -0400 Message-ID: To: Gaurav Dawra , draft-ietf-spring-segment-routing-msdc@ietf.org Cc: SPRING WG , tsv-art@ietf.org, Martin Stiemerling , "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary="000000000000d5113d0579634109" Archived-At: Subject: Re: [spring] [Tsv-art] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 19:41:39 -0000 --000000000000d5113d0579634109 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF) ( ietf@kuehlewind.net) wrote: Hi! FWIW, I agree with Mirja and her proposal below. Not only does it sound like this Informational document is talking about items that should be out of scope, but the first paragraph in =C2=A77 says that it talks about "how = the problems described above (in section 3) could be solved using the segment routing concept.=E2=80=9D To me, these are examples and (as the text also mentions) "only parts of the solution=E2=80=9D. Let=E2=80=99s please wrap this document up! Thanks! Alvaro. this still sounds very much like inventing a new mechanism which seem a bit out of scope for this document. However, after all bandwidth requirements might not be known or are very dynamic because of congestion control or adaption mechanism in the application (e.g. adaptive video traffic), and therefore there it is still the same problem that it is no reasonable to make decision based on this very dynamic metric. The text below sounds like you are rather interested to a) distinguish elephant from mice flows and b) understand if the elephant flow has a maximum bandwidth cap (because it's application-limited). These are different information and might be more useful for your case. However, I still think having this discussion in this level of details goes beyond the scope of the document. What=E2=80=99s about just saying something like, a central host can collect per-flow information, either from the host directly or measurement on the path, and use this information to impact routing. I would, however, also like to see a note/warning in this context that metrics that are changing very dynamically should not be used as input for routing decisions. --000000000000d5113d0579634109 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On October 29, 2018 at 11:34:13 AM, Mirja Kuehlewind (IETF) (ietf@kuehlewind.net) wrote:

Hi= !

FWIW, I agree with Mirj= a and her proposal below.=C2=A0 Not only does it sound like this Informatio= nal document is talking about items that should be out of scope, but the fi= rst paragraph in =C2=A77 says that it talks about "how the problems de= scribed above (in section 3) could be solved using the segment routing conc= ept.=E2=80=9D =C2=A0To me, these are examples and (as the text also mention= s) "only parts of the solution=E2=80=9D.

=
= Let=E2=80=99s please wrap this document up!

Th= anks!

Alvaro.


this still sounds very much like inventing a new mechanism w= hich seem a bit out of scope for this document. However, after all bandwidt= h requirements might not be known or are very dynamic because of congestion= control or adaption mechanism in the application (e.g. adaptive video traf= fic), and therefore there it is still the same problem that it is no reason= able to make decision based on this very dynamic metric.=C2=A0

The text below sounds like you are rather interested to a) disting= uish elephant from mice flows and b) understand if the elephant flow has a = maximum bandwidth cap (because it's application-limited). These are dif= ferent information and might be more useful for your case. However, I still= think having this discussion in this level of details goes beyond the scop= e of the document.=C2=A0

What=E2=80=99s about just say= ing something like, a central host can collect per-flow information, either= from the host directly or measurement on the path, and use this informatio= n to impact routing. I would, however, also like to see a note/warning in t= his context that metrics that are changing very dynamically should not be u= sed as input for routing decisions.= =C2=A0
<= /blockquote>
--000000000000d5113d0579634109-- From nobody Tue Oct 30 00:47:26 2018 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 CB91E128CF3 for ; Tue, 30 Oct 2018 00:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Cj_Zx_iRB5bx for ; Tue, 30 Oct 2018 00:47:23 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 73FDD128CE4 for ; Tue, 30 Oct 2018 00:47:23 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7FE96D171478B for ; Tue, 30 Oct 2018 07:47:19 +0000 (GMT) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 30 Oct 2018 07:47:20 +0000 Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.190]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0415.000; Tue, 30 Oct 2018 15:47:12 +0800 From: Mach Chen To: spring Thread-Topic: Path Segment draft updates//FW: New Version Notification for draft-cheng-spring-mpls-path-segment-03.txt Thread-Index: AdRwIinkwMF8a+fSSgiRxN/R+UEk/w== Date: Tue, 30 Oct 2018 07:47:12 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] Path Segment draft updates//FW: New Version Notification for draft-cheng-spring-mpls-path-segment-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 07:47:26 -0000 SGksDQoNClRoaXMgdmVyc2lvbiAodmVyaXNvbi0wMykgYWRkcmVzc2VzIHRoZSBjb21tZW50cyBy ZWNlaXZlZCBzbyBmYXIsIHRoZSB1cGRhdGVzIGluY2x1ZGU6DQoNCjEuIEFjY29yZGluZyB0byB0 aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zLCB0aGVyZSB3YXMgcHJlZmVyZW5jZSB0byB0aGUg Im9uZSBsYWJlbCIgb3B0aW9uIGZvciBTUiBwYXRoIGlkZW50aWZpY2F0aW9uLCBoZW5jZSwgIHRo ZSAidHdvIGxhYmVsIiBvcHRpb24gaXMgcmVtb3ZlZDsgDQoyLiBBY2NvcmRpbmcgdG8gdGhlIHN1 Z2dlc3Rpb24gZnJvbSBTYXNoYSwgYWRkIGEgbmV3IHNlY3Rpb24gdG8gc3VwcG9ydCAiTmVzdGlu ZyBvZiBQYXRoIFNlZ21lbnQiLCBieSB1c2luZyBCaW5kaW5nIFNJRCwgaXQgY2FuIG5vdCBvbmx5 IHJlZHVjZSBkZXB0aCBvZiB0aGUgbGFiZWwgc3RhY2ssIGJ1dCBzdXBwb3J0IGJvdGggc3ViLXBh dGggYW5kIGVuZC10by1lbmQgcGF0aCBtb25pdG9yaW5nOyANCjMuIE1hbnkgZWRpdG9yaWFsIGNo YW5nZXM7DQoNCkFkZGl0aW9uYWwgcmV2aWV3IGFuZCBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQN Cg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE5LCAyMDE4IDk6NTYgQU0NCj4gVG86 IFJha2VzaCBHYW5kaGkgPHJnYW5kaGlAY2lzY28uY29tPjsgV2VpcWlhbmcgQ2hlbmcNCj4gPGNo ZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPjsgTGVpIFdhbmcNCj4gPHdhbmdsZWl5akBjaGlu YW1vYmlsZS5jb20+OyBSb3lpIFppZ2xlciA8cm95aS56aWdsZXJAYnJvYWRjb20uY29tPjsNCj4g U2h1YW5ncGluZyBaaGFuIDx6aGFuLnNodWFuZ3BpbmdAenRlLmNvbS5jbj47IE1hY2ggQ2hlbg0K PiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+OyBIYW4gTGkgPGxpaGFuQGNoaW5hbW9iaWxlLmNvbT47 IE1hY2ggQ2hlbg0KPiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+DQo+IFN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hlbmctc3ByaW5nLW1wbHMtcGF0aC0NCj4gc2Vn bWVudC0wMy50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2hlbmct c3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50LTAzLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IE1hY2goR3VveWkpIENoZW4gYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiBy ZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2Vn bWVudA0KPiBSZXZpc2lvbjoJMDMNCj4gVGl0bGU6CQlQYXRoIFNlZ21lbnQgaW4gTVBMUyBCYXNl ZCBTZWdtZW50IFJvdXRpbmcgTmV0d29yaw0KPiBEb2N1bWVudCBkYXRlOgkyMDE4LTEwLTE2DQo+ IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTENCj4gVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVuZy1z cHJpbmctbXBscy0NCj4gcGF0aC1zZWdtZW50LTAzLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbmctc3ByaW5nLW1wbHMtcGF0 aC0NCj4gc2VnbWVudC8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1jaGVuZy1zcHJpbmctbXBscy1wYXRoLQ0KPiBzZWdtZW50LTAzDQo+IEh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWNo ZW5nLXNwcmluZy1tcGxzLQ0KPiBwYXRoLXNlZ21lbnQNCj4gRGlmZjogICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jaGVuZy1zcHJpbmctbXBscy1wYXRo LQ0KPiBzZWdtZW50LTAzDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgQSBTZWdtZW50IFJvdXRpbmcg KFNSKSBwYXRoIGlzIGlkZW50aWZpZWQgYnkgYW4gU1Igc2VnbWVudCBsaXN0LCBvbmUNCj4gICAg b3IgcGFydGlhbCBzZWdtZW50cyBvZiB0aGUgbGlzdCBjYW5ub3QgdW5pcXVlbHkgaWRlbnRpZnkg dGhlIFNSIHBhdGguDQo+ICAgIFBhdGggaWRlbnRpZmljYXRpb24gaXMgYSBwcmUtcmVxdWlzaXRl IGZvciB2YXJpb3VzIHVzZS1jYXNlcyBzdWNoIGFzDQo+ICAgIHBlcmZvcm1hbmNlIG1lYXN1cmVt ZW50IChQTSkgb2YgYW4gU1IgcGF0aC4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IG5ldyB0eXBlIG9mIHNlZ21lbnQgdGhhdCBpcyByZWZlcnJlZCB0byBhcw0KPiAgICBQYXRoIFNl Z21lbnQsIHdoaWNoIGlzIHVzZWQgdG8gaWRlbnRpZnkgYW4gU1IgcGF0aC4gIFdoZW4gdXNlZCwg aXQgaXMNCj4gICAgaW5zZXJ0ZWQgYXQgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgcGF0aCBh bmQgaW1tZWRpYXRlbHkgZm9sbG93cw0KPiAgICB0aGUgbGFzdCBzZWdtZW50IG9mIHRoZSBTUiBw YXRoLiAgVGhlIFBhdGggU2VnbWVudCB3aWxsIG5vdCBiZSBwb3BwZWQNCj4gICAgb2ZmIHVudGls IGl0IHJlYWNoZXMgdGhlIGVncmVzcyBub2RlIG9mIHRoZSBTUiBwYXRoLg0KPiANCj4gICAgUGF0 aCBTZWdtZW50IGNhbiBiZSB1c2VkIGJ5IHRoZSBlZ3Jlc3Mgbm9kZSB0byBpbXBsZW1lbnQgcGF0 aA0KPiAgICBpZGVudGlmaWNhdGlvbiBoZW5jZSB0byBzdXBwb3J0IHZhcmlvdXMgdXNlLWNhc2Vz IGluY2x1ZGluZyBTUiBwYXRoDQo+ICAgIFBNLCBlbmQtdG8tZW5kIDErMSBTUiBwYXRoIHByb3Rl Y3Rpb24gYW5kIGJpZGlyZWN0aW9uYWwgU1IgcGF0aHMNCj4gICAgY29ycmVsYXRpb24uDQo+IA0K PiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Oct 30 03:27:18 2018 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 853BF128DFD; Tue, 30 Oct 2018 03:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 cXgyYl7gU8o2; Tue, 30 Oct 2018 03:27:08 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.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 9CE7D124BAA; Tue, 30 Oct 2018 03:27:05 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 42knhR6MzQz205g; Tue, 30 Oct 2018 11:27:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 42knhR5WLPzDq82; Tue, 30 Oct 2018 11:27:03 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0415.000; Tue, 30 Oct 2018 11:27:03 +0100 From: To: Ladislav Lhotka , "draft-ietf-spring-sr-yang.all@ietf.org" CC: "spring@ietf.org" , "ietf@ietf.org" , "yang-doctors@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-spring-sr-yang-09 Thread-Index: AQHUa244CJ+3M1qqBUWqCZ85llkyV6U3nrbQ Date: Tue, 30 Oct 2018 10:27:03 +0000 Message-ID: <27687_1540895223_5BD831F7_27687_135_1_53C29892C857584299CBF5D05346208A47F738E5@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <154036725541.6830.14208644072725478318@ietfa.amsl.com> In-Reply-To: <154036725541.6830.14208644072725478318@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Yangdoctors early review of draft-ietf-spring-sr-yang-09 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 10:27:11 -0000 TGFkaXNsYXYsDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcsIGVzcGVjaWFsbHkgb24gYSBz aG9ydCBub3RpY2UgYmVmb3JlIHRoZSBJRVRGIG1lZXRpbmcuDQoNCkF1dGhvcnMsDQoNCkNvdWxk IGZvbGxvdyB1cCBvbiB0aG9zZSBjb21tZW50cyBhbmQgcmVwbHkgdG8gTGFkaXNsYXYnIGVtYWls Pw0KDQpUaGFua3MsDQotLUJydW5vDQoNCiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQog PiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAbmljLmN6XQ0KID4gU2VudDog V2VkbmVzZGF5LCBPY3RvYmVyIDI0LCAyMDE4IDk6NDggQU0NCiA+IFRvOiB5YW5nLWRvY3RvcnNA aWV0Zi5vcmcNCiA+IENjOiBzcHJpbmdAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtc3ByaW5nLXNyLXlhbmcuYWxsQGlldGYub3JnDQogPiBTdWJqZWN0OiBZYW5nZG9jdG9ycyBl YXJseSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy0wOQ0KID4gDQogPiBSZXZp ZXdlcjogTGFkaXNsYXYgTGhvdGthDQogPiBSZXZpZXcgcmVzdWx0OiBPbiB0aGUgUmlnaHQgVHJh Y2sNCiA+IA0KID4gKioqIEdlbmVyYWwgY29tbWVudHMNCiA+IA0KID4gICAgIFRoaXMgZG9jdW1l bnQgY29udGFpbnMgdHdvIFlBTkcgbW9kdWxlczoNCiA+ICAgICBpZXRmLXNlZ21lbnQtcm91dGlu Zy1jb21tb24gYW5kIGlldGYtc2VnbWVudC1yb3V0aW5nLiBUaGUgbGF0dGVyDQogPiAgICAgYXVn bWVudHMgaWV0Zi1yb3V0aW5nIHdpdGggZGF0YSBuZWNlc3NhcnkgZm9yIGNvbmZpZ3VyaW5nIGFu ZA0KID4gICAgIG9wZXJhdGluZyBzZWdtZW50IHJvdXRpbmcsIGJ1dCBhbHNvIHByb3ZpZGVzIGdy b3VwaW5ncyB0aGF0IGRlZmluZQ0KID4gICAgIGRhdGEgdG8gYmUgdXNlZCBpbiBzZWdtZW50IHJv dXRpbmcgZXh0ZW5zaW9ucyBvZiByb3V0aW5nIHByb3RvY29scw0KID4gICAgIGFuZCBpbnRlcmZh Y2VzLiBUaGlzIGRlc2lnbiBtYWtlcyBpdCByZWxhdGl2ZWx5IGVhc3kgdG8gZGVmaW5lDQogPiAg ICAgc3VjaCBJR1AgZXh0ZW5zaW9ucy4NCiA+IA0KID4gKioqKiBOYW1pbmcNCiA+IA0KID4gICAg ICAtIE15IHN1Z2dlc3Rpb24gaXMgdG8gcmV2aWV3IHRoZSBpZGVudGlmaWVycyBkZWZpbmVkIGlu IHRoZQ0KID4gICAgICAgIG1vZHVsZXMgc28gYXMgdG8gYWRoZXJlIG1vcmUgY2xvc2VseSB0byB0 aGUgaWRlbnRpZmllciBuYW1pbmcNCiA+ICAgICAgICBjb252ZW50aW9ucyBpbiBzZWMuIDQuMy4x IG9mIFJGQyA4NDA3LiBJdCBpcyBzdWJqZWN0aXZlIHRvDQogPiAgICAgICAgZGVjaWRlIHdoaWNo IGFjcm9ueW1zIGFyZSB3ZWxsLWtub3duIGJ1dCwgaW4gbXkgdmlldywgInNyZ2IiLA0KID4gICAg ICAgICJzcmxiIiBhbmQgIm1zZCIgZG8gbm90IGZhbGwgaW50byB0aGlzIGNhdGVnb3J5LiBGb3Ig ZXhhbXBsZSwNCiA+ICAgICAgICAibXNkIiBjYW4gYmUgY2hhbmdlZCB0byB0byAibWF4LXNpZC1k ZXB0aCIgKGJvdGggYXMgYSBkYXRhIG5vZGUNCiA+ICAgICAgICBhbmQgYSBmZWF0dXJlKS4NCiA+ ICAgICAgLSBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlICItY2ZnIiBzdWZmaXggaW4gdGhlIG5hbWVz IG9mIHNldmVyYWwNCiA+ICAgICAgICBncm91cGluZ3Mgc2hvdWxkIGJlIHJlbW92ZWQgLSBhY2Nv cmRpbmcgdG8gUkZDIDg0MDcsDQogPiAgICAgICAgaWRlbnRpZmllcnMgc2hvdWxkIG5vdCBjYXJy eSBzZW1hbnRpY3MuIChBbmQgcGVyaGFwcyB0aGUNCiA+ICAgICAgICBzYW1lIGdyb3VwaW5ncyBj YW4gYWxzbyBiZSB1c2VkIGZvciBzdGF0ZSBkYXRhPykNCiA+IA0KID4gKioqKiBSZXZpc2lvbnMN CiA+IA0KID4gICAgICBUaGUgWUFORyBtb2R1bGVzIGNvbnRhaW4gcmV2aXNpb24gZGF0ZXMgb2Yg YWxsIGRldmVsb3BtZW50DQogPiAgICAgIHZlcnNpb25zLiBBbHRob3VnaCBSRkMgODQwNyBkb2Vz bid0IHJlcXVpcmUgdG8gZG8gc28sIEkgdGhpbmsgaXQNCiA+ICAgICAgY2FuIGJlIHVzZWZ1bCBm b3IgdGhlIGRldmVsb3BtbmVudCBhbmQgdGVzdGluZyBvZiB0aGUNCiA+ICAgICAgbW9kdWxlcy4g SG93ZXZlciwgdGhlc2UgZGV2ZWxvcG1lbnQgcmV2aXNpb25zIHNob3VsZCBiZSByZW1vdmVkDQog PiAgICAgIGJlZm9yZSBwdWJsaXNoaW5nIHRoZSBSRkMgKG1heWJlIHRoZSBhdXRob3JzIGludGVu ZCB0byBkbyBzbykuDQogPiANCiA+ICoqKiogUmVmZXJlbmNlcw0KID4gDQogPiAgICAgIE5vcm1h dGl2ZSBSZWZlcmVuY2VzIHNob3VsZCBpbmNsdWRlIHRoZSBSRkNzIGRlZmluaW5nIFlBTkcNCiA+ ICAgICAgbW9kdWxlcyB0aGF0IGFyZSBpbXBvcnRlZCBieSB0aGUgc2VnbWVudC1yb3V0aW5nIG1v ZHVsZXM6IDY5OTEsDQogPiAgICAgIDcyMjMsIDgyOTQgYW5kIDgzNDkuDQogPiANCiA+ICoqKiBT cGVjaWZpYyBjb21tZW50cw0KID4gDQogPiAgICAgLSBDb250YWluZXJzICJjb25uZWN0ZWQtcHJl Zml4LXNpZC1tYXAiIGFuZCAibG9jYWwtcHJlZml4LXNpZCINCiA+ICAgICAgIGhhdmUgc3ViY29u dGFpbmVycyAiaXB2NCIgYW5kICJpcHY2IiB0aGF0IG9ubHkgZGlmZmVyIGluIHRoZQ0KID4gICAg ICAgdHlwZSBvZiB0aGUgInByZWZpeCIgbGVhZi4gQW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gY2Fu IGJlIHRvDQogPiAgICAgICBjaGFuZ2UgdGhlIG91dGVyIGNvbnRhaW5lcnMgaW50byBsaXN0cyB3 aXRoICJhZGRyZXNzLWZhbWlseSIgYXMNCiA+ICAgICAgIHRoZSBrZXkuIERpZCB0aGUgYXV0aG9y cyBkaXNjdXNzIHRoaXMgb3B0aW9uPw0KID4gDQogPiAgICAgLSBUaGUgdGV4dCB1c2VzIHRoZSB0 ZXJtcyAic3RhdGVzIiBhbmQgIm9wZXJhdGlvbmFsIHN0YXRlcyIgaW4NCiA+ICAgICAgIHNldmVy YWwgcGxhY2VzLiBUaGUgcGx1cmFsIGZvcm0gbG9va3Mgd2VpcmQgdG8gbWUuDQogPiANCg0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Oct 30 03:54:38 2018 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 D4395130DC4; Tue, 30 Oct 2018 03:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 l-U2Yls9-AOD; Tue, 30 Oct 2018 03:54:22 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCF2130DD7; Tue, 30 Oct 2018 03:54:21 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 42kpHv6KBxz8ttW; Tue, 30 Oct 2018 11:54:19 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 42kpHv59whz2xCX; Tue, 30 Oct 2018 11:54:19 +0100 (CET) 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.0415.000; Tue, 30 Oct 2018 11:54:19 +0100 From: To: Ahmed Bashandy , "draft-ietf-spring-segment-routing-mpls@ietf.org" CC: SPRING WG List Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Thread-Index: AQHUbjyfU9R84Bl2U0W1RDYxFft7laU3n5OQ Date: Tue, 30 Oct 2018 10:54:18 +0000 Message-ID: <19896_1540896859_5BD8385B_19896_388_1_53C29892C857584299CBF5D05346208A47F73954@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> <13758_1527183609_5B06F8F9_13758_220_1_53C29892C857584299CBF5D05346208A47A53780@OPEXCLILM21.corporate.adroot.infra.ftgroup> <00239620-318d-d9cc-f1b2-f03f8a6ea160@gmail.com> In-Reply-To: <00239620-318d-d9cc-f1b2-f03f8a6ea160@gmail.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.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47F73954OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 10:54:37 -0000 --_000_53C29892C857584299CBF5D05346208A47F73954OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Ahmed. This addresses my comments. --Bruno From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] Sent: Saturday, October 27, 2018 11:33 PM To: DECRAENE Bruno TGI/OLN; draft-ietf-spring-segment-routing-mpls@ietf.org Cc: SPRING WG List Subject: Re: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 I uploaded version 15 on Oct/23 to address comments. Thanks a lot for the comments See my reply "#Ahmed" On 5/24/18 10:40 AM, bruno.decraene@orange.com wrote: Hi authors, I've reviewed the document. It looks good, thanks for your effort. Please find below some comments, nothing major. Thanks for considering them as part of the WG LC. Thanks, Regards, Bruno --- Somewhere in Abstract/1. Introduction/2. MPLS Instantiation of Segment Rout= ing MPLS Instantiation of Segment Routing is sometimes referred to with two dif= ferent names: MPLS-SR or SR-MPLS which seems sub-optimal. [I.D.-ietf-spring-segment-routing] uses the term SR-MPLS. May this term sho= uld also be used at least once in this document. --- =A72.2 "using the SRGB of the node" Please expand SRGB on first used. (in -13, this term is expand on =A72.3 wh= ich is after) #Ahmed: Done --- =A72.3 OLD: Just like SRGB, the SRLB need not be a single contiguous range of label, except the SRGB MUST only be used to instantiate global SIDs into the MPLS forwarding plane. NEW: Just like SRGB, the SRLB need not be a single contiguous range of label. (simplify the sentence. The rule is already stated before in this section) #Ahmed: I used a more general (and IMO more precise) wording --- [SRLB] "Hence it is specified the same way and follows the same rules SRGB is specified above in this sub-section." Sentence is not crystal clear and could probably be rephrased. More importantly, the sentence is incorrect: the SRLB does not follow the l= ast SRGB rules ( "The list of label ranges MUST only be used to instantiate= global SIDs into the MPLS forwarding plane") #Ahmed: I used a more general (and IMO more precise) wording ------ =A72.4 "0 =3D< I < size." "size =3D Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1" Algorithm looks good to me. Yet starting the index at 0 for SID index, and = 1 for SRGB sub-blocks may be slightly misleading. "Lh(1)- Ll(1)" seems only= defined in this document so an option would be to start with "Lh(0)- Ll(0)= " (this would impact the algo: :s/j =3D 1/ j =3D 0) Up to you. #Ahmed: I left it as it is :) ------ =A72.5 OLD: MPLS Incoming Label MAP NEW: MPLS Incoming Label Map #Ahmed: Corrected (as per https://tools.ietf.org/html/rfc3031#section-3.11 ) -- OLD: o (Endpoint, Color) representing an SR policy [I.D. filsfils-spring-s= egment-routing-policy] NEW: o an SR policy [I.D.-ietf-spring-segment-routing] (Otherwise, this would likely require a _Normative_ reference to I.D. filsf= ils-spring-segment-routing-policy which would significantly delay the RFC p= ublication of this document. While [I.D.-ietf-spring-segment-routing is alr= eady in the RFC editor queue and does define a SR policy. ) #Ahmed: This has become rfc8402. I overlooked this one and I will make it r= efer to rfc8402 in version 16 -- OLD: o (Prefix, Routing Instance, Topology, Algorithm), where a topology is identified by a set of links with metrics. For the purpose of incoming label collision resolution, the same numerical value SHOULD be used on all routers to identify the same set of links with metrics. (It's not crystal clear what "numerical value" refers to, given the list (P= refix, Routing Instance, Topology, Algorithm)) NEW1: o (Prefix, Routing Instance, Topology, Algorithm), where a topology is identified by a set of links with metrics. For the purpose of incoming label collision resolution, the same Topology numerical value SHOULD be used on all routers to identify the same set of links with metrics. #Ahmed: I used this wording (thanks) NEW2: o (Prefix, Routing Instance, Topology, Algorithm). A Topology identifies a set of links with metrics. For the purpose of incoming label collision resolution, the same Topology numerical value SHOULD be used on all routers to identify the same set of links with metrics. ----- =A72.5.1 " o All addresses are represented in 128 bits as follows . IPv6 address is encoded natively . IPv4 address is encoded in the most significant bits and the remaining bits are set to zero o All prefixes are represented by 128. . A prefix is encoded in the most significant bits and the remaining bits are set to zero. . The prefix length is encoded before the prefix" "All prefixes are represented by 128." 128 what? Could be bits, but this does not fit with the addition of the pre= fix length. "The prefix length is encoded before the prefix" using a field of what size? #Ahmed: I corrected this to be (128+8) Do we (really) need 2 different encodings for prefix and address? Especiall= y since the rest of the algorithm does not make the difference: "o Encode the remaining set of FECs as follows o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology)" #Ahmed: It is just that conceptually an address and a prefix are different = and they are usually handled quite differently by routing protocols --- =A72.5.2. Redistribution between Routing Protocol Instances " o If the receiving instance's SRGB is the same as the SRGB of origin instance, THEN o the index is redistributed with the route o Else o the index is not redistributed and if needed it is the duty of the receiving instance to allocate a fresh index relative to its own SRGB" With a strict interpretation of this rule, when one increases the size of t= he SRGB, all indexes from redistributed prefixes will be withdrawn because = it's unlikely that we can guaranty that the change of both SRGB be atomic. Could this be accommodated? e.g. by only using the SRBG below the index ? i= .e SRGB [0;index] or just the mapped label in both SRGB? #Ahmed: I think this is a very fine corner case. But I am open to any sugge= stion --- =A72.6 OLD: In the general case, the ingress node may not have exactly have the same data of the receiving node, so the result may be different. NEW: In the general case, the ingress node may not have exactly the same data of the receiving node, so the result may be different. #Ahmed: I used that wording ---- =A72.10 OLD This document covers the calculation of outgoing label for the top label only. The case where outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic engineering tunnel is covered in other documents such as [I.D.filsfils-spring-segment-routing-policy]. This may be understood as requiring a _normative_ reference for [I.D.filsfi= ls-spring-segment-routing-policy], which would significantly delay the RFC = publication of this document. Proposed NEW1: This document covers the calculation of outgoing label for the top label only. Other cases are out of scope of this document. Or NEW2: This document covers the calculation of outgoing label for the top label only. The case where outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic engineering tunnel is out of scope of this document. #Ahmed: I changed the wording a little bit such that [I.D.filsfils-spring-s= egment-routing-policy] is an example -- =A72.10.1 " Suppose an MCC on a router "R0" determines that PUSH or CONTINUE operation is to be applied to an incoming packet whose active SID is the global SID "Si" ..." My undertanding is that "whose" in "whose active SID" refers to the the "i= ncoming packet". This seems to imply that the incoming packet is (already) = labeled. - This does not match the example used in the following paregraph, where th= e incoming packet is IP. "An example of a method to determine the SID "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis- segment-routing-extensions] receives the prefix-SID "Si" sub-TLV advertised with prefix "P/m" in TLV 135 and the destination address of the incoming IPv4 packet is covered by the prefix "P/m"." - Also, you can't simply perform a PUSH on a received label packet. You fi= rst need to POP or SWAP the incoming label. May be proposed NEW: Suppose an MCC on a router "R0" determines that a PUSH or CONTINUE operation is to be applied to an incoming packet, related to the global = SID "Si" ... #Ahmed: Modified the text as suggested ----- =A72.10.1 OLD: If the neighbor "N" does not support SR or "I" does not satisfy the inequality specified in Section 2.4 for the SRGB of the neighbor "N" May be a more generic sentence: NEW If the neighbor "N" does not support SR or advertises a SRGB invalid = or too small, #Ahmed: Modified as suggested ----- =A72.10.1 OLD: o If it is possible to send the packet towards the neighbor "N" using standard MPLS forwarding behavior as specified in {RFC3031] and [RFC3032], then forward the packet. The method by which a router decides whether it is possible to send the packet to "N" or not is beyond the scope of this document. For example, the router "R0" can use the downstream label determined by another MCC, such as LDP [RFC5036], to send the packet. The fall back to LDP seems like a mandated behavior. If so, the behavior se= ems under-specified. In particular "out of scope of this document" does not= seem like a valid argument. #Ahmed: In general LDP is not mandated. The statement says use MPLS. How an= d what protocol is used to determine what to do with the incoming label(s) = (if any) and what is (are) the outgoing label(s) is totally outside the sco= pe of this document. Possible NEW: " o If this neighbor "N" advertises a valid label for the same FEC vi= a another MCC (e.g. LDP [RFC5036]), then forward the packet to N, using the= label advertised by this MCC. ---- 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for Local S= IDs "A local SID on a router "R0" corresponds to a local label such as an IGP adj-SID. In such scenario, the outgoing label towards a next-hop "N" is determined by the MCC running on the router "R0"and the forwarding behavior for CONTINUE operation is identical to swap operation [RFC3032] on an MPLS label" I'm not seeing a case where an IGP adj-SID would have "CONTINUE" as a forwa= rding behavior. And the SR architecture requires a NEXT operation: " When a node binds an Adj-SID to a local data-link L, the node MUST install the following FIB entry: Incoming Active Segment: V Ingress Operation: NEXT Egress Interface: L" https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.4 A solution would be to simply remove "such as an IGP adj-SID" #Ahmed: I agree and I removed adj-SID --- =A73 IGP Segment examples This section, also useful, is quite long and not normative for this STD tra= ck doc. An option may be to move it to appendix. Up to you. #Ahmed: Agreed and moved to appendix --- =A73.1 "R2 is the next-hop along the shortest path towards R8. By applying the steps in Section 2.8 the local label downloaded to R1's FIB corresponding to the global SID index 8 is 1008 because the SRGB of R2 is [1000,5000] as shown in Figure 2." may be OLD: local label downloaded to R1's FIB NEW: local outgoing label downloaded to R1's FIB (because I would assume that by default, label downloaded in the FIB is pr= obably the incomig label one) #Ahmed Changed "local" to "outgoing" -- OLD: owned by the R8 NEW1: OLD: owned by R8 NEW2: OLD: owned by the node R8 #Ahmed: Done -- "The packet arrives at router R2. Because the top label 1008 corresponds to the IGP SID "8", which is the prefix-SID attached to the prefix 192.0.2.8/32 owned by the R8, then the instruction associated with the SID is "forward the packet using all ECMP/UCMP interfaces and all ECMP/UCMP next-hop(s) along the shortest path towards R8". " IGP prefix-SID are typically forwarded along the ECMP shortest path. I'm no= t sure where "UCMP" is coming from. Also "along the shortest path" seems to= be incompatible with UCMP. #Ahmed: I changed the wording to "shortest/useable" -- "Because R3 is the penultimate hop, R3 applies NEXT operation then sends the packet to R8." "penultimate hop" is a required but not sufficient reason. You are assum= ing that R8 asked for PHP, but I'm not seeing this assumption stated in the= text. #Ahmed: I changed to wording to use "assume" --- "The NEXT operation results in popping the outer label and sending the packet as a pure IPv4 packet to R8. The In conclusion, " OLD: The NEW: #Ahmed: In many places, I refer to each operation using "the". --- =A73.2 & =A73.3 & =A73.4 & =A73.5 " Using the calculation techniques specified in Section 2.10 and 2.11 the resulting label stack starting from the topmost label is <1002, 9001, 1008>." Actually section 2.10 only defines the calculation technique for the top la= bel: "This document covers the calculation of outgoing label for the top label only. The case where outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic engineering tunnel is covered in other documents such as [I.D.filsfils-spring-segment-routing-policy]." https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13#se= ction-2.10 Hence this document does not define the behavior for this example 2. You= would need to either extend this doc to cover the push of a stack of label= /SID or remove these examples 2, 3, 4, 5 #Ahmed Done ---- [RFC8174] to be added to normative references. #Ahmed: Done From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, May 24, 2018 7:14 PM To: SPRING WG List Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hello Working Group, This email starts a Working Group Last Call on draft-ietf-spring-segment-ro= uting-mpls-13 [1] which is considered mature and ready for a final working = group review. Please read this document if you haven't read the most recent version yet, = and send your comments to the list, no later than *June 08*. As a reminder, this document had already passed a WGLC more than a year ago= on version -06 [2], had been sent to the AD but then returned to the WG. Since then, the document has significantly changed, so please read it again= . In particular, it now includes the resolution in case of incoming label c= ollision. Hence it killed draft-ietf-spring-conflict-resolution. Both co-chairs co-author this document, hence: - Shraddha has agreed to be the document shepherd. Thank you Shraddha. - Martin, our AD, has agreed to evaluate the WG consensus. Thank you, Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 [2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A47F73954OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Ahmed.

This addresses my comments.

 

--Bruno

 

From: A= hmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Saturday, October 27, 2018 11:33 PM
To: DECRAENE Bruno TGI/OLN; draft-ietf-spring-segment-routing-mpls@i= etf.org
Cc: SPRING WG List
Subject: Re: WG Last Call for draft-ietf-spring-segment-routing-mpls= -13

 

I uploaded version 15 on Oct/23 to address comments.

Thanks a lot for the comments

See my reply "#Ahmed"

 

On 5/24/18 10:40 AM, bruno.decraene@orange.com wrote:

Hi authors,

 

I’ve reviewed the do= cument.

It looks good, thanks for = your effort.

 

Please find below some com= ments, nothing major.

Thanks for considering the= m as part of the WG LC.

 

Thanks,<= /p>

Regards,=

Bruno

 

---

Somewhere in Abstract/1. I= ntroduction/2. MPLS Instantiation of Segment Routing

 

MPLS Instantiation of Segm= ent Routing is sometimes referred to with two different names: MPLS-SR or S= R-MPLS which seems sub-optimal.

[I.D.-ietf-spring-segment-= routing] uses the term SR-MPLS. May this term should also be used at least = once in this document.

 

---

=A72.2

"using the SRGB of th= e node"

Please expand SRGB on firs= t used. (in -13, this term is expand on =A72.3 which is after)<= /o:p>

 

#Ahmed: Done=

---

=A72.3

OLD: Just like SRGB, the S= RLB need not be a single

   contiguous ra= nge of label, except the SRGB MUST only be used to

   instantiate g= lobal SIDs into the MPLS forwarding plane.

 

NEW:

Just like SRGB, the SRLB n= eed not be a single

   contiguous ra= nge of label.

  

(simplify the sentence. Th= e rule is already stated before in this section)

#Ahmed: I us= ed a more general (and IMO more precise) wording

 

---

[SRLB]

"Hence it is

   specified the= same way and follows the same rules SRGB is specified

   above in this= sub-section."

 

Sentence is not crystal cl= ear and could probably be rephrased.

More importantly, the sent= ence is incorrect: the SRLB does not follow the last SRGB rules ( "The= list of label ranges MUST only be used to instantiate global SIDs into the MPLS forwarding plane")

#Ahmed: I us= ed a more general (and IMO more precise) wording

 

------

=A72.4

 

"0 =3D< I < siz= e."

"size =3D Lh(1)- Ll(1= ) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1&q= uot;

 

Algorithm looks good to me= . Yet starting the index at 0 for SID index, and 1 for SRGB sub-blocks may = be slightly misleading. "Lh(1)- Ll(1)" seems only defined in this document so an option would be to start with "Lh(0)- Ll(0)&qu= ot; (this would impact the algo: :s/j =3D 1/ j =3D 0)

Up to you.

#Ahmed: I le= ft it as it is :)

 

------

=A72.5

 

OLD: MPLS Incoming Label M= AP

NEW: MPLS Incoming Label M= ap

#Ahmed: Corr= ected

 

(as per https://tools.= ietf.org/html/rfc3031#section-3.11 )

--

OLD: o  (Endpoint, Co= lor) representing an SR policy [I.D. filsfils-spring-segment-routing-policy= ]

NEW: o  an SR policy = [I.D.-ietf-spring-segment-routing]

 

(Otherwise, this would lik= ely require a _Normative_ reference to I.D. filsfils-spring-segment-routing= -policy which would significantly delay the RFC publication of this document. While [I.D.-ietf-spring-segment-routing is already in th= e RFC editor queue and does define a SR policy. )

#Ahmed: This= has become rfc8402. I overlooked this one and I will make it refer to rfc8= 402 in version 16

 

--

OLD:

 

   o  (Pref= ix, Routing Instance, Topology, Algorithm), where a topology

    &n= bsp; is identified by a set of links with metrics. For the purpose of

    &n= bsp; incoming label collision resolution, the same numerical value

    &n= bsp; SHOULD be used on all routers to identify the same set of links=

    &n= bsp; with metrics.

 

(It's not crystal clear wh= at "numerical value" refers to, given the list (Prefix, Routing I= nstance, Topology, Algorithm))

    &n= bsp;        

NEW1:

   o  (Pref= ix, Routing Instance, Topology, Algorithm), where a topology

    &n= bsp; is identified by a set of links with metrics. For the purpose of

    &n= bsp; incoming label collision resolution, the same Topology numerical value=

    &n= bsp; SHOULD be used on all routers to identify the same set of links=

    &n= bsp; with metrics.

#Ahmed: I us= ed this wording (thanks)

    &n= bsp;         

    &n= bsp;         

NEW2:

   o  (Pref= ix, Routing Instance, Topology, Algorithm). A Topology

    &n= bsp; identifies a set of links with metrics. For the purpose of=

    &n= bsp; incoming label collision resolution, the same Topology numerical value=

    &n= bsp; SHOULD be used on all routers to identify the same set of links=

    &n= bsp; with metrics.

 

-----

=A72.5.1=

 

"   &n= bsp;   o All addresses are represented in 128 bits as follows

 

    &n= bsp;       . IPv6 address is encoded natively=

 

    &n= bsp;       . IPv4 address is encoded in the m= ost significant bits and

    &n= bsp;          the remaining bi= ts are set to zero

 

    &n= bsp;  o All prefixes are represented by 128.

 

    &n= bsp;       . A prefix is encoded in the most = significant bits and the

    &n= bsp;          remaining bits a= re set to zero.

 

    &n= bsp;       . The prefix length is encoded bef= ore the prefix"

    &n= bsp;            = ;            &n= bsp;    

    &n= bsp;            = ;            &n= bsp;    

    &n= bsp;            = ;            &n= bsp;    

"All prefixes are rep= resented by 128."

128 what? Could be bits, b= ut this does not fit with the addition of the prefix length.

 

"The prefix length is= encoded before the prefix"

using a field of what size= ?

#Ahmed: I co= rrected this to be (128+8)

 

 

Do we (really) need 2 diff= erent encodings for prefix and address? Especially since the rest of the al= gorithm does not make the difference:

   "o = Encode the remaining set of FECs as follows

 

    &n= bsp;  o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length,=

    &n= bsp;    Prefix, SR Algorithm, routing_instance_id, Topology)= "

#Ahmed: It i= s just that conceptually an address and a prefix are different and they are= usually handled quite differently by routing protocols

---

=A72.5.2. Redistribution b= etween Routing Protocol Instances

 

 

"   o = If the receiving instance's SRGB is the same as the SRGB of origin<= o:p>

    &n= bsp; instance, THEN

 

    &n= bsp;  o the index is redistributed with the route

 

   o  Else<= /span>

 

    &n= bsp;  o the index is not redistributed and if needed it is the duty of=

    &n= bsp;    the receiving instance to allocate a fresh index rel= ative to

    &n= bsp;    its own SRGB"

    &n= bsp;            = ;      

With a strict interpretati= on of this rule, when one increases the size of the SRGB, all indexes from = redistributed prefixes will be withdrawn because it's unlikely that we can guaranty that the change of both SRGB be atomic.

Could this be accommodated= ? e.g. by only using the SRBG below the index ? i.e SRGB [0;index] or just = the mapped label in both SRGB?

#Ahmed: I th= ink this is a very fine corner case. But I am open to any suggestion

---

=A72.6

OLD:

In the general case, the i= ngress node may not have exactly have the

   same data of = the receiving node, so the result may be different.

 

NEW:

In the general case, the i= ngress node may not have exactly the

   same data of = the receiving node, so the result may be different.

#Ahmed: I us= ed that wording

 

----

=A72.10<= /p>

 

OLD

   This document= covers the calculation of outgoing label for the top

   label only. T= he case where outgoing label is not the top label and is<= /p>

   part of a sta= ck of labels that instantiates a routing policy or a

   traffic engin= eering tunnel is covered in other documents such as

   [I.D.filsfils= -spring-segment-routing-policy].

  

This may be understood as = requiring a _normative_ reference for [I.D.filsfils-spring-segment-routing-= policy], which would significantly delay the RFC publication of this document.

 

Proposed NEW1:

   This doc= ument covers the calculation of outgoing label for the top

   label only. O= ther cases are out of scope of this document.

 

Or NEW2:=

  This document cover= s the calculation of outgoing label for the top

   label only. T= he case where outgoing label is not the top label and is<= /p>

   part of a sta= ck of labels that instantiates a routing policy or a

   traffic engin= eering tunnel is out of scope of this document.

#Ahmed: I ch= anged the wording a little bit such that [I.D.filsfils-spri= ng-segment-routing-policy] is an example

-- 

=A72.10.1

 

"   Suppose= an MCC on a router "R0" determines that PUSH or CONTINUE<= o:p>

   operation is = to be applied to an incoming packet whose active SID is

   the global SI= D "Si" ..."

  

 My undertanding is t= hat "whose" in "whose active SID" refers to the the &qu= ot;incoming packet". This seems to imply that the incoming packet is (= already) labeled.

- This does not match the = example used in the following paregraph, where the incoming packet is IP.

 "An example of = a method to determine the SID

   "Si"= ; for PUSH operation is the case where IS-IS [I-D.ietf-isis-

   segment-routi= ng-extensions] receives the prefix-SID "Si" sub-TLV

   advertised wi= th prefix "P/m" in TLV 135 and the destination address

   of the incomi= ng IPv4 packet is covered by the prefix "P/m"."<= /o:p>

 - Also, you can't si= mply perform a PUSH on a received label packet. You first need to POP or SW= AP the incoming label.

 

May be proposed NEW:

   Suppose an MC= C on a router "R0" determines that a PUSH or CONTINUE=

   operation is = to be applied to an incoming packet, related to the global SID "Si&quo= t; ...

#Ahmed: Modi= fied the text as suggested

-----

=A72.10.1

 

OLD: If the neighbor "= ;N" does not support SR or "I" does not satisfy<= /o:p>

    &n= bsp; the inequality specified in Section 2.4 for the SRGB of the

    &n= bsp; neighbor "N"

    &n= bsp;        

May be a more generic sent= ence:

 

NEW   If the nei= ghbor "N" does not support SR or advertises a SRGB invalid or too= small,

#Ahmed: Modi= fied as suggested

 -----

=A72.10.1

 

OLD:

    &n= bsp;  o If it is possible to send the packet towards the neighbor &quo= t;N"

    &n= bsp;     using standard MPLS forwarding behavior as spe= cified in

    &n= bsp;     {RFC3031] and [RFC3032], then forward the pack= et. The method

    &n= bsp;     by which a router decides whether it is possib= le to send the

    &n= bsp;     packet to "N" or not is beyond the s= cope of this document. For

    &n= bsp;     example, the router "R0" can use the= downstream label

    &n= bsp;     determined by another MCC, such as LDP [RFC503= 6], to send the

    &n= bsp;     packet.

 

The fall back to LDP seems= like a mandated behavior. If so, the behavior seems under-specified. In pa= rticular "out of scope of this document" does not seem like a valid argument.

#Ahmed: In g= eneral LDP is not mandated. The statement says use MPLS. How and what proto= col is used to determine what to do with the incoming label(s) (if any) and what is (are) the outgoing label(s) is totally outside the sc= ope of this document. 

 

Possible NEW:<= /o:p>

"   &n= bsp;   o If this neighbor "N" advertises a valid label = for the same FEC via another MCC (e.g. LDP [RFC5036]), then forward the pac= ket to N, using the label advertised by this MCC.

 

----

2.11.2. Forwarding Behavio= r Corresponding to CONTINUE Operation for Local SIDs

 

  "A local SID o= n a router "R0" corresponds to a local label such as an

   IGP adj-SID. = In such scenario, the outgoing label towards a next-hop

   "N"= is determined by the MCC running on the router "R0"and the

   forwarding be= havior for CONTINUE operation is identical to swap

   operation [RF= C3032] on an MPLS label"

  

I'm not seeing a case wher= e an IGP adj-SID would have "CONTINUE" as a forwarding behavior.<= /span>

And the SR architecture re= quires a NEXT operation:

"   &n= bsp;  When a node binds an Adj-SID to a local data-link L, the node MU= ST

    &n= bsp;  install the following FIB entry:

 

    &n= bsp; Incoming Active Segment: V

    &n= bsp; Ingress Operation: NEXT

    &n= bsp; Egress Interface: L"

 

https://tool= s.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.4=

 

A solution would be to sim= ply remove "such as an IGP adj-SID"

#Ahmed: I ag= ree and I removed adj-SID

---

=A73 IGP Segment examples<= /span>

 

This section, also useful,= is quite long and not normative for this STD track doc. An option may be t= o move it to appendix.

Up to you.

#Ahmed: Agre= ed and moved to appendix

---

=A73.1

 

"R2 is the next-hop a= long the shortest path towards R8. By applying

   the steps in = Section 2.8 the local label downloaded to R1's FIB

   corresponding= to the global SID index 8 is 1008 because the SRGB of

   R2 is [1000,5= 000] as shown in Figure 2."

  

 may be

OLD:  local label dow= nloaded to R1's FIB

NEW:  local outgoing = label downloaded to R1's FIB

 (because I would ass= ume that by default, label downloaded in the FIB is probably the incomig la= bel one)

#Ahmed Chang= ed "local" to "outgoing"

 --=

OLD: owned by the R8

NEW1: OLD: owned by R8

NEW2: OLD: owned by the no= de R8

#Ahmed: Done=

--

"The packet arrives a= t router R2. Because the top label 1008

   corresponds t= o the IGP SID "8", which is the prefix-SID attached to

   the prefix 19= 2.0.2.8/32 owned by the R8, then the instruction

   associated wi= th the SID is "forward the packet using all ECMP/UCMP

   interfaces an= d all ECMP/UCMP next-hop(s) along the shortest path

   towards R8&qu= ot;. "

 

IGP prefix-SID are typical= ly forwarded along the ECMP shortest path. I'm not sure where "UCMP&qu= ot; is coming from. Also "along the shortest path" seems to be in= compatible with UCMP.

#Ahmed: I ch= anged the wording to "shortest/useable"

--

"Because R3

   is the penult= imate hop, R3 applies NEXT operation then sends the

   packet to R8.= "

 

   "penulti= mate hop" is a required but not sufficient reason. You are assuming th= at R8 asked for PHP, but I'm not seeing this assumption stated in the text.=

#Ahmed:
I changed to wording to use  "assume"

---

"The NEXT operation r= esults in popping the outer label

   and sending t= he packet as a pure IPv4 packet to R8. The

 

   In conclusion= , "

  

OLD: The=

NEW:

#Ahmed: In m= any places, I refer to each operation using "the".

---

=A73.2 & =A73.3 & = =A73.4 & =A73.5

" Using the

   calculation t= echniques specified in Section 2.10 and 2.11 the

   resulting lab= el stack starting from the topmost label is <1002, 9001,

   1008>.&quo= t;

  

Actually section 2.10 only= defines the calculation technique for the top label:

 

   "This do= cument covers the calculation of outgoing label for the top

   label only. T= he case where outgoing label is not the top label and is<= /p>

   part of a sta= ck of labels that instantiates a routing policy or a

   traffic engin= eering tunnel is covered in other documents such as

   [I.D.filsfils= -spring-segment-routing-policy]."

   https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13#secti= on-2.10

  

   Hence th= is document does not define the behavior for this example 2. You would need= to either extend this doc to cover the push of a stack of label/SID or rem= ove these examples 2, 3, 4, 5

#Ahmed Done<= br>

----

[RFC8174] to be added to n= ormative references.

#Ahmed: Done=

 

 

From:<= /b> bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13<= /span>

 

Hello Working Group,
    
This email starts a Working Group Last Call on dr=
aft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and =
ready for a final working group review.
    
Please read this document if you haven't read the=
 most recent version yet, and send your comments to the list, no later than=
 *June 08*.
 
As a reminder, this document had already passed a=
 WGLC more than a year ago on version -06 [2], had been sent to the AD but =
then returned to the WG.
Since then, the document has significantly change=
d, so please read it again. In particular, it now includes the resolution i=
n case of incoming label collision. Hence it killed draft-ietf-spring-confl=
ict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd=
. Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG c=
onsensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf=
-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/m=
sg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
______________________________________________________________________=
___________________________________________________
 
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.

 <= /o:p>

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A47F73954OPEXCLILM21corp_-- From nobody Tue Oct 30 04:05:11 2018 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 58223128B14; Tue, 30 Oct 2018 04:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qdQh6PG0kkYj; Tue, 30 Oct 2018 04:05:01 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.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 56F96126CC7; Tue, 30 Oct 2018 04:05:01 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 42kpXC4RVXzCrr9; Tue, 30 Oct 2018 12:04:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 42kpXC3WrmzDq8j; Tue, 30 Oct 2018 12:04:59 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0415.000; Tue, 30 Oct 2018 12:04:59 +0100 From: To: Ahmed Bashandy CC: SPRING WG List , "draft-ietf-spring-segment-routing-mpls@ietf.org" , Shraddha Hegde , "Martin Vigoureux (martin.vigoureux@nokia.com)" Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Thread-Index: AQHUajpXQnSjXL2L30C1pUKldWjDNKU3qmnQ Date: Tue, 30 Oct 2018 11:04:58 +0000 Message-ID: <8930_1540897499_5BD83ADB_8930_111_1_53C29892C857584299CBF5D05346208A47F73992@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6143_1539619921_5BC4BC51_6143_164_1_53C29892C857584299CBF5D05346208A47B69553@OPEXCLILM21.corporate.adroot.infra.ftgroup> <0649713e-d14c-5e81-cac7-d657d58130b7@gmail.com> In-Reply-To: <0649713e-d14c-5e81-cac7-d657d58130b7@gmail.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.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47F73992OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 11:05:10 -0000 --_000_53C29892C857584299CBF5D05346208A47F73992OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Ahmed. Next steps are : - shepherd write up (Shraddha) - 2 weeks to allow WG to comment on the changes, especially from Chris, PK,= Ruediger, Sasha, Shraddha. - WG chairs go ahead (delegated to Martin (AD) as both chairs co-author) Thank you, --Bruno From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] Sent: Monday, October 22, 2018 9:06 PM To: DECRAENE Bruno TGI/OLN; draft-ietf-spring-segment-routing-mpls@ietf.org Cc: SPRING WG List Subject: Re: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 I uploaded version 15 to address the comments below since today is the dead= line before the upcoming IETF I will explaining how version 15 addresses each of the comments before the = start of the IETF next week Thanks a lot for all the help and the feedback Ahmed On 10/15/18 9:12 AM, bruno.decraene@orange.com wrote: Authors, Ahmed, Could you progress on this document? Thread is: https://mailarchive.ietf.org/arch/browse/spring/?q=3Dsubject%3Ad= raft-ietf-spring-segment-routing-mpls Comments still to be addressed/resolved are the following: https://mailarchive.ietf.org/arch/msg/spring/xx-t5v5IW2P_8rZykeJrvl9qDIE = (from myself since 2018-05-24) https://mailarchive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw (f= rom Chris Bowers since 2018-06-08) https://mailarchive.ietf.org/arch/msg/spring/yIwUvKddrcR-gxPQZSMjbynTX74 (f= rom PK since 2018-06-09) https://mailarchive.ietf.org/arch/msg/spring/5PHhLlMIxLgoFdoRC1Wqz6xCBnI (= from PK since 2018-06-09) https://mailarchive.ietf.org/arch/msg/spring/w0ZmOAcDf_TUUWLkeFk_E6jzQm4 (f= rom Ruediger 2018-06-13) https://mailarchive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ (f= rom Shraddha 2018-07-20 & +1 from Sasha) https://mailarchive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk (f= rom Sasha & St=E9phane discussion 2018-08-06) Authors, Ahmed, Thank you for engaging the authors of those comments and update the draft. Thank you, --Bruno From: DECRAENE Bruno IMT/OLN Sent: Thursday, June 07, 2018 6:52 PM To: SPRING WG List Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hi all, A quick update on the status of this WGLC: - All the authors have responded about IPR (thank you!). Still missing repl= ies from some contributors (Wim, Edward, Igor, Saku). I've sent them a remi= nder this Monday. - Two people (Zafar, Adrian) have responded supporting publication. - No opposition. - Two persons have sent comments (Adrian, myself). Thanks Adrian. - Authors have not replied to any comment so far. - The WGLC period was scheduled to end tomorrow. I wish we had more support, reviews, and authors' involvement to reply to r= eviews. The WGLC is extended by a week. Please review the document and send your co= mments to the list, no later than *June 15* Thank you, --Bruno From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Thursday, May 24, 2018 7:14 PM To: SPRING WG List Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hello Working Group, This email starts a Working Group Last Call on draft-ietf-spring-segment-ro= uting-mpls-13 [1] which is considered mature and ready for a final working = group review. Please read this document if you haven't read the most recent version yet, = and send your comments to the list, no later than *June 08*. As a reminder, this document had already passed a WGLC more than a year ago= on version -06 [2], had been sent to the AD but then returned to the WG. Since then, the document has significantly changed, so please read it again= . In particular, it now includes the resolution in case of incoming label c= ollision. Hence it killed draft-ietf-spring-conflict-resolution. Both co-chairs co-author this document, hence: - Shraddha has agreed to be the document shepherd. Thank you Shraddha. - Martin, our AD, has agreed to evaluate the WG consensus. Thank you, Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 [2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A47F73992OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Ahmed.

 

Next steps are :

- shepherd write up (Shraddha= )

- 2 weeks to a= llow WG to comment on the changes, especially from Chris, PK, Ruediger, Sas= ha, Shraddha.

- WG chairs go= ahead (delegated to Martin (AD) as both chairs co-author)

 

Thank you,

--Bruno

 

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Monday, October 22, 2018 9:06 PM
To: DECRAENE Bruno TGI/OLN; draft-ietf-spring-segment-routing-mpls@i= etf.org
Cc: SPRING WG List
Subject: Re: WG Last Call for draft-ietf-spring-segment-routing-mpls= -13

 

I uploaded version 15 to address the comments below since today is the d= eadline before the upcoming IETF

I will explaining how version 15 addresses each of the comments before t= he start of the IETF next week

Thanks a lot for all the help and the feedback

Ahmed

 

 

On 10/15/18 9:12 AM, bruno.decraene@orange.com wrote:

Authors, Ahmed,

 

Could you progress on this= document?

 

Thread is: https://mailarchive.ietf.org/arch/browse/spring/?q=3Dsubject%3Adraft-ietf-s= pring-segment-routing-mpls

 

Comments still to be addre= ssed/resolved are the following:

https://mailarch= ive.ietf.org/arch/msg/spring/xx-t5v5IW2P_8rZykeJrvl9qDIE   (from myself since 2018-05-24)

https://mailarch= ive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw (from Chris Bowers since 2018-06-08)

https://mailarch= ive.ietf.org/arch/msg/spring/yIwUvKddrcR-gxPQZSMjbynTX74 (from PK since 2018-06-09)

https://mailarch= ive.ietf.org/arch/msg/spring/5PHhLlMIxLgoFdoRC1Wqz6xCBnI  (from PK since 2018-06-09) 

https://mailarchive.ietf.org/arch/msg/spring/w0ZmOA=
cDf_TUUWLkeFk_E6jzQm4 (from Ruediger 2018-0=
6-13)

https://mailarch= ive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ (from Shraddha 2018-07-20 & +1 from Sa= sha)

https://mailarch= ive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk (from Sasha & St=E9phane discussion 2018-08-06)

 

 

Authors, Ahmed,

Thank you for engaging the= authors of those comments and update the draft.

 

Thank you,

--Bruno<= /p>

 

 

 

From:<= /b> DECRAENE Bruno IMT/OLN
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls= -13

 

Hi all,

 

A quick update on the stat= us of this WGLC:

 

- All the authors have res= ponded about IPR (thank you!). Still missing replies from some contributors= (Wim, Edward, Igor, Saku). I’ve sent them a reminder this Monday.

- Two people (Zafar, Adria= n) have responded supporting publication.

- No opposition.

- Two persons have sent co= mments (Adrian, myself). Thanks Adrian.

- Authors have not replied= to any comment so far.

- The WGLC period was sche= duled to end tomorrow.

 

I wish we had more support= , reviews, and authors’ involvement to reply to reviews.<= /o:p>

 

The WGLC is extended by a = week. Please review the document and send your comments to the list, no lat= er than *June 15*

 

Thank you,

--Bruno<= /p>

 

From:<= /b> bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13<= /span>

 

Hello Working Group,
    
This email starts a Working Group Last Call on dr=
aft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and =
ready for a final working group review.
    
Please read this document if you haven't read the=
 most recent version yet, and send your comments to the list, no later than=
 *June 08*.
 
As a reminder, this document had already passed a=
 WGLC more than a year ago on version -06 [2], had been sent to the AD but =
then returned to the WG.
Since then, the document has significantly change=
d, so please read it again. In particular, it now includes the resolution i=
n case of incoming label collision. Hence it killed draft-ietf-spring-confl=
ict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd=
. Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG c=
onsensus.
    
Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf=
-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/m=
sg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
______________________________________________________________________=
___________________________________________________
 
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.

 <= /o:p>

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A47F73992OPEXCLILM21corp_-- From nobody Tue Oct 30 09:45:30 2018 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 77DDE130DC8 for ; Tue, 30 Oct 2018 09:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 S78YIjlfhLcN for ; Tue, 30 Oct 2018 09:45:24 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 9C91512D4EA for ; Tue, 30 Oct 2018 09:45:24 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id k17-v6so7675106ioc.4 for ; Tue, 30 Oct 2018 09:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lMxL8VqUxJCp8U9+J/Qj+PiiZs7amJr3N/3DiNa9j+o=; b=iJeyLXSYtSZu+XoCvRhV4XwXWSx/2VtghNopvIBHyFJ1okT6B1z5kC+VySfpnNWzLP BB9PeEmnWL3w1NQKyG9tI3y0qwCqsuoaZk6kw31l7XHXD9jZkQqZCyAlMrNTQinHjMBu Z1SV2yeBXeUG8yETJ0mFGOIq428SdBON3kMJka3pzIOSYRi90LSGYn6K2HbrryKon/1l HHBvuhnZfEXn3S2QedIoPAvTUCFuUqIZV0nemJ/IfC4D1ZIJ7uj2GzujEFzTpQ374pIv daoDteZ3+FF4Q3qYwenV2tiLZpiFgJWyCSahBCHdjMsuYiCHZVmqQdwyeyd6BZhPewvj KJpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lMxL8VqUxJCp8U9+J/Qj+PiiZs7amJr3N/3DiNa9j+o=; b=N6hvDENWDEbrvpM9O/7jNZyWXoUREJILuQAy4iegnosB5ag7JlnMTTgthnfC3PirAc UR4GowbEyj763eW/J1SOD/kwiy+kyyKTi9jS4whcbk53/f3WtdaSi8cJbCn0mL0kSrhl NI7SQi7US10HEYavrO0U/CDU0rjbOOKRdOTHZXPVWJi9ml2Y03bATUDZBC8MAYb7aYfH r4ogQza5RdwFOcMiN1pLOTB7MHXRg5ky5xYI03xqnzjR/TFaiCxdbYamM1ovXPeoCnfs bTaAL8fTgJx2eXbHWcoMX5RQvxSJYv9cfRBsDlZYpYLJo/tUVJuPikQGyRZjAysk2nIE QUTw== X-Gm-Message-State: AGRZ1gIOwRcO9JT1Q7CU/oFqng7ZtJ6D8cXPY9Vp501747FLz1qIuJzc DwzD/MHh57J2cMIVrheB2Xd24tr2wJHbjGdjM5ZUmg== X-Google-Smtp-Source: AJdET5fmbustvw5DTRAAvUnBjEtRuah9hGgFanJPNVsFIFp7UMyVmvSIWa3eGh5lU0JOX22r3bBV0KNCkQ4FCqv516I= X-Received: by 2002:a5e:a507:: with SMTP id 7-v6mr12090109iog.151.1540917923299; Tue, 30 Oct 2018 09:45:23 -0700 (PDT) MIME-Version: 1.0 References: <3470b63ec7264ac096e326a59d97b50f@XCH-ALN-008.cisco.com> In-Reply-To: From: Przemyslaw Krol Date: Tue, 30 Oct 2018 09:44:46 -0700 Message-ID: To: rjs@rob.sh Cc: "Ketan Talaulikar (ketant)" , robjs=40google.com@dmarc.ietf.org, spring@ietf.org, draft-filsfils-spring-sr-policy-considerations@tools.ietf.org Content-Type: multipart/alternative; boundary="00000000000072d61f057974e91b" Archived-At: Subject: Re: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 16:45:29 -0000 --00000000000072d61f057974e91b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, I tend to agree that in the current shape, draft-filsfils-spring-sr-policy-considerations-02 document attempts to cover architectural, operational and use-case aspects which may not be optimal. To that point, if we can agree whether it is supposed to be a more operationally-focused extension to its parent draft-ietf-spring-segment-routing-policy draft or more of a use case overview, we could make relevant adjustments/augmentations to accommodate that. I personally see a value in both options but based on Rob's feedback, the latter one may not be suited for SPRING WG. thanks, pk On Mon, Oct 22, 2018 at 9:50 PM Rob Shakir wrote: > Ketan, Authors, > > Thanks for the update. Further responses are in-line marked [rjs]. > > My key feedback here is that I feel like we're not really on the same pag= e > as to what this draft is trying to communicate. Perhaps if we agreed this= , > then it'd be clearer what the right direction for the document is. > > I'd really encourage the WG to read this doc and provide the authors with > feedback -- especially if you have an implementation, or are implementing > SR-TE Policy in your network. > > On Thu, 18 Oct 2018 at 19:10 Ketan Talaulikar (ketant) > wrote: > >> >> >> - (2) What is the intention of the diagram shown in this section? It >> seems to be completely an implementation detail that an implementatio= n has >> the "SRPM" that acts as a central resolution point. For instance, wha= t >> should a reader learn from the fact that the SRPM is not a standard R= IB >> resolution process? If there are suggestions that one wants this >> implementation - should there be some discussion of the complexity of= this >> new API between say, the BGP daemon and a general RIB process? >> >> *[KT] **We will clarify in the text that the section provides a >> conceptual overview of components/functionality that work with each othe= r >> to implement SR Policy on a headend. The intention is not to define APIs >> between the blocks since those are implementation details. We have sever= al >> drafts related to the SR Policy functionality =E2=80=93 besides the arch= itecture >> draft, there are extensions to BGP (BGP-SRTE & LS), PCEP then we have Ya= ng >> model. This draft puts these blocks into reference so implementers get a= n >> idea of the functionality that maps to say BGP and the SR Policy process= es >> (e.g. draft-ietf-idr-segment-routing-te-policy).* >> > >> - (2) My general feedback on this section is that this is >> implementation discussion, that does not add to the IETF content that= we >> are publishing within SPRING. Like we have had discussion of use case >> drafts, I think this is similar but from the implementor side. I'd li= ke to >> discuss the value that this content has. >> >> *[KT] **There is a difference between documenting implementation details >> and providing a conceptual overview of the implementation aspects. >> Especially when defining an architecture which involves multiple protoco= ls >> and functional blocks. I find it valuable as an implementer myself.* >> > > [rjs] I don't think that the edits that are made to this section > particularly add anything. If the intention is the conceptual overview, I > don't understand why we refer to say, the "SRP process". Conceptually, > shouldn't this be describing interaction between functional blocks? i.e., > we have a functional block in the architecture that is responsible for > learning candidate paths (it's an implementation detail from where...), a= nd > selects the active path, installing it into the RIB or FIB. > > If the intention is to have this be conceptual, my suggestion would be to > make the language refer to architectural concepts - rather than what seem > to be realisations of the idea, and to convert the diagrams into lists th= at > describe what each block is doing. Others may have thoughts on this too - > especially where they have other implementations. > > >> >> - (3.1) I think that this section has some useful content, but it's >> buried by starting out by defining the algorithms.. Why not make this >> section be focused towards the constraints that must be considered wh= en >> calculating a SID stack for a particular path. i.e., the key points s= eem to >> be: >> >> >> - Use of the IGP metric as the metric for path optimisation is >> desirable, especially in constrained push or readable depth enviro= nments, >> because it allows the minimum number of deviations from the shorte= st path >> and therefore labels. >> - If a different metric is used, then this implies that every time >> that metric differs from the IGP metric, then this will result in >> additional SIDs. >> >> >> - There is no mention of flex-algorithm in this section. It seems >> relevant given that you can also mitigate the problem that is t= rying to be >> solved here by having a set of prefix SIDs per metric. >> >> *[KT] **We will put a forward reference to the Flex Algo section here.* >> >> - It may be advantageous to sacrifice optimality of the path >> calculation solution by relaxing the optimisation constraints. >> >> >> - The draft should talk about the operational considerations here - >> i.e., it implies that you can actually tolerate the margin in t= he >> optimisation objective for the service. >> - The "just pick the best you can do within N SIDs" is >> dangerous, since it means that the network delivers a service t= hat *isn't* >> what the operator asked for - which may result in service degra= dation >> (e.g., consider live/live where there is a maximum latency diff= erence that >> is tolerable between the two feeds). >> >> *[KT] **We will add text clarifying this aspect. However, the point is >> also that the operator may be OK with the =E2=80=9Cbest possible=E2=80= =9D and so such an >> option may be useful in some deployments.* >> > > [rjs] I don't think that we agree at all on whether this section is usefu= l > in its current form. What is the message that we're trying to convey in > this section of the document? If it is that there are possible algorithms > that may be used by an operator dependent on their service, I'm not clear > that we need to document this. The value to me *would be* that we cover > some of the caveats of calculating policies that are specific to SR -- > i.e., SID stack depth being something that is influenced by divergence fr= om > the shortest path, and the fact that we might need to sacrifice the optim= al > solution to pathing based on these constraints, then I think it'd be > useful. The current text does not get this across clearly. > > >> >> - (3.2) I'm unclear of the value of this text. It seems to me that >> we're restating some of the optimisation objectives that are known fo= r >> general TE (and, for example, are described by - say RFC3209). What i= s it >> that we're trying to communicate to the reader here -- can it be cove= red by >> "existing path calculation considerations, such as resource affinity >> [rfc3209] can be applied to the path calculation of SR paths"? >> >> *[KT] **We do not assume that anyone that is deploying SR Policies is >> familiar with RSVP-TE. RFC3209 does cover resource affinity but not the >> others. Some of the constraints are unique to SR. Hence, there is a valu= e >> in specifying the available constraints.* >> > > [rjs]: Again, we might have to agree to disagree here. I did not make an > assertion that someone was familiar with RSVP-TE, but that they were > familiar with *TE* -- there are networks that meet these constraints that > do not use SR or RSVP-TE.... Again, I'd find it very useful to understand > what the authors are trying to communicate in this section. If it's that > there are particular trade-offs, sure, let's find new wording -- but if > not, then I'm not clear why SPRING needs to standardise an incomplete lis= t > of optimisation criteria. > > >> >> - (3.4) I'm again going to question the value of this section -- it >> doesn't seem to give enough detail of the algorithm that you're propo= sing >> to be generally useful, and points out it is a node-local behaviour. = If >> there's a desire to get to a common understanding of how to take a pa= th and >> compress its SID stack, then let's write this out. >> >> *[KT] **Agree that this is a node local behavior. However, the high >> level description does indicate how an implementation could go about >> determining a path to a SID in an efficient manner.* >> > > [rjs]: If there's really value in this high-level description (I'm not > sure I agree...) -- it seems like then restructuring this section to writ= e > out the algorithm then use it to illustrate how it operates on a network > after this. > > >> >> - (4) See my comments on Section 2 of this document, why is >> describing how the interaction between different processes within wha= t >> sounds like a single implementation something that we should publish = within >> the IETF? >> >> *[KT] **These examples are important to illustrate how the candidate >> path selection tiebreaker rules work in different conditions. The >> interactions are also valuable to understand the selection which happens >> say within BGP (based on its best path) for BGP-SRTE and the selection t= hat >> then happens at SR Policy level. This section was originally placed in t= he >> Appendix of the SR Policy Architecture draft since the candidate path >> selection tiebreaker rules were specified in that draft. Later was move = to >> this informational draft.* >> > > [rjs]: In my view, this example would be best _as succinctly_ as possible > to demonstrate the preferences in the actual draft. It seems to me that t= he > explanations themselves are quite wordy to make a couple of clear points: > > - BGP path selection is unaffected by SR-TE policy. > - If a protocol does not make its own path selection, then SR-TE policy > attributes are considered to differentiate between them. > etc. > > Ideally, this should be clear in the policy architecture draft itself. If > it can't be made clear, then I think we should seriously consider whether > we have the right level of complexity here. > > >> >> - (5+5.1+5.2) The core point that seems to be being made here is that >> - within a single IGP area the head-end has all the visibility it req= uires; >> if there are multiple areas, there are ways that a head-end could get >> access to the areas that it is not part of (e.g., BGP-LS). Is anythin= g more >> being said here? Do the implementation details that there are BGP-LS = RRs >> actually matter? >> >> *[KT] **The intention is to provide guidance for some of the deployment >> options for achieving this functionality.* >> >> - (5.3) Similarly to the above, this seems to assume one particular >> mechanism of building a centralised system, that doesn't need any new >> extensions in the IETF. Is this something that we need to document? >> >> *[KT] **We explain while taking an example of a mechanism based on IETF >> standards that is available for operators looking to deploy this model.* >> >> - (6.2) This section seems to imply that there can never be >> allocations from the SRLB that are not dynamically advertised via som= e >> other protocol. Is this really true? >> >> *[KT] **I don=E2=80=99t believe this was the intention. We will clarify = this in >> the text.* >> >> - (8) Given that there is a separate draft discussing this -- what is >> the motivation to have this in this document? >> >> *[KT] **This section gives and overview of the proposal with an example >> of optical circuit. It also clarifies that the concept described is >> applicable not just for optical links but in general to other types of >> layer 2 circuits and tunnels as well. The draft-anand-spring-poi-sr goes >> into the details of the use-case, protocol mechanism and extensions >> specifically for optical networks only.* >> > > [rjs]: For the above points -- I think we've clearly seen in the WG and > IESG that there is not a huge amount of appetite to publish use case > drafts. From an operational perspective, I also don't really find these > sections that useful since they don't really give me enough information t= o > be able to figure out an implementation. I'd be interested whether the > working group thinks that they are sufficiently of interest to include in > this document. > > Cheers, > r. > > >> Thanks, >> >> r. >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > --=20 Przemyslaw "PK" Krol | Strategic Network Engineer ing | pkrol@google.com --00000000000072d61f057974e91b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

I tend to agree that in the current shape,=C2=A0draft-fils= fils-spring-sr-policy-considerations-02=C2=A0document attempts to cover= architectural, operational and use-case aspects which may not be optimal. = To that point, if we can agree whether it is supposed to be a more operatio= nally-focused extension to its parent=C2=A0draft-ietf-spring-segment-routin= g-policy draft or more of a use case overview, we could make relevant adjus= tments/augmentations to accommodate that. I personally see a value in both = options but based on Rob's feedback, the latter one may not be suited f= or SPRING WG.

thanks,
pk

On Mon, Oct 22, 201= 8 at 9:50 PM Rob Shakir <rjs@rob.sh> wrote:
Ketan, Authors,

Thanks f= or the update. Further responses are in-line marked [rjs].=C2=A0
=
My key feedback here is that I feel like we're not reall= y on the same page as to what this draft is trying to communicate. Perhaps = if we agreed this, then it'd be clearer what the right direction for th= e document is.

I'd really encourage the WG to = read this doc and provide the authors with feedback -- especially if you ha= ve an implementation, or are implementing SR-TE Policy in your network.

On Thu, 18 Oct 2018 = at 19:10 Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:


  • (2) What is the intention of the diagram shown in this section? It seems to= be completely an implementation detail that an implementation has the &quo= t;SRPM" that acts as a central resolution point. For instance, what sh= ould a reader learn from the fact that the SRPM is not a standard RIB resolution process? If there are suggestions th= at one wants this implementation - should there be some discussion of the c= omplexity of this new API between say, the BGP daemon and a general RIB pro= cess?
<= p class=3D"MsoNormal">[KT] We will= clarify in the text that the section provides a conceptual overview of com= ponents/functionality that work with each other to implement SR Policy on a= headend. The intention is not to define APIs between the blocks since those are implementation details. We = have several drafts related to the SR Policy functionality =E2=80=93 beside= s the architecture draft, there are extensions to BGP (BGP-SRTE & LS), = PCEP then we have Yang model. This draft puts these blocks into reference so implementers get an idea of the functionali= ty that maps to say BGP and the SR Policy processes (e.g. draft-ietf-idr-se= gment-routing-te-policy).

=

=
  • (2) My general feedback on this section is that this is implementation disc= ussion, that does not add to the IETF content that we are publishing within= SPRING. Like we have had discussion of use case drafts, I think this is si= milar but from the implementor side. I'd like to discuss the value that this content has.
<= p class=3D"MsoNormal">[KT] There i= s a difference between documenting implementation details and providing a c= onceptual overview of the implementation aspects. Especially when defining = an architecture which involves multiple protocols and functional blocks. I find it valuable as an implementer myse= lf.


[r= js] I don't think that the edits that are made to this section particul= arly add anything. If the intention is the conceptual overview, I don't= understand why we refer to say, the "SRP process". Conceptually,= shouldn't this be describing interaction between functional blocks? i.= e., we have a functional block in the architecture that is responsible for = learning candidate paths (it's an implementation detail from where...),= and selects the active path, installing it into the RIB or FIB.
=
If the intention is to have this be conceptual, my suggestio= n would be to make the language refer to architectural concepts - rather th= an what seem to be realisations of the idea, and to convert the diagrams in= to lists that describe what each block is doing. Others may have thoughts o= n this too - especially where they have other implementations.
= =C2=A0

  • (3.1) I think that this section has some useful content, but it's burie= d by starting out by defining the algorithms.. Why not make this section be= focused towards the constraints that must be considered when calculating a= SID stack for a particular path. i.e., the key points seem to be:
    • Use of the IGP metric as the metric for path optimisation is desirable, esp= ecially in constrained push or readable depth environments, because it allo= ws the minimum number of deviations from the shortest path and therefore la= bels.
    • If a different metric is used, then this implies that every time that metri= c differs from the IGP metric, then this will result in additional SIDs.=
      • There is no mention of flex-algorithm in this section. It seems relevant gi= ven that you can also mitigate the problem that is trying to be solved here= by having a set of prefix SIDs per metric.
<= p class=3D"MsoNormal">[KT] We will= put a forward reference to the Flex Algo section here.

    • It may be advantageous to sacrifice optimality of the path calculation solu= tion by relaxing the optimisation constraints.
      • The draft should talk about the operational considerations here - i.e., it = implies that you can actually tolerate the margin in the optimisation objec= tive for the service.
      • The "just pick the best you can do within N SIDs" is dangerous, s= ince it means that the network delivers a service that *isn't* what the= operator asked for - which may result in service degradation (e.g., consid= er live/live where there is a maximum latency difference that is tolerable between the two feeds).
<= p class=3D"MsoNormal">[KT] We will= add text clarifying this aspect. However, the point is also that the opera= tor may be OK with the =E2=80=9Cbest possible=E2=80=9D and so such an optio= n may be useful in some deployments.


[rjs] I don't think that we agree at all= on whether this section is useful in its current form. What is the message= that we're trying to convey in this section of the document? If it is = that there are possible algorithms that may be used by an operator dependen= t on their service, I'm not clear that we need to document this. The va= lue to me *would be* that we cover some of the caveats of calculating polic= ies that are specific to SR -- i.e., SID stack depth being something that i= s influenced by divergence from the shortest path, and the fact that we mig= ht need to sacrifice the optimal solution to pathing based on these constra= ints, then I think it'd be useful. The current text does not get this a= cross clearly.
=C2=A0

  • (3.2) I'm unclear of the value of this text. It seems to me that we'= ;re restating some of the optimisation objectives that are known for genera= l TE (and, for example, are described by - say RFC3209). What is it that we= 're trying to communicate to the reader here -- can it be covered by "existing path calculation consideration= s, such as resource affinity [rfc3209] can be applied to the path calculati= on of SR paths"?
<= p class=3D"MsoNormal">[KT] We do n= ot assume that anyone that is deploying SR Policies is familiar with RSVP-T= E. RFC3209 does cover resource affinity but not the others. Some of the con= straints are unique to SR. Hence, there is a value in specifying the available constraints.

[rjs]: Again, we might= have to agree to disagree here. I did not make an assertion that someone w= as familiar with RSVP-TE, but that they were familiar with *TE* -- there ar= e networks that meet these constraints that do not use SR or RSVP-TE.... Ag= ain, I'd find it very useful to understand what the authors are trying = to communicate in this section. If it's that there are particular trade= -offs, sure, let's find new wording -- but if not, then I'm not cle= ar why SPRING needs to standardise an incomplete list of optimisation crite= ria.
=C2=A0

  • (3.4) I'm again going to question the value of this section -- it doesn= 't seem to give enough detail of the algorithm that you're proposin= g to be generally useful, and points out it is a node-local behaviour. If t= here's a desire to get to a common understanding of how to take a path and compress its SID stack, then let's write thi= s out.
<= p class=3D"MsoNormal">[KT] Agree t= hat this is a node local behavior. However, the high level description does= indicate how an implementation could go about determining a path to a SID = in an efficient manner.


[rjs]: If there's really value in this high-level des= cription (I'm not sure I agree...) -- it seems like then restructuring = this section to write out the algorithm then use it to illustrate how it op= erates on a network after this.
=C2=A0

  • (4) See my comments on Section 2 of this document, why is describing how th= e interaction between different processes within what sounds like a single = implementation something that we should publish within the IETF?<= /u>
<= p class=3D"MsoNormal">[KT] These e= xamples are important to illustrate how the candidate path selection tiebre= aker rules work in different conditions. The interactions are also valuable= to understand the selection which happens say within BGP (based on its best path) for BGP-SRTE and the selec= tion that then happens at SR Policy level. This section was originally plac= ed in the Appendix of the SR Policy Architecture draft since the candidate = path selection tiebreaker rules were specified in that draft. Later was move to this informational draft.<= /span>


[rjs]:= In my view, this example would be best _as succinctly_ as possible to demo= nstrate the preferences in the actual draft. It seems to me that the explan= ations themselves are quite wordy to make a couple of clear points:

=C2=A0- BGP path selection is unaffected by SR-TE policy.=
=C2=A0- If a protocol does not make its own path selection, then= SR-TE policy attributes are considered to differentiate between them.
=C2=A0etc.

Ideally, this should be clear in = the policy architecture draft itself. If it can't be made clear, then I= think we should seriously consider whether we have the right level of comp= lexity here.
=C2=A0

  • (5+5.1+5.2) The core point that seems to be being made here is that - withi= n a single IGP area the head-end has all the visibility it requires; if the= re are multiple areas, there are ways that a head-end could get access to t= he areas that it is not part of (e.g., BGP-LS). Is anything more being said here? Do the implementation de= tails that there are BGP-LS RRs actually matter?
<= p class=3D"MsoNormal">[KT] The int= ention is to provide guidance for some of the deployment options for achiev= ing this functionality.<= /p>
  • (5.3) Similarly to the above, this seems to assume one particular mechanism= of building a centralised system, that doesn't need any new extensions= in the IETF. Is this something that we need to document?
<= p class=3D"MsoNormal">[KT] We expl= ain while taking an example of a mechanism based on IETF standards that is = available for operators looking to deploy this model.

  • (6.2) This section seems to imply that there can never be allocations from = the SRLB that are not dynamically advertised via some other protocol. Is th= is really true?
<= p class=3D"MsoNormal">[KT] I don= =E2=80=99t believe this was the intention. We will clarify this in the text= .

<= div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
  • (8) Given that there is a separate draft discussing this -- what is the mot= ivation to have this in this document?
<= p class=3D"MsoNormal">[KT] This se= ction gives and overview of the proposal with an example of optical circuit= . It also clarifies that the concept described is applicable not just for o= ptical links but in general to other types of layer 2 circuits and tunnels as well. The draft-anand-spring-poi-= sr goes into the details of the use-case, protocol mechanism and extensions= specifically for optical networks only.


[rjs]: For the above points -- I think w= e've clearly seen in the WG and IESG that there is not a huge amount of= appetite to publish use case drafts. From an operational perspective, I al= so don't really find these sections that useful since they don't re= ally give me enough information to be able to figure out an implementation.= I'd be interested whether the working group thinks that they are suffi= ciently of interest to include in this document.

C= heers,
r.
=C2=A0

Thanks,

r.

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


--
=
= --00000000000072d61f057974e91b-- From nobody Tue Oct 30 12:31:01 2018 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 94C75130DCF; Tue, 30 Oct 2018 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 BaceSkxA3Bo8; Tue, 30 Oct 2018 12:30:48 -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 2306D130DC0; Tue, 30 Oct 2018 12:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11458; q=dns/txt; s=iport; t=1540927848; x=1542137448; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Knd6fC2BjbEH7ppRhPxAffM2WxkE8J56vZdmXluFDFc=; b=eMn4TYE8VcoiTPo642EnIoNJGH/INNT4QzjPKJh7NZ/UmrHanGoO+wyi WAzsTL+Kq+LGA1mT+zWAWoYCgv2heArT9OjUcefZXl1hWVMIUtTp/gHef VYTMhQGA9KZZY+wXmOuXerTeLDnq9sOZxq8kOMiS4NtNdEvwKF8yoRqVq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAAC6sNhb/5RdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYIFgWUoCoNslDGCDZkaCwEBLIRAAheDDSI4FgEDAQE?= =?us-ascii?q?CAQECbSiFOgEBAQMBIxEzEgULAgEIDgoCAiYCAgIwFRACBA4FgyGBegipRIE?= =?us-ascii?q?uhTyEbYELilwXgUE/gREnH4JMhH44AoJKMYImAoh6lUJUCQKHbYkYGIFSjna?= =?us-ascii?q?CapQVAhEUgSY0IYFVcBU7KgGCQYImF44ab4EoiAMHgScBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,445,1534809600"; d="scan'208";a="470282162" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 19:30:46 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9UJUkA6016034 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 19:30:46 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Oct 2018 14:30:45 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1395.000; Tue, 30 Oct 2018 14:30:45 -0500 From: "Darren Dukes (ddukes)" To: Joel Halpern CC: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUampMSmaiE2sUnkOZwbcZBqOzaaUyIfaAgAAQcoCABlqwgA== Date: Tue, 30 Oct 2018 19:30:45 +0000 Message-ID: <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> In-Reply-To: <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.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: [161.44.212.148] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [spring] SRv6 - SRH in encaps or base header - point 2 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 19:30:52 -0000 SSB0aGluayB3ZeKAmXJlIGFsbW9zdCBjb25jbHVkZWQgc28gb25jZSBtb3JlIGlubGluZSBhdCA8 ZGQ+PC9kZD4NCg0KPiBPbiBPY3QgMjYsIDIwMTgsIGF0IDI6MjggUE0sIEpvZWwgSGFscGVybiA8 am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+IA0KPiAocmVzZW5kaW5nLCArc3ByaW5nIGFz IHJlcXVlc3RlZCkNCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhlIHJlc3BvbnNlcy4gIEkgd2lsbCBy ZXNwb25kIGluIGxpbmUsIG1hcmtlZCA8am1oPjwvam1oPi4gIEkgZmVhciBpdCB3aWxsIHNob3J0 bHkgZ2V0IHRvbyBkZWVwLCBidXQgdGhlIGNvbnRleHQgaXMgaW1wb3J0YW50Lg0KPiANCj4gSSB3 aWxsIHJlcGhyYXNlIGhlcmUgYW4gaXNzdWUgZnJvbSBhbm90aGVyIHRocmVhZCB0aGF0IEkgYWh2 ZSBub3Qgc2VlbiB5b3VyIGNvbW1lbnRzIG9uLiAgSWYgTm9kZSA5IGlzIHNlbmRpbmcgdHJhZmZp YyB0byBOb2RlIDEgKGZvciBleGFtcGxlLCB0aGUgcmV2ZXJzZSB0cmFmZmljIGZvciB0aGUgdHJh ZmZpYyBmcm9tIDEgdG8gOSBpbiB0aGUgZXhhbXBsZXMgYmVsb3cpLCBpdCBwcmVzdW1hYmx5IGhh cyBhbiBTUiBQb2xpY3kgdG8gYmUgYXBwbGllZC4gVGhlIGlzc3VlIEkgcmFpc2VkIGJlZm9yZSBp cyB0aGUgbGVha2FnZSBpc3N1ZS4gIElmIDkgcHV0cyB0aGUgU1JIIGluIGl0cyBwYWNrZXQgKGFz IHRoZSBkb2N1bWVudCBjdXJyZW50bHkgbWFuZGF0ZXMpLCB0aGVuIGl0IHdpbGwgbm90IGJlIHBv c3NpYmxlIGZvciAzIHRvIHJlbW92ZSB0aGUgU1JILiAgVGh1cywgdGhlIFNSSCB3aWxsIGxlYWsu DQo+IA0KPiBTb21lIGhhdmUgYXJndWVkIHRoYXQgaXMgbm90IGEgYmlnIGRlYWwuICBJdCBzZWVt cyB0byBtYXR0ZXIgdG8gbWUuICBCdXQgdGhlcmUgaXMgYW4gYWRkaXRpb25hbCBwcm9ibGVtLiAg QTEgaXMgbm90IGEgU0lELiAgVGhlcmVmb3JlLCA5IGNhbiBub3QgcHV0IEExIGludG8gdGhlIFNS SC4gIElmIGl0IGNhbiBub3QgcHV0IEExIGludG8gdGhlIFNSSCwgYW5kIGl0IGRvZXMgbm90IGVu Y2Fwc3VsYXRlIHRoZSBwYWNrZXQsIHdoZXJlIGRvZXMgaXQgcHV0IEExLg0KDQo8ZGQ+IE5vZGUg OSBoYXMgYSBjaG9pY2UsIGVuY2Fwc3VsYXRlIHRvIG5vZGUgMyBvciBub3QuIA0KSWYgbm9kZSA5 IGRvZXMgbm90IGVuY2Fwc3VsYXRlLCBpdCB3aWxsIGluZm9ybSB0aGUgZGVzdGluYXRpb24gb2Yg dGhlIHNlZ21lbnRzIGluIHRoZSBTUkggYW5kIHBvc3NpYmx5IGxlYWsgdGhlbSB0byBpbnRlcm1l ZGlhdGUgbm9kZXMuDQpJZiBub2RlIDkgZG9lcyBlbmNhcHN1bGF0ZSwgbm9kZSAzIHJlbW92ZXMg dGhlIG91dGVyIGhlYWRlciBhbmQgbm9kZSAxIHdvdWxkIG5vdCBsZWFybiB0aGUgc2VnbWVudCBs aXN0Lg0KSSB0aGluayBpdHMgY2hvaWNlIHNob3VsZCBub3QgYmUgbWFuZGF0ZWQgaW4gdGhlIGRy YWZ0LiA8L2RkPg0KDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gT24gMTAvMjYvMTggMToy OSBQTSwgRGFycmVuIER1a2VzIChkZHVrZXMpIHdyb3RlOg0KPj4gSGkgSm9lbCwgeW914oCZdmUg ZGVzY3JpYmVkIHNlY3Rpb25zIHRpdGxlZCDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLCDi gJxUcmFuc2l0IFBhY2tldCBUaHJvdWdoIFNSIERvbWFpbuKAnSwgYW5kICJTUiBTb3VyY2UgTm9k ZXMgTm90IERpcmVjdGx5IENvbm5lY3RlZOKAnS4NCj4+IEnigJl2ZSBwYXJzZWQgdGhlbSBpbmxp bmUgdG8gdGhlIHNlY3Rpb25zIG9mIHRoZSBkcmFmdCBkZWZpbmluZyB0aGVtIGFuZCBnaXZlbiBt b3JlIGNvbnRleHQgd2hlcmUgbmVlZGVkLg0KPj4+IE9uIE9jdCAyMiwgMjAxOCwgYXQgODo0OSBQ TSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+PiANCj4+ PiBSZXBocmFzaW5nIHVzaW5nIHRoZSBleGFtcGxlIGZyb20gNS4yLiAgQXNzdW1pbmcgdGhhdCA4 IGFuZCA5IGFyZSBTUiBIb3N0cyAobm90IGp1c3QgaG9zdHMgd2l0aGluIHRoZSBkb21haW4sIHRo ZXkgYXJlIGNhcGFibGUgb2YgYW5kIGV4cGVjdCB0byBkZWFsIHdpdGggU1JIcywgYW5kIHRoZXJl Zm9yZSBoYXZlIGxvY2FsIFNJRHMsIC4uLikNCj4+PiANCj4+PiBGb3IgdHJhZmZpYyBmcm9tIDgg dG8gOSB0aGF0IG5lZWRzIGFuIFNSSCwgdGhlIFNSSCBnb2VzIGluIHRoZSBJUHY2IGhlYWRlciBz ZW50IG15IDggdG8gOS4gIFdoZW4gOSBwcm9jZXNzZXMgdGhlIHBhY2tldCwgaXQgc2VlbXMgdGhh dCBpdCBpcyB0aGUgbGFzdCBTSUQsIGZpZ3VyZXMgb3V0IHRoYXQgdGhlcmUgaXMgbm8gZW5jYXBz dWxhdGlvbiwgYW5kIHNlbmQgdGhlIFRDUCAvIFVEUCAvIFFVSUMgaW5mb3JtYXRpb24gdG8gaXRz IGludGVybmFsIHByb3RvY29scyBzdGFja3MuDQo+PiBZZXMsIHRoaXMgaXMgU2VjdGlvbiA1LjMu MSDigJxJbnRyYSBTUiBEb21haW4gUGFja2V04oCdLg0KPiA8am1oPkFncmVlZCBhcyBmYXIgYXMg aXQgZ29lcy4gIEhvd2V2ZXIsICB0aGUgZXhpc3RlbmNlIG9mIFM5IGFuZCBBOSBwb2ludHMgdG8g YSBwcm9ibGVtLiAgTm9kZSA4IGlzIHRyeWluZyB0byBwdXQgb24gYW4gU1JIIGdvaW5nIHRocm91 Z2ggU3gsIFN5LCB3aGF0ZXZlciBmb3Igc29tZSByZWFzb24uICBJdCBjYW4ndCBwdXQgQTkgaW50 byB0aGUgU1JILCBhcyBBSCBpcyBub3QgYSBTSUQsIGl0IGlzIGFuIGFkZHJlc3MuICBJIHByZXN1 bWUgbm9kZSA4IGdvdCBTOSBmcm9tIHdoYXRldmVyIHByb3ZpZGVkIGhpbSB0aGUgU1IgUG9saWN5 IHRoYXQgaXQgaXMgdXNpbmcuICBEb2VzIGl0IHNpbXBseSB1c2UgUzkgYXMgdGhlIGFkZHJlc3Mg Zm9yIG5vZGUgOSwgcmF0aGVyIHRoYW4gQTkgdGhhdCBpdCBnb3QgZnJvbSBETlM/ICBBbmQgZG9l cyB0aGUgVENQIHN0YWNrIGtub3cgdGhhdCB0aGlzIHN1YnN0aXR1dGlvbiBpcyBiZWluZyBtYWRl PyAgKFRoaXMgaXMgYW5vdGhlciBleGFtcGxlIG9mIGEgcHJvYmxlbSB0aGF0IGdvZXMgYXdheSBp ZiB3ZSBhbHdheXMgZW5jYXBzdWxhdGUuKSA8L2ptaD4NCg0KPGRkPlNlY3Rpb24gNC4zLjIgY292 ZXJzIHRoZXNlIHF1ZXN0aW9ucywgaS5lLiBBOSBjYW4gYmUgcGxhY2VkIGluIHRoZSBTUkggYXMg dGhlIGxhc3Qgc2VnbWVudCwgYW5kIHRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaG93IGl04oCZcyBo YW5kbGVkLjwvZGQ+IA0KDQo+IA0KPj4+IA0KPj4+IEZvciB0cmFmZmljIGZyb20gMSB0byA5LCB3 aGVyZSAzIGFkZHMgYW4gU1JILCB0aGF0IFNSSCBzdGlsbCBwcmVzdW1hYmx5IGVuZHMgYXQgOS4g IDkgUmVjZWl2ZXMgdGhlIElQIHBhY2tldC4gIFNlZXMgdGhhdCBpdCBpcyBhZGRyZXNzZWQgdG8g aXRzZWxmLiAgU2VlcyB0aGF0IHRoZSBTUkggaXMgZmluaXNoZWQuICBBbmQgdGhlbiBub3RpY2Vz IHRoYXQgdGhlIG5leHQtaGVhZGVyIGlzIElQdjYuICBVbndyYXBzIHRoZSBoZWFkZXIsIGNoZWNr cyB0aGF0IHRoZSBpbm5lciBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGFsc28gaXRzZWxmLCBhbmQg cGFzc2VzIHRoZSBtYXRlcmlhbCBjYXJyaWVkIGJ5IHRoZSBpbm5lciBoZWFkZXIgdXAgdG8gdGhl IGFwcHJvcHJpYXRlIHN0YWNrLg0KPj4gU28gbm9kZSAxIHNlbmRzIGEgcGFja2V0IHRvIG5vZGUg OSAoQTEsQTkpDQo+PiBJRiB0aGVyZSBpcyBzb21lIHN0ZWVyaW5nIGludG8gYW4gU1IgUG9saWN5 IGF0IG5vZGUgMyB0byByZWFjaCBub2RlIDksIHRoaXMgaXMgaWRlbnRpY2FsIHRvIHNlY3Rpb24g NS4zLjIg4oCcVHJhbnNpdCBwYWNrZXQgdGhyb3VnaCBTUiBkb21haW7igJ0sIGV4Y2VwdCBmb3Ig ZGVzdGluYXRpb24gb2YgQTkgdmlhIG5vZGUgOSAgaW5zdGVhZCBvZiBBMiB2aWEgbm9kZSA0Lg0K PiANCj4+PiANCj4+PiBUaHVzLCA5IG5lZWRzIHRvIGJlIGFibGUgdG8gY2hlY2sgZm9yIGJvdGgg Y2FzZXMuICBXZSBhdCBsZWFzdCBuZWVkIHRvIHRlbGwgaW1wbGVtZW50b3JzIHRoYXQuDQo+PiBX ZWxsLCA5IG5lZWRzIGEgU0lEIFM5IGFuZCBBZGRyZXNzIEE5LiAgVGhhdCBpcyBzaG93biBpbiBT ZWN0aW9uIDUuMSBTSUQgYW5kIGFkZHJlc3MgcmVwcmVzZW50YXRpb24uDQo+IDxqbWg+U28sIGxl dCB1cyBhc3N1bWUgdGhhdCAzIGhhcyBhbiBTUiBwb2xpY3kgaXQgd2FudHMgdG8gYXBwbHkgdG8g dGhlIHRyYWZmaWMgZnJvbSBBMSB0byBBOS4gIEluIHRoaXMgY2FzZSwgdGhlIFM5IC8gQTkgZGlj aG90b215IGlzIG5vdCBhIHByb2JsZW0sIEkgdGhpbmsuICBOb2RlIDMgZW5jYXBzdWFsdGVzIHRo ZSBwYWNrZXQgZnJvbSBBMSB0byBBOSwgdXNlcyBTMyBhcyB0aGUgc291cmNlIGFkZHJlc3Mgb2Yg dGhlIGVuY2Fwc3VsYXRpbmcgaGVhZGVyLCBhbmQgZW5kcyB0aGUgU0lEIGxpc3QgaW4gdGhlIFNS SCB3aXRoIFM5LiAgVGhlIHVuc3BlY2lmaWVkIHBhcnQgaXMgdGhhdCBub2RlIDkgbmVlZHMgdG8g YmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBzdWNoIHBhY2tldHMgYW5kIGRvIHRoZSBkb3VibGUgcHJv Y2Vzc2luZy4gIEl0IGlzIHJlYXNvbmFibGUgZG91YmxlIHByb2Nlc3NpbmcuICBNeSBvbmx5IHJl cXVlc3QgaGVyZSBpcyB0aGF0IHdlIHRlbGwgZm9sa3MgdGhleSBuZWVkIHRvIHN1cHBvcnQgaXQu IDwvam1oPg0KDQo8ZGQ+QWN0dWFsbHksIG5vZGUgMyB1c2VzIEEzIGFzIGl0cyBzb3VyY2UgYWRk cmVzcywgYnV0IHRoYXTigJlzIG1pbm9yLg0KVGhlIGRvdWJsZSBwcm9jZXNzaW5nIChsb29rdXAs IGRvIGVuZCBwcm9jZXNzaW5nLCBkbyBhbm90aGVyIGxvb2t1cCkgaXMgZG9jdW1lbnRlZCBpbiBT ZWN0aW9uIDQuMy4NCklzIHRoZXJlIGEgbmVlZCBmb3IgbW9yZSB0aGFuIHdoYXQgaXMgY3VycmVu dGx5IHNwZWNpZmllZD8gPC9kZD4NCg0KPj4+IA0KPj4+IFRoZXJlIGlzIGEgZnVydGhlciBjb21w bGljYXRpb24uICA5IHNlZW1zIHRvIG5lZWQgdG8gaGF2ZSBhbiBhZGRyZXNzIHRoYXQgaXMgYSB2 YWxpZCBTSUQsIHNvIGl0IGNhbiBiZSB0aGUgbGFzdCBlbnRyeSBpbiB0aGUgU1JIIGZyb20gOCB0 byA5Lg0KPj4gQXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCwgU2VjdGlvbiA1LjEgYSBub2RlIGsg aGFzIGFuIGFkZHJlc3MgQWsgYW5kIFNJRCBTay4gIFNvIG5vZGUgOSBoYXMgYSB2YWxpZCBTSUQu DQo+PiBGb3IgdHJhZmZpYyBmcm9tIDggdG8gOSwgQTkgaXMgdXNlZCBhcyB0aGUgZGVzdGluYXRp b24gYXMgc2hvd24gaW4gc2VjdGlvbiA1LjMuMSwgNS40IGFuZCA1LjUuDQo+Pj4gIEhvd2V2ZXIs IGlmIDEgd2VyZSB0byBzZW5kIHRoZSBwYWNrZXQgdG8gdGhhdCBTSUQgZm9yIDksIHJvdXRlciAz IHdvdWxkIGJlIHJlcXVpcmVkIGJ5IHRoZSBydWxlcyB3ZSBkaXNjdXNzZWQgaW4gdGhlIG90aGVy IHRocmVhZCB0byBkaXNjYXJkIHRoZSBwYWNrZXQgYXMgaXQgaXMgbmVpdGhlciB0byBwcmVmaXgg bm9yIGNvbnRhaW5zIGFuIEhBTUMuDQo+Pj4gIEFuZCBzb21laG93LCA4IGFuZCAxIG5lZWQgdG8g ZWFjaCBwaWNrIHRoZSByaWdodCBhZGRyZXNzIHRvIHVzZSBmb3IgOS4gKHNwbGl0IEROUyBtYXli ZT8pICBBbmQgMyBuZWVkcyB0byBiZSBhYmxlIHRvIGRlcml2ZSB0ZWggU0lELWZvcm1uIGFkZHJl c3MgZm9yIDkgZnJvbSB0aGUgbm9uLVNJRCBmb3JtIG9mIHRoZSBhZGRyZXNzIHNvIHRoYXQgaXQg KDMpIGNhbiBidWlsZCBhIHByb3BlciBTUkggdG8gZ2V0IHRoZSBwYWNrZXQgdG8gOS4NCj4gPGpt aD5JIGhhdmUgcmV0YWluZWQgeW91ciBhbnN3ZXIgYmVsb3cgZm9yIGNvbnRleHQsIGJ1dCBJIHRo aW5rIHRoYXQgYW5zd2VycyB0aGUgd3JvbmcgcXVlc3Rpb24uICBJIGJlbGlldmUgd2hhdCBpcyBp dG5lbmRlZCBpcyB0aGF0IG9ubHkgQTkgYXBwZWFycyBpbiBETlMuICBTbyBOb2RlIDEgd2lsbCBz ZWUgOSBhcyBBOSwgYW5kIHdpbGwgdXNlIHRoYXQuICBTOSB3aWxsIGFwcGVhciBpbiBTUiBQb2xp Y2llcyBhYm91dCB0cmFmZmljIHRvIG5vZGUgOSwgYnV0IG5vdCBpbiBETlMuICBUaGF0IGlzIHdo YXQgd2UgbmVlZC4gIEkgd2lzaCBpdCB3ZXJlIGNsZWFyZXIgaW4gdGhlIHRleHQuIDwvam1oPg0K PiANCj4gPGptaD5JZiBub2RlIDIwIGlzIGdlbmVyYXRpbmcgU1JIcyB3aXRoIEhNQUNzLCB0aGVu IHRoaXMgaXMgbGFyZ2VseSB0aGUgc2FtZSBhcyB0aGUgY2FzZSBmcm9tIDggdG8gOSwgZXhjZXB0 IHRoYXQgd2hvbWV2ZXIgY3JlYXRlcyB0aGUgU1IgUG9saWN5IHRoYXQgMjAgaXMgdXNpbmcgbmVl ZHMgdG8gYWxzbyBtYWtlIHN1cmUgdGhhdCB3aGF0ZXZlciB0aGUgZmlyc3QgU0lEIGlzIGluIHRl aCBsaXN0LCBpdCBwcm9jZXNzZXMgSE1BQ3MgYW5kIGlzIHJlY29nbml6YWJsZSB0byBub2RlIDMg YXMgZG9pbmcgc3VjaCBwcm9jZXNzaW5nLiBJIGFtIGd1ZXNzaW5nIHRoYXQgdGhlIHJlYXNvbiBm b3IgYWxsb3dpbmcgaW50ZXJuYWwgbm9kZXMgdG8gZG8gdGhlIHByb2Nlc3NpbmcgaXMgdG8gbW92 ZSB0aGUgdmVyaWZpY2F0aW9uIGxvYWQgb2ZmIHRoZSBlZGdlIG5vZGVzLiAgSXQgZG9lcyBjcmVh dGUgc2lnbmlmaWNhbnQgYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIGNvbXBsZXhpdHkuIDwvam1o Pg0KDQo8ZGQ+V2UgZGlkbuKAmXQgc2VlIGEgcmVhc29uIHRvIHJlc3RyaWN0IHRoZSBITUFDIHBy b2Nlc3NpbmcgdG8gb25seSBlZGdlIG5vZGVzIHdoZW4gaXQgd2FzIHN0cmFpZ2h0IGZvcndhcmQg dG8gZGVmaW5lIGhvdyB0aGV5IGNvdWxkIGJlIHByb2Nlc3NlZCBhdCBub24tZWRnZSBub2Rlcy48 L2RkPg0KDQo+IA0KPj4gVGhpcyBpcyBpbmNvcnJlY3QuDQo+PiBTZWUgU2VjdGlvbiA2LjIuMSDi gJxTUiBTb3VyY2UgTm9kZXMgTm90IERpcmVjdGx5IENvbm5lY3RlZOKAnSBJIHdpbGwgZXhwYW5k IG9uIHRoZSBleGFtcGxlIGZyb20gdGhhdCBzZWN0aW9uLg0KPj4gTm9kZSAyMCBzZW5kcyBhIHBh Y2tldCB0byBBOSB3aXRoIFNSIFBvbGljeSA8SDc+IGFuZCBhbiBITUFDIHByb3ZpZGVkIHRvIG5v ZGUgMjAgYnkgc29tZSB5ZXQgdG8gYmUgZGVmaW5lZCBtZXRob2QuICBSZXN1bHRpbmcgaW4gcGFj a2V0IHNlbnQgZnJvbSBub2RlIDIwDQo+PiAgIFA6IChBMjAsSDcpKEE5O1NMPTEpKHBheWxvYWQp DQo+PiBSZWNhbGwgSGsgaXMgYSBTSUQgYXQgbm9kZSBrIHJlcXVpcmluZyBITUFDIHZlcmlmaWNh dGlvbiwgYW5kIGl0IGlzIGNvdmVyZWQgYnkgUHJlZml4LUguDQo+PiBQcmVmaXgtSCBpcyBfbm90 XyBzdWJqZWN0IHRvIGluZ3Jlc3MgZmlsdGVyaW5nIGF0IG5vZGUgMy4NCj4+IFRoZXJlZm9yZSB0 aGUgcGFja2V0IFAgZGVzdGluZWQgdG8gSDcgaXMgbm90IHN1YmplY3QgdG8gaW5ncmVzcyBmaWx0 ZXJpbmcgYXQgbm9kZSAzLg0KPj4gUCBpcyBmb3J3YXJkZWQgdG8gbm9kZSA3LCB3aGVyZSBINyBp cyBwcm9jZXNzZWQgYW5kIHRoZSBITUFDIHZlcmlmaWVkLg0KPj4gSWYgdGhlIEhNQUMgY2FuIG5v dCBiZSB2ZXJpZmllZCB0aGUgcGFja2V0IGlzIGRyb3BwZWQsIGVsc2UgaXQgaXMgZm9yd2FyZGVk IHRvIHRoZSBuZXh0IHNlZ21lbnQgYW5kIGRlc3RpbmF0aW9uLCBBOS4NCj4+IERhcnJlbg0KPj4+ IA0KPj4+IFlvdXJzLA0KPj4+IEpvZWwNCj4+PiANCj4+PiBPbiAxMC8yMi8xOCA4OjA0IFBNLCBE YXJyZW4gRHVrZXMgKGRkdWtlcykgd3JvdGU6DQo+Pj4+IGlubGluZS4NCj4+Pj4+IE9uIE9jdCAy MiwgMjAxOCwgYXQgNzoyMSBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29t PiB3cm90ZToNCj4+PiAuLg0KPj4+Pj4gMikgTm93IGxldCB1cyBsb29rIGF0IHBhY2tldHMgYXJy aXZpbmcgYXQgYW5kIGFjdHVhbGx5IGRlc3RpbmVkIGZvciBhbiBTUiBIb3N0IGluIHRoZSBTUiBE b21haW4gd2hlcmUgdGhhdCBwYWNrZXQgaGFzIGFuIFNSSC4gIElmIHRoZSBwYWNrZXQgaXMgY29t aW5nIGZyb20gYW5vdGhlciBTUiBIb3N0LCB0aGUgU1JIIHdpbGwgYmUgaW4gdGhlIGJhc2UgaGVh ZGVyLCBhbmQgdGhlIGhvc3QgY2FuIHNpbXBseSBjaGVjayBpdCBmb3IgYW55IHZpb2xhdGlvbnMs IGFuZCBjb250aW51ZS4gIEJ1dCwgaWYgdGhlIHBhY2tldCBjYW1lIGZyb20gb3V0c2lkZSB0aGUg ZG9tYWluLCB0aGVuIGl0IHdpbGwgaGF2ZSBhbiBlbmNhcHN1bGF0aW5nIFNSdjYgaGVhZGVyLiAg U28gdGhlIGhvc3QgaGFzIHRvIGRldGVjdCB0aGlzIGNhc2UsIGNoZWNrIGFuZCB0aGVuIHBlYWwg b2ZmIHRoZSBlbmNhcHN1bGF0aW5nIGhlYWRlciwgYW5kIHRoZW4gcHJvY2VzcyB0aGUgcmVjZWl2 ZWQgcGFja2V0LiBZZXMsIGl0IGNhbiBkbyBzby4gIEJ1dCBub3RoaW5nIGluIHRlaCBkb2N1bWVu dCB0ZWxscyBpbXBsZW1lbnRvcnMgdGhleSBoYXZlIHRvIGRlYWwgd2l0aCBib3RoIGNhc2VzLg0K Pj4+Pj4gDQo+Pj4+IENhbiB5b3UgYmUgbW9yZSBwcmVjaXNlIGhlcmUuICBQZXJoYXBzIHVzZSB0 aGUgZXhhbXBsZSBmcm9tIHNlY3Rpb24gNS4yIG9yIDYuMi4xPw0KPj4+IC4uDQoNCg== From nobody Tue Oct 30 12:42:39 2018 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 5C28B130DCB; Tue, 30 Oct 2018 12:42:37 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 1hPYdSkaYy-v; Tue, 30 Oct 2018 12:42:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 CA5F1130DC0; Tue, 30 Oct 2018 12:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 6E3C670F01F; Tue, 30 Oct 2018 12:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540928554; bh=oBRgviLKdwAuhnFaxR2NuukmHtDxIbY2Roqc1ZT5q2E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZuBFFc/5tH3w4EfBr9fhU5l0YwaQrwloZxcDgsixT6CvHsK+HfhGQ+5zpUS4o3lj5 w07GLybzxAN+XH8DzHTYBg+6CxEEXtsSgdz7tYpQQoDSQ9/khnTn/K64Ip3ku1UmNu A4hY4w7B2lbV70P5C1A5xiEDCpDh+UHYecKnvkOc= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [205.153.92.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BF42870F019; Tue, 30 Oct 2018 12:42:33 -0700 (PDT) To: "Darren Dukes (ddukes)" Cc: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> From: "Joel M. Halpern" Message-ID: <11918c9b-f0bb-4182-cdbe-9ed720b0a800@joelhalpern.com> Date: Tue, 30 Oct 2018 15:42:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] SRv6 - SRH in encaps or base header - point 2 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 19:42:38 -0000 I am not sure I agree that the allowance for handling the HMAC elsewhere is straightforward. For example, I think the range of implementation strategies for border nodes and the intersection of that with the range of operational and deployment strategies is going to actually make it harder to get multi-vendor deployments. Having said that, the approach in the document will work. And I can live with it. On the choice of encaps or not encaps (from node 9 to external node 1) there are two issues. The important issue is that node 9 needs to be able to encaps. Otherwise there is no decision availabe, and the nodes software is forcing the operator to disclose, even if there policy is not to do so. Thus, I think the minimum requirement is that the document needs to clearly state that node 9 needs to be able to handle incoming encaps and needs to be able to generate outgoing encaps. The lesser issue is "why bother?" Why not always encaps. Given that the network has to have an MTU big enough to handle an encaps packet (due to incoming packets from out the SR domain), there is no MTU issue wiht the encaps. As such, we are talking about reducing the security and robustness of the solution in exchange for saving a few bytes. That almost never turns out well. Yours, Joel On 10/30/18 3:30 PM, Darren Dukes (ddukes) wrote: > I think we’re almost concluded so once more inline at
> >> On Oct 26, 2018, at 2:28 PM, Joel Halpern wrote: >> >> (resending, +spring as requested) >> >> Thank you for the responses. I will respond in line, marked . I fear it will shortly get too deep, but the context is important. >> >> I will rephrase here an issue from another thread that I ahve not seen your comments on. If Node 9 is sending traffic to Node 1 (for example, the reverse traffic for the traffic from 1 to 9 in the examples below), it presumably has an SR Policy to be applied. The issue I raised before is the leakage issue. If 9 puts the SRH in its packet (as the document currently mandates), then it will not be possible for 3 to remove the SRH. Thus, the SRH will leak. >> >> Some have argued that is not a big deal. It seems to matter to me. But there is an additional problem. A1 is not a SID. Therefore, 9 can not put A1 into the SRH. If it can not put A1 into the SRH, and it does not encapsulate the packet, where does it put A1. > >
Node 9 has a choice, encapsulate to node 3 or not. > If node 9 does not encapsulate, it will inform the destination of the segments in the SRH and possibly leak them to intermediate nodes. > If node 9 does encapsulate, node 3 removes the outer header and node 1 would not learn the segment list. > I think its choice should not be mandated in the draft.
> >> >> Yours, >> Joel >> >> On 10/26/18 1:29 PM, Darren Dukes (ddukes) wrote: >>> Hi Joel, you’ve described sections titled “Intra SR Domain Packetâ€, “Transit Packet Through SR Domainâ€, and "SR Source Nodes Not Directly Connectedâ€. >>> I’ve parsed them inline to the sections of the draft defining them and given more context where needed. >>>> On Oct 22, 2018, at 8:49 PM, Joel M. Halpern wrote: >>>> >>>> Rephrasing using the example from 5.2. Assuming that 8 and 9 are SR Hosts (not just hosts within the domain, they are capable of and expect to deal with SRHs, and therefore have local SIDs, ...) >>>> >>>> For traffic from 8 to 9 that needs an SRH, the SRH goes in the IPv6 header sent my 8 to 9. When 9 processes the packet, it seems that it is the last SID, figures out that there is no encapsulation, and send the TCP / UDP / QUIC information to its internal protocols stacks. >>> Yes, this is Section 5.3.1 “Intra SR Domain Packetâ€. >> Agreed as far as it goes. However, the existence of S9 and A9 points to a problem. Node 8 is trying to put on an SRH going through Sx, Sy, whatever for some reason. It can't put A9 into the SRH, as AH is not a SID, it is an address. I presume node 8 got S9 from whatever provided him the SR Policy that it is using. Does it simply use S9 as the address for node 9, rather than A9 that it got from DNS? And does the TCP stack know that this substitution is being made? (This is another example of a problem that goes away if we always encapsulate.) > >
Section 4.3.2 covers these questions, i.e. A9 can be placed in the SRH as the last segment, and this section describes how it’s handled.
> >> >>>> >>>> For traffic from 1 to 9, where 3 adds an SRH, that SRH still presumably ends at 9. 9 Receives the IP packet. Sees that it is addressed to itself. Sees that the SRH is finished. And then notices that the next-header is IPv6. Unwraps the header, checks that the inner destination address is also itself, and passes the material carried by the inner header up to the appropriate stack. >>> So node 1 sends a packet to node 9 (A1,A9) >>> IF there is some steering into an SR Policy at node 3 to reach node 9, this is identical to section 5.3.2 “Transit packet through SR domainâ€, except for destination of A9 via node 9 instead of A2 via node 4. >> >>>> >>>> Thus, 9 needs to be able to check for both cases. We at least need to tell implementors that. >>> Well, 9 needs a SID S9 and Address A9. That is shown in Section 5.1 SID and address representation. >> So, let us assume that 3 has an SR policy it wants to apply to the traffic from A1 to A9. In this case, the S9 / A9 dichotomy is not a problem, I think. Node 3 encapsualtes the packet from A1 to A9, uses S3 as the source address of the encapsulating header, and ends the SID list in the SRH with S9. The unspecified part is that node 9 needs to be prepared to receive such packets and do the double processing. It is reasonable double processing. My only request here is that we tell folks they need to support it. > >
Actually, node 3 uses A3 as its source address, but that’s minor. > The double processing (lookup, do end processing, do another lookup) is documented in Section 4.3. > Is there a need for more than what is currently specified?
> >>>> >>>> There is a further complication. 9 seems to need to have an address that is a valid SID, so it can be the last entry in the SRH from 8 to 9. >>> As described in the draft, Section 5.1 a node k has an address Ak and SID Sk. So node 9 has a valid SID. >>> For traffic from 8 to 9, A9 is used as the destination as shown in section 5.3.1, 5.4 and 5.5. >>>> However, if 1 were to send the packet to that SID for 9, router 3 would be required by the rules we discussed in the other thread to discard the packet as it is neither to prefix nor contains an HAMC. >>>> And somehow, 8 and 1 need to each pick the right address to use for 9. (split DNS maybe?) And 3 needs to be able to derive teh SID-formn address for 9 from the non-SID form of the address so that it (3) can build a proper SRH to get the packet to 9. >> I have retained your answer below for context, but I think that answers the wrong question. I believe what is itnended is that only A9 appears in DNS. So Node 1 will see 9 as A9, and will use that. S9 will appear in SR Policies about traffic to node 9, but not in DNS. That is what we need. I wish it were clearer in the text. >> >> If node 20 is generating SRHs with HMACs, then this is largely the same as the case from 8 to 9, except that whomever creates the SR Policy that 20 is using needs to also make sure that whatever the first SID is in teh list, it processes HMACs and is recognizable to node 3 as doing such processing. I am guessing that the reason for allowing internal nodes to do the processing is to move the verification load off the edge nodes. It does create significant additional configuration complexity. > >
We didn’t see a reason to restrict the HMAC processing to only edge nodes when it was straight forward to define how they could be processed at non-edge nodes.
> >> >>> This is incorrect. >>> See Section 6.2.1 “SR Source Nodes Not Directly Connected†I will expand on the example from that section. >>> Node 20 sends a packet to A9 with SR Policy and an HMAC provided to node 20 by some yet to be defined method. Resulting in packet sent from node 20 >>> P: (A20,H7)(A9;SL=1)(payload) >>> Recall Hk is a SID at node k requiring HMAC verification, and it is covered by Prefix-H. >>> Prefix-H is _not_ subject to ingress filtering at node 3. >>> Therefore the packet P destined to H7 is not subject to ingress filtering at node 3. >>> P is forwarded to node 7, where H7 is processed and the HMAC verified. >>> If the HMAC can not be verified the packet is dropped, else it is forwarded to the next segment and destination, A9. >>> Darren >>>> >>>> Yours, >>>> Joel >>>> >>>> On 10/22/18 8:04 PM, Darren Dukes (ddukes) wrote: >>>>> inline. >>>>>> On Oct 22, 2018, at 7:21 PM, Joel M. Halpern wrote: >>>> .. >>>>>> 2) Now let us look at packets arriving at and actually destined for an SR Host in the SR Domain where that packet has an SRH. If the packet is coming from another SR Host, the SRH will be in the base header, and the host can simply check it for any violations, and continue. But, if the packet came from outside the domain, then it will have an encapsulating SRv6 header. So the host has to detect this case, check and then peal off the encapsulating header, and then process the received packet. Yes, it can do so. But nothing in teh document tells implementors they have to deal with both cases. >>>>>> >>>>> Can you be more precise here. Perhaps use the example from section 5.2 or 6.2.1? >>>> .. > From nobody Tue Oct 30 14:24:28 2018 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 7E328128CFD; Tue, 30 Oct 2018 14:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.491 X-Spam-Level: X-Spam-Status: No, score=-14.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Pju0CHs66r-Q; Tue, 30 Oct 2018 14:24:25 -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 91345124408; Tue, 30 Oct 2018 14:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47924; q=dns/txt; s=iport; t=1540934664; x=1542144264; h=from:to:cc:subject:date:message-id:mime-version; bh=oIAKgA8Ecj5/XH78i/mMLry/STvu+e9RH4qeZJGvzlE=; b=ONTQw8En9AchwSALdWVLeHiTERUgzGlGNAnnvoVfdY8oGtjJUO9YMnbM ILu+Iw36uI4wnfxCg6bT3jWf7hL6zQZsWBVsTF+U8rpWdZaeq7O+U5VKL 2uBmAYw29rBhLDhorykWQRMsviqKzmpBRrRAs10Go92UfFzv09zcMUzZK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACBy9hb/4wNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1NKmZ/KAqDbIgYjiaJAI4gFIFmCwE?= =?us-ascii?q?BJYRHAheDDSI0DQ0BAwEBAgEBAm0cDIU6AQEFHQZWEgEIEQMBAQEhAQYDAgQ?= =?us-ascii?q?fERQJCgQBDQWDIQGBHUwDFQ8DqTCBLoQtAQMCg1ENghMFi2cXggCBEScfgky?= =?us-ascii?q?CVkUBAQIBF4EUARIBPxaCTjGCJgKIY0iFJYYjiXEuCQKGaYZ0gykYgVOEd4M?= =?us-ascii?q?chTuBKIgEgTWDPoEBiQkCERSBJh04ZHFwFTsqAYJBgiYXfQEIh1aFPm+KAoE?= =?us-ascii?q?fgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,446,1534809600"; d="scan'208,217";a="473436736" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 21:24:23 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w9ULOMB9027549 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 21:24:23 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Oct 2018 17:24:22 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Tue, 30 Oct 2018 17:24:22 -0400 From: "Acee Lindem (acee)" To: "bruno.decraene@orange.com" , Ahmed Bashandy CC: "draft-ietf-spring-segment-routing-mpls@ietf.org" , SPRING WG List , "Martin Vigoureux (martin.vigoureux@nokia.com)" , Shraddha Hegde Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Thread-Index: AQHUcJbsPDp6xWSeukaeqI0cuSgUSw== Date: Tue, 30 Oct 2018 21:24:22 +0000 Message-ID: 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.116.152.200] Content-Type: multipart/alternative; boundary="_000_C46F5EEC27CA47B8A9DABAC51E7FB1ADciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 21:24:28 -0000 --_000_C46F5EEC27CA47B8A9DABAC51E7FB1ADciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWhtZWQg4oCTIFRoYW5rcyBtdWNoIGZvciB5b3VyIHdvcmsgcmVzb2x2aW5nIHRoZSBXRyBsYXN0 IGNhbGwgaXNzdWVzIQ0KDQpCcnVubyDigJMgVGhhbmtzIGZvciB0aGUgcGxhbiBmb3IgcHVibGlj YXRpb24uDQoNCkxldOKAmXMga2VlcCBmb2N1cyBvbiB0aGlzIGRyYWZ0IGFzIGl0IGlzIE5vcm1h dGl2ZSByZWZlcmVuY2UgZm9yIGFsbCB0aGUgTFNSIFNlZ21lbnQgUm91dGluZyBkcmFmdHMgaW5j bHVkaW5nIHRoZSBoYW5kbGluZyBmb3IgU0lEIGNvbmZsaWN0cy4NCg0KVGhhbmtzIEFnYWluLA0K QWNlZQ0KDQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBCcnVubyBEZWNyYWVuZSA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4NCkRhdGU6IFR1 ZXNkYXksIE9jdG9iZXIgMzAsIDIwMTggYXQgNzowNSBBTQ0KVG86IEFobWVkIEJhc2hhbmR5IDxh YmFzaGFuZHkuaWV0ZkBnbWFpbC5jb20+DQpDYzogImRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1tcGxzQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LW1wbHNAaWV0Zi5vcmc+LCBTUFJJTkcgV0cgTGlzdCA8c3ByaW5nQGlldGYub3JnPiwgTWFydGlu IFZpZ291cmV1eCA8bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+LCBTaHJhZGRoYSBIZWdkZSA8 c2hyYWRkaGFAanVuaXBlci5uZXQ+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gV0cgTGFzdCBDYWxs IGZvciBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMw0KDQpUaGFua3Mg QWhtZWQuDQoNCk5leHQgc3RlcHMgYXJlIDoNCi0gc2hlcGhlcmQgd3JpdGUgdXAgKFNocmFkZGhh KQ0KLSAyIHdlZWtzIHRvIGFsbG93IFdHIHRvIGNvbW1lbnQgb24gdGhlIGNoYW5nZXMsIGVzcGVj aWFsbHkgZnJvbSBDaHJpcywgUEssIFJ1ZWRpZ2VyLCBTYXNoYSwgU2hyYWRkaGEuDQotIFdHIGNo YWlycyBnbyBhaGVhZCAoZGVsZWdhdGVkIHRvIE1hcnRpbiAoQUQpIGFzIGJvdGggY2hhaXJzIGNv LWF1dGhvcikNCg0KVGhhbmsgeW91LA0KLS1CcnVubw0KDQpGcm9tOiBBaG1lZCBCYXNoYW5keSBb bWFpbHRvOmFiYXNoYW5keS5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAy MiwgMjAxOCA5OjA2IFBNDQpUbzogREVDUkFFTkUgQnJ1bm8gVEdJL09MTjsgZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNAaWV0Zi5vcmcNCkNjOiBTUFJJTkcgV0cgTGlzdA0K U3ViamVjdDogUmU6IFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLW1wbHMtMTMNCg0KDQpJIHVwbG9hZGVkIHZlcnNpb24gMTUgdG8gYWRkcmVzcyB0aGUg Y29tbWVudHMgYmVsb3cgc2luY2UgdG9kYXkgaXMgdGhlIGRlYWRsaW5lIGJlZm9yZSB0aGUgdXBj b21pbmcgSUVURg0KDQpJIHdpbGwgZXhwbGFpbmluZyBob3cgdmVyc2lvbiAxNSBhZGRyZXNzZXMg ZWFjaCBvZiB0aGUgY29tbWVudHMgYmVmb3JlIHRoZSBzdGFydCBvZiB0aGUgSUVURiBuZXh0IHdl ZWsNCg0KVGhhbmtzIGEgbG90IGZvciBhbGwgdGhlIGhlbHAgYW5kIHRoZSBmZWVkYmFjaw0KDQpB aG1lZA0KDQoNCg0KT24gMTAvMTUvMTggOToxMiBBTSwgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4gd3JvdGU6DQpBdXRob3JzLCBBaG1l ZCwNCg0KQ291bGQgeW91IHByb2dyZXNzIG9uIHRoaXMgZG9jdW1lbnQ/DQoNClRocmVhZCBpczog aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zcHJpbmcvP3E9c3ViamVj dCUzQWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzDQoNCkNvbW1lbnRzIHN0 aWxsIHRvIGJlIGFkZHJlc3NlZC9yZXNvbHZlZCBhcmUgdGhlIGZvbGxvd2luZzoNCmh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL3h4LXQ1djVJVzJQXzhyWnlrZUpy dmw5cURJRSAgIChmcm9tIG15c2VsZiBzaW5jZSAyMDE4LTA1LTI0KQ0KaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvQ1JpOTZNbkg0QnN1LXRxbHo1dTI2TWFuOXh3 IChmcm9tIENocmlzIEJvd2VycyBzaW5jZSAyMDE4LTA2LTA4KQ0KaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcveUl3VXZLZGRyY1ItZ3hQUVpTTWpieW5UWDc0IChm cm9tIFBLIHNpbmNlIDIwMTgtMDYtMDkpDQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3NwcmluZy81UEhoTGxNSXhMZ29GZG9SQzFXcXo2eENCbkkgIChmcm9tIFBLIHNpbmNl IDIwMTgtMDYtMDkpDQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3By aW5nL3cwWm1PQWNEZl9UVVVXTGtlRmtfRTZqelFtNCAoZnJvbSBSdWVkaWdlciAyMDE4LTA2LTEz KQ0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvZ0tBNXNxa3Vr M1NuT01BejRuU1NDeEZRSHRRIChmcm9tIFNocmFkZGhhIDIwMTgtMDctMjAgJiArMSBmcm9tIFNh c2hhKQ0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvYzdQYjhw YVR0MVVpYk93X08weWZQVzRmZ09rIChmcm9tIFNhc2hhICYgU3TDqXBoYW5lIGRpc2N1c3Npb24g MjAxOC0wOC0wNikNCg0KDQpBdXRob3JzLCBBaG1lZCwNClRoYW5rIHlvdSBmb3IgZW5nYWdpbmcg dGhlIGF1dGhvcnMgb2YgdGhvc2UgY29tbWVudHMgYW5kIHVwZGF0ZSB0aGUgZHJhZnQuDQoNClRo YW5rIHlvdSwNCi0tQnJ1bm8NCg0KDQoNCkZyb206IERFQ1JBRU5FIEJydW5vIElNVC9PTE4NClNl bnQ6IFRodXJzZGF5LCBKdW5lIDA3LCAyMDE4IDY6NTIgUE0NClRvOiBTUFJJTkcgV0cgTGlzdA0K Q2M6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzQGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBsc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJFOiBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1tcGxzLTEzDQoNCkhpIGFsbCwNCg0KQSBxdWljayB1cGRhdGUgb24gdGhlIHN0YXR1cyBvZiB0 aGlzIFdHTEM6DQoNCi0gQWxsIHRoZSBhdXRob3JzIGhhdmUgcmVzcG9uZGVkIGFib3V0IElQUiAo dGhhbmsgeW91ISkuIFN0aWxsIG1pc3NpbmcgcmVwbGllcyBmcm9tIHNvbWUgY29udHJpYnV0b3Jz IChXaW0sIEVkd2FyZCwgSWdvciwgU2FrdSkuIEnigJl2ZSBzZW50IHRoZW0gYSByZW1pbmRlciB0 aGlzIE1vbmRheS4NCi0gVHdvIHBlb3BsZSAoWmFmYXIsIEFkcmlhbikgaGF2ZSByZXNwb25kZWQg c3VwcG9ydGluZyBwdWJsaWNhdGlvbi4NCi0gTm8gb3Bwb3NpdGlvbi4NCi0gVHdvIHBlcnNvbnMg aGF2ZSBzZW50IGNvbW1lbnRzIChBZHJpYW4sIG15c2VsZikuIFRoYW5rcyBBZHJpYW4uDQotIEF1 dGhvcnMgaGF2ZSBub3QgcmVwbGllZCB0byBhbnkgY29tbWVudCBzbyBmYXIuDQotIFRoZSBXR0xD IHBlcmlvZCB3YXMgc2NoZWR1bGVkIHRvIGVuZCB0b21vcnJvdy4NCg0KSSB3aXNoIHdlIGhhZCBt b3JlIHN1cHBvcnQsIHJldmlld3MsIGFuZCBhdXRob3Jz4oCZIGludm9sdmVtZW50IHRvIHJlcGx5 IHRvIHJldmlld3MuDQoNClRoZSBXR0xDIGlzIGV4dGVuZGVkIGJ5IGEgd2Vlay4gUGxlYXNlIHJl dmlldyB0aGUgZG9jdW1lbnQgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCwgbm8g bGF0ZXIgdGhhbiAqSnVuZSAxNSoNCg0KVGhhbmsgeW91LA0KLS1CcnVubw0KDQpGcm9tOiBicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiBb bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDI0 LCAyMDE4IDc6MTQgUE0NClRvOiBTUFJJTkcgV0cgTGlzdA0KQ2M6IGRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1tcGxzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctbXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFdHIExhc3QgQ2FsbCBmb3Ig ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTMNCg0KDQpIZWxsbyBXb3Jr aW5nIEdyb3VwLA0KDQoNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSBXb3JraW5nIEdyb3VwIExhc3Qg Q2FsbCBvbiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMyBbMV0gd2hp Y2ggaXMgY29uc2lkZXJlZCBtYXR1cmUgYW5kIHJlYWR5IGZvciBhIGZpbmFsIHdvcmtpbmcgZ3Jv dXAgcmV2aWV3Lg0KDQoNCg0KUGxlYXNlIHJlYWQgdGhpcyBkb2N1bWVudCBpZiB5b3UgaGF2ZW4n dCByZWFkIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uIHlldCwgYW5kIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbGlzdCwgbm8gbGF0ZXIgdGhhbiAqSnVuZSAwOCouDQoNCg0KDQpBcyBhIHJlbWlu ZGVyLCB0aGlzIGRvY3VtZW50IGhhZCBhbHJlYWR5IHBhc3NlZCBhIFdHTEMgbW9yZSB0aGFuIGEg eWVhciBhZ28gb24gdmVyc2lvbiAtMDYgWzJdLCBoYWQgYmVlbiBzZW50IHRvIHRoZSBBRCBidXQg dGhlbiByZXR1cm5lZCB0byB0aGUgV0cuDQoNClNpbmNlIHRoZW4sIHRoZSBkb2N1bWVudCBoYXMg c2lnbmlmaWNhbnRseSBjaGFuZ2VkLCBzbyBwbGVhc2UgcmVhZCBpdCBhZ2Fpbi4gSW4gcGFydGlj dWxhciwgaXQgbm93IGluY2x1ZGVzIHRoZSByZXNvbHV0aW9uIGluIGNhc2Ugb2YgaW5jb21pbmcg bGFiZWwgY29sbGlzaW9uLiBIZW5jZSBpdCBraWxsZWQgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxp Y3QtcmVzb2x1dGlvbi4NCg0KDQoNCkJvdGggY28tY2hhaXJzIGNvLWF1dGhvciB0aGlzIGRvY3Vt ZW50LCBoZW5jZToNCg0KLSBTaHJhZGRoYSBoYXMgYWdyZWVkIHRvIGJlIHRoZSBkb2N1bWVudCBz aGVwaGVyZC4uIFRoYW5rIHlvdSBTaHJhZGRoYS4NCg0KLSBNYXJ0aW4sIG91ciBBRCwgaGFzIGFn cmVlZCB0byBldmFsdWF0ZSB0aGUgV0cgY29uc2Vuc3VzLg0KDQoNCg0KVGhhbmsgeW91LA0KDQpC cnVubywgUm9iDQoNCg0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTEzDQoNClsyXSBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9TVGlZc1FKV3VWWEExQzloSzRCaVVueU11N1kN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91 Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4N Cg== --_000_C46F5EEC27CA47B8A9DABAC51E7FB1ADciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <507829F5A1928540A93996B121C77D41@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5QcmZvcm1hdEhUTUwsIGxp LlByZm9ybWF0SFRNTCwgZGl2LlByZm9ybWF0SFRNTA0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZv cm1hdMOpIEhUTUwiOw0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0 w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpGUjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFs IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHls ZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fu cy1zZXJpZjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6d2luZG93dGV4dCI+QWhtZWQg4oCTIFRoYW5rcyBtdWNoIGZvciB5b3Vy IHdvcmsgcmVzb2x2aW5nIHRoZSBXRyBsYXN0IGNhbGwgaXNzdWVzITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOndpbmRvd3Rl eHQiPkJydW5vIOKAkyBUaGFua3MgZm9yIHRoZSBwbGFuIGZvciBwdWJsaWNhdGlvbi4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOndpbmRvd3RleHQiPkxldOKAmXMga2VlcCBmb2N1cyBvbiB0aGlzIGRyYWZ0IGFzIGl0IGlz IE5vcm1hdGl2ZSByZWZlcmVuY2UgZm9yIGFsbCB0aGUgTFNSIFNlZ21lbnQgUm91dGluZyBkcmFm dHMgaW5jbHVkaW5nIHRoZSBoYW5kbGluZyBmb3IgU0lEIGNvbmZsaWN0cy4mbmJzcDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOndpbmRvd3RleHQiPlRoYW5rcyBBZ2FpbiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOndp bmRvd3RleHQiPkFjZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5zcHJpbmcg Jmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQnJ1bm8gRGVjcmFl bmUgJmx0O2JydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1 ZXNkYXksIE9jdG9iZXIgMzAsIDIwMTggYXQgNzowNSBBTTxicj4NCjxiPlRvOiA8L2I+QWhtZWQg QmFzaGFuZHkgJmx0O2FiYXNoYW5keS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9i PiZxdW90O2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzQGlldGYub3JnJnF1 b3Q7ICZsdDtkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBsc0BpZXRmLm9yZyZn dDssIFNQUklORyBXRyBMaXN0ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7LCBNYXJ0aW4gVmlnb3Vy ZXV4ICZsdDttYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbSZndDssIFNocmFkZGhhIEhlZ2RlICZs dDtzaHJhZGRoYUBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzcHJp bmddIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1w bHMtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBB aG1lZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPk5leHQgc3RlcHMgYXJlJm5ic3A7Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij4tIHNoZXBoZXJkIHdyaXRlIHVwIChTaHJhZGRoYSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+LSAyIHdlZWtzIHRvIGFsbG93IFdHIHRvIGNvbW1lbnQgb24gdGhlIGNoYW5nZXMsIGVzcGVj aWFsbHkgZnJvbSBDaHJpcywgUEssIFJ1ZWRpZ2VyLCBTYXNoYSwgU2hyYWRkaGEuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPi0gV0cgY2hhaXJzIGdvIGFoZWFkIChkZWxlZ2F0ZWQgdG8gTWFy dGluIChBRCkgYXMgYm90aCBjaGFpcnMgY28tYXV0aG9yKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91LDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj4tLUJydW5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj4NCiBBaG1lZCBCYXNoYW5keSBb bWFpbHRvOmFiYXNoYW5keS5pZXRmQGdtYWlsLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgT2N0b2JlciAyMiwgMjAxOCA5OjA2IFBNPGJyPg0KPGI+VG86PC9iPiBERUNSQUVORSBCcnVu byBUR0kvT0xOOyBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBsc0BpZXRmLm9y Zzxicj4NCjxiPkNjOjwvYj4gU1BSSU5HIFdHIExpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMt MTM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdXBsb2FkZWQgdmVyc2lvbiAxNSB0byBhZGRyZXNz IHRoZSBjb21tZW50cyBiZWxvdyBzaW5jZSB0b2RheSBpcyB0aGUgZGVhZGxpbmUgYmVmb3JlIHRo ZSB1cGNvbWluZyBJRVRGPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+SSB3aWxsIGV4cGxhaW5pbmcgaG93IHZlcnNpb24gMTUgYWRkcmVzc2VzIGVhY2ggb2YgdGhl IGNvbW1lbnRzIGJlZm9yZSB0aGUgc3RhcnQgb2YgdGhlIElFVEYgbmV4dCB3ZWVrPG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmtzIGEgbG90IGZvciBhbGwg dGhlIGhlbHAgYW5kIHRoZSBmZWVkYmFjazxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkFobWVkPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIDEwLzE1LzE4IDk6MTIgQU0s IDxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj4NCmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5B dXRob3JzLCBBaG1lZCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPkNvdWxkIHlvdSBwcm9ncmVzcyBvbiB0aGlzIGRvY3VtZW50Pzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+VGhyZWFkIGlzOg0KPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L2Jyb3dzZS9zcHJpbmcvP3E9c3ViamVjdCUzQWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91 dGluZy1tcGxzIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2Uvc3By aW5nLz9xPXN1YmplY3QlM0FkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBsczwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkNvbW1lbnRzIHN0aWxsIHRvIGJlIGFkZHJlc3NlZC9yZXNvbHZlZCBhcmUgdGhlIGZv bGxvd2luZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcveHgtdDV2NUlXMlBfOHJaeWtlSnJ2bDlx RElFIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy94eC10NXY1 SVcyUF84clp5a2VKcnZsOXFESUU8L2E+Jm5ic3A7Jm5ic3A7DQogKGZyb20gbXlzZWxmIHNpbmNl IDwvc3Bhbj4yMDE4LTA1LTI0KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL0NSaTk2TW5INEJzdS10cWx6NXUy Nk1hbjl4dyI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvQ1Jp OTZNbkg0QnN1LXRxbHo1dTI2TWFuOXh3PC9hPg0KIChmcm9tIENocmlzIEJvd2VycyBzaW5jZSA8 L3NwYW4+MjAxOC0wNi0wOCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy95SXdVdktkZHJjUi1neFBRWlNNamJ5 blRYNzQiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL3lJd1V2 S2RkcmNSLWd4UFFaU01qYnluVFg3NDwvYT4NCiAoZnJvbSBQSyBzaW5jZSA8L3NwYW4+MjAxOC0w Ni0wOSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3NwcmluZy81UEhoTGxNSXhMZ29GZG9SQzFXcXo2eENCbkkiPmh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nLzVQSGhMbE1JeExnb0Zkb1JD MVdxejZ4Q0JuSTwvYT4mbmJzcDsNCiAoZnJvbSBQSyBzaW5jZSA8L3NwYW4+MjAxOC0wNi0wOSk8 bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy93MFptT0FjRGZfVFVVV0xr ZUZrX0U2anpRbTQiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5n L3cwWm1PQWNEZl9UVVVXTGtlRmtfRTZqelFtNDwvYT4gKGZyb20gPC9zcGFuPlJ1ZWRpZ2VyIDIw MTgtMDYtMTMpPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9nS0E1c3FrdWszU25PTUF6NG5TU0N4RlFIdFEi Pmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2dLQTVzcWt1azNT bk9NQXo0blNTQ3hGUUh0UTwvYT4NCiAoZnJvbSBTaHJhZGRoYSA8L3NwYW4+MjAxOC0wNy0yMCAm YW1wOyAmIzQzOzEgZnJvbSBTYXNoYSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9jN1BiOHBhVHQxVWliT3df TzB5ZlBXNGZnT2siPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5n L2M3UGI4cGFUdDFVaWJPd19PMHlmUFc0ZmdPazwvYT4NCiAoZnJvbSBTYXNoYSAmYW1wOyBTdMOp cGhhbmUgZGlzY3Vzc2lvbiAyMDE4LTA4LTA2KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPkF1dGhvcnMsIEFobWVkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGFu ayB5b3UgZm9yIGVuZ2FnaW5nIHRoZSBhdXRob3JzIG9mIHRob3NlIGNvbW1lbnRzIGFuZCB1cGRh dGUgdGhlIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4t LUJydW5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+IERFQ1JB RU5FIEJydW5vIElNVC9PTE4NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAwNywg MjAxOCA2OjUyIFBNPGJyPg0KPGI+VG86PC9iPiBTUFJJTkcgV0cgTGlzdDxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxz QGlldGYub3JnIj5kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBsc0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIGFsbCw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkEgcXVpY2sgdXBkYXRl IG9uIHRoZSBzdGF0dXMgb2YgdGhpcyBXR0xDOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LSBBbGwgdGhlIGF1dGhvcnMgaGF2ZSBy ZXNwb25kZWQgYWJvdXQgSVBSICh0aGFuayB5b3UhKS4gU3RpbGwgbWlzc2luZyByZXBsaWVzIGZy b20gc29tZSBjb250cmlidXRvcnMgKFdpbSwgRWR3YXJkLCBJZ29yLCBTYWt1KS4gSeKAmXZlIHNl bnQgdGhlbSBhIHJlbWluZGVyDQogdGhpcyBNb25kYXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPi0gVHdvIHBlb3BsZSAoWmFmYXIsIEFkcmlhbikgaGF2ZSByZXNwb25kZWQgc3VwcG9ydGlu ZyBwdWJsaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LSBObyBvcHBvc2l0aW9u Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tIFR3byBwZXJzb25zIGhhdmUgc2VudCBjb21t ZW50cyAoQWRyaWFuLCBteXNlbGYpLiBUaGFua3MgQWRyaWFuLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj4tIEF1dGhvcnMgaGF2ZSBub3QgcmVwbGllZCB0byBhbnkgY29tbWVudCBzbyBmYXIu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0gVGhlIFdHTEMgcGVyaW9kIHdhcyBzY2hlZHVs ZWQgdG8gZW5kIHRvbW9ycm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SSB3aXNoIHdlIGhhZCBtb3JlIHN1cHBvcnQsIHJldmll d3MsIGFuZCBhdXRob3Jz4oCZIGludm9sdmVtZW50IHRvIHJlcGx5IHRvIHJldmlld3MuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5U aGUgV0dMQyBpcyBleHRlbmRlZCBieSBhIHdlZWsuIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50 IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QsIG5vIGxhdGVyIHRoYW4gKjxiPkp1 bmUgMTU8L2I+Kjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+VGhhbmsgeW91LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tLUJy dW5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPg0KPGEgaHJlZj0ibWFpbHRvOmJy dW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+IFs8 YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+bWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkg MjQsIDIwMTggNzoxNCBQTTxicj4NCjxiPlRvOjwvYj4gU1BSSU5HIFdHIExpc3Q8YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct bXBsc0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ SGVsbG8gV29ya2luZyBHcm91cCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGVtYWlsIHN0YXJ0cyBhIFdvcmtpbmcgR3JvdXAg TGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTEzIFsx XSB3aGljaCBpcyBjb25zaWRlcmVkIG1hdHVyZSBhbmQgcmVhZHkgZm9yIGEgZmluYWwgd29ya2lu ZyBncm91cCByZXZpZXcuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+UGxlYXNlIHJlYWQgdGhpcyBkb2N1bWVudCBpZiB5b3UgaGF2ZW4n dCByZWFkIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uIHlldCwgYW5kIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbGlzdCwgbm8gbGF0ZXIgdGhhbiAqSnVuZSAwOCouPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BcyBhIHJlbWluZGVyLCB0aGlzIGRvY3VtZW50 IGhhZCBhbHJlYWR5IHBhc3NlZCBhIFdHTEMgbW9yZSB0aGFuIGEgeWVhciBhZ28gb24gdmVyc2lv biAtMDYgWzJdLCBoYWQgYmVlbiBzZW50IHRvIHRoZSBBRCBidXQgdGhlbiByZXR1cm5lZCB0byB0 aGUgV0cuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNp bmNlIHRoZW4sIHRoZSBkb2N1bWVudCBoYXMgc2lnbmlmaWNhbnRseSBjaGFuZ2VkLCBzbyBwbGVh c2UgcmVhZCBpdCBhZ2Fpbi4gSW4gcGFydGljdWxhciwgaXQgbm93IGluY2x1ZGVzIHRoZSByZXNv bHV0aW9uIGluIGNhc2Ugb2YgaW5jb21pbmcgbGFiZWwgY29sbGlzaW9uLiBIZW5jZSBpdCBraWxs ZWQgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJvdGggY28tY2hhaXJzIGNvLWF1dGhvciB0 aGlzIGRvY3VtZW50LCBoZW5jZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+LSBTaHJhZGRoYSBoYXMgYWdyZWVkIHRvIGJlIHRoZSBkb2N1bWVudCBzaGVw aGVyZC4uIFRoYW5rIHlvdSBTaHJhZGRoYS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+LSBNYXJ0aW4sIG91ciBBRCwgaGFzIGFncmVlZCB0byBldmFsdWF0 ZSB0aGUgV0cgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QnJ1bm8sIFJvYjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xMyI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1t cGxzLTEzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5bMl0gPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJp bmcvU1RpWXNRSld1VlhBMUM5aEs0QmlVbnlNdTdZIj5odHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NwcmluZy9TVGlZc1FKV3VWWEExQzloSzRCaVVueU11N1k8L2E+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5wYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5U aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj50aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5J ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C46F5EEC27CA47B8A9DABAC51E7FB1ADciscocom_-- From nobody Tue Oct 30 20:42:14 2018 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 BD2FB1252B7; Tue, 30 Oct 2018 20:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 R7L1Fyt6otOy; Tue, 30 Oct 2018 20:42:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 60C73124C04; Tue, 30 Oct 2018 20:42:09 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 03711B307CD9D; Wed, 31 Oct 2018 03:42:05 +0000 (GMT) Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 31 Oct 2018 03:42:05 +0000 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.70]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Wed, 31 Oct 2018 11:41:54 +0800 From: "Chengli (IP Technology Research)" To: "Darren Dukes (ddukes)" , Joel Halpern CC: "spring@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Lizhenbin , Mach Chen Thread-Topic: SRv6 - SRH in encaps or base header - point 2 Thread-Index: AQHUcIcsTbFeHZpwLku+NvhkEcQp5qU4pNnQ Date: Wed, 31 Oct 2018 03:41:52 +0000 Message-ID: References: <42663f06-8fcc-4ca4-5e3c-368adcaaef86@joelhalpern.com> <69085e36-f091-44d5-590b-3550983ac4d7@joelhalpern.com> <3e51b691-ae71-31ce-a094-db2d75d80ae0@joelhalpern.com> <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> In-Reply-To: <728DADEC-AC49-4F16-93FB-4B5A6905DF59@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] SRv6 - SRH in encaps or base header - point 2 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 03:42:13 -0000 SGkgRGFycmVuLA0KDQpJIHRoaW5rIHRoZSB0ZXh0IG9mIGVuY2Fwc3VsYXRpbmcgbW9kZSBpcyBj bGVhciBmb3IgbWUuIEJ1dCBJIHN0aWxsIGhhdmUgc29tZSBxdWVzdGlvbnMgb2YgdGhlIGluc2Vy dGlvbiBtb2RlIC4NCg0KMS4xIDo8ZGQ+IE5vZGUgOSBoYXMgYSBjaG9pY2UsIGVuY2Fwc3VsYXRl IHRvIG5vZGUgMyBvciBub3QuIA0KSWYgbm9kZSA5IGRvZXMgbm90IGVuY2Fwc3VsYXRlLCBpdCB3 aWxsIGluZm9ybSB0aGUgZGVzdGluYXRpb24gb2YgdGhlIHNlZ21lbnRzIGluIHRoZSBTUkggYW5k IHBvc3NpYmx5IGxlYWsgdGhlbSB0byBpbnRlcm1lZGlhdGUgbm9kZXMuDQoNCklmIHRoZXJlIGlz IG5vdCBpbmRpY2F0b3IgdG8gbWFrZSBhIGNob2ljZSBvZiBlbmNhcHN1bGF0aW5nIG9yIG5vdCwg aG93IHRoZSBub2RlIHRvIG1ha2UgdGhlIGNob2ljZT8gTG9jYWwgcG9saWN5PyAgDQpPciBtYWtl IGl0IHRoZSBzYW1lIGxpa2UgdGhlIHJlY2VpdmVkIHBhY2tldD8gRW5jYXBzdWxhdGUgaWYgcmVj ZWl2ZWQgcGFja2V0IGRvZXMsIGVsc2UsIGluc2VydD8NCg0KMS4yIDogSG93IHRvIGluZm9ybSB0 aGUgZGVzdGluYXRpb24gb2YgdGhlIHNlZ21lbnRzIGluIHRoZSBTUkg/ICBBbnkgaW5kaWNhdG9y IGluIFNSSD8gT3IgdGhyb3VnaCBzaWduYWxpbmc/IA0KDQoyOiBDYW4gYSBub3JtYWwobm9uLVNJ RCkgSVB2NiBhZGRyZXNzIGJlIGFkZGVkIGludG8gU0lEIGxpc3Q/DQoNCkkgcHJlZmVyIHllcy4N Cg0KQXMgc2VjdGlvbiA0LjMgc2F5cywgaXQgc2VlbXMgbGlrZSB3ZSBjYW4gZG8gdGhhdC4NCg0K ICAgIldoZW4gYW4gU1J2Ni1jYXBhYmxlIG5vZGUgcmVjZWl2ZXMgYW4gSVB2NiBwYWNrZXQsIGl0 IHBlcmZvcm1zIGENCiAgIGxvbmdlc3QtcHJlZml4LW1hdGNoIGxvb2t1cCBvbiB0aGUgcGFja2V0 cyBkZXN0aW5hdGlvbiBhZGRyZXNzLiAgVGhpcw0KICAgbG9va3VwIGNhbiByZXR1cm4gYW55IG9m IHRoZSBmb2xsb3dpbmc6DQoNCiAgICAgICBBIEZJQiBlbnRyeSB0aGF0IHJlcHJlc2VudHMgYSBs b2NhbGx5IGluc3RhbnRpYXRlZCBTUnY2IFNJRA0KICAgICAgIEEgRklCIGVudHJ5IHRoYXQgcmVw cmVzZW50cyBhIGxvY2FsIGludGVyZmFjZSwgbm90IGxvY2FsbHkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpbnN0YW50aWF0ZWQgYXMgYW4gU1J2NiBTSUQNCiAgICAgICBB IEZJQiBlbnRyeSB0aGF0IHJlcHJlc2VudHMgYSBub24tbG9jYWwgcm91dGUNCiAgICAgICBObyBN YXRjaA0KICAgICAgIg0KQWxzbywgaW4gc2VjdGlvbiA1LCB3ZSBjYW4gc2VlIEE5IGNhbiBiZSBh ZGRlZCBpbiBTSUQgbGlzdCBvZiBhIFNSIHBvbGljeS4NCg0KU28gZm9yIHRoZSBwYWNrZXQgZnJv bSBBOSB0byBBMSwgdGhlIGFkZHJlc3Mgb2YgQTEgY2FuIGJlIGFkZGVkIGFzIHRoZSBsYXN0IGVu dHJ5IG9mIFNJRCBsaXN0LCByaWdodD8gDQoNCklmIHllcywgYWRkcmVzcyBvZiBBMSBpcyBub3Qg YW4gaW5zdGFudGlhdGVkIFNJRCwgc28gbm90IFBTUCBmbGF2b3IgY2FuIGJlIGVuYWJsZWQuIFNv IHRoZSBwYWNrZXQgd2lsbCBiZSBzZW50IG91dCBieSBjYXJyeWluZyB0aGUgU1JIIGFmdGVyIEEx IGlzIHVwZGF0ZWQgdG8gdGhlIElQdjYgREEuIA0KU1JIIHdpbGwgYmUgbGVha2VkIHRvIG91dHNp ZGUgb2YgdGhlIFNSIGRvbWFpbiwgd2hpY2ggd2lsbCBicmluZyBuZXcgc2VjdXJpdHkgaXNzdWVz LiANCg0KDQozOiBGb3Igc2VjdGlvbiA2LjIsDQogICBOb2RlcyBvdXRzaWRlIHRoZSBTUiBEb21h aW4gY2Fubm90IGJlIHRydXN0ZWQuICBTUiBEb21haW4gSW5ncmVzcw0KICAgcm91dGVycyBTSE9V TEQgZGlzY2FyZCBwYWNrZXRzIGRlc3RpbmVkIHRvIFNJRHMgd2l0aGluIHRoZSBTUiBEb21haW4N CiAgIChyZWdhcmRsZXNzIG9mIHRoZSBwcmVzZW5jZSBvZiBhbiBTUkgpIHRvIGF2b2lkIGF0dGFj a3Mgb24gdGhlIFNSDQogICBEb21haW4gYXMgZGVzY3JpYmVkIGFuZCByZWZlcmVuY2VkIGluIFtS RkM1MDk1XS4gDQoNCiAgIEFzIGFuIGFkZGl0aW9uYWwNCiAgIGxheWVyIG9mIHByb3RlY3Rpb24s IFNSIFNlZ21lbnQgRW5kcG9pbnQgbm9kZXMgU0hPVUxEIGRpc2NhcmQgcGFja2V0cw0KICAgZGVz dGluZWQgdG8gbG9jYWwgU0lEcyBmcm9tIHNvdXJjZSBhZGRyZXNzZXMgbm90IHBhcnQgb2YgdGhl IFNSDQogICBEb21haW4uDQoNCkZvciBhIHBhY2tldCBmcm9tIEExIHRvIEE5LCAgdGhlIHBhY2tl dCBpcyAoQTEsIEE5KS4gTm9kZTMgd2lsbCBub3QgZHJvcCB0aGUgcGFja2V0IHNpbmNlIHRoZSBk ZXN0aW5hdGlvbiBpcyBBOSBub3QgUzkuDQoNCklmIG5vZGUgMyBpbnNlcnQgYSBTUkggaW4gdGhl IG9yaWdpbmFsIElQdjYgcGFja2V0LCB0aGVuIHRoZSBzb3VyY2UgQWRkcmVzcyB3aWxsIGJlIEEx LiBBbmQgdGhlIFNJRCBsaXN0IGNhbiBiZSAgPEE5LCBTNiA+Lg0KSW4gdGhpcyBjYXNlLCB0aGUg cGFja2V0IHdpbGwgYmUgZHJvcHBlZCBieSBub2RlIDYsIHNpbmNlIHRoZSBzb3VyY2UgYWRkcmVz cyBpcyBub3QgcGFydCBvZiB0aGUgU1IgZG9tYWluLiAgW1NlY3Rpb24gNi4yXSwgcmlnaHQ/DQoN CklNSE8sIHRoZXJlIGFyZSBzb21lIHByb2JsZW1zIGFib3V0IGluc2VydGlvbiBtb2RlLg0KDQpU aGFua3MsDQpDaGVuZw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlw djYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXJyZW4gRHVr ZXMgKGRkdWtlcykNClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAzMSwgMjAxOCAzOjMxIEFNDQpU bzogSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KQ2M6IHNwcmluZ0BpZXRmLm9y ZzsgNm1hbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFNSdjYgLSBTUkggaW4gZW5jYXBzIG9yIGJh c2UgaGVhZGVyIC0gcG9pbnQgMg0KDQpJIHRoaW5rIHdl4oCZcmUgYWxtb3N0IGNvbmNsdWRlZCBz byBvbmNlIG1vcmUgaW5saW5lIGF0IDxkZD48L2RkPg0KDQo+IE9uIE9jdCAyNiwgMjAxOCwgYXQg MjoyOCBQTSwgSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4gDQo+ IChyZXNlbmRpbmcsICtzcHJpbmcgYXMgcmVxdWVzdGVkKQ0KPiANCj4gVGhhbmsgeW91IGZvciB0 aGUgcmVzcG9uc2VzLiAgSSB3aWxsIHJlc3BvbmQgaW4gbGluZSwgbWFya2VkIDxqbWg+PC9qbWg+ LiAgSSBmZWFyIGl0IHdpbGwgc2hvcnRseSBnZXQgdG9vIGRlZXAsIGJ1dCB0aGUgY29udGV4dCBp cyBpbXBvcnRhbnQuDQo+IA0KPiBJIHdpbGwgcmVwaHJhc2UgaGVyZSBhbiBpc3N1ZSBmcm9tIGFu b3RoZXIgdGhyZWFkIHRoYXQgSSBhaHZlIG5vdCBzZWVuIHlvdXIgY29tbWVudHMgb24uICBJZiBO b2RlIDkgaXMgc2VuZGluZyB0cmFmZmljIHRvIE5vZGUgMSAoZm9yIGV4YW1wbGUsIHRoZSByZXZl cnNlIHRyYWZmaWMgZm9yIHRoZSB0cmFmZmljIGZyb20gMSB0byA5IGluIHRoZSBleGFtcGxlcyBi ZWxvdyksIGl0IHByZXN1bWFibHkgaGFzIGFuIFNSIFBvbGljeSB0byBiZSBhcHBsaWVkLiBUaGUg aXNzdWUgSSByYWlzZWQgYmVmb3JlIGlzIHRoZSBsZWFrYWdlIGlzc3VlLiAgSWYgOSBwdXRzIHRo ZSBTUkggaW4gaXRzIHBhY2tldCAoYXMgdGhlIGRvY3VtZW50IGN1cnJlbnRseSBtYW5kYXRlcyks IHRoZW4gaXQgd2lsbCBub3QgYmUgcG9zc2libGUgZm9yIDMgdG8gcmVtb3ZlIHRoZSBTUkguICBU aHVzLCB0aGUgU1JIIHdpbGwgbGVhay4NCj4gDQo+IFNvbWUgaGF2ZSBhcmd1ZWQgdGhhdCBpcyBu b3QgYSBiaWcgZGVhbC4gIEl0IHNlZW1zIHRvIG1hdHRlciB0byBtZS4gIEJ1dCB0aGVyZSBpcyBh biBhZGRpdGlvbmFsIHByb2JsZW0uICBBMSBpcyBub3QgYSBTSUQuICBUaGVyZWZvcmUsIDkgY2Fu IG5vdCBwdXQgQTEgaW50byB0aGUgU1JILiAgSWYgaXQgY2FuIG5vdCBwdXQgQTEgaW50byB0aGUg U1JILCBhbmQgaXQgZG9lcyBub3QgZW5jYXBzdWxhdGUgdGhlIHBhY2tldCwgd2hlcmUgZG9lcyBp dCBwdXQgQTEuDQoNCjxkZD4gTm9kZSA5IGhhcyBhIGNob2ljZSwgZW5jYXBzdWxhdGUgdG8gbm9k ZSAzIG9yIG5vdC4gDQpJZiBub2RlIDkgZG9lcyBub3QgZW5jYXBzdWxhdGUsIGl0IHdpbGwgaW5m b3JtIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgc2VnbWVudHMgaW4gdGhlIFNSSCBhbmQgcG9zc2li bHkgbGVhayB0aGVtIHRvIGludGVybWVkaWF0ZSBub2Rlcy4NCklmIG5vZGUgOSBkb2VzIGVuY2Fw c3VsYXRlLCBub2RlIDMgcmVtb3ZlcyB0aGUgb3V0ZXIgaGVhZGVyIGFuZCBub2RlIDEgd291bGQg bm90IGxlYXJuIHRoZSBzZWdtZW50IGxpc3QuDQpJIHRoaW5rIGl0cyBjaG9pY2Ugc2hvdWxkIG5v dCBiZSBtYW5kYXRlZCBpbiB0aGUgZHJhZnQuIDwvZGQ+DQoNCj4gDQo+IFlvdXJzLA0KPiBKb2Vs DQo+IA0KPiBPbiAxMC8yNi8xOCAxOjI5IFBNLCBEYXJyZW4gRHVrZXMgKGRkdWtlcykgd3JvdGU6 DQo+PiBIaSBKb2VsLCB5b3XigJl2ZSBkZXNjcmliZWQgc2VjdGlvbnMgdGl0bGVkIOKAnEludHJh IFNSIERvbWFpbiBQYWNrZXTigJ0sIOKAnFRyYW5zaXQgUGFja2V0IFRocm91Z2ggU1IgRG9tYWlu 4oCdLCBhbmQgIlNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkgQ29ubmVjdGVk4oCdLg0KPj4g SeKAmXZlIHBhcnNlZCB0aGVtIGlubGluZSB0byB0aGUgc2VjdGlvbnMgb2YgdGhlIGRyYWZ0IGRl ZmluaW5nIHRoZW0gYW5kIGdpdmVuIG1vcmUgY29udGV4dCB3aGVyZSBuZWVkZWQuDQo+Pj4gT24g T2N0IDIyLCAyMDE4LCBhdCA4OjQ5IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVy bi5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IFJlcGhyYXNpbmcgdXNpbmcgdGhlIGV4YW1wbGUgZnJv bSA1LjIuICBBc3N1bWluZyB0aGF0IDggYW5kIDkgYXJlIFNSIA0KPj4+IEhvc3RzIChub3QganVz dCBob3N0cyB3aXRoaW4gdGhlIGRvbWFpbiwgdGhleSBhcmUgY2FwYWJsZSBvZiBhbmQgDQo+Pj4g ZXhwZWN0IHRvIGRlYWwgd2l0aCBTUkhzLCBhbmQgdGhlcmVmb3JlIGhhdmUgbG9jYWwgU0lEcywg Li4uKQ0KPj4+IA0KPj4+IEZvciB0cmFmZmljIGZyb20gOCB0byA5IHRoYXQgbmVlZHMgYW4gU1JI LCB0aGUgU1JIIGdvZXMgaW4gdGhlIElQdjYgaGVhZGVyIHNlbnQgbXkgOCB0byA5LiAgV2hlbiA5 IHByb2Nlc3NlcyB0aGUgcGFja2V0LCBpdCBzZWVtcyB0aGF0IGl0IGlzIHRoZSBsYXN0IFNJRCwg ZmlndXJlcyBvdXQgdGhhdCB0aGVyZSBpcyBubyBlbmNhcHN1bGF0aW9uLCBhbmQgc2VuZCB0aGUg VENQIC8gVURQIC8gUVVJQyBpbmZvcm1hdGlvbiB0byBpdHMgaW50ZXJuYWwgcHJvdG9jb2xzIHN0 YWNrcy4NCj4+IFllcywgdGhpcyBpcyBTZWN0aW9uIDUuMy4xIOKAnEludHJhIFNSIERvbWFpbiBQ YWNrZXTigJ0uDQo+IDxqbWg+QWdyZWVkIGFzIGZhciBhcyBpdCBnb2VzLiAgSG93ZXZlciwgIHRo ZSBleGlzdGVuY2Ugb2YgUzkgYW5kIEE5IA0KPiBwb2ludHMgdG8gYSBwcm9ibGVtLiAgTm9kZSA4 IGlzIHRyeWluZyB0byBwdXQgb24gYW4gU1JIIGdvaW5nIHRocm91Z2ggDQo+IFN4LCBTeSwgd2hh dGV2ZXIgZm9yIHNvbWUgcmVhc29uLiAgSXQgY2FuJ3QgcHV0IEE5IGludG8gdGhlIFNSSCwgYXMg QUggDQo+IGlzIG5vdCBhIFNJRCwgaXQgaXMgYW4gYWRkcmVzcy4gIEkgcHJlc3VtZSBub2RlIDgg Z290IFM5IGZyb20gd2hhdGV2ZXIgDQo+IHByb3ZpZGVkIGhpbSB0aGUgU1IgUG9saWN5IHRoYXQg aXQgaXMgdXNpbmcuICBEb2VzIGl0IHNpbXBseSB1c2UgUzkgYXMgDQo+IHRoZSBhZGRyZXNzIGZv ciBub2RlIDksIHJhdGhlciB0aGFuIEE5IHRoYXQgaXQgZ290IGZyb20gRE5TPyAgQW5kIGRvZXMg DQo+IHRoZSBUQ1Agc3RhY2sga25vdyB0aGF0IHRoaXMgc3Vic3RpdHV0aW9uIGlzIGJlaW5nIG1h ZGU/ICAoVGhpcyBpcyANCj4gYW5vdGhlciBleGFtcGxlIG9mIGEgcHJvYmxlbSB0aGF0IGdvZXMg YXdheSBpZiB3ZSBhbHdheXMgZW5jYXBzdWxhdGUuKSANCj4gPC9qbWg+DQoNCjxkZD5TZWN0aW9u IDQuMy4yIGNvdmVycyB0aGVzZSBxdWVzdGlvbnMsIGkuZS4gQTkgY2FuIGJlIHBsYWNlZCBpbiB0 aGUgU1JIIGFzIHRoZSBsYXN0IHNlZ21lbnQsIGFuZCB0aGlzIHNlY3Rpb24gZGVzY3JpYmVzIGhv dyBpdOKAmXMgaGFuZGxlZC48L2RkPiANCg0KPiANCj4+PiANCj4+PiBGb3IgdHJhZmZpYyBmcm9t IDEgdG8gOSwgd2hlcmUgMyBhZGRzIGFuIFNSSCwgdGhhdCBTUkggc3RpbGwgcHJlc3VtYWJseSBl bmRzIGF0IDkuICA5IFJlY2VpdmVzIHRoZSBJUCBwYWNrZXQuICBTZWVzIHRoYXQgaXQgaXMgYWRk cmVzc2VkIHRvIGl0c2VsZi4gIFNlZXMgdGhhdCB0aGUgU1JIIGlzIGZpbmlzaGVkLiAgQW5kIHRo ZW4gbm90aWNlcyB0aGF0IHRoZSBuZXh0LWhlYWRlciBpcyBJUHY2LiAgVW53cmFwcyB0aGUgaGVh ZGVyLCBjaGVja3MgdGhhdCB0aGUgaW5uZXIgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhbHNvIGl0 c2VsZiwgYW5kIHBhc3NlcyB0aGUgbWF0ZXJpYWwgY2FycmllZCBieSB0aGUgaW5uZXIgaGVhZGVy IHVwIHRvIHRoZSBhcHByb3ByaWF0ZSBzdGFjay4NCj4+IFNvIG5vZGUgMSBzZW5kcyBhIHBhY2tl dCB0byBub2RlIDkgKEExLEE5KSBJRiB0aGVyZSBpcyBzb21lIHN0ZWVyaW5nIA0KPj4gaW50byBh biBTUiBQb2xpY3kgYXQgbm9kZSAzIHRvIHJlYWNoIG5vZGUgOSwgdGhpcyBpcyBpZGVudGljYWwg dG8gc2VjdGlvbiA1LjMuMiDigJxUcmFuc2l0IHBhY2tldCB0aHJvdWdoIFNSIGRvbWFpbuKAnSwg ZXhjZXB0IGZvciBkZXN0aW5hdGlvbiBvZiBBOSB2aWEgbm9kZSA5ICBpbnN0ZWFkIG9mIEEyIHZp YSBub2RlIDQuDQo+IA0KPj4+IA0KPj4+IFRodXMsIDkgbmVlZHMgdG8gYmUgYWJsZSB0byBjaGVj ayBmb3IgYm90aCBjYXNlcy4gIFdlIGF0IGxlYXN0IG5lZWQgdG8gdGVsbCBpbXBsZW1lbnRvcnMg dGhhdC4NCj4+IFdlbGwsIDkgbmVlZHMgYSBTSUQgUzkgYW5kIEFkZHJlc3MgQTkuICBUaGF0IGlz IHNob3duIGluIFNlY3Rpb24gNS4xIFNJRCBhbmQgYWRkcmVzcyByZXByZXNlbnRhdGlvbi4NCj4g PGptaD5TbywgbGV0IHVzIGFzc3VtZSB0aGF0IDMgaGFzIGFuIFNSIHBvbGljeSBpdCB3YW50cyB0 byBhcHBseSB0byANCj4gdGhlIHRyYWZmaWMgZnJvbSBBMSB0byBBOS4gIEluIHRoaXMgY2FzZSwg dGhlIFM5IC8gQTkgZGljaG90b215IGlzIG5vdCANCj4gYSBwcm9ibGVtLCBJIHRoaW5rLiAgTm9k ZSAzIGVuY2Fwc3VhbHRlcyB0aGUgcGFja2V0IGZyb20gQTEgdG8gQTksIA0KPiB1c2VzIFMzIGFz IHRoZSBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgZW5jYXBzdWxhdGluZyBoZWFkZXIsIGFuZCBlbmRz IA0KPiB0aGUgU0lEIGxpc3QgaW4gdGhlIFNSSCB3aXRoIFM5LiAgVGhlIHVuc3BlY2lmaWVkIHBh cnQgaXMgdGhhdCBub2RlIDkgDQo+IG5lZWRzIHRvIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgc3Vj aCBwYWNrZXRzIGFuZCBkbyB0aGUgZG91YmxlIA0KPiBwcm9jZXNzaW5nLiAgSXQgaXMgcmVhc29u YWJsZSBkb3VibGUgcHJvY2Vzc2luZy4gIE15IG9ubHkgcmVxdWVzdCBoZXJlIA0KPiBpcyB0aGF0 IHdlIHRlbGwgZm9sa3MgdGhleSBuZWVkIHRvIHN1cHBvcnQgaXQuIDwvam1oPg0KDQo8ZGQ+QWN0 dWFsbHksIG5vZGUgMyB1c2VzIEEzIGFzIGl0cyBzb3VyY2UgYWRkcmVzcywgYnV0IHRoYXTigJlz IG1pbm9yLg0KVGhlIGRvdWJsZSBwcm9jZXNzaW5nIChsb29rdXAsIGRvIGVuZCBwcm9jZXNzaW5n LCBkbyBhbm90aGVyIGxvb2t1cCkgaXMgZG9jdW1lbnRlZCBpbiBTZWN0aW9uIDQuMy4NCklzIHRo ZXJlIGEgbmVlZCBmb3IgbW9yZSB0aGFuIHdoYXQgaXMgY3VycmVudGx5IHNwZWNpZmllZD8gPC9k ZD4NCg0KPj4+IA0KPj4+IFRoZXJlIGlzIGEgZnVydGhlciBjb21wbGljYXRpb24uICA5IHNlZW1z IHRvIG5lZWQgdG8gaGF2ZSBhbiBhZGRyZXNzIHRoYXQgaXMgYSB2YWxpZCBTSUQsIHNvIGl0IGNh biBiZSB0aGUgbGFzdCBlbnRyeSBpbiB0aGUgU1JIIGZyb20gOCB0byA5Lg0KPj4gQXMgZGVzY3Jp YmVkIGluIHRoZSBkcmFmdCwgU2VjdGlvbiA1LjEgYSBub2RlIGsgaGFzIGFuIGFkZHJlc3MgQWsg YW5kIFNJRCBTay4gIFNvIG5vZGUgOSBoYXMgYSB2YWxpZCBTSUQuDQo+PiBGb3IgdHJhZmZpYyBm cm9tIDggdG8gOSwgQTkgaXMgdXNlZCBhcyB0aGUgZGVzdGluYXRpb24gYXMgc2hvd24gaW4gc2Vj dGlvbiA1LjMuMSwgNS40IGFuZCA1LjUuDQo+Pj4gIEhvd2V2ZXIsIGlmIDEgd2VyZSB0byBzZW5k IHRoZSBwYWNrZXQgdG8gdGhhdCBTSUQgZm9yIDksIHJvdXRlciAzIHdvdWxkIGJlIHJlcXVpcmVk IGJ5IHRoZSBydWxlcyB3ZSBkaXNjdXNzZWQgaW4gdGhlIG90aGVyIHRocmVhZCB0byBkaXNjYXJk IHRoZSBwYWNrZXQgYXMgaXQgaXMgbmVpdGhlciB0byBwcmVmaXggbm9yIGNvbnRhaW5zIGFuIEhB TUMuDQo+Pj4gIEFuZCBzb21laG93LCA4IGFuZCAxIG5lZWQgdG8gZWFjaCBwaWNrIHRoZSByaWdo dCBhZGRyZXNzIHRvIHVzZSBmb3IgOS4gKHNwbGl0IEROUyBtYXliZT8pICBBbmQgMyBuZWVkcyB0 byBiZSBhYmxlIHRvIGRlcml2ZSB0ZWggU0lELWZvcm1uIGFkZHJlc3MgZm9yIDkgZnJvbSB0aGUg bm9uLVNJRCBmb3JtIG9mIHRoZSBhZGRyZXNzIHNvIHRoYXQgaXQgKDMpIGNhbiBidWlsZCBhIHBy b3BlciBTUkggdG8gZ2V0IHRoZSBwYWNrZXQgdG8gOS4NCj4gPGptaD5JIGhhdmUgcmV0YWluZWQg eW91ciBhbnN3ZXIgYmVsb3cgZm9yIGNvbnRleHQsIGJ1dCBJIHRoaW5rIHRoYXQgDQo+IGFuc3dl cnMgdGhlIHdyb25nIHF1ZXN0aW9uLiAgSSBiZWxpZXZlIHdoYXQgaXMgaXRuZW5kZWQgaXMgdGhh dCBvbmx5IA0KPiBBOSBhcHBlYXJzIGluIEROUy4gIFNvIE5vZGUgMSB3aWxsIHNlZSA5IGFzIEE5 LCBhbmQgd2lsbCB1c2UgdGhhdC4gIFM5IA0KPiB3aWxsIGFwcGVhciBpbiBTUiBQb2xpY2llcyBh Ym91dCB0cmFmZmljIHRvIG5vZGUgOSwgYnV0IG5vdCBpbiBETlMuICANCj4gVGhhdCBpcyB3aGF0 IHdlIG5lZWQuICBJIHdpc2ggaXQgd2VyZSBjbGVhcmVyIGluIHRoZSB0ZXh0LiA8L2ptaD4NCj4g DQo+IDxqbWg+SWYgbm9kZSAyMCBpcyBnZW5lcmF0aW5nIFNSSHMgd2l0aCBITUFDcywgdGhlbiB0 aGlzIGlzIGxhcmdlbHkgDQo+IHRoZSBzYW1lIGFzIHRoZSBjYXNlIGZyb20gOCB0byA5LCBleGNl cHQgdGhhdCB3aG9tZXZlciBjcmVhdGVzIHRoZSBTUiANCj4gUG9saWN5IHRoYXQgMjAgaXMgdXNp bmcgbmVlZHMgdG8gYWxzbyBtYWtlIHN1cmUgdGhhdCB3aGF0ZXZlciB0aGUgDQo+IGZpcnN0IFNJ RCBpcyBpbiB0ZWggbGlzdCwgaXQgcHJvY2Vzc2VzIEhNQUNzIGFuZCBpcyByZWNvZ25pemFibGUg dG8gDQo+IG5vZGUgMyBhcyBkb2luZyBzdWNoIHByb2Nlc3NpbmcuIEkgYW0gZ3Vlc3NpbmcgdGhh dCB0aGUgcmVhc29uIGZvciANCj4gYWxsb3dpbmcgaW50ZXJuYWwgbm9kZXMgdG8gZG8gdGhlIHBy b2Nlc3NpbmcgaXMgdG8gbW92ZSB0aGUgDQo+IHZlcmlmaWNhdGlvbiBsb2FkIG9mZiB0aGUgZWRn ZSBub2Rlcy4gIEl0IGRvZXMgY3JlYXRlIHNpZ25pZmljYW50IA0KPiBhZGRpdGlvbmFsIGNvbmZp Z3VyYXRpb24gY29tcGxleGl0eS4gPC9qbWg+DQoNCjxkZD5XZSBkaWRu4oCZdCBzZWUgYSByZWFz b24gdG8gcmVzdHJpY3QgdGhlIEhNQUMgcHJvY2Vzc2luZyB0byBvbmx5IGVkZ2Ugbm9kZXMgd2hl biBpdCB3YXMgc3RyYWlnaHQgZm9yd2FyZCB0byBkZWZpbmUgaG93IHRoZXkgY291bGQgYmUgcHJv Y2Vzc2VkIGF0IG5vbi1lZGdlIG5vZGVzLjwvZGQ+DQoNCj4gDQo+PiBUaGlzIGlzIGluY29ycmVj dC4NCj4+IFNlZSBTZWN0aW9uIDYuMi4xIOKAnFNSIFNvdXJjZSBOb2RlcyBOb3QgRGlyZWN0bHkg Q29ubmVjdGVk4oCdIEkgd2lsbCBleHBhbmQgb24gdGhlIGV4YW1wbGUgZnJvbSB0aGF0IHNlY3Rp b24uDQo+PiBOb2RlIDIwIHNlbmRzIGEgcGFja2V0IHRvIEE5IHdpdGggU1IgUG9saWN5IDxINz4g YW5kIGFuIEhNQUMgcHJvdmlkZWQgdG8gbm9kZSAyMCBieSBzb21lIHlldCB0byBiZSBkZWZpbmVk IG1ldGhvZC4gIFJlc3VsdGluZyBpbiBwYWNrZXQgc2VudCBmcm9tIG5vZGUgMjANCj4+ICAgUDog KEEyMCxINykoQTk7U0w9MSkocGF5bG9hZCkNCj4+IFJlY2FsbCBIayBpcyBhIFNJRCBhdCBub2Rl IGsgcmVxdWlyaW5nIEhNQUMgdmVyaWZpY2F0aW9uLCBhbmQgaXQgaXMgY292ZXJlZCBieSBQcmVm aXgtSC4NCj4+IFByZWZpeC1IIGlzIF9ub3RfIHN1YmplY3QgdG8gaW5ncmVzcyBmaWx0ZXJpbmcg YXQgbm9kZSAzLg0KPj4gVGhlcmVmb3JlIHRoZSBwYWNrZXQgUCBkZXN0aW5lZCB0byBINyBpcyBu b3Qgc3ViamVjdCB0byBpbmdyZXNzIGZpbHRlcmluZyBhdCBub2RlIDMuDQo+PiBQIGlzIGZvcndh cmRlZCB0byBub2RlIDcsIHdoZXJlIEg3IGlzIHByb2Nlc3NlZCBhbmQgdGhlIEhNQUMgdmVyaWZp ZWQuDQo+PiBJZiB0aGUgSE1BQyBjYW4gbm90IGJlIHZlcmlmaWVkIHRoZSBwYWNrZXQgaXMgZHJv cHBlZCwgZWxzZSBpdCBpcyBmb3J3YXJkZWQgdG8gdGhlIG5leHQgc2VnbWVudCBhbmQgZGVzdGlu YXRpb24sIEE5Lg0KPj4gRGFycmVuDQo+Pj4gDQo+Pj4gWW91cnMsDQo+Pj4gSm9lbA0KPj4+IA0K Pj4+IE9uIDEwLzIyLzE4IDg6MDQgUE0sIERhcnJlbiBEdWtlcyAoZGR1a2VzKSB3cm90ZToNCj4+ Pj4gaW5saW5lLg0KPj4+Pj4gT24gT2N0IDIyLCAyMDE4LCBhdCA3OjIxIFBNLCBKb2VsIE0uIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4+IC4uDQo+Pj4+PiAyKSBOb3cg bGV0IHVzIGxvb2sgYXQgcGFja2V0cyBhcnJpdmluZyBhdCBhbmQgYWN0dWFsbHkgZGVzdGluZWQg Zm9yIGFuIFNSIEhvc3QgaW4gdGhlIFNSIERvbWFpbiB3aGVyZSB0aGF0IHBhY2tldCBoYXMgYW4g U1JILiAgSWYgdGhlIHBhY2tldCBpcyBjb21pbmcgZnJvbSBhbm90aGVyIFNSIEhvc3QsIHRoZSBT Ukggd2lsbCBiZSBpbiB0aGUgYmFzZSBoZWFkZXIsIGFuZCB0aGUgaG9zdCBjYW4gc2ltcGx5IGNo ZWNrIGl0IGZvciBhbnkgdmlvbGF0aW9ucywgYW5kIGNvbnRpbnVlLiAgQnV0LCBpZiB0aGUgcGFj a2V0IGNhbWUgZnJvbSBvdXRzaWRlIHRoZSBkb21haW4sIHRoZW4gaXQgd2lsbCBoYXZlIGFuIGVu Y2Fwc3VsYXRpbmcgU1J2NiBoZWFkZXIuICBTbyB0aGUgaG9zdCBoYXMgdG8gZGV0ZWN0IHRoaXMg Y2FzZSwgY2hlY2sgYW5kIHRoZW4gcGVhbCBvZmYgdGhlIGVuY2Fwc3VsYXRpbmcgaGVhZGVyLCBh bmQgdGhlbiBwcm9jZXNzIHRoZSByZWNlaXZlZCBwYWNrZXQuIFllcywgaXQgY2FuIGRvIHNvLiAg QnV0IG5vdGhpbmcgaW4gdGVoIGRvY3VtZW50IHRlbGxzIGltcGxlbWVudG9ycyB0aGV5IGhhdmUg dG8gZGVhbCB3aXRoIGJvdGggY2FzZXMuDQo+Pj4+PiANCj4+Pj4gQ2FuIHlvdSBiZSBtb3JlIHBy ZWNpc2UgaGVyZS4gIFBlcmhhcHMgdXNlIHRoZSBleGFtcGxlIGZyb20gc2VjdGlvbiA1LjIgb3Ig Ni4yLjE/DQo+Pj4gLi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1h aWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZw0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==
Przemyslaw "PK" Krol |=C2=A0Strategic Network Engineering |=C2=A0pkrol@google.com= =C2=A0