From nobody Tue Aug 1 01:28:42 2017 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 BDF72132BB4 for ; Tue, 1 Aug 2017 01:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 KFaRL1lBAQsa for ; Tue, 1 Aug 2017 01:28:35 -0700 (PDT) Received: from relais-inet.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 F179F132BB2 for ; Tue, 1 Aug 2017 01:28:34 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 3C699100634; Tue, 1 Aug 2017 10:28:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 13E1AC0072; Tue, 1 Aug 2017 10:28:33 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0352.000; Tue, 1 Aug 2017 10:28:28 +0200 From: To: "Les Ginsberg (ginsberg)" , DECRAENE Bruno IMT/OLN , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nunx79fg8SlSEioEavvWIrey6JM9RIAgAZpFYCACngtgIAFnN4AgAUtYwCAAHi2gIAAxDgAgAV+hMA= Date: Tue, 1 Aug 2017 08:28:28 +0000 Message-ID: <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> In-Reply-To: <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_8ad8b432cadb42048c98a784fd04d970OPEXCLILM6Fcorporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 08:28:40 -0000 --_000_8ad8b432cadb42048c98a784fd04d970OPEXCLILM6Fcorporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network. Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network. In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement. [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_8ad8b432cadb42048c98a784fd04d970OPEXCLILM6Fcorporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

There is something unc= lear to me here.

Let’s say we hav= e the following entries:

OSPF mappings:

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

There is a prefix conf= lict here because we have 4 SIDs for 10.0.0.1/32. The current proposal shou= ld pick (192,10.0.0.1/32,100,1,0,0) learned fr= om OSPF because of smallest start SID.

Now let’s say th= at the active route in the RIB is an IS-IS route because of local protocol = preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1<= o:p>

So do you program the = following FIB entries (consider SRGB start at 16000 for every nodes) :=

10.0.0.1/3= 2 via Te0/1 push 16100

Inlabel 16100 via Te0/= 1 swap 16100

 

This means that you de= facto allows cross protocols information use (e.g. ISIS route using an OSPF= mapping). The text is not crystal clear on that point.

 

Or the other possibili= ty is to not use the SID information because it does not comes from the rig= ht protocol. So you only program the FIB but not the LFIB:

10.0.0.1/3= 2 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, July 29, 2017 00:25
To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution p= er LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.<= /o:p>

 

 

2)      Conflict resolution p= er LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)      Thesis: On the “= ;per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the &#= 8220;across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)     &= nbsp; Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.=

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 =

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 =

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 = 

“In cases where the
   information advertised by a given protocol in=
stance is either
   internally inconsistent or conflicts with adv=
ertisements from another
   protocol instance a means of achieving consis=
tent forwarding behavior
   in the network is required.”
 
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
/span>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


 Becomes active entry.<=
/b>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
/span>


Across implementations.=



 

 


 =



 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees


     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
/span>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each


   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing=



   pro=
tocol.  MTID ranges are protocol specific and there may be


   sta=
ndardized protocol specific MTID assignments for topologies of a


   spe=
cific type (e.g., an AFI specific topology).  As mapping entries


   can=
 be sourced from multiple protocols it is not possible to use a


   net=
work scoped identifier for a topology when storing mapping entries<=
o:p>


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.


> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.<=
/o:p>


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic=



[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 =



- and even you =
are agreeing that we should not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.<=
o:p>


 =



<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries<=
/o:p>


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 =



 =



Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> 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


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;<=
o:p>
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se 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_8ad8b432cadb42048c98a784fd04d970OPEXCLILM6Fcorporateadr_-- From nobody Tue Aug 1 06:23:57 2017 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 D327D132155 for ; Tue, 1 Aug 2017 06:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 0RkJ2GdOtkWd for ; Tue, 1 Aug 2017 06:23:53 -0700 (PDT) Received: from relais-inet.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 89794127868 for ; Tue, 1 Aug 2017 06:23:52 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 391C2601D4; Tue, 1 Aug 2017 15:23:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 0D2E260073; Tue, 1 Aug 2017 15:23:51 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0352.000; Tue, 1 Aug 2017 15:23:49 +0200 From: To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" CC: LITKOWSKI Stephane OBS/OINIS , "Shraddha Hegde" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nunx79fg8SlSEioEavvWIrey6JM9RIAgAZpFYCACngtgIAFnN4AgAUtYwCAAHi2gIAAxDgAgAV+hMCAAFJIEA== Date: Tue, 1 Aug 2017 13:23:48 +0000 Message-ID: <10776_1501593831_598080E7_10776_344_9_113a21de-6f8e-4d50-a0f9-cc53d8ec4932@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> In-Reply-To: <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_113a21de6f8e4d50a0f9cc53d8ec4932OPEXCLILMA4corporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 13:23:57 -0000 --_000_113a21de6f8e4d50a0f9cc53d8ec4932OPEXCLILMA4corporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding the existence of multiple protocols/LSDB, section 2 related to SR= GB seems to be light on this case. Sender behavior is defined in various SR protocol drafts such as [SR- IS-IS] which specify that senders MUST NOT advertise overlapping ranges. Receivers of SRGB ranges MUST validate the SRGB ranges advertised by other nodes. If the advertised ranges do not conform to the restrictions defined in the respective protocol specification receivers MUST ignore all advertised SRGB ranges from that node. When both IS-IS and OSPF are used, there is no document specifying how SRGB= advertisements should be done across protocols. Some people have expressed that SRGB is a property of the node, not of the = protocol. This seems to call for both IGP to advertise the same SRGB range(= s). But a strict reading of this draft may lead to consider that those SRGB ran= ge(s) are not disjoint, hence must all be ignored. For the set of ranges to be usable the ranges MUST be disjoint. Sender behavior is defined in various SR protocol drafts such as [SR- IS-IS] which specify that senders MUST NOT advertise overlapping ranges. Receivers of SRGB ranges MUST validate the SRGB ranges advertised by other nodes. If the advertised ranges do not conform to the restrictions defined in the respective protocol specification receivers MUST ignore all advertised SRGB ranges from that node. I think this point should be clarifier in the draft. Thanks, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkows= ki@orange.com Sent: Tuesday, August 01, 2017 10:28 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network. Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network. In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement. [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_113a21de6f8e4d50a0f9cc53d8ec4932OPEXCLILMA4corporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Regardi= ng the existence of multiple protocols/LSDB, section 2 related to SRGB seem= s to be light on this case.

&n= bsp;

   Sender behavior is defined in = various SR protocol drafts such as [SR-

   IS-IS] which specify that send= ers MUST NOT advertise overlapping

   ranges.

 

   Receivers of SRGB ranges MUST = validate the SRGB ranges advertised by

   other nodes.  If the adve= rtised ranges do not conform to the

   restrictions defined in the re= spective protocol specification

   receivers MUST ignore all adve= rtised SRGB ranges from that node.

&n= bsp;

When bo= th IS-IS and OSPF are used, there is no document specifying how SRGB advert= isements should be done across protocols.

&n= bsp;

Some pe= ople have expressed that SRGB is a property of the node, not of the protoco= l. This seems to call for both IGP to advertise the same SRGB range(s).

But a s= trict reading of this draft may lead to consider that those SRGB range(s) a= re not disjoint, hence must all be ignored.

   For the set of ranges to be us= able the ranges MUST be disjoint.

   Sender behavior is defined in = various SR protocol drafts such as [SR-

   IS-IS] which specify that send= ers MUST NOT advertise overlapping

   ranges.

 

   Receivers of SRGB ranges MUST = validate the SRGB ranges advertised by

   other nodes.  If the adve= rtised ranges do not conform to the

   restrictions defined in the re= spective protocol specification

   receivers MUST ignore all adve= rtised SRGB ranges from that node.

 

I think= this point should be clarifier in the draft.

&n= bsp;

Thanks,=

--Bruno=

&n= bsp;

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Tuesday, August 01, 2017 10:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi Les,=

 <= /span>

There i= s something unclear to me here.

LetR= 17;s say we have the following entries:

OSPF ma= ppings:

(192,10= .0.0.1/32,100,1,0,0)

(128,10= .0.0.1/32,200,300,0,0)

 <= /span>

ISIS ma= ppings:

(192,10= .0.0.1/32,300,1,0,0)

(128,10= .0.0.1/32,400,300,0,0)

 <= /span>

 <= /span>

There i= s a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The curren= t proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF becaus= e of smallest start SID.

Now let= ’s say that the active route in the RIB is an IS-IS route because of = local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.4= 2.42 via Te0/1

So do y= ou program the following FIB entries (consider SRGB start at 16000 for ever= y nodes) :

10.0.0.1/32 via Te0/1 = push 16100

Inlabel= 16100 via Te0/1 swap 16100

 <= /span>

This me= ans that you defacto allows cross protocols information use (e.g. ISIS rout= e using an OSPF mapping). The text is not crystal clear on that point.

 <= /span>

Or the = other possibility is to not use the SID information because it does not com= es from the right protocol. So you only program the FIB but not the LFIB:

10.0.0.1/32 via Te0/1.=

 <= /span>

Could y= ou clarify ?

 <= /span>

 <= /span>

Thanks,=

 <= /span>

 <= /span>

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, July 29, 2017 00:25
To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Bruno &= #8211;

 <= /span>

Please = reread “Section 3.7.  Guaranteeing Database Consistency.”.=

The dra= ft is explicit that “entries advertised by all routing protocols MUST= be included”.

 <= /span>

Also pl= ease read my recent response to  Shraddha as regards the pitfalls of u= sing protocol specific databases for conflict resolution.

 <= /span>

 &= nbsp;  Les

 <= /span>

 <= /span>

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always = as an individual contributor, thanks to Shraddha comments, a few point belo= w

 <= /span>

1) &nbs= p;    Conflict resolution per LSDB or across LSDB

I’= ;ve haven’t re-read all text, but I’m not certain that the curr= ent text specifies whether the conflict resolution must be run on a per LSD= B basis, or across all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be spec= ified.

 <= /span>

 <= /span>

2) &nbs= p;    Conflict resolution per LSDB or across LSDB ?<= o:p>

I belie= ve Les means across LSDB but Shraddha raised interesting questions regardin= g this, using area/level or IGP transitioning use cases.

a) &nbs= p;    Thesis: On the “per LSDB” side:

Running= conflict resolution on a per LSDB ensure that this conflict resolution run= s on the same data, which is required to get the same result. Otherwise, as= per Shraddha’s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 <= /span>

b) &nbs= p;    Antithesis: On the “across LSDB” side:

We need= consistency across the network, hence across LSDBs.

 <= /span>

c) &nbs= p;     Synthesis

We seem= to have a tradeoff issue as we can’t have both. However, it seems to= me that the consistency issue with different LSDB is not specific to SR co= nflict resolution. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within L= SDB which we can still enforce.

 <= /span>

 <= /span>

Some (t= wo) details inlined [Bruno]

 <= /span>

From: spring [ma= ilto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks = for the response.

 <= /span>

 &= nbsp; It is important  to keep the network functioning correctly in ca= se of transitioning from

 &= nbsp; one protocol to the other.

 &= nbsp;

 &= nbsp; Let us assume a case of OSPF SR network transitioning to ISIS SR= network.

 &= nbsp; Most typical transitioning technique is ships in the night where both= protocols will be

 &= nbsp; enabled in the network with OSPF having better preference and th= e issue in ISIS routing do

 &= nbsp; not affect the traffic. Once the ISIS deployment is complete, the tra= ffic will be switched

 &= nbsp; to ISIS by changing preference.

 &= nbsp;

 &= nbsp; In case of OSPF-SR transitioning to ISIS SR, because of the conf= lict resolution

 &= nbsp; rules that the conflicts are protocol independent, it is possibl= e that config mistakes in ISIS

 &= nbsp; will bring down the routes in OSPF. The ISIS topology and OSPF topolo= gy is not expected to be congruent

 &= nbsp; during transition,

 &= nbsp; so the conflicts seen on each node combining the two views will not b= e similar.

 &= nbsp; This has potential to cause routing loops/ traffic drops in the = network.

 &= nbsp;

 &= nbsp; I suggest to add the protocol-preference as one of the parameter= s in the preference algorithm

 &= nbsp; with this being on the top of the list.

 &= nbsp; The resultant conflict resolution will be consistent on ISIS topology= and OSPF topology

 &= nbsp;and is the best suited model for ships in the night transitions.

 <= /span>

Pls see= inline for other responses.<= /p>

 <= /span>

Rgds

Shraddh= a

 <= /span>

 <= /span>

From: Les Ginsberg (ginsberg) [= mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -=

 

Thanx for the comments - res= ponses inline.

 

> -----Original Message--= ---

> From: spring [mailto:spring-bounces@ietf.org] On = Behalf Of Shraddha Hegde

> Sent: Thursday, July 20= , 2017 11:44 PM

> To: spring@ietf.org

> Subject: Re: [spring] W= G Last Call for draft-ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is = an important problem to solve and it is important to

> Standardize this draft.=

>

> I generally support the= draft but have a few major comments which I hope

> the authors will work o= n.

>

>

>  1.Conflict resolu= tion and forwarding

>

>    =          Section 3.4 has the statem= ent

>    =          "Active Entries in th= e database may be used in forwarding."

>

>    =           This is a very loose= statement which does not enforce

> implementations to prog= ram the forwarding plane

>     = ;        with the active database entrie= s.

>     = ;        This does not ensure traffic dr= ops are minimized.

>

= [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" ent= ries will be used . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated wit= h a prefix which is not actually reachable. So the language in the draft is= intentional and is correct.=

<Shraddha> The language in the draft is ambiguous and it does not h= elp achieve consistent forwarding behavior across implementations.

            &= nbsp;         Prefixes that are not= reachable may not be used in forwarding which is acceptable but the draft = does not mandate that the reachable prefixes which are active

            &= nbsp;       MUST be programmed. Normative lan= guage is necessary in the draft w.r.t using active entries in forwarding.

 

 =

>     = ;        The Forwarding plane programmin= g aspects are completely missing in

> the document.

>     = ;        A separate section is needed wh= ich describes the different aspects

> of programming the forw= arding plane.

 

[Les:] This is NOT in = scope for this draft. If you want a description of how SR MPLS forwarding w= orks please see draft-ietf-spring-segment-routing-mpls.

 

<Shraddha> The point I am bringing up here is not how SR MPLS forwa= rding works. It is w.r.t to programming the forwarding plane when there is = a conflict.

            &= nbsp;         

The abstract section has below statement

 

&#=
8220;In cases where the=

   information advertised by a given protocol insta=
nce is either
   internally inconsistent or conflicts with advert=
isements from another
   protocol instance a means of achieving consisten=
t forwarding behavior
   in the network is required.”
 
If the draft is not=
 going to address the forwarding plane detail w.r.t conflicting entries it =
is definitely not meeting the
The objective descr=
ibed above.
 
Take an example of =
a conflict
(192, 192.0.2.1/32,=
 200, 1, 0, 0)
   (192, =
192.0.2.222/32, 200, 1, 0, 0)
   SID 20=
0 has been assigned to 192.0.2.1/32 by the
   first =
advertisement.
   The se=
cond advertisement assigns SID 200 to 192.0.2.222/32.
 
In this case after =
applying the preference rules
(192, 192.0.2.1/32,=
 200, 1, 0, 0)
 Becomes active ent=
ry.
 
As per the text in =
the draft,” it may be used in forwarding” so some implementatio=
ns
May choose to progr=
am forwarding plane and some may not which does not give a consistent forwa=
rding behavior
Across implementati=
ons.
 
 

 

 

>

> 2.  Protocol indep= endent resolution and impact on network migrations

>    =           In case of network m= igration from one protocol to other for ex: OSPF-

> SR to ISIS-SR,

>    =           it is useful to asso= ciate protocol preferences on a local node to the SID

> advertisement

>     = ;        and feed into the conflict reso= lution. This would make sure the

> conflicts will always

>     = ;        have a winner which is an adver= tisement from protocol with

> preferred admin-distanc= e.

>

>     = ;        There is need for introducing a= nother preference value specific to

> protocol preference

>     = ;        and make it the top rule in the= preference rule hierarchy.

>

 

[Le= s:] "admin distance" is a locally defined preference which is not= advertised. It is therefore not possible to include it as a parameter in a= n algorithm which requires a consistent answer on all nodes throughout the network.=

&= nbsp;

<Shraddha> &n=
bsp;In migration cases, topologies across two different protocols are not c=
ongruent causing inconsistent behavior.=

   &=
nbsp;           &nbs=
p;       Using admin-distance as an input par=
ameter keeps the conflict resolution with-in the protocol and guarantees
   &=
nbsp;           &nbs=
p;      Consistent behavior across all the nodes c=
orresponding to that protocol.
 
   &=
nbsp;           &nbs=
p;     The drafts tries to address this scenario p=
artially between IGP and BGP by suggesting preference values. But that does=
 not solve the
Problem between two=
 different IGPs. 

 


 =



>     =
;        This would also solve the issue=
 of MT-ID numbers being different in


> different protocols


>     =
;        as the SIDs would be compared w=
ithin a protocol advertisement.


 


[Les:] I do not unders=
tand what relationship you see between "protocol preference" and =
"MT-ID".


MT-ID values are scope=
d by  the protocol which uses them. For example, OSPFv2 supports a 7 b=
it MT-ID while IS-IS supports a 12 bit MT-ID. It is therefore possible for =
non-matching MTIDs to be used by different
 protocols when advertising routes for the same physical topology. This is =
why the draft's use of "topology" is not as MTID but rather as a =
locally scoped identifier. >From Section 3:


 <=
span lang=3D"EN-US">


" Note: Topology is a locally scoped identifier assigned by eac=
h


   router.  Although it may have an association with =
Multitopology


   Identifiers (MTID) advertised by routing protocols it i=
s NOT


   equivalent to these identifiers.  MTIDs are scoped=
 by a given routing

   protocol.  MTID ranges are protocol specific and t=
here may be


   standardized protocol specific MTID assignments for top=
ologies of a


   specific type (e.g., an AFI specific topology).  A=
s mapping entries


   can be sourced from multiple protocols it is not possib=
le to use a


   network scoped identifier for a topology when storing m=
apping entries


   in the local database."


 <=
span lang=3D"EN-US">


Topology is then used =
to detect different scopes for a mapping entry - which may result in a SID =
conflict if the same SID is used in different topologies, but it cannot be =
used as a tiebreaker since its value
 is local and any preference (e.g., higher value wins)  is not guarant=
eed to result in consistent answers on all nodes in the network. Which is w=
hy we have Section 3.3 Rule #8:


 <=
span lang=3D"EN-US">


   "8.  If topology IDs are NOT identical both e=
ntries MUST be ignored"=



<=
Shraddha> Lets keep this discussion on-hold until we decide on the proto=
col preference and migration issues.=



 


> 


> 3. In case of hierarchi=
cal IGP networks with multiple ISIS Levels or OSPF areas,=



> It's possible that the<=
o:p>


>    =
  conflicts are not visible in entire domain but are visible only on t=
he border


> router as the border ro=
uters


>    =
  have the database of both domains.


>    =
 The conflict resolution preference Rules should be enhanced to include the=



> Level information in th=
e preference rule.


>    =
 A new parameter called sub-domain should be defined.


> 


>     =
;            &n=
bsp;           One could =
propose using existing SRMS preference values


> and assigning prefixes =
with preference values


>     =
;        based on levels they are advert=
ised in. This introduces more complex


> configuration requireme=
nts on the


>     =
;        network. The objective of this =
draft is to achieve consistent


> behaviours in case of m=
isconfigurations and


>     =
;        introducing more configurations=
 as a solution does not help.


> 


> 


>     =
;            &n=
bsp;           Based on t=
he Advertisement originated in ISIS Level or OSPF


> area below values are d=
efined.


> 


>     =
;            &n=
bsp;           Level 1 , =
non-zero OSPF area =3D1


>     =
;            &n=
bsp;           Level 2, O=
SPF Area 0 =3D 2


>     =
;            &n=
bsp;           Non IGPs s=
et subdomain =3D 0


> 


>     =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      Preference algorithm is changed as


> 


>    =
 1. Higher protocol preference wins


=
 


=
[Les:] I have explained above why protocol preference cannot be used.


 =



>    2. sm=
aller sub-domain wins


>    =
 3. Higher srms preference value wins


>    =
 4. Smaller range wins


>    =
 5.IPv6 entry wins over IPv4 entry


>    =
 6.Longer prefix length wins


>    =
 7.Smaller starting address (considered as an unsigned integer


>    =
    value) wins


>    =
 8.Smaller algorithm wins


>    =
 9. Smaller topology Id wins >>>>>>>>>>..Move=
d above SID comparison.


> since the all these rul=
es are applied


>     =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;         within protocol =
it's safe to compare topology IDs


=
[Les:] No – it isn’t – as explained above.=



>    =
 10. Smaller starting SID wins


> 


=
[Les:] SIDs are assigned either by the node(s) originating the prefix reach=
ability advertisement or by SRMS advertisements. The latter are level/area =
agnostic


[Bruno] I’m not sure to undertand what is meant by “level/are=
a agnostic”. In IS-IS, SRMS advertisements seems to be able to be sco=
ped on a per area/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segmen=
t-routing-extensions-13#section-2.4=



 


=
- and even you are agreeing that we should not change that.<=
span lang=3D"EN-US">


=
There is then no reason for the SID to be altered as it is advertised into =
different areas.  Which leads us to the conclusion that SIDs are not l=
evel/area specific.

=
 


=
If your concern is that border routers who may have more entries in their S=
ID database than intra-area routers may come to a different conclusion as r=
egards conflicts - I agree with you -
 but I do not believe your proposal resolves the problem.


=
Consider the following simple topology:=



=
 


=
A1-----A2------B2-----B1


=
 


=
All nodes run IS-IS.<=
/p>

=
A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100<=
/i>


=
A2 is a Level-1-2 router in Area A=



=
 


=
B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100<=
/i>


=
B2 is a Level-1-2 router in Area B=



=
 


=
If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav=
e the following SID databases on the four routers:


 =









A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 =



 =



Her=
e are the active entries on each node comparing the two algorithms


 =









Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 =



=
There is a tradeoff here between being able to forward some inter-area traf=
fic entering the network via the L2 sub-domain but impacting some intra-are=
a traffic  vs being able to forward all
 intra-area traffic but no inter-area traffic.


[Bruno] For MPLS transit, the ABR knows whether the traffic leaves the ar=
ea or not. If it does, it could take into account both SIDs: incoming label=
 from the SID of the incoming area, outgoing
 label from the SID of the outgoing area. Not that different from LDP which=
 select the label on a per neighbor basis…even though LDP does not do=
 routing i.e. does not natively have this information.


=
Not clear which strategy is “better” – but it is clear th=
at neither strategy eliminates all issues. Given that the same SID database=
 will NOT exist on all routers in multi-area deployments
 some risk exists and cannot be totally eliminated.


=
 


=
I do agree that we should try to minimize the use of conflicting SIDs for i=
nter-area traffic. What is lacking in the draft is a statement that conflic=
ting SIDs should not be leaked out of
 an area. I will work on a statement in the draft to make that point clear.=



 


<Shraddha> No=
t leaking the conflicting SIDs makes sense. But Even if the conflicting SID=
s are not leaked across boundaries, there is still a possibility that inter=
-area/intra-area traffic gets misforwarded at the area boundary. This issue=
 can cause potential security risks as the traffic can get delivered to uni=
ntended node.The best option is to ignore both conflicting entries when the=
y belong to different area/level


 


   &=
nbsp; 1. Higher protocol preference wins


    =
2. If the entries belong to different sub-domains ignore both entries


   &=
nbsp; 3. Higher srms preference value wins


   &=
nbsp; 4. Smaller range wins<=
/span>


   &=
nbsp; 5.IPv6 entry wins over IPv4 entry=



   &=
nbsp; 6.Longer prefix length wins<=
/o:p>


   &=
nbsp; 7.Smaller starting address (considered as an unsigned integer<=
/i>


   &=
nbsp;    value) wins


   &=
nbsp; 8.Smaller algorithm wins


   &=
nbsp; 9. Smaller topology Id 


   &=
nbsp;10. Smaller starting SID wins=



 


 


 


=
Thanx for bringing this issue up.<=
/o:p>


=
 


=
    Les


 =



> 


> 


> Rgds<=
/p>

> Shraddha


> 


> -----Original Message--=
---


> From: Martin Horneffer =
[mailto:maho@nic.dtag.de]


> Sent: Friday, July 14, =
2017 8:22 PM


> To: 
spring@ietf.org


> Subject: Re: [spring] W=
G Last Call for draft-ietf-spring-conflict-resolution


> 


> Strong support from me,=
 too.


> 


>  From an operator'=
s point of view this is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 sc=
hrieb Martin Vigoureux:


> ><=
/p>

> > WG,


> ><=
/p>

> > We are half-way th=
rough the WG Last Call and I am very surprised to


> > only see a single =
answer to it.


> ><=
/p>

> > I am not sure I'll=
 move this forward with only silence as support.


> ><=
/p>

> > -m


> ><=
/p>

> > Le 29/06/2017 =E0 =
15:28, Martin Vigoureux a =E9crit :


> >> Hello Working =
Group,


> >>


> >> This email sta=
rts a Working Group Last Call on


> >> draft-ietf-spr=
ing-conflict-resolution-04 [1] which is considered


> >> mature and rea=
dy for a final working group review.


> >>


> >> =A4 Please rea=
d this document if you haven't read the most recent


> >> version yet, a=
nd send your comments to the list, no later than *21st


> >> of July*.=



> >> Note that this=
 is *not only* a call for comments on the document; it


> >> is also a call=
 for support (or not) to publish this document as a


> >> Proposed Stand=
ard RFC.


> >>


> >> =A4 *Coinciden=
tally*, we are also polling for knowledge of any IPR that=



> >> applies to dra=
ft-ietf-spring-conflict-resolution, to ensure that IPR


> >> has been discl=
osed in compliance with IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 =
for more details).


> >>


> >> If you are lis=
ted as an Author or Contributor of


> >> draft-ietf-spr=
ing-conflict-resolution-04 please respond to this email

> >> and indicate w=
hether or not you are aware of any relevant IPR.


> >>


> >> Note that, as =
of today, no IPR has been disclosed against this


> >> document or it=
s earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]=



> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/<=
/span>


> >>


> >> ______________=
_________________________________


> >> spring mailing=
 list


> >> 
spring@ietf.org


> >> 
https://www.ietf.org/=
mailman/listinfo/spring


> >>


> ><=
/p>

> > __________________=
_____________________________


> > spring mailing lis=
t


> > spri=
ng@ietf.org


> > 
https://www.ietf.org/=
mailman/listinfo/spring


> ><=
/p>

> 


> 


> _______________________=
________________________


> spring mailing list


> spring@ie=
tf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


_=
___________________________________________________________________________=
_____________________________________________
&=
nbsp;
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc<=
/o:p>
p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler
a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=

I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.<=
/span>
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout 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 fo=
r 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_113a21de6f8e4d50a0f9cc53d8ec4932OPEXCLILMA4corporateadr_-- From nobody Tue Aug 1 09:29:11 2017 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 F0353131EC3 for ; Tue, 1 Aug 2017 09:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 bX5_uK6yh6Lo for ; Tue, 1 Aug 2017 09:29:04 -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 BFA9E131C28 for ; Tue, 1 Aug 2017 09:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=100770; q=dns/txt; s=iport; t=1501604943; x=1502814543; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AryJrbIy83H9xT3ssZdrMVNq8A3m+2ZBv0J0rfojohs=; b=Pw6wVymaKhtwEPXqCi6mEVh95VwB7udqlK5KrC6L0tnttPZigvp9qWcM +A7ujqoz8KpjnttWoq09epTlPMXeJsfuSCXcunQJXpx5LtFeCqB878l8E 6kWh+SSuBS6t1MzjwIIzCMwKAejumjFuPDdI/TJhg9TMo2RA2Z/dj3mpS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQBvq4BZ/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWRtJweOB49+gWyWDQ6CAQMhAQyESk8ChCU/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAgEBARgBAhBBBAwHBAIBCBEEAQEWCwEGBycLFAkIAgQBEggTi?= =?us-ascii?q?TBcCBCxOotQAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKIICgUyBYAGCGoEMhDA?= =?us-ascii?q?QARIBJgcYBgoCB4U1BZE5hi6IEAKHToMDiU2CFoVUg3iGaJV4AR84WSYLdxVJh?= =?us-ascii?q?RccgWd2AYd9gSOBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,306,1498521600"; d="scan'208,217";a="277318951" 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; 01 Aug 2017 16:29:00 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v71GT044007334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2017 16:29:00 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Aug 2017 11:28:59 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 1 Aug 2017 11:28:59 -0500 From: "Les Ginsberg (ginsberg)" To: "stephane.litkowski@orange.com" , "DECRAENE Bruno IMT/OLN" , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLAgAaTbgCAAHi3gIAAbspggAW0+QCAADBRoA== Date: Tue, 1 Aug 2017 16:28:59 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> In-Reply-To: <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.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.154.131.4] Content-Type: multipart/alternative; boundary="_000_cefd014c912644cab19f740c2e2e3846XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 16:29:09 -0000 --_000_cefd014c912644cab19f740c2e2e3846XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephane - The draft states (as this thread has discussed): Section 3.7 "In cases where multiple routing protocols are in use mapping entries advertised by all routing protocols MUST be included." In what way is this not clear?? Les From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 01, 2017 1:28 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_cefd014c912644cab19f740c2e2e3846XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Stephane –<= /o:p>

 

The draft states (as t= his thread has discussed):

 

Section 3.7=

 

“In cases where = multiple routing protocols are in use mapping

   &nbs= p;  entries advertised by all routing protocols MUST be included.̶= 1;

 

In what way is this no= t clear??

 

   Les<= /o:p>

 

From: stephane= .litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi Les,

 

There is something unc= lear to me here.

Let’s say we hav= e the following entries:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

There is a prefix conf= lict here because we have 4 SIDs for 10.0.0.1/32. The current proposal shou= ld pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest s= tart SID.

Now let’s say th= at the active route in the RIB is an IS-IS route because of local protocol = preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1<= /span>

So do you program the = following FIB entries (consider SRGB start at 16000 for every nodes) :

10.0.0.1/3= 2 via Te0/1 push 16100

Inlabel 16100 via Te0/= 1 swap 16100

 

This means that you de= facto allows cross protocols information use (e.g. ISIS route using an OSPF= mapping). The text is not crystal clear on that point.

 

Or the other possibili= ty is to not use the SID information because it does not comes from the rig= ht protocol. So you only program the FIB but not the LFIB:

10.0.0.1/3= 2 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

 

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution p= er LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.<= /o:p>

 

 

2)      Conflict resolution p= er LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)      Thesis: On the “= ;per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the &#= 8220;across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)     &= nbsp; Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.=

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 =

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 =

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 = 

“I=
n cases where the
&=
nbsp;  information advertised by a given protocol instance is either
&=
nbsp;  internally inconsistent or conflicts with advertisements from a=
nother
&=
nbsp;  protocol instance a means of achieving consistent forwarding be=
havior
&=
nbsp;  in the network is required.”
&=
nbsp;
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
/span>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


 Becomes active entry.<=
/b>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
/span>


Across implementations.=



 

&=
nbsp;


 =



 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees


     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
/span>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing=



   pro=
tocol.  MTID ranges are protocol specific and there may be


   sta=
ndardized protocol specific MTID assignments for topologies of a


   spe=
cific type (e.g., an AFI specific topology).  As mapping entries


   can=
 be sourced from multiple protocols it is not possible to use a


   net=
work scoped identifier for a topology when storing mapping entries<=
o:p>


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.<=
/o:p>


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic=



[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 =



- and even you =
are agreeing that we should not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.<=
o:p>


 =



<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries<=
/o:p>


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 =



 =



Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> 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


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


________________________________________________________________=
_________________________________________________________=

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

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


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


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


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


Thank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des 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.
--_000_cefd014c912644cab19f740c2e2e3846XCHALN001ciscocom_-- From nobody Tue Aug 1 12:30:55 2017 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 782D41322F5 for ; Tue, 1 Aug 2017 12:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 viOSd7mfltxB for ; Tue, 1 Aug 2017 12:30:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FB1126C0F for ; Tue, 1 Aug 2017 12:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113082; q=dns/txt; s=iport; t=1501615849; x=1502825449; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XsLjkbwQZmCi5YCjQUsxI90w9GO10W4uRTnbPkSTNkI=; b=CBX7g1bd5Nwxii+T7rBXSI7/KS7FHS9TfXgqaCzhR+ljlVdr0VkXYFod 7HGXPST+0lyEN5m1YjWKymXjqO0MeqrVu9E3hmfWzG98b6ZqZ8wybcbNF 4zl0DZVheKpoxD8eDKdYQW/SRMAaZVeQ9AttMRl/iqvc14Ju6qkqnYshz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAQAU1oBZ/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWRtJweOB49/gWyWDQ6CAQMhAQyESk8ChCU/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAgEBARgBAhBBBAcFBwQCAQgRAQMBARYLAQYHJwsUAwYIAgQBD?= =?us-ascii?q?QUIE4kwXAgQsVqLUgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiCAoFMgWABghq?= =?us-ascii?q?BDIQwEAELBwEmBxgGCgIHhTUFkTmGLogQAodOgwOJTYIWhVSDeIZolXgBHzhZJ?= =?us-ascii?q?gt3FUmFFxyBZ3YBh24CDRcHgQWBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,306,1498521600"; d="scan'208,217";a="275243576" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2017 19:30:45 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v71JUjIG004473 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2017 19:30:45 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Aug 2017 14:30:44 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 1 Aug 2017 14:30:44 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "spring@ietf.org" CC: LITKOWSKI Stephane OBS/OINIS , "Shraddha Hegde" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLAgAaTbgCAAHi3gIAAbspggAW0+QCAAFKEAIAADs1g Date: Tue, 1 Aug 2017 19:30:44 +0000 Message-ID: <5e2cd2a929b54e9098aec1e93bcf6663@XCH-ALN-001.cisco.com> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> <10776_1501593831_598080E7_10776_344_9_113a21de-6f8e-4d50-a0f9-cc53d8ec4932@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <10776_1501593831_598080E7_10776_344_9_113a21de-6f8e-4d50-a0f9-cc53d8ec4932@OPEXCLILMA4.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.154.131.4] Content-Type: multipart/alternative; boundary="_000_5e2cd2a929b54e9098aec1e93bcf6663XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:30:54 -0000 --_000_5e2cd2a929b54e9098aec1e93bcf6663XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - I think there is a fundamental point which is being overlooked here. If we look at https://www.ietf.org/id/draft-ietf-spring-segment-routing-12.= txt Section 2: (emphasis added) "SR Global Block (SRGB): local property of an SR node. In the MPLS architecture, SRGB is the set of local labels reserved for global segments." IGP s are one means of advertising SR values (SRGB, SIDs). This does not me= an that the scope of the value advertised is limited to the IGP instance. There is a great deal of precedence for this - many values advertised by IG= Ps are node properties (e.g., IP/IPv6 addresses ). Do not confuse the transport with the scope of the identifier being adverti= sed. Les From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Tuesday, August 01, 2017 6:24 AM To: Les Ginsberg (ginsberg); spring@ietf.org Cc: LITKOWSKI Stephane OBS/OINIS; Shraddha Hegde Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Regarding the existence of multiple protocols/LSDB, section 2 related to SR= GB seems to be light on this case. Sender behavior is defined in various SR protocol drafts such as [SR- IS-IS] which specify that senders MUST NOT advertise overlapping ranges. Receivers of SRGB ranges MUST validate the SRGB ranges advertised by other nodes. If the advertised ranges do not conform to the restrictions defined in the respective protocol specification receivers MUST ignore all advertised SRGB ranges from that node. When both IS-IS and OSPF are used, there is no document specifying how SRGB= advertisements should be done across protocols. Some people have expressed that SRGB is a property of the node, not of the = protocol. This seems to call for both IGP to advertise the same SRGB range(= s). But a strict reading of this draft may lead to consider that those SRGB ran= ge(s) are not disjoint, hence must all be ignored. For the set of ranges to be usable the ranges MUST be disjoint. Sender behavior is defined in various SR protocol drafts such as [SR- IS-IS] which specify that senders MUST NOT advertise overlapping ranges. Receivers of SRGB ranges MUST validate the SRGB ranges advertised by other nodes. If the advertised ranges do not conform to the restrictions defined in the respective protocol specification receivers MUST ignore all advertised SRGB ranges from that node. I think this point should be clarifier in the draft. Thanks, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkows= ki@orange.com Sent: Tuesday, August 01, 2017 10:28 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_5e2cd2a929b54e9098aec1e93bcf6663XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

I think there is a fun= damental point which is being overlooked here.

 

If we look at https://www.ietf.org/id/draft-ietf-spring-segment-routing-12.txt Section 2<= /a>: (emphasis added)

 

“SR Global Block= (SRGB): local property of an SR node.<= /span>  In the MPLS

   architect= ure, SRGB is the set of local labels reserved for global<= /p>

   segments.= ”

 

IGP s are one means of= advertising SR values (SRGB, SIDs). This does not mean that the scope of t= he value advertised is limited to the IGP instance.

There is a great deal = of precedence for this – many values advertised by IGPs are node prop= erties (e.g.,  IP/IPv6 addresses ).

 

Do not confuse the tra= nsport with the scope of the identifier being advertised.=

 

   Les<= /o:p>

 

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Tuesday, August 01, 2017 6:24 AM
To: Les Ginsberg (ginsberg); spring@ietf.org
Cc: LITKOWSKI Stephane OBS/OINIS; Shraddha Hegde
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Regarding the existenc= e of multiple protocols/LSDB, section 2 related to SRGB seems to be light o= n this case.

 

   Sender behavior is defined in various SR prot= ocol drafts such as [SR-

   IS-IS] which specify that senders MUST NOT ad= vertise overlapping

   ranges.

 

   Receivers of SRGB ranges MUST validate the SR= GB ranges advertised by

   other nodes.  If the advertised ranges d= o not conform to the

   restrictions defined in the respective protoc= ol specification

   receivers MUST ignore all advertised SRGB ran= ges from that node.

 

When both IS-IS and OS= PF are used, there is no document specifying how SRGB advertisements should= be done across protocols.

 

Some people have expre= ssed that SRGB is a property of the node, not of the protocol. This seems t= o call for both IGP to advertise the same SRGB range(s).<= /p>

But a strict reading o= f this draft may lead to consider that those SRGB range(s) are not disjoint= , hence must all be ignored.

   For the set of ranges to be usable the ranges= MUST be disjoint.

   Sender behavior is defined in various SR prot= ocol drafts such as [SR-

   IS-IS] which specify that senders MUST NOT ad= vertise overlapping

   ranges.

 

   Receivers of SRGB ranges MUST validate the SR= GB ranges advertised by

   other nodes.  If the advertised ranges d= o not conform to the

   restrictions defined in the respective protoc= ol specification

   receivers MUST ignore all advertised SRGB ran= ges from that node.

 

I think this point sho= uld be clarifier in the draft.

 

Thanks,

--Bruno

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: Tuesday, August 01, 2017 10:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi Les,

 

There is something unc= lear to me here.

Let’s say we hav= e the following entries:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

There is a prefix conf= lict here because we have 4 SIDs for 10.0.0.1/32. The current proposal shou= ld pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest s= tart SID.

Now let’s say th= at the active route in the RIB is an IS-IS route because of local protocol = preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1<= /span>

So do you program the = following FIB entries (consider SRGB start at 16000 for every nodes) :

10.0.0.1/3= 2 via Te0/1 push 16100

Inlabel 16100 via Te0/= 1 swap 16100

 

This means that you de= facto allows cross protocols information use (e.g. ISIS route using an OSPF= mapping). The text is not crystal clear on that point.

 

Or the other possibili= ty is to not use the SID information because it does not comes from the rig= ht protocol. So you only program the FIB but not the LFIB:

10.0.0.1/3= 2 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

 

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution p= er LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.<= /o:p>

 

 

2)      Conflict resolution p= er LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)      Thesis: On the “= ;per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the &#= 8220;across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)     &= nbsp; Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.=

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 =

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 =

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 = 

“I=
n cases where the
&=
nbsp;  information advertised by a given protocol instance is either
&=
nbsp;  internally inconsistent or conflicts with advertisements from a=
nother
&=
nbsp;  protocol instance a means of achieving consistent forwarding be=
havior
&=
nbsp;  in the network is required.”
&=
nbsp;
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
/span>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


 Becomes active entry.<=
/b>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
/span>


Across implementations.=



 

&=
nbsp;


 =



 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees


     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
/span>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing=



   pro=
tocol.  MTID ranges are protocol specific and there may be


   sta=
ndardized protocol specific MTID assignments for topologies of a


   spe=
cific type (e.g., an AFI specific topology).  As mapping entries


   can=
 be sourced from multiple protocols it is not possible to use a


   net=
work scoped identifier for a topology when storing mapping entries<=
o:p>


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.<=
/o:p>


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic=



[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 =



- and even you =
are agreeing that we should not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.<=
o:p>


 =



<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries<=
/o:p>


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 =



 =



Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> 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


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


________________________________________________________________=
_________________________________________________________=

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

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


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


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


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


Thank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des 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 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_5e2cd2a929b54e9098aec1e93bcf6663XCHALN001ciscocom_-- From nobody Wed Aug 2 00:41:08 2017 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 BEB95131C04; Wed, 2 Aug 2017 00:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 hcajyqX1w-jS; Wed, 2 Aug 2017 00:40:59 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDD212EC4B; Wed, 2 Aug 2017 00:40:56 -0700 (PDT) Received: from [192.168.0.2] (c213-89-111-155.bredband.comhem.se [213.89.111.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 88B65180156E; Wed, 2 Aug 2017 09:40:55 +0200 (CEST) To: "mpls@ietf.org" , "spring@ietf.org" References: <4829109f-9993-e015-c35e-29296d4853f9@pi.nu> Cc: "draft-ietf-mpls-spring-lsp-ping@ietf.org" , "mpls-chairs@ietf.org" , "spring-chairs@ietf.org" From: Loa Andersson Message-ID: Date: Wed, 2 Aug 2017 09:40:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4829109f-9993-e015-c35e-29296d4853f9@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] Working group last call on draft-ietf-mpls-spring-lsp-ping X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:41:02 -0000 Working Groups, This working group last call has been closed. There have been comments, can the authors/editors please update as necessary and post a new version. /Loa On 2017-07-11 11:35, Loa Andersson wrote: > Working Groups, > > This is to initiate a two week MPLS working group last call in on > draft-ietf-mpls-spring-lsp-ping-03. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any other IPRs that relates > to this document. > > As usual when a wglc is across an IETF week we do not count that week, > this working group last call therefore ends August 1, 2017. > > > /Loa > MPLS wg co-chairs > > PS > > I was a bit trigger happy and started this wglc with an ambiguous > subjet. Please use this mail when you are responding to the wglc. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Aug 2 01:08:56 2017 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 ADDC712EC4B for ; Wed, 2 Aug 2017 01:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Wx7ggo7XUJif for ; Wed, 2 Aug 2017 01:08:49 -0700 (PDT) Received: from relais-inet.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 F3DEC126BF3 for ; Wed, 2 Aug 2017 01:08:48 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 87BEA60298; Wed, 2 Aug 2017 10:08:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 55A3B40058; Wed, 2 Aug 2017 10:08:47 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0352.000; Wed, 2 Aug 2017 10:08:43 +0200 From: To: "Les Ginsberg (ginsberg)" , DECRAENE Bruno IMT/OLN , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nunx79fg8SlSEioEavvWIrey6JM9RIAgAZpFYCACngtgIAFnN4AgAUtYwCAAHi2gIAAxDgAgAV+hMCAAGdIgIABHD6Q Date: Wed, 2 Aug 2017 08:08:42 +0000 Message-ID: <31728_1501661327_5981888F_31728_392_1_57a14f82-f54c-4ea5-9202-35469a86da12@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_57a14f82f54c4ea5920235469a86da12OPEXCLILM21corporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:08:53 -0000 --_000_57a14f82f54c4ea5920235469a86da12OPEXCLILM21corporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No it's not, it's definitely not enough precise. Telling that you include all the entries (from all protocols) in the confli= ct resolution does not mean that cross protocol info may be used when progr= amming the FIB. That's a different story. And speaking as an operator, from a troubleshooting point of view it become= s a nightmare when you use some information coming from the protocol and so= me other informations coming from another source of information. So let's say that I have two concurrent routes for a prefix on a node N: OSPF 10.0.0.1/32 preference 100 via Te0/1 (N1) ISIS 10.0.0.1/32 preference 200 via Te0/2 (N2) N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISI= S. N has the following SID mappings: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) So to program the LFIB on N, I will take the ISIS route which is the active= route in the RIB. I will so consider the ISIS SRGB of N but from a conflic= t resolution point of view, I will use the OSPF advertisement (192,10.0.0.1= /32,100,1,0,0) So my LFIB entry will be: Inlabel: 2100, swap 2100 via Te0/2 In addition to that, the draft proposes a lower preference for BGP mappings= , which introduces a hierarchy between protocols like a protocol preference. Where is the global logic here ? It is really weird to retrieve some SR inf= ormation from one protocol, and some others from another protocol. I think we are touching things here that are not clearly defined by the arc= hitecture: the multi protocol behavior has never been clearly described, so= we probably need to think about it and define something before rushing on = the conflict resolution. I see two main approaches: a) We can consider that OSPF-SR extensions and the regular OSPF protoc= ol used for routing as completely separate things (same for IS-IS). So OSPF= -SR extensions are considered as a label distribution protocol like LDP is.= As LDP, it requires some routing informations to be used (that may come fr= om the OSPF routing protocol or even IS-IS). So SR builds a kind of label i= nformation base (LIB) like LDP and then the routing process combines the LI= B info with the active route to build the FIB entry. This approach is simil= ar to what you try to achieve except that I suppose here that all the SR in= formations should come from a single source (so if we pick a binding from O= SPF, we consider to use the OSPF SRGB). Thus as we have multiple sources of= labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, we also need to creat= e a preference mechanism between the protocols here as we do for the routin= g table. In such a scenario, when doing an IGP migration, I need to migrate= the label distribution protocol part and also the routing protocol part po= ssibly in multiple steps (by using preferences on each side). We need to de= fine how we can distribute SR informations from one protocol to the other. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routi= ng comes from the IS-IS active route) b) We can consider another approach where the SR informations are tied= with the routing protocol. When multiple protocols are running, we still n= eed to take care of the conflict resolution between the protocols, but this= may be solved easily by using the existing protocol preference of the RIB = as the first criteria. So a mapping will never be used if it does not corre= spond to an active route from the same protocol. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routi= ng comes from the IS-IS active route). The OSPF mappings for 10.0.0.1/32 ar= e not considered as there is no OSPF active route. The approach b) is more simpler to understand from an operation point of vi= ew (single preference to manage, single source of information) while a) has= some similarities with what we do when using LDP with the complexity of ha= ving multiple label distribution protocols involved. In any case, we need t= o document clearly the approach taken. Brgds, From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, August 01, 2017 18:29 To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; s= pring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Stephane - The draft states (as this thread has discussed): Section 3.7 "In cases where multiple routing protocols are in use mapping entries advertised by all routing protocols MUST be included." In what way is this not clear?? Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 01, 2017 1:28 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network. Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network. In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement. [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_57a14f82f54c4ea5920235469a86da12OPEXCLILM21corporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No it’s not, it&= #8217;s definitely not enough precise.

 

Telling that you inclu= de all the entries (from all protocols) in the conflict resolution does not= mean that cross protocol info may be used when programming the FIB. That&#= 8217;s a different story.

 

And speaking as an ope= rator, from a troubleshooting point of view it becomes a nightmare when you= use some information coming from the protocol and some other informations = coming from another source of information.

 

So let’s say tha= t I have two concurrent routes for a prefix on a node N:<= /p>

 

OSPF 10.0.0.1/32 prefe= rence 100 via Te0/1 (N1)

ISIS 10.0.0.1/32 prefe= rence 200 via Te0/2 (N2)

 

N, N1 and N2 advertise= SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.

N has the following SI= D mappings:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

So to program the LFIB= on N, I will take the ISIS route which is the active route in the RIB. I w= ill so consider the ISIS SRGB of N but from a conflict resolution point of = view, I will use the OSPF advertisement (192,10.0.0.1/32,100,1,0,0)

 

So my LFIB entry will = be:

Inlabel: 2= 100, swap 2100 via Te0/2

 = ;

In addition to that, t= he draft proposes a lower preference for BGP mappings, which introduces a h= ierarchy between protocols like a protocol preference.

 

Where is the global lo= gic here ? It is really weird to retrieve some SR information from one prot= ocol, and some others from another protocol.

 

I think we are touchin= g things here that are not clearly defined by the architecture: the multi p= rotocol behavior has never been clearly described, so we probably need to t= hink about it and define something before rushing on the conflict resolution.

 

I see two main approac= hes:

a)&n= bsp;     We can conside= r that OSPF-SR extensions and the regular OSPF protocol used for routing as= completely separate things (same for IS-IS). So OSPF-SR extensions are con= sidered as a label distribution protocol like LDP is. As LDP, it requires some routing informations to be used (tha= t may come from the OSPF routing protocol or even IS-IS). So SR builds a ki= nd of label information base (LIB) like LDP and then the routing process co= mbines the LIB info with the active route to build the FIB entry. This approach is similar to what you try to = achieve except that I suppose here that all the SR informations should come= from a single source (so if we pick a binding from OSPF, we consider to us= e the OSPF SRGB). Thus as we have multiple sources of labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, w= e also need to create a preference mechanism between the protocols here as = we do for the routing table. In such a scenario, when doing an IGP migratio= n, I need to migrate the label distribution protocol part and also the routing protocol part possibly in multiple step= s (by using preferences on each side). We need to define how we can distrib= ute SR informations from one protocol to the other.

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routing comes from t= he IS-IS active route)

 

b)&n= bsp;     We can conside= r another approach where the SR informations are tied with the routing prot= ocol. When multiple protocols are running, we still need to take care of th= e conflict resolution between the protocols, but this may be solved easily by using the existing protocol pr= eference of the RIB as the first criteria. So a mapping will never be used = if it does not correspond to an active route from the same protocol.

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routing comes from t= he IS-IS active route). The OSPF mappings for 10.0.0.1/32 are not considered as there is no OSPF active route.<= /o:p>

 

 

The approach b) is mor= e simpler to understand from an operation point of view (single preference = to manage, single source of information) while a) has some similarities wit= h what we do when using LDP with the complexity of having multiple label distribution protocols involved. In an= y case, we need to document clearly the approach taken.

 

 

Brgds,

 

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, August 01, 2017 18:29
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha H= egde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Stephane –<= /o:p>

 

The draft states (as t= his thread has discussed):

 

Section 3.7=

 

“In cases where = multiple routing protocols are in use mapping

   &nbs= p;  entries advertised by all routing protocols MUST be included.̶= 1;

 

In what way is this no= t clear??

 

   Les<= /o:p>

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi Les,

 

There is something unc= lear to me here.

Let’s say we hav= e the following entries:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

There is a prefix conf= lict here because we have 4 SIDs for 10.0.0.1/32. The current proposal shou= ld pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest s= tart SID.

Now let’s say th= at the active route in the RIB is an IS-IS route because of local protocol = preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1<= /span>

So do you program the = following FIB entries (consider SRGB start at 16000 for every nodes) :

10.0.0.1/3= 2 via Te0/1 push 16100

Inlabel 16100 via Te0/= 1 swap 16100

 

This means that you de= facto allows cross protocols information use (e.g. ISIS route using an OSPF= mapping). The text is not crystal clear on that point.

 

Or the other possibili= ty is to not use the SID information because it does not comes from the rig= ht protocol. So you only program the FIB but not the LFIB:

10.0.0.1/3= 2 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

 

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution p= er LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.<= /o:p>

 

 

2)      Conflict resolution p= er LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)      Thesis: On the “= ;per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the &#= 8220;across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)     &= nbsp; Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.=

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 =

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 =

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 = 

“In cases where the
   information advertised by a given protocol in=
stance is either
   internally inconsistent or conflicts with adv=
ertisements from another
   protocol instance a means of achieving consis=
tent forwarding behavior
   in the network is required.”
 
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
/span>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


 Becomes active entry.<=
/b>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
/span>


Across implementations.=



 

 


 =



 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees


     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
/span>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each


   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing=



   pro=
tocol.  MTID ranges are protocol specific and there may be


   sta=
ndardized protocol specific MTID assignments for topologies of a


   spe=
cific type (e.g., an AFI specific topology).  As mapping entries


   can=
 be sourced from multiple protocols it is not possible to use a


   net=
work scoped identifier for a topology when storing mapping entries<=
o:p>


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.


> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.<=
/o:p>


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic=



[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 =



- and even you =
are agreeing that we should not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.<=
o:p>


 =



<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries<=
/o:p>


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 =



 =



Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> 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


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;<=
o:p>
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_57a14f82f54c4ea5920235469a86da12OPEXCLILM21corporateadr_-- From nobody Wed Aug 2 01:37:59 2017 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 77213131D28 for ; Wed, 2 Aug 2017 01:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.857 X-Spam-Level: X-Spam-Status: No, score=-3.857 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=nokia.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 XOtDXfw0XF3k for ; Wed, 2 Aug 2017 01:37:55 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37399128C81 for ; Wed, 2 Aug 2017 01:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wgwbHIpYTI3lDYJz13BaZZWOCGBz71BXShGnCKUY5nA=; b=Y6Hj7YyaromEeJbEv0m9xmngGikJJdYthslYTIbwtE/qrK2CdXUzelfRXRsnKfj2N6sUJmV4BkKh2dCfDMn0zHIUeAjoc1OUrDRxge6/DRRK5s6UnyVg3njZtbh5Bn6cn56TUG7p9MYxEJNJjMgaYDkN2ssbnnQyvWo95crW/UM= Received: from HE1PR0701CA0058.eurprd07.prod.outlook.com (2603:10a6:3:9e::26) by VI1PR0701MB2205.eurprd07.prod.outlook.com (2603:10a6:800:30::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 2 Aug 2017 08:37:51 +0000 Received: from AM5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::207) by HE1PR0701CA0058.outlook.office365.com (2603:10a6:3:9e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10 via Frontend Transport; Wed, 2 Aug 2017 08:37:50 +0000 Received-SPF: Pass (protection.outlook.com: domain of nokia.com designates 135.245.241.12 as permitted sender) receiver=protection.outlook.com; client-ip=135.245.241.12; helo=fr711usmtp1-o.zeu.alcatel-lucent.com; Received: from fr711usmtp1-o.zeu.alcatel-lucent.com (135.245.241.12) by AM5EUR03FT043.mail.protection.outlook.com (10.152.17.43) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1282.16 via Frontend Transport; Wed, 2 Aug 2017 08:37:49 +0000 Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1-o.zeu.alcatel-lucent.com [135.239.2.135]) by fr711usmtp1-o.zeu.alcatel-lucent.com (GMO-o) with ESMTP id v728bjbr024794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Aug 2017 08:37:45 GMT Received: from princess.be.alcatel-lucent.com (bt9870.be.alcatel-lucent.com [138.203.16.150]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v728bZYn024764; Wed, 2 Aug 2017 08:37:38 GMT Received: from [138.203.22.179] (bt0suf [138.203.22.179]) by princess.be.alcatel-lucent.com (Postfix) with ESMTP id 9B13E104624; Wed, 2 Aug 2017 10:37:33 +0200 (CEST) To: , "Les Ginsberg (ginsberg)" , DECRAENE Bruno IMT/OLN , Shraddha Hegde , "spring@ietf.org" References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> <31728_1501661327_5981888F_31728_392_1_57a14f82-f54c-4ea5-9202-35469a86da12@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Dirk Goethals Message-ID: <1ebe8670-6bd1-d756-ac81-ecc14cd837b0@nokia.com> Date: Wed, 2 Aug 2017 10:37:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <31728_1501661327_5981888F_31728_392_1_57a14f82-f54c-4ea5-9202-35469a86da12@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:135.245.241.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39400400002)(39850400002)(39410400002)(39860400002)(2980300002)(438002)(43544003)(377454003)(51914003)(13464003)(199003)(189002)(189998001)(68736007)(790700001)(50466002)(561944003)(606006)(64126003)(2950100002)(229853002)(106466001)(38730400002)(8666007)(6246003)(65956001)(5660300001)(31686004)(6266002)(4001350100001)(33646002)(76176999)(6706004)(93886004)(2870700001)(50986999)(65806001)(54356999)(6306002)(65826007)(54896002)(23746002)(2501003)(236005)(81166006)(81156014)(8936002)(478600001)(356003)(8676002)(966005)(230783001)(97736004)(53936002)(16200700003)(5890100001)(23846002)(83506001)(31696002)(626005)(1941001)(36756003)(2906002)(86362001)(53946003)(53546010)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2205; H:fr711usmtp1-o.zeu.alcatel-lucent.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR03FT043; 1:WmWrto5yoBKwd68uVsNc+39hLn8sSV1F56UYBHJQhscWlxdhQBb3j9BYJM9XN1zliQlWOnApfdhW7BcCpU3E07HafT4yIF97ZXeFB0LmPIWO1cKRtDlaU7yU3wxnGY1uOs4rQSGHUofrYgi00UBhVEMVdfz1PzYiVjkZfaQXY1AdZxJcM+84yzcCnpOSTLX+38h1VDzgCLr5b593vJq4HpdOOUtJZm9Dqt6BzNBj7IivG1PRYCt7NksH6QAiI2osXQ1ISmqcOxuFuImO3JOQnKp8oQ8sthGsalY9ZxXmwKw5XpUsN+aIK084QblPSF+b3kqOfxIs0FB73rGRmrNthMropURonmPEAUW1hb3ShUXoqcfyFhBXx7P0h+an4VtixBNKHmdAzp1SiJzhF0+KU2XT7yi8oWxfGR5B938DeGT2EFZUlEkAjE/OQMAcOLQy2F3JIgS0/dJiAx8sDZcgDx5RENEpRFV7jLqe1Id+fzgKV0aqURIRMlvUEISt7urdTm0JPdzVAqPqJLFHN5tJfx/cstYN5XsL5+PuFSpFQ4wsgzT3BgMzlOjiT8B1UZH6GdnSA6Bx+30XxWTMRzd9kVETYIdml2NBWTjDaRtvPmD6ZQIy0LSMKEcyjpqcgy0rmLTquVy/MeQYYaGj3/l0BItIvCGkyBvsTfPg4bLgmtZ1eztor4DwAIU4QqKc6sLGKLlpfdT4ChM97PSbQOWt5dvhRaS/gRbfwIwPxRIZqHs6oz/81Rv+F/O0FmbDRBICpNKPgPG5CgtiK5DRAG97z6k5PlZdllwhy9I1KQ9elm2Os/bAFDMdWBt0Fbui760eW2YD56S38XZN1IlWi//IQJ5Tc6reBBevWYUNzRk7KR0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e2319f06-00d7-4470-e20c-08d4d981c274 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB2205; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR0701MB2205; 3:tqBO60MEaMNdIfztijycqrsNYgzIQYFzEq0R?= =?Windows-1252?Q?OKA0qWw6KVLpzKY6qQHshGPVRgYNuvA3mE/eEO9HehIDAKY6ZvKW/6V4?= =?Windows-1252?Q?tVxdNXnhIOOjy8HR6b1IKaRlh4NFNefdHi2gf9CF+/1bKKgLcOnSzTbr?= =?Windows-1252?Q?dP1ra7u02/tLGvbYOey2i6DCTSKPd9DtzbyssJ9m4jtwckB3MiDsYta2?= =?Windows-1252?Q?8j4Le/AYYZBKmbxy2hXTtLe16CkIDG41/JJaXHE8aoC7cy+rgoWdxwfJ?= =?Windows-1252?Q?1M28QDsoW0hz3ZQt8sWl3Qoy7xKgZRqg/+wiL/hqlAIOp5eLDktNm6eC?= =?Windows-1252?Q?ct2eflrlg+Dwsa5Yo2zqZf5usB0R66ckrhFV6erDz/+pmLS367/OaGwC?= =?Windows-1252?Q?aXWoly1abXb+gf5rxrSKofFy4s1eC/1091bssRd1nZRPtZ3WqZzpWgzF?= =?Windows-1252?Q?caH//IARuh116hKiqFhqVIHmspSGWK0gYbmK4mg7H9KVHNkakytOjaI4?= =?Windows-1252?Q?g07iIDKBghe211ay+GIPlkmY9Q0wc1EBi1zYGRlBK2b0UI2vNkbB8HIt?= =?Windows-1252?Q?bV3lv+KWq5dV34FEep4gaAIIQ6RZVA5IzxbJFzBwFHRMjxgAmbRBWfqS?= =?Windows-1252?Q?DlMVL5yNsbQ9+xkc97BuOGu/03X93FN3NW1RYJiWVdjL2iAZRwmG/d0r?= =?Windows-1252?Q?7vfAGEXpVOgZNx/lrxgo7XSCnjxRar8dRokyFU0H6Hgq/yhfMg6Hvu2c?= =?Windows-1252?Q?d7HEa3Wahv0r2i4xex6aRfptSh2bumVb6AodRekqPGQ1O764THtkULXB?= =?Windows-1252?Q?na8VnmUgrt6lf5W+yd56D9ZiAxkeS1bFVMPZq2EvY6aSFlT8/1kF8f+m?= =?Windows-1252?Q?Az9lkOvA2BE4ug3KYIuKVJ1UR/t+CwwUlrQI7ANdGAVxvAsWkubKm511?= =?Windows-1252?Q?j/ICD//y2fODI5EQ8KJLmfA2iLcVifaGNhbFEhqV8i6zLgTVpReosTOp?= =?Windows-1252?Q?QKvee+VtnkCjjguAMU4X6Du6EFs2ZRQgq/gig2A7I7tHh8bS+A=3D=3D?= X-MS-TrafficTypeDiagnostic: VI1PR0701MB2205: X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR0701MB2205; 25:oGSNKNocWw+ZJ41Bii3GgWofVEQQkp6D1Pj?= =?Windows-1252?Q?lEyJMPgl1/c47eZ+jLnPnaZaBj9V7aXREMvDJErEHFtn30b2qS0NHiL4?= =?Windows-1252?Q?j9F9DD2GUcp7+2Gv9t5r1+2heBhL9YlpzqwWUY87mNoW+3ngfGStm1AS?= =?Windows-1252?Q?7SkNfpQNsmduMpRDS0D8co1k0XaFd7WPW97zz7bS6GzsNBxJ48piMlBB?= =?Windows-1252?Q?yXCNp3fAkxb/tFFNcbkk3KR4hgEMcdLaGiwYtgSwlYcIY2aVDEA1WOgb?= =?Windows-1252?Q?JfBCkAr2fAwyO3c48OeppiFafD80keqKoLGGcmYDbGq9o5z4//+GSq/9?= =?Windows-1252?Q?00EFWiWtFVvQzzD0fU+iTr8VhLy4PrRJS8QoaOZRxLJsx/kWSWkZsXiY?= =?Windows-1252?Q?G8oYD03KoP5N0OvcvZlwP6y6VgKMCpVryugT8CnTeUc7s1BsXptzxSky?= =?Windows-1252?Q?bKyAvubnRFtZazkqanvGrrA1J2TjHum03x/DPlDZi5rtwPvKppgsgiyg?= =?Windows-1252?Q?uKx+itLSBBdYacaspXIDj+s8eHVUky6qKGyJMetrbhWZmHcnscgNmRB8?= =?Windows-1252?Q?/jhsnZ9OB2BKkq8ISSiBamD4cAo2dS/eMa1x6Bxc9wFF1Ycb2MVwyFa1?= =?Windows-1252?Q?B0gcJDwT++xD2NySqwId6HEeYrzBy5QEhVksJTmCQOVwXacnCdyNQynj?= =?Windows-1252?Q?la1FX//y4bahJNcQoO6RbTHMS1W+jl5DYQYEEumMrB7Sb4T0svJZZWhH?= =?Windows-1252?Q?HoQtGFcPUG8498xF1HKD8tknyTGDztyoL6BM5xEUz/qlYS/7qRQgq+h+?= =?Windows-1252?Q?6tRN/wswVaaKAfFvpROgu7Ehu8Bet33VZV+TXe8Q3lNQ3FCjTssQfDgH?= =?Windows-1252?Q?EWstsoftybaOxbmspJSVw+j1F8IKFqyrfzJBTjsrj4ZNb1zq5heORH1P?= =?Windows-1252?Q?VhcFmeu08CtFlJ1NOFhEKT5pcEguMUsf7T6brO8zIcQLZE2aUmthk05i?= =?Windows-1252?Q?8n9HianTzvwQ3xSArVkprQ9dhqOWMbdIThgMlCgXAvvFU6fbp3g=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 31:vfPHw6ehgZ/PpUshSvbC/UIU1wZmfvSK8rEbFRAwk6oKA0i1lI1aw7JHKfHBm4WvUDjdd7B4HLqhqWqmLc7zdB2ips3GDhUm3a8SHiNybPpTHqDYe2G9f1solswy7dnhKzwfa4z5gWu1eVAe51kiiGqV4a3smgyY9pwppLWC6qnaR0+g6zTSwAxJ4AykyDFYOrvjEhojE+32c/N6fQ/x+H/lrjhdWP7AEwBODLM6OTP13xcSqvf85KOMlJqAedaCv1JqdzJGrjd9deR8vJRdO38IhtCIE5WLRlAa6INqBrpo9ytgcUnhEHtavtEfrhF/DbXtD3PW47B7BQlsk6xZlE8OsTa2CtsPTgSJ+thUtBge4ehgaKPFOmkpuNl5t28dWDQb0kWfgBgYlTgDIFchhvsIVVe7mhwqW7pOmAw01PxEy53UWOhLMDsNCRr5hmSbCb5CvlQZz14xKImpljTkS0EQ0chx4JRpDEEVRWchZC2XD58nLKwVglyQW+3D7jHp9/zKk8LzgoQqj1NljEFfFi16q5hgcM0nYb7ZVyeCDc14dUpggsTRnmJOwA89lUuGpzEIF53/m8UeP7Tp3jbdyXH5rWhw+26vWQ12wuZTSL3Fhvmuvn7uyZ18nh9bcLflnIPhlPUk63v5unxxKsZ6FItEudhif8W+f9hfZVWbc3lYdGSiUYKqSm9+wNOwUYHAdOT7iL5a+LiP4DVEzRmeHw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 20:kVl4TUuo7PX6zUpdHLHlUWwuxMIRTLE5BwY5LxcAilx7Bzfib6969s7gkNNWznIPlyvKyLrv811dc9G0CSKHy6J54HKU55WUyLpywd3POE2trEjUbr6El26wM3hA59oJcGlt2ONdV1gCFsW0Vwe8NS5d1TNQX1UavyfNaptrpYVTlUMA6ki1bpiHgygPrZDCzSxaElyJepsZ1ehzE76XWAE6ZIQ3eTUX02DrAQJduZ3YRBmNFR67rdKstMZPq01hU6NAMmpQ9gyIF5EIATjjaGp1G9XotwGd3SXxGgWPIPHSXhTSa4bInqwl/rF6FDtIHv3R0jqAYObF+i2vfOJhy4y3vfEAA91HGp3iBW6t9iQ32+gYJYQ5ZxrdZ1bALtJtpbqjI1DJuu/7+nTp/+jdQAb77WiWfzkKdk8pbPRNOWgTQr0Nno2VJMYA8u8MXW4ihD/FHxuTacZyEEidv0rkcJZP7ZkaMkQUGYFOcvrAiBm6/1FsNdmNXxFHru5ug+79+svyMXlVan9AOZTlHTQTvSxW7m2/GZs16695uBeydUBsS4vdLKGQzceHt8qCe0t3FsxHnMfVjXjzrf56kpMHAEsoNR9iyZIudLVnWqdenIQ= X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705)(138986009662008)(95692535739014)(18271650672692); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(5005006)(8121501046)(13016025)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93004095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB2205; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB2205; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR0701MB2205; 4:m6V42LPbAdmD0gmXQR2W4fhNWUsrrwqE7pO/?= =?Windows-1252?Q?7pztst/xQgWPnNpPGRxXB3qjxnn28QEGbVhc8H8Px4GE0lrebfXYmvBf?= =?Windows-1252?Q?eybiVkMf2Grk5j/XupfbrSALTYWPn7UpHOn3v2H939V8D3Xu2PUF6KFL?= =?Windows-1252?Q?Q3MAzVFnvwprcrLZAjOlaYJaTTdVroqhD+ZpOgldcqvKVc1sMF1B2U+d?= =?Windows-1252?Q?bOUebAV2IA4tpl2I1dnFu+U0xEa3BmhqxnfPXus5/YkYA/7Qrtw6W+HH?= =?Windows-1252?Q?cyNC/tGYMkD5qK6jnUQh1ovv0zhmdYQc+khEqKZU9YmcNK1P0py1c8se?= =?Windows-1252?Q?3w1o5S20YncuKciphpFVDCuvt7jYkijLDRHdqf4cq/NfJj80R1d2oqxp?= =?Windows-1252?Q?r5zMNjH6d98q9yY8ncY1XsARLT/OJcN6UTIVtAv7scsTzxACSfXfHirN?= =?Windows-1252?Q?0/M2pXyPny8dd5UyxuLDN+Y6FLky+STDt0NQMe83+gNGUPO/6UnAmU6I?= =?Windows-1252?Q?xFbScEJUin4Agp4eUC4fsokwum5HHVr7ria7Rm7+BgKHFOcgM9vfE/ne?= =?Windows-1252?Q?QkwDtzehYNqOX/DktchK5vt4UeU3ddEwlRkUo6iGNc6qPKCgcZAWBygZ?= =?Windows-1252?Q?4OSPMj/0+XIECuQXeDHA2XRzZPgagmbrJQiWAwToaJ5E3iNn2+WlWOW/?= =?Windows-1252?Q?uViOdbvJd4ELibiisHiD4h8cluru1nAmz1h1N21lxWf6VRdrkhK/1Lcw?= =?Windows-1252?Q?JCYsmPw7eK4TbrIQ/uYscSRncNCbaiuVyEfYN6z0V/DwfIcEcoI+5ZZi?= =?Windows-1252?Q?rNdB13mQTf80Dizw0yPCZCJq0+lLOQevYGX5LvVSuelcqDyBv6kiZpqp?= =?Windows-1252?Q?woi/psm4kbjjQ/RKhYv6ohNWMRmT6nnKSNS+1JUP4sCNRF+hLeHQeWYl?= =?Windows-1252?Q?6OgRnDdvLCFIABl7ULaASKKN+E1T+c5ShrRhD5qIbj7E3NLUhvK7h7Nn?= =?Windows-1252?Q?DyWP+4L6GcOSPlwekx053RhIaiR82/j/mh1I0J+gqKl3CqLzW5AqANOa?= =?Windows-1252?Q?5SSao7Bsjc+sLkP7NtnNnQ3tJJlNB+fak/hCbksG0vnHSoRf6Gi8mtLU?= =?Windows-1252?Q?34VV5LPevBcxicJzaL8jhNPa/QFo5pS62rYNfWtj7/3hcV7Fni84Ezvb?= =?Windows-1252?Q?Ih2ZWOC2MQ6T4LZwDq33tm3ykn9GJXcY9YhIUCk/VMldlD752J8B2gLW?= =?Windows-1252?Q?LTBHH205v832taJRNlB/yqYjUBCa466ZrVEEYfzxM2CO44fhIkepbqTE?= =?Windows-1252?Q?SQKKlyxkDa+0XHbbT0eHDrrnA9B1w3DUQFdq1oiZb0M2ii7GhZX3fSqx?= =?Windows-1252?Q?Wzw7uh1zPOTK/NIhfKOJmSEaBxIVzQ3aNYgMEJYf2bqSKR973Snflc6l?= =?Windows-1252?Q?ABBymxqmHc4LGBbCMEq+nDr1R1f49XCCvX82Zi/6iB4R4lakE9zggfMK?= =?Windows-1252?Q?nQb9beI=3D?= X-Forefront-PRVS: 0387D64A71 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR0701MB2205; 23:YX6D2UwriKrtP10NHTux6t5OnfxjyHHJril?= =?Windows-1252?Q?frdBNef4pQYBbRhcKADi3pqZEmVSI8jyQirbIf3+vWMWurkGOB5YiO2i?= =?Windows-1252?Q?2LFXty2nVKxf/V+Pwf4iT81ZM1+6zQYNXWIw+ya3VIVyVWKYth33wMTE?= =?Windows-1252?Q?+Qs6uyjPWc690UVI05KueavLqWxlMUa0xwbCYO3SEzkBPmDvQuS1+4h/?= =?Windows-1252?Q?1JEalU/QhS0f3oIt11koCjgNUo3+B47pJ0YHfDASe6pXZBj4KoffJEAU?= =?Windows-1252?Q?A8yCaJ9NFo2VxK3ev/stba0Is01WrbalRV/4TADjnK8pKvX75vQB/EG1?= =?Windows-1252?Q?nTuCvjREG773xeR6tS4zTqdSdE6Pp79QYhEYBTO8E3DQJnDuIhBZ0ARi?= =?Windows-1252?Q?NQ3Y0BtuwKEJec1wbK4d35Ec7gCwr0LaWm96WUxoDzgK5JPzcnTIW0Jo?= =?Windows-1252?Q?eSGue3uU5qOmWJXSI6ZXxmR8fMlxwrFekOdkqu5WMKoINx2cEb7gaKAJ?= =?Windows-1252?Q?NAuBn7WEiqs0AREZgQ64N9o+SjqNlVw7cPltdPD1ebsD1rXxOAJQpwv2?= =?Windows-1252?Q?qavCC3ZAVlCxMHBetM48q4DV6UXgNv925QmuMP3IMxi7cgpdqnwmDu6E?= =?Windows-1252?Q?IzSN1Z4O9yT3DuwYrHjclbqPi+dYO9bX7Tq0ohc53jCr+zpFvZxQxBvz?= =?Windows-1252?Q?3HB8Nzb1fBJHzbVQ/ji/JdiB7j8E5KzYt90W0D7tH3KFkAC1rAGQx1mQ?= =?Windows-1252?Q?rgyuErSAKrYnLXYQ2B1bhgIpsYQKtjLyAWOF2YfN/HQyA4PcEQn2I6EK?= =?Windows-1252?Q?8QGz+H+DWXPoHoY0aoMeGKSDlfsKGLGzrquWm/OfaNFIBIE2LZSy4ALD?= =?Windows-1252?Q?s59S8Do+St9gkzP7evRDiGrb/lNnw4zSuIZG/4NaFVzBueEg/lRqzYmN?= =?Windows-1252?Q?subYk/WQfqWoyurPMYnognWKSPgw38IveMg0+oY+c0rewwfzVREJJedT?= =?Windows-1252?Q?730kQS0+9veDsbil14TIvEMJg4u/qozpkbxdjHGgFJwqmUJ/qnaNk/3x?= =?Windows-1252?Q?BU4gl/qPRwGgFwJkMx24vf1jaExPp5gOnHknK4u4/Rq1jpi0pbvBtAHw?= =?Windows-1252?Q?VfAIQAbJdwngykwK284OS2YDZ9MAMdPN6XqalJM1lXMIQkPnHl/jKv00?= =?Windows-1252?Q?RBjB44D56MOOtK1rNf2ZfAndWfMdSp+cjD673PsSmCyMNXuaWmnmULGA?= =?Windows-1252?Q?qKan+w5PPQPWHpcaMP1hipAKieuIXtO+QAV0BW1gOx2DGjhAOLklI1vy?= =?Windows-1252?Q?GRYshQcPq+v+cqHwB3woP3oWy5JT4M5WCEqi7jWIS3o5G/THCURE+b9F?= =?Windows-1252?Q?XtXvzWkdNdKax8Tzq7h0slDVhitbwkYUBiMhE9hJJHZHoGRmUgIMkpp6?= =?Windows-1252?Q?U9Cy7ZsKvY/1IpvsP7VUxPvm8fcNHbcO7f/Xe1aIbfK3LY0UcaAIHVmg?= =?Windows-1252?Q?i3CpQ1VFWK+1tqyxaEH2WW5wa2DVgbiHN5oBWlUMU8Eqz3T7ioNNxJjk?= =?Windows-1252?Q?3jqT/0h+Sne84QLxjJgMW7CKV+WzjyGg2HCr+h+0XqiL5oc33+v8Hljl?= =?Windows-1252?Q?iKN3IA62qGg933EH8/Gu6gZRL0VgXIR6k51CMuLSP49tBUXBLdoEJQt6?= =?Windows-1252?Q?BHHa3Q3YNheOYiwvb4PEKOIPhWSBfhi1qbyNUCtncy41Aq/B/pK8aJT0?= =?Windows-1252?Q?S9yeXMaZ5T560cBrVnLHxiTBY0UKiaoYPDertwvo=3D?= X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR0701MB2205; 6:gYHJYCRHkIshLPIculZP47EABJ+2irl8EKiY?= =?Windows-1252?Q?ub4MTCri2y9Rtz8t6Cl+GZbLYOpIat4YTL21uUQw3om7+xczeQM3O0CL?= =?Windows-1252?Q?Lbi7T0fjCvb/PZDa0+5kGXyxnQDDl2rOvERVLse0S0gFlIwxb7HNSeR9?= =?Windows-1252?Q?YJcmGwdg+87+cAZf3uOJBWsPRbL2GDxwCwRmQn8NvsBPXl1lfs0jlWWP?= =?Windows-1252?Q?G9hfoQv9oohyUoE4QRw5gpt8JOstAF7vj+l6oqJ7Yv4IxcfGexgHMc1O?= =?Windows-1252?Q?22iQh5dGiWhB+ZV59gEK8Ei9Ue+Vikmgk0A0eQTNh1PTZAnwsv0P8rpZ?= =?Windows-1252?Q?3gGOviAHvyPxi4cRtkELIX6ZFbKV37n0kakXIHSIFSrO95lQLEsx0/w+?= =?Windows-1252?Q?WWBXVqFdSfSNzwx3iaT3nxIlMkQbauxjosNA+9TeMn8+0Q0Z7AW0huor?= =?Windows-1252?Q?GSDjLAXKj79KzoFMvmeqoGQNwDn7UoXONsaa4/neAockOUUwjIKT8oRm?= =?Windows-1252?Q?4uEE61Y4/8Xs2zlVcbEft108IFvGixNp3EOU7r6vgIQOZ4dJDOH/Eq/s?= =?Windows-1252?Q?7tBT/XJMmMm3GZS6IsW8rPxxeBju0/GeQyMrf0Eu2xtIVrzkGHE3vBwW?= =?Windows-1252?Q?mBI6gz7fqJMvYK7P+VmHP47l8TGh64+WNcVjUmDg9lkvJIpvB40uZ9nW?= =?Windows-1252?Q?dxhE141m3IWwAnFpZj0MxmGSvpfU15lQ8WunpthL6BiZjJ8IwaOvErx4?= =?Windows-1252?Q?LIRH5vV/4PtgjMCKqK2rEyNQd4b4BhQe8J8SSn28GCLyHCY9oqLhlj/m?= =?Windows-1252?Q?74x3apvtZGxANuMMcwuWnXzs3nFYA1PdbzDw4o2UQr8QyUqLwcLoF07R?= =?Windows-1252?Q?wSWfyevNFybWWGiUgzfQrnPPxPGsJ7/zKlRnrXmSLNK3apa1Aq6/g2kx?= =?Windows-1252?Q?nicw5C124JprnBGnDpYDE9NxSfnpkYCv/M+j82wUvVu67dcdUkywaFTn?= =?Windows-1252?Q?dEUnMHFFof4kLcLXqYVwE074UMQMlEhvAGDAnctytDjPxqimWCWx29Mg?= =?Windows-1252?Q?wRdBvuPlBgdz3bUD44Y/GkxnglGVvQFUuYvr?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 5:OU2eCWVFtzFxgLAgvkbchNp3QUBXNBeVZdxA5mvzJJuXAebrxdtIbcwwmM0dpqe0nHhsg1rqRPKyINTX57tfpTuoaxQ64p+Em3CNX93SAhH9iGFhO5NBLj7bGvyLqYGtSeQBbM7OXgJ/ACnCGNPLj4/m1JIaH3qDe4o/xFIlgKRKtCXeehmwyAXCPPZwyTqvrpGqTVCpnBcF9E+EJilYhia7s3aAA3wdWnwcOi2d47cierOX/C/fNeLDDWljE69QPqkTrLa+YrPALwHuT10yLSklzZbroW4GHjtLsX02ikHIRC/4/zVKm9z+bNuzcXok188Rg46P3cTMRzGKPldCbII0T+bi8XnPIxDdhEqfBmGiWRQZZEeekW7eEG4zNs59/ugqgm98v9+5eooe5MPeCbENV6DnH0s8GzdY5CW4Kj6Dl3iyNfu9ODdDpydlceqok6OCsWQ7XmisINrAQV4XEn+HY33A92KFekz2fx+L1cz1kgYgTEkCA3iRrOaYtB7h; 24:l2IE649A561LZSzXX5TNv2v7040IWiMfJJKSFGO8I9BAt5FA8GPBLXudJVvMkqSEE1Axv5mvyrBs8qj7uTqsIlWPqbIeS2ptJn182T9Hrvw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 7:lLIymHTxhRGTHmH+GLF+Aewy2/ej5PcSMo9LPS+kOYv7kv1gsaNiTb8W5xOG2uGRHqRFxqIrconeTFY8kjNImf0Tf0bjTWsyzXncfy6Xu3+u7sL4bljTMY/raO46+rlgdUEq2En8qUZVfbw+135/gCApcqenISoJW9UPNhrX4aU0btYZTEExKYa57faP79H5ilf6yVzaCCJqxDTz1MXMV+PHzd4hGWn7KWPqSu/f1l+YVp9CpQhdbW2hU6/aTBpoglF1Yn6uhd69T/PZqjfmwnUuAbswpYXcCDHq3HPyONG8+Cg3h89y2fr5lce8CxH5OWoOqFVXwvMiOB80MPFx5W0t4ID9RYtONNyu29kQgqp+2eif/CeJ/Z2M+4e9j2n+0TnpZvN/1SHjjVaAhDUscvPyh5vzgT9yS5e2BgVTyC/ZBWsrX38C+Dp3l4UikBvaoOe/e8D748yEqGNjMSk5X4v8og8K95dGsXrcapVe/TKExMqQxthIWlUPtPMsHMXx4cjuoqcWWNC86HfnLa31tMyRvVuHqMLqq7aUC8zF3vYqYsDrtXPoXUa3yZhIrQ4T/p+oSyfK6AxI5sSiYFuS81Ef/Gf3MneCXqvc50gUGNNPwmOoo0wJ+i7Lxca2N8b3TOMxIAjXpLjRCqRI0KBgHEJpHCPRcEfbKsDuVU9hhDPcGr7yeAGvliTYS86TmK94aKvcs1hjAs2gTad4k5a2V3zF5x/qvA37UsoFiRICVL9J+whsZv4Fx7GaWGSbZ6Bc3kNaH7BztEYPJZrIOpx05pC6BK4yLhPdRWVcdOFPYgg= X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2017 08:37:49.6124 (UTC) X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5d471751-9675-428d-917b-70f44f9630b0; Ip=[135.245.241.12]; Helo=[fr711usmtp1-o.zeu.alcatel-lucent.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2205 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:37:58 -0000 Hi,

N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.

IMHO, there is no real conflict as both SRGB are disjoint, so why
not proving both entries in LFIB?
Dirk

Op 2/08/2017 om 10:08 schreef stephane.litkowski@orange.com:

No it’s not, it’s definitely not enough precise.

 

Telling that you include all the entries (from all protocols) in the conflict resolution does not mean that cross protocol info may be used when programming the FIB. That’s a different story.

 

And speaking as an operator, from a troubleshooting point of view it becomes a nightmare when you use some information coming from the protocol and some other informations coming from another source of information.

 

So let’s say that I have two concurrent routes for a prefix on a node N:

 

OSPF 10.0.0.1/32 preference 100 via Te0/1 (N1)

ISIS 10.0.0.1/32 preference 200 via Te0/2 (N2)

 

N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.

N has the following SID mappings:

OSPF mappings:

(192,10.0.0.1/32,100,1,0,0)

(128,10.0.0.1/32,200,300,0,0)

 

ISIS mappings:

(192,10.0.0.1/32,300,1,0,0)

(128,10.0.0.1/32,400,300,0,0)

 

 

So to program the LFIB on N, I will take the ISIS route which is the active route in the RIB. I will so consider the ISIS SRGB of N but from a conflict resolution point of view, I will use the OSPF advertisement (192,10.0.0.1/32,100,1,0,0)

 

So my LFIB entry will be:

Inlabel: 2100, swap 2100 via Te0/2

 

In addition to that, the draft proposes a lower preference for BGP mappings, which introduces a hierarchy between protocols like a protocol preference.

 

Where is the global logic here ? It is really weird to retrieve some SR information from one protocol, and some others from another protocol.

 

I think we are touching things here that are not clearly defined by the architecture: the multi protocol behavior has never been clearly described, so we probably need to think about it and define something before rushing on the conflict resolution.

 

I see two main approaches:

a)      We can consider that OSPF-SR extensions and the regular OSPF protocol used for routing as completely separate things (same for IS-IS). So OSPF-SR extensions are considered as a label distribution protocol like LDP is. As LDP, it requires some routing informations to be used (that may come from the OSPF routing protocol or even IS-IS). So SR builds a kind of label information base (LIB) like LDP and then the routing process combines the LIB info with the active route to build the FIB entry. This approach is similar to what you try to achieve except that I suppose here that all the SR informations should come from a single source (so if we pick a binding from OSPF, we consider to use the OSPF SRGB). Thus as we have multiple sources of labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, we also need to create a preference mechanism between the protocols here as we do for the routing table. In such a scenario, when doing an IGP migration, I need to migrate the label distribution protocol part and also the routing protocol part possibly in multiple steps (by using preferences on each side). We need to define how we can distribute SR informations from one protocol to the other.

 

In this approach, using the example above, we should program this entry in the LFIB: Inlabel 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routing comes from the IS-IS active route)

 

b)      We can consider another approach where the SR informations are tied with the routing protocol. When multiple protocols are running, we still need to take care of the conflict resolution between the protocols, but this may be solved easily by using the existing protocol preference of the RIB as the first criteria. So a mapping will never be used if it does not correspond to an active route from the same protocol.

 

In this approach, using the example above, we should program this entry in the LFIB: Inlabel 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routing comes from the IS-IS active route). The OSPF mappings for 10.0.0.1/32 are not considered as there is no OSPF active route.

 

 

The approach b) is more simpler to understand from an operation point of view (single preference to manage, single source of information) while a) has some similarities with what we do when using LDP with the complexity of having multiple label distribution protocols involved. In any case, we need to document clearly the approach taken.

 

 

Brgds,

 

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, August 01, 2017 18:29
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

 

Stephane –

 

The draft states (as this thread has discussed):

 

Section 3.7

 

“In cases where multiple routing protocols are in use mapping

      entries advertised by all routing protocols MUST be included.”

 

In what way is this not clear??

 

   Les

 

From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

 

Hi Les,

 

There is something unclear to me here.

Let’s say we have the following entries:

OSPF mappings:

(192,10.0.0.1/32,100,1,0,0)

(128,10.0.0.1/32,200,300,0,0)

 

ISIS mappings:

(192,10.0.0.1/32,300,1,0,0)

(128,10.0.0.1/32,400,300,0,0)

 

 

There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest start SID.

Now let’s say that the active route in the RIB is an IS-IS route because of local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1

So do you program the following FIB entries (consider SRGB start at 16000 for every nodes) :

10.0.0.1/32 via Te0/1 push 16100

Inlabel 16100 via Te0/1 swap 16100

 

This means that you defacto allows cross protocols information use (e.g. ISIS route using an OSPF mapping). The text is not crystal clear on that point.

 

Or the other possibility is to not use the SID information because it does not comes from the right protocol. So you only program the FIB but not the LFIB:

10.0.0.1/32 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, July 29, 2017 00:25
To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

 

Bruno –

 

Please reread “Section 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit that “entries advertised by all routing protocols MUST be included”.

 

Also please read my recent response to  Shraddha as regards the pitfalls of using protocol specific databases for conflict resolution.

 

    Les

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

 

Always as an individual contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution per LSDB or across LSDB

I’ve haven’t re-read all text, but I’m not certain that the current text specifies whether the conflict resolution must be run on a per LSDB basis, or across all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.

 

 

2)      Conflict resolution per LSDB or across LSDB ?

I believe Les means across LSDB but Shraddha raised interesting questions regarding this, using area/level or IGP transitioning use cases.

a)      Thesis: On the “per LSDB” side:

Running conflict resolution on a per LSDB ensure that this conflict resolution runs on the same data, which is required to get the same result. Otherwise, as per Shraddha’s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the “across LSDB” side:

We need consistency across the network, hence across LSDBs.

 

c)       Synthesis

We seem to have a tradeoff issue as we can’t have both. However, it seems to me that the consistency issue with different LSDB is not specific to SR conflict resolution. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still enforce.

 

 

Some (two) details inlined [Bruno]

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

 

Thanks for the response.

 

   It is important  to keep the network functioning correctly in case of transitioning from

   one protocol to the other.

  

   Let us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typical transitioning technique is ships in the night where both protocols will be

   enabled in the network with OSPF having better preference and the issue in ISIS routing do

   not affect the traffic. Once the ISIS deployment is complete, the traffic will be switched

   to ISIS by changing preference.

  

   In case of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rules that the conflicts are protocol independent, it is possible that config mistakes in ISIS

   will bring down the routes in OSPF. The ISIS topology and OSPF topology is not expected to be congruent

   during transition,

   so the conflicts seen on each node combining the two views will not be similar.

   This has potential to cause routing loops/ traffic drops in the network.

  

   I suggest to add the protocol-preference as one of the parameters in the preference algorithm

   with this being on the top of the list.

   The resultant conflict resolution will be consistent on ISIS topology and OSPF topology

  and is the best suited model for ships in the night transitions.

 

Pls see inline for other responses.

 

Rgds

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shraddha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde

> Sent: Thursday, July 20, 2017 11:44 PM

> To: spring@ietf.org

> Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>             Section 3.4 has the statement

>             "Active Entries in the database may be used in forwarding."

>

>              This is a very loose statement which does not enforce

> implementations to program the forwarding plane

>             with the active database entries.

>             This does not ensure traffic drops are minimized.

>

[Les:] Conflict resolution is only determining which entries are eligible to be used in forwarding. This does not mean that all "active" entries will be used . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix which is not actually reachable. So the language in the draft is intentional and is correct.

<Shraddha> The language in the draft is ambiguous and it does not help achieve consistent forwarding behavior across implementations.

                      Prefixes that are not reachable may not be used in forwarding which is acceptable but the draft does not mandate that the reachable prefixes which are active

                    MUST be programmed. Normative language is necessary in the draft w.r.t using active entries in forwarding.

 

 

>             The Forwarding plane programming aspects are completely missing in

> the document.

>             A separate section is needed which describes the different aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft. If you want a description of how SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpls.

 

<Shraddha> The point I am bringing up here is not how SR MPLS forwarding works. It is w.r.t to programming the forwarding plane when there is a conflict.

                      

The abstract section has below statement

 

“In cases where the
   information advertised by a given protocol instance is either
   internally inconsistent or conflicts with advertisements from another
   protocol instance a means of achieving consistent forwarding behavior
   in the network is required.”
 
If the draft is not going to address the forwarding plane detail w.r.t conflicting entries it is definitely not meeting the
The objective described above.
 
Take an example of a conflict
(192, 192.0.2.1/32, 200, 1, 0, 0)
   (192, 192.0.2.222/32, 200, 1, 0, 0)
   SID 200 has been assigned to 192.0.2.1/32 by the
   first advertisement.
   The second advertisement assigns SID 200 to 192.0.2.222/32.
 
In this case after applying the preference rules
(192, 192.0.2.1/32, 200, 1, 0, 0)
 Becomes active entry.
 
As per the text in the draft,” it may be used in forwarding” so some implementations
May choose to program forwarding plane and some may not which does not give a consistent forwarding behavior
Across implementations.
 
 

 

 

>

> 2.  Protocol independent resolution and impact on network migrations

>              In case of network migration from one protocol to other for ex: OSPF-

> SR to ISIS-SR,

>              it is useful to associate protocol preferences on a local node to the SID

> advertisement

>             and feed into the conflict resolution. This would make sure the

> conflicts will always

>             have a winner which is an advertisement from protocol with

> preferred admin-distance.

>

>             There is need for introducing another preference value specific to

> protocol preference

>             and make it the top rule in the preference rule hierarchy.

>

 

[Les:] "admin distance" is a locally defined preference which is not advertised. It is therefore not possible to include it as a parameter in an algorithm which requires a consistent answer on all nodes throughout the network.

 

<Shraddha>  In migration cases, topologies across two different protocols are not congruent causing inconsistent behavior.
                       Using admin-distance as an input parameter keeps the conflict resolution with-in the protocol and guarantees
                      Consistent behavior across all the nodes corresponding to that protocol.
 
                     The drafts tries to address this scenario partially between IGP and BGP by suggesting preference values. But that does not solve the
Problem between two different IGPs. 
 

 

>             This would also solve the issue of MT-ID numbers being different in

> different protocols

>             as the SIDs would be compared within a protocol advertisement.

 

[Les:] I do not understand what relationship you see between "protocol preference" and "MT-ID".

MT-ID values are scoped by  the protocol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to be used by different protocols when advertising routes for the same physical topology. This is why the draft's use of "topology" is not as MTID but rather as a locally scoped identifier. >From Section 3:

 

" Note: Topology is a locally scoped identifier assigned by each

   router.  Although it may have an association with Multitopology

   Identifiers (MTID) advertised by routing protocols it is NOT

   equivalent to these identifiers.  MTIDs are scoped by a given routing

   protocol.  MTID ranges are protocol specific and there may be

   standardized protocol specific MTID assignments for topologies of a

   specific type (e.g., an AFI specific topology).  As mapping entries

   can be sourced from multiple protocols it is not possible to use a

   network scoped identifier for a topology when storing mapping entries

   in the local database."

 

Topology is then used to detect different scopes for a mapping entry - which may result in a SID conflict if the same SID is used in different topologies, but it cannot be used as a tiebreaker since its value is local and any preference (e.g., higher value wins)  is not guaranteed to result in consistent answers on all nodes in the network. Which is why we have Section 3.3 Rule #8:

 

   "8.  If topology IDs are NOT identical both entries MUST be ignored"

<Shraddha> Lets keep this discussion on-hold until we decide on the protocol preference and migration issues.

 

>

> 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF areas,

> It's possible that the

>      conflicts are not visible in entire domain but are visible only on the border

> router as the border routers

>      have the database of both domains.

>     The conflict resolution preference Rules should be enhanced to include the

> Level information in the preference rule.

>     A new parameter called sub-domain should be defined.

>

>                             One could propose using existing SRMS preference values

> and assigning prefixes with preference values

>             based on levels they are advertised in. This introduces more complex

> configuration requirements on the

>             network. The objective of this draft is to achieve consistent

> behaviours in case of misconfigurations and

>             introducing more configurations as a solution does not help.

>

>

>                             Based on the Advertisement originated in ISIS Level or OSPF

> area below values are defined.

>

>                             Level 1 , non-zero OSPF area =1

>                             Level 2, OSPF Area 0 = 2

>                             Non IGPs set subdomain = 0

>

>                                                             Preference algorithm is changed as

>

>     1. Higher protocol preference wins

 

[Les:] I have explained above why protocol preference cannot be used.

 

>    2. smaller sub-domain wins

>     3. Higher srms preference value wins

>     4. Smaller range wins

>     5.IPv6 entry wins over IPv4 entry

>     6.Longer prefix length wins

>     7.Smaller starting address (considered as an unsigned integer

>        value) wins

>     8.Smaller algorithm wins

>     9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison.

> since the all these rules are applied

>                                                     within protocol it's safe to compare topology IDs

[Les:] No – it isn’t – as explained above.

>     10. Smaller starting SID wins

>

[Les:] SIDs are assigned either by the node(s) originating the prefix reachability advertisement or by SRMS advertisements. The latter are level/area agnostic

[Bruno] I’m not sure to undertand what is meant by “level/area agnostic”. In IS-IS, SRMS advertisements seems to be able to be scoped on a per area/level basis using the S-flag

https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#section-2.4

 

- and even you are agreeing that we should not change that.

There is then no reason for the SID to be altered as it is advertised into different areas.  Which leads us to the conclusion that SIDs are not level/area specific.

 

If your concern is that border routers who may have more entries in their SID database than intra-area routers may come to a different conclusion as regards conflicts - I agree with you - but I do not believe your proposal resolves the problem.

Consider the following simple topology:

 

A1-----A2------B2-----B1

 

All nodes run IS-IS.

A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100

A2 is a Level-1-2 router in Area A

 

B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100

B2 is a Level-1-2 router in Area B

 

If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we have the following SID databases on the four routers:

 

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

 

 

Here are the active entries on each node comparing the two algorithms

 

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

 

There is a tradeoff here between being able to forward some inter-area traffic entering the network via the L2 sub-domain but impacting some intra-area traffic  vs being able to forward all intra-area traffic but no inter-area traffic.

[Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area or not. If it does, it could take into account both SIDs: incoming label from the SID of the incoming area, outgoing label from the SID of the outgoing area. Not that different from LDP which select the label on a per neighbor basis…even though LDP does not do routing i.e. does not natively have this information.

Not clear which strategy is “better” – but it is clear that neither strategy eliminates all issues. Given that the same SID database will NOT exist on all routers in multi-area deployments some risk exists and cannot be totally eliminated.

 

I do agree that we should try to minimize the use of conflicting SIDs for inter-area traffic. What is lacking in the draft is a statement that conflicting SIDs should not be leaked out of an area. I will work on a statement in the draft to make that point clear.

 

<Shraddha> Not leaking the conflicting SIDs makes sense. But Even if the conflicting SIDs are not leaked across boundaries, there is still a possibility that inter-area/intra-area traffic gets misforwarded at the area boundary. This issue can cause potential security risks as the traffic can get delivered to unintended node.The best option is to ignore both conflicting entries when they belong to different area/level
 
     1. Higher protocol preference wins
    2. If the entries belong to different sub-domains ignore both entries
     3. Higher srms preference value wins
     4. Smaller range wins
     5.IPv6 entry wins over IPv4 entry
     6.Longer prefix length wins
     7.Smaller starting address (considered as an unsigned integer
        value) wins
     8.Smaller algorithm wins
     9. Smaller topology Id 
    10. Smaller starting SID wins
 

 

 

Thanx for bringing this issue up.

 

    Les

 

>

>

> Rgds

> Shraddha

>

> -----Original Message-----

> From: Martin Horneffer [mailto:maho@nic.dtag.de]

> Sent: Friday, July 14, 2017 8:22 PM

> To: spring@ietf.org

> Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

>

> Strong support from me, too.

>

>  From an operator's point of view this is really needed.

>

> Best regards, Martin

>

>

> Am 10.07.17 um 14:58 schrieb Martin Vigoureux:

> >

> > WG,

> >

> > We are half-way through the WG Last Call and I am very surprised to

> > only see a single answer to it.

> >

> > I am not sure I'll move this forward with only silence as support.

> >

> > -m

> >

> > Le 29/06/2017 à 15:28, Martin Vigoureux a écrit :

> >> Hello Working Group,

> >>

> >> This email starts a Working Group Last Call on

> >> draft-ietf-spring-conflict-resolution-04 [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 *21st

> >> of July*.

> >> Note that this is *not only* a call for comments on the document; it

> >> is also a call for support (or not) to publish this document as a

> >> Proposed Standard RFC.

> >>

> >> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that

> >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR

> >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979,

> >> 4879,

> >> 3669 and 5378 for more details).

> >>

> >> If you are listed as an Author or Contributor of

> >> draft-ietf-spring-conflict-resolution-04 please respond to this email

> >> and indicate whether or not you are aware of any relevant IPR.

> >>

> >> Note that, as of today, no IPR has been disclosed against this

> >> document or its earlier versions.

> >>

> >> Thank you,

> >> Martin

> >>

> >> [1]

> >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio

> >> n/

> >>

> >> _______________________________________________

> >> 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

> >

>

>

> _______________________________________________

> spring mailing list

> spring@ietf.org

> https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

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

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



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

From nobody Wed Aug 2 05:39:51 2017 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 3FA6913207F for ; Wed, 2 Aug 2017 05:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 3vSkM-WrMEAn for ; Wed, 2 Aug 2017 05:39:45 -0700 (PDT) Received: from relais-inet.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 0FE2B132066 for ; Wed, 2 Aug 2017 05:39:45 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id AA33612060C; Wed, 2 Aug 2017 14:39:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 7EFD060078; Wed, 2 Aug 2017 14:39:43 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Wed, 2 Aug 2017 14:39:40 +0200 From: To: Dirk Goethals , "Les Ginsberg (ginsberg)" , DECRAENE Bruno IMT/OLN , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nunx79fg8SlSEioEavvWIrey6JM9RIAgAZpFYCACngtgIAFnN4AgAUtYwCAAHi2gIAAxDgAgAV+hMCAAGdIgIABHD6Q///yYQCAAF40EA== Date: Wed, 2 Aug 2017 12:39:40 +0000 Message-ID: <20941_1501677583_5981C80F_20941_143_1_01c52328-50b1-4ba1-84e2-5dbe7dfd3a79@OPEXCLILMA2.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> <31728_1501661327_5981888F_31728_392_1_57a14f82-f54c-4ea5-9202-35469a86da12@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1ebe8670-6bd1-d756-ac81-ecc14cd837b0@nokia.com> In-Reply-To: <1ebe8670-6bd1-d756-ac81-ecc14cd837b0@nokia.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_01c5232850b14ba184e25dbe7dfd3a79OPEXCLILMA2corporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 12:39:50 -0000 --_000_01c5232850b14ba184e25dbe7dfd3a79OPEXCLILMA2corporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In the current version of the draft, conflict evaluation does not look at t= he SRGB, it only looks at SIDs. In any case, in the given example, there is a prefix conflict =3D> multiple= SIDs/labels associated to a single prefix. >From an LFIB point of view, as per the current draft, only a single entry w= ill be installed as the others will be inactive in the mapping DB. I agree that in this example two LFIB entries may be installed but this req= uires: - a per protocol conflict resolution to let one entry per protocol= to be active. - managing SRGB overlap between protocols: specifications define t= hat SRGB advertisement cannot overlap within a protocol, but not across pro= tocols. It is obvious that an implementation must avoid to advertise overla= pping SRGBs between two protocols (e.g. OSPF [1000,2000] and IS-IS [1200,22= 00]), but I do not think we mandate this somewhere (we do it inside a parti= cular protocol instance) =3D> I think we need to take care of this in any c= ase as even if two SIDs are different, the resulting labels may be equal in= case of SRGB overlap. Brgds, From: Dirk Goethals [mailto:dirk.goethals@nokia.com] Sent: Wednesday, August 02, 2017 10:38 To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); DECRAENE Bruno I= MT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Hi, N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISI= S. IMHO, there is no real conflict as both SRGB are disjoint, so why not proving both entries in LFIB? Dirk Op 2/08/2017 om 10:08 schreef stephane.litkowski@orange.com: No it's not, it's definitely not enough precise. Telling that you include all the entries (from all protocols) in the confli= ct resolution does not mean that cross protocol info may be used when progr= amming the FIB. That's a different story. And speaking as an operator, from a troubleshooting point of view it become= s a nightmare when you use some information coming from the protocol and so= me other informations coming from another source of information. So let's say that I have two concurrent routes for a prefix on a node N: OSPF 10.0.0.1/32 preference 100 via Te0/1 (N1) ISIS 10.0.0.1/32 preference 200 via Te0/2 (N2) N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISI= S. N has the following SID mappings: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) So to program the LFIB on N, I will take the ISIS route which is the active= route in the RIB. I will so consider the ISIS SRGB of N but from a conflic= t resolution point of view, I will use the OSPF advertisement (192,10.0.0.1= /32,100,1,0,0) So my LFIB entry will be: Inlabel: 2100, swap 2100 via Te0/2 In addition to that, the draft proposes a lower preference for BGP mappings= , which introduces a hierarchy between protocols like a protocol preference. Where is the global logic here ? It is really weird to retrieve some SR inf= ormation from one protocol, and some others from another protocol. I think we are touching things here that are not clearly defined by the arc= hitecture: the multi protocol behavior has never been clearly described, so= we probably need to think about it and define something before rushing on = the conflict resolution. I see two main approaches: a) We can consider that OSPF-SR extensions and the regular OSPF protoc= ol used for routing as completely separate things (same for IS-IS). So OSPF= -SR extensions are considered as a label distribution protocol like LDP is.= As LDP, it requires some routing informations to be used (that may come fr= om the OSPF routing protocol or even IS-IS). So SR builds a kind of label i= nformation base (LIB) like LDP and then the routing process combines the LI= B info with the active route to build the FIB entry. This approach is simil= ar to what you try to achieve except that I suppose here that all the SR in= formations should come from a single source (so if we pick a binding from O= SPF, we consider to use the OSPF SRGB). Thus as we have multiple sources of= labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, we also need to creat= e a preference mechanism between the protocols here as we do for the routin= g table. In such a scenario, when doing an IGP migration, I need to migrate= the label distribution protocol part and also the routing protocol part po= ssibly in multiple steps (by using preferences on each side). We need to de= fine how we can distribute SR informations from one protocol to the other. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routi= ng comes from the IS-IS active route) b) We can consider another approach where the SR informations are tied= with the routing protocol. When multiple protocols are running, we still n= eed to take care of the conflict resolution between the protocols, but this= may be solved easily by using the existing protocol preference of the RIB = as the first criteria. So a mapping will never be used if it does not corre= spond to an active route from the same protocol. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routi= ng comes from the IS-IS active route). The OSPF mappings for 10.0.0.1/32 ar= e not considered as there is no OSPF active route. The approach b) is more simpler to understand from an operation point of vi= ew (single preference to manage, single source of information) while a) has= some similarities with what we do when using LDP with the complexity of ha= ving multiple label distribution protocols involved. In any case, we need t= o document clearly the approach taken. Brgds, From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, August 01, 2017 18:29 To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; s= pring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Stephane - The draft states (as this thread has discussed): Section 3.7 "In cases where multiple routing protocols are in use mapping entries advertised by all routing protocols MUST be included." In what way is this not clear?? Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 01, 2017 1:28 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network. Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network. In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement. [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_01c5232850b14ba184e25dbe7dfd3a79OPEXCLILMA2corporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

In the current version= of the draft, conflict evaluation does not look at the SRGB, it only looks= at SIDs.

In any case, in the gi= ven example, there is a prefix conflict =3D> multiple SIDs/labels associ= ated to a single prefix.

 

From an LFIB point of = view, as per the current draft, only a single entry will be installed as th= e others will be inactive in the mapping DB.

I agree that in this e= xample two LFIB entries may be installed but this requires:

-&nb= sp;         a per protocol= conflict resolution to let one entry per protocol to be active.=

-&nb= sp;         managing SRGB = overlap between protocols: specifications define that SRGB advertisement ca= nnot overlap within a protocol, but not across protocols. It is obvious tha= t an implementation must avoid to advertise overlapping SRGBs between two protocols (e.g. OSPF [1000,2000] a= nd IS-IS [1200,2200]), but I do not think we mandate this somewhere (we do = it inside a particular protocol instance) =3D> I think we need to take c= are of this in any case as even if two SIDs are different, the resulting labels may be equal in case of SRGB over= lap.

 

Brgds,

 

 

From: Dirk Goethals [mailto:dirk.goethals@nokia.com]
Sent: Wednesday, August 02, 2017 10:38
To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); DECRAENE = Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi,

N, N1 and N2 advertise SRGB [1000,20= 00] in OSPF and SRGB [2000,3000] in ISIS.

IMHO, there is no rea= l conflict as both SRGB are disjoint, so why
not proving both entries in LFIB?
Dirk

Op 2/08/2017 om 10:08 schreef stephane.litkowski@orange.com:

No it’s not, it&= #8217;s definitely not enough precise.

 

Telling that you inclu= de all the entries (from all protocols) in the conflict resolution does not= mean that cross protocol info may be used when programming the FIB. That&#= 8217;s a different story.

 

And speaking as an ope= rator, from a troubleshooting point of view it becomes a nightmare when you= use some information coming from the protocol and some other informations = coming from another source of information.

 

So let’s say tha= t I have two concurrent routes for a prefix on a node N:<= /p>

 

OSPF 10.0.0.1/32 prefe= rence 100 via Te0/1 (N1)

ISIS 10.0.0.1/32 prefe= rence 200 via Te0/2 (N2)

 

N, N1 and N2 advertise= SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.

N has the following SI= D mappings:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

So to program the LFIB= on N, I will take the ISIS route which is the active route in the RIB. I w= ill so consider the ISIS SRGB of N but from a conflict resolution point of = view, I will use the OSPF advertisement (192,10.0.0.1/32,100,1,0,0)

 

So my LFIB entry will = be:

Inlabel: 2= 100, swap 2100 via Te0/2

 

In addition to that, t= he draft proposes a lower preference for BGP mappings, which introduces a h= ierarchy between protocols like a protocol preference.

 

Where is the global lo= gic here ? It is really weird to retrieve some SR information from one prot= ocol, and some others from another protocol.

 

I think we are touchin= g things here that are not clearly defined by the architecture: the multi p= rotocol behavior has never been clearly described, so we probably need to t= hink about it and define something before rushing on the conflict resolution.

 

I see two main approac= hes:

a)      We can consider that = OSPF-SR extensions and the regular OSPF protocol used for routing as comple= tely separate things (same for IS-IS). So OSPF-SR extensions are considered= as a label distribution protocol like LDP is. As LDP, it requires some routing informations to be used (tha= t may come from the OSPF routing protocol or even IS-IS). So SR builds a ki= nd of label information base (LIB) like LDP and then the routing process co= mbines the LIB info with the active route to build the FIB entry. This approach is similar to what you try to = achieve except that I suppose here that all the SR informations should come= from a single source (so if we pick a binding from OSPF, we consider to us= e the OSPF SRGB). Thus as we have multiple sources of labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, w= e also need to create a preference mechanism between the protocols here as = we do for the routing table. In such a scenario, when doing an IGP migratio= n, I need to migrate the label distribution protocol part and also the routing protocol part possibly in multiple step= s (by using preferences on each side). We need to define how we can distrib= ute SR informations from one protocol to the other.

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routing comes from t= he IS-IS active route)

 

b)      We can consider anoth= er approach where the SR informations are tied with the routing protocol. W= hen multiple protocols are running, we still need to take care of the confl= ict resolution between the protocols, but this may be solved easily by using the existing protocol preference of= the RIB as the first criteria. So a mapping will never be used if it does = not correspond to an active route from the same protocol.=

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routing comes from t= he IS-IS active route). The OSPF mappings for 10.0.0.1/32 are not considered as there is no OSPF active route.

 

 

The approach b) is mor= e simpler to understand from an operation point of view (single preference = to manage, single source of information) while a) has some similarities wit= h what we do when using LDP with the complexity of having multiple label distribution protocols involved. In an= y case, we need to document clearly the approach taken.

 

 

Brgds,

 

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Tuesday, August 01, 2017 18:29
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha H= egde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Stephane –

 

The draft states (as t= his thread has discussed):

 

Section 3.7

 

“In cases where = multiple routing protocols are in use mapping

   &nbs= p;  entries advertised by all routing protocols MUST be included.̶= 1;

 

In what way is this no= t clear??

 

   Les

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi Les,

 

There is something unc= lear to me here.

Let’s say we hav= e the following entries:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

There is a prefix conf= lict here because we have 4 SIDs for 10.0.0.1/32. The current proposal shou= ld pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest s= tart SID.

Now let’s say th= at the active route in the RIB is an IS-IS route because of local protocol = preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1<= /span>

So do you program the = following FIB entries (consider SRGB start at 16000 for every nodes) :

10.0.0.1/3= 2 via Te0/1 push 16100

Inlabel 16100 via Te0/= 1 swap 16100

 

This means that you de= facto allows cross protocols information use (e.g. ISIS route using an OSPF= mapping). The text is not crystal clear on that point.

 

Or the other possibili= ty is to not use the SID information because it does not comes from the rig= ht protocol. So you only program the FIB but not the LFIB:

10.0.0.1/3= 2 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

 

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution p= er LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.<= /o:p>

 

 

2)      Conflict resolution p= er LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)      Thesis: On the “= ;per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the &#= 8220;across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)     &= nbsp; Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.=

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict resolution is only determin= ing which entries are eligible to be used in forwarding. This does not mean= that all "active" entries will be used . The most obvious exampl= e (but not the only possible one) of this is an SRMS entry that is associated with a prefix which is not actually reach= able. So the language in the draft is intentional and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 =

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 =

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 = 

“In cases where the
   information advertised by a given protocol in=
stance is either
   internally inconsistent or conflicts with adv=
ertisements from another
   protocol instance a means of achieving consis=
tent forwarding behavior
   in the network is required.”
 
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
/span>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


 Becomes active entry.<=
/b>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
/span>


Across implementations.=



 

 


 =



 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 


[Les:] "admin distance" is a locally=
 defined preference which is not advertised. It is therefore not possible t=
o include it as a parameter in an algorithm which requires a consistent ans=
wer on all nodes throughout the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees


     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
/span>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each


   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing=



   pro=
tocol.  MTID ranges are protocol specific and there may be


   sta=
ndardized protocol specific MTID assignments for topologies of a


   spe=
cific type (e.g., an AFI specific topology).  As mapping entries


   can=
 be sourced from multiple protocols it is not possible to use a


   net=
work scoped identifier for a topology when storing mapping entries<=
o:p>


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.


> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have explained above why protocol =
preference cannot be used.


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No – it isn’t – as=
 explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are assigned either by the node=
(s) originating the prefix reachability advertisement or by SRMS advertisem=
ents. The latter are level/area agnostic


[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 =



- and even you are agreeing that we should =
not change that.


There is then no reason for the SID to be a=
ltered as it is advertised into different areas.  Which leads us to th=
e conclusion that SIDs are not level/area specific.


 


If your concern is that border routers who =
may have more entries in their SID database than intra-area routers may com=
e to a different conclusion as regards conflicts - I agree with you - but I=
 do not believe your proposal resolves
 the problem.


Consider the following simple topology:=



 


A1-----A2------B2-----B1=



 


All nodes run IS-IS.


A1 is a Level-1 router in Area A. It advert=
ises: 1.1.1.1/32 SID 100


A2 is a Level-1-2 router in Area A<=
o:p>


 


B1 is a Level-1 router in Area B. It advert=
ises: 2.2.2.2/32 SID 100


B2 is a Level-1-2 router in Area B<=
o:p>


 


If Level 1 routes are leaked into Level 2 b=
ut NOT down into Level 1, we have the following SID databases on the four r=
outers:


 








A1




1.1.1.1/32 100








A2




1.1.1.1/32 100


2.2.2.2/32 100








B1




2.2.2.2/32 100








B2




1.1.1.1/32 100


2.2.2.2/32 100








 


 


Here are the active entries on each node compa=
ring the two algorithms


 








Node




Draft Algorithm




Shraddha Algorithm








A1




1.1.1.1/32 100




1.1.1.1/32 100








A2




1.1.1.1/32 100




1.1.1.1/32 100








B1




2.2.2.2/32 100




2.2.2.2/32 100








B2




1.1.1.1/32 100




2.2.2.2/32 100








 


There is a tradeoff here between being able=
 to forward some inter-area traffic entering the network via the L2 sub-dom=
ain but impacting some intra-area traffic  vs being able to forward al=
l intra-area traffic but no inter-area
 traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which strategy is “better&#=
8221; – but it is clear that neither strategy eliminates all issues. =
Given that the same SID database will NOT exist on all routers in multi-are=
a deployments some risk exists and cannot be totally
 eliminated.


 


I do agree that we should try to minimize t=
he use of conflicting SIDs for inter-area traffic. What is lacking in the d=
raft is a statement that conflicting SIDs should not be leaked out of an ar=
ea. I will work on a statement in
 the draft to make that point clear.


 =



<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries<=
/o:p>


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 =



 =



Thanx for bringing this issue up.


 


    Les

 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> 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


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;<=
o:p>
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.




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

 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_01c5232850b14ba184e25dbe7dfd3a79OPEXCLILMA2corporateadr_-- From nobody Wed Aug 2 08:53:18 2017 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 5CF5D131935; Wed, 2 Aug 2017 08:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 n7zwd1nAiXWK; Wed, 2 Aug 2017 08:53:09 -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 6CA8F1241F5; Wed, 2 Aug 2017 08:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8628; q=dns/txt; s=iport; t=1501689189; x=1502898789; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3FJ8dX/KKSDJuLaGvK2Kjm4RdPuENqVMuujtWcFqFEU=; b=DQDjIyP9mc5ohBUNbk2fQw7ha9QzFWKopfk+58WXZPKJ7hKRGBs/2xxq +eCmMmGXGoXuw//YghB9N4HK5Vu3ANOlC4CADPSoh9UCDV/3VkgQXvaIp Iy/Hhv6hvk6/Yr0cokSApNPhc/j424WIKwgAKrnbFj2In4EZPF/67jMUj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQAY9YFZ/5hdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBUScHjgeQBJJNhTEOggSFRwIahBs/GAECAQEBAQEBAWsohRkGI0g?= =?us-ascii?q?DCw4CAgEIPwMCAgIZFxQRAgQOBYlLZK5EgiaLTQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR0FgyOCAoFMgWMrgnyEQAERAgEkEYJ8MIIxBZdqiBIClCqCDYVWimGJWow?= =?us-ascii?q?gAR84fwt3FUkSAYcHdohegQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,312,1498521600"; d="scan'208,217";a="465361805" 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; 02 Aug 2017 15:52:56 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v72FqtSY026723 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 15:52:56 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 11:52:54 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 11:52:54 -0400 From: "Carlos Pignataro (cpignata)" To: Loa Andersson CC: "mpls@ietf.org" , "spring@ietf.org" , "draft-ietf-mpls-spring-lsp-ping@ietf.org" , "mpls-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: Working group last call on draft-ietf-mpls-spring-lsp-ping Thread-Index: AQHTC2KzUsJXouOcMESKDhDHMOrhH6JxerwA Date: Wed, 2 Aug 2017 15:52:54 +0000 Message-ID: References: <4829109f-9993-e015-c35e-29296d4853f9@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.133] Content-Type: multipart/alternative; boundary="_000_F9275DA6574B400C9C05EC84AD073D8Dciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Working group last call on draft-ietf-mpls-spring-lsp-ping X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:53:10 -0000 --_000_F9275DA6574B400C9C05EC84AD073D8Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IExvYS4gTmV3IHJldmlzaW9uIGFkZHJlc3NpbmcgYWxsIGNvbW1lbnRzLCBwb3N0 ZWQuDQoNClRoYW5rcyENCg0K4oCUIENhcmxvcy4NCg0KT24gQXVnIDIsIDIwMTcsIGF0IDM6NDAg QU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQoN CldvcmtpbmcgR3JvdXBzLA0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVu IGNsb3NlZC4NCg0KVGhlcmUgaGF2ZSBiZWVuIGNvbW1lbnRzLCBjYW4gdGhlIGF1dGhvcnMvZWRp dG9ycyBwbGVhc2UgdXBkYXRlIGFzDQpuZWNlc3NhcnkgYW5kIHBvc3QgYSBuZXcgdmVyc2lvbi4N Cg0KL0xvYQ0KDQpPbiAyMDE3LTA3LTExIDExOjM1LCBMb2EgQW5kZXJzc29uIHdyb3RlOg0KV29y a2luZyBHcm91cHMsDQoNClRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayBNUExTIHdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIGluIG9uDQpkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWxzcC1waW5n LTAzLg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcg bGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQpUaGVyZSBhcmUg bm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCg0KQWxsIHRoZSBhdXRo b3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXANCm1h aWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBScyB0aGF0 IHJlbGF0ZXMNCnRvIHRoaXMgZG9jdW1lbnQuDQoNCkFzIHVzdWFsIHdoZW4gYSB3Z2xjIGlzIGFj cm9zcyBhbiBJRVRGIHdlZWsgd2UgZG8gbm90IGNvdW50IHRoYXQgd2VlaywNCnRoaXMgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgdGhlcmVmb3JlIGVuZHMgQXVndXN0IDEsIDIwMTcuDQoNCg0KL0xv YQ0KTVBMUyB3ZyBjby1jaGFpcnMNCg0KUFMNCg0KSSB3YXMgYSBiaXQgdHJpZ2dlciBoYXBweSBh bmQgc3RhcnRlZCB0aGlzIHdnbGMgd2l0aCBhbiBhbWJpZ3VvdXMNCnN1YmpldC4gUGxlYXNlIHVz ZSB0aGlzIG1haWwgd2hlbiB5b3UgYXJlIHJlc3BvbmRpbmcgdG8gdGhlIHdnbGMuDQoNCi0tDQoN Cg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAx Lmh1YXdlaS5jb208bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbT4NClNlbmlvciBNUExTIEV4 cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+ DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEg MjEgNjQNCg0K4oCUDQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tPG1haWx0bzpj YXJsb3NAY2lzY28uY29tPg0KDQrigJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBk byBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5 bnRoZXNpcy4iDQoNCg== --_000_F9275DA6574B400C9C05EC84AD073D8Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <336A1E1FF9BD4647BD23C1FD2C1E6712@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmsgeW91IExvYS4gTmV3IHJl dmlzaW9uIGFkZHJlc3NpbmcgYWxsIGNvbW1lbnRzLCBwb3N0ZWQuDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MhPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyAyLCAyMDE3LCBhdCAzOjQw IEFNLCBMb2EgQW5kZXJzc29uICZsdDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiBjbGFzcz0i Ij5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Xb3JraW5nIEdy b3Vwcyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIGhhcyBiZWVuIGNsb3NlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVy ZSBoYXZlIGJlZW4gY29tbWVudHMsIGNhbiB0aGUgYXV0aG9ycy9lZGl0b3JzIHBsZWFzZSB1cGRh dGUgYXM8YnIgY2xhc3M9IiI+DQpuZWNlc3NhcnkgYW5kIHBvc3QgYSBuZXcgdmVyc2lvbi48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQovTG9hPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KT24gMjAxNy0wNy0xMSAxMTozNSwgTG9hIEFuZGVyc3NvbiB3cm90ZTo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Xb3JraW5nIEdyb3Vwcyw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGlzIHRvIGluaXRpYXRlIGEgdHdvIHdlZWsgTVBM UyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBpbiBvbjxiciBjbGFzcz0iIj4NCmRyYWZ0LWlldGYt bXBscy1zcHJpbmctbHNwLXBpbmctMDMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxl YXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3ZyBtYWlsaW5nIGxpc3QgKDxhIGhy ZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiBjbGFzcz0iIj5tcGxzQGlldGYub3JnPC9hPikuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBh Z2FpbnN0IHRoaXMgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWxsIHRo ZSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3Jv dXA8YnIgY2xhc3M9IiI+DQptYWlsaW5nIGxpc3QgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2Yg YW55IG90aGVyIElQUnMgdGhhdCByZWxhdGVzPGJyIGNsYXNzPSIiPg0KdG8gdGhpcyBkb2N1bWVu dC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBcyB1c3VhbCB3aGVuIGEgd2dsYyBpcyBh Y3Jvc3MgYW4gSUVURiB3ZWVrIHdlIGRvIG5vdCBjb3VudCB0aGF0IHdlZWssPGJyIGNsYXNzPSIi Pg0KdGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCB0aGVyZWZvcmUgZW5kcyBBdWd1c3QgMSwg MjAxNy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQovTG9hPGJy IGNsYXNzPSIiPg0KTVBMUyB3ZyBjby1jaGFpcnM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpQUzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgd2FzIGEgYml0IHRyaWdnZXIgaGFw cHkgYW5kIHN0YXJ0ZWQgdGhpcyB3Z2xjIHdpdGggYW4gYW1iaWd1b3VzPGJyIGNsYXNzPSIiPg0K c3ViamV0LiBQbGVhc2UgdXNlIHRoaXMgbWFpbCB3aGVuIHlvdSBhcmUgcmVzcG9uZGluZyB0byB0 aGUgd2dsYy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQotLSA8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpMb2EgQW5kZXJzc29u ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VtYWlsOiA8YSBocmVmPSJtYWlsdG86bG9hQG1haWww MS5odWF3ZWkuY29tIiBjbGFzcz0iIj4NCmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT48YnIgY2xh c3M9IiI+DQpTZW5pb3IgTVBMUyBFeHBlcnQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgY2xhc3M9IiI+bG9hQHBpLm51PC9hPjxi ciBjbGFzcz0iIj4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3Bob25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NDxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQrigJQ8L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25hdGFybywmbmJz cDs8YSBocmVmPSJtYWlsdG86Y2FybG9zQGNpc2NvLmNvbSIgY2xhc3M9IiI+Y2FybG9zQGNpc2Nv LmNvbTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8aSBjbGFzcz0iIj7igJxTb21l dGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8g bWFrZSBteXNlbGYgc291bmQgbW9yZSZuYnNwO3Bob3Rvc3ludGhlc2lzLiZxdW90OzwvaT48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F9275DA6574B400C9C05EC84AD073D8Dciscocom_-- From nobody Wed Aug 2 11:06:33 2017 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 EDA31126C22 for ; Wed, 2 Aug 2017 11:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 1SBLeJru8uEG for ; Wed, 2 Aug 2017 11:06:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB701201F2 for ; Wed, 2 Aug 2017 11:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=141552; q=dns/txt; s=iport; t=1501697187; x=1502906787; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cyMbRsp6bBJU92K32vWpxVC2UV9SVr9f+2oqdG9jdX4=; b=DoeRDcbTAE4jOXELJnZW2susgUDjOB9V5QRun+DH/FG2427gedZLIvM9 y/KfpjIceYMU8rTPsQsq31Mn7cvMPq+9mInoIlL4Y6FikAEBybOzyYibp l4AXubEoy/3/P8b05rzF0vg2w9BtKyob0gPaDOiKPx8sLb0Qg74i9MipL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AAD/E4JZ/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFAeOB5ADgW6WEA6CAQMhAQyDOoEQTwKENT8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQECAQEBCg4BAhBBBAwHBAIBCBEBAwEBFgsBBgcnCxQDBggCB?= =?us-ascii?q?AESCBOJMFwIELAri0oBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMoggKBTIFiAYI?= =?us-ascii?q?bgQyEMBABEgEmBxgGCgIHhTUFkTmGMYgSAodRgwOJTYIWhVaDeIZplXoBHzhZJ?= =?us-ascii?q?gt3FUmEXjkcgWd2AYc5gSOBDwEBAQ?= X-IronPort-AV: E=Sophos; i="5.41,312,1498521600"; d="scan'208,217"; a="59882866" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 18:06:23 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v72I6MXQ013114 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 18:06:22 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 13:06:21 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 13:06:22 -0500 From: "Les Ginsberg (ginsberg)" To: "stephane.litkowski@orange.com" , "DECRAENE Bruno IMT/OLN" , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLAgAaTbgCAAHi3gIAAbspggAW0+QCAADBRoIABXH4AgAAxSPA= Date: Wed, 2 Aug 2017 18:06:21 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> <31728_1501661327_5981888F_31728_392_1_57a14f82-f54c-4ea5-9202-35469a86da12@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <31728_1501661327_5981888F_31728_392_1_57a14f82-f54c-4ea5-9202-35469a86da12@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.27.157] Content-Type: multipart/alternative; boundary="_000_d574c1d1bb104a578462bdb5f78b8416XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:06:32 -0000 --_000_d574c1d1bb104a578462bdb5f78b8416XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephane - I think it is important to look at conflict resolution in the context of th= e SR architecture. Much of what you discuss below is inconsistent with the = SR architecture and as a result it creates new problems that actually don't= need to be solved. Let me see if I can get us back on the same page. As previously quoted, https://www.ietf.org/id/draft-ietf-spring-segment-ro= uting-12.txt Section 2: (emphasis added) "SR Global Block (SRGB): local property of an SR node. In the MPLS architecture, SRGB is the set of local labels reserved for global segments." >From the same draft, Section 3 we have other relevant statements: "An IGP-Prefix segment is an IGP segment attached to an IGP prefix. An IGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR/IGP domain." "In the context of an instance and a topology, multiple Prefix-SID's MAY be allocated to the same IGP Prefix as long as the algorithm value is different in each one." There are a number of conclusions which follow from these statements. 1)An SRGB is a node property, it is NOT a per protocol property 2)The SID associated with a prefix is a property of the prefix, not the pro= tocol which advertises it. 3)One - and only one - SID is associated with a given prefix/algorithm 4)The SR architecture is NOT defining a per protocol forwarding plane - it = is defining an SR forwarding plane If we try to support per protocol SRGBs and allow per protocol SID assignme= nts, this leads to a number of problems, some of which you have mentioned i= n your posts. By far the biggest issue is that if we allow per protocol SID assignments, = then we are actually REQUIRED to support non-overlapping per protocol SRGBs= , which in turn means that we are REQUIRED to support multiple incoming lab= els for the same prefix. This follows because a node has no way to determine which protocol will pro= vide the winning route on its neighbors. It would therefore have to program= all of the SIDs which the neighbor might use to forward traffic. This in turn leads to the requirement for per protocol non-overlapping SRGB= s because if we allow the same SID to be used for different prefixes so lon= g as the advertising protocols are different, we then have to have a way of= mapping that same SID to two different local labels. The only way to guara= ntee that is possible is to have per protocol non-overlapping SRGBs. All of this is in conflict with the SR architecture as per the excerpts I h= ave quoted above - which is why the conflict resolution drafts specifies =B7 one conflict resolution database populated by advertisements pr= ovided by all protocols/SRMSs. =B7 SRGB inconsistency detection on a per node basis If there is concern that the current language in the draft is not explicit = enough, I am happy to work on adding clarifying language. But it is crucial to understand and agree that the choice to use a protocol= independent database and per node SRGB is required by the SR Architecture. A few more comments inline... From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Wednesday, August 02, 2017 1:09 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n No it's not, it's definitely not enough precise. Telling that you include all the entries (from all protocols) in the confli= ct resolution does not mean that cross protocol info may be used when progr= amming the FIB. That's a different story. And speaking as an operator, from a troubleshooting point of view it become= s a nightmare when you use some information coming from the protocol and so= me other informations coming from another source of information. So let's say that I have two concurrent routes for a prefix on a node N: OSPF 10.0.0.1/32 preference 100 via Te0/1 (N1) ISIS 10.0.0.1/32 preference 200 via Te0/2 (N2) N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISI= S. N has the following SID mappings: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) So to program the LFIB on N, I will take the ISIS route which is the active= route in the RIB. I will so consider the ISIS SRGB of N but from a conflic= t resolution point of view, I will use the OSPF advertisement (192,10.0.0.1= /32,100,1,0,0) So my LFIB entry will be: Inlabel: 2100, swap 2100 via Te0/2 In addition to that, the draft proposes a lower preference for BGP mappings= , which introduces a hierarchy between protocols like a protocol preference= . [Les:] The reason this was introduced was to provide a preference for SIDs = associated with intra-area prefix advertisements. It recognizes that, withi= n an IGP area, what is likely to be the case is that all SR capable nodes w= ill have IGP advertisements, but BGP is only enabled on a few nodes (the AB= Rs). So the conflict resolution database on all nodes will have the IGP SID= advertisements - but only a few nodes will have the BGP SID advertisements= . By making BGP advertisements least preferred we insure that the nodes run= ning BGP make conflict resolution choices which are consistent with the nod= es which have only the IGP advertisements. Where is the global logic here ? It is really weird to retrieve some SR inf= ormation from one protocol, and some others from another protocol. [Les:] The SR information being advertised is scoped by the node - not by t= he protocol. It is therefore not "weird" to maintain a protocol independent= database but logical to do so. I think this may seem "weird" because you are likely aware that some implem= entations have chosen to use a per protocol configuration model for SRGB an= d prefix SIDs. This is an unfortunate choice in my opinion as it introduces= the possibility for local configuration inconsistency where none was inten= ded. But, as always, the normative behavior defined by the draft is not mea= nt to mandate how an implementation supports the normative behavior. But t= he solution defined in the draft MUST conform to SR architecture. This in = turn may influence implementation strategies i.e. an implementation may mov= e away from per protocol configuration, but that choice is out of scope for= the draft itself. I think we are touching things here that are not clearly defined by the arc= hitecture: the multi protocol behavior has never been clearly described, so= we probably need to think about it and define something before rushing on = the conflict resolution. I see two main approaches: a) We can consider that OSPF-SR extensions and the regular OSPF protoc= ol used for routing as completely separate things (same for IS-IS). So OSPF= -SR extensions are considered as a label distribution protocol like LDP is.= As LDP, it requires some routing informations to be used (that may come fr= om the OSPF routing protocol or even IS-IS). So SR builds a kind of label i= nformation base (LIB) like LDP and then the routing process combines the LI= B info with the active route to build the FIB entry. This approach is simil= ar to what you try to achieve except that I suppose here that all the SR in= formations should come from a single source (so if we pick a binding from O= SPF, we consider to use the OSPF SRGB). Thus as we have multiple sources of= labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, we also need to creat= e a preference mechanism between the protocols here as we do for the routin= g table. In such a scenario, when doing an IGP migration, I need to migrate= the label distribution protocol part and also the routing protocol part po= ssibly in multiple steps (by using preferences on each side). We need to de= fine how we can distribute SR informations from one protocol to the other. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routi= ng comes from the IS-IS active route) b) We can consider another approach where the SR informations are tied= with the routing protocol. When multiple protocols are running, we still n= eed to take care of the conflict resolution between the protocols, but this= may be solved easily by using the existing protocol preference of the RIB = as the first criteria. So a mapping will never be used if it does not corre= spond to an active route from the same protocol. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routi= ng comes from the IS-IS active route). The OSPF mappings for 10.0.0.1/32 ar= e not considered as there is no OSPF active route. [Les:] Solution "a" is closer to what the draft defines than "b". But, as d= etailed above, per protocol SRGB leads to other issues and is inconsistent = w the SR architecture. As far as how to "distribute SR information from one protocol to the other"= , this is already supported by at least some implementations. When routes a= re redistributed between protocols the SIDs from the source protocol are pa= ssed to the destination protocol. This of course does not imply support for per protocol SIDs -which - as det= ailed above - is inconsistent with the SR Architecture. Les The approach b) is more simpler to understand from an operation point of vi= ew (single preference to manage, single source of information) while a) has= some similarities with what we do when using LDP with the complexity of ha= ving multiple label distribution protocols involved. In any case, we need t= o document clearly the approach taken. Brgds, From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, August 01, 2017 18:29 To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; s= pring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Stephane - The draft states (as this thread has discussed): Section 3.7 "In cases where multiple routing protocols are in use mapping entries advertised by all routing protocols MUST be included." In what way is this not clear?? Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 01, 2017 1:28 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_d574c1d1bb104a578462bdb5f78b8416XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Stephane –<= /o:p>

 

I think it is importan= t to look at conflict resolution in the context of the SR architecture. Muc= h of what you discuss below is inconsistent with the SR architecture and as= a result it creates new problems that actually don’t need to be solved.

Let me see if I can ge= t us back on the same page.

 

As previously quoted, =  https://www.ietf= .org/id/draft-ietf-spring-segment-routing-12.txt Section 2: (emphasis added)

 

“SR Global Block (SRGB): = local property of an SR node.  In the MPLS

   architecture, SRGB is the set of local labels reserved= for global

   segments.”

 

From the same draft, S= ection 3 we have other relevant statements:

 

“An IGP-Prefix segment is an IGP segment attached to an IGP p= refix.

   An IGP-Prefix segment is global (unless explicitly adv= ertised

   otherwise) within the SR/IGP domain.”=

 

“In the context of an instance and a topology, multiple Prefi= x-SID's

   MAY be allocated to the same IGP Prefix as long as the= algorithm

   value is different in each one.”

 

There are a number of = conclusions which follow from these statements.

 

1)An SRGB is a node pr= operty, it is NOT a per protocol property

 

2)The SID associated w= ith a prefix is a property of the prefix, not the protocol which advertises= it.

 

3)One – and only= one – SID is associated with a given prefix/algorithm

 

4)The SR architecture = is NOT defining a per protocol forwarding plane – it is defining an S= R forwarding plane

 

If we try to support p= er protocol SRGBs and allow per protocol SID assignments, this leads to a n= umber of problems, some of which you have mentioned in your posts.

By far the biggest iss= ue is that if we allow per protocol SID assignments, then we are actually R= EQUIRED to support non-overlapping per protocol SRGBs, which in turn means = that we are REQUIRED to support multiple incoming labels for the same prefix.

 

This follows because a= node has no way to determine which protocol will provide the winning route= on its neighbors. It would therefore have to program all of the SIDs which= the neighbor might use to forward traffic.

This in turn leads to = the requirement for per protocol non-overlapping SRGBs because if we allow = the same SID to be used for different prefixes so long as the advertising p= rotocols are different, we then have to have a way of mapping that same SID to two different local labels. The = only way to guarantee that is possible is to have per protocol non-overlapp= ing SRGBs.

 

All of this is in conf= lict with the SR architecture as per the excerpts I have quoted above ̵= 1; which is why the conflict resolution drafts specifies<= /p>

 

=B7         one conflict r= esolution database populated by advertisements provided by all protocols/SR= MSs.

=B7         SRGB inconsist= ency detection on a per node basis

 

If there is concern th= at the current language in the draft is not explicit enough, I am happy to = work on adding clarifying language.

But it is crucial to u= nderstand and agree that the choice to use a protocol independent database = and per node SRGB is required by the SR Architecture.

 

A few more comments in= line…

 

 

From: stephane= .litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Wednesday, August 02, 2017 1:09 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

No it’s not, it&= #8217;s definitely not enough precise.

 

Telling that you inclu= de all the entries (from all protocols) in the conflict resolution does not= mean that cross protocol info may be used when programming the FIB. That&#= 8217;s a different story.

 

And speaking as an ope= rator, from a troubleshooting point of view it becomes a nightmare when you= use some information coming from the protocol and some other informations = coming from another source of information.

 

So let’s say tha= t I have two concurrent routes for a prefix on a node N:<= /p>

 

OSPF 10.0.0.1/32 prefe= rence 100 via Te0/1 (N1)

ISIS 10.0.0.1/32 prefe= rence 200 via Te0/2 (N2)

 

N, N1 and N2 advertise= SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.

N has the following SI= D mappings:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

So to program the LFIB= on N, I will take the ISIS route which is the active route in the RIB. I w= ill so consider the ISIS SRGB of N but from a conflict resolution point of = view, I will use the OSPF advertisement (192,10.0.0.1/32,100,1,0,0)

 

So my LFIB entry will = be:

Inlabel: 2= 100, swap 2100 via Te0/2

 = ;

In addition to that, t= he draft proposes a lower preference for BGP mappings, which introduces a h= ierarchy between protocols like a protocol preference.

 

[Les:] The reaso= n this was introduced was to provide a preference for SIDs associated with = intra-area prefix advertisements. It recognizes that, within an IGP area, w= hat is likely to be the case is that all SR capable nodes will have IGP advertisements, but BGP is only enabled= on a few nodes (the ABRs). So the conflict resolution database on all node= s will have the IGP SID advertisements – but only a few nodes will ha= ve the BGP SID advertisements. By making BGP advertisements least preferred we insure that the nodes running BGP ma= ke conflict resolution choices which are consistent with the nodes which ha= ve only the IGP advertisements.

 

Where is the global lo= gic here ? It is really weird to retrieve some SR information from one prot= ocol, and some others from another protocol.

 

[Les:] The SR in= formation being advertised is scoped by the node – not by the protoco= l. It is therefore not “weird” to maintain a protocol independe= nt database but logical to do so.

I think this may= seem “weird” because you are likely aware that some implementa= tions have chosen to use a per protocol configuration model for SRGB and pr= efix SIDs. This is an unfortunate choice in my opinion as it introduces the possibility for local configuration inconsistency whe= re none was intended. But, as always, the normative behavior defined by the= draft is not meant to mandate how an  implementation supports the nor= mative behavior. But the solution defined in the draft  MUST conform to SR architecture. This in turn may influ= ence implementation strategies i.e. an implementation may move away from pe= r protocol configuration, but that choice is out of scope for the draft its= elf.

 

I think we are touchin= g things here that are not clearly defined by the architecture: the multi p= rotocol behavior has never been clearly described, so we probably need to t= hink about it and define something before rushing on the conflict resolution.

 

I see two main approac= hes:

a)&n= bsp;     We can conside= r that OSPF-SR extensions and the regular OSPF protocol used for routing as= completely separate things (same for IS-IS). So OSPF-SR extensions are con= sidered as a label distribution protocol like LDP is. As LDP, it requires some routing informations to be used (tha= t may come from the OSPF routing protocol or even IS-IS). So SR builds a ki= nd of label information base (LIB) like LDP and then the routing process co= mbines the LIB info with the active route to build the FIB entry. This approach is similar to what you try to = achieve except that I suppose here that all the SR informations should come= from a single source (so if we pick a binding from OSPF, we consider to us= e the OSPF SRGB). Thus as we have multiple sources of labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, w= e also need to create a preference mechanism between the protocols here as = we do for the routing table. In such a scenario, when doing an IGP migratio= n, I need to migrate the label distribution protocol part and also the routing protocol part possibly in multiple step= s (by using preferences on each side). We need to define how we can distrib= ute SR informations from one protocol to the other.

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routing comes from t= he IS-IS active route)

 

b)&n= bsp;     We can conside= r another approach where the SR informations are tied with the routing prot= ocol. When multiple protocols are running, we still need to take care of th= e conflict resolution between the protocols, but this may be solved easily by using the existing protocol pr= eference of the RIB as the first criteria. So a mapping will never be used = if it does not correspond to an active route from the same protocol.

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routing comes from t= he IS-IS active route). The OSPF mappings for 10.0.0.1/32 are not considered as there is no OSPF active route.<= /o:p>

 

 

[Les:] Solution = “a” is closer to what the draft defines than “b”. B= ut, as detailed above, per protocol SRGB leads to other issues and is incon= sistent w the SR architecture.

As far as how to= “distribute SR information from one protocol to the other”, th= is is already supported by at least some implementations. When routes are r= edistributed between protocols the SIDs from the source protocol are passed to the destination protocol.<= /i>

This of course d= oes not imply support for per protocol SIDs –which – as detaile= d above – is inconsistent with the SR Architecture.=

 

   Les=

 

The approach b) is mor= e simpler to understand from an operation point of view (single preference = to manage, single source of information) while a) has some similarities wit= h what we do when using LDP with the complexity of having multiple label distribution protocols involved. In an= y case, we need to document clearly the approach taken.

 

 

Brgds,

 

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Tuesday, August 01, 2017 18:29
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha H= egde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Stephane –<= /o:p>

 

The draft states (as t= his thread has discussed):

 

Section 3.7=

 

“In cases where = multiple routing protocols are in use mapping

   &nbs= p;  entries advertised by all routing protocols MUST be included.̶= 1;

 

In what way is this no= t clear??

 

   Les<= /o:p>

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi Les,

 

There is something unc= lear to me here.

Let’s say we hav= e the following entries:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

There is a prefix conf= lict here because we have 4 SIDs for 10.0.0.1/32. The current proposal shou= ld pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest s= tart SID.

Now let’s say th= at the active route in the RIB is an IS-IS route because of local protocol = preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1<= /span>

So do you program the = following FIB entries (consider SRGB start at 16000 for every nodes) :

10.0.0.1/3= 2 via Te0/1 push 16100

Inlabel 16100 via Te0/= 1 swap 16100

 

This means that you de= facto allows cross protocols information use (e.g. ISIS route using an OSPF= mapping). The text is not crystal clear on that point.

 

Or the other possibili= ty is to not use the SID information because it does not comes from the rig= ht protocol. So you only program the FIB but not the LFIB:

10.0.0.1/3= 2 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

 

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution p= er LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.<= /o:p>

 

 

2)      Conflict resolution p= er LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)      Thesis: On the “= ;per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the &#= 8220;across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)     &= nbsp; Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.=

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 =

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 =

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 = 

“I=
n cases where the
&=
nbsp;  information advertised by a given protocol instance is either
&=
nbsp;  internally inconsistent or conflicts with advertisements from a=
nother
&=
nbsp;  protocol instance a means of achieving consistent forwarding be=
havior
&=
nbsp;  in the network is required.”
&=
nbsp;
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
/span>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


 Becomes active entry.<=
/b>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
/span>


Across implementations.=



 

&=
nbsp;


 =



 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees


     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
/span>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing=



   pro=
tocol.  MTID ranges are protocol specific and there may be


   sta=
ndardized protocol specific MTID assignments for topologies of a


   spe=
cific type (e.g., an AFI specific topology).  As mapping entries


   can=
 be sourced from multiple protocols it is not possible to use a


   net=
work scoped identifier for a topology when storing mapping entries<=
o:p>


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.<=
/o:p>


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic=



[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 =



- and even you =
are agreeing that we should not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.<=
o:p>


 =



<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries<=
/o:p>


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 =



 =



Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> 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


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


________________________________________________________________=
_________________________________________________________=

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

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


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


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


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


Thank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des 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.
--_000_d574c1d1bb104a578462bdb5f78b8416XCHALN001ciscocom_-- From nobody Thu Aug 3 06:42:44 2017 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 04E73132059 for ; Thu, 3 Aug 2017 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 wLib-FV0nnI6 for ; Thu, 3 Aug 2017 06:42:37 -0700 (PDT) Received: from relais-inet.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 98407132022 for ; Thu, 3 Aug 2017 06:42:36 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 3D2611001E0; Thu, 3 Aug 2017 15:42:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 10CA4180071; Thu, 3 Aug 2017 15:42:35 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0352.000; Thu, 3 Aug 2017 15:42:31 +0200 From: To: "Les Ginsberg (ginsberg)" , DECRAENE Bruno IMT/OLN , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nunx79fg8SlSEioEavvWIrey6JM9RIAgAZpFYCACngtgIAFnN4AgAUtYwCAAHi2gIAAxDgAgAV+hMCAAGdIgIABHD6QgACRS4CAAWbNsA== Date: Thu, 3 Aug 2017 13:42:30 +0000 Message-ID: <29113_1501767755_5983284B_29113_343_1_97a1a4e3-ec9e-484f-8b5d-4b8e70962e06@OPEXCLILM31.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> <30110_1501576113_59803BB1_30110_340_1_8ad8b432-cadb-4204-8c98-a784fd04d970@OPEXCLILM6F.corporate.adroot.infra.ftgroup> <31728_1501661327_5981888F_31728_392_1_57a14f82-f54c-4ea5-9202-35469a86da12@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_97a1a4e3ec9e484f8b5d4b8e70962e06OPEXCLILM31corporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:42:43 -0000 --_000_97a1a4e3ec9e484f8b5d4b8e70962e06OPEXCLILM31corporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, I think there is a fundamental disagreement here. "SR Global Block (SRGB): local property of an SR node. In the MPLS architecture, SRGB is the set of local labels reserved for global segments." We agree that the SRGB is a per node property, but a per node+per protocol = SRGB is still compliant with this and there was a consensus on the list to = let implementations having a per protocol SRGB configuration on each node (= this was reflected in the YANG model). "An IGP-Prefix segment is an IGP segment attached to an IGP prefix. An IGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR/IGP domain." This statement clearly mentions the IGP domain as the boundary... "In the context of an instance and a topology, multiple Prefix-SID's MAY be allocated to the same IGP Prefix as long as the algorithm value is different in each one." This also mentions that the statement is limited to a particular IGP instan= ce and topology and does not imply anything for cross instances... Honestly when the architecture document was written, it was with only a sin= gle IGP instance/domain in mind... Brgds, From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, August 02, 2017 20:06 To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; s= pring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Stephane - I think it is important to look at conflict resolution in the context of th= e SR architecture. Much of what you discuss below is inconsistent with the = SR architecture and as a result it creates new problems that actually don't= need to be solved. Let me see if I can get us back on the same page. As previously quoted, https://www.ietf.org/id/draft-ietf-spring-segment-ro= uting-12.txt Section 2: (emphasis added) "SR Global Block (SRGB): local property of an SR node. In the MPLS architecture, SRGB is the set of local labels reserved for global segments." >From the same draft, Section 3 we have other relevant statements: "An IGP-Prefix segment is an IGP segment attached to an IGP prefix. An IGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR/IGP domain." "In the context of an instance and a topology, multiple Prefix-SID's MAY be allocated to the same IGP Prefix as long as the algorithm value is different in each one." There are a number of conclusions which follow from these statements. 1)An SRGB is a node property, it is NOT a per protocol property 2)The SID associated with a prefix is a property of the prefix, not the pro= tocol which advertises it. 3)One - and only one - SID is associated with a given prefix/algorithm 4)The SR architecture is NOT defining a per protocol forwarding plane - it = is defining an SR forwarding plane If we try to support per protocol SRGBs and allow per protocol SID assignme= nts, this leads to a number of problems, some of which you have mentioned i= n your posts. By far the biggest issue is that if we allow per protocol SID assignments, = then we are actually REQUIRED to support non-overlapping per protocol SRGBs= , which in turn means that we are REQUIRED to support multiple incoming lab= els for the same prefix. This follows because a node has no way to determine which protocol will pro= vide the winning route on its neighbors. It would therefore have to program= all of the SIDs which the neighbor might use to forward traffic. This in turn leads to the requirement for per protocol non-overlapping SRGB= s because if we allow the same SID to be used for different prefixes so lon= g as the advertising protocols are different, we then have to have a way of= mapping that same SID to two different local labels. The only way to guara= ntee that is possible is to have per protocol non-overlapping SRGBs. All of this is in conflict with the SR architecture as per the excerpts I h= ave quoted above - which is why the conflict resolution drafts specifies =B7 one conflict resolution database populated by advertisements pr= ovided by all protocols/SRMSs. =B7 SRGB inconsistency detection on a per node basis If there is concern that the current language in the draft is not explicit = enough, I am happy to work on adding clarifying language. But it is crucial to understand and agree that the choice to use a protocol= independent database and per node SRGB is required by the SR Architecture. A few more comments inline... From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Wednesday, August 02, 2017 1:09 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution No it's not, it's definitely not enough precise. Telling that you include all the entries (from all protocols) in the confli= ct resolution does not mean that cross protocol info may be used when progr= amming the FIB. That's a different story. And speaking as an operator, from a troubleshooting point of view it become= s a nightmare when you use some information coming from the protocol and so= me other informations coming from another source of information. So let's say that I have two concurrent routes for a prefix on a node N: OSPF 10.0.0.1/32 preference 100 via Te0/1 (N1) ISIS 10.0.0.1/32 preference 200 via Te0/2 (N2) N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISI= S. N has the following SID mappings: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) So to program the LFIB on N, I will take the ISIS route which is the active= route in the RIB. I will so consider the ISIS SRGB of N but from a conflic= t resolution point of view, I will use the OSPF advertisement (192,10.0.0.1= /32,100,1,0,0) So my LFIB entry will be: Inlabel: 2100, swap 2100 via Te0/2 In addition to that, the draft proposes a lower preference for BGP mappings= , which introduces a hierarchy between protocols like a protocol preference. [Les:] The reason this was introduced was to provide a preference for SIDs = associated with intra-area prefix advertisements. It recognizes that, withi= n an IGP area, what is likely to be the case is that all SR capable nodes w= ill have IGP advertisements, but BGP is only enabled on a few nodes (the AB= Rs). So the conflict resolution database on all nodes will have the IGP SID= advertisements - but only a few nodes will have the BGP SID advertisements= . By making BGP advertisements least preferred we insure that the nodes run= ning BGP make conflict resolution choices which are consistent with the nod= es which have only the IGP advertisements. Where is the global logic here ? It is really weird to retrieve some SR inf= ormation from one protocol, and some others from another protocol. [Les:] The SR information being advertised is scoped by the node - not by t= he protocol. It is therefore not "weird" to maintain a protocol independent= database but logical to do so. I think this may seem "weird" because you are likely aware that some implem= entations have chosen to use a per protocol configuration model for SRGB an= d prefix SIDs. This is an unfortunate choice in my opinion as it introduces= the possibility for local configuration inconsistency where none was inten= ded. But, as always, the normative behavior defined by the draft is not mea= nt to mandate how an implementation supports the normative behavior. But t= he solution defined in the draft MUST conform to SR architecture. This in = turn may influence implementation strategies i.e. an implementation may mov= e away from per protocol configuration, but that choice is out of scope for= the draft itself. I think we are touching things here that are not clearly defined by the arc= hitecture: the multi protocol behavior has never been clearly described, so= we probably need to think about it and define something before rushing on = the conflict resolution. I see two main approaches: a) We can consider that OSPF-SR extensions and the regular OSPF protoc= ol used for routing as completely separate things (same for IS-IS). So OSPF= -SR extensions are considered as a label distribution protocol like LDP is.= As LDP, it requires some routing informations to be used (that may come fr= om the OSPF routing protocol or even IS-IS). So SR builds a kind of label i= nformation base (LIB) like LDP and then the routing process combines the LI= B info with the active route to build the FIB entry. This approach is simil= ar to what you try to achieve except that I suppose here that all the SR in= formations should come from a single source (so if we pick a binding from O= SPF, we consider to use the OSPF SRGB). Thus as we have multiple sources of= labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, we also need to creat= e a preference mechanism between the protocols here as we do for the routin= g table. In such a scenario, when doing an IGP migration, I need to migrate= the label distribution protocol part and also the routing protocol part po= ssibly in multiple steps (by using preferences on each side). We need to de= fine how we can distribute SR informations from one protocol to the other. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routi= ng comes from the IS-IS active route) b) We can consider another approach where the SR informations are tied= with the routing protocol. When multiple protocols are running, we still n= eed to take care of the conflict resolution between the protocols, but this= may be solved easily by using the existing protocol preference of the RIB = as the first criteria. So a mapping will never be used if it does not corre= spond to an active route from the same protocol. In this approach, using the example above, we should program this entry in = the LFIB: Inlabel 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routi= ng comes from the IS-IS active route). The OSPF mappings for 10.0.0.1/32 ar= e not considered as there is no OSPF active route. [Les:] Solution "a" is closer to what the draft defines than "b". But, as d= etailed above, per protocol SRGB leads to other issues and is inconsistent = w the SR architecture. As far as how to "distribute SR information from one protocol to the other"= , this is already supported by at least some implementations. When routes a= re redistributed between protocols the SIDs from the source protocol are pa= ssed to the destination protocol. This of course does not imply support for per protocol SIDs -which - as det= ailed above - is inconsistent with the SR Architecture. Les The approach b) is more simpler to understand from an operation point of vi= ew (single preference to manage, single source of information) while a) has= some similarities with what we do when using LDP with the complexity of ha= ving multiple label distribution protocols involved. In any case, we need t= o document clearly the approach taken. Brgds, From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, August 01, 2017 18:29 To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; s= pring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Stephane - The draft states (as this thread has discussed): Section 3.7 "In cases where multiple routing protocols are in use mapping entries advertised by all routing protocols MUST be included." In what way is this not clear?? Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 01, 2017 1:28 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring= @ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Hi Les, There is something unclear to me here. Let's say we have the following entries: OSPF mappings: (192,10.0.0.1/32,100,1,0,0) (128,10.0.0.1/32,200,300,0,0) ISIS mappings: (192,10.0.0.1/32,300,1,0,0) (128,10.0.0.1/32,400,300,0,0) There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The= current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF= because of smallest start SID. Now let's say that the active route in the RIB is an IS-IS route because of= local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.= 42.42 via Te0/1 So do you program the following FIB entries (consider SRGB start at 16000 f= or every nodes) : 10.0.0.1/32 via Te0/1 push 16100 Inlabel 16100 via Te0/1 swap 16100 This means that you defacto allows cross protocols information use (e.g. IS= IS route using an OSPF mapping). The text is not crystal clear on that poin= t. Or the other possibility is to not use the SID information because it does = not comes from the right protocol. So you only program the FIB but not the = LFIB: 10.0.0.1/32 via Te0/1. Could you clarify ? Thanks, From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, July 29, 2017 00:25 To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network. Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network. In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement. [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_97a1a4e3ec9e484f8b5d4b8e70962e06OPEXCLILM31corporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

I think there is a fun= damental disagreement here.

“SR Global Block (SRGB): = local property of an SR node.  In the MPLS

   architecture, SRGB is the set of local labels reserved= for global

   segments.”

 

We agree that the SRGB= is a per node property, but a per node+per protocol SRGB is still comp= liant with this and there was a consensus on the list to let implementation= s having a per protocol SRGB configuration on each node (this was reflected in the YANG model).

 

“An IGP-Prefix segment is an IGP segment attached to an IGP p= refix.

   An IGP-Prefix segment is global (unless explicitly adv= ertised

   otherwise) within the SR/IGP domain.”=

 

This statement clearly= mentions the IGP domain as the boundary…

 

“In the context of an instance and a topology, multiple Prefi= x-SID's

   MAY be allocated to the same IGP Prefix as long as the= algorithm

   value is different in each one.”

 

This also mentions tha= t the statement is limited to a particular IGP instance and topology and do= es not imply anything for cross instances…

 

Honestly when the arch= itecture document was written, it was with only a single IGP instance/domai= n in mind…

 

 

Brgds,

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, August 02, 2017 20:06
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha H= egde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Stephane –<= /o:p>

 

I think it is importan= t to look at conflict resolution in the context of the SR architecture. Muc= h of what you discuss below is inconsistent with the SR architecture and as= a result it creates new problems that actually don’t need to be solved.

Let me see if I can ge= t us back on the same page.

 

As previously quoted, =  https://www.ietf.org/id/draft-ietf-spring-segment-rou= ting-12.txt Section 2: (emphasis added)

 

“SR Global Block (SRGB): = local property of an SR node.  In the MPLS

   architecture, SRGB is the set of local labels reserved= for global

   segments.”

 

From the same draft, S= ection 3 we have other relevant statements:

 

“An IGP-Prefix segment is an IGP segment attached to an IGP p= refix.

   An IGP-Prefix segment is global (unless explicitly adv= ertised

   otherwise) within the SR/IGP domain.”=

 

“In the context of an instance and a topology, multiple Prefi= x-SID's

   MAY be allocated to the same IGP Prefix as long as the= algorithm

   value is different in each one.”

 

There are a number of = conclusions which follow from these statements.

 

1)An SRGB is a node pr= operty, it is NOT a per protocol property

 

2)The SID associated w= ith a prefix is a property of the prefix, not the protocol which advertises= it.

 

3)One – and only= one – SID is associated with a given prefix/algorithm

 

4)The SR architecture = is NOT defining a per protocol forwarding plane – it is defining an S= R forwarding plane

 

If we try to support p= er protocol SRGBs and allow per protocol SID assignments, this leads to a n= umber of problems, some of which you have mentioned in your posts.

By far the biggest iss= ue is that if we allow per protocol SID assignments, then we are actually R= EQUIRED to support non-overlapping per protocol SRGBs, which in turn means = that we are REQUIRED to support multiple incoming labels for the same prefix.

 

This follows because a= node has no way to determine which protocol will provide the winning route= on its neighbors. It would therefore have to program all of the SIDs which= the neighbor might use to forward traffic.

This in turn leads to = the requirement for per protocol non-overlapping SRGBs because if we allow = the same SID to be used for different prefixes so long as the advertising p= rotocols are different, we then have to have a way of mapping that same SID to two different local labels. The = only way to guarantee that is possible is to have per protocol non-overlapp= ing SRGBs.

 

All of this is in conf= lict with the SR architecture as per the excerpts I have quoted above ̵= 1; which is why the conflict resolution drafts specifies<= /p>

 

=B7         one conflict r= esolution database populated by advertisements provided by all protocols/SR= MSs.

=B7         SRGB inconsist= ency detection on a per node basis

 

If there is concern th= at the current language in the draft is not explicit enough, I am happy to = work on adding clarifying language.

But it is crucial to u= nderstand and agree that the choice to use a protocol independent database = and per node SRGB is required by the SR Architecture.

 

A few more comments in= line…

 

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Wednesday, August 02, 2017 1:09 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

No it’s not, it&= #8217;s definitely not enough precise.

 

Telling that you inclu= de all the entries (from all protocols) in the conflict resolution does not= mean that cross protocol info may be used when programming the FIB. That&#= 8217;s a different story.

 

And speaking as an ope= rator, from a troubleshooting point of view it becomes a nightmare when you= use some information coming from the protocol and some other informations = coming from another source of information.

 

So let’s say tha= t I have two concurrent routes for a prefix on a node N:<= /p>

 

OSPF 10.0.0.1/32 prefe= rence 100 via Te0/1 (N1)

ISIS 10.0.0.1/32 prefe= rence 200 via Te0/2 (N2)

 

N, N1 and N2 advertise= SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.

N has the following SI= D mappings:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

So to program the LFIB= on N, I will take the ISIS route which is the active route in the RIB. I w= ill so consider the ISIS SRGB of N but from a conflict resolution point of = view, I will use the OSPF advertisement (192,10.0.0.1/32,100,1,0,0)

 

So my LFIB entry will = be:

Inlabel: 2= 100, swap 2100 via Te0/2

 = ;

In addition to that, t= he draft proposes a lower preference for BGP mappings, which introduces a h= ierarchy between protocols like a protocol preference.

 

[Les:] The reaso= n this was introduced was to provide a preference for SIDs associated with = intra-area prefix advertisements. It recognizes that, within an IGP area, w= hat is likely to be the case is that all SR capable nodes will have IGP advertisements, but BGP is only enabled= on a few nodes (the ABRs). So the conflict resolution database on all node= s will have the IGP SID advertisements – but only a few nodes will ha= ve the BGP SID advertisements. By making BGP advertisements least preferred we insure that the nodes running BGP ma= ke conflict resolution choices which are consistent with the nodes which ha= ve only the IGP advertisements.

 

Where is the global lo= gic here ? It is really weird to retrieve some SR information from one prot= ocol, and some others from another protocol.

 

[Les:] The SR in= formation being advertised is scoped by the node – not by the protoco= l. It is therefore not “weird” to maintain a protocol independe= nt database but logical to do so.

I think this may= seem “weird” because you are likely aware that some implementa= tions have chosen to use a per protocol configuration model for SRGB and pr= efix SIDs. This is an unfortunate choice in my opinion as it introduces the possibility for local configuration inconsistency whe= re none was intended. But, as always, the normative behavior defined by the= draft is not meant to mandate how an  implementation supports the nor= mative behavior. But the solution defined in the draft  MUST conform to SR architecture. This in turn may influ= ence implementation strategies i.e. an implementation may move away from pe= r protocol configuration, but that choice is out of scope for the draft its= elf.

 

I think we are touchin= g things here that are not clearly defined by the architecture: the multi p= rotocol behavior has never been clearly described, so we probably need to t= hink about it and define something before rushing on the conflict resolution.

 

I see two main approac= hes:

a)&n= bsp;     We can conside= r that OSPF-SR extensions and the regular OSPF protocol used for routing as= completely separate things (same for IS-IS). So OSPF-SR extensions are con= sidered as a label distribution protocol like LDP is. As LDP, it requires some routing informations to be used (tha= t may come from the OSPF routing protocol or even IS-IS). So SR builds a ki= nd of label information base (LIB) like LDP and then the routing process co= mbines the LIB info with the active route to build the FIB entry. This approach is similar to what you try to = achieve except that I suppose here that all the SR informations should come= from a single source (so if we pick a binding from OSPF, we consider to us= e the OSPF SRGB). Thus as we have multiple sources of labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, w= e also need to create a preference mechanism between the protocols here as = we do for the routing table. In such a scenario, when doing an IGP migratio= n, I need to migrate the label distribution protocol part and also the routing protocol part possibly in multiple step= s (by using preferences on each side). We need to define how we can distrib= ute SR informations from one protocol to the other.

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routing comes from t= he IS-IS active route)

 

b)&n= bsp;     We can conside= r another approach where the SR informations are tied with the routing prot= ocol. When multiple protocols are running, we still need to take care of th= e conflict resolution between the protocols, but this may be solved easily by using the existing protocol pr= eference of the RIB as the first criteria. So a mapping will never be used = if it does not correspond to an active route from the same protocol.

 

In this approac= h, using the example above, we should program this entry in the LFIB: Inlab= el 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routing comes from t= he IS-IS active route). The OSPF mappings for 10.0.0.1/32 are not considered as there is no OSPF active route.<= /o:p>

 

 

[Les:] Solution = “a” is closer to what the draft defines than “b”. B= ut, as detailed above, per protocol SRGB leads to other issues and is incon= sistent w the SR architecture.

As far as how to= “distribute SR information from one protocol to the other”, th= is is already supported by at least some implementations. When routes are r= edistributed between protocols the SIDs from the source protocol are passed to the destination protocol.<= /i>

This of course d= oes not imply support for per protocol SIDs –which – as detaile= d above – is inconsistent with the SR Architecture.=

 

   Les=

 

The approach b) is mor= e simpler to understand from an operation point of view (single preference = to manage, single source of information) while a) has some similarities wit= h what we do when using LDP with the complexity of having multiple label distribution protocols involved. In an= y case, we need to document clearly the approach taken.

 

 

Brgds,

 

 

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Tuesday, August 01, 2017 18:29
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha H= egde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Stephane –<= /o:p>

 

The draft states (as t= his thread has discussed):

 

Section 3.7=

 

“In cases where = multiple routing protocols are in use mapping

   &nbs= p;  entries advertised by all routing protocols MUST be included.̶= 1;

 

In what way is this no= t clear??

 

   Les<= /o:p>

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde;= spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Hi Les,

 

There is something unc= lear to me here.

Let’s say we hav= e the following entries:

OSPF mappings:<= o:p>

(192,10.0.0.1/32,100,1= ,0,0)

(128,10.0.0.1/32,200,3= 00,0,0)

 

ISIS mappings:<= o:p>

(192,10.0.0.1/32,300,1= ,0,0)

(128,10.0.0.1/32,400,3= 00,0,0)

 

 

There is a prefix conf= lict here because we have 4 SIDs for 10.0.0.1/32. The current proposal shou= ld pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest s= tart SID.

Now let’s say th= at the active route in the RIB is an IS-IS route because of local protocol = preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1<= /span>

So do you program the = following FIB entries (consider SRGB start at 16000 for every nodes) :

10.0.0.1/3= 2 via Te0/1 push 16100

Inlabel 16100 via Te0/= 1 swap 16100

 

This means that you de= facto allows cross protocols information use (e.g. ISIS route using an OSPF= mapping). The text is not crystal clear on that point.

 

Or the other possibili= ty is to not use the SID information because it does not comes from the rig= ht protocol. So you only program the FIB but not the LFIB:

10.0.0.1/3= 2 via Te0/1.

 

Could you clarify ?

 

 

Thanks,

 

 

 

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)      Conflict resolution p= er LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.<= /o:p>

 

 

2)      Conflict resolution p= er LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)      Thesis: On the “= ;per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)      Antithesis: On the &#= 8220;across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)     &= nbsp; Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.=

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 =

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 =

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 = 

“In cases where the
   information advertised by a given protocol in=
stance is either
   internally inconsistent or conflicts with adv=
ertisements from another
   protocol instance a means of achieving consis=
tent forwarding behavior
   in the network is required.”
 
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
/span>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
/span>


 Becomes active entry.<=
/b>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
/span>


Across implementations.=



 

 


 =



 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees


     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
/span>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each


   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing=



   pro=
tocol.  MTID ranges are protocol specific and there may be


   sta=
ndardized protocol specific MTID assignments for topologies of a


   spe=
cific type (e.g., an AFI specific topology).  As mapping entries


   can=
 be sourced from multiple protocols it is not possible to use a


   net=
work scoped identifier for a topology when storing mapping entries<=
o:p>


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.


> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.<=
/o:p>


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic=



[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 =



- and even you =
are agreeing that we should not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.<=
o:p>


 =



<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries<=
/o:p>


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 =



 =



Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> 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


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;<=
o:p>
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_97a1a4e3ec9e484f8b5d4b8e70962e06OPEXCLILM31corporateadr_-- From nobody Wed Aug 9 20:52:56 2017 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 C3E9A1323BE for ; Wed, 9 Aug 2017 20:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 warwsOe0DVPR for ; Wed, 9 Aug 2017 20:52:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B771131D25 for ; Wed, 9 Aug 2017 20:52:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMH58995; Thu, 10 Aug 2017 03:52:46 +0000 (GMT) Received: from DGGEMI405-HUB.china.huawei.com (10.3.17.143) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 10 Aug 2017 04:52:45 +0100 Received: from DGGEMI502-MBX.china.huawei.com ([169.254.4.150]) by dggemi405-hub.china.huawei.com ([10.3.17.143]) with mapi id 14.03.0301.000; Thu, 10 Aug 2017 11:52:35 +0800 From: "Chengli (Distance)" To: Pushpasis Sarkar CC: "draft-ietf-spring-anycast-segment@ietf.org" , "spring@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0?= =?utf-8?Q?-specific_label_spaces?= Thread-Index: AdMAXJkJ1clImMhlSCmQwtRBBfPkPwAcdcyABAO96EAAAPCngAAAFegAACfggdA= Date: Thu, 10 Aug 2017 03:52:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CDE9dggemi502mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.598BD88F.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.150, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fb9f917d25c99606d0ebc1f6659cbdc5 Archived-At: Subject: [spring] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBBbnljYXN0IHNlZ21lbnRz?= =?utf-8?q?_and_context-specific_label_spaces?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 03:52:54 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CDE9dggemi502mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgIFB1c2hwYXNpcywNCg0KV293LCBpdCBoYXMgYmVlbiB0d28geWVhcnMgc2luY2UgeW91IG1h ZGUgdGhlIHByZXNlbnRhdGlvbi4gIFRoYW5rIHlvdSBmb3IgeW91ciBzbGlkZXMuIEkgaGF2ZSBy ZWFkIGl0IGFsbC4NCg0KQnV0IEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9ucy4gUGxlYXNlIGZp bmQgdGhlbSBpbmxpbmUuDQoNCg0K5Y+R5Lu25Lq6OiBQdXNocGFzaXMgU2Fya2FyIFttYWlsdG86 cHVzaHBhc2lzLmlldGZAZ21haWwuY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDnml6Ug MjM6MzENCuaUtuS7tuS6ujogQ2hlbmdsaSAoRGlzdGFuY2UpIDxjaGVuZ2xpMTNAaHVhd2VpLmNv bT4NCuS4u+mimDogUmU6IOetlOWkjTogW3NwcmluZ10gQW55Y2FzdCBzZWdtZW50cyBhbmQgY29u dGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXMNCg0KSG9wZSB5b3UgaGF2ZSBhbHJlYWR5IGdvbmUg dGhyb3VnaCBteSBwcmVzZW50YXRpb24gcHJlc2VudGVkIHdheSBiYWNrIGluIDIwMTUuLiBJZiBu b3QgaGVyZSBpcyB0aGUgbGluayB0byB0aGUgc2FtZS4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1zcHJpbmctMS5wZGYNCg0KT24gV2VkLCBB dWcgOSwgMjAxNyBhdCA4OjU4IFBNLCBQdXNocGFzaXMgU2Fya2FyIDxwdXNocGFzaXMuaWV0ZkBn bWFpbC5jb208bWFpbHRvOnB1c2hwYXNpcy5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgQ2hl bmdsaSwNCg0KVGhhbmtzIGEgbG90IGZvciB0YWtpbmcgdGltZSB0byByZWFkIHRoZSBkcmFmdCBh bmQgcHJvdmlkZSBjb21tZW50cy4gUGxlYXNlIGZpbmQgYW5zd2VycyBpbmxpbmUNCg0KT24gV2Vk LCBBdWcgOSwgMjAxNyBhdCAyOjA0IFBNLCBDaGVuZ2xpIChEaXN0YW5jZSkgPGNoZW5nbGkxM0Bo dWF3ZWkuY29tPG1haWx0bzpjaGVuZ2xpMTNAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgUHVzaHBh c2lzLA0KSSBhbSBhIG5ldyBsZWFybmVyIG9mIFNSLiBSZWNlbnRseSwgSSByZWFkIHRoZSBkcmFm dDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctbXBscy1hbnlj YXN0LXNlZ21lbnRzLTAxPiwgYW5kIEkgaGFhIHNvbWUgcXVlc3Rpb25zIGFib3V0IGl0LiBTb21l IG9mIHRoZW0gYXJlIGFib3V0IHRoZSBhbGdvcml0aG0sIHdoaWxlIHRoZSBvdGhlcnMgYXJlIGFi b3V0IHRoZSBjb250ZXh0Lg0KDQoxOiBJZiBDQS1TUkdCIG5lZWQgdG8gYmUgY29uZmlndXJlZCB0 aGUgc2FtZSBhbW9uZyBhbGwgbm9kZXMsIHdoaWNoIG1lYW5zIGFsbCBub2RlcyBjYW4gdW5kZXJz dGFuZCB0aGUgbGFiZWwgaW4gQ0EtU1JHQi4gSWYgc28sIHdoeSBkbyB3ZSBuZWVkIHRvIHNldCBQ LUZsYWcgd2hlbiB0aGUgbm9kZSBoYXMgYSBkaWZmZXJlbnQgQ0EtU1JHQiByYW5nZSB3aXRoIFNS R0IuIFdpdGhvdXQgdGhlIEFueWNhc3QtU0lELCB0aGUgbm9kZSBjYW4gdW5kZXJzdGFuZCBDQS1T UkdCIGFuZCBwcm9jZXNzIENBUFNMIGFzIHdlbGwuICBXaHkgZG8gd2UgbmVlZCB0byBrZWVwIEFu eWNhc3QgbGFiZWw/IFRvIGluZGVudGlmeSB0aGUgbmV4dCBsYWJlbCBpcyBhIENQQVNMPw0KW1B1 c2hwYXNpc10gWWVzIHRoaXMgaXMgbmVlZGVkIGZvciB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0ZWQg dGhlIENBUFNMLiBJbiBjYXNlIHRoZSBDQS1TUkdCIGlzIGRpZmZlcmVudCBmcm9tIHJlZ3VsYXIg U1JHQiB0aGUgcGFja2V0IG11c3QgY29tZSBpbiB3aXRoIHRoZSBDQVBTTCBhdCB0aGUgdG9wIG9m IHRoZSBzdGFjayBzbyB0aGF0IGl0IHBvcHMgYW5kIGRvZXMgYSByZWN1cnNpdmUgbGFiZWwgbG9v a3VwIHdpdGggdGhlIG5leHQgbGFiZWwgaW4gc3RhY2suLg0KDQpbQ2hlbmddIElmIHRoZXJlIGlz IGFuIGFjdGlvbiBzdXBwb3J0aW5nIHRvIGxvb2sgdXAgaW4gVi1MRklCLCB3aHkgbm90IHVzZSBD QVBTTCBhcyB0aGUga2V5IGluIERlZmF1bHQgTEZJQiBkaXJlY3RseT8gIElmIHNvLCBQLUZsYWcg Y2FuIGJlIGxlYXZlZCAwLCBhbmQgbm9kZSB3aWxsIHJlY2VpdmUgYSBwYWNrZXQgd2l0aCB0aGUg Q0FQU0wgYXMgdGhlIHRvcCBsYWJlbCBubyBtYXR0ZXIgaXTigJlzIENBLVNSR0IgaXMgdGhlIHNh bWUgYXMgU1JHQiBvciBub3QuIEluIGRlZmF1bHQgTEZJQiwgdGhlcmUgc2hvdWxkIGJlIGFuIGVu dHJ5IGZvciBDQVBTTCwgYW5kIGl04oCZcyBhY3Rpb24gaXMgdG8gbG9vayB1cCBDQVBTTCBpbiBW LUxGSUIuIEkgYW0gbm90IHN1cmUgdGhhdCB3aGV0aGVyIGl0IGNhbiB3b3JrIG9yIG5vdC4NCg0K SW4gdGhpcyB3YXksIGNvbmZpZ3VyYXRpb24gd2lsbCBiZSBtdWNoIGVhc2llci4NCg0KSW4gc3Vt bWFyeSwgaW4gbXkgUE9WLCB3ZSBjYW4gcG9wIHRoZSBwcmV2aW91cyBhbnljYXN0IGxhYmVsIHNv IHRoYXQgdGhlIG5vZGUgY2FuIHJlY2VpdmUgdGhlIHNhbWUgcGFja2V0IG5vIG1hdHRlciBpdOKA mXMgQ0EtU1JHQiBpcyB0aGUgc2FtZSBhcyBTUkdCIG9yIG5vdC4gQnV0IEkgc3VwcG9zZSB0aGF0 ICB0aGVyZSBtdXN0IGJlIHNvbWUgcmVhc29ucyB0aGF0IHlvdSBkaWRu4oCZdCAgcHJvcG9zZSBh IHNvbHV0aW9uIGxpa2UgdGhpcy4gSWYgcG9zc2libGUsIGNhbiB5b3UgYmUga2luZCB0byB0ZWxs IG1lID8NCg0KSSB0aGluayB0aGUgcmVhc29uIG1heWJlOg0KDQpLZWVwaW5nIHRoZSBhbnljYXN0 IGxhYmVsIGNhbiByZWR1Y2UgdGhlIGVudHJpZXMgb2YgTEZJQi4gIElmIHdlIHVzZSBDQVBTTCBh cyB0aGUgdG9wIGxhYmVsLCB3ZSBuZWVkIHRvIGluc3RhbGwgZW50cmllcyBmb3IgYWxsIENBUFNM cyBpbiBMRklCIGFuZCBpbiBWLUxGSUIgYXMgd2VsbC4gQnV0IGlmIHdlIGtlZXAgQW55Y2FzdCBs YWJlbCBhcyB0aGUgdG9wIGxhYmVsLCAgd2Ugb25seSBuZWVkIHRvIGluc3RhbGwgb25lIGVudHJ5 IGZvciBBbnljYXN0IGxhYmVsLCBhbmQgb25lIGVudHJ5IGZvciBlYWNoIENBUFNMIGluIFYtTEZJ Qi4NCg0KDQoyOiBJbiBzZWN0aW9uIDMuMi4yIG9mIHlvdXIgZHJhZnQsIGl0IHNheXMgdGhhdA0K VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgc2VwYXJhdGUgdmlydHVhbCBsYWJlbCBsb29rdXAg dGFibGUNCiAgIChoZXJlYWZ0ZXIgcmVmZXJyZWQgdG8gYXMgVmlydHVhbCBMRklCIG9yIFYtTEZJ QiksIHRoYXQgcmVwcmVzZW50cyBhDQogICBsYWJlbCBzcGFjZSB3aGljaCBpcyBhbHNvIHNlcGFy YXRlIGZyb20gdGhlIGFjdHVhbCBsYWJlbCBzcGFjZQ0KICAgcmVwcmVzZW50ZWQgYnkgdGhlIGRl ZmF1bHQgTEZJQi4gIFRoZSBsYWJlbCB2YWx1ZSBtYXkgYmUgcHJlc2VudCBpbg0KICAgYm90aCB0 aGUgZGVmYXVsdCBhbmQgVmlydHVhbCBMRklCLg0KDQpJZiBWLUxGSUIgcmVwcmVzZW50cyBhIGxh YmVsIHNwYWNlIHNlcGFyYXRlZCBmcm9tIHRoZSBsYWJlbCBzcGFjZSByZXByZXNlbnRlZCBieSBM RklCLCB3aHkgbGFiZWwgdmFsdWUgbWF5IGJlIHByZXNlbnQgaW4gYm90aCBvZiB0aGVtPyAgSWYg dGhpcyBpcyByaWdodCwgSSBzdXBwb3NlIHRoYXQgdGhlIHJlYXNvbiBvZiBrZWVwaW5nIGFueWNh c3QgbGFiZWwgaXMgdG8gaWRlbnRpZnkgdGhlIG5leHQgbGFiZWwgc2hvdWxkIGJlIGxvb2tlZCB1 cCBpbiBWLUxGSUIgaW5zdGVhZCBvZiBkZWZhdWx0IG9uZS4NCltQdXNocGFzaXNdIFRoZW9yZXRp Y2FsbHkgYWxsIGxhYmVsLXNwYWNlcyBjYW4gYmUgaW5kZXBlbmRlbnQgYW5kIG1heSBoYXZlIHRo ZSBzYW1lIGxhYmVsIHByb2dyYW1tZWQgaW4gdGhlbSB3aXRoIGRpZmZlcmVudCBmb3J3YXJkaW5n IHNlbWFudGljcy4gSG93ZXZlciBmcm9tIHRoZSBmb2xsb3dpbmcgdGV4dCB3ZSBwcm9wb3NlZCBh IHNlcGFyYXRlIFYtTEZJQiBpZiBhbmQgb25seSBpZiBDQS1TUkdCIGlzIGRpZmZlcmVudCBmcm9t IFNSR0IuLg0KDQpbQ2hlbmddIEkgYW0gd29uZGVyaW5nIHRoYXQgd2hhdCBpcyB0aGUgbGFiZWwt c3BhY2U/IEkgdGhpbmsgaXQgaXMgdGhlIHJhbmdlIG9mIGxhYmVsLiBCdXQgaXQgc2VlbXMgbm90 Lg0KDQoNCiIgU3VjaCBhIGRldmljZSBNVVNUIGFkZCBhbiBlbnRyeSBpbiB0aGUgVmlydHVhbCBM RklCIGZvciBlYWNoIHVuaWNhc3QNCg0KICAgYW5kIGFueWNhc3QgcHJlZml4IHNlZ21lbnRzIGxl YXJudCBmcm9tIGEgcmVtb3RlIGRldmljZSwgaWYgYW5kIG9ubHkNCg0KICAgaWYgdGhlIHNhbWUg cHJlZml4IGhhcyBub3QgYmVlbiBwcm92aXNpb25lZCBvbiB0aGUgZGV2aWNlLiAgVGhlDQoNCiAg IGRldmljZSBTSE9VTEQgTk9UIGFkZCBhbiBlbnRyeSBmb3IgYW55IG9mIHRoZSBBbnljYXN0IG9y IE5vZGUgcHJlZml4DQoNCiAgIHNlZ21lbnRzIHRoYXQgaXQgaGFzIGFkdmVydGlzZWQgaXRzZWxm LiAgSG93ZXZlciBpZiB0aGUgZGV2aWNlIGhhcw0KDQogICBsZWFybnQgYW55IGFueWNhc3QgcHJl Zml4IHNlZ21lbnQgZnJvbSBhIHJlbW90ZSBkZXZpY2UsIGFuZCB0aGUgc2FtZQ0KDQogICBpcyBu b3QgcHJvdmlzaW9uZWQgb24gdGhpcyBkZXZpY2UsIHRoZSBkZXZpY2UgTVVTVCBpbmNsdWRlIHRo ZSBzYW1lDQoNCiAgIGluIHRoZSBWaXJ0dWFsIExGSUIgdGFibGUuDQoiDQoNCltQdXNocGFzaXNd IElmIHRoZSBsYWJlbCBhdCB0aGUgdG9wIG9mIHRoZSBzdGFjayBiZWxvbmdzIHRvIENBLVNSR0Ig dGhlbiBpdCBoYXMgdG8gYmUgZm9yIGFueWNhc3QgcHJlZml4IG9yaWdpbmF0ZWQgcmVtb3RlbHkg YW5kIHRoZSBwYWNrZXQgYWN0dWFsbHkgaGl0cyBhbiBlbnRyeSBpbiB0aGUgZGVmYXVsdCBMRklC IGZpcnN0Li4gQnV0IGJlY2F1c2UgdGhlIGxhYmVsIGlzIGNvcnJlc3BvbmRpbmcgdG8gYW4gYW55 Y2FzdCBwcmVmaXggd2UgaW5zdGFsbCBhIHJlY3Vyc2l2ZSBsb29rdXAgd2l0aCB0aGUgVi1MRklC IGFzIHRoZSBuZXh0IHRhYmxlLi4gV2hlbiB0aGUgbG9va3VwIGZvciBuZXh0IGxhYmVsIGluIHN0 YWNrIGluIHRoZSBWTEZJQiBpcyBsYXVuY2hlZCB0aGF0IGxhYmVsIG1heWJlIGFzc29jaWF0ZWQg d2l0aCBDQV9TUkdCIG9yIGRlZmF1bHQtU1JHQi4uIFRoZSBWLUxGSUIgaXMgbmVlZGVkIHRvIG9u bHkgZmFjbGl0YXRlIGxvb2t1cCBvZiB0aGUgbmV4dCBsYWJlbC4uICBJbiBjYXNlIHRoZSBDQS1T UkdCIGlzIHNhbWUgYXMgZGVmYXVsdC1TUkdCIEkgaG9wZSB5b3VyIHJlYWxpemUgdGhhdCBhIHJl Y3Vyc2l2ZSBsYWJlbCBpcyBub3QgcmVxdWlyZWQuIEl0IGlzIGltcG9ydGFudCB0byByZWFsaXpl IHRoYXQgQ0EtU1JHQiBpcyBpbnZlbnRlZCB0byBhY3R1YWxseSBhdm9pZCByZWN1cnNpdmUgbGFi ZWwgbG9va3VwLi4gVGhlIGRldmljZXMgdGhhdCB1c2VzIHNhbWUgQ0EtU1JHQiBhcyBkZWZhdWx0 IFNSR0IgbmVlZCBub3Qgc3VwcG9ydCByZWN1cnNpdmUgbGFiZWwgbG9va3VwIGluIHRoZSBoYXJk d2FyZS4uDQoNCltDaGVuZ10gWWVzLCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBsb2dpYyBvZiB5b3Vy IHNvbHV0aW9uLiAgV2hhdCBpZiB3ZSBwb3AgdGhlIGFueWNhc3QgbGFiZWwgLGFuZCBsZXQgdGhl IENBUFNMIHRvIGhpdCB0aGUgZW50cnkgaW4gTEZJQiwgYW5kIHRoZW4gZXhlY3V0ZSB0aGUgYWN0 aW9uIG9mIGxvb2tpbmcgdXAgQ0FQU0wgaW4gVi1MRklCLiAgV2h5IGRvIHdlIG5lZWQgdG8ga2Vl cCB0aGUgYW55Y2FzdCBsYWJlbCA/IFRoaXMgaXMgbXkgcXVlc3Rpb24uDQoNCg0KDQozOiBJIGZv dW5kIG91dCBzb21lIHN0cmFuZ2Ugc3RhdGVtZW50cyBpbiB0aGUgZHJhZnQ6DQoNCg0KYSkgICAg ICAgUGFnZSAxMQ0KDQpGb3IgZXhhbXBsZSwgb24gZGV2aWNlIEExLCB0aGUgcHJlZml4IFNJRCAx MCAob3JpZ2luYXRlZCBieSBQRTMpIGlzDQoNCiAgIHJlYWNoYWJsZSB0aHJvdWdoIGl0cyBuZWln aGJvcnMgQTMgYW5kIEE0LiAgQW5kIGFzIHBlciB0aGUgU1JHQg0KDQogICBhZHZlcnRpc2VkIGJ5 IEEzIGFuZCBBNCwgdGhlIGxhYmVscyBhbGxvY2F0ZWQgYnkgQTMgYW5kIEE0IGFyZSAzMDMwDQog ICBhbmQgNDAzMCByZXNwZWN0aXZlbHkNCg0KSSBzdXBwb3NlIHRoYXQgdGhlIHByZWZpeCBTSUQg aXMgMzAgaW5zdGVhZCBvZiAxMC4NCltQdXNocGFzaXNdIFllcyB5b3UgYXJlIHJpZ2h0LiBJIGhh dmUgYWxyZWFkeSBnb3QgdGhpcyBjb21tZW50IGZyb20gb25lIG9mIHRoZSBXRyBtZW1iZXJzLiBJ IHdpbGwgcmVjdGlmeWluZyB0aGlzIGluIG5leHQgdmVyc2lvbi4NCg0KYikgICAgICAgUGFnZSAx NA0KDQpUaGlzIGlzIGJlY2F1c2Ugb24gbm9kZSBBMe+8iElzIGl0IEEyP++8iSB0aGUgZG9tYWlu LXdpZGUgQ0EtU1JHQiBpcyBpZGVudGljYWwgdG8gdGhlIGxvY2FsIFNSR0IgcHJvdmlzaW9uZWQg b24gQTIuDQoNCg0KDQpjKSAgICAgICBQYWdlIDE0DQoNCldoaWxlIGZvcndhcmRpbmcgdG8gQTIs IHNpbmNlIEEyIHdvdWxkDQoNCiAgICBoYXZlIGFkdmVydGlzZWQgdGhlIGFueWNhc3QgU0lEIDEw MCB3aXRoIFAtRmxhZyAoTm8tUEhQKSB1bnNldCwgUjENCg0KICAgIHNoYWxsIFBPUCB0aGUgaW5j b21pbmcgbGFiZWwgNzEwMCBiZWZvcmUgZm9yd2FyZGluZyBpdCB0byBSMShJcyBpdCBBMj8pLg0K W1B1c2hwYXNpc10gWWVzIHlvdSBhcmUgcmlnaHQuIEkgaGF2ZSBhbHJlYWR5IGdvdCB0aGlzIGNv bW1lbnQgYXMgd2VsbCBmcm9tIG9uZSBvZiB0aGUgV0cgbWVtYmVycy4gSSB3aWxsIHJlY3RpZnlp bmcgdGhpcyBpbiBuZXh0IHZlcnNpb24uDQoNClRoYW5rcyBhIGxvdCBmb3IgY29tbWVudHMgYW5k IHRob3VnaHRzLg0KDQpCZXN0IHJlZ2FyZHMNCi1QdXNocGFzaXMNCg0KDQpUaGFuayB5b3UgZm9y IHlvdXIgZ29vZCBqb2IhDQoNClJlZ2FyZHMsDQpDaGVuZw0KDQoNCuWPkeS7tuS6ujogc3ByaW5n IFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnPl0g5Luj6KGoIFB1c2hwYXNpcyBTYXJrYXINCuWPkemAgeaXtumXtDogMjAxN+W5tDfm nIgyMOaXpSAxMjozNQ0K5pS25Lu25Lq6OiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tPj4NCuaKhOmAgTogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IGRy YWZ0LWlldGYtc3ByaW5nLWFueWNhc3Qtc2VnbWVudEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi1zcHJpbmctYW55Y2FzdC1zZWdtZW50QGlldGYub3JnPjsgZHJhZnQtbXBscy1zaGVuLWVncmVz cy1wcm90ZWN0aW9uLWZyYW1ld29ya0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtbXBscy1zaGVuLWVn cmVzcy1wcm90ZWN0aW9uLWZyYW1ld29ya0BpZXRmLm9yZz47IFNoZWxsIE5ha2FzaCA8U2hlbGwu TmFrYXNoQGVjaXRlbGUuY29tPG1haWx0bzpTaGVsbC5OYWthc2hAZWNpdGVsZS5jb20+PjsgTWlj aGFlbCBHb3Jva2hvdnNreSA8TWljaGFlbC5Hb3Jva2hvdnNreUBlY2l0ZWxlLmNvbTxtYWlsdG86 TWljaGFlbC5Hb3Jva2hvdnNreUBlY2l0ZWxlLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz47IERtaXRyeSBWYWxkbWFuIDxEbWl0cnkuVmFsZG1hbkBlY2l0ZWxl LmNvbTxtYWlsdG86RG1pdHJ5LlZhbGRtYW5AZWNpdGVsZS5jb20+PjsgUm9uIFNkYXlvb3IgPFJv bi5TZGF5b29yQGVjaXRlbGUuY29tPG1haWx0bzpSb24uU2RheW9vckBlY2l0ZWxlLmNvbT4+OyBS b3RlbSBDb2hlbiA8Um90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVj aXRlbGUuY29tPj4NCuS4u+mimDogUmU6IFtzcHJpbmddIEFueWNhc3Qgc2VnbWVudHMgYW5kIGNv bnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2VzDQoNCkhpIFNhc2hhLA0KDQpUaGFua3MgYSBsb3Qg Zm9yIHRha2luZyB0aW1lIHRvIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBwcm92aWRpbmcgdGhlIG11 Y2ggYXBwcmVjaWF0ZWQgY29tbWVudHMuIFBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgaW5saW5l Lg0KDQoNCk9uIFdlZCwgSnVsIDE5LCAyMDE3IGF0IDEyOjA5IEFNLCBBbGV4YW5kZXIgVmFpbnNo dGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPj4gd3JvdGU6DQpIaSBhbGwsDQpJIGhhdmUgcmVhZCB0aGUg ZHJhZnQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLW1wbHMt YW55Y2FzdC1zZWdtZW50cy0wMT4gaW4gcXVlc3Rpb24sIGFuZCwgZnJvbSBteSBQT1YsIGl0IGRl ZmluZXMsIHVuZGVyIHRoZSBuYW1lIG9mIFZpcnR1YWwgTEZJQiwgIGEgZGVkaWNhdGVkIGNvbnRl eHQtc3BlY2lmaWMgbGFiZWwgc3BhY2UgKHNlZSBSRkMgNTMzMTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNTMzMT4pICBpbiB0aGUgZGV2aWNlcyB0aGF0IGFyZSBhc3NpZ25lZCB3aXRo IG9uZSBvciBtb3JlIGFueWNhc3Qgc2VnbWVudHMsIGFuZCB1c2VzIHRoZSBsYWJlbHMgc3VjaCBk ZXZpY2VzIGFsbG9jYXRlIGZvciB0aGVzZSBzZWdtZW50cyBhcyB0aGUgY29udGV4dCBsYWJlbHMg aWRlbnRpZnlpbmcgdGhpcyBzcGFjZS4NCltQdXNocGFzaXNdIFllcywgdGhhdCBpcyBjb3JyZWN0 LiBJIHdpbGwgYWRkIGEgcmVmZXJlbmNlIHRvIFJGQyA1MzMxIGluIHRoZSBuZXh0IHZlcnNpb24u DQoNCg0KSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0Og0KDQrigKIgICAgICAgICBFeHBs aWNpdCBtYXBwaW5nIG9mIHRoZSBkZWZpbml0aW9ucyBvZiB0aGUgZHJhZnQgdG8gYWxyZWFkeSBk ZWZpbmVkIGFuZCB3ZWxsLXVuZGVyc3Rvb2QgTVBMUyBhcmNoaXRlY3R1cmFsIG1lY2hhbmlzbXMg d291bGQgZ3JlYXRseSBpbXByb3ZlIGl0cyByZWFkYWJpbGl0eS4gSXQgd291bGQgYWxzbyBncmVh dGx5IGhlbHAgdGhlIGltcGxlbWVudGVycywgZXNwZWNpYWxseSBpZiB0aGV5IGhhdmUgYWxyZWFk eSBpbXBsZW1lbnRlZCAob3IgY29uc2lkZXIgaW1wbGVtZW50YXRpb24gb2YpIGNvbnRleHQtc3Bl Y2lmaWMgbGFiZWwgc3BhY2VzIGluIHRoZWlyIGRldmljZXMNCltQdXNocGFzaXNdIEF0IHRoZSB0 aW1lIG9mIHdyaXRpbmcgdGhpcyBkcmFmdCwgdGhlcmUgd2VyZSBhbHJlYWR5IHNvbWUgaW1wbGVt ZW50YXRpb25zIG9mIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2UgLCBhbmQgc28gSSB0aG91 Z2h0IGFkZGluZyB0aG9zZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHdpbGwgbm90IGJlIHVzZWZ1 bCwgZXNwZWNpYWxseSBkdXJpbmcgdGhlIFdHTEMgbGFzdCBjYWxscy4gSW1wbGVtZW50YXRpb24g bWludXRlIGRldGFpbHMgYXJlIG5vdCB3ZWxjb21lIEkgYXNzdW1lIGZyb20gdGhlIFdHTEMgcmV2 aWV3cyBJIGhhdmUgZ29uZSB0aHJvdWdoIHNvIGZhci4gQnV0IGwgY2FuIHN1cmUgYWRkIHNvbWUg cmVmZXJlbmNlIHRvIFJGQzUzMzEuDQoNCuKAoiAgICAgICAgIEFkZGluZyB0aGUgcmVsZXZhbnQg cmVmZXJlbmNlcyAoaW5jbHVkaW5nIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgNTMzMSkg c2VlbXMgbmVjZXNzYXJ5DQoNClVzaW5nIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2VzIGFu ZCBjb250ZXh0IGxhYmVscyBpbiBjb25qdW5jdGlvbiB3aXRoIGFueWNhc3QgKG9yIGFueWNhc3Qt bGlrZSkgZnVuY3Rpb25hbGl0eSAgaW4gTVBMUyBpcyBub3QgbmV3LiBPbmUgZXhhbXBsZSAoYXMg aW5kaWNhdGVkIGluIEVyaWMgUm9zZW7igJlzIGVtYWlsPGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzEyNjU5Lmh0bWw+KSAgaXMgdGhlIFBXIEVu ZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uIG1lY2hhbmlzbSBkZWZpbmVkIGluIFJGQyA4 MTA0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTA0Pi4NCltQdXNocGFzaXNdIFll cywgdXNlIG9mIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2UgaXMgbm90IG5ldy4gQW5kIHdv cmtpbmcgaW4gSnVuaXBlciBmb3Igc29tZXRpbWUgSSBoYXZlIGEgZ29vZCBpZGVhIG9mIGl0cyBh cHBsaWNhdGlvbi4gQnV0IHVzaW5nIGl0IHRvIHByb3ZpZGUgYSBtZWFucyB0byBkbyBhbnljYXN0 IHNlZ21lbnRzIHVzaW5nIE1QTFMgZGF0YXBsYW5lIGlzIHZlcnkgbXVjaCBuZXcuIEFuZCB0byBt eSBrbm93bGVkZ2UgdGlsbCBkYXRlIHRoZXJlIGlzIG5vIG90aGVyIHdheSB0byBhY2hpZXZlIHRo aXMgd2l0aG91dCByZWN1cnNpdmUgbGFiZWwgbG9va3VwIGFuZCBjb250ZXh0LXNwZWNpZmljIGxh YmVsIHNwYWNlcy4NCg0KVGhlIGFuYWxvZ3kgbG9va3MgaW1wb3J0YW50IHRvIG1lIHNpbmNlIGFu eWNhc3QgZ3JvdXBzIGFyZSBjb21tb25seSBjb25zaWRlcmVkIGFzIGEgcHJvdGVjdGlvbiBtZWNo YW5pc20gKGFuZCBub3QganVzdCBhcyBhIGxvYWQtYmFsYW5jaW5nIG9uZSkuDQpbUHVzaHBhc2lz XSBBY3R1YWxseSwgYWJvdXQgdGhlIHVzZWNhc2VzIEkgaGF2ZSBkaXNjdXNzZWQgc29tZSBvZiB0 aGUgb3BlcmF0b3JzIEkgaGF2ZSBkaXNjdXNzZWQgd2l0aCBzbyBmYXIgb24gdGhpcywgYWxtb3N0 IGFsbCB0aGVtIGFyZSBhYm91dCBwb2xpY3ktYmFzZWQtcm91dGluZywgIGxvYWQtYmFsYW5jaW5n IGFuZCBwcm92aWRpbmcgZGlzam9pbnQgcGF0aHMuIE9mZmNvdXJzZSBkaXNqb2ludCBwYXRocyBj YW4gYmUgdXNlZCBmb3IgcHJvdGVjdGlvbiBhcyB3ZWxsIGFzIGxvYWQtYmFsYW5jaW5nLg0KDQpJ IGFsc28gdGhpbmsgdGhhdCByZWxhdGlvbnNoaXBzIGJldHdlZW4gdGhpcyBkcmFmdCBhbmQgdGhl IGVncmVzcyBwcm90ZWN0aW9uIGZyYW1ld29yazxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zaGVuLW1wbHMtZWdyZXNzLXByb3RlY3Rpb24tZnJhbWV3b3JrLz9pbmNsdWRl X3RleHQ9MT4gb25lIGFyZSB3b3J0aCBsb29raW5nIGF0IGNhcmVmdWxseS4NCltQdXNocGFzaXNd IEZpcnN0IHRoZSBlZ3Jlc3MgcHJvdGVjdGlvbiBkcmFmdHMgZG9lcyBub3Qgc2VlbSB0byBoYXZl IGdvbmUgdGhyb3VnaCBXRyBhZG9wdGlvbi4gTmV4dCB0aG91Z2ggdGhlc2UgdHdvIGRyYWZ0cyB1 c2UgdGhlIHNhbWUgbWVjaGFuaXNtcywgdGhlIGV4YWN0IHByb2JsZW0gdGhleSB0cnkgdG8gc29s dmUgYXJlIG5vdCBleGFjdGx5IHJlbGF0ZWQuDQoNCk5ldmVydGhlbGVzcywgSSB2YWx1ZSB5b3Vy IGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhbmQgdGhvdWdodHMgYSBsb3QsIGFuZCB0aGFuayB5b3Ug dmVyeSBtdWNoIGZvciBwcm92aWRpbmcgdGhlIGluc2lnaHRzLiBJIHdpbGwgZGVmaW5pdGVseSB3 b3JrIG9uIHRoZW0gYW5kIGFkZHJlc3MgdGhlbSBpbiB0aGUgbmV4dCBkcmFmdC4NCg0KVGhhbmtz IG9uY2UgYWdhaW4gYW5kIGJlc3QgcmVnYXJkcywNCi1QdXNocGFzaXMNCg0KDQpNeSAyYywNClNh c2hhDQoNCk9mZmljZTogKzk3Mi0zOTI2NjMwMg0KQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0K RW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlz IGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNv bnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzDQpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBi ZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0K dHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUg b3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsDQphbmQgYWxsIGNvcGllcyB0aGVy ZW9mLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nDQoNCg0KDQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CDE9dggemi502mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm0y NDQ3NDk4MzUyMTk0NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4NTY4Njc2bXNvbGlzdHBhcmFncmFw aCwgbGkubTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtc29saXN0 cGFyYWdyYXBoLCBkaXYubTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2 NzZtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fMjQ0NzQ5ODM1MjE5NDY1ODFn bWFpbC1tXy0zMTU3MDUyMzI3MTg1Njg2NzZtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk65a6L5L2TO30NCnAubTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2 NzZtNzQ5MDc0Njg3Mjk5NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0yNDQ3NDk4MzUyMTk0 NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4NTY4Njc2bTc0OTA3NDY4NzI5OTY1MTkxNDRtc29saXN0 cGFyYWdyYXBoLCBkaXYubTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2 NzZtNzQ5MDc0Njg3Mjk5NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6 bV8yNDQ3NDk4MzUyMTk0NjU4MWdtYWlsLW1fLTMxNTcwNTIzMjcxODU2ODY3Nm03NDkwNzQ2ODcy OTk2NTE5MTQ0bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFu LmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpJm5i c3A7IFB1c2hwYXNpcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Xb3csIGl0 IGhhcyBiZWVuIHR3byB5ZWFycyBzaW5jZSB5b3UgbWFkZSB0aGUgcHJlc2VudGF0aW9uLiZuYnNw OyBUaGFuayB5b3UgZm9yIHlvdXIgc2xpZGVzLiBJIGhhdmUgcmVhZCBpdCBhbGwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnV0IEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9u cy4gUGxlYXNlIGZpbmQgdGhlbSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IFB1c2hwYXNpcyBTYXJrYXIgW21haWx0bzpwdXNo cGFzaXMuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWYiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjg8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4t VVMiPjk8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDIzOjMxPGJyPg0KPC9zcGFuPjxi PuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IENoZW5nbGkgKERpc3RhbmNlKSAmbHQ7Y2hlbmdsaTEzQGh1YXdlaS5jb20mZ3Q7PGJyPg0K PC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IFJlOiA8L3NwYW4+562U5aSNPHNwYW4gbGFuZz0iRU4tVVMiPjogW3NwcmluZ10g QW55Y2FzdCBzZWdtZW50cyBhbmQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SG9wZSB5b3UgaGF2ZSBhbHJlYWR5IGdvbmUgdGhy b3VnaCBteSBwcmVzZW50YXRpb24gcHJlc2VudGVkIHdheSBiYWNrIGluIDIwMTUuLiBJZiBub3Qg aGVyZSBpcyB0aGUgbGluayB0byB0aGUgc2FtZS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1zcHJpbmctMS5wZGYiPmh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkzL3NsaWRlcy9zbGlkZXMtOTMtc3ByaW5nLTEucGRmPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBBdWcg OSwgMjAxNyBhdCA4OjU4IFBNLCBQdXNocGFzaXMgU2Fya2FyICZsdDs8YSBocmVmPSJtYWlsdG86 cHVzaHBhc2lzLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHVzaHBhc2lzLmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIENoZW5nbGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGEgbG90IGZvciB0YWtpbmcgdGltZSB0 byByZWFkIHRoZSBkcmFmdCBhbmQgcHJvdmlkZSBjb21tZW50cy4gUGxlYXNlIGZpbmQgYW5zd2Vy cyBpbmxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQs IEF1ZyA5LCAyMDE3IGF0IDI6MDQgUE0sIENoZW5nbGkgKERpc3RhbmNlKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNoZW5nbGkxM0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hlbmdsaTEzQGh1 YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhpIFB1c2hwYXNpcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFtIGEgbmV3IGxlYXJuZXIgb2YgU1IuIFJlY2VudGx5 LCBJIHJlYWQgdGhlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1tcGxzLWFueWNhc3Qtc2VnbWVu dHMtMDEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+ZHJh ZnQ8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQiPiwNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPmFuZCBJIGhhYSBzb21lIHF1ZXN0aW9ucyBhYm91dCBpdC4gU29tZSBvZiB0aGVtIGFyZSBh Ym91dCB0aGUgYWxnb3JpdGhtLCB3aGlsZSB0aGUgb3RoZXJzIGFyZSBhYm91dCB0aGUgY29udGV4 dC4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjE6IElmIENBLVNSR0IgbmVlZCB0byBiZSBjb25maWd1cmVkIHRoZSBz YW1lIGFtb25nIGFsbCBub2Rlcywgd2hpY2ggbWVhbnMgYWxsIG5vZGVzIGNhbg0KIHVuZGVyc3Rh bmQgdGhlIGxhYmVsIGluIENBLVNSR0IuIElmIHNvLCB3aHkgZG8gd2UgbmVlZCB0byBzZXQgUC1G bGFnIHdoZW4gdGhlIG5vZGUgaGFzIGEgZGlmZmVyZW50IENBLVNSR0IgcmFuZ2Ugd2l0aCBTUkdC LiBXaXRob3V0IHRoZSBBbnljYXN0LVNJRCwgdGhlIG5vZGUgY2FuIHVuZGVyc3RhbmQgQ0EtU1JH QiBhbmQgcHJvY2VzcyBDQVBTTCBhcyB3ZWxsLiZuYnNwOyBXaHkgZG8gd2UgbmVlZCB0byBrZWVw IEFueWNhc3QgbGFiZWw/IFRvIGluZGVudGlmeQ0KIHRoZSBuZXh0IGxhYmVsIGlzIGEgQ1BBU0w/ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVzaHBhc2lzXSBZZXMgdGhpcyBpcyBuZWVkZWQgZm9yIHRo ZSBub2RlIHRoYXQgb3JpZ2luYXRlZCB0aGUgQ0FQU0wuIEluIGNhc2UgdGhlIENBLVNSR0IgaXMg ZGlmZmVyZW50IGZyb20gcmVndWxhciBTUkdCIHRoZSBwYWNrZXQgbXVzdCBjb21lIGluIHdpdGgg dGhlIENBUFNMIGF0IHRoZSB0b3Agb2YgdGhlIHN0YWNrIHNvIHRoYXQgaXQgcG9wcyBhbmQgZG9l cyBhIHJlY3Vyc2l2ZQ0KIGxhYmVsIGxvb2t1cCB3aXRoIHRoZSBuZXh0IGxhYmVsIGluIHN0YWNr Li4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltDaGVuZ10gSWYgdGhlcmUgaXMgYW4gYWN0aW9uIHN1cHBvcnRpbmcgdG8gbG9vayB1cCBp biBWLUxGSUIsIHdoeSBub3QgdXNlIENBUFNMIGFzIHRoZSBrZXkgaW4gRGVmYXVsdCBMRklCIGRp cmVjdGx5PyZuYnNwOyBJZiBzbywgUC1GbGFnIGNhbiBiZSBsZWF2ZWQgMCwgYW5kIG5vZGUgd2ls bA0KIHJlY2VpdmUgYSBwYWNrZXQgd2l0aCB0aGUgQ0FQU0wgYXMgdGhlIHRvcCBsYWJlbCBubyBt YXR0ZXIgaXTigJlzIENBLVNSR0IgaXMgdGhlIHNhbWUgYXMgU1JHQiBvciBub3QuIEluIGRlZmF1 bHQgTEZJQiwgdGhlcmUgc2hvdWxkIGJlIGFuIGVudHJ5IGZvciBDQVBTTCwgYW5kIGl04oCZcyBh Y3Rpb24gaXMgdG8gbG9vayB1cCBDQVBTTCBpbiBWLUxGSUIuIEkgYW0gbm90IHN1cmUgdGhhdCB3 aGV0aGVyIGl0IGNhbiB3b3JrIG9yIG5vdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkluIHRoaXMgd2F5LCBjb25maWd1cmF0aW9uIHdpbGwgYmUgbXVjaCBlYXNpZXIuJm5i c3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBzdW1tYXJ5LCBpbiBt eSBQT1YsIHdlIGNhbiBwb3AgdGhlIHByZXZpb3VzIGFueWNhc3QgbGFiZWwgc28gdGhhdCB0aGUg bm9kZSBjYW4gcmVjZWl2ZSB0aGUgc2FtZSBwYWNrZXQgbm8gbWF0dGVyIGl04oCZcyBDQS1TUkdC IGlzIHRoZSBzYW1lIGFzIFNSR0Igb3Igbm90LiBCdXQgSQ0KIHN1cHBvc2UgdGhhdCAmbmJzcDt0 aGVyZSBtdXN0IGJlIHNvbWUgcmVhc29ucyB0aGF0IHlvdSBkaWRu4oCZdCZuYnNwOyBwcm9wb3Nl IGEgc29sdXRpb24gbGlrZSB0aGlzLiBJZiBwb3NzaWJsZSwgY2FuIHlvdSBiZSBraW5kIHRvIHRl bGwgbWUgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhlIHJl YXNvbiBtYXliZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPktlZXBpbmcg dGhlIGFueWNhc3QgbGFiZWwgY2FuIHJlZHVjZSB0aGUgZW50cmllcyBvZiBMRklCLiZuYnNwOyBJ ZiB3ZSB1c2UgQ0FQU0wgYXMgdGhlIHRvcCBsYWJlbCwgd2UgbmVlZCB0byBpbnN0YWxsIGVudHJp ZXMgZm9yIGFsbCBDQVBTTHMgaW4gTEZJQiBhbmQgaW4gVi1MRklCIGFzIHdlbGwuDQogQnV0IGlm IHdlIGtlZXAgQW55Y2FzdCBsYWJlbCBhcyB0aGUgdG9wIGxhYmVsLCZuYnNwOyB3ZSBvbmx5IG5l ZWQgdG8gaW5zdGFsbCBvbmUgZW50cnkgZm9yIEFueWNhc3QgbGFiZWwsIGFuZCBvbmUgZW50cnkg Zm9yIGVhY2ggQ0FQU0wgaW4gVi1MRklCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4yOiBJbiBzZWN0 aW9uIDMuMi4yIG9mIHlvdXIgZHJhZnQsIGl0IHNheXMgdGhhdA0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1pbmRlbnQ6MjEuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgc2VwYXJhdGUgdmly dHVhbCBsYWJlbCBsb29rdXAgdGFibGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgKGhlcmVh ZnRlciByZWZlcnJlZCB0byBhcyBWaXJ0dWFsIExGSUIgb3IgVi1MRklCKSwgdGhhdCByZXByZXNl bnRzIGE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbGFiZWwgc3BhY2Ugd2hpY2ggaXMgYWxz byBzZXBhcmF0ZSBmcm9tIHRoZSBhY3R1YWwgbGFiZWwgc3BhY2U8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgcmVwcmVzZW50ZWQgYnkgdGhlIGRlZmF1bHQgTEZJQi4mbmJzcDsgVGhlIGxhYmVs IHZhbHVlIG1heSBiZSBwcmVzZW50IGluPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGJvdGgg dGhlIGRlZmF1bHQgYW5kIFZpcnR1YWwgTEZJQi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBWLUxGSUIgcmVwcmVz ZW50cyBhIGxhYmVsIHNwYWNlIHNlcGFyYXRlZCBmcm9tIHRoZSBsYWJlbCBzcGFjZSByZXByZXNl bnRlZCBieSBMRklCLA0KIHdoeSBsYWJlbCB2YWx1ZSBtYXkgYmUgcHJlc2VudCBpbiBib3RoIG9m IHRoZW0/Jm5ic3A7IElmIHRoaXMgaXMgcmlnaHQsIEkgc3VwcG9zZSB0aGF0IHRoZSByZWFzb24g b2Yga2VlcGluZyBhbnljYXN0IGxhYmVsIGlzIHRvIGlkZW50aWZ5IHRoZSBuZXh0IGxhYmVsIHNo b3VsZCBiZSBsb29rZWQgdXAgaW4gVi1MRklCIGluc3RlYWQgb2YgZGVmYXVsdCBvbmUuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5bUHVzaHBhc2lzXSBUaGVvcmV0aWNhbGx5IGFsbCBsYWJlbC1zcGFjZXMgY2FuIGJl IGluZGVwZW5kZW50IGFuZCBtYXkgaGF2ZSB0aGUgc2FtZSBsYWJlbCBwcm9ncmFtbWVkIGluIHRo ZW0gd2l0aCBkaWZmZXJlbnQgZm9yd2FyZGluZyBzZW1hbnRpY3MuIEhvd2V2ZXIgZnJvbSB0aGUg Zm9sbG93aW5nIHRleHQgd2UgcHJvcG9zZWQgYSBzZXBhcmF0ZSBWLUxGSUIgaWYgYW5kIG9ubHkN CiBpZiBDQS1TUkdCIGlzIGRpZmZlcmVudCBmcm9tIFNSR0IuLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0NoZW5n XSBJIGFtIHdvbmRlcmluZyB0aGF0IHdoYXQgaXMgdGhlIGxhYmVsLXNwYWNlPyBJIHRoaW5rIGl0 IGlzIHRoZSByYW5nZSBvZiBsYWJlbC4gQnV0IGl0IHNlZW1zIG5vdC4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+IFN1Y2ggYSBkZXZpY2UgTVVT VCBhZGQgYW4gZW50cnkgaW4gdGhlIFZpcnR1YWwgTEZJQiBmb3IgZWFjaCB1bmljYXN0PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgYW5kIGFueWNhc3QgcHJlZml4IHNlZ21lbnRzIGxlYXJudCBmcm9tIGEgcmVt b3RlIGRldmljZSwgaWYgYW5kIG9ubHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgaWYgdGhlIHNhbWUgcHJlZml4IGhhcyBub3QgYmVlbiBwcm92aXNpb25lZCBvbiB0 aGUgZGV2aWNlLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgZGV2aWNlIFNIT1VMRCBOT1QgYWRkIGFuIGVudHJ5IGZvciBhbnkgb2YgdGhlIEFueWNh c3Qgb3IgTm9kZSBwcmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgc2VnbWVudHMgdGhhdCBpdCBoYXMgYWR2ZXJ0aXNlZCBpdHNlbGYuJm5ic3A7IEhvd2V2ZXIg aWYgdGhlIGRldmljZSBoYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgbGVhcm50IGFueSBhbnljYXN0IHByZWZpeCBzZWdtZW50IGZyb20gYSByZW1vdGUgZGV2aWNl LCBhbmQgdGhlIHNhbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg aXMgbm90IHByb3Zpc2lvbmVkIG9uIHRoaXMgZGV2aWNlLCB0aGUgZGV2aWNlIE1VU1QgaW5jbHVk ZSB0aGUgc2FtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbiB0 aGUgVmlydHVhbCBMRklCIHRhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPltQdXNocGFzaXNdIElmIHRoZSBs YWJlbCBhdCB0aGUgdG9wIG9mIHRoZSBzdGFjayBiZWxvbmdzIHRvIENBLVNSR0IgdGhlbiBpdCBo YXMgdG8gYmUgZm9yIGFueWNhc3QgcHJlZml4IG9yaWdpbmF0ZWQgcmVtb3RlbHkgYW5kIHRoZSBw YWNrZXQgYWN0dWFsbHkgaGl0cyBhbiBlbnRyeSBpbiB0aGUgZGVmYXVsdCBMRklCIGZpcnN0Li4g QnV0IGJlY2F1c2UgdGhlIGxhYmVsIGlzIGNvcnJlc3BvbmRpbmcNCiB0byBhbiBhbnljYXN0IHBy ZWZpeCB3ZSBpbnN0YWxsIGEgcmVjdXJzaXZlIGxvb2t1cCB3aXRoIHRoZSBWLUxGSUIgYXMgdGhl IG5leHQgdGFibGUuLiBXaGVuIHRoZSBsb29rdXAgZm9yIG5leHQgbGFiZWwgaW4gc3RhY2sgaW4g dGhlIFZMRklCIGlzIGxhdW5jaGVkIHRoYXQgbGFiZWwgbWF5YmUgYXNzb2NpYXRlZCB3aXRoIENB X1NSR0Igb3IgZGVmYXVsdC1TUkdCLi4gVGhlIFYtTEZJQiBpcyBuZWVkZWQgdG8gb25seSBmYWNs aXRhdGUgbG9va3VwDQogb2YgdGhlIG5leHQgbGFiZWwuLiZuYnNwOyBJbiBjYXNlIHRoZSBDQS1T UkdCIGlzIHNhbWUgYXMgZGVmYXVsdC1TUkdCIEkgaG9wZSB5b3VyIHJlYWxpemUgdGhhdCBhIHJl Y3Vyc2l2ZSBsYWJlbCBpcyBub3QgcmVxdWlyZWQuIEl0IGlzIGltcG9ydGFudCB0byByZWFsaXpl IHRoYXQgQ0EtU1JHQiBpcyBpbnZlbnRlZCB0byBhY3R1YWxseSBhdm9pZCByZWN1cnNpdmUgbGFi ZWwgbG9va3VwLi4gVGhlIGRldmljZXMgdGhhdCB1c2VzIHNhbWUgQ0EtU1JHQiBhcw0KIGRlZmF1 bHQgU1JHQiBuZWVkIG5vdCBzdXBwb3J0IHJlY3Vyc2l2ZSBsYWJlbCBsb29rdXAgaW4gdGhlIGhh cmR3YXJlLi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltDaGVuZ10gWWVzLCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBs b2dpYyBvZiB5b3VyIHNvbHV0aW9uLiZuYnNwOyBXaGF0IGlmIHdlIHBvcCB0aGUgYW55Y2FzdCBs YWJlbCAsYW5kIGxldCB0aGUgQ0FQU0wgdG8gaGl0IHRoZSBlbnRyeSBpbiBMRklCLCBhbmQgdGhl biBleGVjdXRlIHRoZSBhY3Rpb24NCiBvZiBsb29raW5nIHVwIENBUFNMIGluIFYtTEZJQi4mbmJz cDsgV2h5IGRvIHdlIG5lZWQgdG8ga2VlcCB0aGUgYW55Y2FzdCBsYWJlbCA/IFRoaXMgaXMgbXkg cXVlc3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+MzogSSBmb3VuZCBvdXQgc29tZSBzdHJhbmdlIHN0YXRlbWVudHMgaW4gdGhl IGRyYWZ0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Im0yNDQ3NDk4MzUyMTk0NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4 NTY4Njc2bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmEpPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlBhZ2UgMTE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0LjBwdDt0ZXh0LWluZGVudDox MC41cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPkZvciBl eGFtcGxlLCBvbiBkZXZpY2UgQTEsIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+dGhl IHByZWZpeCBTSUQgMTAgKG9yaWdpbmF0ZWQgYnkgUEUzKTwvc3Bhbj4gaXM8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MjQuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgcmVhY2hhYmxlIHRocm91Z2ggaXRzIG5laWdoYm9ycyBBMyBhbmQgQTQu Jm5ic3A7IEFuZCBhcyBwZXIgdGhlIFNSR0I8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjQuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWR2 ZXJ0aXNlZCBieSBBMyBhbmQgQTQsIHRoZSBsYWJlbHMgYWxsb2NhdGVkIGJ5IEEzIGFuZCBBNCBh cmUgMzAzMDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgNDAzMCBy ZXNwZWN0aXZlbHk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIHN1cHBvc2UgdGhhdCB0aGUgcHJlZml4IFNJRCBpcyAzMCBpbnN0ZWFkIG9mIDEw Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+W1B1c2hwYXNpc10gWWVzIHlvdSBhcmUgcmlnaHQuIEkgaGF2ZSBhbHJl YWR5IGdvdCB0aGlzIGNvbW1lbnQgZnJvbSBvbmUgb2YgdGhlIFdHIG1lbWJlcnMuIEkgd2lsbCBy ZWN0aWZ5aW5nIHRoaXMgaW4gbmV4dCB2ZXJzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMjQ0NzQ5ODM1MjE5NDY1ODFnbWFpbC1tLTMx NTcwNTIzMjcxODU2ODY3Nm1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w cHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5iKTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYWdlIDE0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJ0ZXh0LWluZGVudDoxNS4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPlRoaXMgaXMgYmVjYXVz ZSBvbiBub2RlIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+QTE8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7vvIg8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+SXMgaXQgQTI/PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7vvIk8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4gPHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBkb21h aW4td2lkZSBDQS1TUkdCIGlzIGlkZW50aWNhbCB0byB0aGUgbG9jYWwgU1JHQiBwcm92aXNpb25l ZCBvbiBBMi4gPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cCBjbGFzcz0ibTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2 NzZtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Yyk8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+UGFnZSAxNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHByZSBzdHlsZT0idGV4dC1pbmRlbnQ6MTAuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5XaGlsZSBmb3J3YXJkaW5nIHRvIEEyLCBzaW5j ZSBBMiB3b3VsZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOyAmbmJzcDsmbmJzcDtoYXZlIGFkdmVydGlzZWQgdGhlIGFueWNhc3QgU0lEIDEwMCB3aXRo IFAtRmxhZyAoTm8tUEhQKSB1bnNldCwgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5S MTwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrO2JhY2tn cm91bmQ6eWVsbG93Ij4gJm5ic3A7Jm5ic3A7Jm5ic3A7c2hhbGwgUE9QIHRoZSBpbmNvbWluZyBs YWJlbCA3MTAwIGJlZm9yZSBmb3J3YXJkaW5nIGl0IHRvIFIxKElzIGl0IEEyPykuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPltQdXNocGFzaXNdIFllcyB5b3UgYXJlIHJpZ2h0LiBJIGhhdmUgYWxyZWFkeSBnb3Qg dGhpcyBjb21tZW50IGFzIHdlbGwgZnJvbSBvbmUgb2YgdGhlIFdHIG1lbWJlcnMuIEkgd2lsbCBy ZWN0aWZ5aW5nIHRoaXMgaW4gbmV4dCB2ZXJzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGEgbG90IGZvciBjb21tZW50cyBh bmQgdGhvdWdodHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiM4ODg4ODgiPi1QdXNocGFzaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9y IHlvdXIgZ29vZCBqb2IhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVuZzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWYiPg0KIHNwcmluZyBbbWFpbHRvOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWYiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWYiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmIj5QdXNocGFzaXMgU2Fya2FyPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMTc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxzcGFu IGxhbmc9IkVOLVVTIj4yMDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTI6MzU8YnI+ DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0Ozwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj5BbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBo cmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmIj5tcGxzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLXNwcmluZy1hbnljYXN0LXNlZ21lbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ZHJhZnQtaWV0Zi1zcHJpbmctYW55Y2FzdC1z ZWdtZW50QGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmIj47DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpk cmFmdC1tcGxzLXNoZW4tZWdyZXNzLXByb3RlY3Rpb24tZnJhbWV3b3JrQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPmRyYWZ0LW1wbHMtc2hlbi1lZ3Jlc3Mt cHJvdGVjdGlvbi1mcmFtZXdvcmtAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPjsNCiBTaGVsbCBOYWthc2ggJmx0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOlNoZWxsLk5ha2FzaEBlY2l0ZWxlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj5TaGVsbC5OYWthc2hAZWNpdGVs ZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDs7DQogTWljaGFlbCBHb3Jva2hvdnNreSAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48YSBocmVmPSJtYWlsdG86TWljaGFlbC5Hb3Jva2hvdnNreUBlY2l0ZWxlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj5NaWNoYWVsLkdvcm9raG92c2t5QGVjaXRl bGUuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPnNwcmluZ0Bp ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+OyBEbWl0cnkgVmFsZG1hbg0KICZsdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhy ZWY9Im1haWx0bzpEbWl0cnkuVmFsZG1hbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmIj5EbWl0cnkuVmFsZG1hbkBlY2l0ZWxlLmNvbTwvc3Bhbj48L2E+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCiBSb24gU2Rh eW9vciAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86Um9uLlNk YXlvb3JAZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ Um9uLlNkYXlvb3JAZWNpdGVsZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQogUm90ZW0gQ29oZW4gJmx0Ozwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPlJvdGVtLkNvaGVuQGVjaXRlbGUuY29t PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7kuLvpopg8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+IFJlOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNwZWNpZmljIGxh YmVsIHNwYWNlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgU2FzaGEsPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBhIGxvdCBmb3IgdGFraW5nIHRpbWUgdG8gcmVh ZCB0aGUgZG9jdW1lbnQgYW5kIHByb3ZpZGluZyB0aGUgbXVjaCBhcHByZWNpYXRlZCBjb21tZW50 cy4gUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IFdlZCwgSnVsIDE5LCAyMDE3IGF0IDEyOjA5IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0Ow0KIHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBoYXZlIHJlYWQgdGhlDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctbXBscy1hbnlj YXN0LXNlZ21lbnRzLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdDwvYT4gaW4gcXVlc3Rpb24s IGFuZCwgZnJvbSBteSBQT1YsIGl0IGRlZmluZXMsIHVuZGVyIHRoZSBuYW1lIG9mIFZpcnR1YWwg TEZJQiwgJm5ic3A7PGk+YSBkZWRpY2F0ZWQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZTwv aT4gKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzMzEiIHRh cmdldD0iX2JsYW5rIj5SRkMgNTMzMTwvYT4pICZuYnNwO2luIHRoZSBkZXZpY2VzIHRoYXQgYXJl IGFzc2lnbmVkIHdpdGggb25lIG9yIG1vcmUgYW55Y2FzdCBzZWdtZW50cywgYW5kIHVzZXMgdGhl IGxhYmVscyBzdWNoIGRldmljZXMgYWxsb2NhdGUgZm9yIHRoZXNlIHNlZ21lbnRzIGFzIHRoZQ0K PGk+Y29udGV4dCBsYWJlbHM8L2k+IGlkZW50aWZ5aW5nIHRoaXMgc3BhY2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVzaHBhc2lzXSBZZXMsIHRoYXQg aXMgY29ycmVjdC4gSSB3aWxsIGFkZCBhIHJlZmVyZW5jZSB0byBSRkMgNTMzMSBpbiB0aGUgbmV4 dCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0z MTU3MDUyMzI3MTg1Njg2NzZtNzQ5MDc0Njg3Mjk5NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkV4cGxpY2l0 IG1hcHBpbmcgb2YgdGhlIGRlZmluaXRpb25zIG9mIHRoZSBkcmFmdCB0byBhbHJlYWR5IGRlZmlu ZWQgYW5kIHdlbGwtdW5kZXJzdG9vZCBNUExTIGFyY2hpdGVjdHVyYWwgbWVjaGFuaXNtcyB3b3Vs ZCBncmVhdGx5IGltcHJvdmUgaXRzIHJlYWRhYmlsaXR5LiBJdCB3b3VsZCBhbHNvIGdyZWF0bHkg aGVscCB0aGUgaW1wbGVtZW50ZXJzLCBlc3BlY2lhbGx5IGlmIHRoZXkgaGF2ZSBhbHJlYWR5DQog aW1wbGVtZW50ZWQgKG9yIGNvbnNpZGVyIGltcGxlbWVudGF0aW9uIG9mKSBjb250ZXh0LXNwZWNp ZmljIGxhYmVsIHNwYWNlcyBpbiB0aGVpciBkZXZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVzaHBhc2lzXSBBdCB0aGUgdGltZSBvZiB3cml0aW5n IHRoaXMgZHJhZnQsIHRoZXJlIHdlcmUgYWxyZWFkeSBzb21lIGltcGxlbWVudGF0aW9ucyBvZiBj b250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlICwgYW5kIHNvIEkgdGhvdWdodCBhZGRpbmcgdGhv c2UgaW1wbGVtZW50YXRpb24NCiBkZXRhaWxzIHdpbGwgbm90IGJlIHVzZWZ1bCwgZXNwZWNpYWxs eSBkdXJpbmcgdGhlIFdHTEMgbGFzdCBjYWxscy4gSW1wbGVtZW50YXRpb24gbWludXRlIGRldGFp bHMgYXJlIG5vdCB3ZWxjb21lIEkgYXNzdW1lIGZyb20gdGhlIFdHTEMgcmV2aWV3cyBJIGhhdmUg Z29uZSB0aHJvdWdoIHNvIGZhci4gQnV0IGwgY2FuIHN1cmUgYWRkIHNvbWUgcmVmZXJlbmNlIHRv IFJGQzUzMzEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Im0yNDQ3NDk4MzUyMTk0NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4NTY4Njc2bTc0OTA3NDY4NzI5 OTY1MTkxNDRtc29saXN0cGFyYWdyYXBoIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj5BZGRpbmcgdGhlIHJlbGV2YW50IHJlZmVyZW5jZXMgKGluY2x1 ZGluZyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDUzMzEpIHNlZW1zIG5lY2Vzc2FyeTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPlVzaW5nIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2Vz IGFuZCBjb250ZXh0IGxhYmVscyBpbiBjb25qdW5jdGlvbiB3aXRoIGFueWNhc3QgKG9yIGFueWNh c3QtbGlrZSkgZnVuY3Rpb25hbGl0eSAmbmJzcDtpbiBNUExTIGlzIG5vdCBuZXcuIE9uZSBleGFt cGxlIChhcyBpbmRpY2F0ZWQNCiBpbiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxMjY1OS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+ DQpFcmljIFJvc2VuPHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJlzIGVt YWlsPC9zcGFuPjwvc3Bhbj48L2E+KSAmbmJzcDtpcyB0aGUgUFcgRW5kcG9pbnQgRmFzdCBGYWls dXJlIFByb3RlY3Rpb24gbWVjaGFuaXNtIGRlZmluZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTA0IiB0YXJnZXQ9Il9ibGFuayI+UkZDIDgxMDQ8L2E+LiA8 bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+W1B1c2hwYXNp c10gWWVzLCB1c2Ugb2YgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSBpcyBub3QgbmV3LiBB bmQgd29ya2luZyBpbiBKdW5pcGVyIGZvciBzb21ldGltZSBJIGhhdmUgYSBnb29kIGlkZWEgb2Yg aXRzIGFwcGxpY2F0aW9uLiBCdXQgdXNpbmcgaXQgdG8gcHJvdmlkZQ0KIGEgbWVhbnMgdG8gZG8g YW55Y2FzdCBzZWdtZW50cyB1c2luZyBNUExTIGRhdGFwbGFuZSBpcyB2ZXJ5IG11Y2ggbmV3LiBB bmQgdG8gbXkga25vd2xlZGdlIHRpbGwgZGF0ZSB0aGVyZSBpcyBubyBvdGhlciB3YXkgdG8gYWNo aWV2ZSB0aGlzIHdpdGhvdXQgcmVjdXJzaXZlIGxhYmVsIGxvb2t1cCBhbmQgY29udGV4dC1zcGVj aWZpYyBsYWJlbCBzcGFjZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGFuYWxvZ3kgbG9va3MgaW1wb3J0YW50IHRvIG1lIHNpbmNlIGFu eWNhc3QgZ3JvdXBzIGFyZSBjb21tb25seSBjb25zaWRlcmVkIGFzIGEgcHJvdGVjdGlvbiBtZWNo YW5pc20gKGFuZCBub3QganVzdCBhcyBhIGxvYWQtYmFsYW5jaW5nIG9uZSkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVzaHBhc2lzXSBBY3R1YWxseSwg YWJvdXQgdGhlIHVzZWNhc2VzIEkgaGF2ZSBkaXNjdXNzZWQgc29tZSBvZiB0aGUgb3BlcmF0b3Jz IEkgaGF2ZSBkaXNjdXNzZWQgd2l0aCBzbyBmYXIgb24gdGhpcywgYWxtb3N0IGFsbCB0aGVtIGFy ZSBhYm91dCBwb2xpY3ktYmFzZWQtcm91dGluZywNCiAmbmJzcDtsb2FkLWJhbGFuY2luZyBhbmQg cHJvdmlkaW5nIGRpc2pvaW50IHBhdGhzLiBPZmZjb3Vyc2UgZGlzam9pbnQgcGF0aHMgY2FuIGJl IHVzZWQgZm9yIHByb3RlY3Rpb24gYXMgd2VsbCBhcyBsb2FkLWJhbGFuY2luZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFsc28gdGhpbmsg dGhhdCByZWxhdGlvbnNoaXBzIGJldHdlZW4gdGhpcyBkcmFmdCBhbmQgdGhlDQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zaGVuLW1wbHMtZWdyZXNzLXBy b3RlY3Rpb24tZnJhbWV3b3JrLz9pbmNsdWRlX3RleHQ9MSIgdGFyZ2V0PSJfYmxhbmsiPg0KZWdy ZXNzIHByb3RlY3Rpb24gZnJhbWV3b3JrPC9hPiBvbmUgYXJlIHdvcnRoIGxvb2tpbmcgYXQgY2Fy ZWZ1bGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+W1B1 c2hwYXNpc10gRmlyc3QgdGhlIGVncmVzcyBwcm90ZWN0aW9uIGRyYWZ0cyBkb2VzIG5vdCBzZWVt IHRvIGhhdmUgZ29uZSB0aHJvdWdoIFdHIGFkb3B0aW9uLiBOZXh0IHRob3VnaCB0aGVzZSB0d28g ZHJhZnRzIHVzZSB0aGUgc2FtZSBtZWNoYW5pc21zLCB0aGUgZXhhY3QNCiBwcm9ibGVtIHRoZXkg dHJ5IHRvIHNvbHZlIGFyZSBub3QgZXhhY3RseSByZWxhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk5ldmVydGhlbGVzcywgSSB2YWx1ZSB5 b3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhbmQgdGhvdWdodHMgYSBsb3QsIGFuZCB0aGFuayB5 b3UgdmVyeSBtdWNoIGZvciBwcm92aWRpbmcgdGhlIGluc2lnaHRzLiBJIHdpbGwgZGVmaW5pdGVs eSB3b3JrIG9uIHRoZW0gYW5kIGFkZHJlc3MNCiB0aGVtIGluIHRoZSBuZXh0IGRyYWZ0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBv bmNlIGFnYWluIGFuZCBiZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LVB1c2hw YXNpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPk15IDJjLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNhc2hhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+T2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkNlbGw6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkVtYWlsOiZuYnNwOyZu YnNwOw0KPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8 YnI+DQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9u bHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzDQo8YnI+DQpDT05GSURFTlRJQUwg YW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcw0KPGJyPg0KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3Jt IHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFs DQo8YnI+DQphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CDE9dggemi502mbxchina_-- From nobody Wed Aug 9 23:28:54 2017 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 4831A132561 for ; Wed, 9 Aug 2017 23:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2Mciu-LL66DK for ; Wed, 9 Aug 2017 23:28:49 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 B14E7132451 for ; Wed, 9 Aug 2017 23:28:48 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id u207so53030569ywc.3; Wed, 09 Aug 2017 23:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yBBz2GB0OvAX/dSDmCwiAht0YBkdJTguWr543/kU+RU=; b=FAmq6rJ3uJvThZh6TQ0hpFumJPjIe2e+NiA1uvA/W41+lYKfa34YtPe0IrzLoqBjsf yWvlU6MLFmRJxfEmfwMXSe0kpmmmIUeLmelBLRwXFOG0dyfhja1HcY0lXO858SNGSowQ eTo2KRZKXimIjC29VECEdusnSh97Oob+vUYryoEtOPnY6rxABOi3wo6dC6HklR0kSEmb BcVaTGrZHIY5g6ebtd23srx0eKoLf4PYE1vKLpmMssUlekmsFWX2U3Pxm1cf/VNHwwKe gPwsPkkzUVzyaPuvoAGgc2mLFr15zkKfBEjiMkKWfsfZS2/drZb440FYnsSWIRLeAos/ ddYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yBBz2GB0OvAX/dSDmCwiAht0YBkdJTguWr543/kU+RU=; b=pVrd5Q+v+6ZA00Q9We2ZieRF86WlKD8lyMgNOZiinAfpyQlIo/G0RwsGNrscyHNt+s tOCZO6fWKtcyPN0SgE5q03KmLlDqr0Y44vfyUbBkHETKFfMONbBbgMwqGSOEyo/5OEWH /SD20o+q2n+RGpqFe9R7OIZE+9pBbmU2eukppTf+vGfXomgTOiDoVzaiw9nqFtWgH1R4 KmTM62nCyyMzhTy1x7FjGrIoxwXJ6zO3WOY6ZBAVT7lqQ37Mj0S59mE1825fk9cMdt7C H7+lBvfNOs3VBNjh3RrACPrpwaAF5Njax7Di2Ox3sAqs8Zfa4UVAJ/TPSyaepWqO8g2W FCNw== X-Gm-Message-State: AHYfb5igDmempEyWiz1peuSag32cr+BrawpHa72XT+ZDmcnvbfHNd5R4 L829qbh8zFtgN7UEOJjl+aeeOISXFw== X-Received: by 10.129.114.137 with SMTP id n131mr8470021ywc.22.1502346527657; Wed, 09 Aug 2017 23:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.11 with HTTP; Wed, 9 Aug 2017 23:28:47 -0700 (PDT) In-Reply-To: References: From: Pushpasis Sarkar Date: Thu, 10 Aug 2017 11:58:47 +0530 Message-ID: To: "Chengli (Distance)" Cc: "draft-ietf-spring-anycast-segment@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="001a11492ba41c5aa40556604fe9" Archived-At: Subject: Re: [spring] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBBbnljYXN0IHNlZ21lbnRz?= =?utf-8?q?_and_context-specific_label_spaces?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 06:28:53 -0000 --001a11492ba41c5aa40556604fe9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chengli, Please refer to Figure 4 in the draft. In this example CA-SRGB is 2000-3000. But let's say A1 for some hardware specific reason cannot support label range 2000-3000. So it uses a regular SRGB range of 1000-2000. If A1 would not have advertised the anycast prefix segment 100 with P-Flag 1, the topmost label in the incoming packet will be pf the next segment as 2030. As you may know already the first label lookup for any packet is always in the default-LFIB, and 2030 cannot be programmed in default-LFIB of A1. Then the packet shall have to be dropped. Instead we force the penultimate hop to not POP the topmost label but swap it with 1100. When the packet comes with 1100 as the topmost label it hits the corresponding entry in default-LFIB which pops it and launches a lookup for 2030 in a separate V-LFIB. The purpose of CA-SRGB is for the source of the traffic to derive the label to be used for the next segment following a anycast segment. The label to be used for the first anycast segment is always derived from the regular SRGB of the next hop node(s). Now question is why cannot we use CASRGB to be same as SRGB everywhere? But If that would have been possible there would have been no reason for this draft to be written in the first place. The reason that cannot be possible is different vendors support different label-ranges in their hardware. And the biggest reason all vendors cannot support the same range is because of platform-specific legacy limitations in their hardwares. For example the device used for the node A1 already reserves the label range 2000-3000 for some internal switching and cannot be made available for the regular MPLS switching and forwarding. Also as per MPLS architecture labels are of local significance and there should be no solution based on global label ranges. Hope your questions are answered now. Thanks -Pushpasis On Thu, Aug 10, 2017 at 9:22 AM, Chengli (Distance) wrote: > Hi Pushpasis, > > > > Wow, it has been two years since you made the presentation. Thank you fo= r > your slides. I have read it all. > > > > But I still have some questions. Please find them inline. > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Pushpasis Sarkar [mailto:pushpasis.ietf@gm= ail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B48=E6=9C=889=E6=97=A5= 23:31 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Chengli (Distance) > *=E4=B8=BB=E9=A2=98:* Re: =E7=AD=94=E5=A4=8D: [spring] Anycast segments a= nd context-specific label spaces > > > > Hope you have already gone through my presentation presented way back in > 2015.. If not here is the link to the same. > > > > https://www.ietf.org/proceedings/93/slides/slides-93-spring-1.pdf > > > > On Wed, Aug 9, 2017 at 8:58 PM, Pushpasis Sarkar > wrote: > > Hi Chengli, > > > > Thanks a lot for taking time to read the draft and provide comments. > Please find answers inline > > > > On Wed, Aug 9, 2017 at 2:04 PM, Chengli (Distance) > wrote: > > Hi Pushpasis, > > I am a new learner of SR. Recently, I read the draft > ,= and > I haa some questions about it. Some of them are about the algorithm, whil= e > the others are about the context. > > > > 1: If CA-SRGB need to be configured the same among all nodes, which means > all nodes can understand the label in CA-SRGB. If so, why do we need to s= et > P-Flag when the node has a different CA-SRGB range with SRGB. Without the > Anycast-SID, the node can understand CA-SRGB and process CAPSL as well. > Why do we need to keep Anycast label? To indentify the next label is a > CPASL? > > [Pushpasis] Yes this is needed for the node that originated the CAPSL. In > case the CA-SRGB is different from regular SRGB the packet must come in > with the CAPSL at the top of the stack so that it pops and does a recursi= ve > label lookup with the next label in stack.. > > > > [Cheng] If there is an action supporting to look up in V-LFIB, why not us= e > CAPSL as the key in Default LFIB directly? If so, P-Flag can be leaved 0= , > and node will receive a packet with the CAPSL as the top label no matter > it=E2=80=99s CA-SRGB is the same as SRGB or not. In default LFIB, there s= hould be > an entry for CAPSL, and it=E2=80=99s action is to look up CAPSL in V-LFIB= . I am not > sure that whether it can work or not. > > > > In this way, configuration will be much easier. > > > > In summary, in my POV, we can pop the previous anycast label so that the > node can receive the same packet no matter it=E2=80=99s CA-SRGB is the sa= me as SRGB > or not. But I suppose that there must be some reasons that you didn=E2= =80=99t > propose a solution like this. If possible, can you be kind to tell me ? > > > > I think the reason maybe: > > > > Keeping the anycast label can reduce the entries of LFIB. If we use CAPS= L > as the top label, we need to install entries for all CAPSLs in LFIB and i= n > V-LFIB as well. But if we keep Anycast label as the top label, we only > need to install one entry for Anycast label, and one entry for each CAPSL > in V-LFIB. > > > > > > 2: In section 3.2.2 of your draft, it says that > > This document introduces a separate virtual label lookup table > > (hereafter referred to as Virtual LFIB or V-LFIB), that represents a > > label space which is also separate from the actual label space > > represented by the default LFIB. The label value may be present in > > both the default and Virtual LFIB. > > > > If V-LFIB represents a label space separated from the label space > represented by LFIB, why label value may be present in both of them? If > this is right, I suppose that the reason of keeping anycast label is to > identify the next label should be looked up in V-LFIB instead of default > one. > > [Pushpasis] Theoretically all label-spaces can be independent and may hav= e > the same label programmed in them with different forwarding semantics. > However from the following text we proposed a separate V-LFIB if and only > if CA-SRGB is different from SRGB.. > > > > [Cheng] I am wondering that what is the label-space? I think it is the > range of label. But it seems not. > > > > > > " Such a device MUST add an entry in the Virtual LFIB for each unicast > > and anycast prefix segments learnt from a remote device, if and only > > if the same prefix has not been provisioned on the device. The > > device SHOULD NOT add an entry for any of the Anycast or Node prefix > > segments that it has advertised itself. However if the device has > > learnt any anycast prefix segment from a remote device, and the same > > is not provisioned on this device, the device MUST include the same > > in the Virtual LFIB table. > > " > > > > [Pushpasis] If the label at the top of the stack belongs to CA-SRGB then > it has to be for anycast prefix originated remotely and the packet actual= ly > hits an entry in the default LFIB first.. But because the label is > corresponding to an anycast prefix we install a recursive lookup with the > V-LFIB as the next table.. When the lookup for next label in stack in the > VLFIB is launched that label maybe associated with CA_SRGB or > default-SRGB.. The V-LFIB is needed to only faclitate lookup of the next > label.. In case the CA-SRGB is same as default-SRGB I hope your realize > that a recursive label is not required. It is important to realize that > CA-SRGB is invented to actually avoid recursive label lookup.. The device= s > that uses same CA-SRGB as default SRGB need not support recursive label > lookup in the hardware.. > > > > [Cheng] Yes, I can understand the logic of your solution. What if we pop > the anycast label ,and let the CAPSL to hit the entry in LFIB, and then > execute the action of looking up CAPSL in V-LFIB. Why do we need to keep > the anycast label ? This is my question. > > > > > > > > 3: I found out some strange statements in the draft: > > > > a) Page 11 > > For example, on device A1, the prefix SID 10 (originated by PE3) is > > reachable through its neighbors A3 and A4. And as per the SRGB > > advertised by A3 and A4, the labels allocated by A3 and A4 are 3030 > > and 4030 respectively > > > > I suppose that the prefix SID is 30 instead of 10. > > [Pushpasis] Yes you are right. I have already got this comment from one o= f > the WG members. I will rectifying this in next version. > > b) Page 14 > > This is because on node A1=EF=BC=88Is it A2?=EF=BC=89 the domain-wide CA-= SRGB is identical to the local SRGB provisioned on A2. > > > > c) Page 14 > > While forwarding to A2, since A2 would > > have advertised the anycast SID 100 with P-Flag (No-PHP) unset, R1 > > shall POP the incoming label 7100 before forwarding it to R1(Is it A2= ?). > > [Pushpasis] Yes you are right. I have already got this comment as well > from one of the WG members. I will rectifying this in next version. > > > > Thanks a lot for comments and thoughts. > > > > Best regards > > -Pushpasis > > > > > > Thank you for your good job! > > > > Regards, > > Cheng > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* spring [mailto:spring-bounces@ietf.org] *= =E4=BB=A3=E8=A1=A8 *Pushpasis Sarkar > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B47=E6=9C=8820=E6=97= =A5 12:35 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Alexander Vainshtein > *=E6=8A=84=E9=80=81:* mpls@ietf.org; draft-ietf-spring-anycast-segment@ie= tf.org; > draft-mpls-shen-egress-protection-framework@ietf.org; Shell Nakash < > Shell.Nakash@ecitele.com>; Michael Gorokhovsky < > Michael.Gorokhovsky@ecitele.com>; spring@ietf.org; Dmitry Valdman < > Dmitry.Valdman@ecitele.com>; Ron Sdayoor ; Rotem > Cohen > *=E4=B8=BB=E9=A2=98:* Re: [spring] Anycast segments and context-specific = label spaces > > > > Hi Sasha, > > > > Thanks a lot for taking time to read the document and providing the much > appreciated comments. Please find some comments inline. > > > > > > On Wed, Jul 19, 2017 at 12:09 AM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote: > > Hi all, > > I have read the draft > > in question, and, from my POV, it defines, under the name of Virtual LFIB= , *a > dedicated context-specific label space* (see RFC 5331 > ) in the devices that are assigned > with one or more anycast segments, and uses the labels such devices > allocate for these segments as the *context labels* identifying this > space. > > [Pushpasis] Yes, that is correct. I will add a reference to RFC 5331 in > the next version. > > > > > > If my understanding is correct: > > =C2=B7 Explicit mapping of the definitions of the draft to alread= y > defined and well-understood MPLS architectural mechanisms would greatly > improve its readability. It would also greatly help the implementers, > especially if they have already implemented (or consider implementation o= f) > context-specific label spaces in their devices > > [Pushpasis] At the time of writing this draft, there were already some > implementations of context-specific label space , and so I thought adding > those implementation details will not be useful, especially during the WG= LC > last calls. Implementation minute details are not welcome I assume from t= he > WGLC reviews I have gone through so far. But l can sure add some referenc= e > to RFC5331. > > =C2=B7 Adding the relevant references (including a normative refe= rence > to RFC 5331) seems necessary > > > > Using context-specific label spaces and context labels in conjunction wit= h > anycast (or anycast-like) functionality in MPLS is not new. One example > (as indicated in Eric Rosen=E2=80=99s email > ) is > the PW Endpoint Fast Failure Protection mechanism defined in RFC 8104 > . > > [Pushpasis] Yes, use of context-specific label space is not new. And > working in Juniper for sometime I have a good idea of its application. Bu= t > using it to provide a means to do anycast segments using MPLS dataplane i= s > very much new. And to my knowledge till date there is no other way to > achieve this without recursive label lookup and context-specific label > spaces. > > > > The analogy looks important to me since anycast groups are commonly > considered as a protection mechanism (and not just as a load-balancing on= e). > > [Pushpasis] Actually, about the usecases I have discussed some of the > operators I have discussed with so far on this, almost all them are about > policy-based-routing, load-balancing and providing disjoint paths. > Offcourse disjoint paths can be used for protection as well as > load-balancing. > > > > I also think that relationships between this draft and the egress > protection framework > > one are worth looking at carefully. > > [Pushpasis] First the egress protection drafts does not seem to have gone > through WG adoption. Next though these two drafts use the same mechanisms= , > the exact problem they try to solve are not exactly related. > > > > Nevertheless, I value your comments, suggestions and thoughts a lot, and > thank you very much for providing the insights. I will definitely work on > them and address them in the next draft. > > > > Thanks once again and best regards, > > -Pushpasis > > > > > > My 2c, > > 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. > ____________________________________________________________ > _______________ > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > > > > --001a11492ba41c5aa40556604fe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chengli,

Please refer to Figure 4 in= the draft. In this example CA-SRGB is 2000-3000. But let's say A1 for = some hardware specific reason cannot support label range 2000-3000. So it u= ses a regular SRGB range of 1000-2000. If A1 would not have advertised the = anycast prefix segment 100 with P-Flag 1, the topmost label in the incoming= packet will be pf the next segment as 2030. As you may know already the fi= rst label lookup for any packet is always in the default-LFIB, and 2030 can= not be programmed in default-LFIB of A1. Then the packet shall have to be d= ropped. Instead we force the penultimate hop to not POP the topmost label b= ut swap it with 1100. When the packet comes with 1100 as the topmost label = it hits the corresponding entry in default-LFIB which pops it and launches = a lookup for 2030 in a separate V-LFIB.=C2=A0

The = purpose of CA-SRGB is for the source of the traffic to derive the label to = be used for the next segment following a anycast segment. The label to be u= sed for the first anycast segment is always derived from the regular SRGB o= f the next hop node(s).=C2=A0

Now question is why = cannot we use CASRGB to be same as SRGB everywhere? But If that would have = been possible there would have been no reason for this draft to be written = in the first place. The reason that cannot be possible is different vendors= support different label-ranges in their hardware. And the biggest reason a= ll vendors cannot support the same range is because of platform-specific le= gacy limitations in their hardwares. For example the device used for the no= de A1 already reserves the label range 2000-3000 for some internal switchin= g and cannot be made available for the regular MPLS switching and forwardin= g. Also as per MPLS architecture labels are of local significance and there= should be no solution based on global label ranges.=C2=A0

Hope your questions are answered now.

Tha= nks
-Pushpasis


On Thu, Aug 10, 2017 at 9:22 AM, Chengli = (Distance) <chengli13@huawei.com> wrote:

Hi=C2=A0 Pushpasis,

=C2=A0

Wow, it has been two years since you ma= de the presentation.=C2=A0 Thank you for your slides. I have read it all.

=C2=A0

But I still have some questions. Please= find them inline.

=C2=A0

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA= :pushpasis.ietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017= =E5=B9=B48=E6=9C= =889=E6=97=A5 23:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Chengli (Distance) <chengli13@huawei.com>
=E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [spring] Anycas= t segments and context-specific label spaces

=C2=A0

Hope you have already gone thro= ugh my presentation presented way back in 2015.. If not here is the link to= the same. =C2=A0

=C2=A0

=C2=A0

On Wed, Aug 9, 2017 at 8:58 PM,= Pushpasis Sarkar <pushpasis.ietf@gmail.com> wrote:

Hi Chengli,

=C2=A0

Thanks a lot for taking time to= read the draft and provide comments. Please find answers inline<= /u>

=C2=A0

On Wed, Aug 9, 2017 at 2:04 PM,= Chengli (Distance) <chengli13@huawei.com> wrote:

Hi Pushpasis,

I am a new learner of = SR. Recently, I read the draft, and I haa some questions about it. Som= e of them are about the algorithm, while the others are about the context.

=C2=A0

1: If CA-SRGB need to = be configured the same among all nodes, which means all nodes can understand the label in CA-SRGB. If so, why do we need to set P-Flag when = the node has a different CA-SRGB range with SRGB. Without the Anycast-SID, = the node can understand CA-SRGB and process CAPSL as well.=C2=A0 Why do we = need to keep Anycast label? To indentify the next label is a CPASL?=C2=A0=

[Pushpasis] Yes this is needed = for the node that originated the CAPSL. In case the CA-SRGB is different fr= om regular SRGB the packet must come in with the CAPSL at the top of the st= ack so that it pops and does a recursive label lookup with the next label in stack..=C2=A0

=C2=A0

[Cheng] If there is an action su= pporting to look up in V-LFIB, why not use CAPSL as the key in Default LFIB= directly?=C2=A0 If so, P-Flag can be leaved 0, and node will receive a packet with the CAPSL as the top label no matter it=E2=80=99s CA= -SRGB is the same as SRGB or not. In default LFIB, there should be an entry= for CAPSL, and it=E2=80=99s action is to look up CAPSL in V-LFIB. I am not= sure that whether it can work or not.

=C2=A0

In this way, configuration will be much= easier.=C2=A0

=C2=A0

In summary, in my POV, we can pop the p= revious anycast label so that the node can receive the same packet no matte= r it=E2=80=99s CA-SRGB is the same as SRGB or not. But I suppose that =C2=A0there must be some reasons that you didn=E2=80=99t=C2= =A0 propose a solution like this. If possible, can you be kind to tell me ?=

=C2=A0

I think the reason maybe:

=C2=A0

Keeping the anycast label can reduce th= e entries of LFIB.=C2=A0 If we use CAPSL as the top label, we need to insta= ll entries for all CAPSLs in LFIB and in V-LFIB as well. But if we keep Anycast label as the top label,=C2=A0 we only need to insta= ll one entry for Anycast label, and one entry for each CAPSL in V-LFIB.<= /u>

=C2=A0

=C2=A0

2: In section 3.2.2 of= your draft, it says that

This document i= ntroduces a separate virtual label lookup table=

=C2=A0=C2=A0 (hereafter referred to as Virtual LFIB or V-LFIB), tha= t represents a

=C2=A0=C2=A0 label space which is also separate from the actual lab= el space

=C2=A0=C2=A0 represented by the default LFIB.=C2=A0 The label value= may be present in

=C2=A0=C2=A0 both the default and Virtual LFIB.

=C2=A0

If V-LFIB represents a= label space separated from the label space represented by LFIB, why label value may be present in both of them?=C2=A0 If this is right, I = suppose that the reason of keeping anycast label is to identify the next la= bel should be looked up in V-LFIB instead of default one.

[Pushpasis] Theoretically all l= abel-spaces can be independent and may have the same label programmed in th= em with different forwarding semantics. However from the following text we = proposed a separate V-LFIB if and only if CA-SRGB is different from SRGB..=C2=A0

= =C2=A0

[Cheng] I am wondering that what is the= label-space? I think it is the range of label. But it seems not.

=C2=A0

=C2=A0

" Such a device MUST add an entry = in the Virtual LFIB for each unicast<= /u>

=C2=A0=C2=
=A0 and anycast prefix segments learnt from a remote device, if and only=

=C2=A0=C2=
=A0 if the same prefix has not been provisioned on the device.=C2=A0 The=

=C2=A0=C2=
=A0 device SHOULD NOT add an entry for any of the Anycast or Node prefix=

=C2=A0=C2=
=A0 segments that it has advertised itself.=C2=A0 However if the device has=

=C2=A0=C2=
=A0 learnt any anycast prefix segment from a remote device, and the same=

=C2=A0=C2=
=A0 is not provisioned on this device, the device MUST include the same<=
/u>
=C2=A0=C2=
=A0 in the Virtual LFIB table.

"

=C2=A0

[Pushpasis] If the label at the= top of the stack belongs to CA-SRGB then it has to be for anycast prefix o= riginated remotely and the packet actually hits an entry in the default LFI= B first.. But because the label is corresponding to an anycast prefix we install a recursive lookup with the V-LFIB as the = next table.. When the lookup for next label in stack in the VLFIB is launch= ed that label maybe associated with CA_SRGB or default-SRGB.. The V-LFIB is= needed to only faclitate lookup of the next label..=C2=A0 In case the CA-SRGB is same as default-SRGB I ho= pe your realize that a recursive label is not required. It is important to = realize that CA-SRGB is invented to actually avoid recursive label lookup..= The devices that uses same CA-SRGB as default SRGB need not support recursive label lookup in the hardware..=C2= =A0

= =C2=A0

[Cheng] Yes, I can understand the logic= of your solution.=C2=A0 What if we pop the anycast label ,and let the CAPS= L to hit the entry in LFIB, and then execute the action of looking up CAPSL in V-LFIB.=C2=A0 Why do we need to keep the anycast la= bel ? This is my question.

=C2=A0

=C2=A0

=C2=A0

3: I found out some st= range statements in the draft:

=C2=A0

a)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Page 11= 

For example, on device A1, the p=
refix SID 10 (originated by PE3) is
=C2=A0=C2=
=A0 reachable through its neighbors A3 and A4.=C2=A0 And as per the SRGB
=C2=A0=C2=
=A0 advertised by A3 and A4, the labels allocated by A3 and A4 are 3030

=C2=A0=C2=A0 and 4030 respectively

=C2=A0<= /u>

I suppose that the prefix SID is 30 instead o= f 10.

[Pushpasis] Yes you are right. = I have already got this comment from one of the WG members. I will rectifyi= ng this in next version.=C2=A0

b)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Page 14= 

This is be=
cause on node A1=EF=BC=88Is it A2?=EF=BC=
=89 the domain-wide CA-SRGB is =
identical to the local SRGB provisioned on A2. 
=C2=A0

c)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Page 14= 

While forw=
arding to A2, since A2 would
=C2=A0 =C2=A0=C2=A0have advertised the =
anycast SID 100 with P-Flag (No-PHP) unset, R1
 =C2=A0=C2=A0=C2=A0sh=
all POP the incoming label 7100 before forwarding it to R1(Is it A2?).

[Pushpasis] Yes you are right. = I have already got this comment as well from one of the WG members. I will = rectifying this in next version.=C2=A0

=C2=A0

Thanks a lot for comments and t= houghts.=C2=A0

=C2=A0

Best regards

-Pushpa= sis

=C2=A0

=C2=A0

Thank you for your goo= d job!

=C2=A0

Regards,

Cheng

=C2=A0

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA= :spring-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Pushpasis Sarkar
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017= =E5=B9=B47=E6=9C= =8820=E6=97=A5 12:35
=E6=94=B6=E4=BB=B6=E4=BA=BA: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"\005fae\008= f6f\0096c5\009ed1",sans-serif">>
=E6=8A=84=E9=80=81: mpls@ietf.org; draft-ietf-spring-an= ycast-segment@ietf.org; draft-mpls= -shen-egress-protection-framework@ietf.org; Shell Nakash <Shell.Nakash@ecitele= .com>; Michael Gorokhovsky <Michae= l.Gorokhovsky@ecitele.com>; spring@ietf.org; Dmitry Valdman <Dmitry.Valdman@ecitele.com>; Ron Sdayoor <Ron.Sdayoor@ecitele.co= m>; Rotem Cohen <Rotem.Cohen@ecitele.co= m>
=E4=B8=BB=E9=A2=98: Re: [spring] Anycast s= egments and context-specific label spaces

=C2=A0

Hi Sasha,<= /p>

=C2=A0

Thanks a lot for taking time to= read the document and providing the much appreciated comments. Please find= some comments inline.

=C2=A0

=C2=A0

On Wed, Jul 19, 2017 at 12:09 A= M, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Hi all,

I have read the draft in question, and, from my POV, it defines, under the name of Virt= ual LFIB, =C2=A0a dedicated context-specific label space (see RFC 5331<= /a>) =C2=A0in the devices that are assigned with one or more anycast segmen= ts, and uses the labels such devices allocate for these segments as the context labels identifying this space.

[Pushpasis] Yes, that is correc= t. I will add a reference to RFC 5331 in the next version.

=C2=A0

=C2=A0

If my understanding is correct:=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Explicit mapping of the definitions of the draf= t to already defined and well-understood MPLS architectural mechanisms woul= d greatly improve its readability. It would also greatly help the implement= ers, especially if they have already implemented (or consider implementation of) context-specific label spaces = in their devices

[Pushpasis] At the time of writ= ing this draft, there were already some implementations of context-specific= label space , and so I thought adding those implementation details will not be useful, especially during the WGLC last calls. Impleme= ntation minute details are not welcome I assume from the WGLC reviews I hav= e gone through so far. But l can sure add some reference to RFC5331.=

[Pushpasis] Yes, use of context= -specific label space is not new. And working in Juniper for sometime I hav= e a good idea of its application. But using it to provide a means to do anycast segments using MPLS dataplane is very much new. And = to my knowledge till date there is no other way to achieve this without rec= ursive label lookup and context-specific label spaces.=

=C2=A0

The analogy looks important to = me since anycast groups are commonly considered as a protection mechanism (= and not just as a load-balancing one).

[Pushpasis] Actually, about the= usecases I have discussed some of the operators I have discussed with so f= ar on this, almost all them are about policy-based-routing, =C2=A0load-balancing and providing disjoint paths. Offcourse disjoint path= s can be used for protection as well as load-balancing.

=C2=A0

[Pushpasis] First the egress pr= otection drafts does not seem to have gone through WG adoption. Next though= these two drafts use the same mechanisms, the exact problem they try to solve are not exactly related.

=C2=A0

Nevertheless, I value your comm= ents, suggestions and thoughts a lot, and thank you very much for providing= the insights. I will definitely work on them and address them in the next draft.

=C2=A0

Thanks once again and best rega= rds,

-Pushpasis=

=C2=A0

=C2=A0

My 2c,

Sasha

=C2=A0

Office: +972-39266302=

Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexa= nder.Vainshtein@ecitele.com

=C2=A0


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

=
_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring<= /p>

=C2=A0

=C2=A0

=C2=A0


--001a11492ba41c5aa40556604fe9-- From nobody Thu Aug 10 00:29:17 2017 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 803A413262A for ; Thu, 10 Aug 2017 00:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fNKm8Ta6tEYO for ; Thu, 10 Aug 2017 00:29:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F092132628 for ; Thu, 10 Aug 2017 00:29:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMH87234; Thu, 10 Aug 2017 07:29:07 +0000 (GMT) Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 10 Aug 2017 08:29:04 +0100 Received: from DGGEMI502-MBX.china.huawei.com ([169.254.4.150]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Thu, 10 Aug 2017 15:28:57 +0800 From: "Chengli (Distance)" To: Pushpasis Sarkar CC: "draft-ietf-spring-anycast-segment@ietf.org" , "spring@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IFtzcHJpbmddIEFueWNhc3Qgc2VnbWVudHMgYW5k?= =?utf-8?Q?_context-specific_label_spaces?= Thread-Index: AdMAXJkJ1clImMhlSCmQwtRBBfPkPwAcdcyABAO96EAAAPCngAAAFegAACfggdD//7uzgP//b1cQ Date: Thu, 10 Aug 2017 07:28:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE4Ddggemi502mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.598C0B44.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.150, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c124ad21468b1fcd09a2ae4406dcbc7c Archived-At: Subject: [spring] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIEFueWNhc3Qg?= =?utf-8?q?segments_and_context-specific_label_spaces?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 07:29:17 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE4Ddggemi502mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUHVzaHBhc2lzLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgYW5zd2VyLCBub3cgSSB1bmRlcnN0 YW5kIHRoZSByZWFzb24gb2YgaXQuIFBsZWFzZSByZWFkIGRldGFpbGVkIHJlcGx5IGlubGluZS4N Cg0KDQrlj5Hku7bkuro6IFB1c2hwYXNpcyBTYXJrYXIgW21haWx0bzpwdXNocGFzaXMuaWV0ZkBn bWFpbC5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ45pyIMTDml6UgMTQ6MjkNCuaUtuS7tuS6 ujogQ2hlbmdsaSAoRGlzdGFuY2UpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT4NCuaKhOmAgTogZHJh ZnQtaWV0Zi1zcHJpbmctYW55Y2FzdC1zZWdtZW50QGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmcN CuS4u+mimDogUmU6IOetlOWkjTog562U5aSNOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFu ZCBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcw0KDQpIaSBDaGVuZ2xpLA0KDQpQbGVhc2Ug cmVmZXIgdG8gRmlndXJlIDQgaW4gdGhlIGRyYWZ0LiBJbiB0aGlzIGV4YW1wbGUgQ0EtU1JHQiBp cyAyMDAwLTMwMDAuIEJ1dCBsZXQncyBzYXkgQTEgZm9yIHNvbWUgaGFyZHdhcmUgc3BlY2lmaWMg cmVhc29uIGNhbm5vdCBzdXBwb3J0IGxhYmVsIHJhbmdlIDIwMDAtMzAwMC4gU28gaXQgdXNlcyBh IHJlZ3VsYXIgU1JHQiByYW5nZSBvZiAxMDAwLTIwMDAuIElmIEExIHdvdWxkIG5vdCBoYXZlIGFk dmVydGlzZWQgdGhlIGFueWNhc3QgcHJlZml4IHNlZ21lbnQgMTAwIHdpdGggUC1GbGFnIDEsIHRo ZSB0b3Btb3N0IGxhYmVsIGluIHRoZSBpbmNvbWluZyBwYWNrZXQgd2lsbCBiZSBwZiB0aGUgbmV4 dCBzZWdtZW50IGFzIDIwMzAuIEFzIHlvdSBtYXkga25vdyBhbHJlYWR5IHRoZSBmaXJzdCBsYWJl bCBsb29rdXAgZm9yIGFueSBwYWNrZXQgaXMgYWx3YXlzIGluIHRoZSBkZWZhdWx0LUxGSUIsIGFu ZCAyMDMwIGNhbm5vdCBiZSBwcm9ncmFtbWVkIGluIGRlZmF1bHQtTEZJQiBvZiBBMS4gVGhlbiB0 aGUgcGFja2V0IHNoYWxsIGhhdmUgdG8gYmUgZHJvcHBlZC4NCg0KW0NoZW5nXVNvIHRoaXMgaXMg dGhlIG1haW4gcmVhc29uIG9mIHdoeSB3ZSBuZWVkIHRvIGtlZXAgYW55Y2FzdCBsYWJlbC4gQmVj YXVzZSAgdGhlIENBUFNMIGNhbiBub3QgYmUgcHJvZ3JhbW1lZCBpbiBkZWZhdWx0LUxGSUIsIGlm IHRoZSBub2RlIGNhbiBub3Qgc3VwcG9ydCB0aGUgbGFiZWwgcmFuZ2UuIEl0IHJlYWxseSBtYWtl cyBzZW5zZS4gS2VlcGluZyB0aGUgQVBTTCBhcyB0aGUgdG9wIGxhYmVsIGlzIGEgZ29vZCB3YXkg dG8gc29sdmUgdGhpcyBwcm9ibGVtISBBd2Vzb21lIQ0KDQpCdXQgSSBoYXZlIGFub3RoZXIgcXVl c3Rpb246IEluIHRoaXMgY2FzZSwgcmFuZ2UgMjAwMC0zMDAwIGNhbiBub3QgYmUgc3VwcG9ydGVk IGJ5IEExLCBzbyB3aHkgaXQgY2FuIGJlIHVzZWQgaW4gVi1MRklCPyAgICBBY3R1YWxseSwgSSBh bSBjdXJpb3VzIGFib3V0IHRoZSBoYXJkd2FyZSBzcGVjaWZpYyByZWFzb24sIGFuZCB3aHkgdGhp cyByZWFzb24gZG9lcyBub3QgYWZmZWN0IFYtTEZJQi4NCg0KDQpJbnN0ZWFkIHdlIGZvcmNlIHRo ZSBwZW51bHRpbWF0ZSBob3AgdG8gbm90IFBPUCB0aGUgdG9wbW9zdCBsYWJlbCBidXQgc3dhcCBp dCB3aXRoIDExMDAuIFdoZW4gdGhlIHBhY2tldCBjb21lcyB3aXRoIDExMDAgYXMgdGhlIHRvcG1v c3QgbGFiZWwgaXQgaGl0cyB0aGUgY29ycmVzcG9uZGluZyBlbnRyeSBpbiBkZWZhdWx0LUxGSUIg d2hpY2ggcG9wcyBpdCBhbmQgbGF1bmNoZXMgYSBsb29rdXAgZm9yIDIwMzAgaW4gYSBzZXBhcmF0 ZSBWLUxGSUIuDQpbQ2hlbmddIFllcy4NCg0KVGhlIHB1cnBvc2Ugb2YgQ0EtU1JHQiBpcyBmb3Ig dGhlIHNvdXJjZSBvZiB0aGUgdHJhZmZpYyB0byBkZXJpdmUgdGhlIGxhYmVsIHRvIGJlIHVzZWQg Zm9yIHRoZSBuZXh0IHNlZ21lbnQgZm9sbG93aW5nIGEgYW55Y2FzdCBzZWdtZW50LiBUaGUgbGFi ZWwgdG8gYmUgdXNlZCBmb3IgdGhlIGZpcnN0IGFueWNhc3Qgc2VnbWVudCBpcyBhbHdheXMgZGVy aXZlZCBmcm9tIHRoZSByZWd1bGFyIFNSR0Igb2YgdGhlIG5leHQgaG9wIG5vZGUocykuDQpbQ2hl bmddIFllcywgdGhpcyBpcyBhIHJlYWxseSBhbWF6aW5nIGlkZWEhDQoNCk5vdyBxdWVzdGlvbiBp cyB3aHkgY2Fubm90IHdlIHVzZSBDQVNSR0IgdG8gYmUgc2FtZSBhcyBTUkdCIGV2ZXJ5d2hlcmU/ IEJ1dCBJZiB0aGF0IHdvdWxkIGhhdmUgYmVlbiBwb3NzaWJsZSB0aGVyZSB3b3VsZCBoYXZlIGJl ZW4gbm8gcmVhc29uIGZvciB0aGlzIGRyYWZ0IHRvIGJlIHdyaXR0ZW4gaW4gdGhlIGZpcnN0IHBs YWNlLiBUaGUgcmVhc29uIHRoYXQgY2Fubm90IGJlIHBvc3NpYmxlIGlzIGRpZmZlcmVudCB2ZW5k b3JzIHN1cHBvcnQgZGlmZmVyZW50IGxhYmVsLXJhbmdlcyBpbiB0aGVpciBoYXJkd2FyZS4gQW5k IHRoZSBiaWdnZXN0IHJlYXNvbiBhbGwgdmVuZG9ycyBjYW5ub3Qgc3VwcG9ydCB0aGUgc2FtZSBy YW5nZSBpcyBiZWNhdXNlIG9mIHBsYXRmb3JtLXNwZWNpZmljIGxlZ2FjeSBsaW1pdGF0aW9ucyBp biB0aGVpciBoYXJkd2FyZXMuIEZvciBleGFtcGxlIHRoZSBkZXZpY2UgdXNlZCBmb3IgdGhlIG5v ZGUgQTEgYWxyZWFkeSByZXNlcnZlcyB0aGUgbGFiZWwgcmFuZ2UgMjAwMC0zMDAwIGZvciBzb21l IGludGVybmFsIHN3aXRjaGluZyBhbmQgY2Fubm90IGJlIG1hZGUgYXZhaWxhYmxlIGZvciB0aGUg cmVndWxhciBNUExTIHN3aXRjaGluZyBhbmQgZm9yd2FyZGluZy4gQWxzbyBhcyBwZXIgTVBMUyBh cmNoaXRlY3R1cmUgbGFiZWxzIGFyZSBvZiBsb2NhbCBzaWduaWZpY2FuY2UgYW5kIHRoZXJlIHNo b3VsZCBiZSBubyBzb2x1dGlvbiBiYXNlZCBvbiBnbG9iYWwgbGFiZWwgcmFuZ2VzLg0KDQoNCltD aGVuZ11ObywgSSB1bmRlcnN0YW5kIHRoZSByZWFzb24gdG90YWxseS4gWW91ciB3b3JrIGlzIHJl YWxseSB1c2VmdWwuIEdvb2Qgam9iIQ0KDQpIb3BlIHlvdXIgcXVlc3Rpb25zIGFyZSBhbnN3ZXJl ZCBub3cuDQoNClRoYW5rcw0KLVB1c2hwYXNpcw0KDQoNCk9uIFRodSwgQXVnIDEwLCAyMDE3IGF0 IDk6MjIgQU0sIENoZW5nbGkgKERpc3RhbmNlKSA8Y2hlbmdsaTEzQGh1YXdlaS5jb208bWFpbHRv OmNoZW5nbGkxM0BodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSAgUHVzaHBhc2lzLA0KDQpXb3csIGl0 IGhhcyBiZWVuIHR3byB5ZWFycyBzaW5jZSB5b3UgbWFkZSB0aGUgcHJlc2VudGF0aW9uLiAgVGhh bmsgeW91IGZvciB5b3VyIHNsaWRlcy4gSSBoYXZlIHJlYWQgaXQgYWxsLg0KDQpCdXQgSSBzdGls bCBoYXZlIHNvbWUgcXVlc3Rpb25zLiBQbGVhc2UgZmluZCB0aGVtIGlubGluZS4NCg0KDQrlj5Hk u7bkuro6IFB1c2hwYXNpcyBTYXJrYXIgW21haWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOnB1c2hwYXNpcy5pZXRmQGdtYWlsLmNvbT5dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ4 5pyIOeaXpSAyMzozMQ0K5pS25Lu25Lq6OiBDaGVuZ2xpIChEaXN0YW5jZSkgPGNoZW5nbGkxM0Bo dWF3ZWkuY29tPG1haWx0bzpjaGVuZ2xpMTNAaHVhd2VpLmNvbT4+DQrkuLvpopg6IFJlOiDnrZTl pI06IFtzcHJpbmddIEFueWNhc3Qgc2VnbWVudHMgYW5kIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwg c3BhY2VzDQoNCkhvcGUgeW91IGhhdmUgYWxyZWFkeSBnb25lIHRocm91Z2ggbXkgcHJlc2VudGF0 aW9uIHByZXNlbnRlZCB3YXkgYmFjayBpbiAyMDE1Li4gSWYgbm90IGhlcmUgaXMgdGhlIGxpbmsg dG8gdGhlIHNhbWUuDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkzL3NsaWRl cy9zbGlkZXMtOTMtc3ByaW5nLTEucGRmDQoNCk9uIFdlZCwgQXVnIDksIDIwMTcgYXQgODo1OCBQ TSwgUHVzaHBhc2lzIFNhcmthciA8cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPG1haWx0bzpwdXNo cGFzaXMuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkhpIENoZW5nbGksDQoNClRoYW5rcyBhIGxv dCBmb3IgdGFraW5nIHRpbWUgdG8gcmVhZCB0aGUgZHJhZnQgYW5kIHByb3ZpZGUgY29tbWVudHMu IFBsZWFzZSBmaW5kIGFuc3dlcnMgaW5saW5lDQoNCk9uIFdlZCwgQXVnIDksIDIwMTcgYXQgMjow NCBQTSwgQ2hlbmdsaSAoRGlzdGFuY2UpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbTxtYWlsdG86Y2hl bmdsaTEzQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIFB1c2hwYXNpcywNCkkgYW0gYSBuZXcgbGVh cm5lciBvZiBTUi4gUmVjZW50bHksIEkgcmVhZCB0aGUgZHJhZnQ8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLW1wbHMtYW55Y2FzdC1zZWdtZW50cy0wMT4sIGFu ZCBJIGhhYSBzb21lIHF1ZXN0aW9ucyBhYm91dCBpdC4gU29tZSBvZiB0aGVtIGFyZSBhYm91dCB0 aGUgYWxnb3JpdGhtLCB3aGlsZSB0aGUgb3RoZXJzIGFyZSBhYm91dCB0aGUgY29udGV4dC4NCg0K MTogSWYgQ0EtU1JHQiBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgdGhlIHNhbWUgYW1vbmcgYWxsIG5v ZGVzLCB3aGljaCBtZWFucyBhbGwgbm9kZXMgY2FuIHVuZGVyc3RhbmQgdGhlIGxhYmVsIGluIENB LVNSR0IuIElmIHNvLCB3aHkgZG8gd2UgbmVlZCB0byBzZXQgUC1GbGFnIHdoZW4gdGhlIG5vZGUg aGFzIGEgZGlmZmVyZW50IENBLVNSR0IgcmFuZ2Ugd2l0aCBTUkdCLiBXaXRob3V0IHRoZSBBbnlj YXN0LVNJRCwgdGhlIG5vZGUgY2FuIHVuZGVyc3RhbmQgQ0EtU1JHQiBhbmQgcHJvY2VzcyBDQVBT TCBhcyB3ZWxsLiAgV2h5IGRvIHdlIG5lZWQgdG8ga2VlcCBBbnljYXN0IGxhYmVsPyBUbyBpbmRl bnRpZnkgdGhlIG5leHQgbGFiZWwgaXMgYSBDUEFTTD8NCltQdXNocGFzaXNdIFllcyB0aGlzIGlz IG5lZWRlZCBmb3IgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVkIHRoZSBDQVBTTC4gSW4gY2FzZSB0 aGUgQ0EtU1JHQiBpcyBkaWZmZXJlbnQgZnJvbSByZWd1bGFyIFNSR0IgdGhlIHBhY2tldCBtdXN0 IGNvbWUgaW4gd2l0aCB0aGUgQ0FQU0wgYXQgdGhlIHRvcCBvZiB0aGUgc3RhY2sgc28gdGhhdCBp dCBwb3BzIGFuZCBkb2VzIGEgcmVjdXJzaXZlIGxhYmVsIGxvb2t1cCB3aXRoIHRoZSBuZXh0IGxh YmVsIGluIHN0YWNrLi4NCg0KW0NoZW5nXSBJZiB0aGVyZSBpcyBhbiBhY3Rpb24gc3VwcG9ydGlu ZyB0byBsb29rIHVwIGluIFYtTEZJQiwgd2h5IG5vdCB1c2UgQ0FQU0wgYXMgdGhlIGtleSBpbiBE ZWZhdWx0IExGSUIgZGlyZWN0bHk/ICBJZiBzbywgUC1GbGFnIGNhbiBiZSBsZWF2ZWQgMCwgYW5k IG5vZGUgd2lsbCByZWNlaXZlIGEgcGFja2V0IHdpdGggdGhlIENBUFNMIGFzIHRoZSB0b3AgbGFi ZWwgbm8gbWF0dGVyIGl04oCZcyBDQS1TUkdCIGlzIHRoZSBzYW1lIGFzIFNSR0Igb3Igbm90LiBJ biBkZWZhdWx0IExGSUIsIHRoZXJlIHNob3VsZCBiZSBhbiBlbnRyeSBmb3IgQ0FQU0wsIGFuZCBp dOKAmXMgYWN0aW9uIGlzIHRvIGxvb2sgdXAgQ0FQU0wgaW4gVi1MRklCLiBJIGFtIG5vdCBzdXJl IHRoYXQgd2hldGhlciBpdCBjYW4gd29yayBvciBub3QuDQoNCkluIHRoaXMgd2F5LCBjb25maWd1 cmF0aW9uIHdpbGwgYmUgbXVjaCBlYXNpZXIuDQoNCkluIHN1bW1hcnksIGluIG15IFBPViwgd2Ug Y2FuIHBvcCB0aGUgcHJldmlvdXMgYW55Y2FzdCBsYWJlbCBzbyB0aGF0IHRoZSBub2RlIGNhbiBy ZWNlaXZlIHRoZSBzYW1lIHBhY2tldCBubyBtYXR0ZXIgaXTigJlzIENBLVNSR0IgaXMgdGhlIHNh bWUgYXMgU1JHQiBvciBub3QuIEJ1dCBJIHN1cHBvc2UgdGhhdCAgdGhlcmUgbXVzdCBiZSBzb21l IHJlYXNvbnMgdGhhdCB5b3UgZGlkbuKAmXQgIHByb3Bvc2UgYSBzb2x1dGlvbiBsaWtlIHRoaXMu IElmIHBvc3NpYmxlLCBjYW4geW91IGJlIGtpbmQgdG8gdGVsbCBtZSA/DQoNCkkgdGhpbmsgdGhl IHJlYXNvbiBtYXliZToNCg0KS2VlcGluZyB0aGUgYW55Y2FzdCBsYWJlbCBjYW4gcmVkdWNlIHRo ZSBlbnRyaWVzIG9mIExGSUIuICBJZiB3ZSB1c2UgQ0FQU0wgYXMgdGhlIHRvcCBsYWJlbCwgd2Ug bmVlZCB0byBpbnN0YWxsIGVudHJpZXMgZm9yIGFsbCBDQVBTTHMgaW4gTEZJQiBhbmQgaW4gVi1M RklCIGFzIHdlbGwuIEJ1dCBpZiB3ZSBrZWVwIEFueWNhc3QgbGFiZWwgYXMgdGhlIHRvcCBsYWJl bCwgIHdlIG9ubHkgbmVlZCB0byBpbnN0YWxsIG9uZSBlbnRyeSBmb3IgQW55Y2FzdCBsYWJlbCwg YW5kIG9uZSBlbnRyeSBmb3IgZWFjaCBDQVBTTCBpbiBWLUxGSUIuDQoNCg0KMjogSW4gc2VjdGlv biAzLjIuMiBvZiB5b3VyIGRyYWZ0LCBpdCBzYXlzIHRoYXQNClRoaXMgZG9jdW1lbnQgaW50cm9k dWNlcyBhIHNlcGFyYXRlIHZpcnR1YWwgbGFiZWwgbG9va3VwIHRhYmxlDQogICAoaGVyZWFmdGVy IHJlZmVycmVkIHRvIGFzIFZpcnR1YWwgTEZJQiBvciBWLUxGSUIpLCB0aGF0IHJlcHJlc2VudHMg YQ0KICAgbGFiZWwgc3BhY2Ugd2hpY2ggaXMgYWxzbyBzZXBhcmF0ZSBmcm9tIHRoZSBhY3R1YWwg bGFiZWwgc3BhY2UNCiAgIHJlcHJlc2VudGVkIGJ5IHRoZSBkZWZhdWx0IExGSUIuICBUaGUgbGFi ZWwgdmFsdWUgbWF5IGJlIHByZXNlbnQgaW4NCiAgIGJvdGggdGhlIGRlZmF1bHQgYW5kIFZpcnR1 YWwgTEZJQi4NCg0KSWYgVi1MRklCIHJlcHJlc2VudHMgYSBsYWJlbCBzcGFjZSBzZXBhcmF0ZWQg ZnJvbSB0aGUgbGFiZWwgc3BhY2UgcmVwcmVzZW50ZWQgYnkgTEZJQiwgd2h5IGxhYmVsIHZhbHVl IG1heSBiZSBwcmVzZW50IGluIGJvdGggb2YgdGhlbT8gIElmIHRoaXMgaXMgcmlnaHQsIEkgc3Vw cG9zZSB0aGF0IHRoZSByZWFzb24gb2Yga2VlcGluZyBhbnljYXN0IGxhYmVsIGlzIHRvIGlkZW50 aWZ5IHRoZSBuZXh0IGxhYmVsIHNob3VsZCBiZSBsb29rZWQgdXAgaW4gVi1MRklCIGluc3RlYWQg b2YgZGVmYXVsdCBvbmUuDQpbUHVzaHBhc2lzXSBUaGVvcmV0aWNhbGx5IGFsbCBsYWJlbC1zcGFj ZXMgY2FuIGJlIGluZGVwZW5kZW50IGFuZCBtYXkgaGF2ZSB0aGUgc2FtZSBsYWJlbCBwcm9ncmFt bWVkIGluIHRoZW0gd2l0aCBkaWZmZXJlbnQgZm9yd2FyZGluZyBzZW1hbnRpY3MuIEhvd2V2ZXIg ZnJvbSB0aGUgZm9sbG93aW5nIHRleHQgd2UgcHJvcG9zZWQgYSBzZXBhcmF0ZSBWLUxGSUIgaWYg YW5kIG9ubHkgaWYgQ0EtU1JHQiBpcyBkaWZmZXJlbnQgZnJvbSBTUkdCLi4NCg0KW0NoZW5nXSBJ IGFtIHdvbmRlcmluZyB0aGF0IHdoYXQgaXMgdGhlIGxhYmVsLXNwYWNlPyBJIHRoaW5rIGl0IGlz IHRoZSByYW5nZSBvZiBsYWJlbC4gQnV0IGl0IHNlZW1zIG5vdC4NCg0KDQoiIFN1Y2ggYSBkZXZp Y2UgTVVTVCBhZGQgYW4gZW50cnkgaW4gdGhlIFZpcnR1YWwgTEZJQiBmb3IgZWFjaCB1bmljYXN0 DQoNCiAgIGFuZCBhbnljYXN0IHByZWZpeCBzZWdtZW50cyBsZWFybnQgZnJvbSBhIHJlbW90ZSBk ZXZpY2UsIGlmIGFuZCBvbmx5DQoNCiAgIGlmIHRoZSBzYW1lIHByZWZpeCBoYXMgbm90IGJlZW4g cHJvdmlzaW9uZWQgb24gdGhlIGRldmljZS4gIFRoZQ0KDQogICBkZXZpY2UgU0hPVUxEIE5PVCBh ZGQgYW4gZW50cnkgZm9yIGFueSBvZiB0aGUgQW55Y2FzdCBvciBOb2RlIHByZWZpeA0KDQogICBz ZWdtZW50cyB0aGF0IGl0IGhhcyBhZHZlcnRpc2VkIGl0c2VsZi4gIEhvd2V2ZXIgaWYgdGhlIGRl dmljZSBoYXMNCg0KICAgbGVhcm50IGFueSBhbnljYXN0IHByZWZpeCBzZWdtZW50IGZyb20gYSBy ZW1vdGUgZGV2aWNlLCBhbmQgdGhlIHNhbWUNCg0KICAgaXMgbm90IHByb3Zpc2lvbmVkIG9uIHRo aXMgZGV2aWNlLCB0aGUgZGV2aWNlIE1VU1QgaW5jbHVkZSB0aGUgc2FtZQ0KDQogICBpbiB0aGUg VmlydHVhbCBMRklCIHRhYmxlLg0KIg0KDQpbUHVzaHBhc2lzXSBJZiB0aGUgbGFiZWwgYXQgdGhl IHRvcCBvZiB0aGUgc3RhY2sgYmVsb25ncyB0byBDQS1TUkdCIHRoZW4gaXQgaGFzIHRvIGJlIGZv ciBhbnljYXN0IHByZWZpeCBvcmlnaW5hdGVkIHJlbW90ZWx5IGFuZCB0aGUgcGFja2V0IGFjdHVh bGx5IGhpdHMgYW4gZW50cnkgaW4gdGhlIGRlZmF1bHQgTEZJQiBmaXJzdC4uIEJ1dCBiZWNhdXNl IHRoZSBsYWJlbCBpcyBjb3JyZXNwb25kaW5nIHRvIGFuIGFueWNhc3QgcHJlZml4IHdlIGluc3Rh bGwgYSByZWN1cnNpdmUgbG9va3VwIHdpdGggdGhlIFYtTEZJQiBhcyB0aGUgbmV4dCB0YWJsZS4u IFdoZW4gdGhlIGxvb2t1cCBmb3IgbmV4dCBsYWJlbCBpbiBzdGFjayBpbiB0aGUgVkxGSUIgaXMg bGF1bmNoZWQgdGhhdCBsYWJlbCBtYXliZSBhc3NvY2lhdGVkIHdpdGggQ0FfU1JHQiBvciBkZWZh dWx0LVNSR0IuLiBUaGUgVi1MRklCIGlzIG5lZWRlZCB0byBvbmx5IGZhY2xpdGF0ZSBsb29rdXAg b2YgdGhlIG5leHQgbGFiZWwuLiAgSW4gY2FzZSB0aGUgQ0EtU1JHQiBpcyBzYW1lIGFzIGRlZmF1 bHQtU1JHQiBJIGhvcGUgeW91ciByZWFsaXplIHRoYXQgYSByZWN1cnNpdmUgbGFiZWwgaXMgbm90 IHJlcXVpcmVkLiBJdCBpcyBpbXBvcnRhbnQgdG8gcmVhbGl6ZSB0aGF0IENBLVNSR0IgaXMgaW52 ZW50ZWQgdG8gYWN0dWFsbHkgYXZvaWQgcmVjdXJzaXZlIGxhYmVsIGxvb2t1cC4uIFRoZSBkZXZp Y2VzIHRoYXQgdXNlcyBzYW1lIENBLVNSR0IgYXMgZGVmYXVsdCBTUkdCIG5lZWQgbm90IHN1cHBv cnQgcmVjdXJzaXZlIGxhYmVsIGxvb2t1cCBpbiB0aGUgaGFyZHdhcmUuLg0KDQpbQ2hlbmddIFll cywgSSBjYW4gdW5kZXJzdGFuZCB0aGUgbG9naWMgb2YgeW91ciBzb2x1dGlvbi4gIFdoYXQgaWYg d2UgcG9wIHRoZSBhbnljYXN0IGxhYmVsICxhbmQgbGV0IHRoZSBDQVBTTCB0byBoaXQgdGhlIGVu dHJ5IGluIExGSUIsIGFuZCB0aGVuIGV4ZWN1dGUgdGhlIGFjdGlvbiBvZiBsb29raW5nIHVwIENB UFNMIGluIFYtTEZJQi4gIFdoeSBkbyB3ZSBuZWVkIHRvIGtlZXAgdGhlIGFueWNhc3QgbGFiZWwg PyBUaGlzIGlzIG15IHF1ZXN0aW9uLg0KDQoNCg0KMzogSSBmb3VuZCBvdXQgc29tZSBzdHJhbmdl IHN0YXRlbWVudHMgaW4gdGhlIGRyYWZ0Og0KDQoNCmEpICAgICAgIFBhZ2UgMTENCg0KRm9yIGV4 YW1wbGUsIG9uIGRldmljZSBBMSwgdGhlIHByZWZpeCBTSUQgMTAgKG9yaWdpbmF0ZWQgYnkgUEUz KSBpcw0KDQogICByZWFjaGFibGUgdGhyb3VnaCBpdHMgbmVpZ2hib3JzIEEzIGFuZCBBNC4gIEFu ZCBhcyBwZXIgdGhlIFNSR0INCg0KICAgYWR2ZXJ0aXNlZCBieSBBMyBhbmQgQTQsIHRoZSBsYWJl bHMgYWxsb2NhdGVkIGJ5IEEzIGFuZCBBNCBhcmUgMzAzMA0KICAgYW5kIDQwMzAgcmVzcGVjdGl2 ZWx5DQoNCkkgc3VwcG9zZSB0aGF0IHRoZSBwcmVmaXggU0lEIGlzIDMwIGluc3RlYWQgb2YgMTAu DQpbUHVzaHBhc2lzXSBZZXMgeW91IGFyZSByaWdodC4gSSBoYXZlIGFscmVhZHkgZ290IHRoaXMg Y29tbWVudCBmcm9tIG9uZSBvZiB0aGUgV0cgbWVtYmVycy4gSSB3aWxsIHJlY3RpZnlpbmcgdGhp cyBpbiBuZXh0IHZlcnNpb24uDQoNCmIpICAgICAgIFBhZ2UgMTQNCg0KVGhpcyBpcyBiZWNhdXNl IG9uIG5vZGUgQTHvvIhJcyBpdCBBMj/vvIkgdGhlIGRvbWFpbi13aWRlIENBLVNSR0IgaXMgaWRl bnRpY2FsIHRvIHRoZSBsb2NhbCBTUkdCIHByb3Zpc2lvbmVkIG9uIEEyLg0KDQoNCg0KYykgICAg ICAgUGFnZSAxNA0KDQpXaGlsZSBmb3J3YXJkaW5nIHRvIEEyLCBzaW5jZSBBMiB3b3VsZA0KDQog ICAgaGF2ZSBhZHZlcnRpc2VkIHRoZSBhbnljYXN0IFNJRCAxMDAgd2l0aCBQLUZsYWcgKE5vLVBI UCkgdW5zZXQsIFIxDQoNCiAgICBzaGFsbCBQT1AgdGhlIGluY29taW5nIGxhYmVsIDcxMDAgYmVm b3JlIGZvcndhcmRpbmcgaXQgdG8gUjEoSXMgaXQgQTI/KS4NCltQdXNocGFzaXNdIFllcyB5b3Ug YXJlIHJpZ2h0LiBJIGhhdmUgYWxyZWFkeSBnb3QgdGhpcyBjb21tZW50IGFzIHdlbGwgZnJvbSBv bmUgb2YgdGhlIFdHIG1lbWJlcnMuIEkgd2lsbCByZWN0aWZ5aW5nIHRoaXMgaW4gbmV4dCB2ZXJz aW9uLg0KDQpUaGFua3MgYSBsb3QgZm9yIGNvbW1lbnRzIGFuZCB0aG91Z2h0cy4NCg0KQmVzdCBy ZWdhcmRzDQotUHVzaHBhc2lzDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGdvb2Qgam9iIQ0KDQpS ZWdhcmRzLA0KQ2hlbmcNCg0KDQrlj5Hku7bkuro6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz5dIOS7o+ihqCBQdXNo cGFzaXMgU2Fya2FyDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ35pyIMjDml6UgMTI6MzUNCuaUtuS7 tuS6ujogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQrmioTpgIE6IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLXNwcmluZy1hbnlj YXN0LXNlZ21lbnRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5nLWFueWNhc3Qtc2Vn bWVudEBpZXRmLm9yZz47IGRyYWZ0LW1wbHMtc2hlbi1lZ3Jlc3MtcHJvdGVjdGlvbi1mcmFtZXdv cmtAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LW1wbHMtc2hlbi1lZ3Jlc3MtcHJvdGVjdGlvbi1mcmFt ZXdvcmtAaWV0Zi5vcmc+OyBTaGVsbCBOYWthc2ggPFNoZWxsLk5ha2FzaEBlY2l0ZWxlLmNvbTxt YWlsdG86U2hlbGwuTmFrYXNoQGVjaXRlbGUuY29tPj47IE1pY2hhZWwgR29yb2tob3Zza3kgPE1p Y2hhZWwuR29yb2tob3Zza3lAZWNpdGVsZS5jb208bWFpbHRvOk1pY2hhZWwuR29yb2tob3Zza3lA ZWNpdGVsZS5jb20+Pjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBE bWl0cnkgVmFsZG1hbiA8RG1pdHJ5LlZhbGRtYW5AZWNpdGVsZS5jb208bWFpbHRvOkRtaXRyeS5W YWxkbWFuQGVjaXRlbGUuY29tPj47IFJvbiBTZGF5b29yIDxSb24uU2RheW9vckBlY2l0ZWxlLmNv bTxtYWlsdG86Um9uLlNkYXlvb3JAZWNpdGVsZS5jb20+PjsgUm90ZW0gQ29oZW4gPFJvdGVtLkNv aGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4+DQrkuLvpopg6 IFJlOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNwZWNpZmljIGxhYmVs IHNwYWNlcw0KDQpIaSBTYXNoYSwNCg0KVGhhbmtzIGEgbG90IGZvciB0YWtpbmcgdGltZSB0byBy ZWFkIHRoZSBkb2N1bWVudCBhbmQgcHJvdmlkaW5nIHRoZSBtdWNoIGFwcHJlY2lhdGVkIGNvbW1l bnRzLiBQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGlubGluZS4NCg0KDQpPbiBXZWQsIEp1bCAx OSwgMjAxNyBhdCAxMjowOSBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4+IHdyb3RlOg0KSGkgYWxsLA0KSSBoYXZlIHJlYWQgdGhlIGRyYWZ0PGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1tcGxzLWFueWNhc3Qtc2VnbWVudHMtMDE+ IGluIHF1ZXN0aW9uLCBhbmQsIGZyb20gbXkgUE9WLCBpdCBkZWZpbmVzLCB1bmRlciB0aGUgbmFt ZSBvZiBWaXJ0dWFsIExGSUIsICBhIGRlZGljYXRlZCBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNw YWNlIChzZWUgUkZDIDUzMzE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzMzE+KSAg aW4gdGhlIGRldmljZXMgdGhhdCBhcmUgYXNzaWduZWQgd2l0aCBvbmUgb3IgbW9yZSBhbnljYXN0 IHNlZ21lbnRzLCBhbmQgdXNlcyB0aGUgbGFiZWxzIHN1Y2ggZGV2aWNlcyBhbGxvY2F0ZSBmb3Ig dGhlc2Ugc2VnbWVudHMgYXMgdGhlIGNvbnRleHQgbGFiZWxzIGlkZW50aWZ5aW5nIHRoaXMgc3Bh Y2UuDQpbUHVzaHBhc2lzXSBZZXMsIHRoYXQgaXMgY29ycmVjdC4gSSB3aWxsIGFkZCBhIHJlZmVy ZW5jZSB0byBSRkMgNTMzMSBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQoNCklmIG15IHVuZGVyc3Rh bmRpbmcgaXMgY29ycmVjdDoNCg0K4oCiICAgICAgICAgRXhwbGljaXQgbWFwcGluZyBvZiB0aGUg ZGVmaW5pdGlvbnMgb2YgdGhlIGRyYWZ0IHRvIGFscmVhZHkgZGVmaW5lZCBhbmQgd2VsbC11bmRl cnN0b29kIE1QTFMgYXJjaGl0ZWN0dXJhbCBtZWNoYW5pc21zIHdvdWxkIGdyZWF0bHkgaW1wcm92 ZSBpdHMgcmVhZGFiaWxpdHkuIEl0IHdvdWxkIGFsc28gZ3JlYXRseSBoZWxwIHRoZSBpbXBsZW1l bnRlcnMsIGVzcGVjaWFsbHkgaWYgdGhleSBoYXZlIGFscmVhZHkgaW1wbGVtZW50ZWQgKG9yIGNv bnNpZGVyIGltcGxlbWVudGF0aW9uIG9mKSBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBp biB0aGVpciBkZXZpY2VzDQpbUHVzaHBhc2lzXSBBdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoaXMg ZHJhZnQsIHRoZXJlIHdlcmUgYWxyZWFkeSBzb21lIGltcGxlbWVudGF0aW9ucyBvZiBjb250ZXh0 LXNwZWNpZmljIGxhYmVsIHNwYWNlICwgYW5kIHNvIEkgdGhvdWdodCBhZGRpbmcgdGhvc2UgaW1w bGVtZW50YXRpb24gZGV0YWlscyB3aWxsIG5vdCBiZSB1c2VmdWwsIGVzcGVjaWFsbHkgZHVyaW5n IHRoZSBXR0xDIGxhc3QgY2FsbHMuIEltcGxlbWVudGF0aW9uIG1pbnV0ZSBkZXRhaWxzIGFyZSBu b3Qgd2VsY29tZSBJIGFzc3VtZSBmcm9tIHRoZSBXR0xDIHJldmlld3MgSSBoYXZlIGdvbmUgdGhy b3VnaCBzbyBmYXIuIEJ1dCBsIGNhbiBzdXJlIGFkZCBzb21lIHJlZmVyZW5jZSB0byBSRkM1MzMx Lg0KDQrigKIgICAgICAgICBBZGRpbmcgdGhlIHJlbGV2YW50IHJlZmVyZW5jZXMgKGluY2x1ZGlu ZyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDUzMzEpIHNlZW1zIG5lY2Vzc2FyeQ0KDQpV c2luZyBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBhbmQgY29udGV4dCBsYWJlbHMgaW4g Y29uanVuY3Rpb24gd2l0aCBhbnljYXN0IChvciBhbnljYXN0LWxpa2UpIGZ1bmN0aW9uYWxpdHkg IGluIE1QTFMgaXMgbm90IG5ldy4gT25lIGV4YW1wbGUgKGFzIGluZGljYXRlZCBpbiBFcmljIFJv c2Vu4oCZcyBlbWFpbDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMv Y3VycmVudC9tc2cxMjY1OS5odG1sPikgIGlzIHRoZSBQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUg UHJvdGVjdGlvbiBtZWNoYW5pc20gZGVmaW5lZCBpbiBSRkMgODEwNDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjODEwND4uDQpbUHVzaHBhc2lzXSBZZXMsIHVzZSBvZiBjb250ZXh0LXNw ZWNpZmljIGxhYmVsIHNwYWNlIGlzIG5vdCBuZXcuIEFuZCB3b3JraW5nIGluIEp1bmlwZXIgZm9y IHNvbWV0aW1lIEkgaGF2ZSBhIGdvb2QgaWRlYSBvZiBpdHMgYXBwbGljYXRpb24uIEJ1dCB1c2lu ZyBpdCB0byBwcm92aWRlIGEgbWVhbnMgdG8gZG8gYW55Y2FzdCBzZWdtZW50cyB1c2luZyBNUExT IGRhdGFwbGFuZSBpcyB2ZXJ5IG11Y2ggbmV3LiBBbmQgdG8gbXkga25vd2xlZGdlIHRpbGwgZGF0 ZSB0aGVyZSBpcyBubyBvdGhlciB3YXkgdG8gYWNoaWV2ZSB0aGlzIHdpdGhvdXQgcmVjdXJzaXZl IGxhYmVsIGxvb2t1cCBhbmQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXMuDQoNClRoZSBh bmFsb2d5IGxvb2tzIGltcG9ydGFudCB0byBtZSBzaW5jZSBhbnljYXN0IGdyb3VwcyBhcmUgY29t bW9ubHkgY29uc2lkZXJlZCBhcyBhIHByb3RlY3Rpb24gbWVjaGFuaXNtIChhbmQgbm90IGp1c3Qg YXMgYSBsb2FkLWJhbGFuY2luZyBvbmUpLg0KW1B1c2hwYXNpc10gQWN0dWFsbHksIGFib3V0IHRo ZSB1c2VjYXNlcyBJIGhhdmUgZGlzY3Vzc2VkIHNvbWUgb2YgdGhlIG9wZXJhdG9ycyBJIGhhdmUg ZGlzY3Vzc2VkIHdpdGggc28gZmFyIG9uIHRoaXMsIGFsbW9zdCBhbGwgdGhlbSBhcmUgYWJvdXQg cG9saWN5LWJhc2VkLXJvdXRpbmcsICBsb2FkLWJhbGFuY2luZyBhbmQgcHJvdmlkaW5nIGRpc2pv aW50IHBhdGhzLiBPZmZjb3Vyc2UgZGlzam9pbnQgcGF0aHMgY2FuIGJlIHVzZWQgZm9yIHByb3Rl Y3Rpb24gYXMgd2VsbCBhcyBsb2FkLWJhbGFuY2luZy4NCg0KSSBhbHNvIHRoaW5rIHRoYXQgcmVs YXRpb25zaGlwcyBiZXR3ZWVuIHRoaXMgZHJhZnQgYW5kIHRoZSBlZ3Jlc3MgcHJvdGVjdGlvbiBm cmFtZXdvcms8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hlbi1tcGxz LWVncmVzcy1wcm90ZWN0aW9uLWZyYW1ld29yay8/aW5jbHVkZV90ZXh0PTE+IG9uZSBhcmUgd29y dGggbG9va2luZyBhdCBjYXJlZnVsbHkuDQpbUHVzaHBhc2lzXSBGaXJzdCB0aGUgZWdyZXNzIHBy b3RlY3Rpb24gZHJhZnRzIGRvZXMgbm90IHNlZW0gdG8gaGF2ZSBnb25lIHRocm91Z2ggV0cgYWRv cHRpb24uIE5leHQgdGhvdWdoIHRoZXNlIHR3byBkcmFmdHMgdXNlIHRoZSBzYW1lIG1lY2hhbmlz bXMsIHRoZSBleGFjdCBwcm9ibGVtIHRoZXkgdHJ5IHRvIHNvbHZlIGFyZSBub3QgZXhhY3RseSBy ZWxhdGVkLg0KDQpOZXZlcnRoZWxlc3MsIEkgdmFsdWUgeW91ciBjb21tZW50cywgc3VnZ2VzdGlv bnMgYW5kIHRob3VnaHRzIGEgbG90LCBhbmQgdGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgcHJvdmlk aW5nIHRoZSBpbnNpZ2h0cy4gSSB3aWxsIGRlZmluaXRlbHkgd29yayBvbiB0aGVtIGFuZCBhZGRy ZXNzIHRoZW0gaW4gdGhlIG5leHQgZHJhZnQuDQoNClRoYW5rcyBvbmNlIGFnYWluIGFuZCBiZXN0 IHJlZ2FyZHMsDQotUHVzaHBhc2lzDQoNCg0KTXkgMmMsDQpTYXNoYQ0KDQpPZmZpY2U6ICs5NzIt MzkyNjYzMDINCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDINCkVtYWlsOiAgIEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBp bnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3 aGljaCBpcw0KQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJ IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMNCnRyYW5zbWlzc2lvbiBpbiBlcnJv ciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVs ZXRlIHRoZSBvcmlnaW5hbA0KYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K c3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQoNCg0K DQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE4Ddggemi502mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm04 MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5ODM1MjE5NDY1ODFnbWFpbC1tLTMxNTcwNTIzMjcxODU2 ODY3Nm1zb2xpc3RwYXJhZ3JhcGgsIGxpLm04MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5ODM1MjE5 NDY1ODFnbWFpbC1tLTMxNTcwNTIzMjcxODU2ODY3Nm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tODI0 ODIwMTE0NzM2NzYxMjg1bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2 NzZtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fODI0ODIwMTE0NzM2NzYxMjg1 bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAubTgyNDgyMDExNDczNjc2MTI4NW0yNDQ3 NDk4MzUyMTk0NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4NTY4Njc2bTc0OTA3NDY4NzI5OTY1MTkx NDRtc29saXN0cGFyYWdyYXBoLCBsaS5tODI0ODIwMTE0NzM2NzYxMjg1bTI0NDc0OTgzNTIxOTQ2 NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtNzQ5MDc0Njg3Mjk5NjUxOTE0NG1zb2xpc3Rw YXJhZ3JhcGgsIGRpdi5tODI0ODIwMTE0NzM2NzYxMjg1bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwt bS0zMTU3MDUyMzI3MTg1Njg2NzZtNzQ5MDc0Njg3Mjk5NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLW5hbWU6bV84MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5ODM1MjE5NDY1ODFn bWFpbC1tLTMxNTcwNTIzMjcxODU2ODY3Nm03NDkwNzQ2ODcyOTk2NTE5MTQ0bXNvbGlzdHBhcmFn cmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkw LjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgUHVzaHBhc2lz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHlvdXIgYW5zd2VyLCBub3cgSSB1bmRlcnN0YW5k IHRoZSByZWFzb24gb2YgaXQuIFBsZWFzZSByZWFkIGRldGFpbGVkIHJlcGx5IGlubGluZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gUHVz aHBhc2lzIFNhcmthciBbbWFpbHRvOnB1c2hwYXNpcy5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi PiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+ ODwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4t VVMiPg0KIDE0OjI5PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IENoZW5nbGkgKERpc3RhbmNlKSAmbHQ7Y2hl bmdsaTEzQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IGRyYWZ0LWlldGYtc3ByaW5nLWFu eWNhc3Qtc2VnbWVudEBpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4 u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJl OiA8L3NwYW4+562U5aSNPHNwYW4gbGFuZz0iRU4tVVMiPjoNCjwvc3Bhbj7nrZTlpI08c3BhbiBs YW5nPSJFTi1VUyI+OiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNwZWNp ZmljIGxhYmVsIHNwYWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBDaGVu Z2xpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSByZWZl ciB0byBGaWd1cmUgNCBpbiB0aGUgZHJhZnQuIEluIHRoaXMgZXhhbXBsZSBDQS1TUkdCIGlzIDIw MDAtMzAwMC4gQnV0IGxldCdzIHNheSBBMSBmb3Igc29tZSBoYXJkd2FyZSBzcGVjaWZpYyByZWFz b24gY2Fubm90IHN1cHBvcnQgbGFiZWwgcmFuZ2UgMjAwMC0zMDAwLiBTbyBpdCB1c2VzIGEgcmVn dWxhciBTUkdCIHJhbmdlIG9mIDEwMDAtMjAwMC4gSWYgQTENCiB3b3VsZCBub3QgaGF2ZSBhZHZl cnRpc2VkIHRoZSBhbnljYXN0IHByZWZpeCBzZWdtZW50IDEwMCB3aXRoIFAtRmxhZyAxLCB0aGUg dG9wbW9zdCBsYWJlbCBpbiB0aGUgaW5jb21pbmcgcGFja2V0IHdpbGwgYmUgcGYgdGhlIG5leHQg c2VnbWVudCBhcyAyMDMwLiBBcyB5b3UgbWF5IGtub3cgYWxyZWFkeSB0aGUgZmlyc3QgbGFiZWwg bG9va3VwIGZvciBhbnkgcGFja2V0IGlzIGFsd2F5cyBpbiB0aGUgZGVmYXVsdC1MRklCLCBhbmQg MjAzMCBjYW5ub3QNCiBiZSBwcm9ncmFtbWVkIGluIGRlZmF1bHQtTEZJQiBvZiBBMS4gVGhlbiB0 aGUgcGFja2V0IHNoYWxsIGhhdmUgdG8gYmUgZHJvcHBlZC4gPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPg0KPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+W0NoZW5nXVNvIHRoaXMgaXMgdGhlIG1haW4gcmVhc29uIG9mIHdoeSB3ZSBu ZWVkIHRvIGtlZXAgYW55Y2FzdCBsYWJlbC4gQmVjYXVzZSAmbmJzcDt0aGUgQ0FQU0wgY2FuIG5v dCBiZSBwcm9ncmFtbWVkIGluIGRlZmF1bHQtTEZJQiwgaWYgdGhlIG5vZGUgY2FuIG5vdCBzdXBw b3J0IHRoZQ0KIGxhYmVsIHJhbmdlLiBJdCByZWFsbHkgbWFrZXMgc2Vuc2UuIEtlZXBpbmcgdGhl IEFQU0wgYXMgdGhlIHRvcCBsYWJlbCBpcyBhIGdvb2Qgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxl bSEgQXdlc29tZSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQgSSBoYXZl IGFub3RoZXIgcXVlc3Rpb246IEluIHRoaXMgY2FzZSwgcmFuZ2UgMjAwMC0zMDAwIGNhbiBub3Qg YmUgc3VwcG9ydGVkIGJ5IEExLCBzbyB3aHkgaXQgY2FuIGJlIHVzZWQgaW4gVi1MRklCPyAmbmJz cDsmbmJzcDsmbmJzcDtBY3R1YWxseSwgSSBhbSBjdXJpb3VzIGFib3V0IHRoZSBoYXJkd2FyZQ0K IHNwZWNpZmljIHJlYXNvbiwgYW5kIHdoeSB0aGlzIHJlYXNvbiBkb2VzIG5vdCBhZmZlY3QgVi1M RklCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SW5zdGVhZCB3ZSBmb3JjZSB0aGUgcGVudWx0 aW1hdGUgaG9wIHRvIG5vdCBQT1AgdGhlIHRvcG1vc3QgbGFiZWwgYnV0IHN3YXAgaXQgd2l0aCAx MTAwLiBXaGVuIHRoZSBwYWNrZXQgY29tZXMgd2l0aCAxMTAwIGFzIHRoZSB0b3Btb3N0IGxhYmVs IGl0IGhpdHMgdGhlIGNvcnJlc3BvbmRpbmcgZW50cnkgaW4gZGVmYXVsdC1MRklCIHdoaWNoIHBv cHMgaXQgYW5kIGxhdW5jaGVzDQogYSBsb29rdXAgZm9yIDIwMzAgaW4gYSBzZXBhcmF0ZSBWLUxG SUIuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bQ2hl bmddIFllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgcHVycG9zZSBvZiBDQS1TUkdCIGlzIGZvciB0aGUgc291cmNlIG9mIHRo ZSB0cmFmZmljIHRvIGRlcml2ZSB0aGUgbGFiZWwgdG8gYmUgdXNlZCBmb3IgdGhlIG5leHQgc2Vn bWVudCBmb2xsb3dpbmcgYSBhbnljYXN0IHNlZ21lbnQuIFRoZSBsYWJlbCB0byBiZSB1c2VkIGZv ciB0aGUgZmlyc3QgYW55Y2FzdCBzZWdtZW50IGlzIGFsd2F5cyBkZXJpdmVkIGZyb20gdGhlIHJl Z3VsYXINCiBTUkdCIG9mIHRoZSBuZXh0IGhvcCBub2RlKHMpLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0NoZW5nXSBZZXMsIHRoaXMgaXMgYSByZWFs bHkgYW1hemluZyBpZGVhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk5vdyBxdWVzdGlvbiBpcyB3aHkgY2Fubm90IHdlIHVzZSBDQVNS R0IgdG8gYmUgc2FtZSBhcyBTUkdCIGV2ZXJ5d2hlcmU/IEJ1dCBJZiB0aGF0IHdvdWxkIGhhdmUg YmVlbiBwb3NzaWJsZSB0aGVyZSB3b3VsZCBoYXZlIGJlZW4gbm8gcmVhc29uIGZvciB0aGlzIGRy YWZ0IHRvIGJlIHdyaXR0ZW4gaW4gdGhlIGZpcnN0IHBsYWNlLiBUaGUgcmVhc29uIHRoYXQgY2Fu bm90IGJlIHBvc3NpYmxlDQogaXMgZGlmZmVyZW50IHZlbmRvcnMgc3VwcG9ydCBkaWZmZXJlbnQg bGFiZWwtcmFuZ2VzIGluIHRoZWlyIGhhcmR3YXJlLiBBbmQgdGhlIGJpZ2dlc3QgcmVhc29uIGFs bCB2ZW5kb3JzIGNhbm5vdCBzdXBwb3J0IHRoZSBzYW1lIHJhbmdlIGlzIGJlY2F1c2Ugb2YgcGxh dGZvcm0tc3BlY2lmaWMgbGVnYWN5IGxpbWl0YXRpb25zIGluIHRoZWlyIGhhcmR3YXJlcy4gRm9y IGV4YW1wbGUgdGhlIGRldmljZSB1c2VkIGZvciB0aGUgbm9kZSBBMSBhbHJlYWR5DQogcmVzZXJ2 ZXMgdGhlIGxhYmVsIHJhbmdlIDIwMDAtMzAwMCBmb3Igc29tZSBpbnRlcm5hbCBzd2l0Y2hpbmcg YW5kIGNhbm5vdCBiZSBtYWRlIGF2YWlsYWJsZSBmb3IgdGhlIHJlZ3VsYXIgTVBMUyBzd2l0Y2hp bmcgYW5kIGZvcndhcmRpbmcuIEFsc28gYXMgcGVyIE1QTFMgYXJjaGl0ZWN0dXJlIGxhYmVscyBh cmUgb2YgbG9jYWwgc2lnbmlmaWNhbmNlIGFuZCB0aGVyZSBzaG91bGQgYmUgbm8gc29sdXRpb24g YmFzZWQgb24gZ2xvYmFsIGxhYmVsDQogcmFuZ2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltDaGVuZ11ObywgSSB1bmRl cnN0YW5kIHRoZSByZWFzb24gdG90YWxseS4gWW91ciB3b3JrIGlzIHJlYWxseSB1c2VmdWwuIEdv b2Qgam9iITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhvcGUgeW91ciBxdWVzdGlvbnMgYXJlIGFuc3dlcmVkIG5vdy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4tUHVzaHBhc2lzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBBdWcgMTAs IDIwMTcgYXQgOToyMiBBTSwgQ2hlbmdsaSAoRGlzdGFuY2UpICZsdDs8YSBocmVmPSJtYWlsdG86 Y2hlbmdsaTEzQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5jaGVuZ2xpMTNAaHVhd2VpLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkmbmJzcDsgUHVzaHBhc2lzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ V293LCBpdCBoYXMgYmVlbiB0d28geWVhcnMgc2luY2UgeW91IG1hZGUgdGhlIHByZXNlbnRhdGlv bi4mbmJzcDsgVGhhbmsgeW91IGZvciB5b3VyIHNsaWRlcy4gSSBoYXZlIHJlYWQgaXQNCiBhbGwu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQgSSBzdGlsbCBoYXZlIHNvbWUg cXVlc3Rpb25zLiBQbGVhc2UgZmluZCB0aGVtIGlubGluZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuWPkeS7tuS6ujwv c3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCiBQdXNocGFzaXMgU2Fya2FyIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnB1c2hwYXNpcy5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnB1c2hw YXNpcy5pZXRmQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4gMjAx Nzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5bm0PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj44PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjk8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+DQogMjM6MzE8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PuaUtuS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4gQ2hlbmdsaSAoRGlzdGFuY2UpICZs dDs8YSBocmVmPSJtYWlsdG86Y2hlbmdsaTEzQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5j aGVuZ2xpMTNAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij7kuLvpopg8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+IFJlOg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7nrZTlpI08L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjogW3NwcmluZ10gQW55Y2FzdCBzZWdtZW50cyBhbmQgY29udGV4 dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3BlIHlvdSBoYXZlIGFscmVhZHkgZ29uZSB0aHJvdWdo IG15IHByZXNlbnRhdGlvbiBwcmVzZW50ZWQgd2F5IGJhY2sgaW4gMjAxNS4uIElmIG5vdCBoZXJl IGlzIHRoZSBsaW5rIHRvIHRoZSBzYW1lLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1zcHJpbmctMS5wZGYiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLXNwcmlu Zy0xLnBkZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5PbiBXZWQsIEF1ZyA5LCAyMDE3IGF0IDg6NTggUE0sIFB1c2hwYXNpcyBTYXJrYXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5wdXNocGFzaXMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBD aGVuZ2xpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFu a3MgYSBsb3QgZm9yIHRha2luZyB0aW1lIHRvIHJlYWQgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIGNv bW1lbnRzLiBQbGVhc2UgZmluZCBhbnN3ZXJzIGlubGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEF1ZyA5LCAyMDE3IGF0IDI6MDQgUE0sIENo ZW5nbGkgKERpc3RhbmNlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoZW5nbGkxM0BodWF3ZWkuY29t IiB0YXJnZXQ9Il9ibGFuayI+Y2hlbmdsaTEzQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFB1c2hwYXNpcyw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFt IGEgbmV3IGxlYXJuZXIgb2YgU1IuIFJlY2VudGx5LCBJIHJlYWQgdGhlDQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNwcmluZy1tcGxzLWFueWNhc3Qtc2VnbWVudHMtMDEiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+ZHJhZnQ8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiwNCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFuZCBJIGhhYSBzb21lIHF1ZXN0aW9u cyBhYm91dCBpdC4gU29tZSBvZiB0aGVtIGFyZSBhYm91dCB0aGUgYWxnb3JpdGhtLCB3aGlsZSB0 aGUgb3RoZXJzIGFyZSBhYm91dCB0aGUgY29udGV4dC4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjE6IElmIENBLVNS R0IgbmVlZCB0byBiZSBjb25maWd1cmVkIHRoZSBzYW1lIGFtb25nIGFsbCBub2Rlcywgd2hpY2gg bWVhbnMgYWxsIG5vZGVzIGNhbg0KIHVuZGVyc3RhbmQgdGhlIGxhYmVsIGluIENBLVNSR0IuIElm IHNvLCB3aHkgZG8gd2UgbmVlZCB0byBzZXQgUC1GbGFnIHdoZW4gdGhlIG5vZGUgaGFzIGEgZGlm ZmVyZW50IENBLVNSR0IgcmFuZ2Ugd2l0aCBTUkdCLiBXaXRob3V0IHRoZSBBbnljYXN0LVNJRCwg dGhlIG5vZGUgY2FuIHVuZGVyc3RhbmQgQ0EtU1JHQiBhbmQgcHJvY2VzcyBDQVBTTCBhcyB3ZWxs LiZuYnNwOyBXaHkgZG8gd2UgbmVlZCB0byBrZWVwIEFueWNhc3QgbGFiZWw/IFRvIGluZGVudGlm eQ0KIHRoZSBuZXh0IGxhYmVsIGlzIGEgQ1BBU0w/Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPltQdXNo cGFzaXNdIFllcyB0aGlzIGlzIG5lZWRlZCBmb3IgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVkIHRo ZSBDQVBTTC4gSW4gY2FzZSB0aGUgQ0EtU1JHQiBpcyBkaWZmZXJlbnQgZnJvbSByZWd1bGFyIFNS R0IgdGhlIHBhY2tldCBtdXN0IGNvbWUgaW4gd2l0aCB0aGUgQ0FQU0wNCiBhdCB0aGUgdG9wIG9m IHRoZSBzdGFjayBzbyB0aGF0IGl0IHBvcHMgYW5kIGRvZXMgYSByZWN1cnNpdmUgbGFiZWwgbG9v a3VwIHdpdGggdGhlIG5leHQgbGFiZWwgaW4gc3RhY2suLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+W0NoZW5nXSBJZiB0aGVyZSBpcyBhbiBhY3Rpb24gc3VwcG9ydGluZyB0byBsb29r IHVwIGluIFYtTEZJQiwgd2h5IG5vdCB1c2UgQ0FQU0wgYXMgdGhlIGtleSBpbiBEZWZhdWx0DQog TEZJQiBkaXJlY3RseT8mbmJzcDsgSWYgc28sIFAtRmxhZyBjYW4gYmUgbGVhdmVkIDAsIGFuZCBu b2RlIHdpbGwgcmVjZWl2ZSBhIHBhY2tldCB3aXRoIHRoZSBDQVBTTCBhcyB0aGUgdG9wIGxhYmVs IG5vIG1hdHRlciBpdOKAmXMgQ0EtU1JHQiBpcyB0aGUgc2FtZSBhcyBTUkdCIG9yIG5vdC4gSW4g ZGVmYXVsdCBMRklCLCB0aGVyZSBzaG91bGQgYmUgYW4gZW50cnkgZm9yIENBUFNMLCBhbmQgaXTi gJlzIGFjdGlvbiBpcyB0byBsb29rIHVwIENBUFNMIGluIFYtTEZJQi4NCiBJIGFtIG5vdCBzdXJl IHRoYXQgd2hldGhlciBpdCBjYW4gd29yayBvciBub3QuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SW4gdGhpcyB3YXksIGNvbmZpZ3VyYXRpb24gd2lsbCBiZSBtdWNoIGVhc2ll ci4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4gc3VtbWFyeSwg aW4gbXkgUE9WLCB3ZSBjYW4gcG9wIHRoZSBwcmV2aW91cyBhbnljYXN0IGxhYmVsIHNvIHRoYXQg dGhlIG5vZGUgY2FuIHJlY2VpdmUgdGhlIHNhbWUgcGFja2V0DQogbm8gbWF0dGVyIGl04oCZcyBD QS1TUkdCIGlzIHRoZSBzYW1lIGFzIFNSR0Igb3Igbm90LiBCdXQgSSBzdXBwb3NlIHRoYXQgJm5i c3A7dGhlcmUgbXVzdCBiZSBzb21lIHJlYXNvbnMgdGhhdCB5b3UgZGlkbuKAmXQmbmJzcDsgcHJv cG9zZSBhIHNvbHV0aW9uIGxpa2UgdGhpcy4gSWYgcG9zc2libGUsIGNhbiB5b3UgYmUga2luZCB0 byB0ZWxsIG1lID88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhl IHJlYXNvbiBtYXliZToNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+S2VlcGlu ZyB0aGUgYW55Y2FzdCBsYWJlbCBjYW4gcmVkdWNlIHRoZSBlbnRyaWVzIG9mIExGSUIuJm5ic3A7 IElmIHdlIHVzZSBDQVBTTCBhcyB0aGUgdG9wIGxhYmVsLCB3ZSBuZWVkIHRvDQogaW5zdGFsbCBl bnRyaWVzIGZvciBhbGwgQ0FQU0xzIGluIExGSUIgYW5kIGluIFYtTEZJQiBhcyB3ZWxsLiBCdXQg aWYgd2Uga2VlcCBBbnljYXN0IGxhYmVsIGFzIHRoZSB0b3AgbGFiZWwsJm5ic3A7IHdlIG9ubHkg bmVlZCB0byBpbnN0YWxsIG9uZSBlbnRyeSBmb3IgQW55Y2FzdCBsYWJlbCwgYW5kIG9uZSBlbnRy eSBmb3IgZWFjaCBDQVBTTCBpbiBWLUxGSUIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjI6IEluIHNlY3Rp b24gMy4yLjIgb2YgeW91ciBkcmFmdCwgaXQgc2F5cyB0aGF0DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWluZGVudDoyMS4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj5UaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYSBzZXBhcmF0ZSB2aXJ0 dWFsIGxhYmVsIGxvb2t1cCB0YWJsZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoaGVyZWFm dGVyIHJlZmVycmVkIHRvIGFzIFZpcnR1YWwgTEZJQiBvciBWLUxGSUIpLCB0aGF0IHJlcHJlc2Vu dHMgYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBsYWJlbCBzcGFjZSB3aGljaCBpcyBhbHNv IHNlcGFyYXRlIGZyb20gdGhlIGFjdHVhbCBsYWJlbCBzcGFjZTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyByZXByZXNlbnRlZCBieSB0aGUgZGVmYXVsdCBMRklCLiZuYnNwOyBUaGUgbGFiZWwg dmFsdWUgbWF5IGJlIHByZXNlbnQgaW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYm90aCB0 aGUgZGVmYXVsdCBhbmQgVmlydHVhbCBMRklCLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIFYtTEZJQiByZXByZXNl bnRzIGEgbGFiZWwgc3BhY2Ugc2VwYXJhdGVkIGZyb20gdGhlIGxhYmVsIHNwYWNlIHJlcHJlc2Vu dGVkIGJ5IExGSUIsDQogd2h5IGxhYmVsIHZhbHVlIG1heSBiZSBwcmVzZW50IGluIGJvdGggb2Yg dGhlbT8mbmJzcDsgSWYgdGhpcyBpcyByaWdodCwgSSBzdXBwb3NlIHRoYXQgdGhlIHJlYXNvbiBv ZiBrZWVwaW5nIGFueWNhc3QgbGFiZWwgaXMgdG8gaWRlbnRpZnkgdGhlIG5leHQgbGFiZWwgc2hv dWxkIGJlIGxvb2tlZCB1cCBpbiBWLUxGSUIgaW5zdGVhZCBvZiBkZWZhdWx0IG9uZS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+W1B1c2hwYXNpc10gVGhlb3JldGljYWxseSBhbGwgbGFiZWwtc3BhY2VzIGNhbiBi ZSBpbmRlcGVuZGVudCBhbmQgbWF5IGhhdmUgdGhlIHNhbWUgbGFiZWwgcHJvZ3JhbW1lZCBpbiB0 aGVtIHdpdGggZGlmZmVyZW50IGZvcndhcmRpbmcgc2VtYW50aWNzLiBIb3dldmVyIGZyb20NCiB0 aGUgZm9sbG93aW5nIHRleHQgd2UgcHJvcG9zZWQgYSBzZXBhcmF0ZSBWLUxGSUIgaWYgYW5kIG9u bHkgaWYgQ0EtU1JHQiBpcyBkaWZmZXJlbnQgZnJvbSBTUkdCLi4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltDaGVuZ10gSSBhbSB3b25kZXJpbmcgdGhhdCB3aGF0 IGlzIHRoZSBsYWJlbC1zcGFjZT8gSSB0aGluayBpdCBpcyB0aGUgcmFuZ2Ugb2YgbGFiZWwuIEJ1 dCBpdCBzZWVtcyBub3QuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiBTdWNoIGEgZGV2aWNlIE1V U1QgYWRkIGFuIGVudHJ5IGluIHRoZSBWaXJ0dWFsIExGSUIgZm9yIGVhY2ggdW5pY2FzdDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGFuZCBhbnljYXN0IHByZWZpeCBzZWdtZW50cyBsZWFybnQgZnJvbSBhIHJl bW90ZSBkZXZpY2UsIGlmIGFuZCBvbmx5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaWYgdGhlIHNhbWUgcHJlZml4IGhh cyBub3QgYmVlbiBwcm92aXNpb25lZCBvbiB0aGUgZGV2aWNlLiZuYnNwOyBUaGU8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBkZXZpY2UgU0hPVUxEIE5PVCBhZGQgYW4gZW50cnkgZm9yIGFueSBvZiB0aGUgQW55Y2FzdCBv ciBOb2RlIHByZWZpeDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNlZ21lbnRzIHRoYXQgaXQgaGFzIGFkdmVydGlzZWQg aXRzZWxmLiZuYnNwOyBIb3dldmVyIGlmIHRoZSBkZXZpY2UgaGFzPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbGVhcm50 IGFueSBhbnljYXN0IHByZWZpeCBzZWdtZW50IGZyb20gYSByZW1vdGUgZGV2aWNlLCBhbmQgdGhl IHNhbWU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBpcyBub3QgcHJvdmlzaW9uZWQgb24gdGhpcyBkZXZpY2UsIHRoZSBk ZXZpY2UgTVVTVCBpbmNsdWRlIHRoZSBzYW1lPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW4gdGhlIFZpcnR1YWwgTEZJ QiB0YWJsZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPltQ dXNocGFzaXNdIElmIHRoZSBsYWJlbCBhdCB0aGUgdG9wIG9mIHRoZSBzdGFjayBiZWxvbmdzIHRv IENBLVNSR0IgdGhlbiBpdCBoYXMgdG8gYmUgZm9yIGFueWNhc3QgcHJlZml4IG9yaWdpbmF0ZWQg cmVtb3RlbHkgYW5kIHRoZSBwYWNrZXQgYWN0dWFsbHkgaGl0cyBhbiBlbnRyeQ0KIGluIHRoZSBk ZWZhdWx0IExGSUIgZmlyc3QuLiBCdXQgYmVjYXVzZSB0aGUgbGFiZWwgaXMgY29ycmVzcG9uZGlu ZyB0byBhbiBhbnljYXN0IHByZWZpeCB3ZSBpbnN0YWxsIGEgcmVjdXJzaXZlIGxvb2t1cCB3aXRo IHRoZSBWLUxGSUIgYXMgdGhlIG5leHQgdGFibGUuLiBXaGVuIHRoZSBsb29rdXAgZm9yIG5leHQg bGFiZWwgaW4gc3RhY2sgaW4gdGhlIFZMRklCIGlzIGxhdW5jaGVkIHRoYXQgbGFiZWwgbWF5YmUg YXNzb2NpYXRlZCB3aXRoIENBX1NSR0INCiBvciBkZWZhdWx0LVNSR0IuLiBUaGUgVi1MRklCIGlz IG5lZWRlZCB0byBvbmx5IGZhY2xpdGF0ZSBsb29rdXAgb2YgdGhlIG5leHQgbGFiZWwuLiZuYnNw OyBJbiBjYXNlIHRoZSBDQS1TUkdCIGlzIHNhbWUgYXMgZGVmYXVsdC1TUkdCIEkgaG9wZSB5b3Vy IHJlYWxpemUgdGhhdCBhIHJlY3Vyc2l2ZSBsYWJlbCBpcyBub3QgcmVxdWlyZWQuIEl0IGlzIGlt cG9ydGFudCB0byByZWFsaXplIHRoYXQgQ0EtU1JHQiBpcyBpbnZlbnRlZCB0byBhY3R1YWxseSBh dm9pZA0KIHJlY3Vyc2l2ZSBsYWJlbCBsb29rdXAuLiBUaGUgZGV2aWNlcyB0aGF0IHVzZXMgc2Ft ZSBDQS1TUkdCIGFzIGRlZmF1bHQgU1JHQiBuZWVkIG5vdCBzdXBwb3J0IHJlY3Vyc2l2ZSBsYWJl bCBsb29rdXAgaW4gdGhlIGhhcmR3YXJlLi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPltDaGVuZ10gWWVzLCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBsb2dpYyBvZiB5 b3VyIHNvbHV0aW9uLiZuYnNwOyBXaGF0IGlmIHdlIHBvcCB0aGUgYW55Y2FzdCBsYWJlbCAsYW5k IGxldCB0aGUNCiBDQVBTTCB0byBoaXQgdGhlIGVudHJ5IGluIExGSUIsIGFuZCB0aGVuIGV4ZWN1 dGUgdGhlIGFjdGlvbiBvZiBsb29raW5nIHVwIENBUFNMIGluIFYtTEZJQi4mbmJzcDsgV2h5IGRv IHdlIG5lZWQgdG8ga2VlcCB0aGUgYW55Y2FzdCBsYWJlbCA/IFRoaXMgaXMgbXkgcXVlc3Rpb24u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MzogSSBmb3VuZCBvdXQg c29tZSBzdHJhbmdlIHN0YXRlbWVudHMgaW4gdGhlIGRyYWZ0Ojwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im04MjQ4MjAx MTQ3MzY3NjEyODVtMjQ0NzQ5ODM1MjE5NDY1ODFnbWFpbC1tLTMxNTcwNTIzMjcxODU2ODY3Nm1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5QYWdlIDExPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7dGV4dC1pbmRlbnQ6MTAuNXB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5Gb3IgZXhhbXBsZSwg b24gZGV2aWNlIEExLCA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPnRoZSBwcmVmaXgg U0lEIDEwIChvcmlnaW5hdGVkIGJ5IFBFMyk8L3NwYW4+IGlzPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IHJlYWNoYWJsZSB0aHJvdWdoIGl0cyBuZWlnaGJvcnMgQTMgYW5kIEE0LiZuYnNwOyBB bmQgYXMgcGVyIHRoZSBTUkdCPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFkdmVydGlzZWQg YnkgQTMgYW5kIEE0LCB0aGUgbGFiZWxzIGFsbG9jYXRlZCBieSBBMyBhbmQgQTQgYXJlIDMwMzA8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjI0LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW5kIDQwMzAgcmVzcGVjdGl2 ZWx5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBzdXBwb3NlIHRoYXQgdGhlIHByZWZpeCBTSUQgaXMgMzAgaW5zdGVhZCBvZiAxMC48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+W1B1c2hwYXNpc10gWWVzIHlvdSBhcmUgcmlnaHQuIEkgaGF2ZSBhbHJlYWR5IGdv dCB0aGlzIGNvbW1lbnQgZnJvbSBvbmUgb2YgdGhlIFdHIG1lbWJlcnMuIEkgd2lsbCByZWN0aWZ5 aW5nIHRoaXMgaW4gbmV4dCB2ZXJzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtODI0ODIwMTE0NzM2NzYxMjg1bTI0NDc0OTgzNTIxOTQ2 NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Yik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFnZSAxNDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0idGV4dC1pbmRl bnQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5U aGlzIGlzIGJlY2F1c2Ugb24gbm9kZSA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPkEx PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ 77yIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPklz IGl0IEEyPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ 77yJPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiB0 aGUgZG9tYWluLXdpZGUgQ0EtU1JHQiBpcyBpZGVudGljYWwgdG8gdGhlIGxvY2FsIFNSR0IgcHJv dmlzaW9uZWQgb24gQTIuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cCBjbGFzcz0ibTgyNDgyMDExNDczNjc2MTI4NW0yNDQ3NDk4MzUyMTk0NjU4MWdtYWls LW0tMzE1NzA1MjMyNzE4NTY4Njc2bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmMp PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBhZ2UgMTQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9InRleHQtaW5kZW50OjEwLjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+V2hpbGUgZm9y d2FyZGluZyB0byBBMiwgc2luY2UgQTIgd291bGQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7Jm5ic3A7aGF2ZSBhZHZlcnRpc2VkIHRoZSBh bnljYXN0IFNJRCAxMDAgd2l0aCBQLUZsYWcgKE5vLVBIUCkgdW5zZXQsIDxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kOnllbGxvdyI+UjE8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp Zjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOnllbGxvdyI+ICZuYnNwOyZuYnNwOyZuYnNwO3NoYWxs IFBPUCB0aGUgaW5jb21pbmcgbGFiZWwgNzEwMCBiZWZvcmUgZm9yd2FyZGluZyBpdCB0byBSMShJ cyBpdCBBMj8pLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPltQdXNocGFzaXNdIFllcyB5b3UgYXJlIHJpZ2h0 LiBJIGhhdmUgYWxyZWFkeSBnb3QgdGhpcyBjb21tZW50IGFzIHdlbGwgZnJvbSBvbmUgb2YgdGhl IFdHIG1lbWJlcnMuIEkgd2lsbCByZWN0aWZ5aW5nIHRoaXMgaW4gbmV4dCB2ZXJzaW9uLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rcyBhIGxvdCBmb3IgY29tbWVudHMgYW5kIHRob3VnaHRzLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tUHVzaHBhc2lzPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9y IHlvdXIgZ29vZCBqb2IhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVuZzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5Y+R 5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIHNwcmluZyBbbWFpbHRvOjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7ku6Pooag8L3NwYW4+PC9iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UHVzaHBh c2lzIFNhcmthcjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ 5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDE3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaciDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+MjA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+DQogMTI6MzU8YnI+ DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaUtuS7tuS6ujwvc3Bh bj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5oqE 6YCBPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPm1wbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1zcHJpbmctYW55Y2FzdC1zZWdtZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+ZHJhZnQtaWV0Zi1zcHJpbmctYW55Y2FzdC1zZWdtZW50QGlldGYub3JnPC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LW1wbHMtc2hlbi1lZ3Jlc3MtcHJv dGVjdGlvbi1mcmFtZXdvcmtAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5kcmFmdC1tcGxzLXNoZW4tZWdyZXNzLXByb3RlY3Rpb24tZnJhbWV3b3JrQGlldGYub3JnPC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjsNCiBTaGVsbCBOYWth c2ggJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOlNoZWxsLk5h a2FzaEBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNoZWxsLk5h a2FzaEBlY2l0ZWxlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7Ow0KIE1pY2hhZWwgR29yb2tob3Zza3kgJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuR29yb2tob3Zza3lAZWNpdGVsZS5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5NaWNoYWVsLkdvcm9raG92c2t5QGVjaXRlbGUu Y29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5zcHJpbmdAaWV0Zi5vcmc8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+OyBEbWl0cnkgVmFsZG1hbg0KICZs dDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpEbWl0cnkuVmFsZG1h bkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRtaXRyeS5WYWxk bWFuQGVjaXRlbGUuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDs7DQogUm9uIFNkYXlvb3IgJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0ibWFpbHRvOlJvbi5TZGF5b29yQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+Um9uLlNkYXlvb3JAZWNpdGVsZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCiBSb3RlbSBDb2hlbiAmbHQ7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Sb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTwv c3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KPC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7kuLvpopg8L3NwYW4+PC9iPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+IFJlOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNw ZWNpZmljDQogbGFiZWwgc3BhY2VzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBTYXNoYSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGEgbG90IGZvciB0YWtpbmcg dGltZSB0byByZWFkIHRoZSBkb2N1bWVudCBhbmQgcHJvdmlkaW5nIHRoZSBtdWNoIGFwcHJlY2lh dGVkIGNvbW1lbnRzLiBQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGlubGluZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+T24gV2VkLCBKdWwgMTksIDIwMTcgYXQgMTI6MDkgQU0sIEFsZXhhbmRlciBWYWlu c2h0ZWluICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4m Z3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUgcmVhZCB0 aGUNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmlu Zy1tcGxzLWFueWNhc3Qtc2VnbWVudHMtMDEiIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0PC9hPiBp biBxdWVzdGlvbiwgYW5kLCBmcm9tIG15IFBPViwgaXQgZGVmaW5lcywgdW5kZXIgdGhlIG5hbWUg b2YgVmlydHVhbCBMRklCLCAmbmJzcDs8aT5hIGRlZGljYXRlZCBjb250ZXh0LXNwZWNpZmljIGxh YmVsIHNwYWNlPC9pPiAoc2VlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTMzMSIgdGFyZ2V0PSJfYmxhbmsiPlJGQyA1MzMxPC9hPikgJm5ic3A7aW4gdGhlIGRldmlj ZXMgdGhhdCBhcmUgYXNzaWduZWQgd2l0aCBvbmUgb3IgbW9yZSBhbnljYXN0IHNlZ21lbnRzLCBh bmQgdXNlcyB0aGUgbGFiZWxzIHN1Y2ggZGV2aWNlcyBhbGxvY2F0ZSBmb3IgdGhlc2Ugc2VnbWVu dHMgYXMgdGhlDQo8aT5jb250ZXh0IGxhYmVsczwvaT4gaWRlbnRpZnlpbmcgdGhpcyBzcGFjZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPltQdXNocGFzaXNd IFllcywgdGhhdCBpcyBjb3JyZWN0LiBJIHdpbGwgYWRkIGEgcmVmZXJlbmNlIHRvIFJGQyA1MzMx IGluIHRoZSBuZXh0IHZlcnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgbXkgdW5kZXJzdGFuZGluZyBpcyBj b3JyZWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtODI0ODIwMTE0NzM2NzYx Mjg1bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtNzQ5MDc0Njg3 Mjk5NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPkV4cGxpY2l0IG1hcHBpbmcgb2YgdGhlIGRlZmluaXRpb25z IG9mIHRoZSBkcmFmdCB0byBhbHJlYWR5IGRlZmluZWQgYW5kIHdlbGwtdW5kZXJzdG9vZCBNUExT IGFyY2hpdGVjdHVyYWwgbWVjaGFuaXNtcyB3b3VsZCBncmVhdGx5IGltcHJvdmUgaXRzIHJlYWRh YmlsaXR5LiBJdCB3b3VsZCBhbHNvIGdyZWF0bHkgaGVscCB0aGUgaW1wbGVtZW50ZXJzLCBlc3Bl Y2lhbGx5IGlmIHRoZXkgaGF2ZSBhbHJlYWR5DQogaW1wbGVtZW50ZWQgKG9yIGNvbnNpZGVyIGlt cGxlbWVudGF0aW9uIG9mKSBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBpbiB0aGVpciBk ZXZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVz aHBhc2lzXSBBdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoaXMgZHJhZnQsIHRoZXJlIHdlcmUgYWxy ZWFkeSBzb21lIGltcGxlbWVudGF0aW9ucyBvZiBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNl ICwgYW5kIHNvIEkgdGhvdWdodCBhZGRpbmcgdGhvc2UgaW1wbGVtZW50YXRpb24NCiBkZXRhaWxz IHdpbGwgbm90IGJlIHVzZWZ1bCwgZXNwZWNpYWxseSBkdXJpbmcgdGhlIFdHTEMgbGFzdCBjYWxs cy4gSW1wbGVtZW50YXRpb24gbWludXRlIGRldGFpbHMgYXJlIG5vdCB3ZWxjb21lIEkgYXNzdW1l IGZyb20gdGhlIFdHTEMgcmV2aWV3cyBJIGhhdmUgZ29uZSB0aHJvdWdoIHNvIGZhci4gQnV0IGwg Y2FuIHN1cmUgYWRkIHNvbWUgcmVmZXJlbmNlIHRvIFJGQzUzMzEuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im04MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5 ODM1MjE5NDY1ODFnbWFpbC1tLTMxNTcwNTIzMjcxODU2ODY3Nm03NDkwNzQ2ODcyOTk2NTE5MTQ0 bXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+QWRkaW5nIHRoZSByZWxldmFudCByZWZlcmVuY2VzIChpbmNsdWRpbmcgYSBu b3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQyA1MzMxKSBzZWVtcyBuZWNlc3Nhcnk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5Vc2luZyBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBhbmQgY29u dGV4dCBsYWJlbHMgaW4gY29uanVuY3Rpb24gd2l0aCBhbnljYXN0IChvciBhbnljYXN0LWxpa2Up IGZ1bmN0aW9uYWxpdHkgJm5ic3A7aW4gTVBMUyBpcyBub3QgbmV3LiBPbmUgZXhhbXBsZSAoYXMg aW5kaWNhdGVkDQogaW4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9tcGxzL2N1cnJlbnQvbXNnMTI2NTkuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KRXJpYyBS b3NlbuKAmXMgZW1haWw8L2E+KSAmbmJzcDtpcyB0aGUgUFcgRW5kcG9pbnQgRmFzdCBGYWlsdXJl IFByb3RlY3Rpb24gbWVjaGFuaXNtIGRlZmluZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4MTA0IiB0YXJnZXQ9Il9ibGFuayI+UkZDIDgxMDQ8L2E+LiA8bzpw Pg0KPC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+W1B1c2hwYXNpc10g WWVzLCB1c2Ugb2YgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSBpcyBub3QgbmV3LiBBbmQg d29ya2luZyBpbiBKdW5pcGVyIGZvciBzb21ldGltZSBJIGhhdmUgYSBnb29kIGlkZWEgb2YgaXRz IGFwcGxpY2F0aW9uLiBCdXQgdXNpbmcgaXQgdG8gcHJvdmlkZQ0KIGEgbWVhbnMgdG8gZG8gYW55 Y2FzdCBzZWdtZW50cyB1c2luZyBNUExTIGRhdGFwbGFuZSBpcyB2ZXJ5IG11Y2ggbmV3LiBBbmQg dG8gbXkga25vd2xlZGdlIHRpbGwgZGF0ZSB0aGVyZSBpcyBubyBvdGhlciB3YXkgdG8gYWNoaWV2 ZSB0aGlzIHdpdGhvdXQgcmVjdXJzaXZlIGxhYmVsIGxvb2t1cCBhbmQgY29udGV4dC1zcGVjaWZp YyBsYWJlbCBzcGFjZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIGFuYWxvZ3kgbG9va3MgaW1wb3J0YW50IHRvIG1lIHNpbmNlIGFueWNh c3QgZ3JvdXBzIGFyZSBjb21tb25seSBjb25zaWRlcmVkIGFzIGEgcHJvdGVjdGlvbiBtZWNoYW5p c20gKGFuZCBub3QganVzdCBhcyBhIGxvYWQtYmFsYW5jaW5nIG9uZSkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVzaHBhc2lzXSBBY3R1YWxseSwgYWJv dXQgdGhlIHVzZWNhc2VzIEkgaGF2ZSBkaXNjdXNzZWQgc29tZSBvZiB0aGUgb3BlcmF0b3JzIEkg aGF2ZSBkaXNjdXNzZWQgd2l0aCBzbyBmYXIgb24gdGhpcywgYWxtb3N0IGFsbCB0aGVtIGFyZSBh Ym91dCBwb2xpY3ktYmFzZWQtcm91dGluZywNCiAmbmJzcDtsb2FkLWJhbGFuY2luZyBhbmQgcHJv dmlkaW5nIGRpc2pvaW50IHBhdGhzLiBPZmZjb3Vyc2UgZGlzam9pbnQgcGF0aHMgY2FuIGJlIHVz ZWQgZm9yIHByb3RlY3Rpb24gYXMgd2VsbCBhcyBsb2FkLWJhbGFuY2luZy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFsc28gdGhpbmsgdGhh dCByZWxhdGlvbnNoaXBzIGJldHdlZW4gdGhpcyBkcmFmdCBhbmQgdGhlDQo8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zaGVuLW1wbHMtZWdyZXNzLXByb3Rl Y3Rpb24tZnJhbWV3b3JrLz9pbmNsdWRlX3RleHQ9MSIgdGFyZ2V0PSJfYmxhbmsiPg0KZWdyZXNz IHByb3RlY3Rpb24gZnJhbWV3b3JrPC9hPiBvbmUgYXJlIHdvcnRoIGxvb2tpbmcgYXQgY2FyZWZ1 bGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+W1B1c2hw YXNpc10gRmlyc3QgdGhlIGVncmVzcyBwcm90ZWN0aW9uIGRyYWZ0cyBkb2VzIG5vdCBzZWVtIHRv IGhhdmUgZ29uZSB0aHJvdWdoIFdHIGFkb3B0aW9uLiBOZXh0IHRob3VnaCB0aGVzZSB0d28gZHJh ZnRzIHVzZSB0aGUgc2FtZSBtZWNoYW5pc21zLCB0aGUgZXhhY3QNCiBwcm9ibGVtIHRoZXkgdHJ5 IHRvIHNvbHZlIGFyZSBub3QgZXhhY3RseSByZWxhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk5ldmVydGhlbGVzcywgSSB2YWx1ZSB5b3Vy IGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhbmQgdGhvdWdodHMgYSBsb3QsIGFuZCB0aGFuayB5b3Ug dmVyeSBtdWNoIGZvciBwcm92aWRpbmcgdGhlIGluc2lnaHRzLiBJIHdpbGwgZGVmaW5pdGVseSB3 b3JrIG9uIHRoZW0gYW5kIGFkZHJlc3MNCiB0aGVtIGluIHRoZSBuZXh0IGRyYWZ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBvbmNl IGFnYWluIGFuZCBiZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LVB1c2hwYXNp czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPk15IDJjLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNhc2hhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ T2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkVtYWlsOiZuYnNwOyZuYnNw Ow0KPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+ DQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkg YW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzDQo8YnI+DQpDT05GSURFTlRJQUwgYW5k IHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcw0KPGJyPg0KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVz IGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsDQo8 YnI+DQphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE4Ddggemi502mbxchina_-- From nobody Thu Aug 10 01:57:43 2017 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 3D488127868 for ; Thu, 10 Aug 2017 01:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gnXhw7_GCYkW for ; Thu, 10 Aug 2017 01:57:38 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44004126E3A for ; Thu, 10 Aug 2017 01:57:38 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id u207so746681ywc.3; Thu, 10 Aug 2017 01:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OW+3EcI9bIw47ICrlHjtyviUCs7BB4OjxX8tiWJBe6I=; b=IhxzPN1JdJNWztviDbZDUOE5E2/NYdocGwsWptj5bz10DwtdNQsXxeKcZ4SzZ5hiNY qYzXxfj/UKRqUJkWKUzlSZGpnWbqtsUir6sZyqFHDt4sn+Q60Q6S1qGJPKifqW7YaECA qqPBtRHiMpcc7DHVVOUc7UPVX0yXHp4sBLUKKSBHTggBpECwTn2yzB81QBBboSsuiKQQ nCcvSTne0uKk67boVhMFhYUkF7JI0WAAMR3DPvrUVEg8tELl8nYzfAeAKWKqnlvKPh70 bXycU9+hTA18O1CG3Ak7OJZv2hnEM+Ix7VwIkCgEqNWDhlYSnHm3nR7gi0ODWSF7F5En DkJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OW+3EcI9bIw47ICrlHjtyviUCs7BB4OjxX8tiWJBe6I=; b=htA9gBRoKCioYNUS2oY+0ZW6d01C7Wctdj7J0VUEd6mV/oSmdgST8r/iQM4VqY1N42 wn/imp3nrDU4VL+bNieibuyCA6qjvrJcES9ZcwzXN0T/TJ5JCDJqXdk+yFETWMp9W/oN VdH26mAHaBcDup1kZ92OkkRtHfwiEWZlXp71exsj49XeyF7kFUHDqvbHH4t2KEWnaxCh kfXKD+O3XPV2Hk8iTtCp8z5/L3x7Kr9AJ9HAs/P1fmZ56v9rfYaNjU8gvSTVFUiB0hM1 f7ieVPMUasKn9SLJebhW6qhm2vOzELuTiCgGQaCBuv7IY51HsxsEzgGum4K2T71K8E4F 2pCA== X-Gm-Message-State: AHYfb5jZe+6fWc3Mjh0D94FdBM63v6ns1fSp0NcahI9wtJn335guKm0u Dk+bHJleMBA28S78raCdRDOrklfGWQ== X-Received: by 10.13.251.194 with SMTP id l185mr9206493ywf.244.1502355457157; Thu, 10 Aug 2017 01:57:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.11 with HTTP; Thu, 10 Aug 2017 01:57:36 -0700 (PDT) In-Reply-To: References: From: Pushpasis Sarkar Date: Thu, 10 Aug 2017 14:27:36 +0530 Message-ID: To: "Chengli (Distance)" Cc: "draft-ietf-spring-anycast-segment@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07f5c059cfe3055662634f" Archived-At: Subject: Re: [spring] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIEFueWNhc3Qg?= =?utf-8?q?segments_and_context-specific_label_spaces?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 08:57:42 -0000 --94eb2c07f5c059cfe3055662634f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chengli, Once again please see answer inline On Thu, Aug 10, 2017 at 12:58 PM, Chengli (Distance) wrote: > Hi Pushpasis, > > > > Thank you for your answer, now I understand the reason of it. Please read > detailed reply inline. > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Pushpasis Sarkar [mailto:pushpasis.ietf@gm= ail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B48=E6=9C=8810=E6=97= =A5 14:29 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Chengli (Distance) > *=E6=8A=84=E9=80=81:* draft-ietf-spring-anycast-segment@ietf.org; spring@= ietf.org > *=E4=B8=BB=E9=A2=98:* Re: =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: [spring= ] Anycast segments and context-specific label > spaces > > > > Hi Chengli, > > > > Please refer to Figure 4 in the draft. In this example CA-SRGB is > 2000-3000. But let's say A1 for some hardware specific reason cannot > support label range 2000-3000. So it uses a regular SRGB range of > 1000-2000. If A1 would not have advertised the anycast prefix segment 100 > with P-Flag 1, the topmost label in the incoming packet will be pf the ne= xt > segment as 2030. As you may know already the first label lookup for any > packet is always in the default-LFIB, and 2030 cannot be programmed in > default-LFIB of A1. Then the packet shall have to be dropped. > > > > [Cheng]So this is the main reason of why we need to keep anycast label. > Because the CAPSL can not be programmed in default-LFIB, if the node can > not support the label range. It really makes sense. Keeping the APSL as t= he > top label is a good way to solve this problem! Awesome! > > > > But I have another question: In this case, range 2000-3000 can not be > supported by A1, so why it can be used in V-LFIB? Actually, I am curio= us > about the hardware specific reason, and why this reason does not affect > V-LFIB. > [Pushpasis] In this case 2000-3000 could not be supported for default-LFIB coz some internal usecase may have already reserved it from the default-LFIB.. so labels from cannot be used for switching external traffic in the regular LFIB table.. But if the lookup is directed to another LFIB we can use whatever label range required.. Now the first label of packet always end up in a lookup under default-LFIB.. But the next one can always be directed to another LFIB table (provided the hardware supports switching LFIBs).. This method is not new and there has been few drafts (e.g. egress-protection) that prescribes using a different LFIB.. We just used it for solving the any cast problem.. Thanks and regards, -Pushpasis > > > > Instead we force the penultimate hop to not POP the topmost label but swa= p > it with 1100. When the packet comes with 1100 as the topmost label it hit= s > the corresponding entry in default-LFIB which pops it and launches a look= up > for 2030 in a separate V-LFIB. > > [Cheng] Yes. > > > > The purpose of CA-SRGB is for the source of the traffic to derive the > label to be used for the next segment following a anycast segment. The > label to be used for the first anycast segment is always derived from the > regular SRGB of the next hop node(s). > > [Cheng] Yes, this is a really amazing idea! > > > > Now question is why cannot we use CASRGB to be same as SRGB everywhere? > But If that would have been possible there would have been no reason for > this draft to be written in the first place. The reason that cannot be > possible is different vendors support different label-ranges in their > hardware. And the biggest reason all vendors cannot support the same rang= e > is because of platform-specific legacy limitations in their hardwares. Fo= r > example the device used for the node A1 already reserves the label range > 2000-3000 for some internal switching and cannot be made available for th= e > regular MPLS switching and forwarding. Also as per MPLS architecture labe= ls > are of local significance and there should be no solution based on global > label ranges. > > > > > > [Cheng]No, I understand the reason totally. Your work is really useful. > Good job! > > > > Hope your questions are answered now. > > > > Thanks > > -Pushpasis > > > > > > On Thu, Aug 10, 2017 at 9:22 AM, Chengli (Distance) > wrote: > > Hi Pushpasis, > > > > Wow, it has been two years since you made the presentation. Thank you fo= r > your slides. I have read it all. > > > > But I still have some questions. Please find them inline. > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Pushpasis Sarkar [mailto:pushpasis.ietf@= gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2017=E5=B9=B48=E6=9C=889=E6=97= =A5 23:31 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* Chengli (Distance) > *=E4=B8=BB=E9=A2=98**:* Re: =E7=AD=94=E5=A4=8D: [spring] Anycast segments= and context-specific label > spaces > > > > Hope you have already gone through my presentation presented way back in > 2015.. If not here is the link to the same. > > > > https://www.ietf.org/proceedings/93/slides/slides-93-spring-1.pdf > > > > On Wed, Aug 9, 2017 at 8:58 PM, Pushpasis Sarkar > wrote: > > Hi Chengli, > > > > Thanks a lot for taking time to read the draft and provide comments. > Please find answers inline > > > > On Wed, Aug 9, 2017 at 2:04 PM, Chengli (Distance) > wrote: > > Hi Pushpasis, > > I am a new learner of SR. Recently, I read the draft > ,= and > I haa some questions about it. Some of them are about the algorithm, whil= e > the others are about the context. > > > > 1: If CA-SRGB need to be configured the same among all nodes, which means > all nodes can understand the label in CA-SRGB. If so, why do we need to s= et > P-Flag when the node has a different CA-SRGB range with SRGB. Without the > Anycast-SID, the node can understand CA-SRGB and process CAPSL as well. > Why do we need to keep Anycast label? To indentify the next label is a > CPASL? > > [Pushpasis] Yes this is needed for the node that originated the CAPSL. In > case the CA-SRGB is different from regular SRGB the packet must come in > with the CAPSL at the top of the stack so that it pops and does a recursi= ve > label lookup with the next label in stack.. > > > > [Cheng] If there is an action supporting to look up in V-LFIB, why not us= e > CAPSL as the key in Default LFIB directly? If so, P-Flag can be leaved 0= , > and node will receive a packet with the CAPSL as the top label no matter > it=E2=80=99s CA-SRGB is the same as SRGB or not. In default LFIB, there s= hould be > an entry for CAPSL, and it=E2=80=99s action is to look up CAPSL in V-LFIB= . I am not > sure that whether it can work or not. > > > > In this way, configuration will be much easier. > > > > In summary, in my POV, we can pop the previous anycast label so that the > node can receive the same packet no matter it=E2=80=99s CA-SRGB is the sa= me as SRGB > or not. But I suppose that there must be some reasons that you didn=E2= =80=99t > propose a solution like this. If possible, can you be kind to tell me ? > > > > I think the reason maybe: > > > > Keeping the anycast label can reduce the entries of LFIB. If we use CAPS= L > as the top label, we need to install entries for all CAPSLs in LFIB and i= n > V-LFIB as well. But if we keep Anycast label as the top label, we only > need to install one entry for Anycast label, and one entry for each CAPSL > in V-LFIB. > > > > > > 2: In section 3.2.2 of your draft, it says that > > This document introduces a separate virtual label lookup table > > (hereafter referred to as Virtual LFIB or V-LFIB), that represents a > > label space which is also separate from the actual label space > > represented by the default LFIB. The label value may be present in > > both the default and Virtual LFIB. > > > > If V-LFIB represents a label space separated from the label space > represented by LFIB, why label value may be present in both of them? If > this is right, I suppose that the reason of keeping anycast label is to > identify the next label should be looked up in V-LFIB instead of default > one. > > [Pushpasis] Theoretically all label-spaces can be independent and may hav= e > the same label programmed in them with different forwarding semantics. > However from the following text we proposed a separate V-LFIB if and only > if CA-SRGB is different from SRGB.. > > > > [Cheng] I am wondering that what is the label-space? I think it is the > range of label. But it seems not. > > > > > > " Such a device MUST add an entry in the Virtual LFIB for each unicast > > and anycast prefix segments learnt from a remote device, if and only > > if the same prefix has not been provisioned on the device. The > > device SHOULD NOT add an entry for any of the Anycast or Node prefix > > segments that it has advertised itself. However if the device has > > learnt any anycast prefix segment from a remote device, and the same > > is not provisioned on this device, the device MUST include the same > > in the Virtual LFIB table. > > " > > > > [Pushpasis] If the label at the top of the stack belongs to CA-SRGB then > it has to be for anycast prefix originated remotely and the packet actual= ly > hits an entry in the default LFIB first.. But because the label is > corresponding to an anycast prefix we install a recursive lookup with the > V-LFIB as the next table.. When the lookup for next label in stack in the > VLFIB is launched that label maybe associated with CA_SRGB or > default-SRGB.. The V-LFIB is needed to only faclitate lookup of the next > label.. In case the CA-SRGB is same as default-SRGB I hope your realize > that a recursive label is not required. It is important to realize that > CA-SRGB is invented to actually avoid recursive label lookup.. The device= s > that uses same CA-SRGB as default SRGB need not support recursive label > lookup in the hardware.. > > > > [Cheng] Yes, I can understand the logic of your solution. What if we pop > the anycast label ,and let the CAPSL to hit the entry in LFIB, and then > execute the action of looking up CAPSL in V-LFIB. Why do we need to keep > the anycast label ? This is my question. > > > > > > > > 3: I found out some strange statements in the draft: > > > > a) Page 11 > > For example, on device A1, the prefix SID 10 (originated by PE3) is > > reachable through its neighbors A3 and A4. And as per the SRGB > > advertised by A3 and A4, the labels allocated by A3 and A4 are 3030 > > and 4030 respectively > > > > I suppose that the prefix SID is 30 instead of 10. > > [Pushpasis] Yes you are right. I have already got this comment from one o= f > the WG members. I will rectifying this in next version. > > b) Page 14 > > This is because on node A1=EF=BC=88Is it A2?=EF=BC=89 the domain-wide CA-= SRGB is identical to the local SRGB provisioned on A2. > > > > c) Page 14 > > While forwarding to A2, since A2 would > > have advertised the anycast SID 100 with P-Flag (No-PHP) unset, R1 > > shall POP the incoming label 7100 before forwarding it to R1(Is it A2= ?). > > [Pushpasis] Yes you are right. I have already got this comment as well > from one of the WG members. I will rectifying this in next version. > > > > Thanks a lot for comments and thoughts. > > > > Best regards > > -Pushpasis > > > > > > Thank you for your good job! > > > > Regards, > > Cheng > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* spring [mailto:spring-bounces@ietf.org] = *=E4=BB=A3=E8=A1=A8* Pushpasis Sarkar > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2017=E5=B9=B47=E6=9C=8820=E6=97= =A5 12:35 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* Alexander Vainshtein > *=E6=8A=84=E9=80=81**:* mpls@ietf.org; draft-ietf-spring-anycast-segment@= ietf.org; > draft-mpls-shen-egress-protection-framework@ietf.org; Shell Nakash < > Shell.Nakash@ecitele.com>; Michael Gorokhovsky < > Michael.Gorokhovsky@ecitele.com>; spring@ietf.org; Dmitry Valdman < > Dmitry.Valdman@ecitele.com>; Ron Sdayoor ; Rotem > Cohen > *=E4=B8=BB=E9=A2=98**:* Re: [spring] Anycast segments and context-specifi= c label spaces > > > > Hi Sasha, > > > > Thanks a lot for taking time to read the document and providing the much > appreciated comments. Please find some comments inline. > > > > > > On Wed, Jul 19, 2017 at 12:09 AM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote: > > Hi all, > > I have read the draft > > in question, and, from my POV, it defines, under the name of Virtual LFIB= , *a > dedicated context-specific label space* (see RFC 5331 > ) in the devices that are assigned > with one or more anycast segments, and uses the labels such devices > allocate for these segments as the *context labels* identifying this > space. > > [Pushpasis] Yes, that is correct. I will add a reference to RFC 5331 in > the next version. > > > > > > If my understanding is correct: > > =C2=B7 Explicit mapping of the definitions of the draft to alread= y > defined and well-understood MPLS architectural mechanisms would greatly > improve its readability. It would also greatly help the implementers, > especially if they have already implemented (or consider implementation o= f) > context-specific label spaces in their devices > > [Pushpasis] At the time of writing this draft, there were already some > implementations of context-specific label space , and so I thought adding > those implementation details will not be useful, especially during the WG= LC > last calls. Implementation minute details are not welcome I assume from t= he > WGLC reviews I have gone through so far. But l can sure add some referenc= e > to RFC5331. > > =C2=B7 Adding the relevant references (including a normative refe= rence > to RFC 5331) seems necessary > > > > Using context-specific label spaces and context labels in conjunction wit= h > anycast (or anycast-like) functionality in MPLS is not new. One example > (as indicated in Eric Rosen=E2=80=99s email > ) is > the PW Endpoint Fast Failure Protection mechanism defined in RFC 8104 > . > > [Pushpasis] Yes, use of context-specific label space is not new. And > working in Juniper for sometime I have a good idea of its application. Bu= t > using it to provide a means to do anycast segments using MPLS dataplane i= s > very much new. And to my knowledge till date there is no other way to > achieve this without recursive label lookup and context-specific label > spaces. > > > > The analogy looks important to me since anycast groups are commonly > considered as a protection mechanism (and not just as a load-balancing on= e). > > [Pushpasis] Actually, about the usecases I have discussed some of the > operators I have discussed with so far on this, almost all them are about > policy-based-routing, load-balancing and providing disjoint paths. > Offcourse disjoint paths can be used for protection as well as > load-balancing. > > > > I also think that relationships between this draft and the egress > protection framework > > one are worth looking at carefully. > > [Pushpasis] First the egress protection drafts does not seem to have gone > through WG adoption. Next though these two drafts use the same mechanisms= , > the exact problem they try to solve are not exactly related. > > > > Nevertheless, I value your comments, suggestions and thoughts a lot, and > thank you very much for providing the insights. I will definitely work on > them and address them in the next draft. > > > > Thanks once again and best regards, > > -Pushpasis > > > > > > My 2c, > > 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. > ____________________________________________________________ > _______________ > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > --94eb2c07f5c059cfe3055662634f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chengli,

Once again please see answe= r inline

On = Thu, Aug 10, 2017 at 12:58 PM, Chengli (Distance) <chengli13@huawei.com= > wrote:

Hi Pushpasis,

=C2=A0

Thank you for your ans= wer, now I understand the reason of it. Please read detailed reply inline.<= u>

=C2=A0

=C2=A0

=E5=8F=91= =E4=BB=B6=E4=BA=BA: Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= :=E5=B9=B48= =E6=9C=8810=E6=97=A5 14:29
=E6=94=B6=E4=BB=B6=E4=BA=BA: Chengli (Distance) <chengli13@huawei.com>
=E6=8A=84=E9=80=81: draft-ietf-spring-anycast-segment@ietf.org; spring@ietf.org
=E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: [spring] Anycast segments a= nd context-specific label spaces

=C2=A0

Hi Chengli,

=C2=A0

Please refer to Figure 4 in the= draft. In this example CA-SRGB is 2000-3000. But let's say A1 for some= hardware specific reason cannot support label range 2000-3000. So it uses = a regular SRGB range of 1000-2000. If A1 would not have advertised the anycast prefix segment 100 with P-Flag 1, th= e topmost label in the incoming packet will be pf the next segment as 2030.= As you may know already the first label lookup for any packet is always in= the default-LFIB, and 2030 cannot be programmed in default-LFIB of A1. Then the packet shall have to be drop= ped.

=C2=A0

[Cheng]So this is the main reaso= n of why we need to keep anycast label. Because =C2=A0the CAPSL can not be = programmed in default-LFIB, if the node can not support the label range. It really makes sense. Keeping the APSL as the top label is a= good way to solve this problem! Awesome!

=C2=A0

But I have another question: In this ca= se, range 2000-3000 can not be supported by A1, so why it can be used in V-= LFIB? =C2=A0=C2=A0=C2=A0Actually, I am curious about the hardware specific reason, and why this reason does not affect V-LFIB.

[Pushpasis] In this case 2000-3000 c= ould not be supported for default-LFIB coz some internal usecase may have a= lready reserved it from the default-LFIB.. so labels from cannot be used fo= r switching external traffic in the regular LFIB table.. But if the lookup = is directed to another LFIB we can use whatever label range required.. Now = the first label of packet always end up in a lookup under default-LFIB.. Bu= t the next one can always be directed to another LFIB table (provided the h= ardware supports switching LFIBs).. This method is not new and there has be= en few drafts (e.g. egress-protection) that prescribes using a different LF= IB.. We just used it for solving the any cast problem..=C2=A0
Thanks and regards,
-Pushpasis

=C2=A0

=C2=A0

Instead we force the penultimat= e hop to not POP the topmost label but swap it with 1100. When the packet c= omes with 1100 as the topmost label it hits the corresponding entry in defa= ult-LFIB which pops it and launches a lookup for 2030 in a separate V-LFIB.=C2=A0

[Cheng]= Yes.

=C2=A0

The purpose of CA-SRGB is for t= he source of the traffic to derive the label to be used for the next segmen= t following a anycast segment. The label to be used for the first anycast s= egment is always derived from the regular SRGB of the next hop node(s).=C2=A0

[Cheng]= Yes, this is a really amazing idea!

=C2=A0

Now question is why cannot we u= se CASRGB to be same as SRGB everywhere? But If that would have been possib= le there would have been no reason for this draft to be written in the firs= t place. The reason that cannot be possible is different vendors support different label-ranges in their hardware. And= the biggest reason all vendors cannot support the same range is because of= platform-specific legacy limitations in their hardwares. For example the d= evice used for the node A1 already reserves the label range 2000-3000 for some internal switching and cannot = be made available for the regular MPLS switching and forwarding. Also as pe= r MPLS architecture labels are of local significance and there should be no= solution based on global label ranges.=C2=A0

= =C2=A0

=C2=A0

[Cheng]= No, I understand the reason totally. Your work is really useful. Good job!<= u>

=C2=A0

Hope your questions are answere= d now.

=C2=A0

Thanks

-Pushpasis=

=C2=A0

=C2=A0

On Thu, Aug 10, 2017 at 9:22 AM= , Chengli (Distance) <chengli13@huawei.com> wrote:

Hi=C2=A0 Pushpasis,

=C2=A0

Wow, it has been two years since you ma= de the presentation.=C2=A0 Thank you for your slides. I have read it all.

=C2=A0

But I still have some questions. Please= find them inline.

=C2=A0

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2017=E5=B9=B48=E6=9C=889=E6=97=A5 23:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Chengli (Distance) <chengli13@huawei.co= m>
=E4=B8=BB=E9=A2=98= : Re: =E7=AD=94=E5=A4=8D: [spring] Anycast segments and context-specific label spaces

=C2=A0

Hope you have already gone thro= ugh my presentation presented way back in 2015.. If not here is the link to= the same. =C2=A0

=C2=A0

=C2=A0

On Wed, Aug 9, 2017 at 8:58 PM,= Pushpasis Sarkar <pushpasis.ietf@gmail.com> wrote:

Hi Chengli,

=C2=A0

Thanks a lot for taking time to= read the draft and provide comments. Please find answers inline<= /u>

=C2=A0

On Wed, Aug 9, 2017 at 2:04 PM,= Chengli (Distance) <chengli13@huawei.com> wrote:

Hi Pushpasis,

I am a new learner of = SR. Recently, I read the draft, and I haa some questions about it. Som= e of them are about the algorithm, while the others are about the context.

=C2=A0

1: If CA-SRGB need to = be configured the same among all nodes, which means all nodes can understand the label in CA-SRGB. If so, why do we need to set P-Flag when = the node has a different CA-SRGB range with SRGB. Without the Anycast-SID, = the node can understand CA-SRGB and process CAPSL as well.=C2=A0 Why do we = need to keep Anycast label? To indentify the next label is a CPASL?=C2=A0=

[Pushpasis] Yes this is needed = for the node that originated the CAPSL. In case the CA-SRGB is different fr= om regular SRGB the packet must come in with the CAPSL at the top of the stack so that it pops and does a recursive label lookup = with the next label in stack..=C2=A0

=C2=A0

[Cheng] If there is an action supportin= g to look up in V-LFIB, why not use CAPSL as the key in Default LFIB directly?=C2=A0 If so, P-Flag can be leaved 0, and node will receive = a packet with the CAPSL as the top label no matter it=E2=80=99s CA-SRGB is = the same as SRGB or not. In default LFIB, there should be an entry for CAPS= L, and it=E2=80=99s action is to look up CAPSL in V-LFIB. I am not sure that whether it can work or not.

=C2=A0

In this way, configuration will be much= easier.=C2=A0

=C2=A0

In summary, in my POV, we can pop the p= revious anycast label so that the node can receive the same packet no matter it=E2=80=99s CA-SRGB is the same as SRGB or not. But I suppose t= hat =C2=A0there must be some reasons that you didn=E2=80=99t=C2=A0 propose = a solution like this. If possible, can you be kind to tell me ?

=C2=A0

I think the reason maybe:

=C2=A0

Keeping the anycast label can reduce th= e entries of LFIB.=C2=A0 If we use CAPSL as the top label, we need to install entries for all CAPSLs in LFIB and in V-LFIB as well. But if we ke= ep Anycast label as the top label,=C2=A0 we only need to install one entry = for Anycast label, and one entry for each CAPSL in V-LFIB.

=C2=A0

=C2=A0

2: In section 3.2.2 of= your draft, it says that

This document i= ntroduces a separate virtual label lookup table=

=C2=A0=C2=A0 (hereafter referred to as Virtual LFIB or V-LFIB), tha= t represents a

=C2=A0=C2=A0 label space which is also separate from the actual lab= el space

=C2=A0=C2=A0 represented by the default LFIB.=C2=A0 The label value= may be present in

=C2=A0=C2=A0 both the default and Virtual LFIB.

=C2=A0

If V-LFIB represents a= label space separated from the label space represented by LFIB, why label value may be present in both of them?=C2=A0 If this is right, I = suppose that the reason of keeping anycast label is to identify the next la= bel should be looked up in V-LFIB instead of default one.

[Pushpasis] Theoretically all l= abel-spaces can be independent and may have the same label programmed in th= em with different forwarding semantics. However from the following text we proposed a separate V-LFIB if and only if CA-SRGB is= different from SRGB..=C2=A0

=C2=A0<= /span>

[Cheng] I am wondering that what is the= label-space? I think it is the range of label. But it seems not.

=C2=A0

=C2=A0

" Such a device MUST add an entry = in the Virtual LFIB for each unicast<= /u>

=C2=A0=C2=
=A0 and anycast prefix segments learnt from a remote device, if and only
=C2=A0=C2=
=A0 if the same prefix has not been provisioned on the device.=C2=A0 The
=C2=A0=C2=
=A0 device SHOULD NOT add an entry for any of the Anycast or Node prefix
=C2=A0=C2=
=A0 segments that it has advertised itself.=C2=A0 However if the device has=

=C2=A0=C2=
=A0 learnt any anycast prefix segment from a remote device, and the same
=C2=A0=C2=
=A0 is not provisioned on this device, the device MUST include the same
=C2=A0=C2=
=A0 in the Virtual LFIB table.

"

=C2=A0

[Pushpasis] If the label at the= top of the stack belongs to CA-SRGB then it has to be for anycast prefix o= riginated remotely and the packet actually hits an entry in the default LFIB first.. But because the label is corresponding to an a= nycast prefix we install a recursive lookup with the V-LFIB as the next tab= le.. When the lookup for next label in stack in the VLFIB is launched that = label maybe associated with CA_SRGB or default-SRGB.. The V-LFIB is needed to only faclitate lookup of the nex= t label..=C2=A0 In case the CA-SRGB is same as default-SRGB I hope your rea= lize that a recursive label is not required. It is important to realize tha= t CA-SRGB is invented to actually avoid recursive label lookup.. The devices that uses same CA-SRGB as default SRG= B need not support recursive label lookup in the hardware..=C2=A0=

=C2=A0<= /span>

[Cheng] Yes, I can understand the logic= of your solution.=C2=A0 What if we pop the anycast label ,and let the CAPSL to hit the entry in LFIB, and then execute the action of looking up = CAPSL in V-LFIB.=C2=A0 Why do we need to keep the anycast label ? This is m= y question.

=C2=A0

=C2=A0

=C2=A0

3: I found out some st= range statements in the draft:

=C2=A0

a)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Page 11= 

For example, on device A1, the p=
refix SID 10 (originated by PE3) is
=C2=A0=C2=
=A0 reachable through its neighbors A3 and A4.=C2=A0 And as per the SRGB
=C2=A0=C2=
=A0 advertised by A3 and A4, the labels allocated by A3 and A4 are 3030

=C2=A0=C2=A0 and 4030 respectively

=C2=A0<= /u>

I suppose that the prefix SID is 30 instead o= f 10.

[Pushpasis] Yes you are right. = I have already got this comment from one of the WG members. I will rectifyi= ng this in next version.=C2=A0

b)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Page 14= 

This is be=
cause on node A1=EF=BC=88Is it A2?=EF=BC=
=89 the domain-wide CA-SRGB is identi=
cal to the local SRGB provisioned on A2. 
=C2=A0

c)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Page 14= 

While forw=
arding to A2, since A2 would
=C2=A0 =C2=A0=C2=A0have advertised the =
anycast SID 100 with P-Flag (No-PHP) unset, R1
 =C2=A0=C2=A0=C2=A0sh=
all POP the incoming label 7100 before forwarding it to R1(Is it A2?).

[Pushpasis] Yes you are right. = I have already got this comment as well from one of the WG members. I will = rectifying this in next version.=C2=A0

=C2=A0

Thanks a lot for comments and t= houghts.=C2=A0

=C2=A0

Best regards

-Pushpa= sis

=C2=A0

=C2=A0

Thank you for your goo= d job!

=C2=A0

Regards,

Cheng

=C2=A0

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org= ] =E4=BB=A3=E8=A1=A8= Pushpasis Sarkar
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2017=E5=B9=B47=E6=9C=8820=E6=97=A5 12:35
=E6=94=B6=E4=BB=B6=E4=BA=BA: Alexander Vainshtein <= Alexander.Vainshtein@ecitele.com>
=E6=8A=84=E9=80=81= : mpls@ietf.org; draft-ietf-spring-anycast-segment@ietf= .org; draft-mpls-shen-egress-prote= ction-framework@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Arial"= ,sans-serif">>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.<= wbr>com>; spring@ietf.org; Dmitry Valdman <Dmitry.Valdman@ecitele.com>; Ron Sdayoor <Ron.Sdayoor@ecitele.com>; Rotem Cohen <Rotem.Cohen@ecitele.com>
=E4=B8=BB=E9=A2=98= : Re: [spring] Anycast segments and = context-specific label spaces

=C2=A0

Hi Sasha,<= /p>

=C2=A0

Thanks a lot for taking time to= read the document and providing the much appreciated comments. Please find= some comments inline.

=C2=A0

=C2=A0

On Wed, Jul 19, 2017 at 12:09 A= M, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Hi all,

I have read the draft in question, and, from my POV, it defines, under the name of Virt= ual LFIB, =C2=A0a dedicated context-specific label space (see RFC 5331<= /a>) =C2=A0in the devices that are assigned with one or more anycast segmen= ts, and uses the labels such devices allocate for these segments as the context labels identifying this space.

[Pushpasis] Yes, that is correc= t. I will add a reference to RFC 5331 in the next version.

=C2=A0

=C2=A0

If my understanding is correct:=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Explicit mapping of the definitions of the draf= t to already defined and well-understood MPLS architectural mechanisms woul= d greatly improve its readability. It would also greatly help the implement= ers, especially if they have already implemented (or consider implementation of) context-specific label spaces = in their devices

[Pushpasis] At the time of writ= ing this draft, there were already some implementations of context-specific= label space , and so I thought adding those implementation details will not be useful, especially during the WGLC last calls. Impleme= ntation minute details are not welcome I assume from the WGLC reviews I hav= e gone through so far. But l can sure add some reference to RFC5331.=

[Pushpasis] Yes, use of context= -specific label space is not new. And working in Juniper for sometime I hav= e a good idea of its application. But using it to provide a means to do anycast segments using MPLS dataplane is very much new. And = to my knowledge till date there is no other way to achieve this without rec= ursive label lookup and context-specific label spaces.=

=C2=A0

The analogy looks important to = me since anycast groups are commonly considered as a protection mechanism (= and not just as a load-balancing one).

[Pushpasis] Actually, about the= usecases I have discussed some of the operators I have discussed with so f= ar on this, almost all them are about policy-based-routing, =C2=A0load-balancing and providing disjoint paths. Offcourse disjoint path= s can be used for protection as well as load-balancing.

=C2=A0

[Pushpasis] First the egress pr= otection drafts does not seem to have gone through WG adoption. Next though= these two drafts use the same mechanisms, the exact problem they try to solve are not exactly related.

=C2=A0

Nevertheless, I value your comm= ents, suggestions and thoughts a lot, and thank you very much for providing= the insights. I will definitely work on them and address them in the next draft.

=C2=A0

Thanks once again and best rega= rds,

-Pushpasis=

=C2=A0

=C2=A0

My 2c,

Sasha

=C2=A0

Office: +972-39266302=

Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexa= nder.Vainshtein@ecitele.com

=C2=A0


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

=
_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--94eb2c07f5c059cfe3055662634f-- From nobody Thu Aug 10 02:05:16 2017 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 048D613266D for ; Thu, 10 Aug 2017 02:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Yuc4i2sbWtCR for ; Thu, 10 Aug 2017 02:05:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B09B13266C for ; Thu, 10 Aug 2017 02:05:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTC37361; Thu, 10 Aug 2017 09:05:05 +0000 (GMT) Received: from DGGEMI403-HUB.china.huawei.com (10.3.17.136) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 10 Aug 2017 10:05:02 +0100 Received: from DGGEMI502-MBX.china.huawei.com ([169.254.4.150]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0301.000; Thu, 10 Aug 2017 17:04:59 +0800 From: "Chengli (Distance)" To: Pushpasis Sarkar CC: "draft-ietf-spring-anycast-segment@ietf.org" , "spring@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogW3NwcmluZ10gQW55Y2FzdCBzZWdt?= =?utf-8?Q?ents_and_context-specific_label_spaces?= Thread-Index: AdMAXJkJ1clImMhlSCmQwtRBBfPkPwAcdcyABAO96EAAAPCngAAAFegAACfggdD//7uzgP//b1cQgAC6PQD//3jq4A== Date: Thu, 10 Aug 2017 09:04:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE8Bdggemi502mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.598C21C2.0175, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.150, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c311bd9a164f10b04aeb1701453295ef Archived-At: Subject: [spring] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiAg?= =?utf-8?q?Anycast_segments_and_context-specific_label_spaces?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 09:05:15 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE8Bdggemi502mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUHVzaHBhc2lzLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoISBUaGlzIGlzIHdoYXQgSSB3YW50 LiAgVGhlIGludGVybmFsIHVzZSBjYXNlcyBtYXkgcmVzZXJ2ZSB0aGUgcmFuZ2Ugc28gdGhhdCBp dCBjYW4gbm90IGJlIHVzZWQgYnkgZXh0ZXJuYWwgdXNlIGNhc2VzLg0KRGVmaW5pdGVseSwgIHdl IGNhbiB1c2UgYW55IGxhYmVsIHJhbmdlIGluIHRoZSDigJhuZXh04oCZIExGSUIuDQoNClRoYW5r IHlvdSBhZ2FpbiENCg0KQmVzdCByZWdhcmRzLA0KQ2hlbmcNCg0K5Y+R5Lu25Lq6OiBQdXNocGFz aXMgU2Fya2FyIFttYWlsdG86cHVzaHBhc2lzLmlldGZAZ21haWwuY29tXQ0K5Y+R6YCB5pe26Ze0 OiAyMDE35bm0OOaciDEw5pelIDE2OjU4DQrmlLbku7bkuro6IENoZW5nbGkgKERpc3RhbmNlKSA8 Y2hlbmdsaTEzQGh1YXdlaS5jb20+DQrmioTpgIE6IGRyYWZ0LWlldGYtc3ByaW5nLWFueWNhc3Qt c2VnbWVudEBpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnDQrkuLvpopg6IFJlOiDnrZTlpI06IOet lOWkjTog562U5aSNOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNwZWNp ZmljIGxhYmVsIHNwYWNlcw0KDQpIaSBDaGVuZ2xpLA0KDQpPbmNlIGFnYWluIHBsZWFzZSBzZWUg YW5zd2VyIGlubGluZQ0KDQpPbiBUaHUsIEF1ZyAxMCwgMjAxNyBhdCAxMjo1OCBQTSwgQ2hlbmds aSAoRGlzdGFuY2UpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbTxtYWlsdG86Y2hlbmdsaTEzQGh1YXdl aS5jb20+PiB3cm90ZToNCkhpIFB1c2hwYXNpcywNCg0KVGhhbmsgeW91IGZvciB5b3VyIGFuc3dl ciwgbm93IEkgdW5kZXJzdGFuZCB0aGUgcmVhc29uIG9mIGl0LiBQbGVhc2UgcmVhZCBkZXRhaWxl ZCByZXBseSBpbmxpbmUuDQoNCg0K5Y+R5Lu25Lq6OiBQdXNocGFzaXMgU2Fya2FyIFttYWlsdG86 cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPG1haWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb20+ XQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDEw5pelIDE0OjI5DQrmlLbku7bkuro6IENoZW5n bGkgKERpc3RhbmNlKSA8Y2hlbmdsaTEzQGh1YXdlaS5jb208bWFpbHRvOmNoZW5nbGkxM0BodWF3 ZWkuY29tPj4NCuaKhOmAgTogZHJhZnQtaWV0Zi1zcHJpbmctYW55Y2FzdC1zZWdtZW50QGlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLXNwcmluZy1hbnljYXN0LXNlZ21lbnRAaWV0Zi5vcmc+OyBz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCuS4u+mimDogUmU6IOetlOWk jTog562U5aSNOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNwZWNpZmlj IGxhYmVsIHNwYWNlcw0KDQpIaSBDaGVuZ2xpLA0KDQpQbGVhc2UgcmVmZXIgdG8gRmlndXJlIDQg aW4gdGhlIGRyYWZ0LiBJbiB0aGlzIGV4YW1wbGUgQ0EtU1JHQiBpcyAyMDAwLTMwMDAuIEJ1dCBs ZXQncyBzYXkgQTEgZm9yIHNvbWUgaGFyZHdhcmUgc3BlY2lmaWMgcmVhc29uIGNhbm5vdCBzdXBw b3J0IGxhYmVsIHJhbmdlIDIwMDAtMzAwMC4gU28gaXQgdXNlcyBhIHJlZ3VsYXIgU1JHQiByYW5n ZSBvZiAxMDAwLTIwMDAuIElmIEExIHdvdWxkIG5vdCBoYXZlIGFkdmVydGlzZWQgdGhlIGFueWNh c3QgcHJlZml4IHNlZ21lbnQgMTAwIHdpdGggUC1GbGFnIDEsIHRoZSB0b3Btb3N0IGxhYmVsIGlu IHRoZSBpbmNvbWluZyBwYWNrZXQgd2lsbCBiZSBwZiB0aGUgbmV4dCBzZWdtZW50IGFzIDIwMzAu IEFzIHlvdSBtYXkga25vdyBhbHJlYWR5IHRoZSBmaXJzdCBsYWJlbCBsb29rdXAgZm9yIGFueSBw YWNrZXQgaXMgYWx3YXlzIGluIHRoZSBkZWZhdWx0LUxGSUIsIGFuZCAyMDMwIGNhbm5vdCBiZSBw cm9ncmFtbWVkIGluIGRlZmF1bHQtTEZJQiBvZiBBMS4gVGhlbiB0aGUgcGFja2V0IHNoYWxsIGhh dmUgdG8gYmUgZHJvcHBlZC4NCg0KW0NoZW5nXVNvIHRoaXMgaXMgdGhlIG1haW4gcmVhc29uIG9m IHdoeSB3ZSBuZWVkIHRvIGtlZXAgYW55Y2FzdCBsYWJlbC4gQmVjYXVzZSAgdGhlIENBUFNMIGNh biBub3QgYmUgcHJvZ3JhbW1lZCBpbiBkZWZhdWx0LUxGSUIsIGlmIHRoZSBub2RlIGNhbiBub3Qg c3VwcG9ydCB0aGUgbGFiZWwgcmFuZ2UuIEl0IHJlYWxseSBtYWtlcyBzZW5zZS4gS2VlcGluZyB0 aGUgQVBTTCBhcyB0aGUgdG9wIGxhYmVsIGlzIGEgZ29vZCB3YXkgdG8gc29sdmUgdGhpcyBwcm9i bGVtISBBd2Vzb21lIQ0KDQpCdXQgSSBoYXZlIGFub3RoZXIgcXVlc3Rpb246IEluIHRoaXMgY2Fz ZSwgcmFuZ2UgMjAwMC0zMDAwIGNhbiBub3QgYmUgc3VwcG9ydGVkIGJ5IEExLCBzbyB3aHkgaXQg Y2FuIGJlIHVzZWQgaW4gVi1MRklCPyAgICBBY3R1YWxseSwgSSBhbSBjdXJpb3VzIGFib3V0IHRo ZSBoYXJkd2FyZSBzcGVjaWZpYyByZWFzb24sIGFuZCB3aHkgdGhpcyByZWFzb24gZG9lcyBub3Qg YWZmZWN0IFYtTEZJQi4NCltQdXNocGFzaXNdIEluIHRoaXMgY2FzZSAyMDAwLTMwMDAgY291bGQg bm90IGJlIHN1cHBvcnRlZCBmb3IgZGVmYXVsdC1MRklCIGNveiBzb21lIGludGVybmFsIHVzZWNh c2UgbWF5IGhhdmUgYWxyZWFkeSByZXNlcnZlZCBpdCBmcm9tIHRoZSBkZWZhdWx0LUxGSUIuLiBz byBsYWJlbHMgZnJvbSBjYW5ub3QgYmUgdXNlZCBmb3Igc3dpdGNoaW5nIGV4dGVybmFsIHRyYWZm aWMgaW4gdGhlIHJlZ3VsYXIgTEZJQiB0YWJsZS4uIEJ1dCBpZiB0aGUgbG9va3VwIGlzIGRpcmVj dGVkIHRvIGFub3RoZXIgTEZJQiB3ZSBjYW4gdXNlIHdoYXRldmVyIGxhYmVsIHJhbmdlIHJlcXVp cmVkLi4gTm93IHRoZSBmaXJzdCBsYWJlbCBvZiBwYWNrZXQgYWx3YXlzIGVuZCB1cCBpbiBhIGxv b2t1cCB1bmRlciBkZWZhdWx0LUxGSUIuLiBCdXQgdGhlIG5leHQgb25lIGNhbiBhbHdheXMgYmUg ZGlyZWN0ZWQgdG8gYW5vdGhlciBMRklCIHRhYmxlIChwcm92aWRlZCB0aGUgaGFyZHdhcmUgc3Vw cG9ydHMgc3dpdGNoaW5nIExGSUJzKS4uIFRoaXMgbWV0aG9kIGlzIG5vdCBuZXcgYW5kIHRoZXJl IGhhcyBiZWVuIGZldyBkcmFmdHMgKGUuZy4gZWdyZXNzLXByb3RlY3Rpb24pIHRoYXQgcHJlc2Ny aWJlcyB1c2luZyBhIGRpZmZlcmVudCBMRklCLi4gV2UganVzdCB1c2VkIGl0IGZvciBzb2x2aW5n IHRoZSBhbnkgY2FzdCBwcm9ibGVtLi4NCg0KVGhhbmtzIGFuZCByZWdhcmRzLA0KLVB1c2hwYXNp cw0KDQoNCg0KSW5zdGVhZCB3ZSBmb3JjZSB0aGUgcGVudWx0aW1hdGUgaG9wIHRvIG5vdCBQT1Ag dGhlIHRvcG1vc3QgbGFiZWwgYnV0IHN3YXAgaXQgd2l0aCAxMTAwLiBXaGVuIHRoZSBwYWNrZXQg Y29tZXMgd2l0aCAxMTAwIGFzIHRoZSB0b3Btb3N0IGxhYmVsIGl0IGhpdHMgdGhlIGNvcnJlc3Bv bmRpbmcgZW50cnkgaW4gZGVmYXVsdC1MRklCIHdoaWNoIHBvcHMgaXQgYW5kIGxhdW5jaGVzIGEg bG9va3VwIGZvciAyMDMwIGluIGEgc2VwYXJhdGUgVi1MRklCLg0KW0NoZW5nXSBZZXMuDQoNClRo ZSBwdXJwb3NlIG9mIENBLVNSR0IgaXMgZm9yIHRoZSBzb3VyY2Ugb2YgdGhlIHRyYWZmaWMgdG8g ZGVyaXZlIHRoZSBsYWJlbCB0byBiZSB1c2VkIGZvciB0aGUgbmV4dCBzZWdtZW50IGZvbGxvd2lu ZyBhIGFueWNhc3Qgc2VnbWVudC4gVGhlIGxhYmVsIHRvIGJlIHVzZWQgZm9yIHRoZSBmaXJzdCBh bnljYXN0IHNlZ21lbnQgaXMgYWx3YXlzIGRlcml2ZWQgZnJvbSB0aGUgcmVndWxhciBTUkdCIG9m IHRoZSBuZXh0IGhvcCBub2RlKHMpLg0KW0NoZW5nXSBZZXMsIHRoaXMgaXMgYSByZWFsbHkgYW1h emluZyBpZGVhIQ0KDQpOb3cgcXVlc3Rpb24gaXMgd2h5IGNhbm5vdCB3ZSB1c2UgQ0FTUkdCIHRv IGJlIHNhbWUgYXMgU1JHQiBldmVyeXdoZXJlPyBCdXQgSWYgdGhhdCB3b3VsZCBoYXZlIGJlZW4g cG9zc2libGUgdGhlcmUgd291bGQgaGF2ZSBiZWVuIG5vIHJlYXNvbiBmb3IgdGhpcyBkcmFmdCB0 byBiZSB3cml0dGVuIGluIHRoZSBmaXJzdCBwbGFjZS4gVGhlIHJlYXNvbiB0aGF0IGNhbm5vdCBi ZSBwb3NzaWJsZSBpcyBkaWZmZXJlbnQgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBsYWJlbC1y YW5nZXMgaW4gdGhlaXIgaGFyZHdhcmUuIEFuZCB0aGUgYmlnZ2VzdCByZWFzb24gYWxsIHZlbmRv cnMgY2Fubm90IHN1cHBvcnQgdGhlIHNhbWUgcmFuZ2UgaXMgYmVjYXVzZSBvZiBwbGF0Zm9ybS1z cGVjaWZpYyBsZWdhY3kgbGltaXRhdGlvbnMgaW4gdGhlaXIgaGFyZHdhcmVzLiBGb3IgZXhhbXBs ZSB0aGUgZGV2aWNlIHVzZWQgZm9yIHRoZSBub2RlIEExIGFscmVhZHkgcmVzZXJ2ZXMgdGhlIGxh YmVsIHJhbmdlIDIwMDAtMzAwMCBmb3Igc29tZSBpbnRlcm5hbCBzd2l0Y2hpbmcgYW5kIGNhbm5v dCBiZSBtYWRlIGF2YWlsYWJsZSBmb3IgdGhlIHJlZ3VsYXIgTVBMUyBzd2l0Y2hpbmcgYW5kIGZv cndhcmRpbmcuIEFsc28gYXMgcGVyIE1QTFMgYXJjaGl0ZWN0dXJlIGxhYmVscyBhcmUgb2YgbG9j YWwgc2lnbmlmaWNhbmNlIGFuZCB0aGVyZSBzaG91bGQgYmUgbm8gc29sdXRpb24gYmFzZWQgb24g Z2xvYmFsIGxhYmVsIHJhbmdlcy4NCg0KDQpbQ2hlbmddTm8sIEkgdW5kZXJzdGFuZCB0aGUgcmVh c29uIHRvdGFsbHkuIFlvdXIgd29yayBpcyByZWFsbHkgdXNlZnVsLiBHb29kIGpvYiENCg0KSG9w ZSB5b3VyIHF1ZXN0aW9ucyBhcmUgYW5zd2VyZWQgbm93Lg0KDQpUaGFua3MNCi1QdXNocGFzaXMN Cg0KDQpPbiBUaHUsIEF1ZyAxMCwgMjAxNyBhdCA5OjIyIEFNLCBDaGVuZ2xpIChEaXN0YW5jZSkg PGNoZW5nbGkxM0BodWF3ZWkuY29tPG1haWx0bzpjaGVuZ2xpMTNAaHVhd2VpLmNvbT4+IHdyb3Rl Og0KSGkgIFB1c2hwYXNpcywNCg0KV293LCBpdCBoYXMgYmVlbiB0d28geWVhcnMgc2luY2UgeW91 IG1hZGUgdGhlIHByZXNlbnRhdGlvbi4gIFRoYW5rIHlvdSBmb3IgeW91ciBzbGlkZXMuIEkgaGF2 ZSByZWFkIGl0IGFsbC4NCg0KQnV0IEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9ucy4gUGxlYXNl IGZpbmQgdGhlbSBpbmxpbmUuDQoNCg0K5Y+R5Lu25Lq6OiBQdXNocGFzaXMgU2Fya2FyIFttYWls dG86cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPG1haWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5j b20+XQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDnml6UgMjM6MzENCuaUtuS7tuS6ujogQ2hl bmdsaSAoRGlzdGFuY2UpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbTxtYWlsdG86Y2hlbmdsaTEzQGh1 YXdlaS5jb20+Pg0K5Li76aKYOiBSZTog562U5aSNOiBbc3ByaW5nXSBBbnljYXN0IHNlZ21lbnRz IGFuZCBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcw0KDQpIb3BlIHlvdSBoYXZlIGFscmVh ZHkgZ29uZSB0aHJvdWdoIG15IHByZXNlbnRhdGlvbiBwcmVzZW50ZWQgd2F5IGJhY2sgaW4gMjAx NS4uIElmIG5vdCBoZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBzYW1lLg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLXNwcmluZy0xLnBkZg0KDQpP biBXZWQsIEF1ZyA5LCAyMDE3IGF0IDg6NTggUE0sIFB1c2hwYXNpcyBTYXJrYXIgPHB1c2hwYXNp cy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPj4gd3JvdGU6 DQpIaSBDaGVuZ2xpLA0KDQpUaGFua3MgYSBsb3QgZm9yIHRha2luZyB0aW1lIHRvIHJlYWQgdGhl IGRyYWZ0IGFuZCBwcm92aWRlIGNvbW1lbnRzLiBQbGVhc2UgZmluZCBhbnN3ZXJzIGlubGluZQ0K DQpPbiBXZWQsIEF1ZyA5LCAyMDE3IGF0IDI6MDQgUE0sIENoZW5nbGkgKERpc3RhbmNlKSA8Y2hl bmdsaTEzQGh1YXdlaS5jb208bWFpbHRvOmNoZW5nbGkxM0BodWF3ZWkuY29tPj4gd3JvdGU6DQpI aSBQdXNocGFzaXMsDQpJIGFtIGEgbmV3IGxlYXJuZXIgb2YgU1IuIFJlY2VudGx5LCBJIHJlYWQg dGhlIGRyYWZ0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1t cGxzLWFueWNhc3Qtc2VnbWVudHMtMDE+LCBhbmQgSSBoYWEgc29tZSBxdWVzdGlvbnMgYWJvdXQg aXQuIFNvbWUgb2YgdGhlbSBhcmUgYWJvdXQgdGhlIGFsZ29yaXRobSwgd2hpbGUgdGhlIG90aGVy cyBhcmUgYWJvdXQgdGhlIGNvbnRleHQuDQoNCjE6IElmIENBLVNSR0IgbmVlZCB0byBiZSBjb25m aWd1cmVkIHRoZSBzYW1lIGFtb25nIGFsbCBub2Rlcywgd2hpY2ggbWVhbnMgYWxsIG5vZGVzIGNh biB1bmRlcnN0YW5kIHRoZSBsYWJlbCBpbiBDQS1TUkdCLiBJZiBzbywgd2h5IGRvIHdlIG5lZWQg dG8gc2V0IFAtRmxhZyB3aGVuIHRoZSBub2RlIGhhcyBhIGRpZmZlcmVudCBDQS1TUkdCIHJhbmdl IHdpdGggU1JHQi4gV2l0aG91dCB0aGUgQW55Y2FzdC1TSUQsIHRoZSBub2RlIGNhbiB1bmRlcnN0 YW5kIENBLVNSR0IgYW5kIHByb2Nlc3MgQ0FQU0wgYXMgd2VsbC4gIFdoeSBkbyB3ZSBuZWVkIHRv IGtlZXAgQW55Y2FzdCBsYWJlbD8gVG8gaW5kZW50aWZ5IHRoZSBuZXh0IGxhYmVsIGlzIGEgQ1BB U0w/DQpbUHVzaHBhc2lzXSBZZXMgdGhpcyBpcyBuZWVkZWQgZm9yIHRoZSBub2RlIHRoYXQgb3Jp Z2luYXRlZCB0aGUgQ0FQU0wuIEluIGNhc2UgdGhlIENBLVNSR0IgaXMgZGlmZmVyZW50IGZyb20g cmVndWxhciBTUkdCIHRoZSBwYWNrZXQgbXVzdCBjb21lIGluIHdpdGggdGhlIENBUFNMIGF0IHRo ZSB0b3Agb2YgdGhlIHN0YWNrIHNvIHRoYXQgaXQgcG9wcyBhbmQgZG9lcyBhIHJlY3Vyc2l2ZSBs YWJlbCBsb29rdXAgd2l0aCB0aGUgbmV4dCBsYWJlbCBpbiBzdGFjay4uDQoNCltDaGVuZ10gSWYg dGhlcmUgaXMgYW4gYWN0aW9uIHN1cHBvcnRpbmcgdG8gbG9vayB1cCBpbiBWLUxGSUIsIHdoeSBu b3QgdXNlIENBUFNMIGFzIHRoZSBrZXkgaW4gRGVmYXVsdCBMRklCIGRpcmVjdGx5PyAgSWYgc28s IFAtRmxhZyBjYW4gYmUgbGVhdmVkIDAsIGFuZCBub2RlIHdpbGwgcmVjZWl2ZSBhIHBhY2tldCB3 aXRoIHRoZSBDQVBTTCBhcyB0aGUgdG9wIGxhYmVsIG5vIG1hdHRlciBpdOKAmXMgQ0EtU1JHQiBp cyB0aGUgc2FtZSBhcyBTUkdCIG9yIG5vdC4gSW4gZGVmYXVsdCBMRklCLCB0aGVyZSBzaG91bGQg YmUgYW4gZW50cnkgZm9yIENBUFNMLCBhbmQgaXTigJlzIGFjdGlvbiBpcyB0byBsb29rIHVwIENB UFNMIGluIFYtTEZJQi4gSSBhbSBub3Qgc3VyZSB0aGF0IHdoZXRoZXIgaXQgY2FuIHdvcmsgb3Ig bm90Lg0KDQpJbiB0aGlzIHdheSwgY29uZmlndXJhdGlvbiB3aWxsIGJlIG11Y2ggZWFzaWVyLg0K DQpJbiBzdW1tYXJ5LCBpbiBteSBQT1YsIHdlIGNhbiBwb3AgdGhlIHByZXZpb3VzIGFueWNhc3Qg bGFiZWwgc28gdGhhdCB0aGUgbm9kZSBjYW4gcmVjZWl2ZSB0aGUgc2FtZSBwYWNrZXQgbm8gbWF0 dGVyIGl04oCZcyBDQS1TUkdCIGlzIHRoZSBzYW1lIGFzIFNSR0Igb3Igbm90LiBCdXQgSSBzdXBw b3NlIHRoYXQgIHRoZXJlIG11c3QgYmUgc29tZSByZWFzb25zIHRoYXQgeW91IGRpZG7igJl0ICBw cm9wb3NlIGEgc29sdXRpb24gbGlrZSB0aGlzLiBJZiBwb3NzaWJsZSwgY2FuIHlvdSBiZSBraW5k IHRvIHRlbGwgbWUgPw0KDQpJIHRoaW5rIHRoZSByZWFzb24gbWF5YmU6DQoNCktlZXBpbmcgdGhl IGFueWNhc3QgbGFiZWwgY2FuIHJlZHVjZSB0aGUgZW50cmllcyBvZiBMRklCLiAgSWYgd2UgdXNl IENBUFNMIGFzIHRoZSB0b3AgbGFiZWwsIHdlIG5lZWQgdG8gaW5zdGFsbCBlbnRyaWVzIGZvciBh bGwgQ0FQU0xzIGluIExGSUIgYW5kIGluIFYtTEZJQiBhcyB3ZWxsLiBCdXQgaWYgd2Uga2VlcCBB bnljYXN0IGxhYmVsIGFzIHRoZSB0b3AgbGFiZWwsICB3ZSBvbmx5IG5lZWQgdG8gaW5zdGFsbCBv bmUgZW50cnkgZm9yIEFueWNhc3QgbGFiZWwsIGFuZCBvbmUgZW50cnkgZm9yIGVhY2ggQ0FQU0wg aW4gVi1MRklCLg0KDQoNCjI6IEluIHNlY3Rpb24gMy4yLjIgb2YgeW91ciBkcmFmdCwgaXQgc2F5 cyB0aGF0DQpUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYSBzZXBhcmF0ZSB2aXJ0dWFsIGxhYmVs IGxvb2t1cCB0YWJsZQ0KICAgKGhlcmVhZnRlciByZWZlcnJlZCB0byBhcyBWaXJ0dWFsIExGSUIg b3IgVi1MRklCKSwgdGhhdCByZXByZXNlbnRzIGENCiAgIGxhYmVsIHNwYWNlIHdoaWNoIGlzIGFs c28gc2VwYXJhdGUgZnJvbSB0aGUgYWN0dWFsIGxhYmVsIHNwYWNlDQogICByZXByZXNlbnRlZCBi eSB0aGUgZGVmYXVsdCBMRklCLiAgVGhlIGxhYmVsIHZhbHVlIG1heSBiZSBwcmVzZW50IGluDQog ICBib3RoIHRoZSBkZWZhdWx0IGFuZCBWaXJ0dWFsIExGSUIuDQoNCklmIFYtTEZJQiByZXByZXNl bnRzIGEgbGFiZWwgc3BhY2Ugc2VwYXJhdGVkIGZyb20gdGhlIGxhYmVsIHNwYWNlIHJlcHJlc2Vu dGVkIGJ5IExGSUIsIHdoeSBsYWJlbCB2YWx1ZSBtYXkgYmUgcHJlc2VudCBpbiBib3RoIG9mIHRo ZW0/ICBJZiB0aGlzIGlzIHJpZ2h0LCBJIHN1cHBvc2UgdGhhdCB0aGUgcmVhc29uIG9mIGtlZXBp bmcgYW55Y2FzdCBsYWJlbCBpcyB0byBpZGVudGlmeSB0aGUgbmV4dCBsYWJlbCBzaG91bGQgYmUg bG9va2VkIHVwIGluIFYtTEZJQiBpbnN0ZWFkIG9mIGRlZmF1bHQgb25lLg0KW1B1c2hwYXNpc10g VGhlb3JldGljYWxseSBhbGwgbGFiZWwtc3BhY2VzIGNhbiBiZSBpbmRlcGVuZGVudCBhbmQgbWF5 IGhhdmUgdGhlIHNhbWUgbGFiZWwgcHJvZ3JhbW1lZCBpbiB0aGVtIHdpdGggZGlmZmVyZW50IGZv cndhcmRpbmcgc2VtYW50aWNzLiBIb3dldmVyIGZyb20gdGhlIGZvbGxvd2luZyB0ZXh0IHdlIHBy b3Bvc2VkIGEgc2VwYXJhdGUgVi1MRklCIGlmIGFuZCBvbmx5IGlmIENBLVNSR0IgaXMgZGlmZmVy ZW50IGZyb20gU1JHQi4uDQoNCltDaGVuZ10gSSBhbSB3b25kZXJpbmcgdGhhdCB3aGF0IGlzIHRo ZSBsYWJlbC1zcGFjZT8gSSB0aGluayBpdCBpcyB0aGUgcmFuZ2Ugb2YgbGFiZWwuIEJ1dCBpdCBz ZWVtcyBub3QuDQoNCg0KIiBTdWNoIGEgZGV2aWNlIE1VU1QgYWRkIGFuIGVudHJ5IGluIHRoZSBW aXJ0dWFsIExGSUIgZm9yIGVhY2ggdW5pY2FzdA0KDQogICBhbmQgYW55Y2FzdCBwcmVmaXggc2Vn bWVudHMgbGVhcm50IGZyb20gYSByZW1vdGUgZGV2aWNlLCBpZiBhbmQgb25seQ0KDQogICBpZiB0 aGUgc2FtZSBwcmVmaXggaGFzIG5vdCBiZWVuIHByb3Zpc2lvbmVkIG9uIHRoZSBkZXZpY2UuICBU aGUNCg0KICAgZGV2aWNlIFNIT1VMRCBOT1QgYWRkIGFuIGVudHJ5IGZvciBhbnkgb2YgdGhlIEFu eWNhc3Qgb3IgTm9kZSBwcmVmaXgNCg0KICAgc2VnbWVudHMgdGhhdCBpdCBoYXMgYWR2ZXJ0aXNl ZCBpdHNlbGYuICBIb3dldmVyIGlmIHRoZSBkZXZpY2UgaGFzDQoNCiAgIGxlYXJudCBhbnkgYW55 Y2FzdCBwcmVmaXggc2VnbWVudCBmcm9tIGEgcmVtb3RlIGRldmljZSwgYW5kIHRoZSBzYW1lDQoN CiAgIGlzIG5vdCBwcm92aXNpb25lZCBvbiB0aGlzIGRldmljZSwgdGhlIGRldmljZSBNVVNUIGlu Y2x1ZGUgdGhlIHNhbWUNCg0KICAgaW4gdGhlIFZpcnR1YWwgTEZJQiB0YWJsZS4NCiINCg0KW1B1 c2hwYXNpc10gSWYgdGhlIGxhYmVsIGF0IHRoZSB0b3Agb2YgdGhlIHN0YWNrIGJlbG9uZ3MgdG8g Q0EtU1JHQiB0aGVuIGl0IGhhcyB0byBiZSBmb3IgYW55Y2FzdCBwcmVmaXggb3JpZ2luYXRlZCBy ZW1vdGVseSBhbmQgdGhlIHBhY2tldCBhY3R1YWxseSBoaXRzIGFuIGVudHJ5IGluIHRoZSBkZWZh dWx0IExGSUIgZmlyc3QuLiBCdXQgYmVjYXVzZSB0aGUgbGFiZWwgaXMgY29ycmVzcG9uZGluZyB0 byBhbiBhbnljYXN0IHByZWZpeCB3ZSBpbnN0YWxsIGEgcmVjdXJzaXZlIGxvb2t1cCB3aXRoIHRo ZSBWLUxGSUIgYXMgdGhlIG5leHQgdGFibGUuLiBXaGVuIHRoZSBsb29rdXAgZm9yIG5leHQgbGFi ZWwgaW4gc3RhY2sgaW4gdGhlIFZMRklCIGlzIGxhdW5jaGVkIHRoYXQgbGFiZWwgbWF5YmUgYXNz b2NpYXRlZCB3aXRoIENBX1NSR0Igb3IgZGVmYXVsdC1TUkdCLi4gVGhlIFYtTEZJQiBpcyBuZWVk ZWQgdG8gb25seSBmYWNsaXRhdGUgbG9va3VwIG9mIHRoZSBuZXh0IGxhYmVsLi4gIEluIGNhc2Ug dGhlIENBLVNSR0IgaXMgc2FtZSBhcyBkZWZhdWx0LVNSR0IgSSBob3BlIHlvdXIgcmVhbGl6ZSB0 aGF0IGEgcmVjdXJzaXZlIGxhYmVsIGlzIG5vdCByZXF1aXJlZC4gSXQgaXMgaW1wb3J0YW50IHRv IHJlYWxpemUgdGhhdCBDQS1TUkdCIGlzIGludmVudGVkIHRvIGFjdHVhbGx5IGF2b2lkIHJlY3Vy c2l2ZSBsYWJlbCBsb29rdXAuLiBUaGUgZGV2aWNlcyB0aGF0IHVzZXMgc2FtZSBDQS1TUkdCIGFz IGRlZmF1bHQgU1JHQiBuZWVkIG5vdCBzdXBwb3J0IHJlY3Vyc2l2ZSBsYWJlbCBsb29rdXAgaW4g dGhlIGhhcmR3YXJlLi4NCg0KW0NoZW5nXSBZZXMsIEkgY2FuIHVuZGVyc3RhbmQgdGhlIGxvZ2lj IG9mIHlvdXIgc29sdXRpb24uICBXaGF0IGlmIHdlIHBvcCB0aGUgYW55Y2FzdCBsYWJlbCAsYW5k IGxldCB0aGUgQ0FQU0wgdG8gaGl0IHRoZSBlbnRyeSBpbiBMRklCLCBhbmQgdGhlbiBleGVjdXRl IHRoZSBhY3Rpb24gb2YgbG9va2luZyB1cCBDQVBTTCBpbiBWLUxGSUIuICBXaHkgZG8gd2UgbmVl ZCB0byBrZWVwIHRoZSBhbnljYXN0IGxhYmVsID8gVGhpcyBpcyBteSBxdWVzdGlvbi4NCg0KDQoN CjM6IEkgZm91bmQgb3V0IHNvbWUgc3RyYW5nZSBzdGF0ZW1lbnRzIGluIHRoZSBkcmFmdDoNCg0K DQphKSAgICAgICBQYWdlIDExDQoNCkZvciBleGFtcGxlLCBvbiBkZXZpY2UgQTEsIHRoZSBwcmVm aXggU0lEIDEwIChvcmlnaW5hdGVkIGJ5IFBFMykgaXMNCg0KICAgcmVhY2hhYmxlIHRocm91Z2gg aXRzIG5laWdoYm9ycyBBMyBhbmQgQTQuICBBbmQgYXMgcGVyIHRoZSBTUkdCDQoNCiAgIGFkdmVy dGlzZWQgYnkgQTMgYW5kIEE0LCB0aGUgbGFiZWxzIGFsbG9jYXRlZCBieSBBMyBhbmQgQTQgYXJl IDMwMzANCiAgIGFuZCA0MDMwIHJlc3BlY3RpdmVseQ0KDQpJIHN1cHBvc2UgdGhhdCB0aGUgcHJl Zml4IFNJRCBpcyAzMCBpbnN0ZWFkIG9mIDEwLg0KW1B1c2hwYXNpc10gWWVzIHlvdSBhcmUgcmln aHQuIEkgaGF2ZSBhbHJlYWR5IGdvdCB0aGlzIGNvbW1lbnQgZnJvbSBvbmUgb2YgdGhlIFdHIG1l bWJlcnMuIEkgd2lsbCByZWN0aWZ5aW5nIHRoaXMgaW4gbmV4dCB2ZXJzaW9uLg0KDQpiKSAgICAg ICBQYWdlIDE0DQoNClRoaXMgaXMgYmVjYXVzZSBvbiBub2RlIEEx77yISXMgaXQgQTI/77yJIHRo ZSBkb21haW4td2lkZSBDQS1TUkdCIGlzIGlkZW50aWNhbCB0byB0aGUgbG9jYWwgU1JHQiBwcm92 aXNpb25lZCBvbiBBMi4NCg0KDQoNCmMpICAgICAgIFBhZ2UgMTQNCg0KV2hpbGUgZm9yd2FyZGlu ZyB0byBBMiwgc2luY2UgQTIgd291bGQNCg0KICAgIGhhdmUgYWR2ZXJ0aXNlZCB0aGUgYW55Y2Fz dCBTSUQgMTAwIHdpdGggUC1GbGFnIChOby1QSFApIHVuc2V0LCBSMQ0KDQogICAgc2hhbGwgUE9Q IHRoZSBpbmNvbWluZyBsYWJlbCA3MTAwIGJlZm9yZSBmb3J3YXJkaW5nIGl0IHRvIFIxKElzIGl0 IEEyPykuDQpbUHVzaHBhc2lzXSBZZXMgeW91IGFyZSByaWdodC4gSSBoYXZlIGFscmVhZHkgZ290 IHRoaXMgY29tbWVudCBhcyB3ZWxsIGZyb20gb25lIG9mIHRoZSBXRyBtZW1iZXJzLiBJIHdpbGwg cmVjdGlmeWluZyB0aGlzIGluIG5leHQgdmVyc2lvbi4NCg0KVGhhbmtzIGEgbG90IGZvciBjb21t ZW50cyBhbmQgdGhvdWdodHMuDQoNCkJlc3QgcmVnYXJkcw0KLVB1c2hwYXNpcw0KDQoNClRoYW5r IHlvdSBmb3IgeW91ciBnb29kIGpvYiENCg0KUmVnYXJkcywNCkNoZW5nDQoNCg0K5Y+R5Lu25Lq6 OiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmc+XSDku6PooaggUHVzaHBhc2lzIFNhcmthcg0K5Y+R6YCB5pe26Ze0OiAy MDE35bm0N+aciDIw5pelIDEyOjM1DQrmlLbku7bkuro6IEFsZXhhbmRlciBWYWluc2h0ZWluIDxB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20+Pg0K5oqE6YCBOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPjsgZHJhZnQtaWV0Zi1zcHJpbmctYW55Y2FzdC1zZWdtZW50QGlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLXNwcmluZy1hbnljYXN0LXNlZ21lbnRAaWV0Zi5vcmc+OyBkcmFmdC1tcGxzLXNo ZW4tZWdyZXNzLXByb3RlY3Rpb24tZnJhbWV3b3JrQGlldGYub3JnPG1haWx0bzpkcmFmdC1tcGxz LXNoZW4tZWdyZXNzLXByb3RlY3Rpb24tZnJhbWV3b3JrQGlldGYub3JnPjsgU2hlbGwgTmFrYXNo IDxTaGVsbC5OYWthc2hAZWNpdGVsZS5jb208bWFpbHRvOlNoZWxsLk5ha2FzaEBlY2l0ZWxlLmNv bT4+OyBNaWNoYWVsIEdvcm9raG92c2t5IDxNaWNoYWVsLkdvcm9raG92c2t5QGVjaXRlbGUuY29t PG1haWx0bzpNaWNoYWVsLkdvcm9raG92c2t5QGVjaXRlbGUuY29tPj47IHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPjsgRG1pdHJ5IFZhbGRtYW4gPERtaXRyeS5WYWxkbWFu QGVjaXRlbGUuY29tPG1haWx0bzpEbWl0cnkuVmFsZG1hbkBlY2l0ZWxlLmNvbT4+OyBSb24gU2Rh eW9vciA8Um9uLlNkYXlvb3JAZWNpdGVsZS5jb208bWFpbHRvOlJvbi5TZGF5b29yQGVjaXRlbGUu Y29tPj47IFJvdGVtIENvaGVuIDxSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0u Q29oZW5AZWNpdGVsZS5jb20+Pg0K5Li76aKYOiBSZTogW3NwcmluZ10gQW55Y2FzdCBzZWdtZW50 cyBhbmQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXMNCg0KSGkgU2FzaGEsDQoNClRoYW5r cyBhIGxvdCBmb3IgdGFraW5nIHRpbWUgdG8gcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHByb3ZpZGlu ZyB0aGUgbXVjaCBhcHByZWNpYXRlZCBjb21tZW50cy4gUGxlYXNlIGZpbmQgc29tZSBjb21tZW50 cyBpbmxpbmUuDQoNCg0KT24gV2VkLCBKdWwgMTksIDIwMTcgYXQgMTI6MDkgQU0sIEFsZXhhbmRl ciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCkkgaGF2ZSBy ZWFkIHRoZSBkcmFmdDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJp bmctbXBscy1hbnljYXN0LXNlZ21lbnRzLTAxPiBpbiBxdWVzdGlvbiwgYW5kLCBmcm9tIG15IFBP ViwgaXQgZGVmaW5lcywgdW5kZXIgdGhlIG5hbWUgb2YgVmlydHVhbCBMRklCLCAgYSBkZWRpY2F0 ZWQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSAoc2VlIFJGQyA1MzMxPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzMxPikgIGluIHRoZSBkZXZpY2VzIHRoYXQgYXJlIGFzc2ln bmVkIHdpdGggb25lIG9yIG1vcmUgYW55Y2FzdCBzZWdtZW50cywgYW5kIHVzZXMgdGhlIGxhYmVs cyBzdWNoIGRldmljZXMgYWxsb2NhdGUgZm9yIHRoZXNlIHNlZ21lbnRzIGFzIHRoZSBjb250ZXh0 IGxhYmVscyBpZGVudGlmeWluZyB0aGlzIHNwYWNlLg0KW1B1c2hwYXNpc10gWWVzLCB0aGF0IGlz IGNvcnJlY3QuIEkgd2lsbCBhZGQgYSByZWZlcmVuY2UgdG8gUkZDIDUzMzEgaW4gdGhlIG5leHQg dmVyc2lvbi4NCg0KDQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q6DQoNCuKAoiAgICAg ICAgIEV4cGxpY2l0IG1hcHBpbmcgb2YgdGhlIGRlZmluaXRpb25zIG9mIHRoZSBkcmFmdCB0byBh bHJlYWR5IGRlZmluZWQgYW5kIHdlbGwtdW5kZXJzdG9vZCBNUExTIGFyY2hpdGVjdHVyYWwgbWVj aGFuaXNtcyB3b3VsZCBncmVhdGx5IGltcHJvdmUgaXRzIHJlYWRhYmlsaXR5LiBJdCB3b3VsZCBh bHNvIGdyZWF0bHkgaGVscCB0aGUgaW1wbGVtZW50ZXJzLCBlc3BlY2lhbGx5IGlmIHRoZXkgaGF2 ZSBhbHJlYWR5IGltcGxlbWVudGVkIChvciBjb25zaWRlciBpbXBsZW1lbnRhdGlvbiBvZikgY29u dGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXMgaW4gdGhlaXIgZGV2aWNlcw0KW1B1c2hwYXNpc10g QXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGlzIGRyYWZ0LCB0aGVyZSB3ZXJlIGFscmVhZHkgc29t ZSBpbXBsZW1lbnRhdGlvbnMgb2YgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSAsIGFuZCBz byBJIHRob3VnaHQgYWRkaW5nIHRob3NlIGltcGxlbWVudGF0aW9uIGRldGFpbHMgd2lsbCBub3Qg YmUgdXNlZnVsLCBlc3BlY2lhbGx5IGR1cmluZyB0aGUgV0dMQyBsYXN0IGNhbGxzLiBJbXBsZW1l bnRhdGlvbiBtaW51dGUgZGV0YWlscyBhcmUgbm90IHdlbGNvbWUgSSBhc3N1bWUgZnJvbSB0aGUg V0dMQyByZXZpZXdzIEkgaGF2ZSBnb25lIHRocm91Z2ggc28gZmFyLiBCdXQgbCBjYW4gc3VyZSBh ZGQgc29tZSByZWZlcmVuY2UgdG8gUkZDNTMzMS4NCg0K4oCiICAgICAgICAgQWRkaW5nIHRoZSBy ZWxldmFudCByZWZlcmVuY2VzIChpbmNsdWRpbmcgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJG QyA1MzMxKSBzZWVtcyBuZWNlc3NhcnkNCg0KVXNpbmcgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBz cGFjZXMgYW5kIGNvbnRleHQgbGFiZWxzIGluIGNvbmp1bmN0aW9uIHdpdGggYW55Y2FzdCAob3Ig YW55Y2FzdC1saWtlKSBmdW5jdGlvbmFsaXR5ICBpbiBNUExTIGlzIG5vdCBuZXcuIE9uZSBleGFt cGxlIChhcyBpbmRpY2F0ZWQgaW4gRXJpYyBSb3NlbuKAmXMgZW1haWw8aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTI2NTkuaHRtbD4pICBpcyB0 aGUgUFcgRW5kcG9pbnQgRmFzdCBGYWlsdXJlIFByb3RlY3Rpb24gbWVjaGFuaXNtIGRlZmluZWQg aW4gUkZDIDgxMDQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMDQ+Lg0KW1B1c2hw YXNpc10gWWVzLCB1c2Ugb2YgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSBpcyBub3QgbmV3 LiBBbmQgd29ya2luZyBpbiBKdW5pcGVyIGZvciBzb21ldGltZSBJIGhhdmUgYSBnb29kIGlkZWEg b2YgaXRzIGFwcGxpY2F0aW9uLiBCdXQgdXNpbmcgaXQgdG8gcHJvdmlkZSBhIG1lYW5zIHRvIGRv IGFueWNhc3Qgc2VnbWVudHMgdXNpbmcgTVBMUyBkYXRhcGxhbmUgaXMgdmVyeSBtdWNoIG5ldy4g QW5kIHRvIG15IGtub3dsZWRnZSB0aWxsIGRhdGUgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IHRvIGFj aGlldmUgdGhpcyB3aXRob3V0IHJlY3Vyc2l2ZSBsYWJlbCBsb29rdXAgYW5kIGNvbnRleHQtc3Bl Y2lmaWMgbGFiZWwgc3BhY2VzLg0KDQpUaGUgYW5hbG9neSBsb29rcyBpbXBvcnRhbnQgdG8gbWUg c2luY2UgYW55Y2FzdCBncm91cHMgYXJlIGNvbW1vbmx5IGNvbnNpZGVyZWQgYXMgYSBwcm90ZWN0 aW9uIG1lY2hhbmlzbSAoYW5kIG5vdCBqdXN0IGFzIGEgbG9hZC1iYWxhbmNpbmcgb25lKS4NCltQ dXNocGFzaXNdIEFjdHVhbGx5LCBhYm91dCB0aGUgdXNlY2FzZXMgSSBoYXZlIGRpc2N1c3NlZCBz b21lIG9mIHRoZSBvcGVyYXRvcnMgSSBoYXZlIGRpc2N1c3NlZCB3aXRoIHNvIGZhciBvbiB0aGlz LCBhbG1vc3QgYWxsIHRoZW0gYXJlIGFib3V0IHBvbGljeS1iYXNlZC1yb3V0aW5nLCAgbG9hZC1i YWxhbmNpbmcgYW5kIHByb3ZpZGluZyBkaXNqb2ludCBwYXRocy4gT2ZmY291cnNlIGRpc2pvaW50 IHBhdGhzIGNhbiBiZSB1c2VkIGZvciBwcm90ZWN0aW9uIGFzIHdlbGwgYXMgbG9hZC1iYWxhbmNp bmcuDQoNCkkgYWxzbyB0aGluayB0aGF0IHJlbGF0aW9uc2hpcHMgYmV0d2VlbiB0aGlzIGRyYWZ0 IGFuZCB0aGUgZWdyZXNzIHByb3RlY3Rpb24gZnJhbWV3b3JrPGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXNoZW4tbXBscy1lZ3Jlc3MtcHJvdGVjdGlvbi1mcmFtZXdvcmsv P2luY2x1ZGVfdGV4dD0xPiBvbmUgYXJlIHdvcnRoIGxvb2tpbmcgYXQgY2FyZWZ1bGx5Lg0KW1B1 c2hwYXNpc10gRmlyc3QgdGhlIGVncmVzcyBwcm90ZWN0aW9uIGRyYWZ0cyBkb2VzIG5vdCBzZWVt IHRvIGhhdmUgZ29uZSB0aHJvdWdoIFdHIGFkb3B0aW9uLiBOZXh0IHRob3VnaCB0aGVzZSB0d28g ZHJhZnRzIHVzZSB0aGUgc2FtZSBtZWNoYW5pc21zLCB0aGUgZXhhY3QgcHJvYmxlbSB0aGV5IHRy eSB0byBzb2x2ZSBhcmUgbm90IGV4YWN0bHkgcmVsYXRlZC4NCg0KTmV2ZXJ0aGVsZXNzLCBJIHZh bHVlIHlvdXIgY29tbWVudHMsIHN1Z2dlc3Rpb25zIGFuZCB0aG91Z2h0cyBhIGxvdCwgYW5kIHRo YW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHByb3ZpZGluZyB0aGUgaW5zaWdodHMuIEkgd2lsbCBkZWZp bml0ZWx5IHdvcmsgb24gdGhlbSBhbmQgYWRkcmVzcyB0aGVtIGluIHRoZSBuZXh0IGRyYWZ0Lg0K DQpUaGFua3Mgb25jZSBhZ2FpbiBhbmQgYmVzdCByZWdhcmRzLA0KLVB1c2hwYXNpcw0KDQoNCk15 IDJjLA0KU2FzaGENCg0KT2ZmaWNlOiArOTcyLTM5MjY2MzAyDQpDZWxsOiAgICAgICs5NzItNTQ5 MjY2MzAyDQpFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86 QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25s eSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMNCkNPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzDQp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWls LCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwNCmFuZCBhbGwgY29w aWVzIHRoZXJlb2YuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmcNCg0KDQoNCg0KDQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE8Bdggemi502mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm0t MTY0MzA0MTc0NjY5NjIzNDMzOG04MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5ODM1MjE5NDY1ODFn bWFpbC1tLTMxNTcwNTIzMjcxODU2ODY3Nm1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tMTY0MzA0MTc0 NjY5NjIzNDMzOG04MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5ODM1MjE5NDY1ODFnbWFpbC1tLTMx NTcwNTIzMjcxODU2ODY3Nm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTE2NDMwNDE3NDY2OTYyMzQz MzhtODI0ODIwMTE0NzM2NzYxMjg1bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3 MTg1Njg2NzZtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTE2NDMwNDE3NDY2 OTYyMzQzMzhtODI0ODIwMTE0NzM2NzYxMjg1bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3 MDUyMzI3MTg1Njg2NzZtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CnAubS0xNjQzMDQxNzQ2Njk2MjM0MzM4bTgyNDgyMDExNDczNjc2MTI4NW0yNDQ3NDk4MzUyMTk0 NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4NTY4Njc2bTc0OTA3NDY4NzI5OTY1MTkxNDRtc29saXN0 cGFyYWdyYXBoLCBsaS5tLTE2NDMwNDE3NDY2OTYyMzQzMzhtODI0ODIwMTE0NzM2NzYxMjg1bTI0 NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtNzQ5MDc0Njg3Mjk5NjUx OTE0NG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTE2NDMwNDE3NDY2OTYyMzQzMzhtODI0ODIwMTE0 NzM2NzYxMjg1bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtNzQ5 MDc0Njg3Mjk5NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8tMTY0 MzA0MTc0NjY5NjIzNDMzOG04MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5ODM1MjE5NDY1ODFnbWFp bC1tLTMxNTcwNTIzMjcxODU2ODY3Nm03NDkwNzQ2ODcyOTk2NTE5MTQ0bXNvbGlzdHBhcmFncmFw aDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgUHVzaHBhc2lzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFuayB5b3UgdmVyeSBtdWNoISBUaGlzIGlzIHdoYXQgSSB3YW50LiZuYnNw OyBUaGUgaW50ZXJuYWwgdXNlIGNhc2VzIG1heSByZXNlcnZlIHRoZSByYW5nZSBzbyB0aGF0IGl0 IGNhbiBub3QgYmUgdXNlZCBieSBleHRlcm5hbCB1c2UgY2FzZXMuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkRlZmluaXRlbHksJm5ic3A7IHdlIGNhbiB1c2UgYW55IGxhYmVsIHJh bmdlIGluIHRoZSDigJhuZXh04oCZIExGSUIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGFnYWlu IQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+IFB1c2hwYXNpcyBTYXJrYXIgW21haWx0bzpwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb21dDQo8 YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkemAgeaXtumXtDxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmIj4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5bm0PHNwYW4gbGFuZz0i RU4tVVMiPjg8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaXpTxzcGFuIGxh bmc9IkVOLVVTIj4NCiAxNjo1ODxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBDaGVuZ2xpIChEaXN0YW5jZSkg Jmx0O2NoZW5nbGkxM0BodWF3ZWkuY29tJmd0Ozxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBkcmFmdC1pZXRmLXNw cmluZy1hbnljYXN0LXNlZ21lbnRAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzxicj4NCjwvc3Bh bj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBSZTogPC9zcGFuPuetlOWkjTxzcGFuIGxhbmc9IkVOLVVTIj46DQo8L3NwYW4+562U5aSN PHNwYW4gbGFuZz0iRU4tVVMiPjogPC9zcGFuPuetlOWkjTxzcGFuIGxhbmc9IkVOLVVTIj46IFtz cHJpbmddIEFueWNhc3Qgc2VnbWVudHMgYW5kIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2Vz PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIENoZW5nbGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T25jZSBhZ2FpbiBwbGVhc2Ugc2VlIGFuc3dl ciBpbmxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUaHUs IEF1ZyAxMCwgMjAxNyBhdCAxMjo1OCBQTSwgQ2hlbmdsaSAoRGlzdGFuY2UpICZsdDs8YSBocmVm PSJtYWlsdG86Y2hlbmdsaTEzQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5jaGVuZ2xpMTNA aHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBQdXNocGFzaXMsPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhh bmsgeW91IGZvciB5b3VyIGFuc3dlciwgbm93IEkgdW5kZXJzdGFuZCB0aGUgcmVhc29uIG9mIGl0 LiBQbGVhc2UgcmVhZCBkZXRhaWxlZCByZXBseQ0KIGlubGluZS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuWPkeS7tuS6 ujwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCiBQdXNocGFzaXMgU2Fya2FyIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnB1c2hwYXNpcy5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnB1 c2hwYXNpcy5pZXRmQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4g MjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5bm0PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj44PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjEwPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPg0KIDE0OjI5PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+IENoZW5nbGkgKERpc3RhbmNl KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoZW5nbGkxM0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+Y2hlbmdsaTEzQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+5oqE6YCBPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5nLWFueWNhc3Qtc2VnbWVudEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtc3ByaW5nLWFueWNhc3Qtc2VnbWVudEBpZXRmLm9y ZzwvYT47DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiBSZToNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+562U5aSNPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj46DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuetlOWk jTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+OiBbc3ByaW5nXSBBbnljYXN0IHNl Z21lbnRzIGFuZCBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlczwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIENoZW5nbGksPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSByZWZlciB0byBG aWd1cmUgNCBpbiB0aGUgZHJhZnQuIEluIHRoaXMgZXhhbXBsZSBDQS1TUkdCIGlzIDIwMDAtMzAw MC4gQnV0IGxldCdzIHNheSBBMSBmb3Igc29tZSBoYXJkd2FyZSBzcGVjaWZpYyByZWFzb24gY2Fu bm90IHN1cHBvcnQgbGFiZWwgcmFuZ2UgMjAwMC0zMDAwLg0KIFNvIGl0IHVzZXMgYSByZWd1bGFy IFNSR0IgcmFuZ2Ugb2YgMTAwMC0yMDAwLiBJZiBBMSB3b3VsZCBub3QgaGF2ZSBhZHZlcnRpc2Vk IHRoZSBhbnljYXN0IHByZWZpeCBzZWdtZW50IDEwMCB3aXRoIFAtRmxhZyAxLCB0aGUgdG9wbW9z dCBsYWJlbCBpbiB0aGUgaW5jb21pbmcgcGFja2V0IHdpbGwgYmUgcGYgdGhlIG5leHQgc2VnbWVu dCBhcyAyMDMwLiBBcyB5b3UgbWF5IGtub3cgYWxyZWFkeSB0aGUgZmlyc3QgbGFiZWwgbG9va3Vw IGZvciBhbnkNCiBwYWNrZXQgaXMgYWx3YXlzIGluIHRoZSBkZWZhdWx0LUxGSUIsIGFuZCAyMDMw IGNhbm5vdCBiZSBwcm9ncmFtbWVkIGluIGRlZmF1bHQtTEZJQiBvZiBBMS4gVGhlbiB0aGUgcGFj a2V0IHNoYWxsIGhhdmUgdG8gYmUgZHJvcHBlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ W0NoZW5nXVNvIHRoaXMgaXMgdGhlIG1haW4gcmVhc29uIG9mIHdoeSB3ZSBuZWVkIHRvIGtlZXAg YW55Y2FzdCBsYWJlbC4gQmVjYXVzZSAmbmJzcDt0aGUgQ0FQU0wgY2FuIG5vdCBiZSBwcm9ncmFt bWVkDQogaW4gZGVmYXVsdC1MRklCLCBpZiB0aGUgbm9kZSBjYW4gbm90IHN1cHBvcnQgdGhlIGxh YmVsIHJhbmdlLiBJdCByZWFsbHkgbWFrZXMgc2Vuc2UuIEtlZXBpbmcgdGhlIEFQU0wgYXMgdGhl IHRvcCBsYWJlbCBpcyBhIGdvb2Qgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbSEgQXdlc29tZSE8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGhhdmUgYW5vdGhlciBxdWVz dGlvbjogSW4gdGhpcyBjYXNlLCByYW5nZSAyMDAwLTMwMDAgY2FuIG5vdCBiZSBzdXBwb3J0ZWQg YnkgQTEsIHNvIHdoeSBpdCBjYW4gYmUNCiB1c2VkIGluIFYtTEZJQj8gJm5ic3A7Jm5ic3A7Jm5i c3A7QWN0dWFsbHksIEkgYW0gY3VyaW91cyBhYm91dCB0aGUgaGFyZHdhcmUgc3BlY2lmaWMgcmVh c29uLCBhbmQgd2h5IHRoaXMgcmVhc29uIGRvZXMgbm90IGFmZmVjdCBWLUxGSUIuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+W1B1c2hwYXNpc10gSW4gdGhpcyBjYXNlIDIwMDAtMzAwMCBj b3VsZCBub3QgYmUgc3VwcG9ydGVkIGZvciBkZWZhdWx0LUxGSUIgY296IHNvbWUgaW50ZXJuYWwg dXNlY2FzZSBtYXkgaGF2ZSBhbHJlYWR5IHJlc2VydmVkIGl0IGZyb20gdGhlIGRlZmF1bHQtTEZJ Qi4uIHNvIGxhYmVscyBmcm9tIGNhbm5vdCBiZSB1c2VkIGZvciBzd2l0Y2hpbmcgZXh0ZXJuYWwg dHJhZmZpYyBpbg0KIHRoZSByZWd1bGFyIExGSUIgdGFibGUuLiBCdXQgaWYgdGhlIGxvb2t1cCBp cyBkaXJlY3RlZCB0byBhbm90aGVyIExGSUIgd2UgY2FuIHVzZSB3aGF0ZXZlciBsYWJlbCByYW5n ZSByZXF1aXJlZC4uIE5vdyB0aGUgZmlyc3QgbGFiZWwgb2YgcGFja2V0IGFsd2F5cyBlbmQgdXAg aW4gYSBsb29rdXAgdW5kZXIgZGVmYXVsdC1MRklCLi4gQnV0IHRoZSBuZXh0IG9uZSBjYW4gYWx3 YXlzIGJlIGRpcmVjdGVkIHRvIGFub3RoZXIgTEZJQiB0YWJsZSAocHJvdmlkZWQNCiB0aGUgaGFy ZHdhcmUgc3VwcG9ydHMgc3dpdGNoaW5nIExGSUJzKS4uIFRoaXMgbWV0aG9kIGlzIG5vdCBuZXcg YW5kIHRoZXJlIGhhcyBiZWVuIGZldyBkcmFmdHMgKGUuZy4gZWdyZXNzLXByb3RlY3Rpb24pIHRo YXQgcHJlc2NyaWJlcyB1c2luZyBhIGRpZmZlcmVudCBMRklCLi4gV2UganVzdCB1c2VkIGl0IGZv ciBzb2x2aW5nIHRoZSBhbnkgY2FzdCBwcm9ibGVtLi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBhbmQgcmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+LVB1c2hwYXNpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+SW5zdGVhZCB3ZSBmb3JjZSB0aGUgcGVudWx0aW1hdGUgaG9wIHRvIG5v dCBQT1AgdGhlIHRvcG1vc3QgbGFiZWwgYnV0IHN3YXAgaXQgd2l0aCAxMTAwLiBXaGVuIHRoZSBw YWNrZXQgY29tZXMgd2l0aCAxMTAwIGFzIHRoZSB0b3Btb3N0IGxhYmVsIGl0IGhpdHMgdGhlIGNv cnJlc3BvbmRpbmcNCiBlbnRyeSBpbiBkZWZhdWx0LUxGSUIgd2hpY2ggcG9wcyBpdCBhbmQgbGF1 bmNoZXMgYSBsb29rdXAgZm9yIDIwMzAgaW4gYSBzZXBhcmF0ZSBWLUxGSUIuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltDaGVuZ10gWWVzLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhl IHB1cnBvc2Ugb2YgQ0EtU1JHQiBpcyBmb3IgdGhlIHNvdXJjZSBvZiB0aGUgdHJhZmZpYyB0byBk ZXJpdmUgdGhlIGxhYmVsIHRvIGJlIHVzZWQgZm9yIHRoZSBuZXh0IHNlZ21lbnQgZm9sbG93aW5n IGEgYW55Y2FzdCBzZWdtZW50LiBUaGUgbGFiZWwgdG8gYmUgdXNlZA0KIGZvciB0aGUgZmlyc3Qg YW55Y2FzdCBzZWdtZW50IGlzIGFsd2F5cyBkZXJpdmVkIGZyb20gdGhlIHJlZ3VsYXIgU1JHQiBv ZiB0aGUgbmV4dCBob3Agbm9kZShzKS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+W0NoZW5nXSBZZXMsIHRoaXMgaXMgYSByZWFsbHkgYW1hemluZyBp ZGVhITwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Tm93IHF1ZXN0aW9uIGlzIHdoeSBjYW5ub3Qgd2UgdXNlIENBU1JHQiB0byBiZSBzYW1l IGFzIFNSR0IgZXZlcnl3aGVyZT8gQnV0IElmIHRoYXQgd291bGQgaGF2ZSBiZWVuIHBvc3NpYmxl IHRoZXJlIHdvdWxkIGhhdmUgYmVlbiBubyByZWFzb24gZm9yIHRoaXMgZHJhZnQgdG8NCiBiZSB3 cml0dGVuIGluIHRoZSBmaXJzdCBwbGFjZS4gVGhlIHJlYXNvbiB0aGF0IGNhbm5vdCBiZSBwb3Nz aWJsZSBpcyBkaWZmZXJlbnQgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBsYWJlbC1yYW5nZXMg aW4gdGhlaXIgaGFyZHdhcmUuIEFuZCB0aGUgYmlnZ2VzdCByZWFzb24gYWxsIHZlbmRvcnMgY2Fu bm90IHN1cHBvcnQgdGhlIHNhbWUgcmFuZ2UgaXMgYmVjYXVzZSBvZiBwbGF0Zm9ybS1zcGVjaWZp YyBsZWdhY3kgbGltaXRhdGlvbnMgaW4NCiB0aGVpciBoYXJkd2FyZXMuIEZvciBleGFtcGxlIHRo ZSBkZXZpY2UgdXNlZCBmb3IgdGhlIG5vZGUgQTEgYWxyZWFkeSByZXNlcnZlcyB0aGUgbGFiZWwg cmFuZ2UgMjAwMC0zMDAwIGZvciBzb21lIGludGVybmFsIHN3aXRjaGluZyBhbmQgY2Fubm90IGJl IG1hZGUgYXZhaWxhYmxlIGZvciB0aGUgcmVndWxhciBNUExTIHN3aXRjaGluZyBhbmQgZm9yd2Fy ZGluZy4gQWxzbyBhcyBwZXIgTVBMUyBhcmNoaXRlY3R1cmUgbGFiZWxzIGFyZSBvZiBsb2NhbA0K IHNpZ25pZmljYW5jZSBhbmQgdGhlcmUgc2hvdWxkIGJlIG5vIHNvbHV0aW9uIGJhc2VkIG9uIGds b2JhbCBsYWJlbCByYW5nZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltDaGVuZ11ObywgSSB1bmRlcnN0YW5kIHRoZSBy ZWFzb24gdG90YWxseS4gWW91ciB3b3JrIGlzIHJlYWxseSB1c2VmdWwuIEdvb2Qgam9iITwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5Ib3BlIHlvdXIgcXVlc3Rpb25zIGFyZSBhbnN3ZXJlZCBub3cuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+LVB1c2hwYXNpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgQXVnIDEwLCAyMDE3IGF0IDk6MjIg QU0sIENoZW5nbGkgKERpc3RhbmNlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoZW5nbGkxM0BodWF3 ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hlbmdsaTEzQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSZuYnNwOyBQdXNocGFzaXMsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Xb3csIGl0IGhhcyBiZWVuIHR3byB5ZWFycyBzaW5jZSB5 b3UgbWFkZSB0aGUgcHJlc2VudGF0aW9uLiZuYnNwOyBUaGFuayB5b3UgZm9yIHlvdXIgc2xpZGVz LiBJIGhhdmUgcmVhZCBpdA0KIGFsbC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkJ1dCBJIHN0aWxsIGhhdmUgc29tZSBxdWVzdGlvbnMuIFBsZWFzZSBmaW5kIHRoZW0gaW5saW5l Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIFB1c2hwYXNp cyBTYXJrYXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cHVzaHBhc2lzLmlldGZAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+cHVzaHBhc2lzLmlldGZAZ21haWwuY29tPC9hPl0NCjxicj4NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5Y+R6YCB5pe26Ze0PC9zcGFu PjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjg8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+OTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5pelPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCiAyMzozMTxicj4NCjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+5pS25Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PiBDaGVuZ2xpIChEaXN0YW5jZSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGVuZ2xpMTNAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNoZW5nbGkxM0BodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuS4u+mimDwvc3Bhbj48L2I+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj4gUmU6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PuetlOWkjTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+OiBbc3ByaW5nXSBBbnlj YXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlczwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvcGUgeW91IGhh dmUgYWxyZWFkeSBnb25lIHRocm91Z2ggbXkgcHJlc2VudGF0aW9uIHByZXNlbnRlZCB3YXkgYmFj ayBpbiAyMDE1Li4gSWYgbm90IGhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIHNhbWUuICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLXNwcmluZy0x LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkz L3NsaWRlcy9zbGlkZXMtOTMtc3ByaW5nLTEucGRmPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgQXVnIDksIDIwMTcgYXQgODo1 OCBQTSwgUHVzaHBhc2lzIFNhcmthciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB1c2hwYXNpcy5pZXRm QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnB1c2hwYXNpcy5pZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhpIENoZW5nbGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBhIGxvdCBmb3IgdGFraW5nIHRpbWUgdG8gcmVhZCB0 aGUgZHJhZnQgYW5kIHByb3ZpZGUgY29tbWVudHMuIFBsZWFzZSBmaW5kIGFuc3dlcnMgaW5saW5l PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgQXVn IDksIDIwMTcgYXQgMjowNCBQTSwgQ2hlbmdsaSAoRGlzdGFuY2UpICZsdDs8YSBocmVmPSJtYWls dG86Y2hlbmdsaTEzQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5jaGVuZ2xpMTNAaHVhd2Vp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgUHVzaHBhc2lzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gYSBuZXcgbGVhcm5lciBvZiBTUi4gUmVjZW50bHksIEkg cmVhZCB0aGUNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLW1wbHMtYW55Y2FzdC1zZWdtZW50cy0w MSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5kcmFmdDwv c3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+LA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ YW5kIEkgaGFhIHNvbWUgcXVlc3Rpb25zIGFib3V0IGl0LiBTb21lIG9mIHRoZW0gYXJlIGFib3V0 IHRoZSBhbGdvcml0aG0sIHdoaWxlIHRoZSBvdGhlcnMgYXJlIGFib3V0IHRoZSBjb250ZXh0Lg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+MTogSWYgQ0EtU1JHQiBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgdGhlIHNhbWUg YW1vbmcgYWxsIG5vZGVzLCB3aGljaCBtZWFucyBhbGwgbm9kZXMgY2FuDQogdW5kZXJzdGFuZCB0 aGUgbGFiZWwgaW4gQ0EtU1JHQi4gSWYgc28sIHdoeSBkbyB3ZSBuZWVkIHRvIHNldCBQLUZsYWcg d2hlbiB0aGUgbm9kZSBoYXMgYSBkaWZmZXJlbnQgQ0EtU1JHQiByYW5nZSB3aXRoIFNSR0IuIFdp dGhvdXQgdGhlIEFueWNhc3QtU0lELCB0aGUgbm9kZSBjYW4gdW5kZXJzdGFuZCBDQS1TUkdCIGFu ZCBwcm9jZXNzIENBUFNMIGFzIHdlbGwuJm5ic3A7IFdoeSBkbyB3ZSBuZWVkIHRvIGtlZXAgQW55 Y2FzdCBsYWJlbD8gVG8gaW5kZW50aWZ5DQogdGhlIG5leHQgbGFiZWwgaXMgYSBDUEFTTD8mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+W1B1c2hwYXNpc10gWWVzIHRoaXMgaXMgbmVlZGVkIGZvciB0aGUg bm9kZSB0aGF0IG9yaWdpbmF0ZWQgdGhlIENBUFNMLiBJbiBjYXNlIHRoZSBDQS1TUkdCIGlzIGRp ZmZlcmVudCBmcm9tIHJlZ3VsYXIgU1JHQiB0aGUgcGFja2V0IG11c3QgY29tZSBpbiB3aXRoIHRo ZSBDQVBTTA0KIGF0IHRoZSB0b3Agb2YgdGhlIHN0YWNrIHNvIHRoYXQgaXQgcG9wcyBhbmQgZG9l cyBhIHJlY3Vyc2l2ZSBsYWJlbCBsb29rdXAgd2l0aCB0aGUgbmV4dCBsYWJlbCBpbiBzdGFjay4u Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bQ2hlbmddIElmIHRoZXJlIGlzIGFuIGFj dGlvbiBzdXBwb3J0aW5nIHRvIGxvb2sgdXAgaW4gVi1MRklCLCB3aHkgbm90IHVzZSBDQVBTTCBh cyB0aGUga2V5IGluIERlZmF1bHQNCiBMRklCIGRpcmVjdGx5PyZuYnNwOyBJZiBzbywgUC1GbGFn IGNhbiBiZSBsZWF2ZWQgMCwgYW5kIG5vZGUgd2lsbCByZWNlaXZlIGEgcGFja2V0IHdpdGggdGhl IENBUFNMIGFzIHRoZSB0b3AgbGFiZWwgbm8gbWF0dGVyIGl04oCZcyBDQS1TUkdCIGlzIHRoZSBz YW1lIGFzIFNSR0Igb3Igbm90LiBJbiBkZWZhdWx0IExGSUIsIHRoZXJlIHNob3VsZCBiZSBhbiBl bnRyeSBmb3IgQ0FQU0wsIGFuZCBpdOKAmXMgYWN0aW9uIGlzIHRvIGxvb2sgdXAgQ0FQU0wgaW4g Vi1MRklCLg0KIEkgYW0gbm90IHN1cmUgdGhhdCB3aGV0aGVyIGl0IGNhbiB3b3JrIG9yIG5vdC4g PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0aGlzIHdheSwgY29uZmlndXJh dGlvbiB3aWxsIGJlIG11Y2ggZWFzaWVyLiZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JbiBzdW1tYXJ5LCBpbiBteSBQT1YsIHdlIGNhbiBwb3AgdGhlIHByZXZpb3Vz IGFueWNhc3QgbGFiZWwgc28gdGhhdCB0aGUgbm9kZSBjYW4gcmVjZWl2ZSB0aGUgc2FtZSBwYWNr ZXQNCiBubyBtYXR0ZXIgaXTigJlzIENBLVNSR0IgaXMgdGhlIHNhbWUgYXMgU1JHQiBvciBub3Qu IEJ1dCBJIHN1cHBvc2UgdGhhdCAmbmJzcDt0aGVyZSBtdXN0IGJlIHNvbWUgcmVhc29ucyB0aGF0 IHlvdSBkaWRu4oCZdCZuYnNwOyBwcm9wb3NlIGEgc29sdXRpb24gbGlrZSB0aGlzLiBJZiBwb3Nz aWJsZSwgY2FuIHlvdSBiZSBraW5kIHRvIHRlbGwgbWUgPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSB0aGluayB0aGUgcmVhc29uIG1heWJlOg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5LZWVwaW5nIHRoZSBhbnljYXN0IGxhYmVsIGNhbiByZWR1Y2UgdGhl IGVudHJpZXMgb2YgTEZJQi4mbmJzcDsgSWYgd2UgdXNlIENBUFNMIGFzIHRoZSB0b3AgbGFiZWws IHdlIG5lZWQgdG8NCiBpbnN0YWxsIGVudHJpZXMgZm9yIGFsbCBDQVBTTHMgaW4gTEZJQiBhbmQg aW4gVi1MRklCIGFzIHdlbGwuIEJ1dCBpZiB3ZSBrZWVwIEFueWNhc3QgbGFiZWwgYXMgdGhlIHRv cCBsYWJlbCwmbmJzcDsgd2Ugb25seSBuZWVkIHRvIGluc3RhbGwgb25lIGVudHJ5IGZvciBBbnlj YXN0IGxhYmVsLCBhbmQgb25lIGVudHJ5IGZvciBlYWNoIENBUFNMIGluIFYtTEZJQi48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+MjogSW4gc2VjdGlvbiAzLjIuMiBvZiB5b3VyIGRyYWZ0LCBpdCBzYXlzIHRo YXQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjIxLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoaXMgZG9jdW1lbnQgaW50 cm9kdWNlcyBhIHNlcGFyYXRlIHZpcnR1YWwgbGFiZWwgbG9va3VwIHRhYmxlPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IChoZXJlYWZ0ZXIgcmVmZXJyZWQgdG8gYXMgVmlydHVhbCBMRklCIG9y IFYtTEZJQiksIHRoYXQgcmVwcmVzZW50cyBhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGxh YmVsIHNwYWNlIHdoaWNoIGlzIGFsc28gc2VwYXJhdGUgZnJvbSB0aGUgYWN0dWFsIGxhYmVsIHNw YWNlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlcHJlc2VudGVkIGJ5IHRoZSBkZWZhdWx0 IExGSUIuJm5ic3A7IFRoZSBsYWJlbCB2YWx1ZSBtYXkgYmUgcHJlc2VudCBpbjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBib3RoIHRoZSBkZWZhdWx0IGFuZCBWaXJ0dWFsIExGSUIuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SWYgVi1MRklCIHJlcHJlc2VudHMgYSBsYWJlbCBzcGFjZSBzZXBhcmF0ZWQgZnJvbSB0 aGUgbGFiZWwgc3BhY2UgcmVwcmVzZW50ZWQgYnkgTEZJQiwNCiB3aHkgbGFiZWwgdmFsdWUgbWF5 IGJlIHByZXNlbnQgaW4gYm90aCBvZiB0aGVtPyZuYnNwOyBJZiB0aGlzIGlzIHJpZ2h0LCBJIHN1 cHBvc2UgdGhhdCB0aGUgcmVhc29uIG9mIGtlZXBpbmcgYW55Y2FzdCBsYWJlbCBpcyB0byBpZGVu dGlmeSB0aGUgbmV4dCBsYWJlbCBzaG91bGQgYmUgbG9va2VkIHVwIGluIFYtTEZJQiBpbnN0ZWFk IG9mIGRlZmF1bHQgb25lLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVzaHBhc2lzXSBUaGVvcmV0aWNhbGx5 IGFsbCBsYWJlbC1zcGFjZXMgY2FuIGJlIGluZGVwZW5kZW50IGFuZCBtYXkgaGF2ZSB0aGUgc2Ft ZSBsYWJlbCBwcm9ncmFtbWVkIGluIHRoZW0gd2l0aCBkaWZmZXJlbnQgZm9yd2FyZGluZyBzZW1h bnRpY3MuIEhvd2V2ZXIgZnJvbQ0KIHRoZSBmb2xsb3dpbmcgdGV4dCB3ZSBwcm9wb3NlZCBhIHNl cGFyYXRlIFYtTEZJQiBpZiBhbmQgb25seSBpZiBDQS1TUkdCIGlzIGRpZmZlcmVudCBmcm9tIFNS R0IuLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0NoZW5nXSBJ IGFtIHdvbmRlcmluZyB0aGF0IHdoYXQgaXMgdGhlIGxhYmVsLXNwYWNlPyBJIHRoaW5rIGl0IGlz IHRoZSByYW5nZSBvZiBsYWJlbC4gQnV0IGl0IHNlZW1zIG5vdC4NCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+IFN1Y2ggYSBkZXZpY2UgTVVTVCBhZGQgYW4gZW50cnkgaW4gdGhlIFZpcnR1YWwgTEZJ QiBmb3IgZWFjaCB1bmljYXN0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW5kIGFueWNhc3QgcHJlZml4IHNl Z21lbnRzIGxlYXJudCBmcm9tIGEgcmVtb3RlIGRldmljZSwgaWYgYW5kIG9ubHk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBpZiB0aGUgc2FtZSBwcmVmaXggaGFzIG5vdCBiZWVuIHByb3Zpc2lvbmVkIG9uIHRoZSBkZXZp Y2UuJm5ic3A7IFRoZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRldmljZSBTSE9VTEQgTk9UIGFkZCBhbiBlbnRyeSBm b3IgYW55IG9mIHRoZSBBbnljYXN0IG9yIE5vZGUgcHJlZml4PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2VnbWVudHMg dGhhdCBpdCBoYXMgYWR2ZXJ0aXNlZCBpdHNlbGYuJm5ic3A7IEhvd2V2ZXIgaWYgdGhlIGRldmlj ZSBoYXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBsZWFybnQgYW55IGFueWNhc3QgcHJlZml4IHNlZ21lbnQgZnJvbSBh IHJlbW90ZSBkZXZpY2UsIGFuZCB0aGUgc2FtZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlzIG5vdCBwcm92aXNpb25l ZCBvbiB0aGlzIGRldmljZSwgdGhlIGRldmljZSBNVVNUIGluY2x1ZGUgdGhlIHNhbWU8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBpbiB0aGUgVmlydHVhbCBMRklCIHRhYmxlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+W1B1c2hwYXNpc10gSWYgdGhlIGxhYmVsIGF0IHRoZSB0b3Ag b2YgdGhlIHN0YWNrIGJlbG9uZ3MgdG8gQ0EtU1JHQiB0aGVuIGl0IGhhcyB0byBiZSBmb3IgYW55 Y2FzdCBwcmVmaXggb3JpZ2luYXRlZCByZW1vdGVseSBhbmQgdGhlIHBhY2tldCBhY3R1YWxseSBo aXRzIGFuIGVudHJ5DQogaW4gdGhlIGRlZmF1bHQgTEZJQiBmaXJzdC4uIEJ1dCBiZWNhdXNlIHRo ZSBsYWJlbCBpcyBjb3JyZXNwb25kaW5nIHRvIGFuIGFueWNhc3QgcHJlZml4IHdlIGluc3RhbGwg YSByZWN1cnNpdmUgbG9va3VwIHdpdGggdGhlIFYtTEZJQiBhcyB0aGUgbmV4dCB0YWJsZS4uIFdo ZW4gdGhlIGxvb2t1cCBmb3IgbmV4dCBsYWJlbCBpbiBzdGFjayBpbiB0aGUgVkxGSUIgaXMgbGF1 bmNoZWQgdGhhdCBsYWJlbCBtYXliZSBhc3NvY2lhdGVkIHdpdGggQ0FfU1JHQg0KIG9yIGRlZmF1 bHQtU1JHQi4uIFRoZSBWLUxGSUIgaXMgbmVlZGVkIHRvIG9ubHkgZmFjbGl0YXRlIGxvb2t1cCBv ZiB0aGUgbmV4dCBsYWJlbC4uJm5ic3A7IEluIGNhc2UgdGhlIENBLVNSR0IgaXMgc2FtZSBhcyBk ZWZhdWx0LVNSR0IgSSBob3BlIHlvdXIgcmVhbGl6ZSB0aGF0IGEgcmVjdXJzaXZlIGxhYmVsIGlz IG5vdCByZXF1aXJlZC4gSXQgaXMgaW1wb3J0YW50IHRvIHJlYWxpemUgdGhhdCBDQS1TUkdCIGlz IGludmVudGVkIHRvIGFjdHVhbGx5IGF2b2lkDQogcmVjdXJzaXZlIGxhYmVsIGxvb2t1cC4uIFRo ZSBkZXZpY2VzIHRoYXQgdXNlcyBzYW1lIENBLVNSR0IgYXMgZGVmYXVsdCBTUkdCIG5lZWQgbm90 IHN1cHBvcnQgcmVjdXJzaXZlIGxhYmVsIGxvb2t1cCBpbiB0aGUgaGFyZHdhcmUuLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0NoZW5nXSBZZXMsIEkgY2FuIHVu ZGVyc3RhbmQgdGhlIGxvZ2ljIG9mIHlvdXIgc29sdXRpb24uJm5ic3A7IFdoYXQgaWYgd2UgcG9w IHRoZSBhbnljYXN0IGxhYmVsICxhbmQgbGV0IHRoZQ0KIENBUFNMIHRvIGhpdCB0aGUgZW50cnkg aW4gTEZJQiwgYW5kIHRoZW4gZXhlY3V0ZSB0aGUgYWN0aW9uIG9mIGxvb2tpbmcgdXAgQ0FQU0wg aW4gVi1MRklCLiZuYnNwOyBXaHkgZG8gd2UgbmVlZCB0byBrZWVwIHRoZSBhbnljYXN0IGxhYmVs ID8gVGhpcyBpcyBteSBxdWVzdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4zOiBJIGZvdW5kIG91dCBzb21lIHN0cmFuZ2Ugc3RhdGVtZW50cyBpbiB0aGUgZHJh ZnQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0ibS0xNjQzMDQxNzQ2Njk2MjM0MzM4bTgyNDgyMDExNDczNjc2MTI4NW0y NDQ3NDk4MzUyMTk0NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4NTY4Njc2bXNvbGlzdHBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPmEpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBhZ2UgMTE8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjI0LjBwdDt0ZXh0LWluZGVudDoxMC41cHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPkZvciBleGFtcGxlLCBvbiBkZXZpY2UgQTEs IDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+dGhlIHByZWZpeCBTSUQgMTAgKG9yaWdp bmF0ZWQgYnkgUEUzKTwvc3Bhbj4gaXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjQuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVhY2hh YmxlIHRocm91Z2ggaXRzIG5laWdoYm9ycyBBMyBhbmQgQTQuJm5ic3A7IEFuZCBhcyBwZXIgdGhl IFNSR0I8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjQuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWR2ZXJ0aXNlZCBieSBBMyBhbmQgQTQs IHRoZSBsYWJlbHMgYWxsb2NhdGVkIGJ5IEEzIGFuZCBBNCBhcmUgMzAzMDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgNDAzMCByZXNwZWN0aXZlbHk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoyNC4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHN1cHBvc2UgdGhh dCB0aGUgcHJlZml4IFNJRCBpcyAzMCBpbnN0ZWFkIG9mIDEwLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bUHVz aHBhc2lzXSBZZXMgeW91IGFyZSByaWdodC4gSSBoYXZlIGFscmVhZHkgZ290IHRoaXMgY29tbWVu dCBmcm9tIG9uZSBvZiB0aGUgV0cgbWVtYmVycy4gSSB3aWxsIHJlY3RpZnlpbmcgdGhpcyBpbiBu ZXh0IHZlcnNpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Im0tMTY0MzA0MTc0NjY5NjIzNDMzOG04MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0NzQ5 ODM1MjE5NDY1ODFnbWFpbC1tLTMxNTcwNTIzMjcxODU2ODY3Nm1zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5iKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYWdlIDE0PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJ0 ZXh0LWluZGVudDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6 YmxhY2siPlRoaXMgaXMgYmVjYXVzZSBvbiBub2RlIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnll bGxvdyI+QTE8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrIj7vvIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+SXMgaXQgQTI/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrIj7vvIk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+IHRoZSBkb21haW4td2lkZSBDQS1TUkdCIGlzIGlkZW50aWNhbCB0byB0aGUgbG9jYWwg U1JHQiBwcm92aXNpb25lZCBvbiBBMi4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJtLTE2NDMwNDE3NDY2OTYyMzQzMzhtODI0ODIwMTE0NzM2 NzYxMjg1bTI0NDc0OTgzNTIxOTQ2NTgxZ21haWwtbS0zMTU3MDUyMzI3MTg1Njg2NzZtc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Yyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ UGFnZSAxNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHByZSBzdHlsZT0idGV4dC1pbmRlbnQ6MTAuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmO2NvbG9yOmJsYWNrIj5XaGlsZSBmb3J3YXJkaW5nIHRvIEEyLCBzaW5jZSBBMiB3b3Vs ZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJz cDsmbmJzcDtoYXZlIGFkdmVydGlzZWQgdGhlIGFueWNhc3QgU0lEIDEwMCB3aXRoIFAtRmxhZyAo Tm8tUEhQKSB1bnNldCwgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5SMTwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6eWVs bG93Ij4gJm5ic3A7Jm5ic3A7Jm5ic3A7c2hhbGwgUE9QIHRoZSBpbmNvbWluZyBsYWJlbCA3MTAw IGJlZm9yZSBmb3J3YXJkaW5nIGl0IHRvIFIxKElzIGl0IEEyPykuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ W1B1c2hwYXNpc10gWWVzIHlvdSBhcmUgcmlnaHQuIEkgaGF2ZSBhbHJlYWR5IGdvdCB0aGlzIGNv bW1lbnQgYXMgd2VsbCBmcm9tIG9uZSBvZiB0aGUgV0cgbWVtYmVycy4gSSB3aWxsIHJlY3RpZnlp bmcgdGhpcyBpbiBuZXh0IHZlcnNpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGEgbG90IGZvciBjb21tZW50cyBhbmQg dGhvdWdodHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+QmVzdCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiM4ODg4ODgiPi1QdXNocGFzaXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSBmb3IgeW91ciBnb29kIGpvYiE8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkNoZW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+DQogc3ByaW5nIFttYWlsdG86PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5dDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPuS7o+ihqDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+DQo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5QdXNocGFzaXMgU2Fya2FyPGJyPg0KPC9zcGFuPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lj5HpgIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuW5tDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Nzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4yMDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4NCiAxMjozNTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+5pS25Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbGV4YW5k ZXIgVmFpbnNodGVpbiAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7mioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+bXBsc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNwcmluZy1hbnljYXN0LXNlZ21lbnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5kcmFmdC1pZXRmLXNwcmlu Zy1hbnljYXN0LXNlZ21lbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWls dG86ZHJhZnQtbXBscy1zaGVuLWVncmVzcy1wcm90ZWN0aW9uLWZyYW1ld29ya0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmRyYWZ0LW1wbHMtc2hlbi1lZ3Jlc3MtcHJv dGVjdGlvbi1mcmFtZXdvcmtAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+Ow0KIFNoZWxsIE5ha2FzaCAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48YSBocmVmPSJtYWlsdG86U2hlbGwuTmFrYXNoQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+U2hlbGwuTmFrYXNoQGVjaXRlbGUuY29tPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQogTWljaGFlbCBHb3Jva2hv dnNreSAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86TWljaGFl bC5Hb3Jva2hvdnNreUBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pk1pY2hhZWwuR29yb2tob3Zza3lAZWNpdGVsZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPnNwcmluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj47IERtaXRyeSBWYWxkbWFuDQogJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PGEgaHJlZj0ibWFpbHRvOkRtaXRyeS5WYWxkbWFuQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+RG1pdHJ5LlZhbGRtYW5AZWNpdGVsZS5jb208L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCiBSb24gU2RheW9vciAmbHQ7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86Um9uLlNkYXlvb3JAZWNp dGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Sb24uU2RheW9vckBlY2l0 ZWxlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Ow0KIFJvdGVtIENvaGVuICZsdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1h aWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4gUmU6IFtzcHJpbmddIEFu eWNhc3Qgc2VnbWVudHMgYW5kIGNvbnRleHQtc3BlY2lmaWMNCiBsYWJlbCBzcGFjZXM8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPkhpIFNhc2hhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGFua3MgYSBsb3QgZm9yIHRha2luZyB0aW1lIHRvIHJlYWQgdGhlIGRvY3VtZW50IGFu ZCBwcm92aWRpbmcgdGhlIG11Y2ggYXBwcmVjaWF0ZWQgY29tbWVudHMuIFBsZWFzZSBmaW5kIHNv bWUgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEp1bCAxOSwgMjAx NyBhdCAxMjowOSBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSByZWFkIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLW1wbHMtYW55Y2FzdC1zZWdtZW50cy0wMSIg dGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQ8L2E+IGluIHF1ZXN0aW9uLCBhbmQsIGZyb20gbXkgUE9W LCBpdCBkZWZpbmVzLCB1bmRlciB0aGUgbmFtZSBvZiBWaXJ0dWFsIExGSUIsICZuYnNwOzxpPmEg ZGVkaWNhdGVkIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2U8L2k+IChzZWUNCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzMxIiB0YXJnZXQ9Il9ibGFuayI+UkZD IDUzMzE8L2E+KSAmbmJzcDtpbiB0aGUgZGV2aWNlcyB0aGF0IGFyZSBhc3NpZ25lZCB3aXRoIG9u ZSBvciBtb3JlIGFueWNhc3Qgc2VnbWVudHMsIGFuZCB1c2VzIHRoZSBsYWJlbHMgc3VjaCBkZXZp Y2VzIGFsbG9jYXRlIGZvciB0aGVzZSBzZWdtZW50cyBhcyB0aGUNCjxpPmNvbnRleHQgbGFiZWxz PC9pPiBpZGVudGlmeWluZyB0aGlzIHNwYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+W1B1c2hwYXNpc10gWWVzLCB0aGF0IGlzIGNvcnJlY3QuIEkgd2ls bCBhZGQgYSByZWZlcmVuY2UgdG8gUkZDIDUzMzEgaW4gdGhlIG5leHQgdmVyc2lvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5JZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Im0tMTY0MzA0MTc0NjY5NjIzNDMzOG04MjQ4MjAxMTQ3MzY3NjEyODVtMjQ0 NzQ5ODM1MjE5NDY1ODFnbWFpbC1tLTMxNTcwNTIzMjcxODU2ODY3Nm03NDkwNzQ2ODcyOTk2NTE5 MTQ0bXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+RXhwbGljaXQgbWFwcGluZyBvZiB0aGUgZGVmaW5pdGlvbnMgb2YgdGhl IGRyYWZ0IHRvIGFscmVhZHkgZGVmaW5lZCBhbmQgd2VsbC11bmRlcnN0b29kIE1QTFMgYXJjaGl0 ZWN0dXJhbCBtZWNoYW5pc21zIHdvdWxkIGdyZWF0bHkgaW1wcm92ZSBpdHMgcmVhZGFiaWxpdHku IEl0IHdvdWxkIGFsc28gZ3JlYXRseSBoZWxwIHRoZSBpbXBsZW1lbnRlcnMsIGVzcGVjaWFsbHkg aWYgdGhleSBoYXZlIGFscmVhZHkNCiBpbXBsZW1lbnRlZCAob3IgY29uc2lkZXIgaW1wbGVtZW50 YXRpb24gb2YpIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2VzIGluIHRoZWlyIGRldmljZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPltQdXNocGFzaXNd IEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcgdGhpcyBkcmFmdCwgdGhlcmUgd2VyZSBhbHJlYWR5IHNv bWUgaW1wbGVtZW50YXRpb25zIG9mIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2UgLCBhbmQg c28gSSB0aG91Z2h0IGFkZGluZyB0aG9zZSBpbXBsZW1lbnRhdGlvbg0KIGRldGFpbHMgd2lsbCBu b3QgYmUgdXNlZnVsLCBlc3BlY2lhbGx5IGR1cmluZyB0aGUgV0dMQyBsYXN0IGNhbGxzLiBJbXBs ZW1lbnRhdGlvbiBtaW51dGUgZGV0YWlscyBhcmUgbm90IHdlbGNvbWUgSSBhc3N1bWUgZnJvbSB0 aGUgV0dMQyByZXZpZXdzIEkgaGF2ZSBnb25lIHRocm91Z2ggc28gZmFyLiBCdXQgbCBjYW4gc3Vy ZSBhZGQgc29tZSByZWZlcmVuY2UgdG8gUkZDNTMzMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibS0xNjQzMDQxNzQ2Njk2MjM0MzM4bTgyNDgyMDExNDcz Njc2MTI4NW0yNDQ3NDk4MzUyMTk0NjU4MWdtYWlsLW0tMzE1NzA1MjMyNzE4NTY4Njc2bTc0OTA3 NDY4NzI5OTY1MTkxNDRtc29saXN0cGFyYWdyYXBoIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5BZGRpbmcgdGhlIHJlbGV2YW50IHJlZmVyZW5jZXMg KGluY2x1ZGluZyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDUzMzEpIHNlZW1zIG5lY2Vz c2FyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlVzaW5nIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwg c3BhY2VzIGFuZCBjb250ZXh0IGxhYmVscyBpbiBjb25qdW5jdGlvbiB3aXRoIGFueWNhc3QgKG9y IGFueWNhc3QtbGlrZSkgZnVuY3Rpb25hbGl0eSAmbmJzcDtpbiBNUExTIGlzIG5vdCBuZXcuIE9u ZSBleGFtcGxlIChhcyBpbmRpY2F0ZWQNCiBpbiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxMjY1OS5odG1sIiB0YXJnZXQ9Il9i bGFuayI+DQpFcmljIFJvc2Vu4oCZcyBlbWFpbDwvYT4pICZuYnNwO2lzIHRoZSBQVyBFbmRwb2lu dCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbiBtZWNoYW5pc20gZGVmaW5lZCBpbg0KPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMDQiIHRhcmdldD0iX2JsYW5rIj5SRkMg ODEwNDwvYT4uIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5bUHVzaHBhc2lzXSBZZXMsIHVzZSBvZiBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlIGlz IG5vdCBuZXcuIEFuZCB3b3JraW5nIGluIEp1bmlwZXIgZm9yIHNvbWV0aW1lIEkgaGF2ZSBhIGdv b2QgaWRlYSBvZiBpdHMgYXBwbGljYXRpb24uIEJ1dCB1c2luZyBpdCB0byBwcm92aWRlDQogYSBt ZWFucyB0byBkbyBhbnljYXN0IHNlZ21lbnRzIHVzaW5nIE1QTFMgZGF0YXBsYW5lIGlzIHZlcnkg bXVjaCBuZXcuIEFuZCB0byBteSBrbm93bGVkZ2UgdGlsbCBkYXRlIHRoZXJlIGlzIG5vIG90aGVy IHdheSB0byBhY2hpZXZlIHRoaXMgd2l0aG91dCByZWN1cnNpdmUgbGFiZWwgbG9va3VwIGFuZCBj b250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgYW5hbG9neSBsb29rcyBpbXBvcnRhbnQgdG8g bWUgc2luY2UgYW55Y2FzdCBncm91cHMgYXJlIGNvbW1vbmx5IGNvbnNpZGVyZWQgYXMgYSBwcm90 ZWN0aW9uIG1lY2hhbmlzbSAoYW5kIG5vdCBqdXN0IGFzIGEgbG9hZC1iYWxhbmNpbmcgb25lKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPltQdXNocGFzaXNd IEFjdHVhbGx5LCBhYm91dCB0aGUgdXNlY2FzZXMgSSBoYXZlIGRpc2N1c3NlZCBzb21lIG9mIHRo ZSBvcGVyYXRvcnMgSSBoYXZlIGRpc2N1c3NlZCB3aXRoIHNvIGZhciBvbiB0aGlzLCBhbG1vc3Qg YWxsIHRoZW0gYXJlIGFib3V0IHBvbGljeS1iYXNlZC1yb3V0aW5nLA0KICZuYnNwO2xvYWQtYmFs YW5jaW5nIGFuZCBwcm92aWRpbmcgZGlzam9pbnQgcGF0aHMuIE9mZmNvdXJzZSBkaXNqb2ludCBw YXRocyBjYW4gYmUgdXNlZCBmb3IgcHJvdGVjdGlvbiBhcyB3ZWxsIGFzIGxvYWQtYmFsYW5jaW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkg YWxzbyB0aGluayB0aGF0IHJlbGF0aW9uc2hpcHMgYmV0d2VlbiB0aGlzIGRyYWZ0IGFuZCB0aGUN CjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNoZW4tbXBs cy1lZ3Jlc3MtcHJvdGVjdGlvbi1mcmFtZXdvcmsvP2luY2x1ZGVfdGV4dD0xIiB0YXJnZXQ9Il9i bGFuayI+DQplZ3Jlc3MgcHJvdGVjdGlvbiBmcmFtZXdvcms8L2E+IG9uZSBhcmUgd29ydGggbG9v a2luZyBhdCBjYXJlZnVsbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5bUHVzaHBhc2lzXSBGaXJzdCB0aGUgZWdyZXNzIHByb3RlY3Rpb24gZHJhZnRzIGRv ZXMgbm90IHNlZW0gdG8gaGF2ZSBnb25lIHRocm91Z2ggV0cgYWRvcHRpb24uIE5leHQgdGhvdWdo IHRoZXNlIHR3byBkcmFmdHMgdXNlIHRoZSBzYW1lIG1lY2hhbmlzbXMsIHRoZSBleGFjdA0KIHBy b2JsZW0gdGhleSB0cnkgdG8gc29sdmUgYXJlIG5vdCBleGFjdGx5IHJlbGF0ZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+TmV2ZXJ0aGVsZXNz LCBJIHZhbHVlIHlvdXIgY29tbWVudHMsIHN1Z2dlc3Rpb25zIGFuZCB0aG91Z2h0cyBhIGxvdCwg YW5kIHRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHByb3ZpZGluZyB0aGUgaW5zaWdodHMuIEkgd2ls bCBkZWZpbml0ZWx5IHdvcmsgb24gdGhlbSBhbmQgYWRkcmVzcw0KIHRoZW0gaW4gdGhlIG5leHQg ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhhbmtzIG9uY2UgYWdhaW4gYW5kIGJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4tUHVzaHBhc2lzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgMmMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+U2FzaGE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5PZmZpY2U6ICYjNDM7OTcyLTM5MjY2MzAyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2VsbDombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzs5NzItNTQ5MjY2MzAyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+RW1h aWw6Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCjxicj4NClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSBy ZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMNCjxicj4NCkNP TkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo8YnI+DQp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBs ZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0 aGUgb3JpZ2luYWwNCjxicj4NCmFuZCBhbGwgY29waWVzIHRoZXJlb2YuPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C7C2E1C43D652C4E9E49FE7517C236CBF5CE8Bdggemi502mbxchina_-- From nobody Thu Aug 10 12:00:45 2017 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 D82EA132414; Thu, 10 Aug 2017 12:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hHdDkXm8WZAN; Thu, 10 Aug 2017 12:00: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 6CFF9132417; Thu, 10 Aug 2017 12:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75096; q=dns/txt; s=iport; t=1502391629; x=1503601229; h=from:to:cc:subject:date:message-id:mime-version; bh=0olF+4edcTKXAfantIjR4W0CI+80oIA6a1z/SkskYrE=; b=j30JUBZL6czrOgowq5gQcZxXqx4eYr3tWeuvffEeQiRoSENLN32AN/8m TxU3kRX1VPXRK4MOwMpI6C8oeIBPPsRxvEh2S2U4r1z5Tsi885ogW+89z bfIwd6/qgTjQ4I+vxAov26UvfkjZ96WIkud0/C2g3pHvfozcxH85m/WCK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgAnrIxZ/5JdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+LWSBG54RmAMOggQJhT4chF9AFwECAQEBAQEBAWsdC4U5AQgKQgM?= =?us-ascii?q?HEgEGFCYBCQIEMBcQBA4giTBkjzedZIImJ4s/AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEegyiCAoFMgWIBK4c5IIMpMIIxBZB/hwCIIQKLJIkSgg+FXYpmlg0BIQI0gQp?= =?us-ascii?q?3FUkSAYUEHIFniGQrgQWBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,354,1498521600"; d="scan'208,217";a="469676072" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Aug 2017 19:00:27 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v7AJ0RvG006109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Aug 2017 19:00:27 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Aug 2017 14:00:26 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 10 Aug 2017 14:00:26 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-spring-segment-routing@ietf.org" CC: Martin Vigoureux , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-segment-routing-12 Thread-Index: AQHTEgrt3ux6zPueXEq5stU4jlMVEg== Date: Thu, 10 Aug 2017 19:00:26 +0000 Message-ID: <2AC310C5-A42B-4D4D-B223-B52E9BF37DB0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_2AC310C5A42B4D4DB223B52E9BF37DB0ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [spring] AD Review of draft-ietf-spring-segment-routing-12 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 19:00:43 -0000 --_000_2AC310C5A42B4D4DB223B52E9BF37DB0ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpJIGp1c3QgZmluaXNoZWQgcmV2aWV3aW5nIHRoaXMgZG9jdW1lbnQg 4oCTIHNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcHJvY2Vzc2luZy4gIFRoYW5rcyBmb3IgYWxsIHRo ZSB3b3JrIHlvdeKAmXZlIGJ1dCBpbnRvIHRoaXMgZG9jdW1lbnQhDQoNCkkgaGF2ZSBzb21lIHNp Z25pZmljYW50IGNvbmNlcm5zIChzZWUgYmVsb3cgZm9yIGRldGFpbHMpLiAgSW4gZ2VuZXJhbCwg dGhlIGRvY3VtZW50IHByZXNlbnRzIGFuIGluY29tcGxldGUgdmlldyBvZiB0aGUgYXJjaGl0ZWN0 dXJlOiBkZXRhaWxzIGFib3V0IGltcG9ydGFudCBwaWVjZXMgYXJlIGJhcmVseSBtZW50aW9uZWQg b3Igbm90IGZ1bGx5IGRlc2NyaWJlZCwgYXMgaXMgdGhlIGNhc2Ugb2YgdGhlIHJvbGUgb2YgYSBj ZW50cmFsIGNvbnRyb2xsZXIgKFBDRSksIGFuZCB0aGUgQkdQIGFuZCBCaW5kaW5nIFNlZ21lbnRz Lg0KDQpBbHNvLCBzb21lIG9mIHRoZSBhcmNoaXRlY3R1cmFsIGRldGFpbHMgYXJlIHByZWRpY2F0 ZWQgb24gc3BlY2lmaWMgYml0cyBkZWZpbmVkIGluIHRoZSBleHRlbnNpb25zLCB3aGVyZSB0aGlz IGRvY3VtZW50IHNob3VsZCBkZXNjcmliZSB0aGUgZ2VuZXJhbCBvcGVyYXRpb24gYW5kIGxlYXZl IHRoZSBkZXRhaWxzIChsaWtlIGJpdCBuYW1lcykgdG8gdGhlIGV4dGVuc2lvbnMuICBOb3RlIHRo YXQgSeKAmW0gbm90IGFza2luZyB0aGF0IHlvdSBkb27igJl0IG1lbnRpb24gdGhlIGV4dGVuc2lv bnMg4oCTIHBvaW50aW5nIHRvIHRoZW0gaXMgZmluZSAtLSwgSeKAmW0gYXNraW5nIHlvdSB0byBk ZWZpbmUgdGhlIGZ1bmN0aW9uYWxpdHkgaW4gZ2VuZXJhbCBhbmQgbm90IGFzIGEgZnVuY3Rpb24g b2YgdGhlIGV4dGVuc2lvbnMuICBGb3IgYW4gZXhhbXBsZSwgc2VlIHBvaW50IE01LjEuIGJlbG93 Lg0KDQpJIHdpbGwgd2FpdCBmb3IgYXQgbGVhc3QgdGhlIE1ham9yIGNvbW1lbnRzIHRvIGJlIGFk ZHJlc3NlZCBiZWZvcmUgc3RhcnRpbmcgdGhlIElFVEYgTGFzdCBDYWxsLg0KDQpUaGFua3MhDQoN CkFsdmFyby4NCg0KDQoNCk1ham9yOg0KDQpNMS4gVGhlIEludHJvZHVjdGlvbiBtZW50aW9ucyBz ZXZlcmFsIHR5cGVzIG9mIHNlZ21lbnRzLCBhbmQgaXQgc2F5cyB0aGF0IHRoZSBMRFAgTFNQLCBS U1ZQLVRFIExTUCwgYW5kIEJHUCBMU1Agc2VnbWVudHMgYXJlIOKAnGlsbHVzdHJhdGVkIGluIFtJ LUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNd4oCdLiAgQnV0IHRoYXQgaXMgb25s eSB0cnVlIGZvciB0aGUgZmlyc3QgdHdvLCBmb3Igd2hpY2ggZXhhbXBsZXMgYXJlIHNob3duLiAg V2hlcmUgYXJlIHRoZXNlIHNlZ21lbnQgdHlwZXMgZGVmaW5lZD8gIFRoZSBkZWZpbml0aW9uLCBh bmQgbm90IHRoZSBleGFtcGxlcywgaXMgdGhlIE1ham9yIGlzc3VlIGhlcmUuICBUaGlzIGRvY3Vt ZW50IGJlaW5nIHRoZSBtYWluIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzaG91bGQgaW5jbHVkZSB0 aGUgY29tcGxldGUgZGVzY3JpcHRpb24uICBCVFcsIHRoZSBsaXN0IGlzIG9ubHkgYWJvdXQgdGhl IOKAnE1QTFMgaW5zdGFudGlhdGlvbuKAnSwgYXJlIHRoZXJlIHNpbWlsYXIgdHlwZXMgb2Ygc2Vn bWVudHMgZm9yIElQPw0KDQoNCk0yLiBGcm9tIFNlY3Rpb24gMi4gKFRlcm1pbm9sb2d5KTog4oCc VXNpbmcgdGhlIHNhbWUgU1JHQiBvbiBhbGwgbm9kZXMgd2l0aGluIHRoZSBTUiBkb21haW4gZWFz ZSBvcGVyYXRpb25zIGFuZCB0cm91Ymxlc2hvb3RpbmcgYW5kIGlzIGV4cGVjdGVkIHRvIGJlIGEg ZGVwbG95bWVudCBndWlkZWxpbmUu4oCdICBJdCBpcyDigJxleHBlY3RlZCB0byBiZSBhIGRlcGxv eW1lbnQgZ3VpZGVsaW5l4oCdIHdoZXJlL3doZW4/PyAgR2l2ZW4gdGhhdCB0aGlzIGRvY3VtZW50 IGlzIHRoZSBnZW5lcmFsIGFyY2hpdGVjdHVyZSwgSSBmaWd1cmVkIHRoYXQgbWF5YmUgZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMgY29udGFpbmVkIHRoYXQgZGVwbG95bWVu dCByZWNvbW1lbmRhdGlvbiwgYnV0IGFsbCB0aGF0IGRvY3VtZW50IHNheXMgaXM6IOKAnEFzIGRl c2NyaWJlZCBpbiBbSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ10sIHVzaW5nIHRoZSBz YW1lIFNSR0Igb24gYWxsIG5vZGVzIHdpdGhpbiB0aGUgU1IgZG9tYWluIGVhc2VzIG9wZXJhdGlv bnMgYW5kIHRyb3VibGVzaG9vdGluZyBhbmQgaXMgZXhwZWN0ZWQgdG8gYmUgYSBkZXBsb3ltZW50 IGd1aWRlbGluZS7igJ0gIFNv4oCmd2hlcmUgYXJlIHRoZSBEZXBsb3ltZW50L09wZXJhdGlvbmFs IGNvbnNpZGVyYXRpb25zIHJlbGF0ZWQgdG8gdGhlIFNSR0I/ICBJIG5vdGUgdGhhdCBuZWl0aGVy IGRvY3VtZW50IChkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmcgb3IgZHJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMpIGluY2x1ZGUgdGhlbS4gIEkgd291bGQgZXhw ZWN0IHNvbWUgaW5mb3JtYXRpb24gdG8gYmUgaW4gdGhpcyAoZ2VuZXJhbCkgZG9jdW1lbnQgYW5k IG90aGVyIG1vcmUgc3BlY2lmaWMgaW5mb3JtYXRpb24gKGxpa2UgdGhlIGNvbnNpZGVyYXRpb25z IGFib3V0IHVzaW5nIHRoZSBzYW1lIFNSR0IpIHRvIGJlIGluIHRoZSBtb3JlIHNwZWNpZmljIGRv Y3VtZW50IChkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscywgaW4gdGhpcyBj YXNlKS4NCg0KTTIuMS4gIFRoZSBleGFtcGxlIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSAyIHdvdWxk IGJlIGEgZ3JlYXQgcGxhY2UgdG8gZGVtb25zdHJhdGUgdGhlIHZhbHVlIG9mIGhhdmluZyB0aGUg c2FtZSBTUkdCLiAgSW4gZmFjdCwgdGhlIHRleHQgbm93IHNob3dzIHRoaW5ncyBub3Qgd29ya2lu ZyBhbmQgaXQgZXZlbiB3YXJucyBieSBzYXlpbmcgdGhhdCDigJx1c2luZyBhbnljYXN0IHNlZ21l bnQgd2l0aG91dCBjb25maWd1cmluZyB0aGUgc2FtZSBTUkdCIG9uIG5vZGVzIGJlbG9uZ2luZyB0 byB0aGUgc2FtZSBkZXZpY2UgZ3JvdXAgbWF5IGxlYWQgdG8gbWlzcm91dGluZ+KAnSwgYnV0IG5v IGV4cGxhbmF0aW9uIG9mIGhvdyBpdCBzaG91bGQgYmUgZG9uZSB0aGUgcmlnaHQgd2F5Lg0KDQoN Ck0zLiBGcm9tIFNlY3Rpb24gMi4gKFRlcm1pbm9sb2d5KTog4oCc4oCmYSBnbG9iYWwgc2VnbWVu dCBpcyByZXByZXNlbnRlZCBieSBhIGdsb2JhbGx5LXVuaXF1ZSBpbmRleC7igJ0NCg0KTTMuMS4g IEkgY291bGRu4oCZdCBmaW5kIGFueXdoZXJlIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgdXNlIG9m IHRoZSBpbmRleC4gIFdoZW4gaXQgaXMgZGlzY3Vzc2VkIGluIDMuMS4yLCBpdCBzZWVtcyB0byBi ZSBhbiB1bmRlcnN0b29kIGNvbmNlcHQ6IOKAnEEgUHJlZml4LVNJRCBpcyBhbGxvY2F0ZWQgaW4g dGhlIGZvcm0gb2YgYW4gaW5kZXggaW4gdGhlIFNSR0LigKbigJ0gIEV2ZW4gaWYgc3RyYWlnaHRm b3J3YXJkLCBJIHRoaW5rIHRoZSBjb25jZXB0IG9mIHRoZSBpbmRleCBzaG91bGQgYmUgZXhwbGFp bmVkIChtYXliZSB3aXRoIGFuIGV4YW1wbGUpIGFuZCBub3QgYXNzdW1lZC4gIEkgYWdhaW4gd2Vu dCB0byBsb29rIGF0IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLCBidXQg dGhhdCBkb2N1bWVudCBqdXN0IHBvaW50cyBiYWNrIHRvIHRoaXMgb25lOiDigJxUaGUgbm90aW9u IG9mIGluZGV4ZWQgZ2xvYmFsIHNlZ21lbnQsIGRlZmluZWQgaW4gW0ktRC5pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmdd4oCm4oCdDQoNCk0zLjIuIEkgYXNzdW1lIHRoYXQg4oCcZ2xvYmFsbHkt dW5pcXVlIGluZGV44oCdIGlzIHJlYWxseSB1bmlxdWUgdG8gdGhlIFNSIERvbWFpbiwgcmlnaHQ/ ICBJIGFzayB0aGlzIHF1ZXN0aW9uIGJlY2F1c2Ug4oCcZ2xvYmFsbHktdW5pcXVlIElQdjYgYWRk cmVzc+KAnSBoYXMgYSBkaWZmZXJlbnQgY29ubm90YXRpb24gKGFzIGluIHVuaXF1ZSB3b3JsZC13 aWRlLCBub3QganVzdCBpbnNpZGUgYSBkb21haW4pLiAgUGxlYXNlIGNsYXJpZnkuDQoNCk0zLjMu ICBOb3RlIHRoYXQgdGhlIGxhdGVzdCB2ZXJzaW9uICgtMTApIG9mIGRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1tcGxzIGludHJvZHVjZWQgdGhlIFNSIExvY2FsIEJsb2NrIChTUkxC KSB3aGljaCBpcyBub3QgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgSSBtZW50aW9uIGl0IGhl cmUgYmVjYXVzZSBpdCB3YXMgaW50cm9kdWNlZCByaWdodCBhZnRlciB0aGUgcG9pbnRlciBhYm91 dCB0aGUgaW5kZXjigKYNCg0KDQpNNC4gU2VjdGlvbiAzLjEuMS4gKFByZWZpeC1TSUQgQWxnb3Jp dGhtKQ0KDQpNNC4xLiBUaGlzIHNlY3Rpb24gc3RhcnRzIGJ5IGp1c3RpZnlpbmcgdGhlIHVzZSBv ZiBhbiBhbGdvcml0aG0gYmFzZWQgb24gdGhlIElHUCBwcm90b2NvbCBleHRlbnNpb25zOiB0aGUg ZXh0ZW5zaW9ucyBoYXZlIGFuIGFsZ29yaXRobSBmaWVsZCwgc28gd2Ugc2hvdWxkIHVzZSBpdC4g IFRoZSBqdXN0aWZpY2F0aW9uIHNob3VsZCBiZSB0aGUgb3RoZXIgd2F5IGFyb3VuZDogdGhpcyBk b2N1bWVudCAodGhlIGFyY2hpdGVjdHVyZSkgZGVmaW5lcyB0aGUgY29uY2VwdCBvZiBhbiBhbGdv cml0aG0gYW5kIHRoZSBleHRlbnNpb25zIGltcGxlbWVudCBpdC4gIFBsZWFzZSByZS13b3JkIHRo ZSBmaXJzdCAzIHBhcmFncmFwaHMg4oCTIG5vdGUgdGhhdCB0aGUgaW5zdGFuY2UvdG9wb2xvZ3kg cmVmZXJlbmNlcyBzZWVtIHN1cGVyZmx1b3VzIHRvIG1lLg0KDQpNNC4yLiBUaGUgYWxnb3JpdGht cyBhcmUgbm90IHJlYWxseSBkZWZpbmVkIOKAkyB0aGVyZSBhcmUgbWVudGlvbnMgb2YgYSDigJx3 ZWxsIGtub3duIEVDTVAtYXdhcmUgU1BGIGFsZ29yaXRobeKAnSwgYnV0IG5vIHNwZWNpZmljIHJl ZmVyZW5jZSB0byB3aGF0IHRoYXQgaXMuICBUaGUgbGFzdCBzZW50ZW5jZSBpbiB0aGUgU2VjdGlv biBtZW50aW9ucyB0aGF0IHRoZSDigJxkZXRhaWxzIG9mIHRoZSB0d28gZGVmaW5lZCBhbGdvcml0 aG1zIGFyZSBkZWZpbmVkIGlu4oCm4oCdIHBvaW50aW5nIHRvIHRoZSBleHRlbnNpb24gZHJhZnRz IOKAkyBidXQgdGhvc2UgZHJhZnRzIGp1c3Qgb2ZmZXIgYW4gYWRkaXRpb25hbCBwaWVjZSBvZiBp bmZvcm1hdGlvbiBpbiAoZnJvbSB0aGUgT1NQRiBkb2N1bWVudCk6IOKAnHRoZSBzdGFuZGFyZCBz aG9ydGVzdCBwYXRoIGFsZ29yaXRobSBhcyBjb21wdXRlZCBieSB0aGUgT1NQRiBwcm90b2NvbOKA nS4gIElkZWFsbHkgdGhlIGFsZ29yaXRobXMgd291bGQgYmUgZGVmaW5lZCBoZXJlIChldmVuIGlm IGl0IGlzIGp1c3QgdG8gc2F5OiDigJx0aGUgc3RhbmRhcmQgYWxnb3JpdGhtIHVzZWQgaW4gdGhl IGNvcnJlc3BvbmRpbmcgSUdQ4oCdKSwgYW5kIHRoZSBleHRlbnNpb25zIHdvdWxkIGp1c3QgcmVm ZXJlbmNlIGl0Lg0KDQpNNC4zLiAgV2hlbiBzaG91bGQgdGhlIHBhY2tldHMgYmUgZHJvcHBlZD8/ ICBUaGUgZm9sbG93aW5nIHRleHQgcG9pbnRzIHRvIGF0IGxlYXN0IDMgZGlmZmVyZW50IHBsYWNl cyB3aGVyZSBpdCBzaG91bGQgYmUgZHJvcHBlZCwgb25lIG1hcmtlZCB3aXRoIGEgTVVTVC4gIFBs ZWFzZSBjbGFyaWZ5Lg0KDQpNNC4zLjEuIOKAnEEgcm91dGVyIE1VU1QgZHJvcCBhbnkgU1IgdHJh ZmZpYyBhc3NvY2lhdGVkIHdpdGggdGhlIFNSIGFsZ29yaXRobSB0byB0aGUgYWRqYWNlbnQgcm91 dGVyLCBpZiB0aGUgYWRqYWNlbnQgcm91dGVyIGhhcyBub3QgYWR2ZXJ0aXNlZCBzdXBwb3J0IGZv ciBzdWNoIFNSIGFsZ29yaXRobS7igJ0gIE9rLCB0aGlzIHNvdW5kcyBhcyBpZiB0aGUgdHJhZmZp YyBpcyBkcm9wcGVkIG9uZSBob3AgYmVmb3JlIHRoZSByb3V0ZXIgbm90IHN1cHBvcnRpbmcgdGhl IGFsZ29yaXRobSDigJMgYW5kIGl0IGhhcyBhIE1VU1QgaW4gaXQuDQoNCk00LjMuMi4g4oCcVGhl IGluZ3Jlc3Mgbm9kZSBvZiBhbiBTUiBkb21haW4gdmFsaWRhdGVzIHRoYXQgdGhlIHBhdGggdG8g YSBwcmVmaXjigKZpbmNsdWRlcyBub2RlcyBhbGwgc3VwcG9ydGluZyB0aGUgYWR2ZXJ0aXNlZCBh bGdvcml0aG0uICBBcyBhIGNvbnNlcXVlbmNlLCBpZiBhIG5vZGUgb24gdGhlIHBhdGggZG9lcyBu b3Qgc3VwcG9ydCBhbGdvcml0aG0gWCwgdGhlIElHUC1QcmVmaXggc2VnbWVudCB3aWxsIGJlIGlu dGVycnVwdGVkIGFuZCB3aWxsIGRyb3AgcGFja2V0IG9uIHRoYXQgbm9kZS7igJ0gIFRoaXMgc291 bmRzIGxpa2UgdGhlIHRyYWZmaWMgd291bGQgYmUgZHJvcHBlZCBvbiB0aGUgbm9kZSBub3Qgc3Vw cG9ydGluZyB0aGUgYWxnb3JpdGhtLg0KDQpNNC4zLjMuIOKAnEl0J3MgdGhlIHJlc3BvbnNpYmls aXR5IG9mIHRoZSBpbmdyZXNzIG5vZGUgdXNpbmcgYSBzZWdtZW50IHRvIGNoZWNrIHRoYXQgYWxs IGRvd25zdHJlYW0gbm9kZXMgc3VwcG9ydCB0aGUgYWxnb3JpdGhtIG9mIHRoZSBzZWdtZW50LuKA nSAgVGhpcyBsYXN0IHNlbnRlbmNlIGhpbnRzIGF0IHRoZSBmYWN0IHRoYXQgdGhlIGluZ3Jlc3Mg bm9kZSBzaG91bGQgbWF5YmUgZXZlbiBzdG9wIHRoZSB0cmFmZmljIHRoZXJlLCBvciBtYXliZSBu b3Qgc2VuZGluZyBpdCB1bmxlc3MgYWxsIG5vZGVzIGluIHRoZSBwYXRoIHN1cHBvcnQgdGhlIHNh bWUgYWxnb3JpdGht4oCmDQoNCg0KTTUuIFNlY3Rpb24gMy4xLjIuIChNUExTIERhdGFwbGFuZSku DQoNCk01LjEuIFRoZSBmaXJzdCBidWxsZXQgKGFnYWluISkgZXhwbGFpbnMgdGhlIGFyY2hpdGVj dHVyZSBpbiBmdW5jdGlvbiBvZiB0aGUgZXh0ZW5zaW9ucy4gIFRoZSBhcmNoaXRlY3R1cmUgc2hv dWxkIGV4cGxhaW4gd2hhdCBuZWVkcyB0byBiZSBkb25lIGFuZCB0aGUgZXh0ZW5zaW9ucyB3b3Vs ZCB0aGVuIGRvIGl04oCmICBTdWdnZXN0aW9uOg0KDQpORVc+DQogICBJbiBvcmRlciB0byBhY2hp ZXZlIGEgYmVoYXZpb3IgZXF1aXZhbGVudCB0byBQZW51bHRpbWF0ZSBIb3AgUG9wcGluZw0KICAg aW4gTVBMUyBbUmVmZXJlbmNlXSwgYSBOb2RlIE4gYWR2ZXJ0aXNpbmcgYSBQcmVmaXgtU0lEIFNJ RC1SIGZvciBpdHMNCiAgIGF0dGFjaGVkIHByZWZpeCBSIE1VU1QgYmUgYWJsZSB0byBpbnN0cnVj dCBpdHMgY29ubmVjdGVkIG5laWdoYm9ycyB0bw0KICAgcGVyZm9ybSB0aGUgTkVYVCBvcGVyYXRp b24gd2hpbGUgcHJvY2Vzc2luZyBTSUQtUi4gIFVwb24gcmVjZWl2aW5nDQogICB0aGlzIGluc3Ry dWN0aW9uIGZyb20gTm9kZSBOLCBpdHMgbmVpZ2hib3JzIG9mIE4gTVVTVCBwZXJmb3JtIHRoZSBO RVhUDQogICBvcGVyYXRpb24gd2hpbGUgcHJvY2Vzc2luZyBTSUQtUi4gIEFsdGVybmF0aXZlbHks IHRoZSBuZWlnaGJvcnMgb2YgTg0KICAgTVVTVCBwZXJmb3JtIHRoZSBDT05USU5VRSBvcGVyYXRp b24gd2hpbGUgcHJvY2Vzc2luZyBTSUQtUi4NCg0KTTUuMS4xLiBUaGUgcGVudWx0aW1hdGUgYnVs bGV0IHJlZmVycyBhZ2FpbiB0byB0aGUgZXh0ZW5zaW9ucyAoYnV0IGl0IG9ubHkgbWVudGlvbnMg dGhlIFAtYml0IHRoaXMgdGltZSkuICBQbGVhc2UgZXhwbGFpbiB3aGF0IHRoZSBhcmNoaXRlY3R1 cmUgaW50ZW5kcyB0byBkbywgYnV0IG5vdCBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBl eHRlbnNpb25zLiAgVGhpcyBhbmQgdGhlIGxhc3QgYnVsbGV0IHNlZW0gdG8gYmUgdGhlIHJlc3Vs dCBvZiB0aGUgZmlyc3Qgb25lIChhYm92ZSkuICBJIHRoaW5rIHRoYXQgdGhlIGZpcnN0IGJ1bGxl dCB3b3VsZCBoYXZlIGVub3VnaCB0ZXh0IGZvciB0aGUgRklCIGVudHJpZXMgdG8gYmUgb2J2aW91 cywgYnV0IGlmIHlvdSB3YW50IHRvIGluY2x1ZGUgdGhpcyBjb3JvbGxhcnksIHBsZWFzZSBkbyBp dCByaWdodCBhZnRlci4NCg0KTTUuMi4g4oCcQSBQcmVmaXgtU0lEIGlzIGFsbG9jYXRlZCBpbiB0 aGUgZm9ybSBvZiBhbiBpbmRleCBpbiB0aGUgU1JHQiAob3IgYXMgYSBsb2NhbCBNUExTIGxhYmVs KSBhY2NvcmRpbmcgdG8gYSBwcm9jZXNzIHNpbWlsYXIgdG8gSVAgYWRkcmVzcyBhbGxvY2F0aW9u LuKAnSAgVGhlIFNSR0IgaXMgZGVmaW5lZCAoaW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24pIGFz IOKAnHRoZSBzZXQgb2YgbG9jYWwgbGFiZWxzIHJlc2VydmVkIGZvciBnbG9iYWwgc2VnbWVudHPi gJ0sIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiDigJxhbiBpbmRleCBpbiB0aGUgU1JH QuKAnSBhbmQg4oCcYSBsb2NhbCBNUExTIGxhYmVs4oCdPyAgSeKAmW0gaG9waW5nIHRoYXQgdGhl IGV4cGxhbmF0aW9uIG9mIHRoZSBjb25jZXB0IG9mIGluZGV4IHdvdWxkIGNsYXJpZnkgdGhpcy4N Cg0KTTUuMi4xLiBUaHJlZSBidWxsZXRzIGRvd27igKYg4oCcSWYgYSBub2RlIGxlYXJucyBhIFBy ZWZpeC1TSUQgaGF2aW5nIGEgdmFsdWUgdGhhdCBmYWxscyBvdXRzaWRlIHRoZSBsb2NhbGx5IGNv bmZpZ3VyZWQgU1JHQiByYW5nZSwgdGhlbiB0aGUgbm9kZSBNVVNUIE5PVCB1c2UgdGhlIFByZWZp eC1TSUTigKbigJ0gIEdvaW5nIGJhY2sgdG8gbXkgcHJldmlvdXMgcXVlc3Rpb246IGl0IGxvb2tz IGxpa2Ug4oCcYSBsb2NhbCBNUExTIGxhYmVs4oCdIHdvdWxkIGhhdmUgdG8gYmUgaW5jbHVkZWQg aW4gdGhlIFNSR0Ig4oCTIGFnYWluLCBjbGFyaWZ5aW5nIHVwZnJvbnQgd291bGQgaGVscCBhIGxv dC4gIE5vdGUgdGhhdCB0aGlzIHBpZWNlIG9mIHRleHQgZmFsbHMgaW50byB0aGUgcmVjb21tZW5k YXRpb24gb2YgaGF2aW5nIHRoZSBzYW1lIFNSR0IgY29uZmlndXJlZCBpbiBhbGwgbm9kZXMuDQoN Ck01LjIuMi4gIFJlbGF0ZWQgdG8gdGhlIGNvbmNlcHQgb2YgaW5kZXggYW5kIGl0cyByZWxhdGlv bnNoaXAgdG8gdGhlIFNSR0LigKZ0aGUgbmV4dCBidWxsZXQgc2F5czog4oCc4oCmdGhlIHNlZ21l bnQgaXMgZ2xvYmFsICh0aGUgU0lEIGlzIGFsbG9jYXRlZCBmcm9tIHRoZSBTUkdCIG9yIGFzIGFu IGluZGV4KeKAnS4gIFdlIG5vdyBoYXZlIOKAnGdsb2JhbGx5LXVuaXF1ZSBpbmRleOKAnSwg4oCc YW4gaW5kZXggaW4gdGhlIFNSR0LigJ0sIGFuZCDigJx0aGUgU1JHQiBvciBhcyBhbiBpbmRleOKA nSAoc2VwYXJhdGVseSkuDQoNCg0KTTYuIFNlY3Rpb24gMy4zLiAoSUdQLUFueWNhc3QgU2VnbWVu dCwgQW55Y2FzdCBTSUQpOiDigJzigKZ0aGUgdmFsdWUgb2YgdGhlIFNJRCBmb2xsb3dpbmcgdGhl IGFueWNhc3QgU0lEIE1VU1QgYmUgdW5kZXJzdG9vZCBieSBhbGwgbm9kZXMgYWR2ZXJ0aXNpbmcg dGhlIHNhbWUgYW55Y2FzdCBzZWdtZW50LuKAnSAgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIGlz IHJlYWxseSBhIHN0YXRlbWVudCBvZiBmYWN0OiBhbGwgbm9kZXMsIG5vdCBqdXN0IG9uZXMgYWR2 ZXJ0aXNpbmcgYW4gYW55Y2FzdCBzZWdtZW50IG11c3QgdW5kZXJzdGFuZCB3aGF0IHRvIGRvIHdp dGggdGhlIG5leHQgU0lE4oCmICBJT1csIHMvTVVTVC9tdXN0ICBJIHdvdWxkIGV2ZW4gdGFrZSB0 aGlzIHNlbnRlbmNlIG91dCBiZWNhdXNlIGl0IGlzIHJlZHVuZGFudCBhbmQgb2J2aW91cy4NCg0K DQpNNy4gU2VjdGlvbiAzLjQuIChJR1AtQWRqYWNlbmN5IFNlZ21lbnQsIEFkai1TSUQpIGFsc28g dHJpZXMgdG8gZXhwbGFpbiBmdW5jdGlvbmFsaXR5IHN0YXJ0aW5nIGZyb20gdGhlIGV4dGVuc2lv bnMuDQoNCk03LjEuIOKAnFRoZSBlbmNvZGluZ3Mgb2YgdGhlIEFkai1TSUQgaW5jbHVkZSB0aGUg YSBzZXQgb2YgZmxhZ3MgYW1vbmcgd2hpY2ggdGhlcmUgaXMgdGhlIEItZmxhZy4gIFdoZW4gc2V0 LCB0aGUgQWRqLVNJRCByZWZlcnMgdG8gYW4gYWRqYWNlbmN5IHRoYXQgaXMgZWxpZ2libGUgZm9y IHByb3RlY3Rpb24gKGUuZy46IHVzaW5nIElQRlJSIG9yIE1QTFMtRlJSKS7igJ0gIElmIHRoZSBB ZGphY2VuY3kgU2VnbWVudCBpcyBvbmUgdGhhdCBpcyBsb2NhbGx5IHNpZ25pZmljYW50IHRvIHRo ZSBub2RlIGFkdmVydGlzaW5nIGl0LCB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHNpZ25hbGluZyB0 aGF0IGl0IGlzIGVsaWdpYmxlIGZvciBwcm90ZWN0aW9uPyAgV291bGRu4oCZdCB0aGF0IGJlIGEg bG9jYWwgZGVjaXNpb24gYXMgd2VsbD8gIE1heWJlIGFuIGV4YW1wbGUgb2YgaG93IHRoZSBhcmNo aXRlY3R1cmUgaXMgZXhwZWN0ZWQgdG8gd29yayB3b3VsZCBoZWxwLg0KDQpNNy4yLiDigJxUaGUg ZW5jb2RpbmdzIG9mIHRoZSBBZGotU0lEIGFsc28gaW5jbHVkZSB0aGUgTC1mbGFnLiAgV2hlbiBz ZXQsIHRoZSBBZGotU0lEIGhhcyBsb2NhbCBzaWduaWZpY2FuY2UuICBCeSBkZWZhdWx0LCB0aGUg TC1mbGFnIGlzIHNldC7igJ0gIFRoZSBkZWZpbml0aW9uIG9mIElHUC1BZGphY2VuY3kgU2VnbWVu dCBhbHJlYWR5IHNheXMgdGhhdCBpdCBpcyDigJxsb2NhbCAodW5sZXNzIGV4cGxpY2l0bHkgYWR2 ZXJ0aXNlZCBvdGhlcndpc2Up4oCdLCB3aGljaCBtYWtlcyB0aGlzIHN0YXRlbWVudCB1bm5lY2Vz c2FyeS4gIElmIHlvdSB3YW50IHRvIGtlZXAgaXQsIHBsZWFzZSBmaWd1cmUgb3V0IGEgd2F5IHRo YXQgZG9lc27igJl0IGp1c3RpZnkgaXQgYmFzZWQgb24gYSBiaXQgaW4gdGhlIGV4dGVuc2lvbnMu DQoNCg0KTTguIFNlY3Rpb24gMy41LiAoQmluZGluZyBTZWdtZW50KS4gIEEgYmluZGluZyBzZWdt ZW50IGlzIG5vdCBkZXNjcmliZWQgYW55d2hlcmUgaW4gdGhpcyBkb2N1bWVudCDigJMgcGxlYXNl IGRvIHNvISAgU2VjdGlvbiAzLjUuMS4gKE1hcHBpbmcgU2VydmVyKSBtZW50aW9ucyBhIOKAnFJl bW90ZS1CaW5kaW5nIFNJRCBTIGFkdmVydGlzZWQgYnkgdGhlIG1hcHBpbmcgc2VydmVy4oCdLCBh bmQgc2F5cyB0aGF0IG1vcmUg4oCcZGV0YWlscyBhcmUgZGVzY3JpYmVkIGluIHRoZSBTUi9MRFAg aW50ZXJ3b3JraW5nIHByb2NlZHVyZXMgKFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LWxkcC1pbnRlcm9wXeKAnSwgYnV0IHRoYXQgZHJhZnQgZG9lc27igJl0IG1lbnRpb24gYSBCaW5k aW5nIFNlZ21lbnQuICBTZWN0aW9uIDUuIChJR1AgTWlycm9yaW5nIENvbnRleHQgU2VnbWVudCkg c2F5cyB0aGF0IOKAnHRoZSBiaW5kaW5nIHNlZ21lbnQgW2lzXSBkZWZpbmVkIGluIFNSIElHUCBw cm90b2NvbCBleHRlbnNpb25zICggW0ktRC5pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVu c2lvbnNdLCBbSS1ELmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10gYW5kIFtJ LUQuaWV0Zi1vc3BmLW9zcGZ2My1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10p4oCdOyBob3dl dmVyLCB0aG9zZSBkb2N1bWVudHMgZG9u4oCZdCBtZW50aW9uIGEgQmluZGluZyBTZWdtZW50LCB0 aGV5IGp1c3QgKGV4Y2VwdCBmb3IgdGhlIE9TUEZ2MiBkcmFmdCkgZGVmaW5lIFRMVnMuICBOb3Rl IHRoYXQgSS1ELmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucyBwb2ludHMgYmFj ayB0byB0aGlzIGRvY3VtZW50IHdoZW4gcmVmZXJyaW5nIHRvIHRoZSBkZWZpbml0aW9uIG9mIGEg QmluZGluZyBTSUQsIGNvbXBsZXRpbmcgYSBjaXJjdWxhciByZWZlcmVuY2UuDQoNCk04LjEuIEJU VywgU2VjdGlvbiA1LiAoSUdQIE1pcnJvcmluZyBDb250ZXh0IFNlZ21lbnQpIHNheXMgdGhhdCB0 aGUg4oCcTWlycm9yIFNJRCBpcyBhZHZlcnRpc2VkIHVzaW5nIHRoZSBiaW5kaW5nIHNlZ21lbnTi gJ0sIHdoaWNoIHRoZW4gbG9va3MgbGlrZSB0aGUgTWlycm9yIFNlZ21lbnQgaXMgYW4gYXBwbGlj YXRpb24gb2YgdGhlIEJpbmRpbmcgU2VnbWVudCAoKyBhbiBleHBsaWNpdCBpbmRpY2F0aW9uIG9m IGl0KS4gIEkgdGhpbmsgdGhhdCBTZWN0aW9uIDUgc2hvdWxkIHRoZW4gYmUgbW92ZWQgdG8gYmUg YSBzdWItc2VjdGlvbiBvZiAzLjUuDQoNCk04LjIuIFBhcnQgb2YgdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIChpbiBTZWN0aW9uIDguMSkgYXJlIHJlbGF0ZWQgdG8gdGhlIEJpbmRpbmcgU0lE LCB3aGljaCBpcyBhbm90aGVyIHJlYXNvbiBmb3IgY2xlYXJseSBleHBsYWluaW5nIHRoYXQgcGFy dCBvZiB0aGUgYXJjaGl0ZWN0dXJlIGhlcmUuDQoNCg0KTTkuIFNlY3Rpb24gMy41LjEuIChNYXBw aW5nIFNlcnZlcikgbWVudGlvbnMgYSBNYXBwaW5nIFNlcnZlciwgYnV0IGl0IHB1bnRzIHRvIEkt RC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3AgZm9yIGZ1cnRoZXIgZGV0 YWlscy4gIFdoaWxlIHRoZSBTUk1TIGNhbiBiZSB1c2VkIGZvciBpbnRlcm9wZXJhYmlsaXR5IGNh c2VzLCBJIHRoaW5rIHRoYXQgaXQgaXMgYW4gaW1wb3J0YW50IHBhcnQgb2YgdGhlIG92ZXJhbGwg YXJjaGl0ZWN0dXJlIGFuZCBhcyBzdWNoIGl0IHNob3VsZCBiZSBkZXNjcmliZWQgYW5kIGRpc2N1 c3NlZCBpbiB0aGlzIGRvY3VtZW50IGluc3RlYWTigKZpbmNsdWRpbmcgYW55IE1hbmFnZWFiaWxp dHkgQ29uc2lkZXJhdGlvbnMgKGFzIG1lbnRpb25lZCBpbiBTZWN0aW9uIDkpLg0KDQoNCk0xMC4g U2VjdGlvbiAzLjYuIChJbnRlci1BcmVhIENvbnNpZGVyYXRpb25zKQ0KDQpNMTAuMS4gVGhpcyBz ZWN0aW9uIHNob3dzIGFuIGV4YW1wbGUgb2YgdGhlIGJlaGF2aW9yOiBtYWludGFpbiB0aGUgU0lE IGFjcm9zcyBhcmVhIGJvdW5kYXJpZXMuICBCdXQgaXQgZG9lc27igJl0IGFjdHVhbGx5IHNheSBo b3cgdGhlIGFyY2hpdGVjdHVyZSBpcyBleHBlY3RlZCB0byB3b3JrLiAgSU9XLCBpbiB0aGUgZXhh bXBsZSB0aGUgU0lEIGlzIG1haW50YWluZWQsIGJ1dCBzaG91bGQgdGhhdCBhbHdheXMgaGFwcGVu IChNVVNULCBTSE9VTEQpPyBPciBpcyBpdCBqdXN0IGFuIGV4YW1wbGUgKE1BWSk/DQoNCk0xMC4y LiBBbm90aGVyIGNhc2Ugb2YgZXhwbGFpbmluZyB0aGUgYXJjaGl0ZWN0dXJlIGJhc2VkIG9uIHRo ZSBleHRlbnNpb24gZnVuY3Rpb25hbGl0eTog4oCcV2hlbiBhbiBBQlIgcHJvcGFnYXRlcyBhIHBy ZWZpeCBmcm9tIG9uZSBhcmVhIHRvIGFub3RoZXIgaXQgTVVTVCBzZXQgdGhlIFItRmxhZy7igJ0g IE1heWJlIHRyeSBzb21ldGhpbmcgbGlrZSB0aGlzIGluc3RlYWQ6IOKAnFRoZSByZS1hZHZlcnRp c2VtZW50IG9mIGFuIFNJRCB0aGF0IG9yaWdpbmF0ZWQgb24gYSBkaWZmZXJlbnQgSUdQIGFyZWEg TVVTVCBiZSBpbmRpY2F0ZWQu4oCdDQoNCk0xMC4zLiBbbWlub3JdIEFzIHRoZSBhZHZlcnRpc2Vt ZW50IG1vdmVzIHRvIHRoZSBsZWZ0IChmcm9tIEFyZWEgMiB0byB0aGUgQmFja2JvbmXigKYpLCB0 aGUgQUJScyBjaGFuZ2UgdGhlIE5vZGUtU0lEIGZvciBhIFByZWZpeC1TSUQsIHJpZ2h0PyAgVGhl IGRlc2NyaXB0aW9uIGluIHRoZSBsYXN0IDMgcGFyYWdyYXBocyB1c2VzIE5vZGUtU0lEOiDigJxu b2RlIFPigKZwdXNoZXMgTm9kZS1TSUQoMTUwKeKAnS4NCg0KTTEwLjQuIFttaW5vcl0gR29pbmcg YmFjayB0byBnbG9iYWwgdnMgbG9jYWwgc2lnbmlmaWNhbmNlLCBpdCB3b3VsZCBiZSBuaWNlIHRv IHJlbWluZCB0aGUgcmVhZGVycyBhdCB0aGlzIHBvaW50IHRoYXQgdGhlIFNSIGRvbWFpbiBpcyBy ZWFsbHkgdGhlIHdob2xlIElHUCBuZXR3b3JrLCBhbmQgbm90IGp1c3Qgb25lIGZsb29kaW5nIGRv bWFpbuKApndoaWNoIGlzIHdoeSBTSUQgMTUwIGNhbiBiZSB1c2VkIHRocm91Z2hvdXQuDQoNCg0K TTExLiBTZWN0aW9uIDQuIChCR1AgUGVlcmluZyBTZWdtZW50cykgaXMgdGhlIG9ubHkgbm9uLUlH UCBmb2N1c2VkIHNlY3Rpb24gaW4gdGhpcyBkb2N1bWVudC4gIFRoZSBhcmNoaXRlY3R1cmUgb2Yg dGhlIEVQRSBzb2x1dGlvbiAoYXMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1jZW50cmFsLWVwZSkgZ29lcyBiZXlvbmQgd2hhdCBoYXMgYWxyZWFkeSBiZWVu IGRpc2N1c3NlZCBoZXJlIGJlY2F1c2UgaXQgaW5jb3Jwb3JhdGVzIGVsZW1lbnRzIHN1Y2ggYXMg YSBtYW5kYXRvcnkgY2VudHJhbGl6ZWQgY29udHJvbGxlciwgd2hpY2ggd2FzIG9wdGlvbmFsIGJl Zm9yZSAoYSBQQ0Ugc2VydmVyIGlzIG1lbnRpb25lZCBvbmx5IGNhc3VhbGx5IGluIHRoZSBUZXJt aW5vbG9neSBzZWN0aW9uKS4gIFRoaXMgbGVhdmVzIHVzIHdpdGggYW4gaW5jb21wbGV0ZSBhcmNo aXRlY3R1cmUgZm9yIHRoZSBCR1AgY2FzZS4gIEkgd291bGQgcHJlZmVyIGl0IGlmIHRoZSB3aG9s ZSBhcmNoaXRlY3R1cmUgd2FzIGRlZmluZWQgaW4gdGhpcyBzaW5nbGUgZG9jdW1lbnQgKGkuZS4g ZXhwYW5kIHRoaXMgc2VjdGlvbiBieSBwb3RlbnRpYWxseSBtb3ZpbmcgcGFydHMgZnJvbSBkcmFm dC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUg4oCTIHdoaWNoIG1pZ2h0 IGxlYXZlIHRoYXQgZG9jdW1lbnQgd2l0aG91dCBlbm91Z2ggY29udGVudCB0byBzdGFuZCBhbG9u ZSkuDQoNCg0KTTEyLiBTZWN0aW9uIDguIChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykuICBUaGUg bWFpbiBwYXJ0IG9mIHRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCB0aGUgaW5zdHJ1Y3Rpb25zIG9u IHRoZSBwYWNrZXRzIOKAkyBpcyBhZGRpbmcgdGhhdCBtZXRhLWRhdGEgYSBzZWN1cml0eSBjb25j ZXJuPyAgSSB0aGluayBpdCBjb3VsZCBiZSBiZWNhdXNlIHNvbWVvbmUgd2F0Y2hpbmcgY291bGQg dGVsbCB3aGljaCDigJxmb3J3YXJkaW5nIHBhdGggZWxlbWVudHMgKGUuZy46IG5vZGVzLCBsaW5r cywgc2VydmljZXMsIGV0Yy4p4oCdIGFyZSB1c2VkIGZvciBzcGVjaWZpYyBmbG93cywgZXRjLiAg IEJ1dCBJIGFsc28gdGhpbmsgdGhhdCB0aGUgcmlzayBpcyBtaXRpZ2F0ZWQgYnkgdGhlIGZhY3Qg dGhhdCB0aGUgaW5mb3JtYXRpb24gTVVTVCBOT1QgYmUgZXhwb3NlZCBvdXRzaWRlIHRoZSBTUiBk b21haW4uICBNZW50aW9uaW5nIHRoYXQsIGFuZCB0aGUgZmFjdCB0aGF0IHRoZSBTUiBkb21haW4g d2lsbCB1c3VhbGx5IGJlIHVuZGVyIGEgc2luZ2xlIGFkbWluaXN0cmF0aW9uIHdvdWxkIGJlIGEg Z29vZCB0aGluZy4NCg0KDQpNMTMuIFNlY3Rpb24gOS4gKE1hbmFnZWFiaWxpdHkgQ29uc2lkZXJh dGlvbnMpIHNheXMgdGhhdCDigJxhbiBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgcHJvdGVjdCB0aGUg bmV0d29yayBpbiBjYXNlIG9mIGNvbmZsaWN0IGRldGVjdGlvbiBieSBwcm92aWRpbmcgYSBkZXRl cm1pbmlzdGljIHJlc29sdXRpb24gYXBwcm9hY2jigKZhZGRyZXNzZWQgaW4gW0ktRC5pZXRmLXNw cmluZy1jb25mbGljdC1yZXNvbHV0aW9uXS7igJ0gIFRoYXQg4oCcU0hPVUxE4oCdIGlzIGluIGNv bmZsaWN0IHdpdGggSS1ELmlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gKGluIFdHTEMp IHdoZXJlIGl0IHNheXMgdGhhdCDigJxBbGwgcHJvdG9jb2xzIHdoaWNoIHN1cHBvcnQgU1IgTVVT VCBhZGhlcmUgdG8gdGhlIHBvbGljaWVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC7igJ0gIEl0 IHNlZW1zIGxpa2UgdGhlIGVhc3kgd2F5IGZvcndhcmQgaXMgdG8gcy9TSE9VTEQvTVVTVC4gIElu IGVpdGhlciBjYXNlLCBJIHRoaW5rIHRoYXQgSS1ELmlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24gc2hvdWxkIGJlIGEgTm9ybWF0aXZlIHJlZmVyZW5jZS4NCg0KDQoNCk1pbm9yOg0KDQpQ MS4gSW50cm9kdWN0aW9uDQoNClAxLjEuIFRoZSB0ZXJtIOKAnHNlcnZpY2UgY2hhaW7igJ0gaXMg dXNlZCBpbiB0aGUgQWJzdHJhY3QgYW5kIGluIHRoZSBJbnRyb2R1Y3Rpb24uICBHaXZlbiB0aGF0 IHRoZSBjb25jZXB0IGlzIG5vdCB2aXRhbCB0byB0aGUgYXJjaGl0ZWN0dXJlIGFuZCB0aGF0IHRo ZXJlIG1pZ2h0IGJlIHVubmVjZXNzYXJ5IGNvbmZ1c2lvbiB3aXRoIFNGQywgSSB3b3VsZCBzdWdn ZXN0IHRha2luZyBpdCBvdXQuDQoNClAxLjIuICBSZWxhdGVk4oCmICBTZWN0aW9uIDEuMSBzYXlz IHRoYXQgdGhpcyBkb2N1bWVudCDigJxkZWZpbmVz4oCmdGhlIHNlcnZpY2Ugc2VnbWVudHPigJ0s IGJ1dCB0aGVyZeKAmXMgbm8gc3BlY2lmaWMgbWVudGlvbiBvZiDigJxzZXJ2aWNlIHNlZ21lbnRz 4oCdIGFueXdoZXJlLCBleGNlcHQgZm9yIGEgdmVyeSBxdWljayBtZW50aW9uIGluIFNlY3Rpb24g NS4gKElHUCBNaXJyb3JpbmcgQ29udGV4dCBTZWdtZW50KS4gIFdoYXQgYW0gSSBtaXNzaW5nPyAg Q29uc2lkZXIgdGFraW5nIOKAnHNlcnZpY2Ugc2VnbWVudHPigJ0gb2ZmIHRoZSBsaXN0IG9mIHRo aW5ncyB0aGlzIGRvY3VtZW50IGRlZmluZXMuDQoNClAxLjMuIFRoZSBsYXN0IHBhcmFncmFwaCBz YXlzIHRoYXQg4oCcVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2V0IG9mIGluc3RydWN0aW9ucyAo Y2FsbGVkIHNlZ21lbnRzKSB0aGF0IGFyZSByZXF1aXJlZCB0byBmdWxmaWxsIHRoZSBkZXNjcmli ZWQgdXNlLWNhc2VzLuKAnSAgVGhlIHVzZSBjYXNlcyBhcmUgbm90IG1lbnRpb25lZCB1bnRpbCAx LjEuICBTdWdnZXN0aW9uOiBtZXJnZSBTZWN0aW9uIDEgYW5kIDEuMSB0byBwcm92aWRlIHByb3Bl ciBmbG93IHRvIHRoZSB0ZXh0Lg0KDQpQMS40LiBTcGVha2luZyBvZiB1c2UgY2FzZXMsIEktRC5p ZXRmLXNwcmluZy1vYW0tdXNlY2FzZSBkb2VzbuKAmXQgYWN0dWFsbHkgaW5jbHVkZSB1c2UgY2Fz ZXMgdGhhdCB3aWxsIGFmZmVjdCB0aGUgYXJjaGl0ZWN0dXJlLiAgSXQgaW5jbHVkZXMgdXNlIGNh c2Ugb2YgaG93IHRvIHVzZSBtb25pdG9yaW5nIHN5c3RlbSBkZWZpbmVkIGluIGl0LiAgU2FtZSBj b21tZW50IGZvciB0aGUgbWVudGlvbiBpbiBTZWN0aW9uIDkuDQoNCg0KUDIuIEZyb20gU2VjdGlv biAyLiAoVGVybWlub2xvZ3kpDQoNClAyLjEuIFNJRCBpcyBub3QgZGVmaW5lZCwganVzdCBleHRl bmRlZC4gIEJlc2lkZXMgdGhlIGV4YW1wbGVzLCBwbGVhc2UgcHJvdmlkZSBhbiBhY3R1YWwgZGVm aW5pdGlvbi4NCg0KUDIuMi4g4oCcVGhlIENPTlRJTlVFIGluc3RydWN0aW9uIGlzIGltcGxlbWVu dGVkIGFzIHRoZSBTV0FQIGluc3RydWN0aW9uIGluIHRoZSBNUExTIGRhdGFwbGFuZS7igJ0gIFBs ZWFzZSBpbmNsdWRlIGEgcmVmZXJlbmNlIHRvIHdoZXJlIHRoZSDigJxTV0FQIGluc3RydWN0aW9u 4oCdIGlzIGRlZmluZWQuICBJIGFzc3VtZSB5b3XigJlyZSByZWFsbHkgcmVmZXJyaW5nIHRvIOKA nGxhYmVsIHN3YXBwaW5n4oCdIGluIHJmYzMwMzEsIGFyZSB5b3U/ICBJZiBzbywgcGxlYXNlIGJl IGNvbnNpc3RlbnQgYXMg4oCcTVBMUyBkYXRhcGxhbmXigJ0gYW5kIOKAnE1QTFMgYXJjaGl0ZWN0 dXJl4oCdIGFyZSB1c2VkIGluIGRpZmZlcmVudCBwbGFjZXMuDQoNClAyLjMuIFRoZSDigJxMb2Nh bCBTZWdtZW504oCdIGRlZmluaXRpb24gc2F5cyB0aGF0IGZvciBJUHY2IGl0IOKAnGlzIG5vdCBh ZHZlcnRpc2VkIGluIGFueSByb3V0aW5nIHByb3RvY29s4oCdLiAgQnV0IGZvciBNUExTIGl0IGlz IGFkdmVydGlzZWQsIHJpZ2h0PyAgUGxlYXNlIGNsYXJpZnkuICBJIHRoaW5rIHRoYXQgc29tZSBv ZiB0aGUgdm9jYWJ1bGFyeSBpcyBhIGxpdHRsZSBjb25mdXNpbmcsIGZvciBleGFtcGxlLCB0aGUg ZGVmaW5pdGlvbiBvZiBJR1AtQWRqYWNlbmN5IFNlZ21lbnQgc2F5cyB0aGF0IGl0IOKAnGlzIGxv Y2FsICh1bmxlc3MgZXhwbGljaXRseSBhZHZlcnRpc2VkIG90aGVyd2lzZSkgdG8gdGhlIG5vZGUg dGhhdCBhZHZlcnRpc2VzIGl04oCdIOKAkyB0aGlzIG1lYW5zIHRoYXQgZm9yIElQdjYgdGhpcyBw aWVjZSBvZiB0aGUgYXJjaGl0ZWN0dXJlIHdvdWxkbuKAmXQgYXBwbHkgYmVjYXVzZSBhIExvY2Fs IFNlZ21lbnQgaXMgbm90IGFkdmVydGlzZWQuICBUbyBhZGQgdG8gdGhlIGNvbmZ1c2lvbiwgZHJh ZnQtZmlsc2ZpbHMtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZyB0YWxrcyBhYm91dCBs b2NhbCBTSURz4oCmICBJT1csIGluIHNvbWUgcGxhY2VzIGl0IHNvdW5kcyBhcyBpZiB3aGF0IHNo b3VsZCBiZSB0aGUgZ2VuZXJhbCBhcmNoaXRlY3R1cmUgb25seSByZWFsbHkgYXBwbGllcyB0byBN UExTIOKAkyBvciBtYXliZSB3ZSBuZWVkIGEgbW9yZSBleHBsaWNpdCBsb2NhbCBxdWFsaWZpZXIu DQoNClAyLjQuIOKAnFRoZSBQQ0VQIGRpc2NvdmVyeSBjYXBhYmlsaXR5IGlzIGRlc2NyaWJlZCBp biBbSS1ELmlldGYtcGNlLXNlZ21lbnQtcm91dGluZ10u4oCdICBUaGF0IGRvY3VtZW50IGRvZXNu 4oCZdCBldmVuIG1lbnRpb24gdGhlIHdvcmQg4oCcZGlzY292ZXJ54oCdLiAgUGxlYXNlIHVzZSB0 aGUgcHJvcGVyIG5hbWUgZm9yIGVhc2llciBjcm9zcy1yZWZlcmVuY2UuDQoNClAyLjUuIOKAnHVu bGVzcyBleHBsaWNpdGx5IGFkdmVydGlzZWQgb3RoZXJ3aXNl4oCdIGlzIHVzZWQgdG8gcXVhbGlm eSB0aGUgZ2xvYmFsL2xvY2FsIG5hdHVyZSBvZiBhIHNlZ21lbnQuICBIb3cgZG8gdGhlIGNoYXJh Y3RlcmlzdGljcyBvZiB0aGUgc2VnbWVudCBjaGFuZ2UgaWYg4oCcZXhwbGljaXRseSBhZHZlcnRp c2VkIG90aGVyd2lzZeKAnT8gIEZvciBleGFtcGxlLCBpZiBhbiBJR1AtUHJlZml4IFNlZ21lbnQg aXMgYWR2ZXJ0aXNlZCBhcyBsb2NhbCwgaG93IGRvIGl0cyBjaGFyYWN0ZXJpc3RpY3MgY2hhbmdl LCBvciBkbyB0aGV5Pw0KDQpQMi41LjEuIEluIFNlY3Rpb24gMy40LiAoSUdQLUFkamFjZW5jeSBT ZWdtZW50LCBBZGotU0lEKSwgdGhlIHVzZSBvZiBhbiBBZGotU0lEIGlzIGlsbHVzdHJhdGVkIGZv ciBib3RoIHRoZSBsb2NhbCBhbmQgZ2xvYmFsIGNhc2VzLCBidXQgYm90aCBleHBsYW5hdGlvbnMg c2F5IHRoZSBzYW1lIHRoaW5nOiDigJxmb3J3YXJkZWQgYWxvbmcgdGhlIHNob3J0ZXN0LXBhdGgg dG8gTiBhbmQgdGhlbiBiZSBzd2l0Y2hlZCBieSBOLCB3aXRob3V0IGFueSBJUCBzaG9ydGVzdC1w YXRoIGNvbnNpZGVyYXRpb24sIHRvd2FyZHMgbGluayBM4oCdIOKAkyBJIGRvbuKAmXQgc2VlIGEg ZGlmZmVyZW5jZSBpbiBiZWhhdmlvciBiZXR3ZWVuIHRoZSBsb2NhbCBhbmQgZ2xvYmFsIG5hdHVy ZSBvZiB0aGlzIFNJRC4gIFRoZXJlIGlzIHNvbWUgYWRkaXRpb25hbCB0ZXh0IHJlbGF0ZWQgdG8g Z2xvYmFsOiDigJxUaGUgdXNlIG9mIGdsb2JhbCBBZGotU0lEIGFsbG93cyB0byByZWR1Y2UgdGhl IHNpemUgb2YgdGhlIHNlZ21lbnQgbGlzdCB3aGVuIGV4cHJlc3NpbmcgYSBwYXRoIGF0IHRoZSBj b3N0IG9mIGFkZGl0aW9uYWwgc3RhdGUgKGkuZS46IHRoZSBnbG9iYWwgQWRqLVNJRCB3aWxsIGJl IGluc2VydGVkIGJ5IGFsbCByb3V0ZXJzIHdpdGhpbiB0aGUgYXJlYSBpbiB0aGVpciBmb3J3YXJk aW5nIHRhYmxlKS7igJ0gIElmIG5vZGUgTiBpcyB0aGUgb25lIGV4ZWN1dGluZyBvbiB0aGUgQWRq LVNJRCwgaG93IGRvZXMgaW5jbHVkaW5nIGl0IGluIG90aGVyIEZJQnMgaGVscD8NCg0KUDIuNi4g Tm9uZSBvZiB0aGUgc2VnbWVudHMgYWZ0ZXIgU2VjdGlvbiAzLjQgKGJpbmRpbmcsIEJHUCwgbWly cm9yaW5nKSBhcmUgZGVmaW5lZCBpbiB0aGUgVGVybWlub2xvZ3kuICBQbGVhc2UgZG8gc28gZm9y IGNvbXBsZXRlbmVzcy4NCg0KDQpQMy4gUmVmZXJyaW5nIHRvIEZpZ3VyZSAxOiDigJzigKZlYWNo IFBFIGRldmljZSBpcyBjb25uZWN0ZWQgdG8gdHdvIHJvdXRlcnMgaW4gZWFjaCBvZiB0aGUgZ3Jv dXBzIEEgYW5kIEIu4oCdICBUaGUgcm91dGVycyBjb25uZWN0ZWQgdG8gdGhlIFBFcyAoUngpIGFy ZSBub3QgaW4gZWl0aGVyIGdyb3VwLg0KDQoNClA0LiBzL09idmlvdXNseS8vDQoNCg0KUDUuIFNl Y3Rpb24gMy40LiAoSUdQLUFkamFjZW5jeSBTZWdtZW50LCBBZGotU0lEKTog4oCcVGhlIHJlbW90 ZSBub2RlIE1BWSBiZSBhbiBhZGphY2VudCBJR1AgbmVpZ2hib3Igb3IgYSBub24tYWRqYWNlbnQg bmVpZ2hib3LigKbigJ0gIFRoZSDigJxNQVnigJ0gaXMgb3V0IG9mIHBsYWNlIGFzIHRoZXJlIGlz buKAmXQgYW5vdGhlciBvcHRpb24sIGl0IGlzIG9uZSBvciB0aGUgb3RoZXIuICBzL01BWS9tYXkN Cg0KDQpQNi4gTWF5YmUgaXTigJlzIGJlY2F1c2UgdGhlIHJlc3Qgb2YgMy41IGlzIGluY29tcGxl dGUsIGJ1dCBTZWN0aW9uIDMuNS4yLiAoVHVubmVsIEhlYWQtZW5kKSBoYXMgbm8gY29udGV4dCB0 byBzcGVhayBvZiDigJMgd2l0aG91dCB0aGF0LCBpdCBmZWVscyBsaWtlIGFuIG9ycGhhbiBzZWN0 aW9uLg0KDQoNClA3LiBTZWN0aW9uIDguMS4gKE1QTFMgRGF0YSBQbGFuZSkNCg0KUDcuMS4gWW91 IGluY2x1ZGVkIGEgY291cGxlIG9mIHJlZmVyZW5jZXMgYXQgdGhlIGVuZCBvZiB0aGlzIHNlY3Rp b24sIHdoaWNoIGlzIGdvb2QuICBJIHdvdWxkIGhvd2V2ZXIgbm90IGV4cGxpY2l0bHkgbWVudGlv biBzcGVjaWZpYyBzZWN0aW9ucywgYXMgdGhlIHdob2xlIFJGQ3MgKHJmYzQzODEgYW5kIHJmYzU5 MjApIGFyZSBhYm91dCBNUExTLXJlbGF0ZWQgc2VjdXJpdHkuDQoNClA3LjIuIFlvdSBjb21wYXJl IHRoZSB1c2Ugb2YgYSBzaW5nbGUgc2VnbWVudCB0byBSU1ZQLVRFIOKAkyBpZiB0aGUgc2VjdXJp dHkgY2hhcmFjdGVyaXN0aWNzIGFyZSBzaW1pbGFyLCBwbGVhc2UgcHJvdmlkZSBhIHJlZmVyZW5j ZS4NCg0KDQpQOC4gUmVmZXJlbmNlcw0KDQpQOC4xLiBSRkMyNDYwIHdhcyBvYnNvbGV0ZWQgYnkg UkZDODIwMCAvIFJGQzY4MjIgd2FzIG9ic29sZXRlZCBieSBSRkM4MjAyDQoNClA4LjIuIEkgdGhp bmsgdGhhdCB0aGUgcmVmZXJlbmNlIHRvIFJGQzQyMDYgc2hvdWxkIGJlIEluZm9ybWF0aXZlLg0K DQoNCg0KTml0czoNCg0KTjEuIFRoZSBBYnN0cmFjdCBpcyB2ZXJ5IGxvbmcg4oCTIEkgd291bGQg ZXZlbiBzYXkgdG9vIGxvbmcuICBJZiBpdCB3YXMgdXAgdG8gbWUsIEkgd291bGQgbGVhdmUganVz dCB0aGUgZmlyc3QgcGFyYWdyYXBoLg0KDQpOMi4gVGhlIHNlY29uZCB0byBsYXN0IHBhcmFncmFw aCBpbiB0aGUgSW50cm9kdWN0aW9uICjigJxOdW1lcm91cyB1c2UtY2FzZXPigKbigJ0pIHJlZmVy ZW5jZXMgdGhlIOKAnG1hcmtldGluZyBzdHlsZeKAnSBjb250ZW50IG9mIEktRC5pZXRmLXNwcmlu Zy1vYW0tdXNlY2FzZS4gIEkgaGF2ZSBhc2tlZCB0aGUgYXV0aG9ycyBvZiB0aGF0IGRvY3VtZW50 IHRvIHBsZWFzZSBmb2N1cyB0aGVpciBjb250ZW50LiAgUGxlYXNlIGNvbnNpZGVyIHRha2luZyB0 aGlzIHBhcmFncmFwaCBvdXQuDQoNCk4zLiBzL3BhcnRpY2lwYXRpbmcgaW50byB0aGUgc291cmNl IGJhc2VkL3BhcnRpY2lwYXRpbmcgaW4gdGhlIHNvdXJjZSBiYXNlZA0KDQpONC4gUmVmZXJlbmNl cy4gIFBsZWFzZSBhZGQgSW5mb3JtYXRpdmUgcmVmZXJlbmNlcyB0byBuZXRjb25mIChTZWN0aW9u IDIpLCBQQ0VQICgyKSwgRlJSICgzLjEuMSksIOKAnHBhcmFsbGVsIGFkamFjZW5jeSBzdXBwcmVz c2lvbuKAnSAoMy40KS4NCg0KTjUuIFNlY3Rpb24gMzog4oCcSUdQIHNlZ21lbnRzIHJlcXVpcmUg ZXh0ZW5zaW9ucyBpbiBsaW5rLXN0YXRlIElHUCBwcm90b2NvbHMuICBJR1AgZXh0ZW5zaW9ucyBh cmUgcmVxdWlyZWQgaW4gb3JkZXIgdG8gYWR2ZXJ0aXNlIHRoZSBJR1Agc2VnbWVudHMu4oCdICBU aGVzZSAyIHNlbnRlbmNlcyBzYXkgdGhlIGV4YWN0IHNhbWUgdGhpbmcuDQoNCk42LiBQbGVhc2Ug YXZvaWQgdXNpbmcg4oCcd2XigJ0gaW4gdGhlIHRleHQg4oCTIGV4Y2VwdCBmb3IgdGhlIEFja25v d2xlZGdlbWVudHMuDQoNCk43LiBzL1JlZ2FyZGxlc3MgU2VnbWVudCBSb3V0aW5nL0luZGVwZW5k ZW50IG9mIFNlZ21lbnQgUm91dGluZw0KDQpOOC4gcy9hbmQgbm90IHRvIGVhY2ggb3RoZXIgaW5k aXZpZHVhbCBub2RlcyBpbiB0aGUgTEFOL2FuZCBub3QgdG8gaW5kaXZpZHVhbCBub2RlcyBpbiB0 aGUgTEFODQoNCk45LiBzLyhbSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50 ZXJvcF0vW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3BdDQoNCk4x MC4g4oCcSUdQIGRlcGxveWVkIHVzaW5nIGFyZWFz4oCdICBBbiBhcmVhIGlzIGFuIE9TUEYtc3Bl Y2lmaWMgY29uc3RydWN0IOKAkyBmbG9vZGluZyBkb21haW4gaXMgbW9yZSBnZW5lcmljLg0KDQpO MTEuIEl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIGV4YW1wbGVzIHVzZWQgSVB2NiBpbnN0ZWFkIG9m IElQdjQuDQo= --_000_2AC310C5A42B4D4DB223B52E9BF37DB0ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8249364553B3DF41A4E9F9E05C1529D6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0K CWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm b250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNyIvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RGVhciBhdXRob3JzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3QgZmluaXNo ZWQgcmV2aWV3aW5nIHRoaXMgZG9jdW1lbnQg4oCTIHNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcHJv Y2Vzc2luZy4mbmJzcDsgVGhhbmtzIGZvciBhbGwgdGhlIHdvcmsgeW914oCZdmUgYnV0IGludG8g dGhpcyBkb2N1bWVudCE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHNvbWUgc2lnbmlm aWNhbnQgY29uY2VybnMgKHNlZSBiZWxvdyBmb3IgZGV0YWlscykuJm5ic3A7IEluIGdlbmVyYWws IHRoZSBkb2N1bWVudCBwcmVzZW50cyBhbiBpbmNvbXBsZXRlIHZpZXcgb2YgdGhlIGFyY2hpdGVj dHVyZTogZGV0YWlscyBhYm91dCBpbXBvcnRhbnQgcGllY2VzIGFyZSBiYXJlbHkgbWVudGlvbmVk IG9yIG5vdCBmdWxseSBkZXNjcmliZWQsIGFzIGlzIHRoZSBjYXNlIG9mIHRoZSByb2xlDQogb2Yg YSBjZW50cmFsIGNvbnRyb2xsZXIgKFBDRSksIGFuZCB0aGUgQkdQIGFuZCBCaW5kaW5nIFNlZ21l bnRzLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgc29tZSBvZiB0aGUgYXJj aGl0ZWN0dXJhbCBkZXRhaWxzIGFyZSBwcmVkaWNhdGVkIG9uIHNwZWNpZmljIGJpdHMgZGVmaW5l ZCBpbiB0aGUgZXh0ZW5zaW9ucywgd2hlcmUgdGhpcyBkb2N1bWVudCBzaG91bGQgZGVzY3JpYmUg dGhlIGdlbmVyYWwgb3BlcmF0aW9uIGFuZCBsZWF2ZSB0aGUgZGV0YWlscyAobGlrZSBiaXQgbmFt ZXMpIHRvIHRoZSBleHRlbnNpb25zLiZuYnNwOyBOb3RlIHRoYXQgSeKAmW0gbm90IGFza2luZw0K IHRoYXQgeW91IGRvbuKAmXQgbWVudGlvbiB0aGUgZXh0ZW5zaW9ucyDigJMgcG9pbnRpbmcgdG8g dGhlbSBpcyBmaW5lIC0tLCBJ4oCZbSBhc2tpbmcgeW91IHRvIGRlZmluZSB0aGUgZnVuY3Rpb25h bGl0eSBpbiBnZW5lcmFsIGFuZCBub3QgYXMgYSBmdW5jdGlvbiBvZiB0aGUgZXh0ZW5zaW9ucy4m bmJzcDsgRm9yIGFuIGV4YW1wbGUsIHNlZSBwb2ludCBNNS4xLiBiZWxvdy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB3aWxsIHdhaXQgZm9yIGF0IGxlYXN0IHRoZSBNYWpvciBjb21tZW50cyB0 byBiZSBhZGRyZXNzZWQgYmVmb3JlIHN0YXJ0aW5nIHRoZSBJRVRGIExhc3QgQ2FsbC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHZhcm8u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N YWpvcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTEuIFRoZSBJbnRyb2R1Y3Rpb24gbWVudGlv bnMgc2V2ZXJhbCB0eXBlcyBvZiBzZWdtZW50cywgYW5kIGl0IHNheXMgdGhhdCB0aGUgTERQIExT UCwgUlNWUC1URSBMU1AsIGFuZCBCR1AgTFNQIHNlZ21lbnRzIGFyZSDigJxpbGx1c3RyYXRlZCBp biBbSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzXeKAnS4mbmJzcDsgQnV0IHRo YXQgaXMgb25seSB0cnVlIGZvciB0aGUgZmlyc3QgdHdvLCBmb3Igd2hpY2ggZXhhbXBsZXMNCiBh cmUgc2hvd24uJm5ic3A7IFdoZXJlIGFyZSB0aGVzZSBzZWdtZW50IHR5cGVzIGRlZmluZWQ/Jm5i c3A7IFRoZSBkZWZpbml0aW9uLCBhbmQgbm90IHRoZSBleGFtcGxlcywgaXMgdGhlIE1ham9yIGlz c3VlIGhlcmUuJm5ic3A7IFRoaXMgZG9jdW1lbnQgYmVpbmcgdGhlIG1haW4gYXJjaGl0ZWN0dXJl IGRvY3VtZW50IHNob3VsZCBpbmNsdWRlIHRoZSBjb21wbGV0ZSBkZXNjcmlwdGlvbi4mbmJzcDsg QlRXLCB0aGUgbGlzdCBpcyBvbmx5IGFib3V0IHRoZSDigJxNUExTIGluc3RhbnRpYXRpb27igJ0s DQogYXJlIHRoZXJlIHNpbWlsYXIgdHlwZXMgb2Ygc2VnbWVudHMgZm9yIElQPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk0yLiBGcm9tIFNlY3Rpb24gMi4gKFRlcm1pbm9sb2d5KTog4oCcVXNpbmcgdGhlIHNhbWUgU1JH QiBvbiBhbGwgbm9kZXMgd2l0aGluIHRoZSBTUiBkb21haW4gZWFzZSBvcGVyYXRpb25zIGFuZCB0 cm91Ymxlc2hvb3RpbmcgYW5kIGlzIGV4cGVjdGVkIHRvIGJlIGEgZGVwbG95bWVudCBndWlkZWxp bmUu4oCdJm5ic3A7IEl0IGlzIOKAnGV4cGVjdGVkIHRvIGJlIGEgZGVwbG95bWVudCBndWlkZWxp bmXigJ0gd2hlcmUvd2hlbj8/Jm5ic3A7IEdpdmVuDQogdGhhdCB0aGlzIGRvY3VtZW50IGlzIHRo ZSBnZW5lcmFsIGFyY2hpdGVjdHVyZSwgSSBmaWd1cmVkIHRoYXQgbWF5YmUgZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMgY29udGFpbmVkIHRoYXQgZGVwbG95bWVudCByZWNv bW1lbmRhdGlvbiwgYnV0IGFsbCB0aGF0IGRvY3VtZW50IHNheXMgaXM6IOKAnEFzIGRlc2NyaWJl ZCBpbiBbSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ10sIHVzaW5nIHRoZSBzYW1lIFNS R0Igb24NCiBhbGwgbm9kZXMgd2l0aGluIHRoZSBTUiBkb21haW4gZWFzZXMgb3BlcmF0aW9ucyBh bmQgdHJvdWJsZXNob290aW5nIGFuZCBpcyBleHBlY3RlZCB0byBiZSBhIGRlcGxveW1lbnQgZ3Vp ZGVsaW5lLuKAnSZuYnNwOyBTb+KApndoZXJlIGFyZSB0aGUgRGVwbG95bWVudC9PcGVyYXRpb25h bCBjb25zaWRlcmF0aW9ucyByZWxhdGVkIHRvIHRoZSBTUkdCPyZuYnNwOyBJIG5vdGUgdGhhdCBu ZWl0aGVyIGRvY3VtZW50IChkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmcNCiBvciBk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscykgaW5jbHVkZSB0aGVtLiAmbmJz cDtJIHdvdWxkIGV4cGVjdCBzb21lIGluZm9ybWF0aW9uIHRvIGJlIGluIHRoaXMgKGdlbmVyYWwp IGRvY3VtZW50IGFuZCBvdGhlciBtb3JlIHNwZWNpZmljIGluZm9ybWF0aW9uIChsaWtlIHRoZSBj b25zaWRlcmF0aW9ucyBhYm91dCB1c2luZyB0aGUgc2FtZSBTUkdCKSB0byBiZSBpbiB0aGUgbW9y ZSBzcGVjaWZpYyBkb2N1bWVudCAoZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1w bHMsDQogaW4gdGhpcyBjYXNlKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTIuMS4mbmJzcDsg VGhlIGV4YW1wbGUgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDIgd291bGQgYmUgYSBncmVhdCBwbGFj ZSB0byBkZW1vbnN0cmF0ZSB0aGUgdmFsdWUgb2YgaGF2aW5nIHRoZSBzYW1lIFNSR0IuJm5ic3A7 IEluIGZhY3QsIHRoZSB0ZXh0IG5vdyBzaG93cyB0aGluZ3Mgbm90IHdvcmtpbmcgYW5kIGl0IGV2 ZW4gd2FybnMgYnkgc2F5aW5nIHRoYXQg4oCcdXNpbmcgYW55Y2FzdCBzZWdtZW50IHdpdGhvdXQg Y29uZmlndXJpbmcNCiB0aGUgc2FtZSBTUkdCIG9uIG5vZGVzIGJlbG9uZ2luZyB0byB0aGUgc2Ft ZSBkZXZpY2UgZ3JvdXAgbWF5IGxlYWQgdG8gbWlzcm91dGluZ+KAnSwgYnV0IG5vIGV4cGxhbmF0 aW9uIG9mIGhvdyBpdCBzaG91bGQgYmUgZG9uZSB0aGUgcmlnaHQgd2F5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk0z LiBGcm9tIFNlY3Rpb24gMi4gKFRlcm1pbm9sb2d5KTog4oCc4oCmYSBnbG9iYWwgc2VnbWVudCBp cyByZXByZXNlbnRlZCBieSBhIGdsb2JhbGx5LXVuaXF1ZSBpbmRleC7igJ0mbmJzcDsNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5NMy4xLiZuYnNwOyBJIGNvdWxkbuKAmXQgZmluZCBhbnl3aGVy ZSBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIHVzZSBvZiB0aGUgaW5kZXguJm5ic3A7IFdoZW4gaXQg aXMgZGlzY3Vzc2VkIGluIDMuMS4yLCBpdCBzZWVtcyB0byBiZSBhbiB1bmRlcnN0b29kIGNvbmNl cHQ6IOKAnEEgUHJlZml4LVNJRCBpcyBhbGxvY2F0ZWQgaW4gdGhlIGZvcm0gb2YgYW4gaW5kZXgg aW4gdGhlIFNSR0LigKbigJ0mbmJzcDsgRXZlbiBpZiBzdHJhaWdodGZvcndhcmQsIEkNCiB0aGlu ayB0aGUgY29uY2VwdCBvZiB0aGUgaW5kZXggc2hvdWxkIGJlIGV4cGxhaW5lZCAobWF5YmUgd2l0 aCBhbiBleGFtcGxlKSBhbmQgbm90IGFzc3VtZWQuJm5ic3A7IEkgYWdhaW4gd2VudCB0byBsb29r IGF0IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLCBidXQgdGhhdCBkb2N1 bWVudCBqdXN0IHBvaW50cyBiYWNrIHRvIHRoaXMgb25lOiDigJxUaGUgbm90aW9uIG9mIGluZGV4 ZWQgZ2xvYmFsIHNlZ21lbnQsIGRlZmluZWQgaW4gW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmdd4oCm4oCdDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTMuMi4gSSBhc3N1bWUgdGhh dCDigJxnbG9iYWxseS11bmlxdWUgaW5kZXjigJ0gaXMgcmVhbGx5IHVuaXF1ZSB0byB0aGUgU1Ig RG9tYWluLCByaWdodD8mbmJzcDsgSSBhc2sgdGhpcyBxdWVzdGlvbiBiZWNhdXNlIOKAnGdsb2Jh bGx5LXVuaXF1ZSBJUHY2IGFkZHJlc3PigJ0gaGFzIGEgZGlmZmVyZW50IGNvbm5vdGF0aW9uIChh cyBpbiB1bmlxdWUgd29ybGQtd2lkZSwgbm90IGp1c3QgaW5zaWRlIGEgZG9tYWluKS4mbmJzcDsg UGxlYXNlIGNsYXJpZnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk0zLjMuJm5ic3A7IE5vdGUg dGhhdCB0aGUgbGF0ZXN0IHZlcnNpb24gKC0xMCkgb2YgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLW1wbHMgaW50cm9kdWNlZCB0aGUgU1IgTG9jYWwgQmxvY2sgKFNSTEIpIHdoaWNo IGlzIG5vdCBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuJm5ic3A7IEkgbWVudGlvbiBpdCBoZXJl IGJlY2F1c2UgaXQgd2FzIGludHJvZHVjZWQgcmlnaHQgYWZ0ZXIgdGhlIHBvaW50ZXIgYWJvdXQg dGhlDQogaW5kZXjigKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NNC4gU2VjdGlvbiAzLjEuMS4gKFByZWZpeC1TSUQg QWxnb3JpdGhtKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NNC4xLiBUaGlzIHNlY3Rpb24gc3Rh cnRzIGJ5IGp1c3RpZnlpbmcgdGhlIHVzZSBvZiBhbiBhbGdvcml0aG0gYmFzZWQgb24gdGhlIElH UCBwcm90b2NvbCBleHRlbnNpb25zOiB0aGUgZXh0ZW5zaW9ucyBoYXZlIGFuIGFsZ29yaXRobSBm aWVsZCwgc28gd2Ugc2hvdWxkIHVzZSBpdC4mbmJzcDsgVGhlIGp1c3RpZmljYXRpb24gc2hvdWxk IGJlIHRoZSBvdGhlciB3YXkgYXJvdW5kOiB0aGlzIGRvY3VtZW50ICh0aGUgYXJjaGl0ZWN0dXJl KQ0KIGRlZmluZXMgdGhlIGNvbmNlcHQgb2YgYW4gYWxnb3JpdGhtIGFuZCB0aGUgZXh0ZW5zaW9u cyBpbXBsZW1lbnQgaXQuJm5ic3A7IFBsZWFzZSByZS13b3JkIHRoZSBmaXJzdCAzIHBhcmFncmFw aHMg4oCTIG5vdGUgdGhhdCB0aGUgaW5zdGFuY2UvdG9wb2xvZ3kgcmVmZXJlbmNlcyBzZWVtIHN1 cGVyZmx1b3VzIHRvIG1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NNC4yLiBUaGUgYWxnb3Jp dGhtcyBhcmUgbm90IHJlYWxseSBkZWZpbmVkIOKAkyB0aGVyZSBhcmUgbWVudGlvbnMgb2YgYSDi gJx3ZWxsIGtub3duIEVDTVAtYXdhcmUgU1BGIGFsZ29yaXRobeKAnSwgYnV0IG5vIHNwZWNpZmlj IHJlZmVyZW5jZSB0byB3aGF0IHRoYXQgaXMuJm5ic3A7IFRoZSBsYXN0IHNlbnRlbmNlIGluIHRo ZSBTZWN0aW9uIG1lbnRpb25zIHRoYXQgdGhlIOKAnGRldGFpbHMgb2YgdGhlIHR3byBkZWZpbmVk IGFsZ29yaXRobXMNCiBhcmUgZGVmaW5lZCBpbuKApuKAnSBwb2ludGluZyB0byB0aGUgZXh0ZW5z aW9uIGRyYWZ0cyDigJMgYnV0IHRob3NlIGRyYWZ0cyBqdXN0IG9mZmVyIGFuIGFkZGl0aW9uYWwg cGllY2Ugb2YgaW5mb3JtYXRpb24gaW4gKGZyb20gdGhlIE9TUEYgZG9jdW1lbnQpOiDigJx0aGUg c3RhbmRhcmQgc2hvcnRlc3QgcGF0aCBhbGdvcml0aG0gYXMgY29tcHV0ZWQgYnkgdGhlIE9TUEYg cHJvdG9jb2zigJ0uJm5ic3A7IElkZWFsbHkgdGhlIGFsZ29yaXRobXMgd291bGQgYmUgZGVmaW5l ZA0KIGhlcmUgKGV2ZW4gaWYgaXQgaXMganVzdCB0byBzYXk6IOKAnHRoZSBzdGFuZGFyZCBhbGdv cml0aG0gdXNlZCBpbiB0aGUgY29ycmVzcG9uZGluZyBJR1DigJ0pLCBhbmQgdGhlIGV4dGVuc2lv bnMgd291bGQganVzdCByZWZlcmVuY2UgaXQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTQu My4mbmJzcDsgV2hlbiBzaG91bGQgdGhlIHBhY2tldHMgYmUgZHJvcHBlZD8/Jm5ic3A7IFRoZSBm b2xsb3dpbmcgdGV4dCBwb2ludHMgdG8gYXQgbGVhc3QgMyBkaWZmZXJlbnQgcGxhY2VzIHdoZXJl IGl0IHNob3VsZCBiZSBkcm9wcGVkLCBvbmUgbWFya2VkIHdpdGggYSBNVVNULiZuYnNwOyBQbGVh c2UgY2xhcmlmeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTQuMy4xLiDigJxBIHJvdXRlciBN VVNUIGRyb3AgYW55IFNSIHRyYWZmaWMgYXNzb2NpYXRlZCB3aXRoIHRoZSBTUiBhbGdvcml0aG0g dG8gdGhlIGFkamFjZW50IHJvdXRlciwgaWYgdGhlIGFkamFjZW50IHJvdXRlciBoYXMgbm90IGFk dmVydGlzZWQgc3VwcG9ydCBmb3Igc3VjaCBTUiBhbGdvcml0aG0u4oCdJm5ic3A7IE9rLCB0aGlz IHNvdW5kcyBhcyBpZiB0aGUgdHJhZmZpYyBpcyBkcm9wcGVkIG9uZSBob3AgYmVmb3JlIHRoZQ0K IHJvdXRlciBub3Qgc3VwcG9ydGluZyB0aGUgYWxnb3JpdGhtIOKAkyBhbmQgaXQgaGFzIGEgTVVT VCBpbiBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTQuMy4yLiDigJxUaGUgaW5ncmVzcyBu b2RlIG9mIGFuIFNSIGRvbWFpbiB2YWxpZGF0ZXMgdGhhdCB0aGUgcGF0aCB0byBhIHByZWZpeOKA pmluY2x1ZGVzIG5vZGVzIGFsbCBzdXBwb3J0aW5nIHRoZSBhZHZlcnRpc2VkIGFsZ29yaXRobS4m bmJzcDsgQXMgYSBjb25zZXF1ZW5jZSwgaWYgYSBub2RlIG9uIHRoZSBwYXRoIGRvZXMgbm90IHN1 cHBvcnQgYWxnb3JpdGhtIFgsIHRoZSBJR1AtUHJlZml4IHNlZ21lbnQgd2lsbCBiZQ0KIGludGVy cnVwdGVkIGFuZCB3aWxsIGRyb3AgcGFja2V0IG9uIHRoYXQgbm9kZS7igJ0mbmJzcDsgVGhpcyBz b3VuZHMgbGlrZSB0aGUgdHJhZmZpYyB3b3VsZCBiZSBkcm9wcGVkIG9uIHRoZSBub2RlIG5vdCBz dXBwb3J0aW5nIHRoZSBhbGdvcml0aG0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk00LjMuMy4g 4oCcSXQncyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIGluZ3Jlc3Mgbm9kZSB1c2luZyBhIHNl Z21lbnQgdG8gY2hlY2sgdGhhdCBhbGwgZG93bnN0cmVhbSBub2RlcyBzdXBwb3J0IHRoZSBhbGdv cml0aG0gb2YgdGhlIHNlZ21lbnQu4oCdJm5ic3A7IFRoaXMgbGFzdCBzZW50ZW5jZSBoaW50cyBh dCB0aGUgZmFjdCB0aGF0IHRoZSBpbmdyZXNzIG5vZGUgc2hvdWxkIG1heWJlIGV2ZW4gc3RvcCB0 aGUgdHJhZmZpYw0KIHRoZXJlLCBvciBtYXliZSBub3Qgc2VuZGluZyBpdCB1bmxlc3MgYWxsIG5v ZGVzIGluIHRoZSBwYXRoIHN1cHBvcnQgdGhlIHNhbWUgYWxnb3JpdGht4oCmPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TTUuIFNlY3Rpb24gMy4xLjIuIChNUExTIERhdGFwbGFuZSkuJm5ic3A7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NNS4xLiBUaGUgZmlyc3QgYnVsbGV0IChhZ2FpbiEpIGV4cGxhaW5zIHRoZSBh cmNoaXRlY3R1cmUgaW4gZnVuY3Rpb24gb2YgdGhlIGV4dGVuc2lvbnMuJm5ic3A7IFRoZSBhcmNo aXRlY3R1cmUgc2hvdWxkIGV4cGxhaW4gd2hhdCBuZWVkcyB0byBiZSBkb25lIGFuZCB0aGUgZXh0 ZW5zaW9ucyB3b3VsZCB0aGVuIGRvIGl04oCmJm5ic3A7IFN1Z2dlc3Rpb246PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk5FVyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBJbiBvcmRlciB0byBhY2hpZXZlIGEgYmVoYXZpb3IgZXF1aXZhbGVudCB0 byBQZW51bHRpbWF0ZSBIb3AgUG9wcGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IGluIE1QTFMgW1JlZmVyZW5jZV0sIGEgTm9kZSBOIGFkdmVydGlz aW5nIGEgUHJlZml4LVNJRCBTSUQtUiBmb3IgaXRzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO2F0dGFjaGVkIHByZWZpeCBSIE1VU1QgYmUg YWJsZSB0byBpbnN0cnVjdCBpdHMgY29ubmVjdGVkIG5laWdoYm9ycyB0bw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtwZXJmb3JtIHRoZSBO RVhUIG9wZXJhdGlvbiB3aGlsZSBwcm9jZXNzaW5nIFNJRC1SLiZuYnNwOyBVcG9uIHJlY2Vpdmlu Zw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDt0aGlzIGluc3RydWN0aW9uIGZyb20gTm9kZSBOLCBpdHMgbmVpZ2hib3JzIG9mIE4gTVVTVCBw ZXJmb3JtIHRoZSBORVhUPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsgb3BlcmF0aW9uIHdoaWxlIHByb2Nlc3NpbmcgU0lELVIuJm5ic3A7IEFsdGVybmF0 aXZlbHksIHRoZSBuZWlnaGJvcnMgb2YgTg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtNVVNUIHBlcmZvcm0gdGhlIENPTlRJTlVFIG9wZXJh dGlvbiB3aGlsZSBwcm9jZXNzaW5nIFNJRC1SLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NNS4x LjEuIFRoZSBwZW51bHRpbWF0ZSBidWxsZXQgcmVmZXJzIGFnYWluIHRvIHRoZSBleHRlbnNpb25z IChidXQgaXQgb25seSBtZW50aW9ucyB0aGUgUC1iaXQgdGhpcyB0aW1lKS4mbmJzcDsgUGxlYXNl IGV4cGxhaW4gd2hhdCB0aGUgYXJjaGl0ZWN0dXJlIGludGVuZHMgdG8gZG8sIGJ1dCBub3QgZnJv bSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgZXh0ZW5zaW9ucy4mbmJzcDsgVGhpcyBhbmQgdGhl IGxhc3QgYnVsbGV0IHNlZW0NCiB0byBiZSB0aGUgcmVzdWx0IG9mIHRoZSBmaXJzdCBvbmUgKGFi b3ZlKS4mbmJzcDsgSSB0aGluayB0aGF0IHRoZSBmaXJzdCBidWxsZXQgd291bGQgaGF2ZSBlbm91 Z2ggdGV4dCBmb3IgdGhlIEZJQiBlbnRyaWVzIHRvIGJlIG9idmlvdXMsIGJ1dCBpZiB5b3Ugd2Fu dCB0byBpbmNsdWRlIHRoaXMgY29yb2xsYXJ5LCBwbGVhc2UgZG8gaXQgcmlnaHQgYWZ0ZXIuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk01LjIuIOKAnEEgUHJlZml4LVNJRCBpcyBhbGxvY2F0ZWQg aW4gdGhlIGZvcm0gb2YgYW4gaW5kZXggaW4gdGhlIFNSR0IgKG9yIGFzIGEgbG9jYWwgTVBMUyBs YWJlbCkgYWNjb3JkaW5nIHRvIGEgcHJvY2VzcyBzaW1pbGFyIHRvIElQIGFkZHJlc3MgYWxsb2Nh dGlvbi7igJ0mbmJzcDsgVGhlIFNSR0IgaXMgZGVmaW5lZCAoaW4gdGhlIFRlcm1pbm9sb2d5IHNl Y3Rpb24pIGFzIOKAnHRoZSBzZXQgb2YgbG9jYWwgbGFiZWxzIHJlc2VydmVkDQogZm9yIGdsb2Jh bCBzZWdtZW50c+KAnSwgd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIOKAnGFuIGluZGV4 IGluIHRoZSBTUkdC4oCdIGFuZCDigJxhIGxvY2FsIE1QTFMgbGFiZWzigJ0/Jm5ic3A7IEnigJlt IGhvcGluZyB0aGF0IHRoZSBleHBsYW5hdGlvbiBvZiB0aGUgY29uY2VwdCBvZiBpbmRleCB3b3Vs ZCBjbGFyaWZ5IHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk01LjIuMS4gVGhyZWUgYnVs bGV0cyBkb3du4oCmIOKAnElmIGEgbm9kZSBsZWFybnMgYSBQcmVmaXgtU0lEIGhhdmluZyBhIHZh bHVlIHRoYXQgZmFsbHMgb3V0c2lkZSB0aGUgbG9jYWxseSBjb25maWd1cmVkIFNSR0IgcmFuZ2Us IHRoZW4gdGhlIG5vZGUgTVVTVCBOT1QgdXNlIHRoZSBQcmVmaXgtU0lE4oCm4oCdJm5ic3A7IEdv aW5nIGJhY2sgdG8gbXkgcHJldmlvdXMgcXVlc3Rpb246IGl0IGxvb2tzIGxpa2Ug4oCcYSBsb2Nh bCBNUExTDQogbGFiZWzigJ0gd291bGQgaGF2ZSB0byBiZSBpbmNsdWRlZCBpbiB0aGUgU1JHQiDi gJMgYWdhaW4sIGNsYXJpZnlpbmcgdXBmcm9udCB3b3VsZCBoZWxwIGEgbG90LiZuYnNwOyBOb3Rl IHRoYXQgdGhpcyBwaWVjZSBvZiB0ZXh0IGZhbGxzIGludG8gdGhlIHJlY29tbWVuZGF0aW9uIG9m IGhhdmluZyB0aGUgc2FtZSBTUkdCIGNvbmZpZ3VyZWQgaW4gYWxsIG5vZGVzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NNS4yLjIuJm5ic3A7IFJlbGF0ZWQgdG8gdGhlIGNvbmNlcHQgb2YgaW5k ZXggYW5kIGl0cyByZWxhdGlvbnNoaXAgdG8gdGhlIFNSR0LigKZ0aGUgbmV4dCBidWxsZXQgc2F5 czog4oCc4oCmdGhlIHNlZ21lbnQgaXMgZ2xvYmFsICh0aGUgU0lEIGlzIGFsbG9jYXRlZCBmcm9t IHRoZSBTUkdCIG9yIGFzIGFuIGluZGV4KeKAnS4mbmJzcDsgV2Ugbm93IGhhdmUg4oCcZ2xvYmFs bHktdW5pcXVlIGluZGV44oCdLCDigJxhbiBpbmRleCBpbiB0aGUgU1JHQuKAnSwNCiBhbmQg4oCc dGhlIFNSR0Igb3IgYXMgYW4gaW5kZXjigJ0gKHNlcGFyYXRlbHkpLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk02LiBT ZWN0aW9uIDMuMy4gKElHUC1BbnljYXN0IFNlZ21lbnQsIEFueWNhc3QgU0lEKTog4oCc4oCmdGhl IHZhbHVlIG9mIHRoZSBTSUQgZm9sbG93aW5nIHRoZSBhbnljYXN0IFNJRCBNVVNUIGJlIHVuZGVy c3Rvb2QgYnkgYWxsIG5vZGVzIGFkdmVydGlzaW5nIHRoZSBzYW1lIGFueWNhc3Qgc2VnbWVudC7i gJ0mbmJzcDsgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIGlzIHJlYWxseSBhIHN0YXRlbWVudCBv ZiBmYWN0OiBhbGwgbm9kZXMsDQogbm90IGp1c3Qgb25lcyBhZHZlcnRpc2luZyBhbiBhbnljYXN0 IHNlZ21lbnQgbXVzdCB1bmRlcnN0YW5kIHdoYXQgdG8gZG8gd2l0aCB0aGUgbmV4dCBTSUTigKYm bmJzcDsgSU9XLCBzL01VU1QvbXVzdCZuYnNwOyBJIHdvdWxkIGV2ZW4gdGFrZSB0aGlzIHNlbnRl bmNlIG91dCBiZWNhdXNlIGl0IGlzIHJlZHVuZGFudCBhbmQgb2J2aW91cy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N Ny4gU2VjdGlvbiAzLjQuIChJR1AtQWRqYWNlbmN5IFNlZ21lbnQsIEFkai1TSUQpIGFsc28gdHJp ZXMgdG8gZXhwbGFpbiBmdW5jdGlvbmFsaXR5IHN0YXJ0aW5nIGZyb20gdGhlIGV4dGVuc2lvbnMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk03LjEuIOKAnFRoZSBlbmNvZGluZ3Mgb2YgdGhlIEFk ai1TSUQgaW5jbHVkZSB0aGUgYSBzZXQgb2YgZmxhZ3MgYW1vbmcgd2hpY2ggdGhlcmUgaXMgdGhl IEItZmxhZy4mbmJzcDsgV2hlbiBzZXQsIHRoZSBBZGotU0lEIHJlZmVycyB0byBhbiBhZGphY2Vu Y3kgdGhhdCBpcyBlbGlnaWJsZSBmb3IgcHJvdGVjdGlvbiAoZS5nLjogdXNpbmcgSVBGUlIgb3Ig TVBMUy1GUlIpLuKAnSZuYnNwOyBJZiB0aGUgQWRqYWNlbmN5IFNlZ21lbnQgaXMNCiBvbmUgdGhh dCBpcyBsb2NhbGx5IHNpZ25pZmljYW50IHRvIHRoZSBub2RlIGFkdmVydGlzaW5nIGl0LCB3aGF0 IGlzIHRoZSBwdXJwb3NlIG9mIHNpZ25hbGluZyB0aGF0IGl0IGlzIGVsaWdpYmxlIGZvciBwcm90 ZWN0aW9uPyZuYnNwOyBXb3VsZG7igJl0IHRoYXQgYmUgYSBsb2NhbCBkZWNpc2lvbiBhcyB3ZWxs PyZuYnNwOyBNYXliZSBhbiBleGFtcGxlIG9mIGhvdyB0aGUgYXJjaGl0ZWN0dXJlIGlzIGV4cGVj dGVkIHRvIHdvcmsgd291bGQgaGVscC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTcuMi4g4oCc VGhlIGVuY29kaW5ncyBvZiB0aGUgQWRqLVNJRCBhbHNvIGluY2x1ZGUgdGhlIEwtZmxhZy4mbmJz cDsgV2hlbiBzZXQsIHRoZSBBZGotU0lEIGhhcyBsb2NhbCBzaWduaWZpY2FuY2UuJm5ic3A7IEJ5 IGRlZmF1bHQsIHRoZSBMLWZsYWcgaXMgc2V0LuKAnSZuYnNwOyBUaGUgZGVmaW5pdGlvbiBvZiBJ R1AtQWRqYWNlbmN5IFNlZ21lbnQgYWxyZWFkeSBzYXlzIHRoYXQgaXQgaXMg4oCcbG9jYWwgKHVu bGVzcyBleHBsaWNpdGx5IGFkdmVydGlzZWQNCiBvdGhlcndpc2Up4oCdLCB3aGljaCBtYWtlcyB0 aGlzIHN0YXRlbWVudCB1bm5lY2Vzc2FyeS4mbmJzcDsgSWYgeW91IHdhbnQgdG8ga2VlcCBpdCwg cGxlYXNlIGZpZ3VyZSBvdXQgYSB3YXkgdGhhdCBkb2VzbuKAmXQganVzdGlmeSBpdCBiYXNlZCBv biBhIGJpdCBpbiB0aGUgZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NOC4gU2VjdGlvbiAzLjUuIChC aW5kaW5nIFNlZ21lbnQpLiZuYnNwOyBBIGJpbmRpbmcgc2VnbWVudCBpcyBub3QgZGVzY3JpYmVk IGFueXdoZXJlIGluIHRoaXMgZG9jdW1lbnQg4oCTIHBsZWFzZSBkbyBzbyEmbmJzcDsgU2VjdGlv biAzLjUuMS4gKE1hcHBpbmcgU2VydmVyKSBtZW50aW9ucyBhIOKAnFJlbW90ZS1CaW5kaW5nIFNJ RCBTIGFkdmVydGlzZWQgYnkgdGhlIG1hcHBpbmcgc2VydmVy4oCdLCBhbmQgc2F5cyB0aGF0IG1v cmUg4oCcZGV0YWlscw0KIGFyZSBkZXNjcmliZWQgaW4gdGhlIFNSL0xEUCBpbnRlcndvcmtpbmcg cHJvY2VkdXJlcyAoW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3Bd 4oCdLCBidXQgdGhhdCBkcmFmdCBkb2VzbuKAmXQgbWVudGlvbiBhIEJpbmRpbmcgU2VnbWVudC4m bmJzcDsgU2VjdGlvbiA1LiAoSUdQIE1pcnJvcmluZyBDb250ZXh0IFNlZ21lbnQpIHNheXMgdGhh dCDigJx0aGUgYmluZGluZyBzZWdtZW50IFtpc10gZGVmaW5lZCBpbiBTUiBJR1AgcHJvdG9jb2wN CiBleHRlbnNpb25zICggW0ktRC5pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNd LCBbSS1ELmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10gYW5kIFtJLUQuaWV0 Zi1vc3BmLW9zcGZ2My1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10p4oCdOyBob3dldmVyLCB0 aG9zZSBkb2N1bWVudHMgZG9u4oCZdCBtZW50aW9uIGEgQmluZGluZyBTZWdtZW50LCB0aGV5IGp1 c3QgKGV4Y2VwdCBmb3IgdGhlIE9TUEZ2MiBkcmFmdCkgZGVmaW5lDQogVExWcy4mbmJzcDsgTm90 ZSB0aGF0IEktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMgcG9pbnRzIGJh Y2sgdG8gdGhpcyBkb2N1bWVudCB3aGVuIHJlZmVycmluZyB0byB0aGUgZGVmaW5pdGlvbiBvZiBh IEJpbmRpbmcgU0lELCBjb21wbGV0aW5nIGEgY2lyY3VsYXIgcmVmZXJlbmNlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NOC4xLiBCVFcsIFNlY3Rpb24gNS4gKElHUCBNaXJyb3JpbmcgQ29udGV4 dCBTZWdtZW50KSBzYXlzIHRoYXQgdGhlIOKAnE1pcnJvciBTSUQgaXMgYWR2ZXJ0aXNlZCB1c2lu ZyB0aGUgYmluZGluZyBzZWdtZW504oCdLCB3aGljaCB0aGVuIGxvb2tzIGxpa2UgdGhlIE1pcnJv ciBTZWdtZW50IGlzIGFuIGFwcGxpY2F0aW9uIG9mIHRoZSBCaW5kaW5nIFNlZ21lbnQgKCYjNDM7 IGFuIGV4cGxpY2l0IGluZGljYXRpb24gb2YgaXQpLiZuYnNwOw0KIEkgdGhpbmsgdGhhdCBTZWN0 aW9uIDUgc2hvdWxkIHRoZW4gYmUgbW92ZWQgdG8gYmUgYSBzdWItc2VjdGlvbiBvZiAzLjUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk04LjIuIFBhcnQgb2YgdGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIChpbiBTZWN0aW9uIDguMSkgYXJlIHJlbGF0ZWQgdG8gdGhlIEJpbmRpbmcgU0lELCB3 aGljaCBpcyBhbm90aGVyIHJlYXNvbiBmb3IgY2xlYXJseSBleHBsYWluaW5nIHRoYXQgcGFydCBv ZiB0aGUgYXJjaGl0ZWN0dXJlIGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTkuIFNlY3Rpb24gMy41LjEuIChN YXBwaW5nIFNlcnZlcikgbWVudGlvbnMgYSBNYXBwaW5nIFNlcnZlciwgYnV0IGl0IHB1bnRzIHRv IEktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3AgZm9yIGZ1cnRoZXIg ZGV0YWlscy4mbmJzcDsgV2hpbGUgdGhlIFNSTVMgY2FuIGJlIHVzZWQgZm9yIGludGVyb3BlcmFi aWxpdHkgY2FzZXMsIEkgdGhpbmsgdGhhdCBpdCBpcyBhbiBpbXBvcnRhbnQgcGFydA0KIG9mIHRo ZSBvdmVyYWxsIGFyY2hpdGVjdHVyZSBhbmQgYXMgc3VjaCBpdCBzaG91bGQgYmUgZGVzY3JpYmVk IGFuZCBkaXNjdXNzZWQgaW4gdGhpcyBkb2N1bWVudCBpbnN0ZWFk4oCmaW5jbHVkaW5nIGFueSBN YW5hZ2VhYmlsaXR5IENvbnNpZGVyYXRpb25zIChhcyBtZW50aW9uZWQgaW4gU2VjdGlvbiA5KS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NMTAuIFNlY3Rpb24gMy42LiAoSW50ZXItQXJlYSBDb25zaWRlcmF0aW9ucykg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk0xMC4xLiBUaGlzIHNlY3Rpb24gc2hvd3MgYW4gZXhh bXBsZSBvZiB0aGUgYmVoYXZpb3I6IG1haW50YWluIHRoZSBTSUQgYWNyb3NzIGFyZWEgYm91bmRh cmllcy4mbmJzcDsgQnV0IGl0IGRvZXNu4oCZdCBhY3R1YWxseSBzYXkgaG93IHRoZSBhcmNoaXRl Y3R1cmUgaXMgZXhwZWN0ZWQgdG8gd29yay4mbmJzcDsgSU9XLCBpbiB0aGUgZXhhbXBsZSB0aGUg U0lEIGlzIG1haW50YWluZWQsIGJ1dCBzaG91bGQgdGhhdCBhbHdheXMgaGFwcGVuDQogKE1VU1Qs IFNIT1VMRCk/IE9yIGlzIGl0IGp1c3QgYW4gZXhhbXBsZSAoTUFZKT88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TTEwLjIuIEFub3RoZXIgY2FzZSBvZiBleHBsYWluaW5nIHRoZSBhcmNoaXRlY3R1 cmUgYmFzZWQgb24gdGhlIGV4dGVuc2lvbiBmdW5jdGlvbmFsaXR5OiDigJxXaGVuIGFuIEFCUiBw cm9wYWdhdGVzIGEgcHJlZml4IGZyb20gb25lIGFyZWEgdG8gYW5vdGhlciBpdCBNVVNUIHNldCB0 aGUgUi1GbGFnLuKAnSZuYnNwOyBNYXliZSB0cnkgc29tZXRoaW5nIGxpa2UgdGhpcyBpbnN0ZWFk OiDigJxUaGUgcmUtYWR2ZXJ0aXNlbWVudCBvZg0KIGFuIFNJRCB0aGF0IG9yaWdpbmF0ZWQgb24g YSBkaWZmZXJlbnQgSUdQIGFyZWEgTVVTVCBiZSBpbmRpY2F0ZWQu4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk0xMC4zLiBbbWlub3JdIEFzIHRoZSBhZHZlcnRpc2VtZW50IG1vdmVzIHRvIHRo ZSBsZWZ0IChmcm9tIEFyZWEgMiB0byB0aGUgQmFja2JvbmXigKYpLCB0aGUgQUJScyBjaGFuZ2Ug dGhlIE5vZGUtU0lEIGZvciBhIFByZWZpeC1TSUQsIHJpZ2h0PyZuYnNwOyBUaGUgZGVzY3JpcHRp b24gaW4gdGhlIGxhc3QgMyBwYXJhZ3JhcGhzIHVzZXMgTm9kZS1TSUQ6IOKAnG5vZGUgU+KApnB1 c2hlcyBOb2RlLVNJRCgxNTAp4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NMTAuNC4gW21p bm9yXSBHb2luZyBiYWNrIHRvIGdsb2JhbCB2cyBsb2NhbCBzaWduaWZpY2FuY2UsIGl0IHdvdWxk IGJlIG5pY2UgdG8gcmVtaW5kIHRoZSByZWFkZXJzIGF0IHRoaXMgcG9pbnQgdGhhdCB0aGUgU1Ig ZG9tYWluIGlzIHJlYWxseSB0aGUgd2hvbGUgSUdQIG5ldHdvcmssIGFuZCBub3QganVzdCBvbmUg Zmxvb2RpbmcgZG9tYWlu4oCmd2hpY2ggaXMgd2h5IFNJRCAxNTAgY2FuIGJlIHVzZWQgdGhyb3Vn aG91dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NMTEuIFNlY3Rpb24gNC4gKEJHUCBQZWVyaW5nIFNlZ21lbnRzKSBp cyB0aGUgb25seSBub24tSUdQIGZvY3VzZWQgc2VjdGlvbiBpbiB0aGlzIGRvY3VtZW50LiZuYnNw OyBUaGUgYXJjaGl0ZWN0dXJlIG9mIHRoZSBFUEUgc29sdXRpb24gKGFzIGRlc2NyaWJlZCBpbiBk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUpIGdvZXMgYmV5b25k IHdoYXQgaGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQNCiBoZXJlIGJlY2F1c2UgaXQgaW5jb3Jw b3JhdGVzIGVsZW1lbnRzIHN1Y2ggYXMgYSBtYW5kYXRvcnkgY2VudHJhbGl6ZWQgY29udHJvbGxl ciwgd2hpY2ggd2FzIG9wdGlvbmFsIGJlZm9yZSAoYSBQQ0Ugc2VydmVyIGlzIG1lbnRpb25lZCBv bmx5IGNhc3VhbGx5IGluIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uKS4mbmJzcDsgVGhpcyBsZWF2 ZXMgdXMgd2l0aCBhbiBpbmNvbXBsZXRlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIEJHUCBjYXNlLiZu YnNwOyBJIHdvdWxkIHByZWZlcg0KIGl0IGlmIHRoZSB3aG9sZSBhcmNoaXRlY3R1cmUgd2FzIGRl ZmluZWQgaW4gdGhpcyBzaW5nbGUgZG9jdW1lbnQgKGkuZS4gZXhwYW5kIHRoaXMgc2VjdGlvbiBi eSBwb3RlbnRpYWxseSBtb3ZpbmcgcGFydHMgZnJvbSBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctY2VudHJhbC1lcGUg4oCTIHdoaWNoIG1pZ2h0IGxlYXZlIHRoYXQgZG9jdW1lbnQg d2l0aG91dCBlbm91Z2ggY29udGVudCB0byBzdGFuZCBhbG9uZSkuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTEyLiBT ZWN0aW9uIDguIChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykuJm5ic3A7IFRoZSBtYWluIHBhcnQg b2YgdGhpcyBzZWN0aW9uIHRhbGtzIGFib3V0IHRoZSBpbnN0cnVjdGlvbnMgb24gdGhlIHBhY2tl dHMg4oCTIGlzIGFkZGluZyB0aGF0IG1ldGEtZGF0YSBhIHNlY3VyaXR5IGNvbmNlcm4/Jm5ic3A7 IEkgdGhpbmsgaXQgY291bGQgYmUgYmVjYXVzZSBzb21lb25lIHdhdGNoaW5nIGNvdWxkIHRlbGwg d2hpY2gg4oCcZm9yd2FyZGluZw0KIHBhdGggZWxlbWVudHMgKGUuZy46IG5vZGVzLCBsaW5rcywg c2VydmljZXMsIGV0Yy4p4oCdIGFyZSB1c2VkIGZvciBzcGVjaWZpYyBmbG93cywgZXRjLiZuYnNw OyZuYnNwOyBCdXQgSSBhbHNvIHRoaW5rIHRoYXQgdGhlIHJpc2sgaXMgbWl0aWdhdGVkIGJ5IHRo ZSBmYWN0IHRoYXQgdGhlIGluZm9ybWF0aW9uIE1VU1QgTk9UIGJlIGV4cG9zZWQgb3V0c2lkZSB0 aGUgU1IgZG9tYWluLiZuYnNwOyBNZW50aW9uaW5nIHRoYXQsIGFuZCB0aGUgZmFjdCB0aGF0IHRo ZSBTUiBkb21haW4NCiB3aWxsIHVzdWFsbHkgYmUgdW5kZXIgYSBzaW5nbGUgYWRtaW5pc3RyYXRp b24gd291bGQgYmUgYSBnb29kIHRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk0xMy4gU2VjdGlvbiA5LiAoTWFu YWdlYWJpbGl0eSBDb25zaWRlcmF0aW9ucykgc2F5cyB0aGF0IOKAnGFuIGltcGxlbWVudGF0aW9u IFNIT1VMRCBwcm90ZWN0IHRoZSBuZXR3b3JrIGluIGNhc2Ugb2YgY29uZmxpY3QgZGV0ZWN0aW9u IGJ5IHByb3ZpZGluZyBhIGRldGVybWluaXN0aWMgcmVzb2x1dGlvbiBhcHByb2FjaOKApmFkZHJl c3NlZCBpbiBbSS1ELmlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb25dLuKAnSZuYnNwOw0K IFRoYXQg4oCcU0hPVUxE4oCdIGlzIGluIGNvbmZsaWN0IHdpdGggSS1ELmlldGYtc3ByaW5nLWNv bmZsaWN0LXJlc29sdXRpb24gKGluIFdHTEMpIHdoZXJlIGl0IHNheXMgdGhhdCDigJxBbGwgcHJv dG9jb2xzIHdoaWNoIHN1cHBvcnQgU1IgTVVTVCBhZGhlcmUgdG8gdGhlIHBvbGljaWVzIGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudC7igJ0mbmJzcDsgSXQgc2VlbXMgbGlrZSB0aGUgZWFzeSB3YXkg Zm9yd2FyZCBpcyB0byBzL1NIT1VMRC9NVVNULiZuYnNwOyBJbiBlaXRoZXIgY2FzZSwNCiBJIHRo aW5rIHRoYXQgSS1ELmlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gc2hvdWxkIGJlIGEg Tm9ybWF0aXZlIHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1pbm9yOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QMS4gSW50 cm9kdWN0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlAxLjEuIFRoZSB0ZXJtIOKAnHNlcnZp Y2UgY2hhaW7igJ0gaXMgdXNlZCBpbiB0aGUgQWJzdHJhY3QgYW5kIGluIHRoZSBJbnRyb2R1Y3Rp b24uJm5ic3A7IEdpdmVuIHRoYXQgdGhlIGNvbmNlcHQgaXMgbm90IHZpdGFsIHRvIHRoZSBhcmNo aXRlY3R1cmUgYW5kIHRoYXQgdGhlcmUgbWlnaHQgYmUgdW5uZWNlc3NhcnkgY29uZnVzaW9uIHdp dGggU0ZDLCBJIHdvdWxkIHN1Z2dlc3QgdGFraW5nIGl0IG91dC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UDEuMi4mbmJzcDsgUmVsYXRlZOKApiZuYnNwOyBTZWN0aW9uIDEuMSBzYXlzIHRoYXQg dGhpcyBkb2N1bWVudCDigJxkZWZpbmVz4oCmdGhlIHNlcnZpY2Ugc2VnbWVudHPigJ0sIGJ1dCB0 aGVyZeKAmXMgbm8gc3BlY2lmaWMgbWVudGlvbiBvZiDigJxzZXJ2aWNlIHNlZ21lbnRz4oCdIGFu eXdoZXJlLCBleGNlcHQgZm9yIGEgdmVyeSBxdWljayBtZW50aW9uIGluIFNlY3Rpb24gNS4gKElH UCBNaXJyb3JpbmcgQ29udGV4dCBTZWdtZW50KS4mbmJzcDsgV2hhdCBhbQ0KIEkgbWlzc2luZz8m bmJzcDsgQ29uc2lkZXIgdGFraW5nIOKAnHNlcnZpY2Ugc2VnbWVudHPigJ0gb2ZmIHRoZSBsaXN0 IG9mIHRoaW5ncyB0aGlzIGRvY3VtZW50IGRlZmluZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlAxLjMuIFRoZSBsYXN0IHBhcmFncmFwaCBzYXlzIHRoYXQg4oCcVGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgc2V0IG9mIGluc3RydWN0aW9ucyAoY2FsbGVkIHNlZ21lbnRzKSB0aGF0IGFyZSByZXF1 aXJlZCB0byBmdWxmaWxsIHRoZSBkZXNjcmliZWQgdXNlLWNhc2VzLuKAnSZuYnNwOyBUaGUgdXNl IGNhc2VzIGFyZSBub3QgbWVudGlvbmVkIHVudGlsIDEuMS4mbmJzcDsgU3VnZ2VzdGlvbjogbWVy Z2UgU2VjdGlvbiAxIGFuZCAxLjEgdG8NCiBwcm92aWRlIHByb3BlciBmbG93IHRvIHRoZSB0ZXh0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QMS40LiBTcGVha2luZyBvZiB1c2UgY2FzZXMsIEkt RC5pZXRmLXNwcmluZy1vYW0tdXNlY2FzZSBkb2VzbuKAmXQgYWN0dWFsbHkgaW5jbHVkZSB1c2Ug Y2FzZXMgdGhhdCB3aWxsIGFmZmVjdCB0aGUgYXJjaGl0ZWN0dXJlLiZuYnNwOyBJdCBpbmNsdWRl cyB1c2UgY2FzZSBvZiBob3cgdG8gdXNlIG1vbml0b3Jpbmcgc3lzdGVtIGRlZmluZWQgaW4gaXQu Jm5ic3A7IFNhbWUgY29tbWVudCBmb3IgdGhlIG1lbnRpb24gaW4gU2VjdGlvbg0KIDkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UDIuIEZyb20gU2VjdGlvbiAyLiAoVGVybWlub2xvZ3kpPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlAyLjEuIFNJRCBpcyBub3QgZGVmaW5lZCwganVzdCBleHRlbmRlZC4mbmJzcDsgQmVz aWRlcyB0aGUgZXhhbXBsZXMsIHBsZWFzZSBwcm92aWRlIGFuIGFjdHVhbCBkZWZpbml0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QMi4yLiDigJxUaGUgQ09OVElOVUUgaW5zdHJ1Y3Rpb24g aXMgaW1wbGVtZW50ZWQgYXMgdGhlIFNXQVAgaW5zdHJ1Y3Rpb24gaW4gdGhlIE1QTFMgZGF0YXBs YW5lLuKAnSZuYnNwOyBQbGVhc2UgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byB3aGVyZSB0aGUg4oCc U1dBUCBpbnN0cnVjdGlvbuKAnSBpcyBkZWZpbmVkLiZuYnNwOyBJIGFzc3VtZSB5b3XigJlyZSBy ZWFsbHkgcmVmZXJyaW5nIHRvIOKAnGxhYmVsIHN3YXBwaW5n4oCdIGluIHJmYzMwMzEsIGFyZQ0K IHlvdT8mbmJzcDsgSWYgc28sIHBsZWFzZSBiZSBjb25zaXN0ZW50IGFzIOKAnE1QTFMgZGF0YXBs YW5l4oCdIGFuZCDigJxNUExTIGFyY2hpdGVjdHVyZeKAnSBhcmUgdXNlZCBpbiBkaWZmZXJlbnQg cGxhY2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QMi4zLiBUaGUg4oCcTG9jYWwgU2VnbWVu dOKAnSBkZWZpbml0aW9uIHNheXMgdGhhdCBmb3IgSVB2NiBpdCDigJxpcyBub3QgYWR2ZXJ0aXNl ZCBpbiBhbnkgcm91dGluZyBwcm90b2NvbOKAnS4mbmJzcDsgQnV0IGZvciBNUExTIGl0IGlzIGFk dmVydGlzZWQsIHJpZ2h0PyZuYnNwOyBQbGVhc2UgY2xhcmlmeS4mbmJzcDsgSSB0aGluayB0aGF0 IHNvbWUgb2YgdGhlIHZvY2FidWxhcnkgaXMgYSBsaXR0bGUgY29uZnVzaW5nLCBmb3IgZXhhbXBs ZSwgdGhlDQogZGVmaW5pdGlvbiBvZiBJR1AtQWRqYWNlbmN5IFNlZ21lbnQgc2F5cyB0aGF0IGl0 IOKAnGlzIGxvY2FsICh1bmxlc3MgZXhwbGljaXRseSBhZHZlcnRpc2VkIG90aGVyd2lzZSkgdG8g dGhlIG5vZGUgdGhhdCBhZHZlcnRpc2VzIGl04oCdIOKAkyB0aGlzIG1lYW5zIHRoYXQgZm9yIElQ djYgdGhpcyBwaWVjZSBvZiB0aGUgYXJjaGl0ZWN0dXJlIHdvdWxkbuKAmXQgYXBwbHkgYmVjYXVz ZSBhIExvY2FsIFNlZ21lbnQgaXMgbm90IGFkdmVydGlzZWQuJm5ic3A7IFRvIGFkZA0KIHRvIHRo ZSBjb25mdXNpb24sIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1p bmcgdGFsa3MgYWJvdXQgbG9jYWwgU0lEc+KApiZuYnNwOyBJT1csIGluIHNvbWUgcGxhY2VzIGl0 IHNvdW5kcyBhcyBpZiB3aGF0IHNob3VsZCBiZSB0aGUgZ2VuZXJhbCBhcmNoaXRlY3R1cmUgb25s eSByZWFsbHkgYXBwbGllcyB0byBNUExTIOKAkyBvciBtYXliZSB3ZSBuZWVkIGEgbW9yZSBleHBs aWNpdCBsb2NhbCBxdWFsaWZpZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlAyLjQuIOKAnFRo ZSBQQ0VQIGRpc2NvdmVyeSBjYXBhYmlsaXR5IGlzIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtcGNl LXNlZ21lbnQtcm91dGluZ10u4oCdJm5ic3A7IFRoYXQgZG9jdW1lbnQgZG9lc27igJl0IGV2ZW4g bWVudGlvbiB0aGUgd29yZCDigJxkaXNjb3ZlcnnigJ0uJm5ic3A7IFBsZWFzZSB1c2UgdGhlIHBy b3BlciBuYW1lIGZvciBlYXNpZXIgY3Jvc3MtcmVmZXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5QMi41LiDigJx1bmxlc3MgZXhwbGljaXRseSBhZHZlcnRpc2VkIG90aGVyd2lzZeKAnSBp cyB1c2VkIHRvIHF1YWxpZnkgdGhlIGdsb2JhbC9sb2NhbCBuYXR1cmUgb2YgYSBzZWdtZW50LiZu YnNwOyBIb3cgZG8gdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgc2VnbWVudCBjaGFuZ2UgaWYg 4oCcZXhwbGljaXRseSBhZHZlcnRpc2VkIG90aGVyd2lzZeKAnT8mbmJzcDsgRm9yIGV4YW1wbGUs IGlmIGFuIElHUC1QcmVmaXggU2VnbWVudCBpcyBhZHZlcnRpc2VkDQogYXMgbG9jYWwsIGhvdyBk byBpdHMgY2hhcmFjdGVyaXN0aWNzIGNoYW5nZSwgb3IgZG8gdGhleT88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UDIuNS4xLiBJbiBTZWN0aW9uIDMuNC4gKElHUC1BZGphY2VuY3kgU2VnbWVudCwg QWRqLVNJRCksIHRoZSB1c2Ugb2YgYW4gQWRqLVNJRCBpcyBpbGx1c3RyYXRlZCBmb3IgYm90aCB0 aGUgbG9jYWwgYW5kIGdsb2JhbCBjYXNlcywgYnV0IGJvdGggZXhwbGFuYXRpb25zIHNheSB0aGUg c2FtZSB0aGluZzog4oCcZm9yd2FyZGVkIGFsb25nIHRoZSBzaG9ydGVzdC1wYXRoIHRvIE4gYW5k IHRoZW4gYmUgc3dpdGNoZWQgYnkNCiBOLCB3aXRob3V0IGFueSBJUCBzaG9ydGVzdC1wYXRoIGNv bnNpZGVyYXRpb24sIHRvd2FyZHMgbGluayBM4oCdIOKAkyBJIGRvbuKAmXQgc2VlIGEgZGlmZmVy ZW5jZSBpbiBiZWhhdmlvciBiZXR3ZWVuIHRoZSBsb2NhbCBhbmQgZ2xvYmFsIG5hdHVyZSBvZiB0 aGlzIFNJRC4mbmJzcDsgVGhlcmUgaXMgc29tZSBhZGRpdGlvbmFsIHRleHQgcmVsYXRlZCB0byBn bG9iYWw6IOKAnFRoZSB1c2Ugb2YgZ2xvYmFsIEFkai1TSUQgYWxsb3dzIHRvIHJlZHVjZSB0aGUg c2l6ZSBvZg0KIHRoZSBzZWdtZW50IGxpc3Qgd2hlbiBleHByZXNzaW5nIGEgcGF0aCBhdCB0aGUg Y29zdCBvZiBhZGRpdGlvbmFsIHN0YXRlIChpLmUuOiB0aGUgZ2xvYmFsIEFkai1TSUQgd2lsbCBi ZSBpbnNlcnRlZCBieSBhbGwgcm91dGVycyB3aXRoaW4gdGhlIGFyZWEgaW4gdGhlaXIgZm9yd2Fy ZGluZyB0YWJsZSku4oCdJm5ic3A7IElmIG5vZGUgTiBpcyB0aGUgb25lIGV4ZWN1dGluZyBvbiB0 aGUgQWRqLVNJRCwgaG93IGRvZXMgaW5jbHVkaW5nIGl0IGluIG90aGVyIEZJQnMNCiBoZWxwPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QMi42LiBOb25lIG9mIHRoZSBzZWdtZW50cyBhZnRlciBT ZWN0aW9uIDMuNCAoYmluZGluZywgQkdQLCBtaXJyb3JpbmcpIGFyZSBkZWZpbmVkIGluIHRoZSBU ZXJtaW5vbG9neS4mbmJzcDsgUGxlYXNlIGRvIHNvIGZvciBjb21wbGV0ZW5lc3MuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UDMuIFJlZmVycmluZyB0byBGaWd1cmUgMTog4oCc4oCmZWFjaCBQRSBkZXZpY2UgaXMgY29u bmVjdGVkIHRvIHR3byByb3V0ZXJzIGluIGVhY2ggb2YgdGhlIGdyb3VwcyBBIGFuZCBCLuKAnSZu YnNwOyBUaGUgcm91dGVycyBjb25uZWN0ZWQgdG8gdGhlIFBFcyAoUngpIGFyZSBub3QgaW4gZWl0 aGVyIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlA0LiBzL09idmlvdXNseS8vJm5ic3A7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlA1LiBTZWN0aW9uIDMuNC4gKElHUC1BZGphY2VuY3kgU2VnbWVudCwgQWRqLVNJRCk6IOKAnFRo ZSByZW1vdGUgbm9kZSBNQVkgYmUgYW4gYWRqYWNlbnQgSUdQIG5laWdoYm9yIG9yIGEgbm9uLWFk amFjZW50IG5laWdoYm9y4oCm4oCdJm5ic3A7IFRoZSDigJxNQVnigJ0gaXMgb3V0IG9mIHBsYWNl IGFzIHRoZXJlIGlzbuKAmXQgYW5vdGhlciBvcHRpb24sIGl0IGlzIG9uZSBvciB0aGUgb3RoZXIu Jm5ic3A7IHMvTUFZL21heTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlA2LiBNYXliZSBpdOKAmXMgYmVjYXVzZSB0aGUg cmVzdCBvZiAzLjUgaXMgaW5jb21wbGV0ZSwgYnV0IFNlY3Rpb24gMy41LjIuIChUdW5uZWwgSGVh ZC1lbmQpIGhhcyBubyBjb250ZXh0IHRvIHNwZWFrIG9mIOKAkyB3aXRob3V0IHRoYXQsIGl0IGZl ZWxzIGxpa2UgYW4gb3JwaGFuIHNlY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UDcuIFNlY3Rpb24gOC4xLiAo TVBMUyBEYXRhIFBsYW5lKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QNy4xLiBZb3UgaW5jbHVk ZWQgYSBjb3VwbGUgb2YgcmVmZXJlbmNlcyBhdCB0aGUgZW5kIG9mIHRoaXMgc2VjdGlvbiwgd2hp Y2ggaXMgZ29vZC4mbmJzcDsgSSB3b3VsZCBob3dldmVyIG5vdCBleHBsaWNpdGx5IG1lbnRpb24g c3BlY2lmaWMgc2VjdGlvbnMsIGFzIHRoZSB3aG9sZSBSRkNzIChyZmM0MzgxIGFuZCByZmM1OTIw KSBhcmUgYWJvdXQgTVBMUy1yZWxhdGVkIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QNy4yLiBZb3UgY29tcGFyZSB0aGUgdXNlIG9mIGEgc2luZ2xlIHNlZ21lbnQgdG8gUlNWUC1U RSDigJMgaWYgdGhlIHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcyBhcmUgc2ltaWxhciwgcGxlYXNl IHByb3ZpZGUgYSByZWZlcmVuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UDguIFJlZmVyZW5jZXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UDguMS4gUkZDMjQ2MCB3YXMgb2Jzb2xldGVkIGJ5IFJGQzgyMDAgLyBS RkM2ODIyIHdhcyBvYnNvbGV0ZWQgYnkgUkZDODIwMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q OC4yLiBJIHRoaW5rIHRoYXQgdGhlIHJlZmVyZW5jZSB0byBSRkM0MjA2IHNob3VsZCBiZSBJbmZv cm1hdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5pdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk4xLiBUaGUgQWJzdHJhY3QgaXMg dmVyeSBsb25nIOKAkyBJIHdvdWxkIGV2ZW4gc2F5IHRvbyBsb25nLiZuYnNwOyBJZiBpdCB3YXMg dXAgdG8gbWUsIEkgd291bGQgbGVhdmUganVzdCB0aGUgZmlyc3QgcGFyYWdyYXBoLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5OMi4gVGhlIHNlY29uZCB0byBsYXN0IHBhcmFncmFwaCBpbiB0aGUg SW50cm9kdWN0aW9uICjigJxOdW1lcm91cyB1c2UtY2FzZXPigKbigJ0pIHJlZmVyZW5jZXMgdGhl IOKAnG1hcmtldGluZyBzdHlsZeKAnSBjb250ZW50IG9mIEktRC5pZXRmLXNwcmluZy1vYW0tdXNl Y2FzZS4mbmJzcDsgSSBoYXZlIGFza2VkIHRoZSBhdXRob3JzIG9mIHRoYXQgZG9jdW1lbnQgdG8g cGxlYXNlIGZvY3VzIHRoZWlyIGNvbnRlbnQuJm5ic3A7IFBsZWFzZSBjb25zaWRlcg0KIHRha2lu ZyB0aGlzIHBhcmFncmFwaCBvdXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk4zLiBzL3BhcnRp Y2lwYXRpbmcgaW50byB0aGUgc291cmNlIGJhc2VkL3BhcnRpY2lwYXRpbmcgaW4gdGhlIHNvdXJj ZSBiYXNlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ONC4gUmVmZXJlbmNlcy4mbmJzcDsgUGxl YXNlIGFkZCBJbmZvcm1hdGl2ZSByZWZlcmVuY2VzIHRvIG5ldGNvbmYgKFNlY3Rpb24gMiksIFBD RVAgKDIpLCBGUlIgKDMuMS4xKSwg4oCccGFyYWxsZWwgYWRqYWNlbmN5IHN1cHByZXNzaW9u4oCd ICgzLjQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ONS4gU2VjdGlvbiAzOiDigJxJR1Agc2Vn bWVudHMgcmVxdWlyZSBleHRlbnNpb25zIGluIGxpbmstc3RhdGUgSUdQIHByb3RvY29scy4mbmJz cDsgSUdQIGV4dGVuc2lvbnMgYXJlIHJlcXVpcmVkIGluIG9yZGVyIHRvIGFkdmVydGlzZSB0aGUg SUdQIHNlZ21lbnRzLuKAnSZuYnNwOyBUaGVzZSAyIHNlbnRlbmNlcyBzYXkgdGhlIGV4YWN0IHNh bWUgdGhpbmcuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TjYuIFBsZWFzZSBhdm9p ZCB1c2luZyDigJx3ZeKAnSBpbiB0aGUgdGV4dCDigJMgZXhjZXB0IGZvciB0aGUgQWNrbm93bGVk Z2VtZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TjcuIHMvUmVnYXJkbGVzcyBTZWdtZW50 IFJvdXRpbmcvSW5kZXBlbmRlbnQgb2YgU2VnbWVudCBSb3V0aW5nPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk44LiBzL2FuZCBub3QgdG8gZWFjaCBvdGhlciBpbmRpdmlkdWFsIG5vZGVzIGluIHRo ZSBMQU4vYW5kIG5vdCB0byBpbmRpdmlkdWFsIG5vZGVzIGluIHRoZSBMQU48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+TjkuIHMvKFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1p bnRlcm9wXS9bSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcF08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TjEwLiDigJxJR1AgZGVwbG95ZWQgdXNpbmcgYXJlYXPigJ0m bmJzcDsgQW4gYXJlYSBpcyBhbiBPU1BGLXNwZWNpZmljIGNvbnN0cnVjdCDigJMgZmxvb2Rpbmcg ZG9tYWluIGlzIG1vcmUgZ2VuZXJpYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TjExLiBJdCB3 b3VsZCBiZSBuaWNlIGlmIHRoZSBleGFtcGxlcyB1c2VkIElQdjYgaW5zdGVhZCBvZiBJUHY0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2AC310C5A42B4D4DB223B52E9BF37DB0ciscocom_-- From nobody Fri Aug 11 11:47:19 2017 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 581EA132655 for ; Fri, 11 Aug 2017 11:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 fnpicW8SNLb1 for ; Fri, 11 Aug 2017 11:47:15 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497AC1293E1 for ; Fri, 11 Aug 2017 11:47:12 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7BIl9iQ025727 for ; Fri, 11 Aug 2017 19:47:09 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7BIl9uC025715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Aug 2017 19:47:09 +0100 Reply-To: From: "Adrian Farrel" To: References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 11 Aug 2017 19:47:07 +0100 Message-ID: <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23252.001 X-TM-AS-Result: No--14.445-10.0-31-10 X-imss-scan-details: No--14.445-10.0-31-10 X-TMASE-MatchedRID: rqmDq8+jU9MALfxbHOcBRlu4M/xm4KZeH8cjAOna5Kv5FE/jy9O3nbMD YIiOMuxa4plhBuwyqtHSrSKGJJTJhrkYizK5Be96ACs2C3nGlBhCn2WEjt2Yo6Gn8EOTqEDA2d8 mtRIRsUPMGlr2fNoNDJs4Q6e9f0oNL0W1btd8e57OeIV+MVeozhpXjRc0zbUqiggc5gPv8G/6hy ODqRDK2Z0EopZ3V99yTugiO6yIdoryAvqldeMqenV7tdtvoibaGbJMFqqIm9wifM7JMNHW6xvDD WnRtEZGX+uVOmHkQvCH/aIpLb3OWxxyVPzEfp5h/jkwiY2tJnL2kudi1D33EqIiUozBB8xriMD6 wB/IizIuFwNzrXciLeSU7G1VvsR9u+66Sy5jOwKHZXNSWjgdUwml5JDmKayhWltirZ/iPP6OudT hERN49oBAUdh4514r9u75WUASg3Q3KXWd30Ii3Tl/1fD/GopdyJ1gFgOMhOnmKuxMXtACKKu6xV HLhqfxrFldG3ZH+DlIGo8bxrs5obQW5W8z2t6njUhQf/WGFLTP70zAdHk7Sq8hJNN51GP5VJ7tc 98LFuo= Archived-At: Subject: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 18:47:17 -0000 Hi all, SPRING didn't meet in Prague so I presented this work in MPLS. Bruno suggested that maybe SPRING would be a better venue. I'm not sure about that, although I do think both WGs should chat about the ideas. The essence of this work is nothing more that MPLS-SR encapsulated in UDP per RFC 7510. What it achieves is a way to obtain the SR functionality that we all know and love in an IP network. The approach is, of course, compatible with MPLS-SR. As the draft says... This document makes no changes to the segment routing architecture and builds on existing protocol mechanisms such as the encapsulation of MPLS within UDP defined in RFC 7510. No new procedures are introduced, but existing mechanisms are combined to achieve the desired result. This is not intended to be a beauty contest with SRv6. As the draft says... The method defined is a complementary way of running SR in an IP network that can be used alongside or interchangeably with that defined in [I-D.ietf-6man-segment-routing-header]. Implementers and deployers should consider the benefits and drawbacks of each method and select the approach most suited to their needs. Thanks, Adrian > ________________________________________ > From: internet-drafts@ietf.org > Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, London > To: Stewart Bryant; John E Drake; Adrian Farrel > Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt > > A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. > > Name: draft-bryant-mpls-unified-ip-sr > Revision: 01 > Title: A Unified Approach to IP Segment Routing > Document date: 2017-08-11 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr- > 01.txt > Status: https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ > Htmlized: https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip- > sr-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-unified-ip-sr-01 > > Abstract: > Segment routing is a source routed forwarding method that allows > packets to be steered through a network on paths other than the > shortest path derived from the routing protocol. The approach uses > information encoded in the packet header to partially or completely > specify the route the packet takes through the network, and does not > make use of a signaling protocol to pre-install paths in the network. > > Two different encapsulations have been defined to enable segment > routing in an MPLS network and in an IPv6 network. While > acknowledging that there is a strong need to support segment routing > in both environments, this document defines a converged, unified > approach to segment routing that enables a single mechanism to be > applied in both types of network. The resulting approach is also > applicable to IPv4 networks without the need for any changes to the > IPv4 specification. > > This document makes no changes to the segment routing architecture > and builds on existing protocol mechanisms such as the encapsulation > of MPLS within UDP defined in RFC 7510. > > No new procedures are introduced, but existing mechanisms are > combined to achieve the desired result. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Fri Aug 11 12:11:50 2017 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 0A7CB13252C; Fri, 11 Aug 2017 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 EGYUCiDh8JYx; Fri, 11 Aug 2017 12:11:47 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 2241913247C; Fri, 11 Aug 2017 12:11:47 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 76so32149702ith.0; Fri, 11 Aug 2017 12:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Zr27mD2hgnjBEyt9cvWsxb7O4Bum3zJssYen8R4rCs4=; b=gVS7xyWQaL4RlmvXCMGVlbsP0rr7Zol4T/3gpOaBMRsP6ZMhgX5ULJWRW1LlYHG1iZ b4wQKNz1CDXoeVoHBB+2g/E3xNy7iQ2R3IL8RrknzCKnbWN6sw7edfbQoNOpUACmdwbG 51ofCbVLrlZB95JGLXuwcRh51Lba/1r1tiD52PXUu9wgrdvJ1+ifpMGfVgsldSdIgiUJ 21scUcuapMbnCYgb3dcTh7YwOeXo1QwUjflwQavWS0fOWfgordNERxGkuqFfGSFoymCV tyP18vFgbRIcQkyPul4qDbm+GkPNVRvOZS8VkmvEd1TyBKUMbOcDakTiLbj9ZjAr8u5j V00w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Zr27mD2hgnjBEyt9cvWsxb7O4Bum3zJssYen8R4rCs4=; b=bc2D15MSMfwQCyD1CD11A0GV2MVGdV6bJcVsaWEl/M312PcElvvOc5OmZaM0Mebbio Uzgkq43Jo3wWxJztIKAhH1VgSW+6BOlMfx366DG1f3knLRDalks+keRYm2A8BpxDcZL1 0mwXnictMMqE3K4DFddRVKfajilIlUg95t8wA7xySWh/4BsdonBAAQR8nylh4gUpMjSR XOawWRkzNbX1NBdUWnyAPRoAXHZ6A+esO6Dt2QeEyub+na967Ft+hN9y54dXfNefw3ia Xxs1EtTpD1ZeGSTia2f38aSH4MhVnFXontSPICmX+k1Meuctlj/eaEqSikQnPy8IcLEm J81w== X-Gm-Message-State: AHYfb5jCf0XlgHKxJ9Y3EpyOeQXF5/fxSmw2HUytf0XrDSbEO4bRko4C EKRFAt6ueFQn80KAQz5ybi83ncFe3hgc X-Received: by 10.36.236.5 with SMTP id g5mr26524ith.49.1502478706163; Fri, 11 Aug 2017 12:11:46 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.76.85 with HTTP; Fri, 11 Aug 2017 12:11:45 -0700 (PDT) In-Reply-To: <053e01d312d3$1dcba0c0$5962e240$@olddog.co.uk> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053e01d312d3$1dcba0c0$5962e240$@olddog.co.uk> From: Robert Raszuk Date: Fri, 11 Aug 2017 21:11:45 +0200 X-Google-Sender-Auth: lmbdyfKsivL5cnnviM5WNyth71U Message-ID: To: Adrian Farrel Cc: "mpls@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c04e95090491905567f155d" Archived-At: Subject: Re: [spring] [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 19:11:50 -0000 --94eb2c04e95090491905567f155d Content-Type: text/plain; charset="UTF-8" Hi Adrian, I see few so to say "challenges" with the proposal A) SRv6 SID is 128 bits where first 64 is the locator and remaining 64 is the function. So to "emulate" this directly with SR-MPLS you need for 1 SRv6 SID stack of 8 labels ! And some use cases of SRv6 already talk about using few SRv6 SIDs. Please show me the today's hardware which can consume in single pass and make sense of stack of say 32 mpls labels ... so here goes your "interchangeability". B) One of serious concerns with SRH insertion in transit as expressed by 6man was MTU. How does this proposal solves this at all if what you are doing here is taking nicely MTU discovered and negotiated IPv6 packet and adding mpls stack or tower + UDP + IPv/v6 encap to it ? How would end hosts now will get any awareness about this ? C) One of the very nice applications for SRv6 is spray function with full multicast address transparency. Please kindly elaborate how are you going to map IPv4 or IPv6 multicast addresses into MPLS labels ? - - - I think while it looks great on slides that now we will have two different ways to do SR on IP networks if you really focus to specific applications you will find a lot of them which are not going to be compatible with your proposal. So maybe instead trying to squeeze the balloon to fit the bottle we better collectively focus on making the balloon fly ? Kind regards, Robert. On Fri, Aug 11, 2017 at 8:53 PM, Adrian Farrel wrote: > All, > > The presentation of this draft in Prague seemed to be well received and we > got > some comments that we have stated to act on in this revision. > > One, non-technical request was to share the work with the SPRING working > group, > and I have just done that. > > At the meeting I noted that... > > The authors think this is in charter for MPLS > > But polish and discussion is needed before we ask for adoption > > As this polish continues, I'd like to ask the list what they think of this > work. > Is it going in the right direction? Is it work that you support? > > Thanks, > Adrian > > > ________________________________________ > > From: internet-drafts@ietf.org > > Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, > London > > To: Stewart Bryant; John E Drake; Adrian Farrel > > Subject: New Version Notification for draft-bryant-mpls-unified-ip- > sr-01.txt > > > > A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Name: draft-bryant-mpls-unified-ip-sr > > Revision: 01 > > Title: A Unified Approach to IP Segment Routing > > Document date: 2017-08-11 > > Group: Individual Submission > > Pages: 16 > > URL: > https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr- > > 01.txt > > Status: > https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ > > Htmlized: https://tools.ietf.org/html/ > draft-bryant-mpls-unified-ip-sr-01 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip- > > sr-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-unified-ip-sr-01 > > > > Abstract: > > Segment routing is a source routed forwarding method that allows > > packets to be steered through a network on paths other than the > > shortest path derived from the routing protocol. The approach uses > > information encoded in the packet header to partially or completely > > specify the route the packet takes through the network, and does not > > make use of a signaling protocol to pre-install paths in the network. > > > > Two different encapsulations have been defined to enable segment > > routing in an MPLS network and in an IPv6 network. While > > acknowledging that there is a strong need to support segment routing > > in both environments, this document defines a converged, unified > > approach to segment routing that enables a single mechanism to be > > applied in both types of network. The resulting approach is also > > applicable to IPv4 networks without the need for any changes to the > > IPv4 specification. > > > > This document makes no changes to the segment routing architecture > > and builds on existing protocol mechanisms such as the encapsulation > > of MPLS within UDP defined in RFC 7510. > > > > No new procedures are introduced, but existing mechanisms are > > combined to achieve the desired result. > > > > > > > > > > > > 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --94eb2c04e95090491905567f155d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

=
I see few so to say "challenges" with th= e proposal=C2=A0

A)=C2= =A0

SRv6 SID is 128 bi= ts where first 64 is the locator and remaining 64 is the function. So to &q= uot;emulate" this directly with SR-MPLS you need for 1 SRv6 SID stack = of 8 labels ! And some use cases of SRv6 already talk about using few SRv6 = SIDs. Please show me the today's hardware which can consume in single p= ass and make sense of stack of say 32 mpls labels ... so here goes your &qu= ot;interchangeability".=C2=A0

B)=C2=A0

One of serious concerns with SRH insertion in transit as expressed by 6man= was MTU. How does this proposal solves this at all if what you are doing h= ere is taking nicely MTU discovered and negotiated IPv6 packet and adding m= pls stack or tower + UDP + IPv/v6 encap to it ? How would end hosts now wil= l get any awareness about this ?

C)=C2=A0

On= e of the very nice applications for SRv6 is spray function with full multic= ast address transparency. Please kindly elaborate how are you going to map = IPv4 or IPv6 multicast addresses into MPLS labels ?

- - -=C2=A0

I think while it looks great on slides that now we will= have two different ways to do SR on IP networks if you really focus to spe= cific applications you will find a lot of them which are not going to be co= mpatible with your proposal. So maybe instead trying to squeeze the balloon= to fit the bottle we better collectively focus on making the balloon fly ?= =C2=A0

Kind regards,
Robert.






On Fri, Aug 11, 2017 at 8:53 PM, Adrian Farrel <adri= an@olddog.co.uk> wrote:
All= ,

The presentation of this draft in Prague seemed to be well received and we = got
some comments that we have stated to act on in this revision.

One, non-technical request was to share the work with the SPRING working gr= oup,
and I have just done that.

At the meeting I noted that...
> The authors think this is in charter for MPLS
> But polish and discussion is needed before we ask for adoption

As this polish continues, I'd like to ask the list what they think of t= his work.
Is it going in the right direction? Is it work that you support?

Thanks,
Adrian

> ________________________________________
> From: internet-drafts@ietf= .org
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, L= ondon
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
>
> A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bryant-mpls-unifie= d-ip-sr
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Unified Approach to IP Segm= ent Routing
> Document date:=C2=A0 2017-08-11
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
> URL:
https://www.ietf.org/internet-<= wbr>drafts/draft-bryant-mpls-unified-ip-sr-
> 01.txt
> Status:
https://datatracker.ietf.org/d= oc/draft-bryant-mpls-unified-ip-sr/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01=
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?<= wbr>url2=3Ddraft-bryant-mpls-unified-ip-sr-01
>
> Abstract:
>=C2=A0 =C2=A0 Segment routing is a source routed forwarding method that= allows
>=C2=A0 =C2=A0 packets to be steered through a network on paths other th= an the
>=C2=A0 =C2=A0 shortest path derived from the routing protocol.=C2=A0 Th= e approach uses
>=C2=A0 =C2=A0 information encoded in the packet header to partially or = completely
>=C2=A0 =C2=A0 specify the route the packet takes through the network, a= nd does not
>=C2=A0 =C2=A0 make use of a signaling protocol to pre-install paths in = the network.
>
>=C2=A0 =C2=A0 Two different encapsulations have been defined to enable = segment
>=C2=A0 =C2=A0 routing in an MPLS network and in an IPv6 network.=C2=A0 = While
>=C2=A0 =C2=A0 acknowledging that there is a strong need to support segm= ent routing
>=C2=A0 =C2=A0 in both environments, this document defines a converged, = unified
>=C2=A0 =C2=A0 approach to segment routing that enables a single mechani= sm to be
>=C2=A0 =C2=A0 applied in both types of network.=C2=A0 The resulting app= roach is also
>=C2=A0 =C2=A0 applicable to IPv4 networks without the need for any chan= ges to the
>=C2=A0 =C2=A0 IPv4 specification.
>
>=C2=A0 =C2=A0 This document makes no changes to the segment routing arc= hitecture
>=C2=A0 =C2=A0 and builds on existing protocol mechanisms such as the en= capsulation
>=C2=A0 =C2=A0 of MPLS within UDP defined in RFC 7510.
>
>=C2=A0 =C2=A0 No new procedures are introduced, but existing mechanisms= are
>=C2=A0 =C2=A0 combined to achieve the desired result.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat

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

--94eb2c04e95090491905567f155d-- From nobody Fri Aug 11 12:22:32 2017 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 87FB5131DB6; Fri, 11 Aug 2017 12:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC-Z0VGtP1q3; Fri, 11 Aug 2017 12:22:26 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B03120713; Fri, 11 Aug 2017 12:22:26 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id x3so41993672oia.1; Fri, 11 Aug 2017 12:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4a8gJsNgq8aXBU8zQbuVC4DaR1HoR5nr4g/flbzDRqo=; b=XFvH9/36GEDiQESl6ZJKm/DNOd9prNzKoDuly4mI63/j2/2Pj/Tn1hVkz+QakDLWqa EKO/A97J5bZsnXNHozWzWd/02pBbel23HLQEhii3l44UyU4wyzqZC10O0ASS/Mit5Td3 0OG5zBozuG5/Kr/vwuC9vnkRL7soy5vbAAtZn+jEjGecWa63DVEiindOb3rDjS4KSMGW FIUZkmrSoN+UQ8yueCxbd9oeof2jrWR0wXtgeyUkE4nJDtKaR5dTJ14J0f60nmlA9B70 Yq789Z6TBnAs00R4RiUKO2bmtQ2QQUGzOppIwLazc8AYRCW5IQ4k4ni1PNw9zutlOwyW hcsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4a8gJsNgq8aXBU8zQbuVC4DaR1HoR5nr4g/flbzDRqo=; b=UucmXu/8ej2WseeqDRer7Zz16sqG/qq8AsTKTpFVTQbrsJL9qZcH8yYft9WxjqIFE6 CJyrhPcpAcRMW2k89KkK6V/mGlbnT6QDA4kTo22E04leDWk9dfdE1GbHo7TLEncQAZy9 d0snJSMo6mNF1jBueCJYEnbpKgUkraWG+fUsx7w6CamstU1FGYJ1Qm96XCBCql6RGDOz JHGpLvT34XyhsGZptAipo0AXIF0DX/AAQdfNsV+HuXIWC64jpxtHF8/41/kherlMuLUm fJY/PFK3GEp/PVtMv70DpeX8+wJR9R5l07n/DVwVsGrZT44ZU27pl5+x7rjIkABCcGQD siNQ== X-Gm-Message-State: AHYfb5ikTine1/ONiuMEa01dSZwxcVxrT72V0qzAxekR/8/ZjX6KTvYc OVu2ec6xZ5Q7fSbZGqS8KU51csMhmQ== X-Received: by 10.202.213.79 with SMTP id m76mr17758953oig.54.1502479346025; Fri, 11 Aug 2017 12:22:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.34 with HTTP; Fri, 11 Aug 2017 12:22:05 -0700 (PDT) In-Reply-To: <053e01d312d3$1dcba0c0$5962e240$@olddog.co.uk> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053e01d312d3$1dcba0c0$5962e240$@olddog.co.uk> From: "Andrew G. Malis" Date: Fri, 11 Aug 2017 15:22:05 -0400 Message-ID: To: Adrian Farrel Cc: "mpls@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="001a113acab2b3ccea05567f3b07" Archived-At: Subject: Re: [spring] [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 19:22:30 -0000 --001a113acab2b3ccea05567f3b07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian, I think this is a straightforward draft that provides valuable functionality, especially SR within an IP (v4 or v6) network as discussed in section 6.2. I certainly support it going forward. I don=E2=80=99t perso= nally have a strong opinion whether MPLS or SPRING is the proper place to pursue the work, as long as it is pursued. I=E2=80=99m happy to let the WG chairs = and ADs figure that out. Cheers, Andy On Fri, Aug 11, 2017 at 2:53 PM, Adrian Farrel wrote: > All, > > The presentation of this draft in Prague seemed to be well received and w= e > got > some comments that we have stated to act on in this revision. > > One, non-technical request was to share the work with the SPRING working > group, > and I have just done that. > > At the meeting I noted that... > > The authors think this is in charter for MPLS > > But polish and discussion is needed before we ask for adoption > > As this polish continues, I'd like to ask the list what they think of thi= s > work. > Is it going in the right direction? Is it work that you support? > > Thanks, > Adrian > > > ________________________________________ > > From: internet-drafts@ietf.org > > Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, > London > > To: Stewart Bryant; John E Drake; Adrian Farrel > > Subject: New Version Notification for draft-bryant-mpls-unified-ip- > sr-01.txt > > > > A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Name: draft-bryant-mpls-unified-ip-sr > > Revision: 01 > > Title: A Unified Approach to IP Segment Routing > > Document date: 2017-08-11 > > Group: Individual Submission > > Pages: 16 > > URL: > https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr- > > 01.txt > > Status: > https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ > > Htmlized: https://tools.ietf.org/html/ > draft-bryant-mpls-unified-ip-sr-01 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip- > > sr-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-bryant-mpls-unified-ip-sr-01 > > > > Abstract: > > Segment routing is a source routed forwarding method that allows > > packets to be steered through a network on paths other than the > > shortest path derived from the routing protocol. The approach uses > > information encoded in the packet header to partially or completely > > specify the route the packet takes through the network, and does not > > make use of a signaling protocol to pre-install paths in the network= . > > > > Two different encapsulations have been defined to enable segment > > routing in an MPLS network and in an IPv6 network. While > > acknowledging that there is a strong need to support segment routing > > in both environments, this document defines a converged, unified > > approach to segment routing that enables a single mechanism to be > > applied in both types of network. The resulting approach is also > > applicable to IPv4 networks without the need for any changes to the > > IPv4 specification. > > > > This document makes no changes to the segment routing architecture > > and builds on existing protocol mechanisms such as the encapsulation > > of MPLS within UDP defined in RFC 7510. > > > > No new procedures are introduced, but existing mechanisms are > > combined to achieve the desired result. > > > > > > > > > > > > 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113acab2b3ccea05567f3b07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adrian,

I think this is a straightforwa= rd draft that provides valuable functionality, especially SR within an IP (= v4 or v6) network as discussed in section 6.2. I certainly support it going= forward. I don=E2=80=99t personally have a strong opinion whether MPLS or = SPRING is the proper place to pursue the work, as long as it is pursued. I= =E2=80=99m happy to let the WG chairs and ADs figure that out.
Cheers,
Andy


On Fri, Aug 11, 2017 at 2:53 P= M, Adrian Farrel <adrian@olddog.co.uk> wrote:
All,

The presentation of this draft in Prague seemed to be well received and we = got
some comments that we have stated to act on in this revision.

One, non-technical request was to share the work with the SPRING working gr= oup,
and I have just done that.

At the meeting I noted that...
> The authors think this is in charter for MPLS
> But polish and discussion is needed before we ask for adoption

As this polish continues, I'd like to ask the list what they think of t= his work.
Is it going in the right direction? Is it work that you support?

Thanks,
Adrian

> ________________________________________
> From: internet-drafts@ietf= .org
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, L= ondon
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
>
> A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bryant-mpls-unifie= d-ip-sr
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Unified Approach to IP Segm= ent Routing
> Document date:=C2=A0 2017-08-11
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
> URL:
https://www.ietf.org/internet-<= wbr>drafts/draft-bryant-mpls-unified-ip-sr-
> 01.txt
> Status:
https://datatracker.ietf.org/d= oc/draft-bryant-mpls-unified-ip-sr/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01=
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?<= wbr>url2=3Ddraft-bryant-mpls-unified-ip-sr-01
>
> Abstract:
>=C2=A0 =C2=A0 Segment routing is a source routed forwarding method that= allows
>=C2=A0 =C2=A0 packets to be steered through a network on paths other th= an the
>=C2=A0 =C2=A0 shortest path derived from the routing protocol.=C2=A0 Th= e approach uses
>=C2=A0 =C2=A0 information encoded in the packet header to partially or = completely
>=C2=A0 =C2=A0 specify the route the packet takes through the network, a= nd does not
>=C2=A0 =C2=A0 make use of a signaling protocol to pre-install paths in = the network.
>
>=C2=A0 =C2=A0 Two different encapsulations have been defined to enable = segment
>=C2=A0 =C2=A0 routing in an MPLS network and in an IPv6 network.=C2=A0 = While
>=C2=A0 =C2=A0 acknowledging that there is a strong need to support segm= ent routing
>=C2=A0 =C2=A0 in both environments, this document defines a converged, = unified
>=C2=A0 =C2=A0 approach to segment routing that enables a single mechani= sm to be
>=C2=A0 =C2=A0 applied in both types of network.=C2=A0 The resulting app= roach is also
>=C2=A0 =C2=A0 applicable to IPv4 networks without the need for any chan= ges to the
>=C2=A0 =C2=A0 IPv4 specification.
>
>=C2=A0 =C2=A0 This document makes no changes to the segment routing arc= hitecture
>=C2=A0 =C2=A0 and builds on existing protocol mechanisms such as the en= capsulation
>=C2=A0 =C2=A0 of MPLS within UDP defined in RFC 7510.
>
>=C2=A0 =C2=A0 No new procedures are introduced, but existing mechanisms= are
>=C2=A0 =C2=A0 combined to achieve the desired result.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat

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

--001a113acab2b3ccea05567f3b07-- From nobody Fri Aug 11 12:23:28 2017 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 737E1131DB6; Fri, 11 Aug 2017 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlI5BuOYyNFP; Fri, 11 Aug 2017 12:23:24 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90577131D1A; Fri, 11 Aug 2017 12:22:57 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id o9so23576176iod.1; Fri, 11 Aug 2017 12:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=F/hdG+M/xrjcpFZoxH7lqGgXRFUC3CBDUpykf4FGl7Q=; b=hBBYYVRHkLdRP3ti/qwNN0/eH+9wD4/0XsDsE/t1kfCF3CTnc6aukpOE8cD5+PbuDs Em4fRHY61jN706sOqAHOAhYHwQXQb9Yxp7qtHZN2AZr0RIIbTViFRXFNtKtBiUzU6Qpl TrRPGFToZ5+JpCl3tuekY1buhNAwur9PJqVmgPtlJtH674PCoGxP7d9dC6ZYi/ib6iNV JsqZxbUVp8gKb+VjQ16uFhnNAFdKau4vfuBg/fID1HajXDgyKmDgH/mF9IdlSblsXLqc B+eHieSr1EmV7nCIxomlntuZkP2ZBWVUXTuyrNMTJcVBgemcsLkvXcVtBR8xiGST7O3j YjGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=F/hdG+M/xrjcpFZoxH7lqGgXRFUC3CBDUpykf4FGl7Q=; b=pUIKD58CmUj1qgcOlv3fk4HgfvciBkbeTwpD6z3y7D4X74x5NhVDcljldvX2CQAj2I TmXXBfhMYSFH5iX1UsDGLwKZGJz7+1M7JTeyeNb2ZBDNVexwz++UEsg7g+MB40W5M4SM waCPZOYZBCTkc3rSgCIgq4LTooZwEvetQLlfsBBVYh4UejBTuUhuG4zgjSm6IV+ow4zd iybKn7jItO4JFzbBqu1o/DL/XQWL+6oxn3nssRExoXLJy9ukBqGyOFxyNDkcuVLb4F7g 0NI9nDsqfBozvEZLBYNjDR3OEjcBAZzD50ZfuPwPTYaDCywVpuh3LYAWLqd/n3SkRp0z kHRA== X-Gm-Message-State: AIVw113wwqCjIZC0zmXc/Mu/1GM/OtepWqbqzi9Pc0Vgy7lZXPe3Vxtx sgR7LuAPcJQn+W6DJUp6dXpK/mA0N0wj X-Received: by 10.107.175.136 with SMTP id p8mr14614788ioo.219.1502479376615; Fri, 11 Aug 2017 12:22:56 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.76.85 with HTTP; Fri, 11 Aug 2017 12:22:55 -0700 (PDT) In-Reply-To: References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053e01d312d3$1dcba0c0$5962e240$@olddog.co.uk> From: Robert Raszuk Date: Fri, 11 Aug 2017 21:22:55 +0200 X-Google-Sender-Auth: 2UGOVjt2gCRhE1Bmg8_JAkrXYfg Message-ID: To: Adrian Farrel Cc: "mpls@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="001a11447f72868d3205567f3dbe" Archived-At: Subject: Re: [spring] [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 19:23:28 -0000 --001a11447f72868d3205567f3dbe Content-Type: text/plain; charset="UTF-8" Sorry but forgot one more really useful advantage which your proposal is lacking ... D) In SRv6 when you traverse SR node you move the pointer from one SID to the next one. This allows you to maintain in the packet the entire history of functions executed on a given packet. Something which to the best of my knowledge we never had in the IP networks. Now how could you accomplish the same or even close to that with SR-MPLS analogy ? Cheers, R. On Fri, Aug 11, 2017 at 9:11 PM, Robert Raszuk wrote: > Hi Adrian, > > I see few so to say "challenges" with the proposal > > A) > > SRv6 SID is 128 bits where first 64 is the locator and remaining 64 is the > function. So to "emulate" this directly with SR-MPLS you need for 1 SRv6 > SID stack of 8 labels ! And some use cases of SRv6 already talk about using > few SRv6 SIDs. Please show me the today's hardware which can consume in > single pass and make sense of stack of say 32 mpls labels ... so here goes > your "interchangeability". > > B) > > One of serious concerns with SRH insertion in transit as expressed by 6man > was MTU. How does this proposal solves this at all if what you are doing > here is taking nicely MTU discovered and negotiated IPv6 packet and adding > mpls stack or tower + UDP + IPv/v6 encap to it ? How would end hosts now > will get any awareness about this ? > > C) > > One of the very nice applications for SRv6 is spray function with full > multicast address transparency. Please kindly elaborate how are you going > to map IPv4 or IPv6 multicast addresses into MPLS labels ? > > - - - > > I think while it looks great on slides that now we will have two different > ways to do SR on IP networks if you really focus to specific applications > you will find a lot of them which are not going to be compatible with your > proposal. So maybe instead trying to squeeze the balloon to fit the bottle > we better collectively focus on making the balloon fly ? > > Kind regards, > Robert. > > > > > > > On Fri, Aug 11, 2017 at 8:53 PM, Adrian Farrel > wrote: > >> All, >> >> The presentation of this draft in Prague seemed to be well received and >> we got >> some comments that we have stated to act on in this revision. >> >> One, non-technical request was to share the work with the SPRING working >> group, >> and I have just done that. >> >> At the meeting I noted that... >> > The authors think this is in charter for MPLS >> > But polish and discussion is needed before we ask for adoption >> >> As this polish continues, I'd like to ask the list what they think of >> this work. >> Is it going in the right direction? Is it work that you support? >> >> Thanks, >> Adrian >> >> > ________________________________________ >> > From: internet-drafts@ietf.org >> > Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, >> London >> > To: Stewart Bryant; John E Drake; Adrian Farrel >> > Subject: New Version Notification for draft-bryant-mpls-unified-ip-s >> r-01.txt >> > >> > A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt >> > has been successfully submitted by Adrian Farrel and posted to the >> > IETF repository. >> > >> > Name: draft-bryant-mpls-unified-ip-sr >> > Revision: 01 >> > Title: A Unified Approach to IP Segment Routing >> > Document date: 2017-08-11 >> > Group: Individual Submission >> > Pages: 16 >> > URL: >> https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr- >> > 01.txt >> > Status: >> https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ >> > Htmlized: https://tools.ietf.org/html/d >> raft-bryant-mpls-unified-ip-sr-01 >> > Htmlized: >> https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip- >> > sr-01 >> > Diff: >> https://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-unified-ip-sr-01 >> > >> > Abstract: >> > Segment routing is a source routed forwarding method that allows >> > packets to be steered through a network on paths other than the >> > shortest path derived from the routing protocol. The approach uses >> > information encoded in the packet header to partially or completely >> > specify the route the packet takes through the network, and does not >> > make use of a signaling protocol to pre-install paths in the network. >> > >> > Two different encapsulations have been defined to enable segment >> > routing in an MPLS network and in an IPv6 network. While >> > acknowledging that there is a strong need to support segment routing >> > in both environments, this document defines a converged, unified >> > approach to segment routing that enables a single mechanism to be >> > applied in both types of network. The resulting approach is also >> > applicable to IPv4 networks without the need for any changes to the >> > IPv4 specification. >> > >> > This document makes no changes to the segment routing architecture >> > and builds on existing protocol mechanisms such as the encapsulation >> > of MPLS within UDP defined in RFC 7510. >> > >> > No new procedures are introduced, but existing mechanisms are >> > combined to achieve the desired result. >> > >> > >> > >> > >> > >> > 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 >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > --001a11447f72868d3205567f3dbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry but forgot one more really useful= advantage which your proposal is lacking ...=C2=A0

D)=C2=A0

In SRv6 when you traverse SR node you move the pointer fro= m one SID to the next one. This allows you to maintain in the packet the en= tire history of functions executed on a given packet. Something which to th= e best of my knowledge we never had in the IP networks. Now how could you a= ccomplish the same or even close to that with SR-MPLS analogy ?=C2=A0
=

Cheers,
R.

On Fri, Aug 11, 201= 7 at 9:11 PM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Adrian,=

I see few so to say &= quot;challenges" with the proposal=C2=A0

<= /div>
A)=C2=A0

SRv6 SID is 128 bits where first 64 is the locator and remaining= 64 is the function. So to "emulate" this directly with SR-MPLS y= ou need for 1 SRv6 SID stack of 8 labels ! And some use cases of SRv6 alrea= dy talk about using few SRv6 SIDs. Please show me the today's hardware = which can consume in single pass and make sense of stack of say 32 mpls lab= els ... so here goes your "interchangeability".=C2=A0

B)=C2=A0
=
One of serious concerns with SRH insertion in = transit as expressed by 6man was MTU. How does this proposal solves this at= all if what you are doing here is taking nicely MTU discovered and negotia= ted IPv6 packet and adding mpls stack or tower + UDP + IPv/v6 encap to it ?= How would end hosts now will get any awareness about this ?

C)=C2=A0
One of the very nice applications for SRv6 is spr= ay function with full multicast address transparency. Please kindly elabora= te how are you going to map IPv4 or IPv6 multicast addresses into MPLS labe= ls ?

- - -=C2=A0

I think while it looks gr= eat on slides that now we will have two different ways to do SR on IP netwo= rks if you really focus to specific applications you will find a lot of the= m which are not going to be compatible with your proposal. So maybe instead= trying to squeeze the balloon to fit the bottle we better collectively foc= us on making the balloon fly ?=C2=A0

Kind regards,
Robert.






On Fri, Aug 11, 2017 at 8:53 PM, Adrian Farrel <adria= n@olddog.co.uk> wrote:
All,=

The presentation of this draft in Prague seemed to be well received and we = got
some comments that we have stated to act on in this revision.

One, non-technical request was to share the work with the SPRING working gr= oup,
and I have just done that.

At the meeting I noted that...
> The authors think this is in charter for MPLS
> But polish and discussion is needed before we ask for adoption

As this polish continues, I'd like to ask the list what they think of t= his work.
Is it going in the right direction? Is it work that you support?

Thanks,
Adrian

> ________________________________________
> From: in= ternet-drafts@ietf.org
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, L= ondon
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
>
> A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bryant-mpls-unifie= d-ip-sr
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Unified Approach to IP Segm= ent Routing
> Document date:=C2=A0 2017-08-11
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
> URL:
https://www.ietf.org/internet-<= wbr>drafts/draft-bryant-mpls-unified-ip-sr-
> 01.txt
> Status:
https://datatracker.ietf.org/d= oc/draft-bryant-mpls-unified-ip-sr/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01=
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-bryant-mpls-unified-ip-sr-01
>
> Abstract:
>=C2=A0 =C2=A0 Segment routing is a source routed forwarding method that= allows
>=C2=A0 =C2=A0 packets to be steered through a network on paths other th= an the
>=C2=A0 =C2=A0 shortest path derived from the routing protocol.=C2=A0 Th= e approach uses
>=C2=A0 =C2=A0 information encoded in the packet header to partially or = completely
>=C2=A0 =C2=A0 specify the route the packet takes through the network, a= nd does not
>=C2=A0 =C2=A0 make use of a signaling protocol to pre-install paths in = the network.
>
>=C2=A0 =C2=A0 Two different encapsulations have been defined to enable = segment
>=C2=A0 =C2=A0 routing in an MPLS network and in an IPv6 network.=C2=A0 = While
>=C2=A0 =C2=A0 acknowledging that there is a strong need to support segm= ent routing
>=C2=A0 =C2=A0 in both environments, this document defines a converged, = unified
>=C2=A0 =C2=A0 approach to segment routing that enables a single mechani= sm to be
>=C2=A0 =C2=A0 applied in both types of network.=C2=A0 The resulting app= roach is also
>=C2=A0 =C2=A0 applicable to IPv4 networks without the need for any chan= ges to the
>=C2=A0 =C2=A0 IPv4 specification.
>
>=C2=A0 =C2=A0 This document makes no changes to the segment routing arc= hitecture
>=C2=A0 =C2=A0 and builds on existing protocol mechanisms such as the en= capsulation
>=C2=A0 =C2=A0 of MPLS within UDP defined in RFC 7510.
>
>=C2=A0 =C2=A0 No new procedures are introduced, but existing mechanisms= are
>=C2=A0 =C2=A0 combined to achieve the desired result.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat

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


--001a11447f72868d3205567f3dbe-- From nobody Fri Aug 11 13:17:10 2017 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 9CD7A1323B2; Fri, 11 Aug 2017 13:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 lscIAZTB18Aj; Fri, 11 Aug 2017 13:17:01 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 0E742132351; Fri, 11 Aug 2017 13:17:00 -0700 (PDT) X-AuditID: c6180641-0f7ff70000002d27-98-598dca59c614 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 63.93.11559.95ACD895; Fri, 11 Aug 2017 17:16:42 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Fri, 11 Aug 2017 16:16:58 -0400 From: Eric Gray To: "Andrew G. Malis" , Adrian Farrel CC: "mpls@ietf.org" , "spring@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS5lxCAAEyogP//zC9Q Date: Fri, 11 Aug 2017 20:16:58 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64B7B6FDB@eusaamb107.ericsson.se> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053e01d312d3$1dcba0c0$5962e240$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF64B7B6FDBeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyuXRPuG7Uqd5IgyXnhSx+9Nxgtjj9/BSb xa2lK1ktjl/4zejA4rFz1l12jyVLfjJ5rNi8kjGAOYrLJiU1J7MstUjfLoEr48Gpq8wFs7oZ K77/mMXYwLinnbGLkZNDQsBEYuKxS2xdjFwcQgJHGSVuNTewQzjLGSUO/3/GClLFJqAhcezO WrAOEQE/iSfzb7F0MXJwMAt4SBw6KwASFhaIldi+7TUTREmcxPpfK6DK3ST+vjzEAmKzCKhK HDv7FSzOK+Arcbb7GTuILSQwiUniT4cKiM0pECix7+hKsDijgJjE91NrwGYyC4hL3Hoynwni aAGJJXvOM0PYohIvH/9jhbCVJCYtPccKUZ8vMfXJGhaIXYISJ2c+YZnAKDILyahZSMpmISmb BfaZpsT6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRfxchRWlyQk5tuZLiJERhdxyTYHHcw7u31 PMQowMGoxMP7dX1vpBBrYllxZe4hRgkOZiURXgfOvkgh3pTEyqrUovz4otKc1OJDjNIcLEri vO/KL0QICaQnlqRmp6YWpBbBZJk4OKUaGFkE1XsF/VZf96rbnb9/Y0L+7Q5tjbXikZ80UzNk 3Vf+v3Pp1/xVbjWmW8wuvgv3f1vz5oQpq5TYKe9X779JL2MISJncqGruF/fmVPH6z7NZru+4 eHFB1YW60AuneiMeRQr48ry//+muXeZ7myNdXKainudmb/MxfWmpe3jNM4+AKcvKzHwquJVY ijMSDbWYi4oTATmkHnqqAgAA Archived-At: Subject: Re: [spring] [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 20:17:03 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF64B7B6FDBeusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBoZSBzYWlk4oCmDQoNCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IEZyaWRheSwgQXVndXN0IDEx LCAyMDE3IDM6MjIgUE0NClRvOiBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0K Q2M6IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVk LWlwLXNyLTAxLnR4dA0KDQpBZHJpYW4sDQoNCkkgdGhpbmsgdGhpcyBpcyBhIHN0cmFpZ2h0Zm9y d2FyZCBkcmFmdCB0aGF0IHByb3ZpZGVzIHZhbHVhYmxlIGZ1bmN0aW9uYWxpdHksIGVzcGVjaWFs bHkgU1Igd2l0aGluIGFuIElQICh2NCBvciB2NikgbmV0d29yayBhcyBkaXNjdXNzZWQgaW4gc2Vj dGlvbiA2LjIuIEkgY2VydGFpbmx5IHN1cHBvcnQgaXQgZ29pbmcgZm9yd2FyZC4gSSBkb27igJl0 IHBlcnNvbmFsbHkgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIHdoZXRoZXIgTVBMUyBvciBTUFJJTkcg aXMgdGhlIHByb3BlciBwbGFjZSB0byBwdXJzdWUgdGhlIHdvcmssIGFzIGxvbmcgYXMgaXQgaXMg cHVyc3VlZC4gSeKAmW0gaGFwcHkgdG8gbGV0IHRoZSBXRyBjaGFpcnMgYW5kIEFEcyBmaWd1cmUg dGhhdCBvdXQuDQoNCkNoZWVycywNCkFuZHkNCg0KDQpPbiBGcmksIEF1ZyAxMSwgMjAxNyBhdCAy OjUzIFBNLCBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5A b2xkZG9nLmNvLnVrPj4gd3JvdGU6DQpBbGwsDQoNClRoZSBwcmVzZW50YXRpb24gb2YgdGhpcyBk cmFmdCBpbiBQcmFndWUgc2VlbWVkIHRvIGJlIHdlbGwgcmVjZWl2ZWQgYW5kIHdlIGdvdA0Kc29t ZSBjb21tZW50cyB0aGF0IHdlIGhhdmUgc3RhdGVkIHRvIGFjdCBvbiBpbiB0aGlzIHJldmlzaW9u Lg0KDQpPbmUsIG5vbi10ZWNobmljYWwgcmVxdWVzdCB3YXMgdG8gc2hhcmUgdGhlIHdvcmsgd2l0 aCB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAsDQphbmQgSSBoYXZlIGp1c3QgZG9uZSB0aGF0Lg0K DQpBdCB0aGUgbWVldGluZyBJIG5vdGVkIHRoYXQuLi4NCj4gVGhlIGF1dGhvcnMgdGhpbmsgdGhp cyBpcyBpbiBjaGFydGVyIGZvciBNUExTDQo+IEJ1dCBwb2xpc2ggYW5kIGRpc2N1c3Npb24gaXMg bmVlZGVkIGJlZm9yZSB3ZSBhc2sgZm9yIGFkb3B0aW9uDQoNCkFzIHRoaXMgcG9saXNoIGNvbnRp bnVlcywgSSdkIGxpa2UgdG8gYXNrIHRoZSBsaXN0IHdoYXQgdGhleSB0aGluayBvZiB0aGlzIHdv cmsuDQpJcyBpdCBnb2luZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uPyBJcyBpdCB3b3JrIHRoYXQg eW91IHN1cHBvcnQ/DQoNClRoYW5rcywNCkFkcmlhbg0KDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+IFNlbnQ6IDExIEF1Z3VzdCAyMDE3IDE5 OjM5OjU5IChVVEMrMDA6MDApIER1YmxpbiwgRWRpbmJ1cmdoLCBMaXNib24sIExvbmRvbg0KPiBU bzogU3Rld2FydCBCcnlhbnQ7IEpvaG4gRSBEcmFrZTsgQWRyaWFuIEZhcnJlbA0KPiBTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQt aXAtc3ItMDEudHh0DQo+DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1icnlhbnQtbXBs cy11bmlmaWVkLWlwLXNyLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEFkcmlhbiBGYXJyZWwgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0K Pg0KPiBOYW1lOiAgICAgICAgICAgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zcg0KPiBS ZXZpc2lvbjogICAgICAgMDENCj4gVGl0bGU6ICAgICAgICAgIEEgVW5pZmllZCBBcHByb2FjaCB0 byBJUCBTZWdtZW50IFJvdXRpbmcNCj4gRG9jdW1lbnQgZGF0ZTogIDIwMTctMDgtMTENCj4gR3Jv dXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczogICAgICAgICAgMTYN Cj4gVVJMOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJyeWFu dC1tcGxzLXVuaWZpZWQtaXAtc3ItDQo+IDAxLnR4dA0KPiBTdGF0dXM6DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLw0KPiBI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyeWFudC1t cGxzLXVuaWZpZWQtaXAtc3ItMDENCj4gSHRtbGl6ZWQ6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtDQo+IHNyLTAxDQo+ IERpZmY6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYnJ5YW50LW1w bHMtdW5pZmllZC1pcC1zci0wMQ0KPg0KPiBBYnN0cmFjdDoNCj4gICAgU2VnbWVudCByb3V0aW5n IGlzIGEgc291cmNlIHJvdXRlZCBmb3J3YXJkaW5nIG1ldGhvZCB0aGF0IGFsbG93cw0KPiAgICBw YWNrZXRzIHRvIGJlIHN0ZWVyZWQgdGhyb3VnaCBhIG5ldHdvcmsgb24gcGF0aHMgb3RoZXIgdGhh biB0aGUNCj4gICAgc2hvcnRlc3QgcGF0aCBkZXJpdmVkIGZyb20gdGhlIHJvdXRpbmcgcHJvdG9j b2wuICBUaGUgYXBwcm9hY2ggdXNlcw0KPiAgICBpbmZvcm1hdGlvbiBlbmNvZGVkIGluIHRoZSBw YWNrZXQgaGVhZGVyIHRvIHBhcnRpYWxseSBvciBjb21wbGV0ZWx5DQo+ICAgIHNwZWNpZnkgdGhl IHJvdXRlIHRoZSBwYWNrZXQgdGFrZXMgdGhyb3VnaCB0aGUgbmV0d29yaywgYW5kIGRvZXMgbm90 DQo+ICAgIG1ha2UgdXNlIG9mIGEgc2lnbmFsaW5nIHByb3RvY29sIHRvIHByZS1pbnN0YWxsIHBh dGhzIGluIHRoZSBuZXR3b3JrLg0KPg0KPiAgICBUd28gZGlmZmVyZW50IGVuY2Fwc3VsYXRpb25z IGhhdmUgYmVlbiBkZWZpbmVkIHRvIGVuYWJsZSBzZWdtZW50DQo+ICAgIHJvdXRpbmcgaW4gYW4g TVBMUyBuZXR3b3JrIGFuZCBpbiBhbiBJUHY2IG5ldHdvcmsuICBXaGlsZQ0KPiAgICBhY2tub3ds ZWRnaW5nIHRoYXQgdGhlcmUgaXMgYSBzdHJvbmcgbmVlZCB0byBzdXBwb3J0IHNlZ21lbnQgcm91 dGluZw0KPiAgICBpbiBib3RoIGVudmlyb25tZW50cywgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGEg Y29udmVyZ2VkLCB1bmlmaWVkDQo+ICAgIGFwcHJvYWNoIHRvIHNlZ21lbnQgcm91dGluZyB0aGF0 IGVuYWJsZXMgYSBzaW5nbGUgbWVjaGFuaXNtIHRvIGJlDQo+ICAgIGFwcGxpZWQgaW4gYm90aCB0 eXBlcyBvZiBuZXR3b3JrLiAgVGhlIHJlc3VsdGluZyBhcHByb2FjaCBpcyBhbHNvDQo+ICAgIGFw cGxpY2FibGUgdG8gSVB2NCBuZXR3b3JrcyB3aXRob3V0IHRoZSBuZWVkIGZvciBhbnkgY2hhbmdl cyB0byB0aGUNCj4gICAgSVB2NCBzcGVjaWZpY2F0aW9uLg0KPg0KPiAgICBUaGlzIGRvY3VtZW50 IG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhlIHNlZ21lbnQgcm91dGluZyBhcmNoaXRlY3R1cmUNCj4g ICAgYW5kIGJ1aWxkcyBvbiBleGlzdGluZyBwcm90b2NvbCBtZWNoYW5pc21zIHN1Y2ggYXMgdGhl IGVuY2Fwc3VsYXRpb24NCj4gICAgb2YgTVBMUyB3aXRoaW4gVURQIGRlZmluZWQgaW4gUkZDIDc1 MTAuDQo+DQo+ICAgIE5vIG5ldyBwcm9jZWR1cmVzIGFyZSBpbnRyb2R1Y2VkLCBidXQgZXhpc3Rp bmcgbWVjaGFuaXNtcyBhcmUNCj4gICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCBy ZXN1bHQuDQo+DQo+DQo+DQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y ZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWls aW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K --_000_48E1A67CB9CA044EADFEAB87D814BFF64B7B6FDBeusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGF0IGhlIHNhaWTigKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IG1wbHMg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkFuZHJl dyBHLiBNYWxpczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEF1Z3VzdCAxMSwgMjAxNyAzOjIy IFBNPGJyPg0KPGI+VG86PC9iPiBBZHJpYW4gRmFycmVsICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVr Jmd0Ozxicj4NCjxiPkNjOjwvYj4gbXBsc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFkcmlhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhpcyBpcyBhIHN0cmFpZ2h0Zm9yd2FyZCBkcmFmdCB0aGF0 IHByb3ZpZGVzIHZhbHVhYmxlIGZ1bmN0aW9uYWxpdHksIGVzcGVjaWFsbHkgU1Igd2l0aGluIGFu IElQICh2NCBvciB2NikgbmV0d29yayBhcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiA2LjIuIEkgY2Vy dGFpbmx5IHN1cHBvcnQgaXQgZ29pbmcgZm9yd2FyZC4gSSBkb27igJl0IHBlcnNvbmFsbHkgaGF2 ZSBhIHN0cm9uZyBvcGluaW9uIHdoZXRoZXINCiBNUExTIG9yIFNQUklORyBpcyB0aGUgcHJvcGVy IHBsYWNlIHRvIHB1cnN1ZSB0aGUgd29yaywgYXMgbG9uZyBhcyBpdCBpcyBwdXJzdWVkLiBJ4oCZ bSBoYXBweSB0byBsZXQgdGhlIFdHIGNoYWlycyBhbmQgQURzIGZpZ3VyZSB0aGF0IG91dC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5k eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIEZyaSwgQXVnIDExLCAyMDE3IGF0IDI6NTMgUE0sIEFkcmlhbiBGYXJyZWwgJmx0OzxhIGhy ZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+YWRyaWFuQG9s ZGRvZy5jby51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFsbCw8YnI+DQo8YnI+DQpUaGUgcHJlc2VudGF0aW9uIG9mIHRo aXMgZHJhZnQgaW4gUHJhZ3VlIHNlZW1lZCB0byBiZSB3ZWxsIHJlY2VpdmVkIGFuZCB3ZSBnb3Q8 YnI+DQpzb21lIGNvbW1lbnRzIHRoYXQgd2UgaGF2ZSBzdGF0ZWQgdG8gYWN0IG9uIGluIHRoaXMg cmV2aXNpb24uPGJyPg0KPGJyPg0KT25lLCBub24tdGVjaG5pY2FsIHJlcXVlc3Qgd2FzIHRvIHNo YXJlIHRoZSB3b3JrIHdpdGggdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLDxicj4NCmFuZCBJIGhh dmUganVzdCBkb25lIHRoYXQuPGJyPg0KPGJyPg0KQXQgdGhlIG1lZXRpbmcgSSBub3RlZCB0aGF0 Li4uPGJyPg0KJmd0OyBUaGUgYXV0aG9ycyB0aGluayB0aGlzIGlzIGluIGNoYXJ0ZXIgZm9yIE1Q TFM8YnI+DQomZ3Q7IEJ1dCBwb2xpc2ggYW5kIGRpc2N1c3Npb24gaXMgbmVlZGVkIGJlZm9yZSB3 ZSBhc2sgZm9yIGFkb3B0aW9uPGJyPg0KPGJyPg0KQXMgdGhpcyBwb2xpc2ggY29udGludWVzLCBJ J2QgbGlrZSB0byBhc2sgdGhlIGxpc3Qgd2hhdCB0aGV5IHRoaW5rIG9mIHRoaXMgd29yay48YnI+ DQpJcyBpdCBnb2luZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uPyBJcyBpdCB3b3JrIHRoYXQgeW91 IHN1cHBvcnQ/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NClRoYW5rcyw8YnI+DQpBZHJpYW48YnI+DQo8YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEZyb206IDxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7IFNlbnQ6IDExIEF1Z3VzdCAyMDE3IDE5OjM5OjU5IChVVEMmIzQzOzAwOjAw KSBEdWJsaW4sIEVkaW5idXJnaCwgTGlzYm9uLCBMb25kb248YnI+DQomZ3Q7IFRvOiBTdGV3YXJ0 IEJyeWFudDsgSm9obiBFIERyYWtlOyBBZHJpYW4gRmFycmVsPGJyPg0KJmd0OyBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAt c3ItMDEudHh0PGJyPg0KJmd0Ozxicj4NCiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0PGJyPg0KJmd0OyBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFkcmlhbiBGYXJyZWwgYW5kIHBvc3RlZCB0byB0aGU8YnI+ DQomZ3Q7IElFVEYgcmVwb3NpdG9yeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBOYW1lOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmll ZC1pcC1zcjxicj4NCiZndDsgUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDE8 YnI+DQomZ3Q7IFRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQSBVbmlm aWVkIEFwcHJvYWNoIHRvIElQIFNlZ21lbnQgUm91dGluZzxicj4NCiZndDsgRG9jdW1lbnQgZGF0 ZTombmJzcDsgMjAxNy0wOC0xMTxicj4NCiZndDsgR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQomZ3Q7IFBhZ2VzOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTY8YnI+DQomZ3Q7IFVSTDo8YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1w bHMtdW5pZmllZC1pcC1zci0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci08L2E+PGJyPg0K Jmd0OyAwMS50eHQ8YnI+DQomZ3Q7IFN0YXR1czo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyeWFu dC1tcGxzLXVuaWZpZWQtaXAtc3IvPC9hPjxicj4NCiZndDsgSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMTwvYT48 YnI+DQomZ3Q7IEh0bWxpemVkOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC0iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJyeWFudC1t cGxzLXVuaWZpZWQtaXAtPC9hPjxicj4NCiZndDsgc3ItMDE8YnI+DQomZ3Q7IERpZmY6PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJyeWFudC1t cGxzLXVuaWZpZWQtaXAtc3ItMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMTwvYT48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBTZWdtZW50 IHJvdXRpbmcgaXMgYSBzb3VyY2Ugcm91dGVkIGZvcndhcmRpbmcgbWV0aG9kIHRoYXQgYWxsb3dz PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgcGFja2V0cyB0byBiZSBzdGVlcmVkIHRocm91Z2ggYSBu ZXR3b3JrIG9uIHBhdGhzIG90aGVyIHRoYW4gdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgc2hv cnRlc3QgcGF0aCBkZXJpdmVkIGZyb20gdGhlIHJvdXRpbmcgcHJvdG9jb2wuJm5ic3A7IFRoZSBh cHByb2FjaCB1c2VzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgaW5mb3JtYXRpb24gZW5jb2RlZCBp biB0aGUgcGFja2V0IGhlYWRlciB0byBwYXJ0aWFsbHkgb3IgY29tcGxldGVseTxicj4NCiZndDsm bmJzcDsgJm5ic3A7IHNwZWNpZnkgdGhlIHJvdXRlIHRoZSBwYWNrZXQgdGFrZXMgdGhyb3VnaCB0 aGUgbmV0d29yaywgYW5kIGRvZXMgbm90PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbWFrZSB1c2Ug b2YgYSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcHJlLWluc3RhbGwgcGF0aHMgaW4gdGhlIG5ldHdv cmsuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IFR3byBkaWZmZXJlbnQgZW5jYXBz dWxhdGlvbnMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gZW5hYmxlIHNlZ21lbnQ8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyByb3V0aW5nIGluIGFuIE1QTFMgbmV0d29yayBhbmQgaW4gYW4gSVB2NiBuZXR3 b3JrLiZuYnNwOyBXaGlsZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGFja25vd2xlZGdpbmcgdGhh dCB0aGVyZSBpcyBhIHN0cm9uZyBuZWVkIHRvIHN1cHBvcnQgc2VnbWVudCByb3V0aW5nPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgaW4gYm90aCBlbnZpcm9ubWVudHMsIHRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhIGNvbnZlcmdlZCwgdW5pZmllZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGFwcHJvYWNo IHRvIHNlZ21lbnQgcm91dGluZyB0aGF0IGVuYWJsZXMgYSBzaW5nbGUgbWVjaGFuaXNtIHRvIGJl PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYXBwbGllZCBpbiBib3RoIHR5cGVzIG9mIG5ldHdvcmsu Jm5ic3A7IFRoZSByZXN1bHRpbmcgYXBwcm9hY2ggaXMgYWxzbzxicj4NCiZndDsmbmJzcDsgJm5i c3A7IGFwcGxpY2FibGUgdG8gSVB2NCBuZXR3b3JrcyB3aXRob3V0IHRoZSBuZWVkIGZvciBhbnkg Y2hhbmdlcyB0byB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJUHY0IHNwZWNpZmljYXRpb24u PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8g Y2hhbmdlcyB0byB0aGUgc2VnbWVudCByb3V0aW5nIGFyY2hpdGVjdHVyZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7IGFuZCBidWlsZHMgb24gZXhpc3RpbmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNo IGFzIHRoZSBlbmNhcHN1bGF0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgb2YgTVBMUyB3aXRo aW4gVURQIGRlZmluZWQgaW4gUkZDIDc1MTAuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7IE5vIG5ldyBwcm9jZWR1cmVzIGFyZSBpbnRyb2R1Y2VkLCBidXQgZXhpc3RpbmcgbWVjaGFu aXNtcyBhcmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBjb21iaW5lZCB0byBhY2hpZXZlIHRoZSBk ZXNpcmVkIHJlc3VsdC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCiZndDsgdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bXBscyBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_48E1A67CB9CA044EADFEAB87D814BFF64B7B6FDBeusaamb107erics_-- From nobody Fri Aug 11 17:21:20 2017 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 55AF3132485 for ; Fri, 11 Aug 2017 17:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kk9VjiSnZehp for ; Fri, 11 Aug 2017 17:21:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1789A13242A for ; Fri, 11 Aug 2017 17:21:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTG17182; Sat, 12 Aug 2017 00:21:13 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 12 Aug 2017 01:21:12 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.181]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 12 Aug 2017 08:21:07 +0800 From: Xuxiaohu To: "adrian@olddog.co.uk" CC: "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAAF7mAg== Date: Sat, 12 Aug 2017 00:21:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF57FC@NKGEML515-MBS.china.huawei.com> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> , <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> In-Reply-To: <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF57FCNKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.598E49F9.00EE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7f1193bff2ac21e787547e3b49bb1987 Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:21:18 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF57FCNKGEML515MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrQ7NChu6INCk2juis4 Ni0xMzkxMDE2MTY5Mg0KRaO6eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVh d2VpLmNvbT4NCrL6xrfT673ivva3vbC4Lc34wufVvcLU0+vStc7xt6LVubK/DQoNCreivP7Iy6O6 IEFkcmlhbiBGYXJyZWwNCsrVvP7Iy6O6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPg0K1vfM4qO6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQrKsbzko7ogMjAxNy0wOC0x MiAwMjo0Nzo0MA0KDQpIaSBhbGwsDQoNClNQUklORyBkaWRuJ3QgbWVldCBpbiBQcmFndWUgc28g SSBwcmVzZW50ZWQgdGhpcyB3b3JrIGluIE1QTFMuIEJydW5vIHN1Z2dlc3RlZA0KdGhhdCBtYXli ZSBTUFJJTkcgd291bGQgYmUgYSBiZXR0ZXIgdmVudWUuDQoNCkknbSBub3Qgc3VyZSBhYm91dCB0 aGF0LCBhbHRob3VnaCBJIGRvIHRoaW5rIGJvdGggV0dzIHNob3VsZCBjaGF0IGFib3V0IHRoZQ0K aWRlYXMuDQoNClRoZSBlc3NlbmNlIG9mIHRoaXMgd29yayBpcyBub3RoaW5nIG1vcmUgdGhhdCBN UExTLVNSIGVuY2Fwc3VsYXRlZCBpbiBVRFAgcGVyDQpSRkMgNzUxMC4gV2hhdCBpdCBhY2hpZXZl cyBpcyBhIHdheSB0byBvYnRhaW4gdGhlIFNSIGZ1bmN0aW9uYWxpdHkgdGhhdCB3ZSBhbGwNCmtu b3cgYW5kIGxvdmUgaW4gYW4gSVAgbmV0d29yay4NCg0KVGhlIGFwcHJvYWNoIGlzLCBvZiBjb3Vy c2UsIGNvbXBhdGlibGUgd2l0aCBNUExTLVNSLiBBcyB0aGUgZHJhZnQgc2F5cy4uLg0KDQogICBU aGlzIGRvY3VtZW50IG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhlIHNlZ21lbnQgcm91dGluZyBhcmNo aXRlY3R1cmUNCiAgIGFuZCBidWlsZHMgb24gZXhpc3RpbmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBz dWNoIGFzIHRoZSBlbmNhcHN1bGF0aW9uDQogICBvZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBp biBSRkMgNzUxMC4NCg0KICAgTm8gbmV3IHByb2NlZHVyZXMgYXJlIGludHJvZHVjZWQsIGJ1dCBl eGlzdGluZyBtZWNoYW5pc21zIGFyZQ0KICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJl ZCByZXN1bHQuDQoNClRoaXMgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgYmVhdXR5IGNvbnRlc3Qg d2l0aCBTUnY2LiBBcyB0aGUgZHJhZnQgc2F5cy4uLg0KDQogICBUaGUgbWV0aG9kIGRlZmluZWQg aXMgYSBjb21wbGVtZW50YXJ5IHdheSBvZiBydW5uaW5nIFNSIGluIGFuIElQDQogICBuZXR3b3Jr IHRoYXQgY2FuIGJlIHVzZWQgYWxvbmdzaWRlIG9yIGludGVyY2hhbmdlYWJseSB3aXRoIHRoYXQN CiAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcl0uICBJ bXBsZW1lbnRlcnMgYW5kDQogICBkZXBsb3llcnMgc2hvdWxkIGNvbnNpZGVyIHRoZSBiZW5lZml0 cyBhbmQgZHJhd2JhY2tzIG9mIGVhY2ggbWV0aG9kDQogICBhbmQgc2VsZWN0IHRoZSBhcHByb2Fj aCBtb3N0IHN1aXRlZCB0byB0aGVpciBuZWVkcy4NCg0KVGhhbmtzLA0KQWRyaWFuDQoNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcNCj4gU2VudDogMTEgQXVndXN0IDIwMTcgMTk6Mzk6NTkgKFVUQyswMDow MCkgRHVibGluLCBFZGluYnVyZ2gsIExpc2JvbiwgTG9uZG9uDQo+IFRvOiBTdGV3YXJ0IEJyeWFu dDsgSm9obiBFIERyYWtlOyBBZHJpYW4gRmFycmVsDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCj4N Cj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3It MDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRyaWFuIEZhcnJl bCBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+DQo+IE5hbWU6ICAgICAg ICAgICBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyDQo+IFJldmlzaW9uOiAgICAgICAw MQ0KPiBUaXRsZTogICAgICAgICAgQSBVbmlmaWVkIEFwcHJvYWNoIHRvIElQIFNlZ21lbnQgUm91 dGluZw0KPiBEb2N1bWVudCBkYXRlOiAgMjAxNy0wOC0xMQ0KPiBHcm91cDogICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAgICAgICAxNg0KPiBVUkw6DQpodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1p cC1zci0NCj4gMDEudHh0DQo+IFN0YXR1czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3IvDQo+IEh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1z ci0wMQ0KPiBIdG1saXplZDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC0NCj4gc3ItMDENCj4gRGlmZjoNCmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNy LTAxDQo+DQo+IEFic3RyYWN0Og0KPiAgICBTZWdtZW50IHJvdXRpbmcgaXMgYSBzb3VyY2Ugcm91 dGVkIGZvcndhcmRpbmcgbWV0aG9kIHRoYXQgYWxsb3dzDQo+ICAgIHBhY2tldHMgdG8gYmUgc3Rl ZXJlZCB0aHJvdWdoIGEgbmV0d29yayBvbiBwYXRocyBvdGhlciB0aGFuIHRoZQ0KPiAgICBzaG9y dGVzdCBwYXRoIGRlcml2ZWQgZnJvbSB0aGUgcm91dGluZyBwcm90b2NvbC4gIFRoZSBhcHByb2Fj aCB1c2VzDQo+ICAgIGluZm9ybWF0aW9uIGVuY29kZWQgaW4gdGhlIHBhY2tldCBoZWFkZXIgdG8g cGFydGlhbGx5IG9yIGNvbXBsZXRlbHkNCj4gICAgc3BlY2lmeSB0aGUgcm91dGUgdGhlIHBhY2tl dCB0YWtlcyB0aHJvdWdoIHRoZSBuZXR3b3JrLCBhbmQgZG9lcyBub3QNCj4gICAgbWFrZSB1c2Ug b2YgYSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcHJlLWluc3RhbGwgcGF0aHMgaW4gdGhlIG5ldHdv cmsuDQo+DQo+ICAgIFR3byBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMgaGF2ZSBiZWVuIGRlZmlu ZWQgdG8gZW5hYmxlIHNlZ21lbnQNCj4gICAgcm91dGluZyBpbiBhbiBNUExTIG5ldHdvcmsgYW5k IGluIGFuIElQdjYgbmV0d29yay4gIFdoaWxlDQo+ICAgIGFja25vd2xlZGdpbmcgdGhhdCB0aGVy ZSBpcyBhIHN0cm9uZyBuZWVkIHRvIHN1cHBvcnQgc2VnbWVudCByb3V0aW5nDQo+ICAgIGluIGJv dGggZW52aXJvbm1lbnRzLCB0aGlzIGRvY3VtZW50IGRlZmluZXMgYSBjb252ZXJnZWQsIHVuaWZp ZWQNCj4gICAgYXBwcm9hY2ggdG8gc2VnbWVudCByb3V0aW5nIHRoYXQgZW5hYmxlcyBhIHNpbmds ZSBtZWNoYW5pc20gdG8gYmUNCj4gICAgYXBwbGllZCBpbiBib3RoIHR5cGVzIG9mIG5ldHdvcmsu ICBUaGUgcmVzdWx0aW5nIGFwcHJvYWNoIGlzIGFsc28NCj4gICAgYXBwbGljYWJsZSB0byBJUHY0 IG5ldHdvcmtzIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFueSBjaGFuZ2VzIHRvIHRoZQ0KPiAgICBJ UHY0IHNwZWNpZmljYXRpb24uDQo+DQo+ICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hhbmdl cyB0byB0aGUgc2VnbWVudCByb3V0aW5nIGFyY2hpdGVjdHVyZQ0KPiAgICBhbmQgYnVpbGRzIG9u IGV4aXN0aW5nIHByb3RvY29sIG1lY2hhbmlzbXMgc3VjaCBhcyB0aGUgZW5jYXBzdWxhdGlvbg0K PiAgICBvZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCj4NCj4gICAgTm8g bmV3IHByb2NlZHVyZXMgYXJlIGludHJvZHVjZWQsIGJ1dCBleGlzdGluZyBtZWNoYW5pc21zIGFy ZQ0KPiAgICBjb21iaW5lZCB0byBhY2hpZXZlIHRoZSBkZXNpcmVkIHJlc3VsdC4NCj4NCj4NCj4N Cj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPiBUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF57FCNKGEML515MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable





=D0=EC=D0=A1=BB=A2
M=A3=BA+86-13910161692  
E=A3=BAxuxiaohu@huawei.com
=B2=FA=C6=B7=D3=EB=BD=E2=BE=F6=B7=BD=B0=B8-=CD=F8=C2=E7=D5=BD=C2=D4=D3=EB= =D2=B5=CE=F1=B7=A2=D5=B9=B2=BF

=B7=A2=BC=FE=C8=CB=A3=BA Adrian Farrel
=CA=D5=BC=FE=C8=CB=A3=BA spr= ing@ietf.org
=D6=F7=CC=E2=A3=BA [spring] FW: New Version Notification for dr= aft-bryant-mpls-unified-ip-sr-01.txt
=CA=B1=BC=E4=A3=BA 2017-08-12 02:47:40

Hi all,

SPRING didn't meet in Prague so I presented this work in MPLS. Bruno sugges= ted
that maybe SPRING would be a better venue.

I'm not sure about that, although I do think both WGs should chat about the=
ideas.

The essence of this work is nothing more that MPLS-SR encapsulated in UDP p= er
RFC 7510. What it achieves is a way to obtain the SR functionality that we = all
know and love in an IP network.

The approach is, of course, compatible with MPLS-SR. As the draft says...
   This document makes no changes to the segment routing architec= ture
   and builds on existing protocol mechanisms such as the encapsu= lation
   of MPLS within UDP defined in RFC 7510.

   No new procedures are introduced, but existing mechanisms are<= br>    combined to achieve the desired result.

This is not intended to be a beauty contest with SRv6. As the draft says...=

   The method defined is a complementary way of running SR in an = IP
   network that can be used alongside or interchangeably with tha= t
   defined in [I-D.ietf-6man-segment-routing-header].  Imple= menters and
   deployers should consider the benefits and drawbacks of each m= ethod
   and select the approach most suited to their needs.

Thanks,
Adrian

> ________________________________________
> From: internet-drafts@ietf.org
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbo= n, London
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-= 01.txt
>
> A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Name:           draf= t-bryant-mpls-unified-ip-sr
> Revision:       01
> Title:          A Unified= Approach to IP Segment Routing
> Document date:  2017-08-11
> Group:          Individua= l Submission
> Pages:          16
> URL:
https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr= -
> 01.txt
> Status:
https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ > Htmlized:       https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-bryant-mpls-unified-ip-sr= -01
>
> Abstract:
>    Segment routing is a source routed forwarding method= that allows
>    packets to be steered through a network on paths oth= er than the
>    shortest path derived from the routing protocol.&nbs= p; The approach uses
>    information encoded in the packet header to partiall= y or completely
>    specify the route the packet takes through the netwo= rk, and does not
>    make use of a signaling protocol to pre-install path= s in the network.
>
>    Two different encapsulations have been defined to en= able segment
>    routing in an MPLS network and in an IPv6 network.&n= bsp; While
>    acknowledging that there is a strong need to support= segment routing
>    in both environments, this document defines a conver= ged, unified
>    approach to segment routing that enables a single me= chanism to be
>    applied in both types of network.  The resultin= g approach is also
>    applicable to IPv4 networks without the need for any= changes to the
>    IPv4 specification.
>
>    This document makes no changes to the segment routin= g architecture
>    and builds on existing protocol mechanisms such as t= he encapsulation
>    of MPLS within UDP defined in RFC 7510.
>
>    No new procedures are introduced, but existing mecha= nisms are
>    combined to achieve the desired result.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring
 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF57FCNKGEML515MBSchi_-- From nobody Fri Aug 11 17:23:23 2017 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 3E1CE132412 for ; Fri, 11 Aug 2017 17:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jqc2t5CWKQ77 for ; Fri, 11 Aug 2017 17:23:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468D3132449 for ; Fri, 11 Aug 2017 17:23:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTG17319; Sat, 12 Aug 2017 00:23:17 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 12 Aug 2017 01:23:16 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.181]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 12 Aug 2017 08:23:12 +0800 From: Xuxiaohu To: "adrian@olddog.co.uk" CC: "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAAF96SQ== Date: Sat, 12 Aug 2017 00:23:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF5847@NKGEML515-MBS.china.huawei.com> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> , <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> In-Reply-To: <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF5847NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.598E4A75.0146, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7f1193bff2ac21e787547e3b49bb1987 Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:23:22 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF5847NKGEML515MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QWRyaWFuIGFuZCBTdGV3YXJ0o6wNCg0KDQpXaGVuIHlvdSBzdWJtaXR0ZWQgdGhlIC0wMCB2ZXJz aW9uIG9mIHRoaXMgZHJhZnQgd2l0aCBteSBuYW1lIGJlaW5nIGxpc3RlZCBpbiB0aGUgY29hdXRo b3IgbGlzdCBidXQgd2l0aG91dCBteSBwZXJtaXNzaW9uLCBJIHRvbGVyYXRlZCBpdCBzbyBhcyB0 byBnaXZlIGZhY2UgdG8geW91LCBhbHRob3VnaCBpdCBoYWQgY2F1c2VkIHVubmVjZXNzYXJ5IGNv bmZ1c2lvbiBpbiB0aGUgSUVURiwgZXNwZWNpYWxseSBhbW9uZyB0aGUgY29hdXRob3JzIG9mIGRy YWZ0LXh1LW1wbHMtdW5pZmllZC1zb3VyY2Utcm91dGluZy1pbnN0cnVjdGlvbi4NCg0KDQpUaGlz IHRpbWUgeW91IHN1Ym1pdHRlZCAtMDEgdmVyc2lvbiB3aXRoIG15IG5hbWUgYmVpbmcgYWRkZWQg aW50byB0aGUgY29udHJpYnV0b3IgbGlzdCBidXQgd2l0aG91dCBteSBwZXJtaXNzaW9uIGFzIHdl bGwuIEkgaGF2ZSB0byByZW1pbmQgeW91OiBkb24ndCByZXBlYXQgc3VjaCBpbXBvbGl0ZSBhY3Rp b25zLg0KDQoNCiBYaWFvaHUNCg0KDQoNCreivP7Iy6O6IEFkcmlhbiBGYXJyZWwNCsrVvP7Iy6O6 IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K1vfM4qO6IFtzcHJpbmdd IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZp ZWQtaXAtc3ItMDEudHh0DQrKsbzko7ogMjAxNy0wOC0xMiAwMjo0Nzo0MA0KDQpIaSBhbGwsDQoN ClNQUklORyBkaWRuJ3QgbWVldCBpbiBQcmFndWUgc28gSSBwcmVzZW50ZWQgdGhpcyB3b3JrIGlu IE1QTFMuIEJydW5vIHN1Z2dlc3RlZA0KdGhhdCBtYXliZSBTUFJJTkcgd291bGQgYmUgYSBiZXR0 ZXIgdmVudWUuDQoNCkknbSBub3Qgc3VyZSBhYm91dCB0aGF0LCBhbHRob3VnaCBJIGRvIHRoaW5r IGJvdGggV0dzIHNob3VsZCBjaGF0IGFib3V0IHRoZQ0KaWRlYXMuDQoNClRoZSBlc3NlbmNlIG9m IHRoaXMgd29yayBpcyBub3RoaW5nIG1vcmUgdGhhdCBNUExTLVNSIGVuY2Fwc3VsYXRlZCBpbiBV RFAgcGVyDQpSRkMgNzUxMC4gV2hhdCBpdCBhY2hpZXZlcyBpcyBhIHdheSB0byBvYnRhaW4gdGhl IFNSIGZ1bmN0aW9uYWxpdHkgdGhhdCB3ZSBhbGwNCmtub3cgYW5kIGxvdmUgaW4gYW4gSVAgbmV0 d29yay4NCg0KVGhlIGFwcHJvYWNoIGlzLCBvZiBjb3Vyc2UsIGNvbXBhdGlibGUgd2l0aCBNUExT LVNSLiBBcyB0aGUgZHJhZnQgc2F5cy4uLg0KDQogICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIGNo YW5nZXMgdG8gdGhlIHNlZ21lbnQgcm91dGluZyBhcmNoaXRlY3R1cmUNCiAgIGFuZCBidWlsZHMg b24gZXhpc3RpbmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBlbmNhcHN1bGF0aW9u DQogICBvZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCg0KICAgTm8gbmV3 IHByb2NlZHVyZXMgYXJlIGludHJvZHVjZWQsIGJ1dCBleGlzdGluZyBtZWNoYW5pc21zIGFyZQ0K ICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCByZXN1bHQuDQoNClRoaXMgaXMgbm90 IGludGVuZGVkIHRvIGJlIGEgYmVhdXR5IGNvbnRlc3Qgd2l0aCBTUnY2LiBBcyB0aGUgZHJhZnQg c2F5cy4uLg0KDQogICBUaGUgbWV0aG9kIGRlZmluZWQgaXMgYSBjb21wbGVtZW50YXJ5IHdheSBv ZiBydW5uaW5nIFNSIGluIGFuIElQDQogICBuZXR3b3JrIHRoYXQgY2FuIGJlIHVzZWQgYWxvbmdz aWRlIG9yIGludGVyY2hhbmdlYWJseSB3aXRoIHRoYXQNCiAgIGRlZmluZWQgaW4gW0ktRC5pZXRm LTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcl0uICBJbXBsZW1lbnRlcnMgYW5kDQogICBkZXBs b3llcnMgc2hvdWxkIGNvbnNpZGVyIHRoZSBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIG9mIGVhY2gg bWV0aG9kDQogICBhbmQgc2VsZWN0IHRoZSBhcHByb2FjaCBtb3N0IHN1aXRlZCB0byB0aGVpciBu ZWVkcy4NCg0KVGhhbmtzLA0KQWRyaWFuDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gU2VudDog MTEgQXVndXN0IDIwMTcgMTk6Mzk6NTkgKFVUQyswMDowMCkgRHVibGluLCBFZGluYnVyZ2gsIExp c2JvbiwgTG9uZG9uDQo+IFRvOiBTdGV3YXJ0IEJyeWFudDsgSm9obiBFIERyYWtlOyBBZHJpYW4g RmFycmVsDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJ5 YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCj4NCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRyaWFuIEZhcnJlbCBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJ RVRGIHJlcG9zaXRvcnkuDQo+DQo+IE5hbWU6ICAgICAgICAgICBkcmFmdC1icnlhbnQtbXBscy11 bmlmaWVkLWlwLXNyDQo+IFJldmlzaW9uOiAgICAgICAwMQ0KPiBUaXRsZTogICAgICAgICAgQSBV bmlmaWVkIEFwcHJvYWNoIHRvIElQIFNlZ21lbnQgUm91dGluZw0KPiBEb2N1bWVudCBkYXRlOiAg MjAxNy0wOC0xMQ0KPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBh Z2VzOiAgICAgICAgICAxNg0KPiBVUkw6DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0NCj4gMDEudHh0DQo+IFN0YXR1 czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyeWFudC1tcGxzLXVu aWZpZWQtaXAtc3IvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMQ0KPiBIdG1saXplZDoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmll ZC1pcC0NCj4gc3ItMDENCj4gRGlmZjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxDQo+DQo+IEFic3RyYWN0Og0KPiAg ICBTZWdtZW50IHJvdXRpbmcgaXMgYSBzb3VyY2Ugcm91dGVkIGZvcndhcmRpbmcgbWV0aG9kIHRo YXQgYWxsb3dzDQo+ICAgIHBhY2tldHMgdG8gYmUgc3RlZXJlZCB0aHJvdWdoIGEgbmV0d29yayBv biBwYXRocyBvdGhlciB0aGFuIHRoZQ0KPiAgICBzaG9ydGVzdCBwYXRoIGRlcml2ZWQgZnJvbSB0 aGUgcm91dGluZyBwcm90b2NvbC4gIFRoZSBhcHByb2FjaCB1c2VzDQo+ICAgIGluZm9ybWF0aW9u IGVuY29kZWQgaW4gdGhlIHBhY2tldCBoZWFkZXIgdG8gcGFydGlhbGx5IG9yIGNvbXBsZXRlbHkN Cj4gICAgc3BlY2lmeSB0aGUgcm91dGUgdGhlIHBhY2tldCB0YWtlcyB0aHJvdWdoIHRoZSBuZXR3 b3JrLCBhbmQgZG9lcyBub3QNCj4gICAgbWFrZSB1c2Ugb2YgYSBzaWduYWxpbmcgcHJvdG9jb2wg dG8gcHJlLWluc3RhbGwgcGF0aHMgaW4gdGhlIG5ldHdvcmsuDQo+DQo+ICAgIFR3byBkaWZmZXJl bnQgZW5jYXBzdWxhdGlvbnMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gZW5hYmxlIHNlZ21lbnQNCj4g ICAgcm91dGluZyBpbiBhbiBNUExTIG5ldHdvcmsgYW5kIGluIGFuIElQdjYgbmV0d29yay4gIFdo aWxlDQo+ICAgIGFja25vd2xlZGdpbmcgdGhhdCB0aGVyZSBpcyBhIHN0cm9uZyBuZWVkIHRvIHN1 cHBvcnQgc2VnbWVudCByb3V0aW5nDQo+ICAgIGluIGJvdGggZW52aXJvbm1lbnRzLCB0aGlzIGRv Y3VtZW50IGRlZmluZXMgYSBjb252ZXJnZWQsIHVuaWZpZWQNCj4gICAgYXBwcm9hY2ggdG8gc2Vn bWVudCByb3V0aW5nIHRoYXQgZW5hYmxlcyBhIHNpbmdsZSBtZWNoYW5pc20gdG8gYmUNCj4gICAg YXBwbGllZCBpbiBib3RoIHR5cGVzIG9mIG5ldHdvcmsuICBUaGUgcmVzdWx0aW5nIGFwcHJvYWNo IGlzIGFsc28NCj4gICAgYXBwbGljYWJsZSB0byBJUHY0IG5ldHdvcmtzIHdpdGhvdXQgdGhlIG5l ZWQgZm9yIGFueSBjaGFuZ2VzIHRvIHRoZQ0KPiAgICBJUHY0IHNwZWNpZmljYXRpb24uDQo+DQo+ ICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hhbmdlcyB0byB0aGUgc2VnbWVudCByb3V0aW5n IGFyY2hpdGVjdHVyZQ0KPiAgICBhbmQgYnVpbGRzIG9uIGV4aXN0aW5nIHByb3RvY29sIG1lY2hh bmlzbXMgc3VjaCBhcyB0aGUgZW5jYXBzdWxhdGlvbg0KPiAgICBvZiBNUExTIHdpdGhpbiBVRFAg ZGVmaW5lZCBpbiBSRkMgNzUxMC4NCj4NCj4gICAgTm8gbmV3IHByb2NlZHVyZXMgYXJlIGludHJv ZHVjZWQsIGJ1dCBleGlzdGluZyBtZWNoYW5pc21zIGFyZQ0KPiAgICBjb21iaW5lZCB0byBhY2hp ZXZlIHRoZSBkZXNpcmVkIHJlc3VsdC4NCj4NCj4NCj4NCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcg bGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF5847NKGEML515MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Adrian and Stewart=A3=AC


When you submitted the -00 version of th= is draft with my name being listed in&nb= sp;the coauthor list but without my permissio= n, I tolerated it so as to give fac= e to you, although it had caused unneces= sary confusion in the IETF, especially among&= nbsp;the coauthors of draft-xu-mpls-unified-source-routing-i= nstruction.


This time you submitted -01 version with = ;my name being added into the contributor&nbs= p;list but without my permission as well.&nbs= p;I have to remind you: don't repeat suc= h impolite actions.


 Xiaohu



=B7=A2=BC=FE=C8=CB=A3=BA Adrian Farrel
=CA=D5=BC=FE=C8=CB=A3=BA spr= ing@ietf.org
=D6=F7=CC=E2=A3=BA [spring] FW: New Version Notification for dr= aft-bryant-mpls-unified-ip-sr-01.txt
=CA=B1=BC=E4=A3=BA 2017-08-12 02:47:40

Hi all,

SPRING didn't meet in Prague so I presented this work in MPLS. Bruno sugges= ted
that maybe SPRING would be a better venue.

I'm not sure about that, although I do think both WGs should chat about the=
ideas.

The essence of this work is nothing more that MPLS-SR encapsulated in UDP p= er
RFC 7510. What it achieves is a way to obtain the SR functionality that we = all
know and love in an IP network.

The approach is, of course, compatible with MPLS-SR. As the draft says...
   This document makes no changes to the segment routing architec= ture
   and builds on existing protocol mechanisms such as the encapsu= lation
   of MPLS within UDP defined in RFC 7510.

   No new procedures are introduced, but existing mechanisms are<= br>    combined to achieve the desired result.

This is not intended to be a beauty contest with SRv6. As the draft says...=

   The method defined is a complementary way of running SR in an = IP
   network that can be used alongside or interchangeably with tha= t
   defined in [I-D.ietf-6man-segment-routing-header].  Imple= menters and
   deployers should consider the benefits and drawbacks of each m= ethod
   and select the approach most suited to their needs.

Thanks,
Adrian

> ________________________________________
> From: internet-drafts@ietf.org
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbo= n, London
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-= 01.txt
>
> A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Name:           draf= t-bryant-mpls-unified-ip-sr
> Revision:       01
> Title:          A Unified= Approach to IP Segment Routing
> Document date:  2017-08-11
> Group:          Individua= l Submission
> Pages:          16
> URL:
https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr= -
> 01.txt
> Status:
https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ > Htmlized:       https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-bryant-mpls-unified-ip-sr= -01
>
> Abstract:
>    Segment routing is a source routed forwarding method= that allows
>    packets to be steered through a network on paths oth= er than the
>    shortest path derived from the routing protocol.&nbs= p; The approach uses
>    information encoded in the packet header to partiall= y or completely
>    specify the route the packet takes through the netwo= rk, and does not
>    make use of a signaling protocol to pre-install path= s in the network.
>
>    Two different encapsulations have been defined to en= able segment
>    routing in an MPLS network and in an IPv6 network.&n= bsp; While
>    acknowledging that there is a strong need to support= segment routing
>    in both environments, this document defines a conver= ged, unified
>    approach to segment routing that enables a single me= chanism to be
>    applied in both types of network.  The resultin= g approach is also
>    applicable to IPv4 networks without the need for any= changes to the
>    IPv4 specification.
>
>    This document makes no changes to the segment routin= g architecture
>    and builds on existing protocol mechanisms such as t= he encapsulation
>    of MPLS within UDP defined in RFC 7510.
>
>    No new procedures are introduced, but existing mecha= nisms are
>    combined to achieve the desired result.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring
 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBF5847NKGEML515MBSchi_-- From nobody Sun Aug 13 18:55:00 2017 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 BFC75133D76 for ; Sun, 13 Aug 2017 18:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 mwa-GUqkRhFh for ; Sun, 13 Aug 2017 18:54:56 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0100.outbound.protection.outlook.com [104.47.2.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8366313475F for ; Sun, 13 Aug 2017 18:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GZSJuH1B5LENcVM6W0l/FlXH5srobFEFJpIOJ0FCjJ8=; b=JlsPHS0+6PDaO94FVwMNRMxNz3QP8HtG6E2W2lvAKuGbx7XucBmPYHMwHXQBeFLGsNrOlPqt3jxB/lj8HlEIyFwlWa55msaXGvVfCT6KWH0ZccTTSQvzEwWG4a8EkgtNTidRob+Fstm2Sg3pedZFbDG2MaRDYnwwtz2Ky2A7sWU= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0834.eurprd07.prod.outlook.com (10.161.71.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Mon, 14 Aug 2017 01:54:51 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651%14]) with mapi id 15.01.1362.012; Mon, 14 Aug 2017 01:54:51 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAA79GAA== Date: Mon, 14 Aug 2017 01:54:51 +0000 Message-ID: <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> In-Reply-To: <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170725 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [135.245.212.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0834; 6:8wkD66sM7FRx7fnAej8v2qTF6rQ/uuSmS+OlnuSUTKDJyNwjziI4v99c66ElDa0AKF7iZnEg7XV5MxbNOLZa/Hj65wKxkqtIwmEK7QiysX4Mw4E2+2JxVDUKH5fjuO7Ox9l4Z1+ytzapr8jiTlRlaUTzTG6ZPuLtPMg7PNAveoNQcWItTjiJFkgpU8nkJyFXZZantMIDmPol+6l6xLuUNd3yoKGthFG39XDkXq2devALMXC+zbJQvzM7JUxMoF8BHBfpBLKaq0YVHmWapFu4AXKIFEyN+Fck1EOMJ0pNUtgDsW6+WV+WTayMuw6yb6g/yITMNwPc3k07oiaO53OtfQ==; 5:caBUV9+vJdt1vCyln1AnpML8kWLVeKHxt7FFJ6p+bZMVagveZfmGtAOMkMH1UfwowzNaoAL8nhVi+Gsp/ZxghSivlePBc7ve24+qgQmScAKFAnK6yenbyaPXEz5wD36+eJggnvPc8XKjF3wnHtKrxg==; 24:ce3Zqa3CZL7+bIGg0e0JWKHPxYOvGYrhAIuTRNQpUVZto34LKukt9XJdoaGo99M81st070VdesoVH7+HArfeBAp59jIxzpG/f77AnN7a+1I=; 7:PJkrJ4Tu1z7hQhNkuKBgPzZcHCKZWmCaHRgoz4RBtOI2EjfejHxs5l6IGLneWlrWttxjiaei89qNKGZrQp0kkJCFT18wuKHU2J+EGyAdfo3nS/Z+hEpYMc8Ta8v2O/oaaKQSEx1qMuB0RcVsrtghZrU9+TIyQrDO/ei5MccFDmS7uBqzVxbAv5jPctfkHAVqi05gKajrgOq+37MN482PWVWU2TzYpVaTuckAa3Y95Eg= x-ms-office365-filtering-correlation-id: 3ea7ea21-299c-4381-5e40-08d4e2b773b7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0834; x-ms-traffictypediagnostic: AM2PR07MB0834: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0834; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0834; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(24454002)(199003)(53754006)(377424004)(83506001)(6246003)(83716003)(81156014)(2501003)(5250100002)(68736007)(3846002)(6116002)(106356001)(105586002)(36756003)(102836003)(966005)(53546010)(81166006)(53936002)(478600001)(5660300001)(14454004)(97736004)(4001350100001)(82746002)(7736002)(6306002)(6512007)(99286003)(8676002)(8936002)(305945005)(6436002)(25786009)(101416001)(189998001)(6486002)(6506006)(229853002)(2900100001)(33656002)(50986999)(76176999)(54356999)(2906002)(2950100002)(3280700002)(15650500001)(230783001)(3660700001)(86362001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0834; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 01:54:51.3278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0834 Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 01:54:59 -0000 VGhlIGRyYWZ0IG9ubHkgZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBTUm9JUCBFMkUsIHdoeSBkb27i gJl0IHdlIGVudmlzaW9uIFNSb0lQIHRvIEludGVyd29yayB3aXRoIG5hdGl2ZSBNUExTLVNSLg0K V2hhdCBJIG1lYW4gaXMgd2hlbiB1c2luZyB0aGUgU1JvSVAgcHJvY2VkdXJlcyB0aGUgZHJhZnQg dXNlcyBTUm9JUCBhdCBldmVyeSBob3Agd2hpY2ggaXMgU1IgY2FwYWJsZS4NCllvdSBjb3VsZCBl bnZpc2lvbiBjZXJ0YWluIHNlZ21lbnRzIHRvIGRvIFNSb0lQIGFuZCBvdGhlciBzZWdtZW50cyB0 byBoYXZlIG5hdGl2ZSBNUExTLVNSIGNhcGFiaWxpdHkuDQoNClNvIG15IHF1ZXN0aW9uIGlzIHRo aXMgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdD8NCg0KT24gMTEvMDgvMjAxNywgMjA6NDcsICJzcHJp bmcgb24gYmVoYWxmIG9mIEFkcmlhbiBGYXJyZWwiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgYWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQog ICAgDQogICAgU1BSSU5HIGRpZG4ndCBtZWV0IGluIFByYWd1ZSBzbyBJIHByZXNlbnRlZCB0aGlz IHdvcmsgaW4gTVBMUy4gQnJ1bm8gc3VnZ2VzdGVkDQogICAgdGhhdCBtYXliZSBTUFJJTkcgd291 bGQgYmUgYSBiZXR0ZXIgdmVudWUuDQogICAgDQogICAgSSdtIG5vdCBzdXJlIGFib3V0IHRoYXQs IGFsdGhvdWdoIEkgZG8gdGhpbmsgYm90aCBXR3Mgc2hvdWxkIGNoYXQgYWJvdXQgdGhlDQogICAg aWRlYXMuDQogICAgDQogICAgVGhlIGVzc2VuY2Ugb2YgdGhpcyB3b3JrIGlzIG5vdGhpbmcgbW9y ZSB0aGF0IE1QTFMtU1IgZW5jYXBzdWxhdGVkIGluIFVEUCBwZXINCiAgICBSRkMgNzUxMC4gV2hh dCBpdCBhY2hpZXZlcyBpcyBhIHdheSB0byBvYnRhaW4gdGhlIFNSIGZ1bmN0aW9uYWxpdHkgdGhh dCB3ZSBhbGwNCiAgICBrbm93IGFuZCBsb3ZlIGluIGFuIElQIG5ldHdvcmsuDQogICAgDQogICAg VGhlIGFwcHJvYWNoIGlzLCBvZiBjb3Vyc2UsIGNvbXBhdGlibGUgd2l0aCBNUExTLVNSLiBBcyB0 aGUgZHJhZnQgc2F5cy4uLg0KICAgIA0KICAgICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hh bmdlcyB0byB0aGUgc2VnbWVudCByb3V0aW5nIGFyY2hpdGVjdHVyZQ0KICAgICAgIGFuZCBidWls ZHMgb24gZXhpc3RpbmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBlbmNhcHN1bGF0 aW9uDQogICAgICAgb2YgTVBMUyB3aXRoaW4gVURQIGRlZmluZWQgaW4gUkZDIDc1MTAuDQogICAg DQogICAgICAgTm8gbmV3IHByb2NlZHVyZXMgYXJlIGludHJvZHVjZWQsIGJ1dCBleGlzdGluZyBt ZWNoYW5pc21zIGFyZQ0KICAgICAgIGNvbWJpbmVkIHRvIGFjaGlldmUgdGhlIGRlc2lyZWQgcmVz dWx0Lg0KICAgIA0KICAgIFRoaXMgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgYmVhdXR5IGNvbnRl c3Qgd2l0aCBTUnY2LiBBcyB0aGUgZHJhZnQgc2F5cy4uLg0KICAgIA0KICAgICAgIFRoZSBtZXRo b2QgZGVmaW5lZCBpcyBhIGNvbXBsZW1lbnRhcnkgd2F5IG9mIHJ1bm5pbmcgU1IgaW4gYW4gSVAN CiAgICAgICBuZXR3b3JrIHRoYXQgY2FuIGJlIHVzZWQgYWxvbmdzaWRlIG9yIGludGVyY2hhbmdl YWJseSB3aXRoIHRoYXQNCiAgICAgICBkZWZpbmVkIGluIFtJLUQuaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy1oZWFkZXJdLiAgSW1wbGVtZW50ZXJzIGFuZA0KICAgICAgIGRlcGxveWVycyBzaG91 bGQgY29uc2lkZXIgdGhlIGJlbmVmaXRzIGFuZCBkcmF3YmFja3Mgb2YgZWFjaCBtZXRob2QNCiAg ICAgICBhbmQgc2VsZWN0IHRoZSBhcHByb2FjaCBtb3N0IHN1aXRlZCB0byB0aGVpciBuZWVkcy4N CiAgICANCiAgICBUaGFua3MsDQogICAgQWRyaWFuDQogICAgDQogICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcNCiAgICA+IFNlbnQ6IDExIEF1Z3VzdCAyMDE3IDE5OjM5OjU5IChVVEMrMDA6MDAp IER1YmxpbiwgRWRpbmJ1cmdoLCBMaXNib24sIExvbmRvbg0KICAgID4gVG86IFN0ZXdhcnQgQnJ5 YW50OyBKb2huIEUgRHJha2U7IEFkcmlhbiBGYXJyZWwNCiAgICA+IFN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50 eHQNCiAgICA+IA0KICAgID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJyeWFudC1tcGxz LXVuaWZpZWQtaXAtc3ItMDEudHh0DQogICAgPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEFkcmlhbiBGYXJyZWwgYW5kIHBvc3RlZCB0byB0aGUNCiAgICA+IElFVEYgcmVwb3Np dG9yeS4NCiAgICA+IA0KICAgID4gTmFtZTogICAgICAgICAgIGRyYWZ0LWJyeWFudC1tcGxzLXVu aWZpZWQtaXAtc3INCiAgICA+IFJldmlzaW9uOiAgICAgICAwMQ0KICAgID4gVGl0bGU6ICAgICAg ICAgIEEgVW5pZmllZCBBcHByb2FjaCB0byBJUCBTZWdtZW50IFJvdXRpbmcNCiAgICA+IERvY3Vt ZW50IGRhdGU6ICAyMDE3LTA4LTExDQogICAgPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQogICAgPiBQYWdlczogICAgICAgICAgMTYNCiAgICA+IFVSTDoNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmll ZC1pcC1zci0NCiAgICA+IDAxLnR4dA0KICAgID4gU3RhdHVzOg0KICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3IvDQogICAg PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyeWFu dC1tcGxzLXVuaWZpZWQtaXAtc3ItMDENCiAgICA+IEh0bWxpemVkOg0KICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC0N CiAgICA+IHNyLTAxDQogICAgPiBEaWZmOg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxDQogICAgPiANCiAgICA+ IEFic3RyYWN0Og0KICAgID4gICAgU2VnbWVudCByb3V0aW5nIGlzIGEgc291cmNlIHJvdXRlZCBm b3J3YXJkaW5nIG1ldGhvZCB0aGF0IGFsbG93cw0KICAgID4gICAgcGFja2V0cyB0byBiZSBzdGVl cmVkIHRocm91Z2ggYSBuZXR3b3JrIG9uIHBhdGhzIG90aGVyIHRoYW4gdGhlDQogICAgPiAgICBz aG9ydGVzdCBwYXRoIGRlcml2ZWQgZnJvbSB0aGUgcm91dGluZyBwcm90b2NvbC4gIFRoZSBhcHBy b2FjaCB1c2VzDQogICAgPiAgICBpbmZvcm1hdGlvbiBlbmNvZGVkIGluIHRoZSBwYWNrZXQgaGVh ZGVyIHRvIHBhcnRpYWxseSBvciBjb21wbGV0ZWx5DQogICAgPiAgICBzcGVjaWZ5IHRoZSByb3V0 ZSB0aGUgcGFja2V0IHRha2VzIHRocm91Z2ggdGhlIG5ldHdvcmssIGFuZCBkb2VzIG5vdA0KICAg ID4gICAgbWFrZSB1c2Ugb2YgYSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcHJlLWluc3RhbGwgcGF0 aHMgaW4gdGhlIG5ldHdvcmsuDQogICAgPiANCiAgICA+ICAgIFR3byBkaWZmZXJlbnQgZW5jYXBz dWxhdGlvbnMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gZW5hYmxlIHNlZ21lbnQNCiAgICA+ICAgIHJv dXRpbmcgaW4gYW4gTVBMUyBuZXR3b3JrIGFuZCBpbiBhbiBJUHY2IG5ldHdvcmsuICBXaGlsZQ0K ICAgID4gICAgYWNrbm93bGVkZ2luZyB0aGF0IHRoZXJlIGlzIGEgc3Ryb25nIG5lZWQgdG8gc3Vw cG9ydCBzZWdtZW50IHJvdXRpbmcNCiAgICA+ICAgIGluIGJvdGggZW52aXJvbm1lbnRzLCB0aGlz IGRvY3VtZW50IGRlZmluZXMgYSBjb252ZXJnZWQsIHVuaWZpZWQNCiAgICA+ICAgIGFwcHJvYWNo IHRvIHNlZ21lbnQgcm91dGluZyB0aGF0IGVuYWJsZXMgYSBzaW5nbGUgbWVjaGFuaXNtIHRvIGJl DQogICAgPiAgICBhcHBsaWVkIGluIGJvdGggdHlwZXMgb2YgbmV0d29yay4gIFRoZSByZXN1bHRp bmcgYXBwcm9hY2ggaXMgYWxzbw0KICAgID4gICAgYXBwbGljYWJsZSB0byBJUHY0IG5ldHdvcmtz IHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFueSBjaGFuZ2VzIHRvIHRoZQ0KICAgID4gICAgSVB2NCBz cGVjaWZpY2F0aW9uLg0KICAgID4gDQogICAgPiAgICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIGNo YW5nZXMgdG8gdGhlIHNlZ21lbnQgcm91dGluZyBhcmNoaXRlY3R1cmUNCiAgICA+ICAgIGFuZCBi dWlsZHMgb24gZXhpc3RpbmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBlbmNhcHN1 bGF0aW9uDQogICAgPiAgICBvZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4N CiAgICA+IA0KICAgID4gICAgTm8gbmV3IHByb2NlZHVyZXMgYXJlIGludHJvZHVjZWQsIGJ1dCBl eGlzdGluZyBtZWNoYW5pc21zIGFyZQ0KICAgID4gICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUg ZGVzaXJlZCByZXN1bHQuDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0K ICAgID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+IA0KICAg ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCiAgICBz cHJpbmdAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZw0KICAgIA0KDQo= From nobody Sun Aug 13 19:58:49 2017 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 C67F312009C for ; Sun, 13 Aug 2017 19:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtf9AAmXOQYk for ; Sun, 13 Aug 2017 19:58:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCE612008A for ; Sun, 13 Aug 2017 19:58:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTJ08652; Mon, 14 Aug 2017 02:58:41 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 14 Aug 2017 03:58:40 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.240]) by SJCEML702-CHM.china.huawei.com ([169.254.4.148]) with mapi id 14.03.0301.000; Sun, 13 Aug 2017 19:58:34 -0700 From: Uma Chunduri To: "Henderickx, Wim (Nokia - BE/Antwerp)" , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAA79GAP//7/Zw Date: Mon, 14 Aug 2017 02:58:33 +0000 Message-ID: <25B4902B1192E84696414485F572685401A3ABA2@SJCEML703-CHM.china.huawei.com> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> In-Reply-To: <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.599111E2.001B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.240, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d94dc72b2553e0b39b86216feee8fd32 Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 02:58:48 -0000 V2ltIC0NCg0KVGhhdCdzIGJlZW4gZGVzY3JpYmVkICBoZXJlOg0KDQpodHRwczovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC14dS1tcGxzLXVuaWZpZWQtc291cmNlLXJvdXRpbmctaW5zdHJ1Y3Rpb24t MDMudHh0DQoNCi0tDQpVbWEgQy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVu ZGVyaWNreCwgV2ltIChOb2tpYSAtIEJFL0FudHdlcnApDQpTZW50OiBTdW5kYXksIEF1Z3VzdCAx MywgMjAxNyA2OjU1IFBNDQpUbzogYWRyaWFuQG9sZGRvZy5jby51azsgc3ByaW5nQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCg0KVGhlIGRyYWZ0IG9ubHkg ZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBTUm9JUCBFMkUsIHdoeSBkb27igJl0IHdlIGVudmlzaW9u IFNSb0lQIHRvIEludGVyd29yayB3aXRoIG5hdGl2ZSBNUExTLVNSLg0KV2hhdCBJIG1lYW4gaXMg d2hlbiB1c2luZyB0aGUgU1JvSVAgcHJvY2VkdXJlcyB0aGUgZHJhZnQgdXNlcyBTUm9JUCBhdCBl dmVyeSBob3Agd2hpY2ggaXMgU1IgY2FwYWJsZS4NCllvdSBjb3VsZCBlbnZpc2lvbiBjZXJ0YWlu IHNlZ21lbnRzIHRvIGRvIFNSb0lQIGFuZCBvdGhlciBzZWdtZW50cyB0byBoYXZlIG5hdGl2ZSBN UExTLVNSIGNhcGFiaWxpdHkuDQoNClNvIG15IHF1ZXN0aW9uIGlzIHRoaXMgaW4gc2NvcGUgb2Yg dGhpcyBkcmFmdD8NCg0KT24gMTEvMDgvMjAxNywgMjA6NDcsICJzcHJpbmcgb24gYmVoYWxmIG9m IEFkcmlhbiBGYXJyZWwiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWRy aWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQogICAgDQogICAgU1BSSU5H IGRpZG4ndCBtZWV0IGluIFByYWd1ZSBzbyBJIHByZXNlbnRlZCB0aGlzIHdvcmsgaW4gTVBMUy4g QnJ1bm8gc3VnZ2VzdGVkDQogICAgdGhhdCBtYXliZSBTUFJJTkcgd291bGQgYmUgYSBiZXR0ZXIg dmVudWUuDQogICAgDQogICAgSSdtIG5vdCBzdXJlIGFib3V0IHRoYXQsIGFsdGhvdWdoIEkgZG8g dGhpbmsgYm90aCBXR3Mgc2hvdWxkIGNoYXQgYWJvdXQgdGhlDQogICAgaWRlYXMuDQogICAgDQog ICAgVGhlIGVzc2VuY2Ugb2YgdGhpcyB3b3JrIGlzIG5vdGhpbmcgbW9yZSB0aGF0IE1QTFMtU1Ig ZW5jYXBzdWxhdGVkIGluIFVEUCBwZXINCiAgICBSRkMgNzUxMC4gV2hhdCBpdCBhY2hpZXZlcyBp cyBhIHdheSB0byBvYnRhaW4gdGhlIFNSIGZ1bmN0aW9uYWxpdHkgdGhhdCB3ZSBhbGwNCiAgICBr bm93IGFuZCBsb3ZlIGluIGFuIElQIG5ldHdvcmsuDQogICAgDQogICAgVGhlIGFwcHJvYWNoIGlz LCBvZiBjb3Vyc2UsIGNvbXBhdGlibGUgd2l0aCBNUExTLVNSLiBBcyB0aGUgZHJhZnQgc2F5cy4u Lg0KICAgIA0KICAgICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hhbmdlcyB0byB0aGUgc2Vn bWVudCByb3V0aW5nIGFyY2hpdGVjdHVyZQ0KICAgICAgIGFuZCBidWlsZHMgb24gZXhpc3Rpbmcg cHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBlbmNhcHN1bGF0aW9uDQogICAgICAgb2Yg TVBMUyB3aXRoaW4gVURQIGRlZmluZWQgaW4gUkZDIDc1MTAuDQogICAgDQogICAgICAgTm8gbmV3 IHByb2NlZHVyZXMgYXJlIGludHJvZHVjZWQsIGJ1dCBleGlzdGluZyBtZWNoYW5pc21zIGFyZQ0K ICAgICAgIGNvbWJpbmVkIHRvIGFjaGlldmUgdGhlIGRlc2lyZWQgcmVzdWx0Lg0KICAgIA0KICAg IFRoaXMgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgYmVhdXR5IGNvbnRlc3Qgd2l0aCBTUnY2LiBB cyB0aGUgZHJhZnQgc2F5cy4uLg0KICAgIA0KICAgICAgIFRoZSBtZXRob2QgZGVmaW5lZCBpcyBh IGNvbXBsZW1lbnRhcnkgd2F5IG9mIHJ1bm5pbmcgU1IgaW4gYW4gSVANCiAgICAgICBuZXR3b3Jr IHRoYXQgY2FuIGJlIHVzZWQgYWxvbmdzaWRlIG9yIGludGVyY2hhbmdlYWJseSB3aXRoIHRoYXQN CiAgICAgICBkZWZpbmVkIGluIFtJLUQuaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJd LiAgSW1wbGVtZW50ZXJzIGFuZA0KICAgICAgIGRlcGxveWVycyBzaG91bGQgY29uc2lkZXIgdGhl IGJlbmVmaXRzIGFuZCBkcmF3YmFja3Mgb2YgZWFjaCBtZXRob2QNCiAgICAgICBhbmQgc2VsZWN0 IHRoZSBhcHByb2FjaCBtb3N0IHN1aXRlZCB0byB0aGVpciBuZWVkcy4NCiAgICANCiAgICBUaGFu a3MsDQogICAgQWRyaWFuDQogICAgDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCiAgICA+ IFNlbnQ6IDExIEF1Z3VzdCAyMDE3IDE5OjM5OjU5IChVVEMrMDA6MDApIER1YmxpbiwgRWRpbmJ1 cmdoLCBMaXNib24sIExvbmRvbg0KICAgID4gVG86IFN0ZXdhcnQgQnJ5YW50OyBKb2huIEUgRHJh a2U7IEFkcmlhbiBGYXJyZWwNCiAgICA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCiAgICA+IA0KICAg ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3It MDEudHh0DQogICAgPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFkcmlhbiBG YXJyZWwgYW5kIHBvc3RlZCB0byB0aGUNCiAgICA+IElFVEYgcmVwb3NpdG9yeS4NCiAgICA+IA0K ICAgID4gTmFtZTogICAgICAgICAgIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3INCiAg ICA+IFJldmlzaW9uOiAgICAgICAwMQ0KICAgID4gVGl0bGU6ICAgICAgICAgIEEgVW5pZmllZCBB cHByb2FjaCB0byBJUCBTZWdtZW50IFJvdXRpbmcNCiAgICA+IERvY3VtZW50IGRhdGU6ICAyMDE3 LTA4LTExDQogICAgPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAg PiBQYWdlczogICAgICAgICAgMTYNCiAgICA+IFVSTDoNCiAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0NCiAgICA+ IDAxLnR4dA0KICAgID4gU3RhdHVzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3IvDQogICAgPiBIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQt aXAtc3ItMDENCiAgICA+IEh0bWxpemVkOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC0NCiAgICA+IHNyLTAxDQog ICAgPiBEaWZmOg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1i cnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxDQogICAgPiANCiAgICA+IEFic3RyYWN0Og0KICAg ID4gICAgU2VnbWVudCByb3V0aW5nIGlzIGEgc291cmNlIHJvdXRlZCBmb3J3YXJkaW5nIG1ldGhv ZCB0aGF0IGFsbG93cw0KICAgID4gICAgcGFja2V0cyB0byBiZSBzdGVlcmVkIHRocm91Z2ggYSBu ZXR3b3JrIG9uIHBhdGhzIG90aGVyIHRoYW4gdGhlDQogICAgPiAgICBzaG9ydGVzdCBwYXRoIGRl cml2ZWQgZnJvbSB0aGUgcm91dGluZyBwcm90b2NvbC4gIFRoZSBhcHByb2FjaCB1c2VzDQogICAg PiAgICBpbmZvcm1hdGlvbiBlbmNvZGVkIGluIHRoZSBwYWNrZXQgaGVhZGVyIHRvIHBhcnRpYWxs eSBvciBjb21wbGV0ZWx5DQogICAgPiAgICBzcGVjaWZ5IHRoZSByb3V0ZSB0aGUgcGFja2V0IHRh a2VzIHRocm91Z2ggdGhlIG5ldHdvcmssIGFuZCBkb2VzIG5vdA0KICAgID4gICAgbWFrZSB1c2Ug b2YgYSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcHJlLWluc3RhbGwgcGF0aHMgaW4gdGhlIG5ldHdv cmsuDQogICAgPiANCiAgICA+ICAgIFR3byBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMgaGF2ZSBi ZWVuIGRlZmluZWQgdG8gZW5hYmxlIHNlZ21lbnQNCiAgICA+ICAgIHJvdXRpbmcgaW4gYW4gTVBM UyBuZXR3b3JrIGFuZCBpbiBhbiBJUHY2IG5ldHdvcmsuICBXaGlsZQ0KICAgID4gICAgYWNrbm93 bGVkZ2luZyB0aGF0IHRoZXJlIGlzIGEgc3Ryb25nIG5lZWQgdG8gc3VwcG9ydCBzZWdtZW50IHJv dXRpbmcNCiAgICA+ICAgIGluIGJvdGggZW52aXJvbm1lbnRzLCB0aGlzIGRvY3VtZW50IGRlZmlu ZXMgYSBjb252ZXJnZWQsIHVuaWZpZWQNCiAgICA+ICAgIGFwcHJvYWNoIHRvIHNlZ21lbnQgcm91 dGluZyB0aGF0IGVuYWJsZXMgYSBzaW5nbGUgbWVjaGFuaXNtIHRvIGJlDQogICAgPiAgICBhcHBs aWVkIGluIGJvdGggdHlwZXMgb2YgbmV0d29yay4gIFRoZSByZXN1bHRpbmcgYXBwcm9hY2ggaXMg YWxzbw0KICAgID4gICAgYXBwbGljYWJsZSB0byBJUHY0IG5ldHdvcmtzIHdpdGhvdXQgdGhlIG5l ZWQgZm9yIGFueSBjaGFuZ2VzIHRvIHRoZQ0KICAgID4gICAgSVB2NCBzcGVjaWZpY2F0aW9uLg0K ICAgID4gDQogICAgPiAgICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhlIHNl Z21lbnQgcm91dGluZyBhcmNoaXRlY3R1cmUNCiAgICA+ICAgIGFuZCBidWlsZHMgb24gZXhpc3Rp bmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBlbmNhcHN1bGF0aW9uDQogICAgPiAg ICBvZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCiAgICA+IA0KICAgID4g ICAgTm8gbmV3IHByb2NlZHVyZXMgYXJlIGludHJvZHVjZWQsIGJ1dCBleGlzdGluZyBtZWNoYW5p c21zIGFyZQ0KICAgID4gICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCByZXN1bHQu DQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+IA0KICAgID4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCiAgICBzcHJpbmdAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KICAgIA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5n IG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZw0K From nobody Sun Aug 13 23:27:25 2017 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 00613126B6E for ; Sun, 13 Aug 2017 23:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 dBlPc_ugwWja for ; Sun, 13 Aug 2017 23:27:21 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0113.outbound.protection.outlook.com [104.47.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4E21200B9 for ; Sun, 13 Aug 2017 23:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vPC9/U1Intm4f1O99dTdr4zukmCmYmgoxMMbsWbYAlE=; b=qGB0jucCONzZKuWdW1Ffyf8D+fbSvQBJn42eXjeQ7t9BqOami0pQRp85t1hLbqh7ZLF0OTh4ktiOICiQ9U3sAMOlM85owvMuS1syeNiQMiQynPkYctGYRFFJ4RbYYQKF8tifzgmE5HID78hD4pFw/bRgbWORhBxu9WHOrx3N7CU= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0786.eurprd07.prod.outlook.com (10.161.70.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Mon, 14 Aug 2017 06:27:17 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651%14]) with mapi id 15.01.1362.012; Mon, 14 Aug 2017 06:27:17 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Uma Chunduri , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAA79GAP//7/ZwgABcJoA= Date: Mon, 14 Aug 2017 06:27:17 +0000 Message-ID: References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> <25B4902B1192E84696414485F572685401A3ABA2@SJCEML703-CHM.china.huawei.com> In-Reply-To: <25B4902B1192E84696414485F572685401A3ABA2@SJCEML703-CHM.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170725 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [88.128.80.101] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0786; 6:5iyAp57i9xk4srvnZULRZWys9/T2JdOi//zuotGEqurz93nhzw7/EmR2mTVCL8DE83Q5J8X398u8VnLDykCGonskZUxubHiPtGqRAVqm8gupznwASDFyfeGvyxBDHsCBXWVdEUSmNwpFlOEwJOiigJ6/++mY7LWBZcXcSx8drEldc7TDcuAJdefVg7cknPqK7IcdOzUfUDtO6xfZF/+85+6FbXT+lOhlop8iNdiAns7BL7qp/R6XVIsnlV6RbIoYlSeInhycDsh51lQ2FFq9KuCAHeLAkQ8nRg3xloea4hpt1+bTBJCC2iqVBuu5Q2n6si1Sj8XeSTyKLu65CuOIuQ==; 5:2YU9Y7++nFQFWp7+ZhSfhdfvym9JIior3fJcVApUg4z1an+ZbG95ufKwE+uoi2fMThespsQUwFv1upHoGnfwDjG7oCy4MfjrJP+2w3ItlMQTeTq0Y+Zo3yH1OJXxk8wQheA7sSnlhtm7MEeIMTI1dA==; 24:kMlhhMHvlpGR/IVATJ5DS0GUDcJ4PJm49brskmvr7AnqMv2KmgEMTHdkgEcaNtz9bO26r/7xKaYXNesNgggbpfNDzCUiXeoH3LjvA20NPiA=; 7:Fy9YcG11y0I5pfxggW442Wf+Y5VypdIxTU+ekzW3Rimp9YZiSadFV+/96BaVEAXnqsvsPnQRCoHLutvA5Yn5LQM5zyq75ZYmpFGOgk4HEdJ+u56AaCK8t/I7mUs023THOJGwH1F9M3qIWzW8a20CDgDY2xUB6b3sED5L28Ln9PnmBYofZXa+RREoq9JY8V7n8EEoUMdiAjpdCfpR2tF0szcdBqU8x+OT7il3hbBGJWI= x-ms-office365-filtering-correlation-id: 65e6fa2c-15c4-4bc5-4ac4-08d4e2dd82c0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0786; x-ms-traffictypediagnostic: AM2PR07MB0786: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0786; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(377424004)(377454003)(53754006)(199003)(13464003)(24454002)(189002)(106356001)(53546010)(101416001)(2906002)(97736004)(4001350100001)(7736002)(3280700002)(305945005)(76176999)(54356999)(50986999)(33656002)(3660700001)(36756003)(6306002)(53936002)(99286003)(66066001)(6116002)(102836003)(3846002)(86362001)(82746002)(5660300001)(6512007)(14454004)(189998001)(2900100001)(105586002)(966005)(6246003)(2501003)(8676002)(68736007)(83506001)(478600001)(83716003)(6506006)(93886004)(6436002)(81166006)(229853002)(8936002)(2950100002)(5250100002)(2201001)(81156014)(15650500001)(6486002)(25786009)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0786; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 06:27:17.4122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0786 Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 06:27:24 -0000 QWxzbyB0aGlzIGRyYWZ0IGRvZXNu4oCZdCBkZXNjcmliZSB0aGlzIHVzZSBjYXNlIGFmYWlzLiBX aGF0IEkgYW0gdGFraW5nIGFib3V0IGlzIHRoaXM6DQpVc2luZyBNUExTLVNSIGZvciB0aGUgU0lE IHRvIEcgYW5kIFNJRCB0byBIIGlzbyB1c2luZyBTUi1VRFAgU0lELiBJcyB0aGlzIGVudmlzaW9u ZWQ/DQoNCg0KICAgICArLS0tLS0rICAgICAgICstLS0tLSsgICAgICAgKy0tLS0tKyAgICAgICAg Ky0tLS0tKyAgICAgICAgKy0tLS0tKw0KICAgICB8ICBBICArLS0tLS0tLSsgIEIgICstLS0tLS0t KyAgQyAgKy0tLS0tLS0tKyAgRCAgKy0tLS0tLS0tKyAgSCAgfA0KICAgICArLS0tLS0rICAgICAg ICstLSstLSsgICAgICAgKy0tKy0tKyAgICAgICAgKy0tKy0tKyAgICAgICAgKy0tLS0tKw0KICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgICstLSstLSsgICAgICAgKy0tKy0tKyAgICAgICAgKy0tKy0tKw0KICAgICAgICAg ICAgICAgICAgIHwgIEUgICstLS0tLS0tKyAgRiAgKy0tLS0tLS0tKyAgRyAgfA0KICAgICAgICAg ICAgICAgICAgICstLS0tLSsgICAgICAgKy0tLS0tKyAgICAgICAgKy0tLS0tKw0KDQogICAgICAg ICAgKy0tLS0tLS0tKw0KICAgICAgICAgIHxJUChBLT5FKXwNCiAgICAgICAgICArLS0tLS0tLS0r ICAgICAgICAgICAgICAgICArLS0tLS0tLS0rDQogICAgICAgICAgfCAgTChHKSAgfCAgICAgICAg ICAgICAgICAgfEwoRykgICB8DQogICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tKw0KICAgICAgICAgIHwgIEwoSCkgIHwgICAgICAg ICAgICAgICAgIHwgIEwoSCkgIHwgICAgICAgIHxMKEgpfA0KICAgICAgICAgICstLS0tLS0tLSsg ICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICstLS0tLS0tLSsNCiAgICAgICAgICB8 IFBhY2tldCB8ICAgLS0tPiAgICB8IFBhY2tldCB8ICAtLS0+ICB8IFBhY2tldCB8DQogICAgICAg ICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0t Kw0KDQpBbHNvLCBpdCBpcyBhIGJpdCBvZGQgd2UgaGF2ZSBzbyBtYW55IGRyYWZ0cyBvbiB0aGUg c2FtZSB0b3BpYy4gDQpCdHcgd2hhdCBhYm91dCBCR1AgZXh0ZW5zaW9ucz8NCg0KT24gMTQvMDgv MjAxNywgMDQ6NTgsICJVbWEgQ2h1bmR1cmkiIDx1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbT4gd3Jv dGU6DQoNCiAgICBXaW0gLQ0KICAgIA0KICAgIFRoYXQncyBiZWVuIGRlc2NyaWJlZCAgaGVyZToN CiAgICANCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC14dS1tcGxzLXVuaWZpZWQt c291cmNlLXJvdXRpbmctaW5zdHJ1Y3Rpb24tMDMudHh0DQogICAgDQogICAgLS0NCiAgICBVbWEg Qy4NCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IHNwcmlu ZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVuZGVyaWNr eCwgV2ltIChOb2tpYSAtIEJFL0FudHdlcnApDQogICAgU2VudDogU3VuZGF5LCBBdWd1c3QgMTMs IDIwMTcgNjo1NSBQTQ0KICAgIFRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBzcHJpbmdAaWV0Zi5v cmcNCiAgICBTdWJqZWN0OiBSZTogW3NwcmluZ10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCiAgICANCiAgICBU aGUgZHJhZnQgb25seSBkZWZpbmVzIHByb2NlZHVyZXMgZm9yIFNSb0lQIEUyRSwgd2h5IGRvbuKA mXQgd2UgZW52aXNpb24gU1JvSVAgdG8gSW50ZXJ3b3JrIHdpdGggbmF0aXZlIE1QTFMtU1IuDQog ICAgV2hhdCBJIG1lYW4gaXMgd2hlbiB1c2luZyB0aGUgU1JvSVAgcHJvY2VkdXJlcyB0aGUgZHJh ZnQgdXNlcyBTUm9JUCBhdCBldmVyeSBob3Agd2hpY2ggaXMgU1IgY2FwYWJsZS4NCiAgICBZb3Ug Y291bGQgZW52aXNpb24gY2VydGFpbiBzZWdtZW50cyB0byBkbyBTUm9JUCBhbmQgb3RoZXIgc2Vn bWVudHMgdG8gaGF2ZSBuYXRpdmUgTVBMUy1TUiBjYXBhYmlsaXR5Lg0KICAgIA0KICAgIFNvIG15 IHF1ZXN0aW9uIGlzIHRoaXMgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdD8NCiAgICANCiAgICBPbiAx MS8wOC8yMDE3LCAyMDo0NywgInNwcmluZyBvbiBiZWhhbGYgb2YgQWRyaWFuIEZhcnJlbCIgPHNw cmluZy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhZHJpYW5Ab2xkZG9nLmNvLnVrPiB3 cm90ZToNCiAgICANCiAgICAgICAgSGkgYWxsLA0KICAgICAgICANCiAgICAgICAgU1BSSU5HIGRp ZG4ndCBtZWV0IGluIFByYWd1ZSBzbyBJIHByZXNlbnRlZCB0aGlzIHdvcmsgaW4gTVBMUy4gQnJ1 bm8gc3VnZ2VzdGVkDQogICAgICAgIHRoYXQgbWF5YmUgU1BSSU5HIHdvdWxkIGJlIGEgYmV0dGVy IHZlbnVlLg0KICAgICAgICANCiAgICAgICAgSSdtIG5vdCBzdXJlIGFib3V0IHRoYXQsIGFsdGhv dWdoIEkgZG8gdGhpbmsgYm90aCBXR3Mgc2hvdWxkIGNoYXQgYWJvdXQgdGhlDQogICAgICAgIGlk ZWFzLg0KICAgICAgICANCiAgICAgICAgVGhlIGVzc2VuY2Ugb2YgdGhpcyB3b3JrIGlzIG5vdGhp bmcgbW9yZSB0aGF0IE1QTFMtU1IgZW5jYXBzdWxhdGVkIGluIFVEUCBwZXINCiAgICAgICAgUkZD IDc1MTAuIFdoYXQgaXQgYWNoaWV2ZXMgaXMgYSB3YXkgdG8gb2J0YWluIHRoZSBTUiBmdW5jdGlv bmFsaXR5IHRoYXQgd2UgYWxsDQogICAgICAgIGtub3cgYW5kIGxvdmUgaW4gYW4gSVAgbmV0d29y ay4NCiAgICAgICAgDQogICAgICAgIFRoZSBhcHByb2FjaCBpcywgb2YgY291cnNlLCBjb21wYXRp YmxlIHdpdGggTVBMUy1TUi4gQXMgdGhlIGRyYWZ0IHNheXMuLi4NCiAgICAgICAgDQogICAgICAg ICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hhbmdlcyB0byB0aGUgc2VnbWVudCByb3V0aW5n IGFyY2hpdGVjdHVyZQ0KICAgICAgICAgICBhbmQgYnVpbGRzIG9uIGV4aXN0aW5nIHByb3RvY29s IG1lY2hhbmlzbXMgc3VjaCBhcyB0aGUgZW5jYXBzdWxhdGlvbg0KICAgICAgICAgICBvZiBNUExT IHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCiAgICAgICAgDQogICAgICAgICAgIE5v IG5ldyBwcm9jZWR1cmVzIGFyZSBpbnRyb2R1Y2VkLCBidXQgZXhpc3RpbmcgbWVjaGFuaXNtcyBh cmUNCiAgICAgICAgICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCByZXN1bHQuDQog ICAgICAgIA0KICAgICAgICBUaGlzIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBhIGJlYXV0eSBjb250 ZXN0IHdpdGggU1J2Ni4gQXMgdGhlIGRyYWZ0IHNheXMuLi4NCiAgICAgICAgDQogICAgICAgICAg IFRoZSBtZXRob2QgZGVmaW5lZCBpcyBhIGNvbXBsZW1lbnRhcnkgd2F5IG9mIHJ1bm5pbmcgU1Ig aW4gYW4gSVANCiAgICAgICAgICAgbmV0d29yayB0aGF0IGNhbiBiZSB1c2VkIGFsb25nc2lkZSBv ciBpbnRlcmNoYW5nZWFibHkgd2l0aCB0aGF0DQogICAgICAgICAgIGRlZmluZWQgaW4gW0ktRC5p ZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcl0uICBJbXBsZW1lbnRlcnMgYW5kDQogICAg ICAgICAgIGRlcGxveWVycyBzaG91bGQgY29uc2lkZXIgdGhlIGJlbmVmaXRzIGFuZCBkcmF3YmFj a3Mgb2YgZWFjaCBtZXRob2QNCiAgICAgICAgICAgYW5kIHNlbGVjdCB0aGUgYXBwcm9hY2ggbW9z dCBzdWl0ZWQgdG8gdGhlaXIgbmVlZHMuDQogICAgICAgIA0KICAgICAgICBUaGFua3MsDQogICAg ICAgIEFkcmlhbg0KICAgICAgICANCiAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgICAgID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn DQogICAgICAgID4gU2VudDogMTEgQXVndXN0IDIwMTcgMTk6Mzk6NTkgKFVUQyswMDowMCkgRHVi bGluLCBFZGluYnVyZ2gsIExpc2JvbiwgTG9uZG9uDQogICAgICAgID4gVG86IFN0ZXdhcnQgQnJ5 YW50OyBKb2huIEUgRHJha2U7IEFkcmlhbiBGYXJyZWwNCiAgICAgICAgPiBTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3It MDEudHh0DQogICAgICAgID4gDQogICAgICAgID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQogICAgICAgID4gaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBZHJpYW4gRmFycmVsIGFuZCBwb3N0ZWQgdG8gdGhlDQog ICAgICAgID4gSUVURiByZXBvc2l0b3J5Lg0KICAgICAgICA+IA0KICAgICAgICA+IE5hbWU6ICAg ICAgICAgICBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyDQogICAgICAgID4gUmV2aXNp b246ICAgICAgIDAxDQogICAgICAgID4gVGl0bGU6ICAgICAgICAgIEEgVW5pZmllZCBBcHByb2Fj aCB0byBJUCBTZWdtZW50IFJvdXRpbmcNCiAgICAgICAgPiBEb2N1bWVudCBkYXRlOiAgMjAxNy0w OC0xMQ0KICAgICAgICA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAg ICAgICAgPiBQYWdlczogICAgICAgICAgMTYNCiAgICAgICAgPiBVUkw6DQogICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1icnlhbnQtbXBscy11bmlmaWVk LWlwLXNyLQ0KICAgICAgICA+IDAxLnR4dA0KICAgICAgICA+IFN0YXR1czoNCiAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1p cC1zci8NCiAgICAgICAgPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDENCiAgICAgICAgPiBIdG1saXpl ZDoNCiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1i cnlhbnQtbXBscy11bmlmaWVkLWlwLQ0KICAgICAgICA+IHNyLTAxDQogICAgICAgID4gRGlmZjoN CiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJyeWFudC1t cGxzLXVuaWZpZWQtaXAtc3ItMDENCiAgICAgICAgPiANCiAgICAgICAgPiBBYnN0cmFjdDoNCiAg ICAgICAgPiAgICBTZWdtZW50IHJvdXRpbmcgaXMgYSBzb3VyY2Ugcm91dGVkIGZvcndhcmRpbmcg bWV0aG9kIHRoYXQgYWxsb3dzDQogICAgICAgID4gICAgcGFja2V0cyB0byBiZSBzdGVlcmVkIHRo cm91Z2ggYSBuZXR3b3JrIG9uIHBhdGhzIG90aGVyIHRoYW4gdGhlDQogICAgICAgID4gICAgc2hv cnRlc3QgcGF0aCBkZXJpdmVkIGZyb20gdGhlIHJvdXRpbmcgcHJvdG9jb2wuICBUaGUgYXBwcm9h Y2ggdXNlcw0KICAgICAgICA+ICAgIGluZm9ybWF0aW9uIGVuY29kZWQgaW4gdGhlIHBhY2tldCBo ZWFkZXIgdG8gcGFydGlhbGx5IG9yIGNvbXBsZXRlbHkNCiAgICAgICAgPiAgICBzcGVjaWZ5IHRo ZSByb3V0ZSB0aGUgcGFja2V0IHRha2VzIHRocm91Z2ggdGhlIG5ldHdvcmssIGFuZCBkb2VzIG5v dA0KICAgICAgICA+ICAgIG1ha2UgdXNlIG9mIGEgc2lnbmFsaW5nIHByb3RvY29sIHRvIHByZS1p bnN0YWxsIHBhdGhzIGluIHRoZSBuZXR3b3JrLg0KICAgICAgICA+IA0KICAgICAgICA+ICAgIFR3 byBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gZW5hYmxlIHNl Z21lbnQNCiAgICAgICAgPiAgICByb3V0aW5nIGluIGFuIE1QTFMgbmV0d29yayBhbmQgaW4gYW4g SVB2NiBuZXR3b3JrLiAgV2hpbGUNCiAgICAgICAgPiAgICBhY2tub3dsZWRnaW5nIHRoYXQgdGhl cmUgaXMgYSBzdHJvbmcgbmVlZCB0byBzdXBwb3J0IHNlZ21lbnQgcm91dGluZw0KICAgICAgICA+ ICAgIGluIGJvdGggZW52aXJvbm1lbnRzLCB0aGlzIGRvY3VtZW50IGRlZmluZXMgYSBjb252ZXJn ZWQsIHVuaWZpZWQNCiAgICAgICAgPiAgICBhcHByb2FjaCB0byBzZWdtZW50IHJvdXRpbmcgdGhh dCBlbmFibGVzIGEgc2luZ2xlIG1lY2hhbmlzbSB0byBiZQ0KICAgICAgICA+ICAgIGFwcGxpZWQg aW4gYm90aCB0eXBlcyBvZiBuZXR3b3JrLiAgVGhlIHJlc3VsdGluZyBhcHByb2FjaCBpcyBhbHNv DQogICAgICAgID4gICAgYXBwbGljYWJsZSB0byBJUHY0IG5ldHdvcmtzIHdpdGhvdXQgdGhlIG5l ZWQgZm9yIGFueSBjaGFuZ2VzIHRvIHRoZQ0KICAgICAgICA+ICAgIElQdjQgc3BlY2lmaWNhdGlv bi4NCiAgICAgICAgPiANCiAgICAgICAgPiAgICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIGNoYW5n ZXMgdG8gdGhlIHNlZ21lbnQgcm91dGluZyBhcmNoaXRlY3R1cmUNCiAgICAgICAgPiAgICBhbmQg YnVpbGRzIG9uIGV4aXN0aW5nIHByb3RvY29sIG1lY2hhbmlzbXMgc3VjaCBhcyB0aGUgZW5jYXBz dWxhdGlvbg0KICAgICAgICA+ICAgIG9mIE1QTFMgd2l0aGluIFVEUCBkZWZpbmVkIGluIFJGQyA3 NTEwLg0KICAgICAgICA+IA0KICAgICAgICA+ICAgIE5vIG5ldyBwcm9jZWR1cmVzIGFyZSBpbnRy b2R1Y2VkLCBidXQgZXhpc3RpbmcgbWVjaGFuaXNtcyBhcmUNCiAgICAgICAgPiAgICBjb21iaW5l ZCB0byBhY2hpZXZlIHRoZSBkZXNpcmVkIHJlc3VsdC4NCiAgICAgICAgPiANCiAgICAgICAgPiAN CiAgICAgICAgPiANCiAgICAgICAgPiANCiAgICAgICAgPiANCiAgICAgICAgPiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQogICAgICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICAgICAgPiANCiAgICAgICAgPiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KICAgICAgICANCiAgICAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgc3ByaW5nIG1haWxpbmcgbGlz dA0KICAgICAgICBzcHJpbmdAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCiAgICAgICAgDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzcHJpbmcgbWFpbGluZyBs aXN0DQogICAgc3ByaW5nQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHJpbmcNCiAgICANCg0KDQo= From nobody Sun Aug 13 23:41:39 2017 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 54509126BF0 for ; Sun, 13 Aug 2017 23:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CNts2yortfk for ; Sun, 13 Aug 2017 23:41:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C720A126B6E for ; Sun, 13 Aug 2017 23:41:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMO97157; Mon, 14 Aug 2017 06:41:34 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 14 Aug 2017 07:41:33 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 14 Aug 2017 14:41:23 +0800 From: Xuxiaohu To: "Henderickx, Wim (Nokia - BE/Antwerp)" , "Uma Chunduri" , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAA79GAP//7/ZwgABcJoD//99kQA== Date: Mon, 14 Aug 2017 06:41:22 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC00BFB@NKGEML515-MBX.china.huawei.com> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> <25B4902B1192E84696414485F572685401A3ABA2@SJCEML703-CHM.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.5991461E.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5a1df0a6f85ce3cfc3cc478a600de751 Archived-At: Subject: [spring] =?utf-8?b?562U5aSNOiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?utf-8?q?tion_for_draft-bryant-mpls-unified-ip-sr-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 06:41:38 -0000 SGkgV2ltLA0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBzcHJpbmcg W21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEhlbmRlcmlja3gsIFdpbSAo Tm9raWENCj4gLSBCRS9BbnR3ZXJwKQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTflubQ45pyIMTTml6Ug MTQ6MjcNCj4g5pS25Lu25Lq6OiBVbWEgQ2h1bmR1cmk7IGFkcmlhbkBvbGRkb2cuY28udWs7IHNw cmluZ0BpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxLnR4dA0K PiANCj4gQWxzbyB0aGlzIGRyYWZ0IGRvZXNu4oCZdCBkZXNjcmliZSB0aGlzIHVzZSBjYXNlIGFm YWlzLiBXaGF0IEkgYW0gdGFraW5nIGFib3V0IGlzDQo+IHRoaXM6DQo+IFVzaW5nIE1QTFMtU1Ig Zm9yIHRoZSBTSUQgdG8gRyBhbmQgU0lEIHRvIEggaXNvIHVzaW5nIFNSLVVEUCBTSUQuIElzIHRo aXMNCj4gZW52aXNpb25lZD8NCj4gDQo+IA0KPiAgICAgICstLS0tLSsgICAgICAgKy0tLS0tKyAg ICAgICArLS0tLS0rICAgICAgICArLS0tLS0rICAgICAgICArLS0tLS0rDQo+ICAgICAgfCAgQSAg Ky0tLS0tLS0rICBCICArLS0tLS0tLSsgIEMgICstLS0tLS0tLSsgIEQgICstLS0tLS0tLSsgIEgg IHwNCj4gICAgICArLS0tLS0rICAgICAgICstLSstLSsgICAgICAgKy0tKy0tKyAgICAgICAgKy0t Ky0tKyAgICAgICAgKy0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHwgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICstLSstLSsgICAgICAgKy0t Ky0tKyAgICAgICAgKy0tKy0tKw0KPiAgICAgICAgICAgICAgICAgICAgfCAgRSAgKy0tLS0tLS0r ICBGICArLS0tLS0tLS0rICBHICB8DQo+ICAgICAgICAgICAgICAgICAgICArLS0tLS0rICAgICAg ICstLS0tLSsgICAgICAgICstLS0tLSsNCj4gDQo+ICAgICAgICAgICArLS0tLS0tLS0rDQo+ICAg ICAgICAgICB8SVAoQS0+RSl8DQo+ICAgICAgICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAg ICArLS0tLS0tLS0rDQo+ICAgICAgICAgICB8ICBMKEcpICB8ICAgICAgICAgICAgICAgICB8TChH KSAgIHwNCj4gICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0tLSsg ICAgICAgICstLS0tLS0tLSsNCj4gICAgICAgICAgIHwgIEwoSCkgIHwgICAgICAgICAgICAgICAg IHwgIEwoSCkgIHwgICAgICAgIHxMKEgpfA0KPiAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tKw0KPiAgICAgICAgICAgfCBQYWNr ZXQgfCAgIC0tLT4gICAgfCBQYWNrZXQgfCAgLS0tPiAgfCBQYWNrZXQgfA0KPiAgICAgICAgICAg Ky0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tKw0K DQpJbiBmYWN0LCB0aGUgZmlyc3QgdXNlIGNhc2UgbGlzdGVkIGluIHRoZSBVc2UgQ2FzZXMgc2Vj dGlvbiB0YWxrcyBhYm91dCB0aGUgaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiBNUExTLVNSLiBJ ZiB5b3UgYmVsaWV2ZSBpdCdzIG5vdCBjbGVhciBlbm91Z2gsIHdlIGNhbiBhZGQgbW9yZSB0ZXh0 IHRvIGNsYXJpZnkgaXQuIEFueSBwcm9wb3NlZCB0ZXh0IGlzIHdlbGNvbWUuDQoNCj4gQWxzbywg aXQgaXMgYSBiaXQgb2RkIHdlIGhhdmUgc28gbWFueSBkcmFmdHMgb24gdGhlIHNhbWUgdG9waWMu DQoNClRoZSBzYW1lIGZlZWxpbmc6KA0KDQo+IEJ0dyB3aGF0IGFib3V0IEJHUCBleHRlbnNpb25z Pw0KDQpTaW5jZSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGZvciBNUExTLVNSIGFyZSByZXVzZWQg d2l0aG91dCBhbnkgY2hhbmdlLCB0aGUgQkdQIGV4dGVuc2lvbnMgZm9yIE1QTFMtU1IgY291bGQg YmUgcmV1c2VkLiBBcyBmb3IgdGhlIEJHUCBleHRlbnNpb24gZm9yIHR1bm5lbCBjYXBhYmlsaXR5 IGFkdmVydGlzZW1lbnQsIHllcywgaXQgd29ya3MgYXMgd2VsbC4gd2Ugd2lsbCBhZGQgc29tZSB0 ZXh0IHRvIGNsYXJpZnkgaXQuIFRoYW5rcyBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cy4NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gT24gMTQvMDgvMjAxNywgMDQ6NTgsICJVbWEgQ2h1 bmR1cmkiIDx1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgV2ltIC0N Cj4gDQo+ICAgICBUaGF0J3MgYmVlbiBkZXNjcmliZWQgIGhlcmU6DQo+IA0KPiANCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQteHUtbXBscy11bmlmaWVkLXNvdXJjZS1yb3V0aW5nLWlu c3RydWN0aW9uLTAzLnR4dA0KPiANCj4gICAgIC0tDQo+ICAgICBVbWEgQy4NCj4gDQo+ICAgICAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgICAgRnJvbTogc3ByaW5nIFttYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIZW5kZXJpY2t4LA0KPiBXaW0gKE5v a2lhIC0gQkUvQW50d2VycCkNCj4gICAgIFNlbnQ6IFN1bmRheSwgQXVndXN0IDEzLCAyMDE3IDY6 NTUgUE0NCj4gICAgIFRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBzcHJpbmdAaWV0Zi5vcmcNCj4g ICAgIFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv cg0KPiBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxLnR4dA0KPiANCj4gICAgIFRo ZSBkcmFmdCBvbmx5IGRlZmluZXMgcHJvY2VkdXJlcyBmb3IgU1JvSVAgRTJFLCB3aHkgZG9u4oCZ dCB3ZSBlbnZpc2lvbg0KPiBTUm9JUCB0byBJbnRlcndvcmsgd2l0aCBuYXRpdmUgTVBMUy1TUi4N Cj4gICAgIFdoYXQgSSBtZWFuIGlzIHdoZW4gdXNpbmcgdGhlIFNSb0lQIHByb2NlZHVyZXMgdGhl IGRyYWZ0IHVzZXMgU1JvSVAgYXQNCj4gZXZlcnkgaG9wIHdoaWNoIGlzIFNSIGNhcGFibGUuDQo+ ICAgICBZb3UgY291bGQgZW52aXNpb24gY2VydGFpbiBzZWdtZW50cyB0byBkbyBTUm9JUCBhbmQg b3RoZXIgc2VnbWVudHMgdG8NCj4gaGF2ZSBuYXRpdmUgTVBMUy1TUiBjYXBhYmlsaXR5Lg0KPiAN Cj4gICAgIFNvIG15IHF1ZXN0aW9uIGlzIHRoaXMgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdD8NCj4g DQo+ICAgICBPbiAxMS8wOC8yMDE3LCAyMDo0NywgInNwcmluZyBvbiBiZWhhbGYgb2YgQWRyaWFu IEZhcnJlbCINCj4gPHNwcmluZy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhZHJpYW5A b2xkZG9nLmNvLnVrPiB3cm90ZToNCj4gDQo+ICAgICAgICAgSGkgYWxsLA0KPiANCj4gICAgICAg ICBTUFJJTkcgZGlkbid0IG1lZXQgaW4gUHJhZ3VlIHNvIEkgcHJlc2VudGVkIHRoaXMgd29yayBp biBNUExTLiBCcnVubw0KPiBzdWdnZXN0ZWQNCj4gICAgICAgICB0aGF0IG1heWJlIFNQUklORyB3 b3VsZCBiZSBhIGJldHRlciB2ZW51ZS4NCj4gDQo+ICAgICAgICAgSSdtIG5vdCBzdXJlIGFib3V0 IHRoYXQsIGFsdGhvdWdoIEkgZG8gdGhpbmsgYm90aCBXR3Mgc2hvdWxkIGNoYXQNCj4gYWJvdXQg dGhlDQo+ICAgICAgICAgaWRlYXMuDQo+IA0KPiAgICAgICAgIFRoZSBlc3NlbmNlIG9mIHRoaXMg d29yayBpcyBub3RoaW5nIG1vcmUgdGhhdCBNUExTLVNSIGVuY2Fwc3VsYXRlZA0KPiBpbiBVRFAg cGVyDQo+ICAgICAgICAgUkZDIDc1MTAuIFdoYXQgaXQgYWNoaWV2ZXMgaXMgYSB3YXkgdG8gb2J0 YWluIHRoZSBTUiBmdW5jdGlvbmFsaXR5IHRoYXQNCj4gd2UgYWxsDQo+ICAgICAgICAga25vdyBh bmQgbG92ZSBpbiBhbiBJUCBuZXR3b3JrLg0KPiANCj4gICAgICAgICBUaGUgYXBwcm9hY2ggaXMs IG9mIGNvdXJzZSwgY29tcGF0aWJsZSB3aXRoIE1QTFMtU1IuIEFzIHRoZSBkcmFmdA0KPiBzYXlz Li4uDQo+IA0KPiAgICAgICAgICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hhbmdlcyB0byB0 aGUgc2VnbWVudCByb3V0aW5nDQo+IGFyY2hpdGVjdHVyZQ0KPiAgICAgICAgICAgIGFuZCBidWls ZHMgb24gZXhpc3RpbmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZQ0KPiBlbmNhcHN1 bGF0aW9uDQo+ICAgICAgICAgICAgb2YgTVBMUyB3aXRoaW4gVURQIGRlZmluZWQgaW4gUkZDIDc1 MTAuDQo+IA0KPiAgICAgICAgICAgIE5vIG5ldyBwcm9jZWR1cmVzIGFyZSBpbnRyb2R1Y2VkLCBi dXQgZXhpc3RpbmcgbWVjaGFuaXNtcyBhcmUNCj4gICAgICAgICAgICBjb21iaW5lZCB0byBhY2hp ZXZlIHRoZSBkZXNpcmVkIHJlc3VsdC4NCj4gDQo+ICAgICAgICAgVGhpcyBpcyBub3QgaW50ZW5k ZWQgdG8gYmUgYSBiZWF1dHkgY29udGVzdCB3aXRoIFNSdjYuIEFzIHRoZSBkcmFmdA0KPiBzYXlz Li4uDQo+IA0KPiAgICAgICAgICAgIFRoZSBtZXRob2QgZGVmaW5lZCBpcyBhIGNvbXBsZW1lbnRh cnkgd2F5IG9mIHJ1bm5pbmcgU1IgaW4gYW4gSVANCj4gICAgICAgICAgICBuZXR3b3JrIHRoYXQg Y2FuIGJlIHVzZWQgYWxvbmdzaWRlIG9yIGludGVyY2hhbmdlYWJseSB3aXRoIHRoYXQNCj4gICAg ICAgICAgICBkZWZpbmVkIGluIFtJLUQuaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJd LiAgSW1wbGVtZW50ZXJzDQo+IGFuZA0KPiAgICAgICAgICAgIGRlcGxveWVycyBzaG91bGQgY29u c2lkZXIgdGhlIGJlbmVmaXRzIGFuZCBkcmF3YmFja3Mgb2YgZWFjaA0KPiBtZXRob2QNCj4gICAg ICAgICAgICBhbmQgc2VsZWN0IHRoZSBhcHByb2FjaCBtb3N0IHN1aXRlZCB0byB0aGVpciBuZWVk cy4NCj4gDQo+ICAgICAgICAgVGhhbmtzLA0KPiAgICAgICAgIEFkcmlhbg0KPiANCj4gICAgICAg ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAgICA+ IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiAgICAgICAgID4gU2VudDogMTEgQXVn dXN0IDIwMTcgMTk6Mzk6NTkgKFVUQyswMDowMCkgRHVibGluLCBFZGluYnVyZ2gsDQo+IExpc2Jv biwgTG9uZG9uDQo+ICAgICAgICAgPiBUbzogU3Rld2FydCBCcnlhbnQ7IEpvaG4gRSBEcmFrZTsg QWRyaWFuIEZhcnJlbA0KPiAgICAgICAgID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxLnR4dA0KPiAgICAg ICAgID4NCj4gICAgICAgICA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1icnlhbnQtbXBs cy11bmlmaWVkLWlwLXNyLTAxLnR4dA0KPiAgICAgICAgID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBBZHJpYW4gRmFycmVsIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ICAgICAgICAg PiBJRVRGIHJlcG9zaXRvcnkuDQo+ICAgICAgICAgPg0KPiAgICAgICAgID4gTmFtZTogICAgICAg ICAgIGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3INCj4gICAgICAgICA+IFJldmlzaW9u OiAgICAgICAwMQ0KPiAgICAgICAgID4gVGl0bGU6ICAgICAgICAgIEEgVW5pZmllZCBBcHByb2Fj aCB0byBJUCBTZWdtZW50IFJvdXRpbmcNCj4gICAgICAgICA+IERvY3VtZW50IGRhdGU6ICAyMDE3 LTA4LTExDQo+ICAgICAgICAgPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ICAgICAgICAgPiBQYWdlczogICAgICAgICAgMTYNCj4gICAgICAgICA+IFVSTDoNCj4gICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1w bHMtdW5pZmllZC1pcC1zci0NCj4gICAgICAgICA+IDAxLnR4dA0KPiAgICAgICAgID4gU3RhdHVz Og0KPiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyeWFu dC1tcGxzLXVuaWZpZWQtaXAtc3IvDQo+ICAgICAgICAgPiBIdG1saXplZDoNCj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDENCj4g ICAgICAgICA+IEh0bWxpemVkOg0KPiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC0NCj4gICAgICAgICA+IHNy LTAxDQo+ICAgICAgICAgPiBEaWZmOg0KPiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxDQo+ICAgICAgICAg Pg0KPiAgICAgICAgID4gQWJzdHJhY3Q6DQo+ICAgICAgICAgPiAgICBTZWdtZW50IHJvdXRpbmcg aXMgYSBzb3VyY2Ugcm91dGVkIGZvcndhcmRpbmcgbWV0aG9kIHRoYXQNCj4gYWxsb3dzDQo+ICAg ICAgICAgPiAgICBwYWNrZXRzIHRvIGJlIHN0ZWVyZWQgdGhyb3VnaCBhIG5ldHdvcmsgb24gcGF0 aHMgb3RoZXIgdGhhbiB0aGUNCj4gICAgICAgICA+ICAgIHNob3J0ZXN0IHBhdGggZGVyaXZlZCBm cm9tIHRoZSByb3V0aW5nIHByb3RvY29sLiAgVGhlIGFwcHJvYWNoDQo+IHVzZXMNCj4gICAgICAg ICA+ICAgIGluZm9ybWF0aW9uIGVuY29kZWQgaW4gdGhlIHBhY2tldCBoZWFkZXIgdG8gcGFydGlh bGx5IG9yDQo+IGNvbXBsZXRlbHkNCj4gICAgICAgICA+ICAgIHNwZWNpZnkgdGhlIHJvdXRlIHRo ZSBwYWNrZXQgdGFrZXMgdGhyb3VnaCB0aGUgbmV0d29yaywgYW5kDQo+IGRvZXMgbm90DQo+ICAg ICAgICAgPiAgICBtYWtlIHVzZSBvZiBhIHNpZ25hbGluZyBwcm90b2NvbCB0byBwcmUtaW5zdGFs bCBwYXRocyBpbiB0aGUNCj4gbmV0d29yay4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPiAgICBU d28gZGlmZmVyZW50IGVuY2Fwc3VsYXRpb25zIGhhdmUgYmVlbiBkZWZpbmVkIHRvIGVuYWJsZQ0K PiBzZWdtZW50DQo+ICAgICAgICAgPiAgICByb3V0aW5nIGluIGFuIE1QTFMgbmV0d29yayBhbmQg aW4gYW4gSVB2NiBuZXR3b3JrLiAgV2hpbGUNCj4gICAgICAgICA+ICAgIGFja25vd2xlZGdpbmcg dGhhdCB0aGVyZSBpcyBhIHN0cm9uZyBuZWVkIHRvIHN1cHBvcnQgc2VnbWVudA0KPiByb3V0aW5n DQo+ICAgICAgICAgPiAgICBpbiBib3RoIGVudmlyb25tZW50cywgdGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgY29udmVyZ2VkLA0KPiB1bmlmaWVkDQo+ICAgICAgICAgPiAgICBhcHByb2FjaCB0byBz ZWdtZW50IHJvdXRpbmcgdGhhdCBlbmFibGVzIGEgc2luZ2xlIG1lY2hhbmlzbSB0bw0KPiBiZQ0K PiAgICAgICAgID4gICAgYXBwbGllZCBpbiBib3RoIHR5cGVzIG9mIG5ldHdvcmsuICBUaGUgcmVz dWx0aW5nIGFwcHJvYWNoIGlzDQo+IGFsc28NCj4gICAgICAgICA+ICAgIGFwcGxpY2FibGUgdG8g SVB2NCBuZXR3b3JrcyB3aXRob3V0IHRoZSBuZWVkIGZvciBhbnkgY2hhbmdlcyB0bw0KPiB0aGUN Cj4gICAgICAgICA+ICAgIElQdjQgc3BlY2lmaWNhdGlvbi4NCj4gICAgICAgICA+DQo+ICAgICAg ICAgPiAgICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhlIHNlZ21lbnQgcm91 dGluZw0KPiBhcmNoaXRlY3R1cmUNCj4gICAgICAgICA+ICAgIGFuZCBidWlsZHMgb24gZXhpc3Rp bmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZQ0KPiBlbmNhcHN1bGF0aW9uDQo+ICAg ICAgICAgPiAgICBvZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCj4gICAg ICAgICA+DQo+ICAgICAgICAgPiAgICBObyBuZXcgcHJvY2VkdXJlcyBhcmUgaW50cm9kdWNlZCwg YnV0IGV4aXN0aW5nIG1lY2hhbmlzbXMgYXJlDQo+ICAgICAgICAgPiAgICBjb21iaW5lZCB0byBh Y2hpZXZlIHRoZSBkZXNpcmVkIHJlc3VsdC4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPg0KPiAg ICAgICAgID4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPg0KPiAgICAgICAgID4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YN Cj4gc3VibWlzc2lvbg0KPiAgICAgICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gICAgICAgICA+DQo+ICAg ICAgICAgPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gICAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgIHNwcmluZyBtYWls aW5nIGxpc3QNCj4gICAgICAgICBzcHJpbmdAaWV0Zi5vcmcNCj4gICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiANCj4gDQo+ICAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgc3ByaW5nIG1h aWxpbmcgbGlzdA0KPiAgICAgc3ByaW5nQGlldGYub3JnDQo+ICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0 DQo+IHNwcmluZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0K From nobody Mon Aug 14 00:02:38 2017 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 A4251126BF0 for ; Mon, 14 Aug 2017 00:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 u1SeavdDDKhF for ; Mon, 14 Aug 2017 00:02:35 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50099.outbound.protection.outlook.com [40.107.5.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5626124BE8 for ; Mon, 14 Aug 2017 00:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xVc05NuIVsuhAY+0+13K8Ro+nqBowAwL1+8RgG9+PF4=; b=LNioBKlTvG1I9RMA90pi1/znRMnNkRmrdjmJqygjXGHlpRibScX9QKZJ9WdZoPciMEOuaeIWPzh17zOmhhS113Gtv+BPS9jsWdUIyp1NHPDZ9pY+cOoYG9n3qDjZg6yeaymea+UXPGxxkMBX5MErUqu8MtPjhFQBI0E9o0WpVEg= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0721.eurprd07.prod.outlook.com (10.160.56.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Mon, 14 Aug 2017 07:02:31 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651%14]) with mapi id 15.01.1362.012; Mon, 14 Aug 2017 07:02:31 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Xuxiaohu , Uma Chunduri , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u?= =?utf-8?Q?_for_draft-bryant-mpls-unified-ip-sr-01.txt?= Thread-Index: AQHTFMtMfjtH/oKHxEi6JLSpCM2cXA== Date: Mon, 14 Aug 2017 07:02:31 +0000 Message-ID: <62310E82-78F9-44C1-B673-8370C0410C45@nokia.com> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170725 x-originating-ip: [88.128.80.101] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0721; 6:Ibo6AG9zCI6C3S86x4UtawWVAmorsBARLZJ5h5OpI/74pP47AMOTa1iw5M16yaltUe2JUpMDgVP4pKslzIzwnF/rGA5VuaKLjSQqQdV+Oco20mwn20gbaL3VGzPRgJJjkdGB49Dt7obTgcZnRYzP6msM1zS8qr2Jf+noM3cxpi4lI+lvAuvWCBwrTw+DGjt7q6FEN+0VyFa7sIUR3xQSaPAQXVixERPefhl6Zzak4pZJdJZYK94Fnp0lmckByFgPEtIst2c8Ev9PEEp/G2abWULt63K/vS1EDenax2buC8DNH5+1ZZnRPejtDjEv0oQ/ah18Nibqd0Hbn6gv+q9bjg==; 5:Rp6cB/rq6OdI0WXU1Qq2Ehofs2XpSq5M2QoibtPv1KF04i0MhXgP6ZpxoLg4Sqk1bAieSH0f8qYYBZNCXjbTlJa7PmcwhTn93N8aZ8hynQHsPRNkluIsRbHjMVPFdwgTKCXfERVuBain6IWrgoJ6pA==; 24:Xtvoou7r4QXk3zhWg5RPZDv1MTyK7zipgNArVc69ExLbcvcy8Hi2U9RTU5oZ2KO10c8nLBknyEy05DYjiAuYoKh2YG8VyEfyHQfRh+3QdWA=; 7:hJbNoGTL/RjS60A1ianAH6+EszKo2lH7lfjFviaIt+cHDjg6cEHe0VXDZ5iQ5h+Q2tw9V5Gap/omXxoK4JWwu6hDJDKWIL6qWocGGNWT+KF8nksIwbEceykLjGMpJWIN+yVmFGIJ0ychubOSOSq8fGzxkMlBNf76lNh0URZsR9gt+K6GXzvQ5YZsFsFVDjLu7xqcYPdQZTnBSVxz7C2JDNwBJiYL0jLAtft90TU4hFw= x-ms-office365-filtering-correlation-id: d91e4b99-f029-4f71-caf4-08d4e2e26edf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603124)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0721; x-ms-traffictypediagnostic: AM2PR07MB0721: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0721; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0721; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(189002)(377424004)(377454003)(53754006)(13464003)(24454002)(199003)(54356999)(101416001)(102836003)(6436002)(3846002)(6116002)(6306002)(50986999)(6506006)(81156014)(105586002)(14454004)(81166006)(224303003)(83506001)(106356001)(99286003)(3660700001)(83716003)(2906002)(6512007)(6486002)(3280700002)(36756003)(229853002)(2900100001)(230783001)(25786009)(5250100002)(2201001)(966005)(82746002)(53936002)(2501003)(7736002)(189998001)(86362001)(4001350100001)(6246003)(53546010)(305945005)(33656002)(8936002)(66066001)(97736004)(68736007)(15650500001)(5660300001)(478600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0721; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0773637A5B4C014E881E02BC9301EE18@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 07:02:31.5635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0721 Archived-At: Subject: Re: [spring] =?utf-8?b?562U5aSNOiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?utf-8?q?tion_for_draft-bryant-mpls-unified-ip-sr-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 07:02:37 -0000 SW4tbGluZQ0KDQpPbiAxNC8wOC8yMDE3LCAwODo0MSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVh d2VpLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBXaW0sDQogICAgDQogICAgPiAtLS0tLemCruS7tuWO n+S7ti0tLS0tDQogICAgPiDlj5Hku7bkuro6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnXSDku6PooaggSGVuZGVyaWNreCwgV2ltIChOb2tpYQ0KICAgID4gLSBCRS9BbnR3 ZXJwKQ0KICAgID4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDE05pelIDE0OjI3DQogICAgPiDm lLbku7bkuro6IFVtYSBDaHVuZHVyaTsgYWRyaWFuQG9sZGRvZy5jby51azsgc3ByaW5nQGlldGYu b3JnDQogICAgPiDkuLvpopg6IFJlOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KICAgID4gZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCiAg ICA+IA0KICAgID4gQWxzbyB0aGlzIGRyYWZ0IGRvZXNu4oCZdCBkZXNjcmliZSB0aGlzIHVzZSBj YXNlIGFmYWlzLiBXaGF0IEkgYW0gdGFraW5nIGFib3V0IGlzDQogICAgPiB0aGlzOg0KICAgID4g VXNpbmcgTVBMUy1TUiBmb3IgdGhlIFNJRCB0byBHIGFuZCBTSUQgdG8gSCBpc28gdXNpbmcgU1It VURQIFNJRC4gSXMgdGhpcw0KICAgID4gZW52aXNpb25lZD8NCiAgICA+IA0KICAgID4gDQogICAg PiAgICAgICstLS0tLSsgICAgICAgKy0tLS0tKyAgICAgICArLS0tLS0rICAgICAgICArLS0tLS0r ICAgICAgICArLS0tLS0rDQogICAgPiAgICAgIHwgIEEgICstLS0tLS0tKyAgQiAgKy0tLS0tLS0r ICBDICArLS0tLS0tLS0rICBEICArLS0tLS0tLS0rICBIICB8DQogICAgPiAgICAgICstLS0tLSsg ICAgICAgKy0tKy0tKyAgICAgICArLS0rLS0rICAgICAgICArLS0rLS0rICAgICAgICArLS0tLS0r DQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg ICB8DQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICAgICB8DQogICAgPiAgICAgICAgICAgICAgICAgICAgKy0tKy0tKyAgICAgICArLS0rLS0rICAg ICAgICArLS0rLS0rDQogICAgPiAgICAgICAgICAgICAgICAgICAgfCAgRSAgKy0tLS0tLS0rICBG ICArLS0tLS0tLS0rICBHICB8DQogICAgPiAgICAgICAgICAgICAgICAgICAgKy0tLS0tKyAgICAg ICArLS0tLS0rICAgICAgICArLS0tLS0rDQogICAgPiANCiAgICA+ICAgICAgICAgICArLS0tLS0t LS0rDQogICAgPiAgICAgICAgICAgfElQKEEtPkUpfA0KICAgID4gICAgICAgICAgICstLS0tLS0t LSsgICAgICAgICAgICAgICAgICstLS0tLS0tLSsNCiAgICA+ICAgICAgICAgICB8ICBMKEcpICB8 ICAgICAgICAgICAgICAgICB8TChHKSAgIHwNCiAgICA+ICAgICAgICAgICArLS0tLS0tLS0rICAg ICAgICAgICAgICAgICArLS0tLS0tLS0rICAgICAgICArLS0tLS0tLS0rDQogICAgPiAgICAgICAg ICAgfCAgTChIKSAgfCAgICAgICAgICAgICAgICAgfCAgTChIKSAgfCAgICAgICAgfEwoSCl8DQog ICAgPiAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAg ICAgKy0tLS0tLS0tKw0KICAgID4gICAgICAgICAgIHwgUGFja2V0IHwgICAtLS0+ICAgIHwgUGFj a2V0IHwgIC0tLT4gIHwgUGFja2V0IHwNCiAgICA+ICAgICAgICAgICArLS0tLS0tLS0rICAgICAg ICAgICAgICAgICArLS0tLS0tLS0rICAgICAgICArLS0tLS0tLS0rDQogICAgDQogICAgSW4gZmFj dCwgdGhlIGZpcnN0IHVzZSBjYXNlIGxpc3RlZCBpbiB0aGUgVXNlIENhc2VzIHNlY3Rpb24gdGFs a3MgYWJvdXQgdGhlIGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgTVBMUy1TUi4gSWYgeW91IGJl bGlldmUgaXQncyBub3QgY2xlYXIgZW5vdWdoLCB3ZSBjYW4gYWRkIG1vcmUgdGV4dCB0byBjbGFy aWZ5IGl0LiBBbnkgcHJvcG9zZWQgdGV4dCBpcyB3ZWxjb21lLg0KDQpXSD4gaWYgd2Ugd2FudCB0 byBzdXBwb3J0IHRoaXMgdXNlIGNhc2Ugd2Ugc2hvdWxkIHNwZWxsIHRoaXMgb3V0IG1vcmUgZXhw bGljaXRseS4gT24gdG9wIHRoaXMgY29tcGxpY2F0ZXMgdGhlIHVzYWdlIG9mIGVudHJvcHkgYmVj YXVzZSB3aXRoIFNSb1VEUCB3ZSB1c2UgdGhlIHNvdXJjZSBwb3J0IGFuZCB3aGVuIHdlIHVzZSBu YXRpdmUgU1JvTVBMUyB3ZSBsb29zZSB0aGlzLiBJIGJlbGlldmUgd2UgbmVlZCB0byBlbmNvZGUg dGhlIGVudHJvcHkgbGFiZWwgaW4gdGhlIHBhY2tldCBmb3IgdGhlIE1QTFMgc2VnbWVudC4gVGhl IG5leHQgcXVlc3Rpb24gaXMgdGhhbiB3aG8gc2hvdWxkIGFkZCB0aGlzIGVudHJvcHkgbGFiZWwu IElzIGl0IHRoZSBzb3VyY2Ugb3IgaXMgaXQgdGhlIHRyYW5zaXQgYm94LiBJbiBteSB2aWV3IGl0 IHNob3VsZCBiZSBhZGRlZCBhdCB0aGUgc291cmNlIHRha2luZyBSTEQvTVNEIGludG8gYWNjb3Vu dC4gT24gdG9wIHlvdSBjYW4gYWxzbyBlbnZpc2lvbiBhIHVzZSBjYXNlIHdoZW4gU1JvTVBMUyBu ZWVkcyB0byBtYXAgYmFjayB0byBTUm9VRFAgaW4gd2hpY2ggY2FzZSB5b3Ugc2hvdWxkIHVzZSB0 aGUgZW50cm9weSBsYWJlbCB0byBtYXAgdG8gU1JvVURQIHNQb3J0IGVudHJvcHkuDQogICAgDQog ICAgPiBBbHNvLCBpdCBpcyBhIGJpdCBvZGQgd2UgaGF2ZSBzbyBtYW55IGRyYWZ0cyBvbiB0aGUg c2FtZSB0b3BpYy4NCiAgICANCiAgICBUaGUgc2FtZSBmZWVsaW5nOigNCiAgICANCiAgICA+IEJ0 dyB3aGF0IGFib3V0IEJHUCBleHRlbnNpb25zPw0KICAgIA0KICAgIFNpbmNlIHRoZSBleGlzdGlu ZyBwcm90b2NvbHMgZm9yIE1QTFMtU1IgYXJlIHJldXNlZCB3aXRob3V0IGFueSBjaGFuZ2UsIHRo ZSBCR1AgZXh0ZW5zaW9ucyBmb3IgTVBMUy1TUiBjb3VsZCBiZSByZXVzZWQuIEFzIGZvciB0aGUg QkdQIGV4dGVuc2lvbiBmb3IgdHVubmVsIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCwgeWVzLCBp dCB3b3JrcyBhcyB3ZWxsLiB3ZSB3aWxsIGFkZCBzb21lIHRleHQgdG8gY2xhcmlmeSBpdC4gVGhh bmtzIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLg0KDQpXSD4gbXkgdmlldyBpcyB0aGF0IGhh dmluZyBhIHJvdXRlciBpbmRpY2F0ZSBpdCBzdXBwb3J0IE1QTFNvVURQIGlzIG5vdCB0aGUgc2Ft ZSBhcyBhIHJvdXRlciBkb2luZyBTUm9VRFAuIFNvLCB3ZSBtaWdodCB3YW50IHRvIGRpc3Rpbmd1 aXNoIGJldHdlZW4gdGhlIGRpZmZlcmVudCBlbmNhcHN1bGF0aW9uIHRlY2huaXF1ZXMuDQogICAg DQogICAgQmVzdCByZWdhcmRzLA0KICAgIFhpYW9odQ0KICAgIA0KICAgID4gT24gMTQvMDgvMjAx NywgMDQ6NTgsICJVbWEgQ2h1bmR1cmkiIDx1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbT4gd3JvdGU6 DQogICAgPiANCiAgICA+ICAgICBXaW0gLQ0KICAgID4gDQogICAgPiAgICAgVGhhdCdzIGJlZW4g ZGVzY3JpYmVkICBoZXJlOg0KICAgID4gDQogICAgPiANCiAgICA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LXh1LW1wbHMtdW5pZmllZC1zb3VyY2Utcm91dGluZy1pbnN0cnVjdGlvbi0w My50eHQNCiAgICA+IA0KICAgID4gICAgIC0tDQogICAgPiAgICAgVW1hIEMuDQogICAgPiANCiAg ICA+ICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gICAgIEZyb206IHNwcmlu ZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVuZGVyaWNr eCwNCiAgICA+IFdpbSAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KICAgID4gICAgIFNlbnQ6IFN1bmRh eSwgQXVndXN0IDEzLCAyMDE3IDY6NTUgUE0NCiAgICA+ICAgICBUbzogYWRyaWFuQG9sZGRvZy5j by51azsgc3ByaW5nQGlldGYub3JnDQogICAgPiAgICAgU3ViamVjdDogUmU6IFtzcHJpbmddIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQogICAgPiBkcmFmdC1icnlhbnQtbXBscy11 bmlmaWVkLWlwLXNyLTAxLnR4dA0KICAgID4gDQogICAgPiAgICAgVGhlIGRyYWZ0IG9ubHkgZGVm aW5lcyBwcm9jZWR1cmVzIGZvciBTUm9JUCBFMkUsIHdoeSBkb27igJl0IHdlIGVudmlzaW9uDQog ICAgPiBTUm9JUCB0byBJbnRlcndvcmsgd2l0aCBuYXRpdmUgTVBMUy1TUi4NCiAgICA+ICAgICBX aGF0IEkgbWVhbiBpcyB3aGVuIHVzaW5nIHRoZSBTUm9JUCBwcm9jZWR1cmVzIHRoZSBkcmFmdCB1 c2VzIFNSb0lQIGF0DQogICAgPiBldmVyeSBob3Agd2hpY2ggaXMgU1IgY2FwYWJsZS4NCiAgICA+ ICAgICBZb3UgY291bGQgZW52aXNpb24gY2VydGFpbiBzZWdtZW50cyB0byBkbyBTUm9JUCBhbmQg b3RoZXIgc2VnbWVudHMgdG8NCiAgICA+IGhhdmUgbmF0aXZlIE1QTFMtU1IgY2FwYWJpbGl0eS4N CiAgICA+IA0KICAgID4gICAgIFNvIG15IHF1ZXN0aW9uIGlzIHRoaXMgaW4gc2NvcGUgb2YgdGhp cyBkcmFmdD8NCiAgICA+IA0KICAgID4gICAgIE9uIDExLzA4LzIwMTcsIDIwOjQ3LCAic3ByaW5n IG9uIGJlaGFsZiBvZiBBZHJpYW4gRmFycmVsIg0KICAgID4gPHNwcmluZy1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBhZHJpYW5Ab2xkZG9nLmNvLnVrPiB3cm90ZToNCiAgICA+IA0KICAg ID4gICAgICAgICBIaSBhbGwsDQogICAgPiANCiAgICA+ICAgICAgICAgU1BSSU5HIGRpZG4ndCBt ZWV0IGluIFByYWd1ZSBzbyBJIHByZXNlbnRlZCB0aGlzIHdvcmsgaW4gTVBMUy4gQnJ1bm8NCiAg ICA+IHN1Z2dlc3RlZA0KICAgID4gICAgICAgICB0aGF0IG1heWJlIFNQUklORyB3b3VsZCBiZSBh IGJldHRlciB2ZW51ZS4NCiAgICA+IA0KICAgID4gICAgICAgICBJJ20gbm90IHN1cmUgYWJvdXQg dGhhdCwgYWx0aG91Z2ggSSBkbyB0aGluayBib3RoIFdHcyBzaG91bGQgY2hhdA0KICAgID4gYWJv dXQgdGhlDQogICAgPiAgICAgICAgIGlkZWFzLg0KICAgID4gDQogICAgPiAgICAgICAgIFRoZSBl c3NlbmNlIG9mIHRoaXMgd29yayBpcyBub3RoaW5nIG1vcmUgdGhhdCBNUExTLVNSIGVuY2Fwc3Vs YXRlZA0KICAgID4gaW4gVURQIHBlcg0KICAgID4gICAgICAgICBSRkMgNzUxMC4gV2hhdCBpdCBh Y2hpZXZlcyBpcyBhIHdheSB0byBvYnRhaW4gdGhlIFNSIGZ1bmN0aW9uYWxpdHkgdGhhdA0KICAg ID4gd2UgYWxsDQogICAgPiAgICAgICAgIGtub3cgYW5kIGxvdmUgaW4gYW4gSVAgbmV0d29yay4N CiAgICA+IA0KICAgID4gICAgICAgICBUaGUgYXBwcm9hY2ggaXMsIG9mIGNvdXJzZSwgY29tcGF0 aWJsZSB3aXRoIE1QTFMtU1IuIEFzIHRoZSBkcmFmdA0KICAgID4gc2F5cy4uLg0KICAgID4gDQog ICAgPiAgICAgICAgICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hhbmdlcyB0byB0aGUgc2Vn bWVudCByb3V0aW5nDQogICAgPiBhcmNoaXRlY3R1cmUNCiAgICA+ICAgICAgICAgICAgYW5kIGJ1 aWxkcyBvbiBleGlzdGluZyBwcm90b2NvbCBtZWNoYW5pc21zIHN1Y2ggYXMgdGhlDQogICAgPiBl bmNhcHN1bGF0aW9uDQogICAgPiAgICAgICAgICAgIG9mIE1QTFMgd2l0aGluIFVEUCBkZWZpbmVk IGluIFJGQyA3NTEwLg0KICAgID4gDQogICAgPiAgICAgICAgICAgIE5vIG5ldyBwcm9jZWR1cmVz IGFyZSBpbnRyb2R1Y2VkLCBidXQgZXhpc3RpbmcgbWVjaGFuaXNtcyBhcmUNCiAgICA+ICAgICAg ICAgICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCByZXN1bHQuDQogICAgPiANCiAg ICA+ICAgICAgICAgVGhpcyBpcyBub3QgaW50ZW5kZWQgdG8gYmUgYSBiZWF1dHkgY29udGVzdCB3 aXRoIFNSdjYuIEFzIHRoZSBkcmFmdA0KICAgID4gc2F5cy4uLg0KICAgID4gDQogICAgPiAgICAg ICAgICAgIFRoZSBtZXRob2QgZGVmaW5lZCBpcyBhIGNvbXBsZW1lbnRhcnkgd2F5IG9mIHJ1bm5p bmcgU1IgaW4gYW4gSVANCiAgICA+ICAgICAgICAgICAgbmV0d29yayB0aGF0IGNhbiBiZSB1c2Vk IGFsb25nc2lkZSBvciBpbnRlcmNoYW5nZWFibHkgd2l0aCB0aGF0DQogICAgPiAgICAgICAgICAg IGRlZmluZWQgaW4gW0ktRC5pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcl0uICBJbXBs ZW1lbnRlcnMNCiAgICA+IGFuZA0KICAgID4gICAgICAgICAgICBkZXBsb3llcnMgc2hvdWxkIGNv bnNpZGVyIHRoZSBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIG9mIGVhY2gNCiAgICA+IG1ldGhvZA0K ICAgID4gICAgICAgICAgICBhbmQgc2VsZWN0IHRoZSBhcHByb2FjaCBtb3N0IHN1aXRlZCB0byB0 aGVpciBuZWVkcy4NCiAgICA+IA0KICAgID4gICAgICAgICBUaGFua3MsDQogICAgPiAgICAgICAg IEFkcmlhbg0KICAgID4gDQogICAgPiAgICAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4gICAgICAgICA+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZw0KICAgID4gICAgICAgICA+IFNlbnQ6IDExIEF1Z3VzdCAyMDE3IDE5OjM5OjU5IChV VEMrMDA6MDApIER1YmxpbiwgRWRpbmJ1cmdoLA0KICAgID4gTGlzYm9uLCBMb25kb24NCiAgICA+ ICAgICAgICAgPiBUbzogU3Rld2FydCBCcnlhbnQ7IEpvaG4gRSBEcmFrZTsgQWRyaWFuIEZhcnJl bA0KICAgID4gICAgICAgICA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IN CiAgICA+IGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQogICAgPiAgICAg ICAgID4NCiAgICA+ICAgICAgICAgPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYnJ5YW50 LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCiAgICA+ICAgICAgICAgPiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFkcmlhbiBGYXJyZWwgYW5kIHBvc3RlZCB0byB0aGUNCiAg ICA+ICAgICAgICAgPiBJRVRGIHJlcG9zaXRvcnkuDQogICAgPiAgICAgICAgID4NCiAgICA+ICAg ICAgICAgPiBOYW1lOiAgICAgICAgICAgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zcg0K ICAgID4gICAgICAgICA+IFJldmlzaW9uOiAgICAgICAwMQ0KICAgID4gICAgICAgICA+IFRpdGxl OiAgICAgICAgICBBIFVuaWZpZWQgQXBwcm9hY2ggdG8gSVAgU2VnbWVudCBSb3V0aW5nDQogICAg PiAgICAgICAgID4gRG9jdW1lbnQgZGF0ZTogIDIwMTctMDgtMTENCiAgICA+ICAgICAgICAgPiBH cm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgPiAgICAgICAgID4gUGFn ZXM6ICAgICAgICAgIDE2DQogICAgPiAgICAgICAgID4gVVJMOg0KICAgID4gICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmll ZC1pcC1zci0NCiAgICA+ICAgICAgICAgPiAwMS50eHQNCiAgICA+ICAgICAgICAgPiBTdGF0dXM6 DQogICAgPiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJy eWFudC1tcGxzLXVuaWZpZWQtaXAtc3IvDQogICAgPiAgICAgICAgID4gSHRtbGl6ZWQ6DQogICAg PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1p cC1zci0wMQ0KICAgID4gICAgICAgICA+IEh0bWxpemVkOg0KICAgID4gICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQt aXAtDQogICAgPiAgICAgICAgID4gc3ItMDENCiAgICA+ICAgICAgICAgPiBEaWZmOg0KICAgID4g ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYnJ5YW50LW1w bHMtdW5pZmllZC1pcC1zci0wMQ0KICAgID4gICAgICAgICA+DQogICAgPiAgICAgICAgID4gQWJz dHJhY3Q6DQogICAgPiAgICAgICAgID4gICAgU2VnbWVudCByb3V0aW5nIGlzIGEgc291cmNlIHJv dXRlZCBmb3J3YXJkaW5nIG1ldGhvZCB0aGF0DQogICAgPiBhbGxvd3MNCiAgICA+ICAgICAgICAg PiAgICBwYWNrZXRzIHRvIGJlIHN0ZWVyZWQgdGhyb3VnaCBhIG5ldHdvcmsgb24gcGF0aHMgb3Ro ZXIgdGhhbiB0aGUNCiAgICA+ICAgICAgICAgPiAgICBzaG9ydGVzdCBwYXRoIGRlcml2ZWQgZnJv bSB0aGUgcm91dGluZyBwcm90b2NvbC4gIFRoZSBhcHByb2FjaA0KICAgID4gdXNlcw0KICAgID4g ICAgICAgICA+ICAgIGluZm9ybWF0aW9uIGVuY29kZWQgaW4gdGhlIHBhY2tldCBoZWFkZXIgdG8g cGFydGlhbGx5IG9yDQogICAgPiBjb21wbGV0ZWx5DQogICAgPiAgICAgICAgID4gICAgc3BlY2lm eSB0aGUgcm91dGUgdGhlIHBhY2tldCB0YWtlcyB0aHJvdWdoIHRoZSBuZXR3b3JrLCBhbmQNCiAg ICA+IGRvZXMgbm90DQogICAgPiAgICAgICAgID4gICAgbWFrZSB1c2Ugb2YgYSBzaWduYWxpbmcg cHJvdG9jb2wgdG8gcHJlLWluc3RhbGwgcGF0aHMgaW4gdGhlDQogICAgPiBuZXR3b3JrLg0KICAg ID4gICAgICAgICA+DQogICAgPiAgICAgICAgID4gICAgVHdvIGRpZmZlcmVudCBlbmNhcHN1bGF0 aW9ucyBoYXZlIGJlZW4gZGVmaW5lZCB0byBlbmFibGUNCiAgICA+IHNlZ21lbnQNCiAgICA+ICAg ICAgICAgPiAgICByb3V0aW5nIGluIGFuIE1QTFMgbmV0d29yayBhbmQgaW4gYW4gSVB2NiBuZXR3 b3JrLiAgV2hpbGUNCiAgICA+ICAgICAgICAgPiAgICBhY2tub3dsZWRnaW5nIHRoYXQgdGhlcmUg aXMgYSBzdHJvbmcgbmVlZCB0byBzdXBwb3J0IHNlZ21lbnQNCiAgICA+IHJvdXRpbmcNCiAgICA+ ICAgICAgICAgPiAgICBpbiBib3RoIGVudmlyb25tZW50cywgdGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgY29udmVyZ2VkLA0KICAgID4gdW5pZmllZA0KICAgID4gICAgICAgICA+ICAgIGFwcHJvYWNo IHRvIHNlZ21lbnQgcm91dGluZyB0aGF0IGVuYWJsZXMgYSBzaW5nbGUgbWVjaGFuaXNtIHRvDQog ICAgPiBiZQ0KICAgID4gICAgICAgICA+ICAgIGFwcGxpZWQgaW4gYm90aCB0eXBlcyBvZiBuZXR3 b3JrLiAgVGhlIHJlc3VsdGluZyBhcHByb2FjaCBpcw0KICAgID4gYWxzbw0KICAgID4gICAgICAg ICA+ICAgIGFwcGxpY2FibGUgdG8gSVB2NCBuZXR3b3JrcyB3aXRob3V0IHRoZSBuZWVkIGZvciBh bnkgY2hhbmdlcyB0bw0KICAgID4gdGhlDQogICAgPiAgICAgICAgID4gICAgSVB2NCBzcGVjaWZp Y2F0aW9uLg0KICAgID4gICAgICAgICA+DQogICAgPiAgICAgICAgID4gICAgVGhpcyBkb2N1bWVu dCBtYWtlcyBubyBjaGFuZ2VzIHRvIHRoZSBzZWdtZW50IHJvdXRpbmcNCiAgICA+IGFyY2hpdGVj dHVyZQ0KICAgID4gICAgICAgICA+ICAgIGFuZCBidWlsZHMgb24gZXhpc3RpbmcgcHJvdG9jb2wg bWVjaGFuaXNtcyBzdWNoIGFzIHRoZQ0KICAgID4gZW5jYXBzdWxhdGlvbg0KICAgID4gICAgICAg ICA+ICAgIG9mIE1QTFMgd2l0aGluIFVEUCBkZWZpbmVkIGluIFJGQyA3NTEwLg0KICAgID4gICAg ICAgICA+DQogICAgPiAgICAgICAgID4gICAgTm8gbmV3IHByb2NlZHVyZXMgYXJlIGludHJvZHVj ZWQsIGJ1dCBleGlzdGluZyBtZWNoYW5pc21zIGFyZQ0KICAgID4gICAgICAgICA+ICAgIGNvbWJp bmVkIHRvIGFjaGlldmUgdGhlIGRlc2lyZWQgcmVzdWx0Lg0KICAgID4gICAgICAgICA+DQogICAg PiAgICAgICAgID4NCiAgICA+ICAgICAgICAgPg0KICAgID4gICAgICAgICA+DQogICAgPiAgICAg ICAgID4NCiAgICA+ICAgICAgICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KICAgID4gc3VibWlzc2lvbg0KICAgID4g ICAgICAgICA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPiAgICAgICAgID4NCiAgICA+ICAgICAgICAgPiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KICAgID4gDQogICAgPiAgICAgICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgICAgIHNwcmluZyBt YWlsaW5nIGxpc3QNCiAgICA+ICAgICAgICAgc3ByaW5nQGlldGYub3JnDQogICAgPiAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQogICAgPiANCiAg ICA+IA0KICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgPiAgICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgID4gICAgIHNwcmluZ0Bp ZXRmLm9yZw0KICAgID4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gc3ByaW5nIG1haWxpbmcgbGlzdA0K ICAgID4gc3ByaW5nQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZw0KICAgIA0KDQo= From nobody Mon Aug 14 00:11:23 2017 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 8CEB3131CF2 for ; Mon, 14 Aug 2017 00:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScqfU_PY4o0q for ; Mon, 14 Aug 2017 00:11:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345D4131D01 for ; Mon, 14 Aug 2017 00:11:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTJ41313; Mon, 14 Aug 2017 07:11:16 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 14 Aug 2017 08:11:15 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 14 Aug 2017 15:11:05 +0800 From: Xuxiaohu To: "Henderickx, Wim (Nokia - BE/Antwerp)" , "Uma Chunduri" , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u?= =?utf-8?Q?_for_draft-bryant-mpls-unified-ip-sr-01.txt?= Thread-Index: AQHTFMtMfjtH/oKHxEi6JLSpCM2cXKKDbb7w Date: Mon, 14 Aug 2017 07:11:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC01E43@NKGEML515-MBX.china.huawei.com> References: <62310E82-78F9-44C1-B673-8370C0410C45@nokia.com> In-Reply-To: <62310E82-78F9-44C1-B673-8370C0410C45@nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59914D14.00B9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b6e085013d898566a8f61f2d15f974da Archived-At: Subject: [spring] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBGVzogTmV3IFZlcnNpb24g?= =?utf-8?q?Notification_for_draft-bryant-mpls-unified-ip-sr-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 07:11:22 -0000 SGkgV2ltLA0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBIZW5kZXJp Y2t4LCBXaW0gKE5va2lhIC0gQkUvQW50d2VycCkNCj4gW21haWx0bzp3aW0uaGVuZGVyaWNreEBu b2tpYS5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxN+W5tDjmnIgxNOaXpSAxNTowMw0KPiDmlLbk u7bkuro6IFh1eGlhb2h1OyBVbWEgQ2h1bmR1cmk7IGFkcmlhbkBvbGRkb2cuY28udWs7IHNwcmlu Z0BpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiDnrZTlpI06IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEu dHh0DQo+IA0KPiBJbi1saW5lDQo+IA0KPiBPbiAxNC8wOC8yMDE3LCAwODo0MSwgIlh1eGlhb2h1 IiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgSGkgV2ltLA0KPiANCj4g ICAgID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiAgICAgPiDlj5Hku7bkuro6IHNwcmluZyBb bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggSGVuZGVyaWNreCwgV2ltDQo+ IChOb2tpYQ0KPiAgICAgPiAtIEJFL0FudHdlcnApDQo+ICAgICA+IOWPkemAgeaXtumXtDogMjAx N+W5tDjmnIgxNOaXpSAxNDoyNw0KPiAgICAgPiDmlLbku7bkuro6IFVtYSBDaHVuZHVyaTsgYWRy aWFuQG9sZGRvZy5jby51azsgc3ByaW5nQGlldGYub3JnDQo+ICAgICA+IOS4u+mimDogUmU6IFtz cHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ICAgICA+IGRyYWZ0LWJy eWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQo+ICAgICA+DQo+ICAgICA+IEFsc28gdGhp cyBkcmFmdCBkb2VzbuKAmXQgZGVzY3JpYmUgdGhpcyB1c2UgY2FzZSBhZmFpcy4gV2hhdCBJIGFt IHRha2luZw0KPiBhYm91dCBpcw0KPiAgICAgPiB0aGlzOg0KPiAgICAgPiBVc2luZyBNUExTLVNS IGZvciB0aGUgU0lEIHRvIEcgYW5kIFNJRCB0byBIIGlzbyB1c2luZyBTUi1VRFAgU0lELiBJcyB0 aGlzDQo+ICAgICA+IGVudmlzaW9uZWQ/DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICAgICAg Ky0tLS0tKyAgICAgICArLS0tLS0rICAgICAgICstLS0tLSsgICAgICAgICstLS0tLSsgICAgICAg ICstLS0tLSsNCj4gICAgID4gICAgICB8ICBBICArLS0tLS0tLSsgIEIgICstLS0tLS0tKyAgQyAg Ky0tLS0tLS0tKyAgRCAgKy0tLS0tLS0tKyAgSCAgfA0KPiAgICAgPiAgICAgICstLS0tLSsgICAg ICAgKy0tKy0tKyAgICAgICArLS0rLS0rICAgICAgICArLS0rLS0rICAgICAgICArLS0tLS0rDQo+ ICAgICA+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAg IHwNCj4gICAgID4gICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgfA0KPiAgICAgPiAgICAgICAgICAgICAgICAgICAgKy0tKy0tKyAgICAgICArLS0rLS0r ICAgICAgICArLS0rLS0rDQo+ICAgICA+ICAgICAgICAgICAgICAgICAgICB8ICBFICArLS0tLS0t LSsgIEYgICstLS0tLS0tLSsgIEcgIHwNCj4gICAgID4gICAgICAgICAgICAgICAgICAgICstLS0t LSsgICAgICAgKy0tLS0tKyAgICAgICAgKy0tLS0tKw0KPiAgICAgPg0KPiAgICAgPiAgICAgICAg ICAgKy0tLS0tLS0tKw0KPiAgICAgPiAgICAgICAgICAgfElQKEEtPkUpfA0KPiAgICAgPiAgICAg ICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KPiAgICAgPiAgICAg ICAgICAgfCAgTChHKSAgfCAgICAgICAgICAgICAgICAgfEwoRykgICB8DQo+ICAgICA+ICAgICAg ICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICArLS0tLS0tLS0rICAgICAgICArLS0tLS0t LS0rDQo+ICAgICA+ICAgICAgICAgICB8ICBMKEgpICB8ICAgICAgICAgICAgICAgICB8ICBMKEgp ICB8ICAgICAgICB8TChIKXwNCj4gICAgID4gICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAg ICAgICAgICstLS0tLS0tLSsgICAgICAgICstLS0tLS0tLSsNCj4gICAgID4gICAgICAgICAgIHwg UGFja2V0IHwgICAtLS0+ICAgIHwgUGFja2V0IHwgIC0tLT4gIHwgUGFja2V0IHwNCj4gICAgID4g ICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICst LS0tLS0tLSsNCj4gDQo+ICAgICBJbiBmYWN0LCB0aGUgZmlyc3QgdXNlIGNhc2UgbGlzdGVkIGlu IHRoZSBVc2UgQ2FzZXMgc2VjdGlvbiB0YWxrcyBhYm91dCB0aGUNCj4gaW5jcmVtZW50YWwgZGVw bG95bWVudCBvZiBNUExTLVNSLiBJZiB5b3UgYmVsaWV2ZSBpdCdzIG5vdCBjbGVhciBlbm91Z2gs IHdlDQo+IGNhbiBhZGQgbW9yZSB0ZXh0IHRvIGNsYXJpZnkgaXQuIEFueSBwcm9wb3NlZCB0ZXh0 IGlzIHdlbGNvbWUuDQo+IA0KPiBXSD4gaWYgd2Ugd2FudCB0byBzdXBwb3J0IHRoaXMgdXNlIGNh c2Ugd2Ugc2hvdWxkIHNwZWxsIHRoaXMgb3V0IG1vcmUgZXhwbGljaXRseS4NCj4gT24gdG9wIHRo aXMgY29tcGxpY2F0ZXMgdGhlIHVzYWdlIG9mIGVudHJvcHkgYmVjYXVzZSB3aXRoIFNSb1VEUCB3 ZSB1c2UgdGhlDQo+IHNvdXJjZSBwb3J0IGFuZCB3aGVuIHdlIHVzZSBuYXRpdmUgU1JvTVBMUyB3 ZSBsb29zZSB0aGlzLiBJIGJlbGlldmUgd2UgbmVlZA0KPiB0byBlbmNvZGUgdGhlIGVudHJvcHkg bGFiZWwgaW4gdGhlIHBhY2tldCBmb3IgdGhlIE1QTFMgc2VnbWVudC4gVGhlIG5leHQNCj4gcXVl c3Rpb24gaXMgdGhhbiB3aG8gc2hvdWxkIGFkZCB0aGlzIGVudHJvcHkgbGFiZWwuIElzIGl0IHRo ZSBzb3VyY2Ugb3IgaXMgaXQgdGhlDQo+IHRyYW5zaXQgYm94LiBJbiBteSB2aWV3IGl0IHNob3Vs ZCBiZSBhZGRlZCBhdCB0aGUgc291cmNlIHRha2luZyBSTEQvTVNEIGludG8NCj4gYWNjb3VudC4g T24gdG9wIHlvdSBjYW4gYWxzbyBlbnZpc2lvbiBhIHVzZSBjYXNlIHdoZW4gU1JvTVBMUyBuZWVk cyB0byBtYXANCj4gYmFjayB0byBTUm9VRFAgaW4gd2hpY2ggY2FzZSB5b3Ugc2hvdWxkIHVzZSB0 aGUgZW50cm9weSBsYWJlbCB0byBtYXAgdG8NCj4gU1JvVURQIHNQb3J0IGVudHJvcHkuDQoNClZl cnkgdXNlZnVsIGNvbW1lbnQgYW5kIHN1Z2dlc3Rpb24uIFdlIHdpbGwgaW5jb3Jwb3JhdGUgdGhl bSBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KPiAgICAgPiBBbHNvLCBpdCBpcyBhIGJpdCBvZGQg d2UgaGF2ZSBzbyBtYW55IGRyYWZ0cyBvbiB0aGUgc2FtZSB0b3BpYy4NCj4gDQo+ICAgICBUaGUg c2FtZSBmZWVsaW5nOigNCj4gDQo+ICAgICA+IEJ0dyB3aGF0IGFib3V0IEJHUCBleHRlbnNpb25z Pw0KPiANCj4gICAgIFNpbmNlIHRoZSBleGlzdGluZyBwcm90b2NvbHMgZm9yIE1QTFMtU1IgYXJl IHJldXNlZCB3aXRob3V0IGFueSBjaGFuZ2UsDQo+IHRoZSBCR1AgZXh0ZW5zaW9ucyBmb3IgTVBM Uy1TUiBjb3VsZCBiZSByZXVzZWQuIEFzIGZvciB0aGUgQkdQIGV4dGVuc2lvbiBmb3INCj4gdHVu bmVsIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCwgeWVzLCBpdCB3b3JrcyBhcyB3ZWxsLiB3ZSB3 aWxsIGFkZCBzb21lIHRleHQgdG8NCj4gY2xhcmlmeSBpdC4gVGhhbmtzIGZvciB5b3VyIHZhbHVh YmxlIGNvbW1lbnRzLg0KPiANCj4gV0g+IG15IHZpZXcgaXMgdGhhdCBoYXZpbmcgYSByb3V0ZXIg aW5kaWNhdGUgaXQgc3VwcG9ydCBNUExTb1VEUCBpcyBub3QgdGhlDQo+IHNhbWUgYXMgYSByb3V0 ZXIgZG9pbmcgU1JvVURQLiBTbywgd2UgbWlnaHQgd2FudCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVu IHRoZQ0KPiBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbiB0ZWNobmlxdWVzLg0KDQpDb3VsZCB5b3Ug cGxlYXNlIGdpdmUgbW9yZSBkZXRhaWxlZCBleHBsYW5hdGlvbiBvbiB0aGlzIHBvaW50Pw0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAgICAgQmVzdCByZWdhcmRzLA0KPiAgICAgWGlhb2h1 DQo+IA0KPiAgICAgPiBPbiAxNC8wOC8yMDE3LCAwNDo1OCwgIlVtYSBDaHVuZHVyaSIgPHVtYS5j aHVuZHVyaUBodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gICAgID4NCj4gICAgID4gICAgIFdpbSAt DQo+ICAgICA+DQo+ICAgICA+ICAgICBUaGF0J3MgYmVlbiBkZXNjcmliZWQgIGhlcmU6DQo+ICAg ICA+DQo+ICAgICA+DQo+ICAgICA+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXh1 LW1wbHMtdW5pZmllZC1zb3VyY2Utcm91dGluZy1pbnN0cnVjdGlvbi0wMy50eHQNCj4gICAgID4N Cj4gICAgID4gICAgIC0tDQo+ICAgICA+ICAgICBVbWEgQy4NCj4gICAgID4NCj4gICAgID4gICAg IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICA+ICAgICBGcm9tOiBzcHJpbmcgW21h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEhlbmRlcmlja3gs DQo+ICAgICA+IFdpbSAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KPiAgICAgPiAgICAgU2VudDogU3Vu ZGF5LCBBdWd1c3QgMTMsIDIwMTcgNjo1NSBQTQ0KPiAgICAgPiAgICAgVG86IGFkcmlhbkBvbGRk b2cuY28udWs7IHNwcmluZ0BpZXRmLm9yZw0KPiAgICAgPiAgICAgU3ViamVjdDogUmU6IFtzcHJp bmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ICAgICA+IGRyYWZ0LWJyeWFu dC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQo+ICAgICA+DQo+ICAgICA+ICAgICBUaGUgZHJh ZnQgb25seSBkZWZpbmVzIHByb2NlZHVyZXMgZm9yIFNSb0lQIEUyRSwgd2h5IGRvbuKAmXQgd2UN Cj4gZW52aXNpb24NCj4gICAgID4gU1JvSVAgdG8gSW50ZXJ3b3JrIHdpdGggbmF0aXZlIE1QTFMt U1IuDQo+ICAgICA+ICAgICBXaGF0IEkgbWVhbiBpcyB3aGVuIHVzaW5nIHRoZSBTUm9JUCBwcm9j ZWR1cmVzIHRoZSBkcmFmdCB1c2VzDQo+IFNSb0lQIGF0DQo+ICAgICA+IGV2ZXJ5IGhvcCB3aGlj aCBpcyBTUiBjYXBhYmxlLg0KPiAgICAgPiAgICAgWW91IGNvdWxkIGVudmlzaW9uIGNlcnRhaW4g c2VnbWVudHMgdG8gZG8gU1JvSVAgYW5kIG90aGVyDQo+IHNlZ21lbnRzIHRvDQo+ICAgICA+IGhh dmUgbmF0aXZlIE1QTFMtU1IgY2FwYWJpbGl0eS4NCj4gICAgID4NCj4gICAgID4gICAgIFNvIG15 IHF1ZXN0aW9uIGlzIHRoaXMgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdD8NCj4gICAgID4NCj4gICAg ID4gICAgIE9uIDExLzA4LzIwMTcsIDIwOjQ3LCAic3ByaW5nIG9uIGJlaGFsZiBvZiBBZHJpYW4g RmFycmVsIg0KPiAgICAgPiA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFk cmlhbkBvbGRkb2cuY28udWs+IHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPiAgICAgICAgIEhpIGFs bCwNCj4gICAgID4NCj4gICAgID4gICAgICAgICBTUFJJTkcgZGlkbid0IG1lZXQgaW4gUHJhZ3Vl IHNvIEkgcHJlc2VudGVkIHRoaXMgd29yayBpbiBNUExTLg0KPiBCcnVubw0KPiAgICAgPiBzdWdn ZXN0ZWQNCj4gICAgID4gICAgICAgICB0aGF0IG1heWJlIFNQUklORyB3b3VsZCBiZSBhIGJldHRl ciB2ZW51ZS4NCj4gICAgID4NCj4gICAgID4gICAgICAgICBJJ20gbm90IHN1cmUgYWJvdXQgdGhh dCwgYWx0aG91Z2ggSSBkbyB0aGluayBib3RoIFdHcyBzaG91bGQNCj4gY2hhdA0KPiAgICAgPiBh Ym91dCB0aGUNCj4gICAgID4gICAgICAgICBpZGVhcy4NCj4gICAgID4NCj4gICAgID4gICAgICAg ICBUaGUgZXNzZW5jZSBvZiB0aGlzIHdvcmsgaXMgbm90aGluZyBtb3JlIHRoYXQgTVBMUy1TUg0K PiBlbmNhcHN1bGF0ZWQNCj4gICAgID4gaW4gVURQIHBlcg0KPiAgICAgPiAgICAgICAgIFJGQyA3 NTEwLiBXaGF0IGl0IGFjaGlldmVzIGlzIGEgd2F5IHRvIG9idGFpbiB0aGUgU1INCj4gZnVuY3Rp b25hbGl0eSB0aGF0DQo+ICAgICA+IHdlIGFsbA0KPiAgICAgPiAgICAgICAgIGtub3cgYW5kIGxv dmUgaW4gYW4gSVAgbmV0d29yay4NCj4gICAgID4NCj4gICAgID4gICAgICAgICBUaGUgYXBwcm9h Y2ggaXMsIG9mIGNvdXJzZSwgY29tcGF0aWJsZSB3aXRoIE1QTFMtU1IuIEFzIHRoZQ0KPiBkcmFm dA0KPiAgICAgPiBzYXlzLi4uDQo+ICAgICA+DQo+ICAgICA+ICAgICAgICAgICAgVGhpcyBkb2N1 bWVudCBtYWtlcyBubyBjaGFuZ2VzIHRvIHRoZSBzZWdtZW50IHJvdXRpbmcNCj4gICAgID4gYXJj aGl0ZWN0dXJlDQo+ICAgICA+ICAgICAgICAgICAgYW5kIGJ1aWxkcyBvbiBleGlzdGluZyBwcm90 b2NvbCBtZWNoYW5pc21zIHN1Y2ggYXMgdGhlDQo+ICAgICA+IGVuY2Fwc3VsYXRpb24NCj4gICAg ID4gICAgICAgICAgICBvZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCj4g ICAgID4NCj4gICAgID4gICAgICAgICAgICBObyBuZXcgcHJvY2VkdXJlcyBhcmUgaW50cm9kdWNl ZCwgYnV0IGV4aXN0aW5nDQo+IG1lY2hhbmlzbXMgYXJlDQo+ICAgICA+ICAgICAgICAgICAgY29t YmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCByZXN1bHQuDQo+ICAgICA+DQo+ICAgICA+ICAg ICAgICAgVGhpcyBpcyBub3QgaW50ZW5kZWQgdG8gYmUgYSBiZWF1dHkgY29udGVzdCB3aXRoIFNS djYuIEFzIHRoZQ0KPiBkcmFmdA0KPiAgICAgPiBzYXlzLi4uDQo+ICAgICA+DQo+ICAgICA+ICAg ICAgICAgICAgVGhlIG1ldGhvZCBkZWZpbmVkIGlzIGEgY29tcGxlbWVudGFyeSB3YXkgb2YgcnVu bmluZyBTUg0KPiBpbiBhbiBJUA0KPiAgICAgPiAgICAgICAgICAgIG5ldHdvcmsgdGhhdCBjYW4g YmUgdXNlZCBhbG9uZ3NpZGUgb3IgaW50ZXJjaGFuZ2VhYmx5IHdpdGgNCj4gdGhhdA0KPiAgICAg PiAgICAgICAgICAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhl YWRlcl0uDQo+IEltcGxlbWVudGVycw0KPiAgICAgPiBhbmQNCj4gICAgID4gICAgICAgICAgICBk ZXBsb3llcnMgc2hvdWxkIGNvbnNpZGVyIHRoZSBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIG9mDQo+ IGVhY2gNCj4gICAgID4gbWV0aG9kDQo+ICAgICA+ICAgICAgICAgICAgYW5kIHNlbGVjdCB0aGUg YXBwcm9hY2ggbW9zdCBzdWl0ZWQgdG8gdGhlaXIgbmVlZHMuDQo+ICAgICA+DQo+ICAgICA+ICAg ICAgICAgVGhhbmtzLA0KPiAgICAgPiAgICAgICAgIEFkcmlhbg0KPiAgICAgPg0KPiAgICAgPiAg ICAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAg PiAgICAgICAgID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ICAgICA+ICAgICAg ICAgPiBTZW50OiAxMSBBdWd1c3QgMjAxNyAxOTozOTo1OSAoVVRDKzAwOjAwKSBEdWJsaW4sDQo+ IEVkaW5idXJnaCwNCj4gICAgID4gTGlzYm9uLCBMb25kb24NCj4gICAgID4gICAgICAgICA+IFRv OiBTdGV3YXJ0IEJyeWFudDsgSm9obiBFIERyYWtlOyBBZHJpYW4gRmFycmVsDQo+ICAgICA+ICAg ICAgICAgPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ICAgICA+IGRy YWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQo+ICAgICA+ICAgICAgICAgPg0K PiAgICAgPiAgICAgICAgID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJyeWFudC1tcGxz LXVuaWZpZWQtaXAtc3ItMDEudHh0DQo+ICAgICA+ICAgICAgICAgPiBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IEFkcmlhbiBGYXJyZWwgYW5kIHBvc3RlZA0KPiB0byB0aGUNCj4g ICAgID4gICAgICAgICA+IElFVEYgcmVwb3NpdG9yeS4NCj4gICAgID4gICAgICAgICA+DQo+ICAg ICA+ICAgICAgICAgPiBOYW1lOiAgICAgICAgICAgZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1p cC1zcg0KPiAgICAgPiAgICAgICAgID4gUmV2aXNpb246ICAgICAgIDAxDQo+ICAgICA+ICAgICAg ICAgPiBUaXRsZTogICAgICAgICAgQSBVbmlmaWVkIEFwcHJvYWNoIHRvIElQIFNlZ21lbnQgUm91 dGluZw0KPiAgICAgPiAgICAgICAgID4gRG9jdW1lbnQgZGF0ZTogIDIwMTctMDgtMTENCj4gICAg ID4gICAgICAgICA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gICAg ID4gICAgICAgICA+IFBhZ2VzOiAgICAgICAgICAxNg0KPiAgICAgPiAgICAgICAgID4gVVJMOg0K PiAgICAgPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5 YW50LW1wbHMtdW5pZmllZC1pcC1zci0NCj4gICAgID4gICAgICAgICA+IDAxLnR4dA0KPiAgICAg PiAgICAgICAgID4gU3RhdHVzOg0KPiAgICAgPiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3IvDQo+ICAgICA+ICAg ICAgICAgPiBIdG1saXplZDoNCj4gICAgID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDENCj4gICAgID4gICAgICAgICA+IEh0bWxp emVkOg0KPiAgICAgPg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtDQo+ICAgICA+ICAgICAgICAgPiBzci0wMQ0KPiAg ICAgPiAgICAgICAgID4gRGlmZjoNCj4gICAgID4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDENCj4gICAgID4gICAg ICAgICA+DQo+ICAgICA+ICAgICAgICAgPiBBYnN0cmFjdDoNCj4gICAgID4gICAgICAgICA+ICAg IFNlZ21lbnQgcm91dGluZyBpcyBhIHNvdXJjZSByb3V0ZWQgZm9yd2FyZGluZyBtZXRob2QNCj4g dGhhdA0KPiAgICAgPiBhbGxvd3MNCj4gICAgID4gICAgICAgICA+ICAgIHBhY2tldHMgdG8gYmUg c3RlZXJlZCB0aHJvdWdoIGEgbmV0d29yayBvbiBwYXRocyBvdGhlcg0KPiB0aGFuIHRoZQ0KPiAg ICAgPiAgICAgICAgID4gICAgc2hvcnRlc3QgcGF0aCBkZXJpdmVkIGZyb20gdGhlIHJvdXRpbmcg cHJvdG9jb2wuICBUaGUNCj4gYXBwcm9hY2gNCj4gICAgID4gdXNlcw0KPiAgICAgPiAgICAgICAg ID4gICAgaW5mb3JtYXRpb24gZW5jb2RlZCBpbiB0aGUgcGFja2V0IGhlYWRlciB0byBwYXJ0aWFs bHkgb3INCj4gICAgID4gY29tcGxldGVseQ0KPiAgICAgPiAgICAgICAgID4gICAgc3BlY2lmeSB0 aGUgcm91dGUgdGhlIHBhY2tldCB0YWtlcyB0aHJvdWdoIHRoZSBuZXR3b3JrLA0KPiBhbmQNCj4g ICAgID4gZG9lcyBub3QNCj4gICAgID4gICAgICAgICA+ICAgIG1ha2UgdXNlIG9mIGEgc2lnbmFs aW5nIHByb3RvY29sIHRvIHByZS1pbnN0YWxsIHBhdGhzIGluIHRoZQ0KPiAgICAgPiBuZXR3b3Jr Lg0KPiAgICAgPiAgICAgICAgID4NCj4gICAgID4gICAgICAgICA+ICAgIFR3byBkaWZmZXJlbnQg ZW5jYXBzdWxhdGlvbnMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gZW5hYmxlDQo+ICAgICA+IHNlZ21l bnQNCj4gICAgID4gICAgICAgICA+ICAgIHJvdXRpbmcgaW4gYW4gTVBMUyBuZXR3b3JrIGFuZCBp biBhbiBJUHY2IG5ldHdvcmsuDQo+IFdoaWxlDQo+ICAgICA+ICAgICAgICAgPiAgICBhY2tub3ds ZWRnaW5nIHRoYXQgdGhlcmUgaXMgYSBzdHJvbmcgbmVlZCB0byBzdXBwb3J0DQo+IHNlZ21lbnQN Cj4gICAgID4gcm91dGluZw0KPiAgICAgPiAgICAgICAgID4gICAgaW4gYm90aCBlbnZpcm9ubWVu dHMsIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhDQo+IGNvbnZlcmdlZCwNCj4gICAgID4gdW5pZmll ZA0KPiAgICAgPiAgICAgICAgID4gICAgYXBwcm9hY2ggdG8gc2VnbWVudCByb3V0aW5nIHRoYXQg ZW5hYmxlcyBhIHNpbmdsZQ0KPiBtZWNoYW5pc20gdG8NCj4gICAgID4gYmUNCj4gICAgID4gICAg ICAgICA+ICAgIGFwcGxpZWQgaW4gYm90aCB0eXBlcyBvZiBuZXR3b3JrLiAgVGhlIHJlc3VsdGlu Zw0KPiBhcHByb2FjaCBpcw0KPiAgICAgPiBhbHNvDQo+ICAgICA+ICAgICAgICAgPiAgICBhcHBs aWNhYmxlIHRvIElQdjQgbmV0d29ya3Mgd2l0aG91dCB0aGUgbmVlZCBmb3IgYW55DQo+IGNoYW5n ZXMgdG8NCj4gICAgID4gdGhlDQo+ICAgICA+ICAgICAgICAgPiAgICBJUHY0IHNwZWNpZmljYXRp b24uDQo+ICAgICA+ICAgICAgICAgPg0KPiAgICAgPiAgICAgICAgID4gICAgVGhpcyBkb2N1bWVu dCBtYWtlcyBubyBjaGFuZ2VzIHRvIHRoZSBzZWdtZW50IHJvdXRpbmcNCj4gICAgID4gYXJjaGl0 ZWN0dXJlDQo+ICAgICA+ICAgICAgICAgPiAgICBhbmQgYnVpbGRzIG9uIGV4aXN0aW5nIHByb3Rv Y29sIG1lY2hhbmlzbXMgc3VjaCBhcyB0aGUNCj4gICAgID4gZW5jYXBzdWxhdGlvbg0KPiAgICAg PiAgICAgICAgID4gICAgb2YgTVBMUyB3aXRoaW4gVURQIGRlZmluZWQgaW4gUkZDIDc1MTAuDQo+ ICAgICA+ICAgICAgICAgPg0KPiAgICAgPiAgICAgICAgID4gICAgTm8gbmV3IHByb2NlZHVyZXMg YXJlIGludHJvZHVjZWQsIGJ1dCBleGlzdGluZw0KPiBtZWNoYW5pc21zIGFyZQ0KPiAgICAgPiAg ICAgICAgID4gICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCByZXN1bHQuDQo+ICAg ICA+ICAgICAgICAgPg0KPiAgICAgPiAgICAgICAgID4NCj4gICAgID4gICAgICAgICA+DQo+ICAg ICA+ICAgICAgICAgPg0KPiAgICAgPiAgICAgICAgID4NCj4gICAgID4gICAgICAgICA+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZQ0KPiB0 aW1lIG9mDQo+ICAgICA+IHN1Ym1pc3Npb24NCj4gICAgID4gICAgICAgICA+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5v cmcuDQo+ICAgICA+ICAgICAgICAgPg0KPiAgICAgPiAgICAgICAgID4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCj4gICAgID4NCj4gICAgID4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiAgICAgICAgIHNwcmluZyBtYWlsaW5nIGxp c3QNCj4gICAgID4gICAgICAgICBzcHJpbmdAaWV0Zi5vcmcNCj4gICAgID4gICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiAgICAgPg0KPiAgICAg Pg0KPiAgICAgPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gICAgID4gICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgID4gICAgIHNwcmlu Z0BpZXRmLm9yZw0KPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmcNCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgID4gc3ByaW5nIG1h aWxpbmcgbGlzdA0KPiAgICAgPiBzcHJpbmdAaWV0Zi5vcmcNCj4gICAgID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCj4gDQoNCg== From nobody Mon Aug 14 00:18:09 2017 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 7359013201E for ; Mon, 14 Aug 2017 00:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 8qvIl8czXXt5 for ; Mon, 14 Aug 2017 00:18:06 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0138.outbound.protection.outlook.com [104.47.2.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B65131D19 for ; Mon, 14 Aug 2017 00:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S0Jcn3KQ5gqyKyMSAdzU+YTCi398rc5yFQ3ATUSXv00=; b=rN7SCrBfHdBc7CvdGNy1hyLRdTZAsrZX/jPt4uJGvoi6s2flC/R0YHXhcQgW5eJpyoEIzRlLOI6/mIU285eRbZcL90KsrlAa/zOjg7RbHjR+tpLwdvGH7MVbfP5uiUvHiuiMsoyrH9Hmd8kfn0SwallNq3o6+ZxYjIurbcogYWg= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0530.eurprd07.prod.outlook.com (10.160.31.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Mon, 14 Aug 2017 07:18:02 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651%14]) with mapi id 15.01.1362.012; Mon, 14 Aug 2017 07:18:02 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Xuxiaohu , Uma Chunduri , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiAg562U5aSNOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90?= =?utf-8?B?aWZpY2F0aW9uIGZvciBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNy?= =?utf-8?Q?-01.txt?= Thread-Index: AQHTFM13oBOwe92250Gg0ozVGT8OeA== Date: Mon, 14 Aug 2017 07:18:02 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170725 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [88.128.80.101] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0530; 6:YzN2azTEyiBsQ2ZvD+Q7RuwoJEDAvwm2oRU6Esb2DyACFUkiIj97jv7zFQAldKtGYMQZ+TWESpNmJkL6hZMglMNdWmA75UcwsGxOZ6yN5NeBibppQqWyKcU+0Ym4hLMLU1qSXUyi0p85XoNWLzaJYn9SufLWWfmzT9xbGOxAcdkKN1BOvIzVcbnZw9EG/PVNiep+QmnbUHAI4eOEjg49IboeEQSmwMONuld4zPeJO6V0e2vo6gqH2S44mR3o1qsuIeFcuCjK0If0w6cfOmD2hpJLFBWVSbLGeGXBFwmK412YRxrlrQwfzl1bMqkXrdmq17eVB7mc/7b6LUFqDFXqjA==; 5:Kz738kAZSEK4y8s+T9Ifab6H7HGia702hOaOsLAs6MEYHEzK/nIeks5yzKUWhzHPqfXDS+2yz75bFqk679HqL93hs9f9kdifwvuANWrUaAoRbON9eTSzJYnpLmYeNfkbX+YY6htAxqVloBPKhfyRFg==; 24:ZxkMo6gJqWxQlMDRmwotYfZug0QnRbKAJCnCAeUBMdoEskKKyn4bQFl0MNWUpaOH999URfblTQ9RcYhAkNMSCOxIsOhj713RavAEhCVP9hQ=; 7:9OHv08KbZxOBVYN7fylvvTtwjC7O8jC86mGD19yv8WDMmfOZD7MfV0AOoetWSDBQV/66LZZDTJvOfZQ898cPWMNRMqDeirLKJlYS6afUpYWsa8asuXLpDjabzjHq2FFzz7EL9p7SEvIKp3a2OuPHrstcC9PvlVd5X+TbimYcci9vxvSsSN199PFKYRiJ2XiavhVYbGXSOuPmKLRtpC/U4V6wCtTwO4SFSH1+BpH+P6k= x-ms-office365-filtering-correlation-id: 1c252180-7443-4d38-17cb-08d4e2e499dd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0530; x-ms-traffictypediagnostic: AM2PR07MB0530: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513)(82608151540597); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0530; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0530; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(24454002)(199003)(13464003)(53754006)(377454003)(189002)(377424004)(2501003)(5250100002)(189998001)(6506006)(229853002)(305945005)(230783001)(2906002)(2900100001)(2201001)(66066001)(3280700002)(3660700001)(97736004)(6486002)(83716003)(5660300001)(4001350100001)(83506001)(33656002)(966005)(54356999)(50986999)(68736007)(14454004)(6512007)(6246003)(6306002)(101416001)(53546010)(99286003)(82746002)(81156014)(3846002)(86362001)(102836003)(6116002)(81166006)(36756003)(15650500001)(53936002)(478600001)(8936002)(25786009)(224303003)(6436002)(105586002)(7736002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0530; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <01205D3235C78F48A0F7CD79B9AB9134@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 07:18:02.6500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0530 Archived-At: Subject: Re: [spring] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgRlc6IE5ldyBWZXJzaW9u?= =?utf-8?q?_Notification_for_draft-bryant-mpls-unified-ip-sr-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 07:18:08 -0000 TW9yZSBpbi1saW5lDQoNCk9uIDE0LzA4LzIwMTcsIDA5OjExLCAiWHV4aWFvaHUiIDx4dXhpYW9o dUBodWF3ZWkuY29tPiB3cm90ZToNCg0KICAgIEhpIFdpbSwNCiAgICANCiAgICA+IC0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCiAgICA+IOWPkeS7tuS6ujogSGVuZGVyaWNreCwgV2ltIChOb2tpYSAt IEJFL0FudHdlcnApDQogICAgPiBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QG5va2lhLmNvbV0NCiAg ICA+IOWPkemAgeaXtumXtDogMjAxN+W5tDjmnIgxNOaXpSAxNTowMw0KICAgID4g5pS25Lu25Lq6 OiBYdXhpYW9odTsgVW1hIENodW5kdXJpOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBzcHJpbmdAaWV0 Zi5vcmcNCiAgICA+IOS4u+mimDogUmU6IOetlOWkjTogW3NwcmluZ10gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3INCiAgICA+IGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3It MDEudHh0DQogICAgPiANCiAgICA+IEluLWxpbmUNCiAgICA+IA0KICAgID4gT24gMTQvMDgvMjAx NywgMDg6NDEsICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KICAgID4g DQogICAgPiAgICAgSGkgV2ltLA0KICAgID4gDQogICAgPiAgICAgPiAtLS0tLemCruS7tuWOn+S7 ti0tLS0tDQogICAgPiAgICAgPiDlj5Hku7bkuro6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggSGVuZGVyaWNreCwgV2ltDQogICAgPiAoTm9raWENCiAgICA+ ICAgICA+IC0gQkUvQW50d2VycCkNCiAgICA+ICAgICA+IOWPkemAgeaXtumXtDogMjAxN+W5tDjm nIgxNOaXpSAxNDoyNw0KICAgID4gICAgID4g5pS25Lu25Lq6OiBVbWEgQ2h1bmR1cmk7IGFkcmlh bkBvbGRkb2cuY28udWs7IHNwcmluZ0BpZXRmLm9yZw0KICAgID4gICAgID4g5Li76aKYOiBSZTog W3NwcmluZ10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCiAgICA+ICAgICA+IGRy YWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQogICAgPiAgICAgPg0KICAgID4g ICAgID4gQWxzbyB0aGlzIGRyYWZ0IGRvZXNu4oCZdCBkZXNjcmliZSB0aGlzIHVzZSBjYXNlIGFm YWlzLiBXaGF0IEkgYW0gdGFraW5nDQogICAgPiBhYm91dCBpcw0KICAgID4gICAgID4gdGhpczoN CiAgICA+ICAgICA+IFVzaW5nIE1QTFMtU1IgZm9yIHRoZSBTSUQgdG8gRyBhbmQgU0lEIHRvIEgg aXNvIHVzaW5nIFNSLVVEUCBTSUQuIElzIHRoaXMNCiAgICA+ICAgICA+IGVudmlzaW9uZWQ/DQog ICAgPiAgICAgPg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICAgKy0tLS0tKyAgICAgICAr LS0tLS0rICAgICAgICstLS0tLSsgICAgICAgICstLS0tLSsgICAgICAgICstLS0tLSsNCiAgICA+ ICAgICA+ICAgICAgfCAgQSAgKy0tLS0tLS0rICBCICArLS0tLS0tLSsgIEMgICstLS0tLS0tLSsg IEQgICstLS0tLS0tLSsgIEggIHwNCiAgICA+ICAgICA+ICAgICAgKy0tLS0tKyAgICAgICArLS0r LS0rICAgICAgICstLSstLSsgICAgICAgICstLSstLSsgICAgICAgICstLS0tLSsNCiAgICA+ICAg ICA+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwN CiAgICA+ICAgICA+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgICAgIHwNCiAgICA+ICAgICA+ICAgICAgICAgICAgICAgICAgICArLS0rLS0rICAgICAgICst LSstLSsgICAgICAgICstLSstLSsNCiAgICA+ICAgICA+ICAgICAgICAgICAgICAgICAgICB8ICBF ICArLS0tLS0tLSsgIEYgICstLS0tLS0tLSsgIEcgIHwNCiAgICA+ICAgICA+ICAgICAgICAgICAg ICAgICAgICArLS0tLS0rICAgICAgICstLS0tLSsgICAgICAgICstLS0tLSsNCiAgICA+ICAgICA+ DQogICAgPiAgICAgPiAgICAgICAgICAgKy0tLS0tLS0tKw0KICAgID4gICAgID4gICAgICAgICAg IHxJUChBLT5FKXwNCiAgICA+ICAgICA+ICAgICAgICAgICArLS0tLS0tLS0rICAgICAgICAgICAg ICAgICArLS0tLS0tLS0rDQogICAgPiAgICAgPiAgICAgICAgICAgfCAgTChHKSAgfCAgICAgICAg ICAgICAgICAgfEwoRykgICB8DQogICAgPiAgICAgPiAgICAgICAgICAgKy0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tKw0KICAgID4gICAgID4gICAg ICAgICAgIHwgIEwoSCkgIHwgICAgICAgICAgICAgICAgIHwgIEwoSCkgIHwgICAgICAgIHxMKEgp fA0KICAgID4gICAgID4gICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0t LS0tLSsgICAgICAgICstLS0tLS0tLSsNCiAgICA+ICAgICA+ICAgICAgICAgICB8IFBhY2tldCB8 ICAgLS0tPiAgICB8IFBhY2tldCB8ICAtLS0+ICB8IFBhY2tldCB8DQogICAgPiAgICAgPiAgICAg ICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgKy0tLS0t LS0tKw0KICAgID4gDQogICAgPiAgICAgSW4gZmFjdCwgdGhlIGZpcnN0IHVzZSBjYXNlIGxpc3Rl ZCBpbiB0aGUgVXNlIENhc2VzIHNlY3Rpb24gdGFsa3MgYWJvdXQgdGhlDQogICAgPiBpbmNyZW1l bnRhbCBkZXBsb3ltZW50IG9mIE1QTFMtU1IuIElmIHlvdSBiZWxpZXZlIGl0J3Mgbm90IGNsZWFy IGVub3VnaCwgd2UNCiAgICA+IGNhbiBhZGQgbW9yZSB0ZXh0IHRvIGNsYXJpZnkgaXQuIEFueSBw cm9wb3NlZCB0ZXh0IGlzIHdlbGNvbWUuDQogICAgPiANCiAgICA+IFdIPiBpZiB3ZSB3YW50IHRv IHN1cHBvcnQgdGhpcyB1c2UgY2FzZSB3ZSBzaG91bGQgc3BlbGwgdGhpcyBvdXQgbW9yZSBleHBs aWNpdGx5Lg0KICAgID4gT24gdG9wIHRoaXMgY29tcGxpY2F0ZXMgdGhlIHVzYWdlIG9mIGVudHJv cHkgYmVjYXVzZSB3aXRoIFNSb1VEUCB3ZSB1c2UgdGhlDQogICAgPiBzb3VyY2UgcG9ydCBhbmQg d2hlbiB3ZSB1c2UgbmF0aXZlIFNSb01QTFMgd2UgbG9vc2UgdGhpcy4gSSBiZWxpZXZlIHdlIG5l ZWQNCiAgICA+IHRvIGVuY29kZSB0aGUgZW50cm9weSBsYWJlbCBpbiB0aGUgcGFja2V0IGZvciB0 aGUgTVBMUyBzZWdtZW50LiBUaGUgbmV4dA0KICAgID4gcXVlc3Rpb24gaXMgdGhhbiB3aG8gc2hv dWxkIGFkZCB0aGlzIGVudHJvcHkgbGFiZWwuIElzIGl0IHRoZSBzb3VyY2Ugb3IgaXMgaXQgdGhl DQogICAgPiB0cmFuc2l0IGJveC4gSW4gbXkgdmlldyBpdCBzaG91bGQgYmUgYWRkZWQgYXQgdGhl IHNvdXJjZSB0YWtpbmcgUkxEL01TRCBpbnRvDQogICAgPiBhY2NvdW50LiBPbiB0b3AgeW91IGNh biBhbHNvIGVudmlzaW9uIGEgdXNlIGNhc2Ugd2hlbiBTUm9NUExTIG5lZWRzIHRvIG1hcA0KICAg ID4gYmFjayB0byBTUm9VRFAgaW4gd2hpY2ggY2FzZSB5b3Ugc2hvdWxkIHVzZSB0aGUgZW50cm9w eSBsYWJlbCB0byBtYXAgdG8NCiAgICA+IFNSb1VEUCBzUG9ydCBlbnRyb3B5Lg0KICAgIA0KICAg IFZlcnkgdXNlZnVsIGNvbW1lbnQgYW5kIHN1Z2dlc3Rpb24uIFdlIHdpbGwgaW5jb3Jwb3JhdGUg dGhlbSBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCiAgICANCiAgICA+ICAgICA+IEFsc28sIGl0IGlz IGEgYml0IG9kZCB3ZSBoYXZlIHNvIG1hbnkgZHJhZnRzIG9uIHRoZSBzYW1lIHRvcGljLg0KICAg ID4gDQogICAgPiAgICAgVGhlIHNhbWUgZmVlbGluZzooDQogICAgPiANCiAgICA+ICAgICA+IEJ0 dyB3aGF0IGFib3V0IEJHUCBleHRlbnNpb25zPw0KICAgID4gDQogICAgPiAgICAgU2luY2UgdGhl IGV4aXN0aW5nIHByb3RvY29scyBmb3IgTVBMUy1TUiBhcmUgcmV1c2VkIHdpdGhvdXQgYW55IGNo YW5nZSwNCiAgICA+IHRoZSBCR1AgZXh0ZW5zaW9ucyBmb3IgTVBMUy1TUiBjb3VsZCBiZSByZXVz ZWQuIEFzIGZvciB0aGUgQkdQIGV4dGVuc2lvbiBmb3INCiAgICA+IHR1bm5lbCBjYXBhYmlsaXR5 IGFkdmVydGlzZW1lbnQsIHllcywgaXQgd29ya3MgYXMgd2VsbC4gd2Ugd2lsbCBhZGQgc29tZSB0 ZXh0IHRvDQogICAgPiBjbGFyaWZ5IGl0LiBUaGFua3MgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVu dHMuDQogICAgPiANCiAgICA+IFdIPiBteSB2aWV3IGlzIHRoYXQgaGF2aW5nIGEgcm91dGVyIGlu ZGljYXRlIGl0IHN1cHBvcnQgTVBMU29VRFAgaXMgbm90IHRoZQ0KICAgID4gc2FtZSBhcyBhIHJv dXRlciBkb2luZyBTUm9VRFAuIFNvLCB3ZSBtaWdodCB3YW50IHRvIGRpc3Rpbmd1aXNoIGJldHdl ZW4gdGhlDQogICAgPiBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbiB0ZWNobmlxdWVzLg0KICAgIA0K ICAgIENvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9uIG9uIHRo aXMgcG9pbnQ/DQoNCldIPiBJIHNlZSAyIHVzZSBjYXNlIHdoZW4geW91IGluZGljYXRlIE1QTFNv VURQIHlvdSBjYW4ganVzdCBhY3QgYXMgYW4gZWdyZXNzIGFuZCB0ZXJtaW5hdGUgdGhlIHR1bm5l bCBhbmQgYmUgYWdub3N0aWMgb24gZW50cm9weSBiZWhhdmlvdXIsIHRyYW5zaXQgYmVoYXZpb3Vy LCBldGMuIElmIHlvdSBkbyBTUm9VRFAgYWxsIHRoZSBhYm92ZSBzaG91bGQgYmUgcGFydCBvZiB5 b3VyIGNhcGFiaWxpdGllcyB3aGVuIHlvdSBpbmRpY2F0ZSB0aGlzIGluIHRoZSBlbmNhcHN1bGF0 aW9uIGNhcGFiaWxpdGllcy4gSGVuY2UgSSBiZWxpZXZlIGl0IG1pZ2h0IGJlIGJldHRlciB0byBk aXN0aW5ndWlzaCB0aGlzIGluIHRoZSBzaWduYWxsaW5nLg0KICAgIA0KICAgIEJlc3QgcmVnYXJk cywNCiAgICBYaWFvaHUNCiAgICANCiAgICA+ICAgICBCZXN0IHJlZ2FyZHMsDQogICAgPiAgICAg WGlhb2h1DQogICAgPiANCiAgICA+ICAgICA+IE9uIDE0LzA4LzIwMTcsIDA0OjU4LCAiVW1hIENo dW5kdXJpIiA8dW1hLmNodW5kdXJpQGh1YXdlaS5jb20+DQogICAgPiB3cm90ZToNCiAgICA+ICAg ICA+DQogICAgPiAgICAgPiAgICAgV2ltIC0NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAg VGhhdCdzIGJlZW4gZGVzY3JpYmVkICBoZXJlOg0KICAgID4gICAgID4NCiAgICA+ICAgICA+DQog ICAgPiAgICAgPg0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQteHUtbXBscy11 bmlmaWVkLXNvdXJjZS1yb3V0aW5nLWluc3RydWN0aW9uLTAzLnR4dA0KICAgID4gICAgID4NCiAg ICA+ICAgICA+ICAgICAtLQ0KICAgID4gICAgID4gICAgIFVtYSBDLg0KICAgID4gICAgID4NCiAg ICA+ICAgICA+ICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gICAgID4gICAg IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCiAgICA+IEhlbmRlcmlja3gsDQogICAgPiAgICAgPiBXaW0gKE5va2lhIC0gQkUvQW50d2Vy cCkNCiAgICA+ICAgICA+ICAgICBTZW50OiBTdW5kYXksIEF1Z3VzdCAxMywgMjAxNyA2OjU1IFBN DQogICAgPiAgICAgPiAgICAgVG86IGFkcmlhbkBvbGRkb2cuY28udWs7IHNwcmluZ0BpZXRmLm9y Zw0KICAgID4gICAgID4gICAgIFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvcg0KICAgID4gICAgID4gZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1p cC1zci0wMS50eHQNCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgVGhlIGRyYWZ0IG9ubHkg ZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBTUm9JUCBFMkUsIHdoeSBkb27igJl0IHdlDQogICAgPiBl bnZpc2lvbg0KICAgID4gICAgID4gU1JvSVAgdG8gSW50ZXJ3b3JrIHdpdGggbmF0aXZlIE1QTFMt U1IuDQogICAgPiAgICAgPiAgICAgV2hhdCBJIG1lYW4gaXMgd2hlbiB1c2luZyB0aGUgU1JvSVAg cHJvY2VkdXJlcyB0aGUgZHJhZnQgdXNlcw0KICAgID4gU1JvSVAgYXQNCiAgICA+ICAgICA+IGV2 ZXJ5IGhvcCB3aGljaCBpcyBTUiBjYXBhYmxlLg0KICAgID4gICAgID4gICAgIFlvdSBjb3VsZCBl bnZpc2lvbiBjZXJ0YWluIHNlZ21lbnRzIHRvIGRvIFNSb0lQIGFuZCBvdGhlcg0KICAgID4gc2Vn bWVudHMgdG8NCiAgICA+ICAgICA+IGhhdmUgbmF0aXZlIE1QTFMtU1IgY2FwYWJpbGl0eS4NCiAg ICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgU28gbXkgcXVlc3Rpb24gaXMgdGhpcyBpbiBzY29w ZSBvZiB0aGlzIGRyYWZ0Pw0KICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICBPbiAxMS8wOC8y MDE3LCAyMDo0NywgInNwcmluZyBvbiBiZWhhbGYgb2YgQWRyaWFuIEZhcnJlbCINCiAgICA+ICAg ICA+IDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWRyaWFuQG9sZGRvZy5j by51az4gd3JvdGU6DQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgICAgICBIaSBhbGwsDQog ICAgPiAgICAgPg0KICAgID4gICAgID4gICAgICAgICBTUFJJTkcgZGlkbid0IG1lZXQgaW4gUHJh Z3VlIHNvIEkgcHJlc2VudGVkIHRoaXMgd29yayBpbiBNUExTLg0KICAgID4gQnJ1bm8NCiAgICA+ ICAgICA+IHN1Z2dlc3RlZA0KICAgID4gICAgID4gICAgICAgICB0aGF0IG1heWJlIFNQUklORyB3 b3VsZCBiZSBhIGJldHRlciB2ZW51ZS4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgICAg IEknbSBub3Qgc3VyZSBhYm91dCB0aGF0LCBhbHRob3VnaCBJIGRvIHRoaW5rIGJvdGggV0dzIHNo b3VsZA0KICAgID4gY2hhdA0KICAgID4gICAgID4gYWJvdXQgdGhlDQogICAgPiAgICAgPiAgICAg ICAgIGlkZWFzLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgVGhlIGVzc2VuY2Ug b2YgdGhpcyB3b3JrIGlzIG5vdGhpbmcgbW9yZSB0aGF0IE1QTFMtU1INCiAgICA+IGVuY2Fwc3Vs YXRlZA0KICAgID4gICAgID4gaW4gVURQIHBlcg0KICAgID4gICAgID4gICAgICAgICBSRkMgNzUx MC4gV2hhdCBpdCBhY2hpZXZlcyBpcyBhIHdheSB0byBvYnRhaW4gdGhlIFNSDQogICAgPiBmdW5j dGlvbmFsaXR5IHRoYXQNCiAgICA+ICAgICA+IHdlIGFsbA0KICAgID4gICAgID4gICAgICAgICBr bm93IGFuZCBsb3ZlIGluIGFuIElQIG5ldHdvcmsuDQogICAgPiAgICAgPg0KICAgID4gICAgID4g ICAgICAgICBUaGUgYXBwcm9hY2ggaXMsIG9mIGNvdXJzZSwgY29tcGF0aWJsZSB3aXRoIE1QTFMt U1IuIEFzIHRoZQ0KICAgID4gZHJhZnQNCiAgICA+ICAgICA+IHNheXMuLi4NCiAgICA+ICAgICA+ DQogICAgPiAgICAgPiAgICAgICAgICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gY2hhbmdlcyB0 byB0aGUgc2VnbWVudCByb3V0aW5nDQogICAgPiAgICAgPiBhcmNoaXRlY3R1cmUNCiAgICA+ICAg ICA+ICAgICAgICAgICAgYW5kIGJ1aWxkcyBvbiBleGlzdGluZyBwcm90b2NvbCBtZWNoYW5pc21z IHN1Y2ggYXMgdGhlDQogICAgPiAgICAgPiBlbmNhcHN1bGF0aW9uDQogICAgPiAgICAgPiAgICAg ICAgICAgIG9mIE1QTFMgd2l0aGluIFVEUCBkZWZpbmVkIGluIFJGQyA3NTEwLg0KICAgID4gICAg ID4NCiAgICA+ICAgICA+ICAgICAgICAgICAgTm8gbmV3IHByb2NlZHVyZXMgYXJlIGludHJvZHVj ZWQsIGJ1dCBleGlzdGluZw0KICAgID4gbWVjaGFuaXNtcyBhcmUNCiAgICA+ICAgICA+ICAgICAg ICAgICAgY29tYmluZWQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCByZXN1bHQuDQogICAgPiAgICAg Pg0KICAgID4gICAgID4gICAgICAgICBUaGlzIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBhIGJlYXV0 eSBjb250ZXN0IHdpdGggU1J2Ni4gQXMgdGhlDQogICAgPiBkcmFmdA0KICAgID4gICAgID4gc2F5 cy4uLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgICAgVGhlIG1ldGhvZCBkZWZp bmVkIGlzIGEgY29tcGxlbWVudGFyeSB3YXkgb2YgcnVubmluZyBTUg0KICAgID4gaW4gYW4gSVAN CiAgICA+ICAgICA+ICAgICAgICAgICAgbmV0d29yayB0aGF0IGNhbiBiZSB1c2VkIGFsb25nc2lk ZSBvciBpbnRlcmNoYW5nZWFibHkgd2l0aA0KICAgID4gdGhhdA0KICAgID4gICAgID4gICAgICAg ICAgICBkZWZpbmVkIGluIFtJLUQuaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJdLg0K ICAgID4gSW1wbGVtZW50ZXJzDQogICAgPiAgICAgPiBhbmQNCiAgICA+ICAgICA+ICAgICAgICAg ICAgZGVwbG95ZXJzIHNob3VsZCBjb25zaWRlciB0aGUgYmVuZWZpdHMgYW5kIGRyYXdiYWNrcyBv Zg0KICAgID4gZWFjaA0KICAgID4gICAgID4gbWV0aG9kDQogICAgPiAgICAgPiAgICAgICAgICAg IGFuZCBzZWxlY3QgdGhlIGFwcHJvYWNoIG1vc3Qgc3VpdGVkIHRvIHRoZWlyIG5lZWRzLg0KICAg ID4gICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgVGhhbmtzLA0KICAgID4gICAgID4gICAgICAg ICBBZHJpYW4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgICAgID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgID4gICAgICAgICA+IEZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KICAgID4gICAgID4gICAgICAgICA+IFNlbnQ6IDEx IEF1Z3VzdCAyMDE3IDE5OjM5OjU5IChVVEMrMDA6MDApIER1YmxpbiwNCiAgICA+IEVkaW5idXJn aCwNCiAgICA+ICAgICA+IExpc2JvbiwgTG9uZG9uDQogICAgPiAgICAgPiAgICAgICAgID4gVG86 IFN0ZXdhcnQgQnJ5YW50OyBKb2huIEUgRHJha2U7IEFkcmlhbiBGYXJyZWwNCiAgICA+ICAgICA+ ICAgICAgICAgPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQogICAgPiAg ICAgPiBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxLnR4dA0KICAgID4gICAgID4g ICAgICAgICA+DQogICAgPiAgICAgPiAgICAgICAgID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQogICAgPiAgICAgPiAgICAgICAg ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBZHJpYW4gRmFycmVsIGFuZCBw b3N0ZWQNCiAgICA+IHRvIHRoZQ0KICAgID4gICAgID4gICAgICAgICA+IElFVEYgcmVwb3NpdG9y eS4NCiAgICA+ICAgICA+ICAgICAgICAgPg0KICAgID4gICAgID4gICAgICAgICA+IE5hbWU6ICAg ICAgICAgICBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyDQogICAgPiAgICAgPiAgICAg ICAgID4gUmV2aXNpb246ICAgICAgIDAxDQogICAgPiAgICAgPiAgICAgICAgID4gVGl0bGU6ICAg ICAgICAgIEEgVW5pZmllZCBBcHByb2FjaCB0byBJUCBTZWdtZW50IFJvdXRpbmcNCiAgICA+ICAg ICA+ICAgICAgICAgPiBEb2N1bWVudCBkYXRlOiAgMjAxNy0wOC0xMQ0KICAgID4gICAgID4gICAg ICAgICA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICA+ICAgICA+ ICAgICAgICAgPiBQYWdlczogICAgICAgICAgMTYNCiAgICA+ICAgICA+ICAgICAgICAgPiBVUkw6 DQogICAgPiAgICAgPg0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtc3ItDQogICAgPiAgICAgPiAgICAgICAgID4g MDEudHh0DQogICAgPiAgICAgPiAgICAgICAgID4gU3RhdHVzOg0KICAgID4gICAgID4gICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1icnlhbnQtbXBscy11bmlm aWVkLWlwLXNyLw0KICAgID4gICAgID4gICAgICAgICA+IEh0bWxpemVkOg0KICAgID4gICAgID4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAt c3ItMDENCiAgICA+ICAgICA+ICAgICAgICAgPiBIdG1saXplZDoNCiAgICA+ICAgICA+DQogICAg PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJyeWFudC1tcGxz LXVuaWZpZWQtaXAtDQogICAgPiAgICAgPiAgICAgICAgID4gc3ItMDENCiAgICA+ICAgICA+ICAg ICAgICAgPiBEaWZmOg0KICAgID4gICAgID4NCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxDQogICAgPiAgICAg PiAgICAgICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgPiBBYnN0cmFjdDoNCiAgICA+ICAgICA+ ICAgICAgICAgPiAgICBTZWdtZW50IHJvdXRpbmcgaXMgYSBzb3VyY2Ugcm91dGVkIGZvcndhcmRp bmcgbWV0aG9kDQogICAgPiB0aGF0DQogICAgPiAgICAgPiBhbGxvd3MNCiAgICA+ICAgICA+ICAg ICAgICAgPiAgICBwYWNrZXRzIHRvIGJlIHN0ZWVyZWQgdGhyb3VnaCBhIG5ldHdvcmsgb24gcGF0 aHMgb3RoZXINCiAgICA+IHRoYW4gdGhlDQogICAgPiAgICAgPiAgICAgICAgID4gICAgc2hvcnRl c3QgcGF0aCBkZXJpdmVkIGZyb20gdGhlIHJvdXRpbmcgcHJvdG9jb2wuICBUaGUNCiAgICA+IGFw cHJvYWNoDQogICAgPiAgICAgPiB1c2VzDQogICAgPiAgICAgPiAgICAgICAgID4gICAgaW5mb3Jt YXRpb24gZW5jb2RlZCBpbiB0aGUgcGFja2V0IGhlYWRlciB0byBwYXJ0aWFsbHkgb3INCiAgICA+ ICAgICA+IGNvbXBsZXRlbHkNCiAgICA+ICAgICA+ICAgICAgICAgPiAgICBzcGVjaWZ5IHRoZSBy b3V0ZSB0aGUgcGFja2V0IHRha2VzIHRocm91Z2ggdGhlIG5ldHdvcmssDQogICAgPiBhbmQNCiAg ICA+ICAgICA+IGRvZXMgbm90DQogICAgPiAgICAgPiAgICAgICAgID4gICAgbWFrZSB1c2Ugb2Yg YSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcHJlLWluc3RhbGwgcGF0aHMgaW4gdGhlDQogICAgPiAg ICAgPiBuZXR3b3JrLg0KICAgID4gICAgID4gICAgICAgICA+DQogICAgPiAgICAgPiAgICAgICAg ID4gICAgVHdvIGRpZmZlcmVudCBlbmNhcHN1bGF0aW9ucyBoYXZlIGJlZW4gZGVmaW5lZCB0byBl bmFibGUNCiAgICA+ICAgICA+IHNlZ21lbnQNCiAgICA+ICAgICA+ICAgICAgICAgPiAgICByb3V0 aW5nIGluIGFuIE1QTFMgbmV0d29yayBhbmQgaW4gYW4gSVB2NiBuZXR3b3JrLg0KICAgID4gV2hp bGUNCiAgICA+ICAgICA+ICAgICAgICAgPiAgICBhY2tub3dsZWRnaW5nIHRoYXQgdGhlcmUgaXMg YSBzdHJvbmcgbmVlZCB0byBzdXBwb3J0DQogICAgPiBzZWdtZW50DQogICAgPiAgICAgPiByb3V0 aW5nDQogICAgPiAgICAgPiAgICAgICAgID4gICAgaW4gYm90aCBlbnZpcm9ubWVudHMsIHRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBhDQogICAgPiBjb252ZXJnZWQsDQogICAgPiAgICAgPiB1bmlmaWVk DQogICAgPiAgICAgPiAgICAgICAgID4gICAgYXBwcm9hY2ggdG8gc2VnbWVudCByb3V0aW5nIHRo YXQgZW5hYmxlcyBhIHNpbmdsZQ0KICAgID4gbWVjaGFuaXNtIHRvDQogICAgPiAgICAgPiBiZQ0K ICAgID4gICAgID4gICAgICAgICA+ICAgIGFwcGxpZWQgaW4gYm90aCB0eXBlcyBvZiBuZXR3b3Jr LiAgVGhlIHJlc3VsdGluZw0KICAgID4gYXBwcm9hY2ggaXMNCiAgICA+ICAgICA+IGFsc28NCiAg ICA+ICAgICA+ICAgICAgICAgPiAgICBhcHBsaWNhYmxlIHRvIElQdjQgbmV0d29ya3Mgd2l0aG91 dCB0aGUgbmVlZCBmb3IgYW55DQogICAgPiBjaGFuZ2VzIHRvDQogICAgPiAgICAgPiB0aGUNCiAg ICA+ICAgICA+ICAgICAgICAgPiAgICBJUHY0IHNwZWNpZmljYXRpb24uDQogICAgPiAgICAgPiAg ICAgICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgPiAgICBUaGlzIGRvY3VtZW50IG1ha2VzIG5v IGNoYW5nZXMgdG8gdGhlIHNlZ21lbnQgcm91dGluZw0KICAgID4gICAgID4gYXJjaGl0ZWN0dXJl DQogICAgPiAgICAgPiAgICAgICAgID4gICAgYW5kIGJ1aWxkcyBvbiBleGlzdGluZyBwcm90b2Nv bCBtZWNoYW5pc21zIHN1Y2ggYXMgdGhlDQogICAgPiAgICAgPiBlbmNhcHN1bGF0aW9uDQogICAg PiAgICAgPiAgICAgICAgID4gICAgb2YgTVBMUyB3aXRoaW4gVURQIGRlZmluZWQgaW4gUkZDIDc1 MTAuDQogICAgPiAgICAgPiAgICAgICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgPiAgICBObyBu ZXcgcHJvY2VkdXJlcyBhcmUgaW50cm9kdWNlZCwgYnV0IGV4aXN0aW5nDQogICAgPiBtZWNoYW5p c21zIGFyZQ0KICAgID4gICAgID4gICAgICAgICA+ICAgIGNvbWJpbmVkIHRvIGFjaGlldmUgdGhl IGRlc2lyZWQgcmVzdWx0Lg0KICAgID4gICAgID4gICAgICAgICA+DQogICAgPiAgICAgPiAgICAg ICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgPg0KICAgID4gICAgID4gICAgICAgICA+DQogICAg PiAgICAgPiAgICAgICAgID4NCiAgICA+ICAgICA+ICAgICAgICAgPiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUNCiAgICA+IHRpbWUgb2YN CiAgICA+ICAgICA+IHN1Ym1pc3Npb24NCiAgICA+ICAgICA+ICAgICAgICAgPiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQogICAgPiB0b29scy5p ZXRmLm9yZy4NCiAgICA+ICAgICA+ICAgICAgICAgPg0KICAgID4gICAgID4gICAgICAgICA+IFRo ZSBJRVRGIFNlY3JldGFyaWF0DQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgID4g ICAgICAgICBzcHJpbmcgbWFpbGluZyBsaXN0DQogICAgPiAgICAgPiAgICAgICAgIHNwcmluZ0Bp ZXRmLm9yZw0KICAgID4gICAgID4gICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZw0KICAgID4gICAgID4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ ICAgICA+ICAgICBzcHJpbmcgbWFpbGluZyBsaXN0DQogICAgPiAgICAgPiAgICAgc3ByaW5nQGll dGYub3JnDQogICAgPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmcNCiAgICA+ICAgICA+DQogICAgPiAgICAgPg0KICAgID4gICAgID4NCiAgICA+ ICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgPiAgICAgPiBzcHJpbmcgbWFpbGluZyBsaXN0DQogICAgPiAgICAgPiBzcHJpbmdAaWV0Zi5v cmcNCiAgICA+ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nDQogICAgPiANCiAgICANCiAgICANCg0K From nobody Mon Aug 14 00:30:29 2017 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 D63B4131D27 for ; Mon, 14 Aug 2017 00:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQrTK8qkRgQ9 for ; Mon, 14 Aug 2017 00:30:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF066131D19 for ; Mon, 14 Aug 2017 00:30:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTJ44779; Mon, 14 Aug 2017 07:30:22 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 14 Aug 2017 08:30:20 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 14 Aug 2017 15:30:10 +0800 From: Xuxiaohu To: "Henderickx, Wim (Nokia - BE/Antwerp)" , "Uma Chunduri" , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiAg562U5aSNOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90?= =?utf-8?B?aWZpY2F0aW9uIGZvciBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNy?= =?utf-8?Q?-01.txt?= Thread-Index: AQHTFM13oBOwe92250Gg0ozVGT8OeKKDc5Iw Date: Mon, 14 Aug 2017 07:30:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC01E8B@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5991518E.007F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3a9808fa6b3a07d16ca89271155960bb Archived-At: Subject: [spring] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06ICBGVzogTmV3?= =?utf-8?q?_Version_Notification_for_draft-bryant-mpls-unified-ip-sr-01=2E?= =?utf-8?q?txt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 07:30:27 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IEhlbmRlcmlja3gsIFdp bSAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KPiBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QG5va2lhLmNv bV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDE05pelIDE1OjE4DQo+IOaUtuS7tuS6ujog WHV4aWFvaHU7IFVtYSBDaHVuZHVyaTsgYWRyaWFuQG9sZGRvZy5jby51azsgc3ByaW5nQGlldGYu b3JnDQo+IOS4u+mimDogUmU6IOetlOWkjTog562U5aSNOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAx LnR4dA0KPiANCj4gTW9yZSBpbi1saW5lDQo+IA0KPiBPbiAxNC8wOC8yMDE3LCAwOToxMSwgIlh1 eGlhb2h1IiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgSGkgV2ltLA0K PiANCj4gICAgID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiAgICAgPiDlj5Hku7bkuro6IEhl bmRlcmlja3gsIFdpbSAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KPiAgICAgPiBbbWFpbHRvOndpbS5o ZW5kZXJpY2t4QG5va2lhLmNvbV0NCj4gICAgID4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDE0 5pelIDE1OjAzDQo+ICAgICA+IOaUtuS7tuS6ujogWHV4aWFvaHU7IFVtYSBDaHVuZHVyaTsgYWRy aWFuQG9sZGRvZy5jby51azsgc3ByaW5nQGlldGYub3JnDQo+ICAgICA+IOS4u+mimDogUmU6IOet lOWkjTogW3NwcmluZ10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gICAgID4g ZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCj4gICAgID4NCj4gICAgID4g SW4tbGluZQ0KPiAgICAgPg0KPiAgICAgPiBPbiAxNC8wOC8yMDE3LCAwODo0MSwgIlh1eGlhb2h1 IiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ICAgICA+DQo+ICAgICA+ICAgICBIaSBX aW0sDQo+ICAgICA+DQo+ICAgICA+ICAgICA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gICAg ID4gICAgID4g5Y+R5Lu25Lq6OiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoDQo+IEhlbmRlcmlja3gsIFdpbQ0KPiAgICAgPiAoTm9raWENCj4gICAgID4gICAg ID4gLSBCRS9BbnR3ZXJwKQ0KPiAgICAgPiAgICAgPiDlj5HpgIHml7bpl7Q6IDIwMTflubQ45pyI MTTml6UgMTQ6MjcNCj4gICAgID4gICAgID4g5pS25Lu25Lq6OiBVbWEgQ2h1bmR1cmk7IGFkcmlh bkBvbGRkb2cuY28udWs7IHNwcmluZ0BpZXRmLm9yZw0KPiAgICAgPiAgICAgPiDkuLvpopg6IFJl OiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiAgICAgPiAgICAg PiBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLTAxLnR4dA0KPiAgICAgPiAgICAgPg0K PiAgICAgPiAgICAgPiBBbHNvIHRoaXMgZHJhZnQgZG9lc27igJl0IGRlc2NyaWJlIHRoaXMgdXNl IGNhc2UgYWZhaXMuIFdoYXQgSSBhbQ0KPiB0YWtpbmcNCj4gICAgID4gYWJvdXQgaXMNCj4gICAg ID4gICAgID4gdGhpczoNCj4gICAgID4gICAgID4gVXNpbmcgTVBMUy1TUiBmb3IgdGhlIFNJRCB0 byBHIGFuZCBTSUQgdG8gSCBpc28gdXNpbmcgU1ItVURQIFNJRC4NCj4gSXMgdGhpcw0KPiAgICAg PiAgICAgPiBlbnZpc2lvbmVkPw0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAg PiAgICAgPiAgICAgICstLS0tLSsgICAgICAgKy0tLS0tKyAgICAgICArLS0tLS0rICAgICAgICAr LS0tLS0rDQo+ICstLS0tLSsNCj4gICAgID4gICAgID4gICAgICB8ICBBICArLS0tLS0tLSsgIEIg ICstLS0tLS0tKyAgQyAgKy0tLS0tLS0tKyAgRCAgKy0tLS0tLS0tKyAgSA0KPiB8DQo+ICAgICA+ ICAgICA+ICAgICAgKy0tLS0tKyAgICAgICArLS0rLS0rICAgICAgICstLSstLSsgICAgICAgICst LSstLSsNCj4gKy0tLS0tKw0KPiAgICAgPiAgICAgPiAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICA+ICAgICA+ICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4gICAgID4gICAgID4gICAg ICAgICAgICAgICAgICAgICstLSstLSsgICAgICAgKy0tKy0tKyAgICAgICAgKy0tKy0tKw0KPiAg ICAgPiAgICAgPiAgICAgICAgICAgICAgICAgICAgfCAgRSAgKy0tLS0tLS0rICBGICArLS0tLS0t LS0rICBHICB8DQo+ICAgICA+ICAgICA+ICAgICAgICAgICAgICAgICAgICArLS0tLS0rICAgICAg ICstLS0tLSsgICAgICAgICstLS0tLSsNCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAg ICAgICAgICstLS0tLS0tLSsNCj4gICAgID4gICAgID4gICAgICAgICAgIHxJUChBLT5FKXwNCj4g ICAgID4gICAgID4gICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0t LSsNCj4gICAgID4gICAgID4gICAgICAgICAgIHwgIEwoRykgIHwgICAgICAgICAgICAgICAgIHxM KEcpICAgfA0KPiAgICAgPiAgICAgPiAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tKw0KPiAgICAgPiAgICAgPiAgICAgICAgICAg fCAgTChIKSAgfCAgICAgICAgICAgICAgICAgfCAgTChIKSAgfA0KPiB8TChIKXwNCj4gICAgID4g ICAgID4gICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAg ICAgICstLS0tLS0tLSsNCj4gICAgID4gICAgID4gICAgICAgICAgIHwgUGFja2V0IHwgICAtLS0+ ICAgIHwgUGFja2V0IHwgIC0tLT4gIHwgUGFja2V0IHwNCj4gICAgID4gICAgID4gICAgICAgICAg ICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICstLS0tLS0tLSsN Cj4gICAgID4NCj4gICAgID4gICAgIEluIGZhY3QsIHRoZSBmaXJzdCB1c2UgY2FzZSBsaXN0ZWQg aW4gdGhlIFVzZSBDYXNlcyBzZWN0aW9uIHRhbGtzIGFib3V0DQo+IHRoZQ0KPiAgICAgPiBpbmNy ZW1lbnRhbCBkZXBsb3ltZW50IG9mIE1QTFMtU1IuIElmIHlvdSBiZWxpZXZlIGl0J3Mgbm90IGNs ZWFyIGVub3VnaCwNCj4gd2UNCj4gICAgID4gY2FuIGFkZCBtb3JlIHRleHQgdG8gY2xhcmlmeSBp dC4gQW55IHByb3Bvc2VkIHRleHQgaXMgd2VsY29tZS4NCj4gICAgID4NCj4gICAgID4gV0g+IGlm IHdlIHdhbnQgdG8gc3VwcG9ydCB0aGlzIHVzZSBjYXNlIHdlIHNob3VsZCBzcGVsbCB0aGlzIG91 dCBtb3JlDQo+IGV4cGxpY2l0bHkuDQo+ICAgICA+IE9uIHRvcCB0aGlzIGNvbXBsaWNhdGVzIHRo ZSB1c2FnZSBvZiBlbnRyb3B5IGJlY2F1c2Ugd2l0aCBTUm9VRFAgd2UNCj4gdXNlIHRoZQ0KPiAg ICAgPiBzb3VyY2UgcG9ydCBhbmQgd2hlbiB3ZSB1c2UgbmF0aXZlIFNSb01QTFMgd2UgbG9vc2Ug dGhpcy4gSSBiZWxpZXZlIHdlDQo+IG5lZWQNCj4gICAgID4gdG8gZW5jb2RlIHRoZSBlbnRyb3B5 IGxhYmVsIGluIHRoZSBwYWNrZXQgZm9yIHRoZSBNUExTIHNlZ21lbnQuIFRoZSBuZXh0DQo+ICAg ICA+IHF1ZXN0aW9uIGlzIHRoYW4gd2hvIHNob3VsZCBhZGQgdGhpcyBlbnRyb3B5IGxhYmVsLiBJ cyBpdCB0aGUgc291cmNlIG9yIGlzIGl0DQo+IHRoZQ0KPiAgICAgPiB0cmFuc2l0IGJveC4gSW4g bXkgdmlldyBpdCBzaG91bGQgYmUgYWRkZWQgYXQgdGhlIHNvdXJjZSB0YWtpbmcgUkxEL01TRA0K PiBpbnRvDQo+ICAgICA+IGFjY291bnQuIE9uIHRvcCB5b3UgY2FuIGFsc28gZW52aXNpb24gYSB1 c2UgY2FzZSB3aGVuIFNSb01QTFMgbmVlZHMNCj4gdG8gbWFwDQo+ICAgICA+IGJhY2sgdG8gU1Jv VURQIGluIHdoaWNoIGNhc2UgeW91IHNob3VsZCB1c2UgdGhlIGVudHJvcHkgbGFiZWwgdG8gbWFw DQo+IHRvDQo+ICAgICA+IFNSb1VEUCBzUG9ydCBlbnRyb3B5Lg0KPiANCj4gICAgIFZlcnkgdXNl ZnVsIGNvbW1lbnQgYW5kIHN1Z2dlc3Rpb24uIFdlIHdpbGwgaW5jb3Jwb3JhdGUgdGhlbSBpbiB0 aGUgbmV4dA0KPiByZXZpc2lvbi4NCj4gDQo+ICAgICA+ICAgICA+IEFsc28sIGl0IGlzIGEgYml0 IG9kZCB3ZSBoYXZlIHNvIG1hbnkgZHJhZnRzIG9uIHRoZSBzYW1lIHRvcGljLg0KPiAgICAgPg0K PiAgICAgPiAgICAgVGhlIHNhbWUgZmVlbGluZzooDQo+ICAgICA+DQo+ICAgICA+ICAgICA+IEJ0 dyB3aGF0IGFib3V0IEJHUCBleHRlbnNpb25zPw0KPiAgICAgPg0KPiAgICAgPiAgICAgU2luY2Ug dGhlIGV4aXN0aW5nIHByb3RvY29scyBmb3IgTVBMUy1TUiBhcmUgcmV1c2VkIHdpdGhvdXQgYW55 DQo+IGNoYW5nZSwNCj4gICAgID4gdGhlIEJHUCBleHRlbnNpb25zIGZvciBNUExTLVNSIGNvdWxk IGJlIHJldXNlZC4gQXMgZm9yIHRoZSBCR1ANCj4gZXh0ZW5zaW9uIGZvcg0KPiAgICAgPiB0dW5u ZWwgY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50LCB5ZXMsIGl0IHdvcmtzIGFzIHdlbGwuIHdlIHdp bGwgYWRkIHNvbWUNCj4gdGV4dCB0bw0KPiAgICAgPiBjbGFyaWZ5IGl0LiBUaGFua3MgZm9yIHlv dXIgdmFsdWFibGUgY29tbWVudHMuDQo+ICAgICA+DQo+ICAgICA+IFdIPiBteSB2aWV3IGlzIHRo YXQgaGF2aW5nIGEgcm91dGVyIGluZGljYXRlIGl0IHN1cHBvcnQgTVBMU29VRFAgaXMgbm90DQo+ IHRoZQ0KPiAgICAgPiBzYW1lIGFzIGEgcm91dGVyIGRvaW5nIFNSb1VEUC4gU28sIHdlIG1pZ2h0 IHdhbnQgdG8gZGlzdGluZ3Vpc2gNCj4gYmV0d2VlbiB0aGUNCj4gICAgID4gZGlmZmVyZW50IGVu Y2Fwc3VsYXRpb24gdGVjaG5pcXVlcy4NCj4gDQo+ICAgICBDb3VsZCB5b3UgcGxlYXNlIGdpdmUg bW9yZSBkZXRhaWxlZCBleHBsYW5hdGlvbiBvbiB0aGlzIHBvaW50Pw0KPiANCj4gV0g+IEkgc2Vl IDIgdXNlIGNhc2Ugd2hlbiB5b3UgaW5kaWNhdGUgTVBMU29VRFAgeW91IGNhbiBqdXN0IGFjdCBh cyBhbg0KPiBlZ3Jlc3MgYW5kIHRlcm1pbmF0ZSB0aGUgdHVubmVsIGFuZCBiZSBhZ25vc3RpYyBv biBlbnRyb3B5IGJlaGF2aW91ciwgdHJhbnNpdA0KPiBiZWhhdmlvdXIsIGV0Yy4gSWYgeW91IGRv IFNSb1VEUCBhbGwgdGhlIGFib3ZlIHNob3VsZCBiZSBwYXJ0IG9mIHlvdXINCj4gY2FwYWJpbGl0 aWVzIHdoZW4geW91IGluZGljYXRlIHRoaXMgaW4gdGhlIGVuY2Fwc3VsYXRpb24gY2FwYWJpbGl0 aWVzLiBIZW5jZSBJDQo+IGJlbGlldmUgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGRpc3Rpbmd1aXNo IHRoaXMgaW4gdGhlIHNpZ25hbGxpbmcuDQoNCkRpZCB5b3UgbWVhbiB0aGUgdHVubmVsIGVncmVz cyByb3V0ZXIgc2hvdWxkIGFkdmVydGlzZSB3aGV0aGVyIGl0IGNvdWxkIHJldXNlIHRoZSBlbnRy eSBmaWVsZCBjb250YWluZWQgaW4gdGhlIFVEUCB0dW5uZWwgaGVhZGVyIHdoZW4gcmVlbmNhcHN1 bGF0aW5nIChzZWUgdGhlIGJlbG93IHRleHQgcXVvdGVkIGZyb20gLTAzIHZlcnNpb24gb2YgZHJh ZnQteHUqKSBpbiB0aGUgU1JvVURQIGNhc2UsIGluIGFkZGl0aW9uIHRvIGFkdmVydGlzaW5nIHRo YXQgaXQgY291bGQgZGVjYXBzdWxhdGUgTVBMU29VRFAgcGFja2V0Pw0KDQoiLi4uVG8gYXZvaWQg cmUtcGVyZm9ybWluZyBoYXNoIG9uIHRoZSB3aG9sZSBwYWNrZXQgd2hlbiByZS1lbmNhcHN1bGF0 aW5nDQogICB0aGUgcGFja2V0IHdpdGggYW4gSVAtYmFzZWQgdHVubmVsIGhlYWRlciwgaXQncyBS RUNPTU1FTkRFRCB0aGF0IHRoZQ0KICAgZW50cm9weSB2YWx1ZSBjb250YWluZWQgaW4gdGhlIHBh Y2tldCAoZS5nLiwgdGhlIFVEUCBzb3VyY2UgcG9ydA0KICAgdmFsdWUpIGlzIGtlcHQgd2hlbiBz dHJpcHBpbmcgdGhlIElQLWJhc2VkIHR1bm5lbCBoZWFkZXIgKGUuZy4sIHRoZQ0KICAgVURQIHR1 bm5lbCBoZWFkZXIpLiAgQXMgc3VjaCwgdGhlIGVudHJvcHkgdmFsdWUgY291bGQgYmUgZGlyZWN0 bHkNCiAgIGNvcGllZCB0byB0aGUgZW50cm9weSBmaWVsZCAoZS5nLiwgdGhlIHNvdXJjZSBwb3J0 IG9mIHRoZSBVRFAgdHVubmVsDQogICBoZWFkZXIpIHdoZW4gcmUtZW5jYXBzdWxhdGluZyB0aGUg cGFja2V0IHdpdGggYW4gSVAtYmFzZWQgdHVubmVsDQogICBoZWFkZXIgKGUuZy4sIFVEUCB0dW5u ZWwgaGVhZGVyKS4gIC4uLiINCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCg0KPiAgICAgQmVz dCByZWdhcmRzLA0KPiAgICAgWGlhb2h1DQo+IA0KPiAgICAgPiAgICAgQmVzdCByZWdhcmRzLA0K PiAgICAgPiAgICAgWGlhb2h1DQo+ICAgICA+DQo+ICAgICA+ICAgICA+IE9uIDE0LzA4LzIwMTcs IDA0OjU4LCAiVW1hIENodW5kdXJpIg0KPiA8dW1hLmNodW5kdXJpQGh1YXdlaS5jb20+DQo+ICAg ICA+IHdyb3RlOg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgV2ltIC0NCj4gICAg ID4gICAgID4NCj4gICAgID4gICAgID4gICAgIFRoYXQncyBiZWVuIGRlc2NyaWJlZCAgaGVyZToN Cj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4NCj4gICAgID4NCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQteHUtbXBscy11bmlmaWVkLXNvdXJjZS1yb3V0 aW5nLWluc3RydWN0aW9uLTAzLnR4dA0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAg LS0NCj4gICAgID4gICAgID4gICAgIFVtYSBDLg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAg PiAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gICAgID4gICAgID4gICAgIEZyb206 IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4g ICAgID4gSGVuZGVyaWNreCwNCj4gICAgID4gICAgID4gV2ltIChOb2tpYSAtIEJFL0FudHdlcnAp DQo+ICAgICA+ICAgICA+ICAgICBTZW50OiBTdW5kYXksIEF1Z3VzdCAxMywgMjAxNyA2OjU1IFBN DQo+ICAgICA+ICAgICA+ICAgICBUbzogYWRyaWFuQG9sZGRvZy5jby51azsgc3ByaW5nQGlldGYu b3JnDQo+ICAgICA+ICAgICA+ICAgICBTdWJqZWN0OiBSZTogW3NwcmluZ10gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gICAgID4gICAgID4gZHJhZnQtYnJ5YW50LW1wbHMtdW5p ZmllZC1pcC1zci0wMS50eHQNCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgIFRoZSBk cmFmdCBvbmx5IGRlZmluZXMgcHJvY2VkdXJlcyBmb3IgU1JvSVAgRTJFLCB3aHkgZG9u4oCZdA0K PiB3ZQ0KPiAgICAgPiBlbnZpc2lvbg0KPiAgICAgPiAgICAgPiBTUm9JUCB0byBJbnRlcndvcmsg d2l0aCBuYXRpdmUgTVBMUy1TUi4NCj4gICAgID4gICAgID4gICAgIFdoYXQgSSBtZWFuIGlzIHdo ZW4gdXNpbmcgdGhlIFNSb0lQIHByb2NlZHVyZXMgdGhlIGRyYWZ0DQo+IHVzZXMNCj4gICAgID4g U1JvSVAgYXQNCj4gICAgID4gICAgID4gZXZlcnkgaG9wIHdoaWNoIGlzIFNSIGNhcGFibGUuDQo+ ICAgICA+ICAgICA+ICAgICBZb3UgY291bGQgZW52aXNpb24gY2VydGFpbiBzZWdtZW50cyB0byBk byBTUm9JUCBhbmQgb3RoZXINCj4gICAgID4gc2VnbWVudHMgdG8NCj4gICAgID4gICAgID4gaGF2 ZSBuYXRpdmUgTVBMUy1TUiBjYXBhYmlsaXR5Lg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAg PiAgICAgU28gbXkgcXVlc3Rpb24gaXMgdGhpcyBpbiBzY29wZSBvZiB0aGlzIGRyYWZ0Pw0KPiAg ICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgT24gMTEvMDgvMjAxNywgMjA6NDcsICJzcHJp bmcgb24gYmVoYWxmIG9mIEFkcmlhbiBGYXJyZWwiDQo+ICAgICA+ICAgICA+IDxzcHJpbmctYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWRyaWFuQG9sZGRvZy5jby51az4NCj4gd3JvdGU6 DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ICAgICAgICAgSGkgYWxsLA0KPiAgICAgPiAg ICAgPg0KPiAgICAgPiAgICAgPiAgICAgICAgIFNQUklORyBkaWRuJ3QgbWVldCBpbiBQcmFndWUg c28gSSBwcmVzZW50ZWQgdGhpcyB3b3JrIGluDQo+IE1QTFMuDQo+ICAgICA+IEJydW5vDQo+ICAg ICA+ICAgICA+IHN1Z2dlc3RlZA0KPiAgICAgPiAgICAgPiAgICAgICAgIHRoYXQgbWF5YmUgU1BS SU5HIHdvdWxkIGJlIGEgYmV0dGVyIHZlbnVlLg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAg PiAgICAgICAgIEknbSBub3Qgc3VyZSBhYm91dCB0aGF0LCBhbHRob3VnaCBJIGRvIHRoaW5rIGJv dGggV0dzDQo+IHNob3VsZA0KPiAgICAgPiBjaGF0DQo+ICAgICA+ICAgICA+IGFib3V0IHRoZQ0K PiAgICAgPiAgICAgPiAgICAgICAgIGlkZWFzLg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAg PiAgICAgICAgIFRoZSBlc3NlbmNlIG9mIHRoaXMgd29yayBpcyBub3RoaW5nIG1vcmUgdGhhdCBN UExTLVNSDQo+ICAgICA+IGVuY2Fwc3VsYXRlZA0KPiAgICAgPiAgICAgPiBpbiBVRFAgcGVyDQo+ ICAgICA+ICAgICA+ICAgICAgICAgUkZDIDc1MTAuIFdoYXQgaXQgYWNoaWV2ZXMgaXMgYSB3YXkg dG8gb2J0YWluIHRoZSBTUg0KPiAgICAgPiBmdW5jdGlvbmFsaXR5IHRoYXQNCj4gICAgID4gICAg ID4gd2UgYWxsDQo+ICAgICA+ICAgICA+ICAgICAgICAga25vdyBhbmQgbG92ZSBpbiBhbiBJUCBu ZXR3b3JrLg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgICAgIFRoZSBhcHByb2Fj aCBpcywgb2YgY291cnNlLCBjb21wYXRpYmxlIHdpdGggTVBMUy1TUi4gQXMNCj4gdGhlDQo+ICAg ICA+IGRyYWZ0DQo+ICAgICA+ICAgICA+IHNheXMuLi4NCj4gICAgID4gICAgID4NCj4gICAgID4g ICAgID4gICAgICAgICAgICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhlIHNl Z21lbnQNCj4gcm91dGluZw0KPiAgICAgPiAgICAgPiBhcmNoaXRlY3R1cmUNCj4gICAgID4gICAg ID4gICAgICAgICAgICBhbmQgYnVpbGRzIG9uIGV4aXN0aW5nIHByb3RvY29sIG1lY2hhbmlzbXMg c3VjaCBhcw0KPiB0aGUNCj4gICAgID4gICAgID4gZW5jYXBzdWxhdGlvbg0KPiAgICAgPiAgICAg PiAgICAgICAgICAgIG9mIE1QTFMgd2l0aGluIFVEUCBkZWZpbmVkIGluIFJGQyA3NTEwLg0KPiAg ICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgICAgICAgIE5vIG5ldyBwcm9jZWR1cmVzIGFy ZSBpbnRyb2R1Y2VkLCBidXQgZXhpc3RpbmcNCj4gICAgID4gbWVjaGFuaXNtcyBhcmUNCj4gICAg ID4gICAgID4gICAgICAgICAgICBjb21iaW5lZCB0byBhY2hpZXZlIHRoZSBkZXNpcmVkIHJlc3Vs dC4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgICAgICBUaGlzIGlzIG5vdCBpbnRl bmRlZCB0byBiZSBhIGJlYXV0eSBjb250ZXN0IHdpdGggU1J2Ni4gQXMNCj4gdGhlDQo+ICAgICA+ IGRyYWZ0DQo+ICAgICA+ICAgICA+IHNheXMuLi4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAg ID4gICAgICAgICAgICBUaGUgbWV0aG9kIGRlZmluZWQgaXMgYSBjb21wbGVtZW50YXJ5IHdheSBv Zg0KPiBydW5uaW5nIFNSDQo+ICAgICA+IGluIGFuIElQDQo+ICAgICA+ICAgICA+ICAgICAgICAg ICAgbmV0d29yayB0aGF0IGNhbiBiZSB1c2VkIGFsb25nc2lkZSBvcg0KPiBpbnRlcmNoYW5nZWFi bHkgd2l0aA0KPiAgICAgPiB0aGF0DQo+ICAgICA+ICAgICA+ICAgICAgICAgICAgZGVmaW5lZCBp biBbSS1ELmlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyXS4NCj4gICAgID4gSW1wbGVt ZW50ZXJzDQo+ICAgICA+ICAgICA+IGFuZA0KPiAgICAgPiAgICAgPiAgICAgICAgICAgIGRlcGxv eWVycyBzaG91bGQgY29uc2lkZXIgdGhlIGJlbmVmaXRzIGFuZA0KPiBkcmF3YmFja3Mgb2YNCj4g ICAgID4gZWFjaA0KPiAgICAgPiAgICAgPiBtZXRob2QNCj4gICAgID4gICAgID4gICAgICAgICAg ICBhbmQgc2VsZWN0IHRoZSBhcHByb2FjaCBtb3N0IHN1aXRlZCB0byB0aGVpciBuZWVkcy4NCj4g ICAgID4gICAgID4NCj4gICAgID4gICAgID4gICAgICAgICBUaGFua3MsDQo+ICAgICA+ICAgICA+ ICAgICAgICAgQWRyaWFuDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ICAgICAgICAgPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICA+ICAgICA+ICAg ICAgICAgPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gICAgID4gICAgID4gICAg ICAgICA+IFNlbnQ6IDExIEF1Z3VzdCAyMDE3IDE5OjM5OjU5IChVVEMrMDA6MDApIER1YmxpbiwN Cj4gICAgID4gRWRpbmJ1cmdoLA0KPiAgICAgPiAgICAgPiBMaXNib24sIExvbmRvbg0KPiAgICAg PiAgICAgPiAgICAgICAgID4gVG86IFN0ZXdhcnQgQnJ5YW50OyBKb2huIEUgRHJha2U7IEFkcmlh biBGYXJyZWwNCj4gICAgID4gICAgID4gICAgICAgICA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCj4gICAgID4gICAgID4gZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1p cC1zci0wMS50eHQNCj4gICAgID4gICAgID4gICAgICAgICA+DQo+ICAgICA+ICAgICA+ICAgICAg ICAgPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwNCj4gZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1p cC1zci0wMS50eHQNCj4gICAgID4gICAgID4gICAgICAgICA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgQWRyaWFuIEZhcnJlbCBhbmQNCj4gcG9zdGVkDQo+ICAgICA+IHRvIHRo ZQ0KPiAgICAgPiAgICAgPiAgICAgICAgID4gSUVURiByZXBvc2l0b3J5Lg0KPiAgICAgPiAgICAg PiAgICAgICAgID4NCj4gICAgID4gICAgID4gICAgICAgICA+IE5hbWU6ICAgICAgICAgICBkcmFm dC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyDQo+ICAgICA+ICAgICA+ICAgICAgICAgPiBSZXZp c2lvbjogICAgICAgMDENCj4gICAgID4gICAgID4gICAgICAgICA+IFRpdGxlOiAgICAgICAgICBB IFVuaWZpZWQgQXBwcm9hY2ggdG8gSVAgU2VnbWVudA0KPiBSb3V0aW5nDQo+ICAgICA+ICAgICA+ ICAgICAgICAgPiBEb2N1bWVudCBkYXRlOiAgMjAxNy0wOC0xMQ0KPiAgICAgPiAgICAgPiAgICAg ICAgID4gR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiAgICAgPiAgICAg PiAgICAgICAgID4gUGFnZXM6ICAgICAgICAgIDE2DQo+ICAgICA+ICAgICA+ICAgICAgICAgPiBV Ukw6DQo+ICAgICA+ICAgICA+DQo+ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNyLQ0KPiAgICAgPiAgICAgPiAg ICAgICAgID4gMDEudHh0DQo+ICAgICA+ICAgICA+ICAgICAgICAgPiBTdGF0dXM6DQo+ICAgICA+ ICAgICA+DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyeWFudC1t cGxzLXVuaWZpZWQtaXAtc3IvDQo+ICAgICA+ICAgICA+ICAgICAgICAgPiBIdG1saXplZDoNCj4g ICAgID4gICAgID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyeWFudC1tcGxz LXVuaWZpZWQtaXAtc3ItMDENCj4gICAgID4gICAgID4gICAgICAgICA+IEh0bWxpemVkOg0KPiAg ICAgPiAgICAgPg0KPiAgICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWJyeWFudC1tcGxzLXVuaWZpZWQtaXAtDQo+ICAgICA+ICAgICA+ICAgICAgICAgPiBz ci0wMQ0KPiAgICAgPiAgICAgPiAgICAgICAgID4gRGlmZjoNCj4gICAgID4gICAgID4NCj4gICAg ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJyeWFudC1tcGxzLXVu aWZpZWQtaXAtc3ItMDENCj4gICAgID4gICAgID4gICAgICAgICA+DQo+ICAgICA+ICAgICA+ICAg ICAgICAgPiBBYnN0cmFjdDoNCj4gICAgID4gICAgID4gICAgICAgICA+ICAgIFNlZ21lbnQgcm91 dGluZyBpcyBhIHNvdXJjZSByb3V0ZWQgZm9yd2FyZGluZw0KPiBtZXRob2QNCj4gICAgID4gdGhh dA0KPiAgICAgPiAgICAgPiBhbGxvd3MNCj4gICAgID4gICAgID4gICAgICAgICA+ICAgIHBhY2tl dHMgdG8gYmUgc3RlZXJlZCB0aHJvdWdoIGEgbmV0d29yayBvbiBwYXRocw0KPiBvdGhlcg0KPiAg ICAgPiB0aGFuIHRoZQ0KPiAgICAgPiAgICAgPiAgICAgICAgID4gICAgc2hvcnRlc3QgcGF0aCBk ZXJpdmVkIGZyb20gdGhlIHJvdXRpbmcgcHJvdG9jb2wuDQo+IFRoZQ0KPiAgICAgPiBhcHByb2Fj aA0KPiAgICAgPiAgICAgPiB1c2VzDQo+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBpbmZvcm1h dGlvbiBlbmNvZGVkIGluIHRoZSBwYWNrZXQgaGVhZGVyIHRvDQo+IHBhcnRpYWxseSBvcg0KPiAg ICAgPiAgICAgPiBjb21wbGV0ZWx5DQo+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBzcGVjaWZ5 IHRoZSByb3V0ZSB0aGUgcGFja2V0IHRha2VzIHRocm91Z2ggdGhlDQo+IG5ldHdvcmssDQo+ICAg ICA+IGFuZA0KPiAgICAgPiAgICAgPiBkb2VzIG5vdA0KPiAgICAgPiAgICAgPiAgICAgICAgID4g ICAgbWFrZSB1c2Ugb2YgYSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcHJlLWluc3RhbGwNCj4gcGF0 aHMgaW4gdGhlDQo+ICAgICA+ICAgICA+IG5ldHdvcmsuDQo+ICAgICA+ICAgICA+ICAgICAgICAg Pg0KPiAgICAgPiAgICAgPiAgICAgICAgID4gICAgVHdvIGRpZmZlcmVudCBlbmNhcHN1bGF0aW9u cyBoYXZlIGJlZW4gZGVmaW5lZCB0bw0KPiBlbmFibGUNCj4gICAgID4gICAgID4gc2VnbWVudA0K PiAgICAgPiAgICAgPiAgICAgICAgID4gICAgcm91dGluZyBpbiBhbiBNUExTIG5ldHdvcmsgYW5k IGluIGFuIElQdjYNCj4gbmV0d29yay4NCj4gICAgID4gV2hpbGUNCj4gICAgID4gICAgID4gICAg ICAgICA+ICAgIGFja25vd2xlZGdpbmcgdGhhdCB0aGVyZSBpcyBhIHN0cm9uZyBuZWVkIHRvDQo+ IHN1cHBvcnQNCj4gICAgID4gc2VnbWVudA0KPiAgICAgPiAgICAgPiByb3V0aW5nDQo+ICAgICA+ ICAgICA+ICAgICAgICAgPiAgICBpbiBib3RoIGVudmlyb25tZW50cywgdGhpcyBkb2N1bWVudCBk ZWZpbmVzIGENCj4gICAgID4gY29udmVyZ2VkLA0KPiAgICAgPiAgICAgPiB1bmlmaWVkDQo+ICAg ICA+ICAgICA+ICAgICAgICAgPiAgICBhcHByb2FjaCB0byBzZWdtZW50IHJvdXRpbmcgdGhhdCBl bmFibGVzIGEgc2luZ2xlDQo+ICAgICA+IG1lY2hhbmlzbSB0bw0KPiAgICAgPiAgICAgPiBiZQ0K PiAgICAgPiAgICAgPiAgICAgICAgID4gICAgYXBwbGllZCBpbiBib3RoIHR5cGVzIG9mIG5ldHdv cmsuICBUaGUgcmVzdWx0aW5nDQo+ICAgICA+IGFwcHJvYWNoIGlzDQo+ICAgICA+ICAgICA+IGFs c28NCj4gICAgID4gICAgID4gICAgICAgICA+ICAgIGFwcGxpY2FibGUgdG8gSVB2NCBuZXR3b3Jr cyB3aXRob3V0IHRoZSBuZWVkIGZvcg0KPiBhbnkNCj4gICAgID4gY2hhbmdlcyB0bw0KPiAgICAg PiAgICAgPiB0aGUNCj4gICAgID4gICAgID4gICAgICAgICA+ICAgIElQdjQgc3BlY2lmaWNhdGlv bi4NCj4gICAgID4gICAgID4gICAgICAgICA+DQo+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBU aGlzIGRvY3VtZW50IG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhlIHNlZ21lbnQNCj4gcm91dGluZw0K PiAgICAgPiAgICAgPiBhcmNoaXRlY3R1cmUNCj4gICAgID4gICAgID4gICAgICAgICA+ICAgIGFu ZCBidWlsZHMgb24gZXhpc3RpbmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBzdWNoDQo+IGFzIHRoZQ0K PiAgICAgPiAgICAgPiBlbmNhcHN1bGF0aW9uDQo+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBv ZiBNUExTIHdpdGhpbiBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCj4gICAgID4gICAgID4gICAg ICAgICA+DQo+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBObyBuZXcgcHJvY2VkdXJlcyBhcmUg aW50cm9kdWNlZCwgYnV0IGV4aXN0aW5nDQo+ICAgICA+IG1lY2hhbmlzbXMgYXJlDQo+ICAgICA+ ICAgICA+ICAgICAgICAgPiAgICBjb21iaW5lZCB0byBhY2hpZXZlIHRoZSBkZXNpcmVkIHJlc3Vs dC4NCj4gICAgID4gICAgID4gICAgICAgICA+DQo+ICAgICA+ICAgICA+ICAgICAgICAgPg0KPiAg ICAgPiAgICAgPiAgICAgICAgID4NCj4gICAgID4gICAgID4gICAgICAgICA+DQo+ICAgICA+ICAg ICA+ICAgICAgICAgPg0KPiAgICAgPiAgICAgPiAgICAgICAgID4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20NCj4gdGhlDQo+ICAgICA+IHRpbWUg b2YNCj4gICAgID4gICAgID4gc3VibWlzc2lvbg0KPiAgICAgPiAgICAgPiAgICAgICAgID4gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiAgICAg PiB0b29scy5pZXRmLm9yZy4NCj4gICAgID4gICAgID4gICAgICAgICA+DQo+ICAgICA+ICAgICA+ ICAgICAgICAgPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAg ICAgPiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ICAgICA+ICAgICA+ICAgICAgICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgPiAg ICAgPiAgICAgICAgIHNwcmluZ0BpZXRmLm9yZw0KPiAgICAgPiAgICAgPiAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ICAgICA+ICAgICA+DQo+ ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiAgICAgPiAgICAgc3ByaW5nIG1haWxpbmcg bGlzdA0KPiAgICAgPiAgICAgPiAgICAgc3ByaW5nQGlldGYub3JnDQo+ICAgICA+ICAgICA+ICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiAgICAgPiAg ICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiAgICAgPiBz cHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICA+ICAgICA+IHNwcmluZ0BpZXRmLm9yZw0KPiAgICAg PiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiAg ICAgPg0KPiANCj4gDQoNCg== From nobody Mon Aug 14 03:59:26 2017 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 C3E9C132196 for ; Mon, 14 Aug 2017 03:59:24 -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] 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 z0yf7zfkl1Tc for ; Mon, 14 Aug 2017 03:59:23 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45571320D8 for ; Mon, 14 Aug 2017 03:59:21 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7EAxJhB018976; Mon, 14 Aug 2017 11:59:19 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7EAxILC018957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Aug 2017 11:59:19 +0100 Reply-To: From: "Adrian Farrel" To: "'Henderickx, Wim \(Nokia - BE/Antwerp\)'" , References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> In-Reply-To: <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> Date: Mon, 14 Aug 2017 11:59:19 +0100 Message-ID: <009b01d314ec$6156eb40$2404c1c0$@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: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDAUp9c4QBwpGvJKIwgGtw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23256.006 X-TM-AS-Result: No--9.218-10.0-31-10 X-imss-scan-details: No--9.218-10.0-31-10 X-TMASE-MatchedRID: HXSqh3WYKfs4HKI/yaqRm6hfOb9ZVXujV7oOVXNbrO27qpOHKudqc3fE ZMKlnNGA+7WepgqHngeUb4B0xTyAdTa9BTI9OTwhDB+ErBr0bANAwbB39AVwlh1u7K8HqaNcb4w S3DNipbw1h4k5lhc/pcuuAuqFdHuH/pS/akpdRW8D2WXLXdz+ASseSAhqf1rRULzpjrEhojrGN8 n6L6dsdAVJt0rD30YalwoWmxp8GUD9z9LbkfiOG7ybDkcAszYRvhf/zJ92tsMgcyGevtftJ6PFj JEFr+olSXhbxZVQ5H+OhzOa6g8KrfLbDGZLBS1CsTecJq/FhALqlWRvYwzuZJSBViV84gr/1YA1 z04vV4VDDKa3G4nrLQ== Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 10:59:25 -0000 Hi Wim, > The draft only defines procedures for SRoIP E2E, why don=E2=80=99t we = envision SRoIP to > Interwork with native MPLS-SR. : > You could envision certain segments to do SRoIP and other segments to = have > native MPLS-SR capability. Yes, the "mixed mode" is both interesting and useful. In fact, this comes "for free". Consider the example in Figure 3 where = UDP is used to connect two SR domains. Now consider that the domains = could be any size, the tunnel could be any length, and the picture could = be repeated concatenating multiple instance. Furthermore, the picture need not be fully symmetrical. That is, one end = of the flow could be a "domain" and the other could be a single (ingress = or egress) router. > So my question is this in scope of this draft? So, yes, definitely in scope. If you feel this could be usefully described we'll add text, but I = suspect it just follows and we only need to add a short note. But... > What I mean is when using the SRoIP procedures the draft uses SRoIP at = every > hop which is SR capable. Not the case. As shown in Figure 4 and discussed in sections 5.3 and = 5.4, there may be transit routers on the path. These may be native IP = (i.e.) legacy routers, or SR-capable routers that are simply not = explicitly part of the SR path. Only the nodes explicitly mentioned in = the SR path become UDP end points and do the SRoIP procedures. Cheers, Adrian From nobody Mon Aug 14 04:53:18 2017 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 CCA98126BFD for ; Mon, 14 Aug 2017 04:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 qC9qa71HQ1eM for ; Mon, 14 Aug 2017 04:53:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB98C1320D8 for ; Mon, 14 Aug 2017 04:53:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7EBr5vl017534; Mon, 14 Aug 2017 12:53:05 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7EBr4hM017520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Aug 2017 12:53:05 +0100 Reply-To: From: "Adrian Farrel" To: "'Xuxiaohu'" Cc: Date: Mon, 14 Aug 2017 12:53:05 +0100 Message-ID: <00ae01d314f3$e48fe3c0$adafab40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMU89AAsfL0PVBJRpuesDlAE//NTg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23256.006 X-TM-AS-Result: No--1.543-10.0-31-10 X-imss-scan-details: No--1.543-10.0-31-10 X-TMASE-MatchedRID: tUbeCmUk5wEO0G36v8LMKkKcYi5Qw/RVy9Hr9JMbCJMNmPMcsvd5FtS+ SqhZzDZ1QcV2t2YzAY29Sk0l35T/M+0MldyiyN3jSEQN/D/3cG5qYquCrLrVwufL+zKjW08P+dn qkV8n1AaxXlUFV6Mg54rQG4TivKaHxzvHgMQjo/ZtD1qg9KZYkVwKy6arPaSXt753XvI27mw6qd xtMsrheOBmZBH3ZVRSh9VyngslPv0gNXYDo2rRhriMC5wdwKqdLdLfmiFS7fsKXKtfi06bFKPFj JEFr+olIoOsWgr8s12OhzOa6g8KrSW+7MLKq2m3SPJKhb+5BqCJYxYfLfvF9KDRPijHlrRqCRHo iGAQEeY9Mvj3gs4Iok6riMCB2bab/w6JWubvxmIo1xw4e3VSVyXidVjAhEZBrX7cmKNisA4yqaE b8zSjj/QwfDO7YmjAf+weolWHdq6UTGVAhB5EbQ== Archived-At: Subject: [spring] Author/contributor [Was: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt] X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 11:53:17 -0000 Greetings Xiaohu, > When=A0you=A0submitted=A0the=A0-00 = version=A0of=A0this=A0draft=A0with=A0my=A0name=A0being=A0listed=A0in >=A0the=A0coauthor=A0list=A0but=A0without=A0my=A0permission,=A0I=A0tolera= ted=A0it=A0so=A0as=A0to=A0give=A0face =A0to >=A0you,=A0although=A0it=A0had=A0caused=A0unnecessary=A0confusion=A0in=A0= the=A0IETF,=A0especially=A0amon g >=A0the=A0coauthors=A0of=A0draft-xu-mpls-unified-source-routing-instructi= on. It was so very kind of you to consider my face and to not send any mail = about this to a public list. It might also have helped reduce the confusion if you had told me of = your objection as soon as -00 was posted. Without that, I could not (of = course) have any visibility into the intricacies of Huawei management and had to = assume that all names of Huawei staff proposed for inclusion on the draft were there = because they were supposed to be. Still here we are... > This=A0time=A0you=A0submitted=A0-01=A0version=A0with=A0my=A0name=A0being=A0= added=A0into=A0the=A0contributo r=A0 > list=A0but=A0without=A0my=A0permission=A0as=A0well.=A0I=A0have=A0to=A0rem= ind=A0you:=A0don't=A0repeat=A0such >=A0impolite=A0actions. Yes, it is important to be polite at all times, isn't it? We'd be delighted to remove your name from future revisions. But we have = to navigate a small piece of IETF process to establish you as not an author = or contributor for IPR and copyright reasons. The easiest way for you to do = this is to send simple email to this list saying something like "I confirm that = I did not write any of the text appearing in = draft-bryant-mpls-unified-ip-sr-01 and there is no reason for me to be listed as an author or contributor." If = you can do that we can issue the new revision. Thanks, Adrian From nobody Mon Aug 14 20:41:43 2017 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 C8D50132190 for ; Mon, 14 Aug 2017 20:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 sKxtQAHGJ1pu for ; Mon, 14 Aug 2017 20:41:38 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0135.outbound.protection.outlook.com [104.47.2.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451BE132125 for ; Mon, 14 Aug 2017 20:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NUAac0Cj+MAXmKo3oLpwZ5AsxL39JPVVUUoyj6qk7Sw=; b=Ob3xWQdFOYlj2WNIJhmYGJF55RhO9zkfkMhLLWh+wbw/9xX4Vx/FibJw/pKnp0OlcLf8iMKnFWgbPGHcfFHJc70Eiy+o2YBd/cTh8EM5yBKOBVvtvgUCqVbXc38PaqkbDTrB/HivMnPKAZKQMfGNo6oj0cIewXJOwengonGudrE= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0609.eurprd07.prod.outlook.com (10.160.54.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Tue, 15 Aug 2017 03:41:35 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651%14]) with mapi id 15.01.1362.012; Tue, 15 Aug 2017 03:41:35 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: Xuxiaohu , Uma Chunduri , "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: =?utf-8?B?W3NwcmluZ10g562U5aSNOiAg562U5aSNOiAg562U5aSNOiAgRlc6IE5ldyBW?= =?utf-8?B?ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJ5YW50LW1wbHMtdW5p?= =?utf-8?Q?fied-ip-sr-01.txt?= Thread-Index: AQHTFXhkj194ClzfK0q54lKkwbeSGw== Date: Tue, 15 Aug 2017 03:41:35 +0000 Message-ID: <2CD66AAE-0244-4506-AA4B-51107E13B932@nokia.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC01E8B@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC01E8B@NKGEML515-MBX.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170725 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [135.245.212.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0609; 6:yc4uBbzsmwkBjQF4srfGIObdbhJfYUQv8WAH6lpWyKD4IaH35VWV3EtOzK4i3D1Wn3NE+f+otgaBQMMqxwInqFz0KrvDYGQhMvvjygkelnNu6Ec566KJmkMcxnPOTd8pQAMIBEMyQ6JY0rrnYrad3O1oYe6oCIPlrUUGoel717bdVGlKrAt70DB8ERlTKKZLyn100UYgPLWQlN7GOGyRPRbICkGAjHkCl8VaCZjTN53NujaApJNMQBOXoSW38PLr7y2t4D2xIemDeMNELivggvnkZQH0+EmnEZw+HtI1amTS+Fljl1GeWihibWhino9RMK2K/Vxx4bWD+krtjSb89Q==; 5:YPLrtlFQB32ZjycBagE2aJZ+dXHuhhYqh4FEIhDma6ObwVz3pmv60Azj+oDXFqwTyrksSsxgA6KYCwdzGxHB03DtjvjkNxvbxxnFQEJwvrpBx2yGGDRMCKqERTIQNWIkpy/dgjKKdL5TSNxoHtNqIA==; 24:RdEHTV2EfB+3LM+X+Ytu+pwapsddNygMUDa6oyivfoMHNz2CNadOGMRuWBELo5LHIamdWX2KuhgU9JpMa0PvvjI77s6293kOC/T4Vt8m3Mc=; 7:CHVKu98xgxa8owQlPgvV3HdnEHEGiS74EJuzZVZTcMU43R127DbEucx04hA+M4knW4L6tq/bPk7kOgLSD1Nv/oVQo9UxA01WNDDIgc09SKzSwgzsixr97rQZroA6RPSdRhSkwtYg/HJS8MwgfJptjFQ5lnxxvzYRqIsvdNxcxgavqoF8/EZOWXRD5UsAEl/zS3pMyLTXNCaGrUBMZJj5SSnBuwbu7R6njaUZkRfudks= x-ms-office365-filtering-correlation-id: 0e404916-f14c-4c57-c08f-08d4e38f8730 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0609; x-ms-traffictypediagnostic: AM2PR07MB0609: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513)(82608151540597); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0609; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0609; x-forefront-prvs: 04004D94E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(24454002)(199003)(53754006)(13464003)(377454003)(189002)(377424004)(3846002)(305945005)(189998001)(6506006)(2501003)(5250100002)(2950100002)(229853002)(53946003)(2201001)(2906002)(2900100001)(230783001)(66066001)(83716003)(6486002)(83506001)(3660700001)(97736004)(5660300001)(33656002)(4001350100001)(3280700002)(101416001)(966005)(50986999)(102836003)(76176999)(14454004)(68736007)(54356999)(6246003)(6512007)(82746002)(99286003)(6306002)(36756003)(15650500001)(81156014)(86362001)(81166006)(53546010)(6116002)(25786009)(53936002)(224303003)(478600001)(8936002)(105586002)(6436002)(7736002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0609; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9EA60859A4E9E44592B798BF076B14D6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 03:41:35.2624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0609 Archived-At: Subject: Re: [spring] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAgRlc6IE5l?= =?utf-8?q?w_Version_Notification_for_draft-bryant-mpls-unified-ip-sr-01?= =?utf-8?q?=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 03:41:42 -0000 SW4tbGluZQ0KDQpPbiAxNC8wOC8yMDE3LCAwMDozMCwgInNwcmluZyBvbiBiZWhhbGYgb2YgWHV4 aWFvaHUiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgeHV4aWFvaHVAaHVh d2VpLmNvbT4gd3JvdGU6DQoNCiAgICANCiAgICANCiAgICA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCiAgICA+IOWPkeS7tuS6ujogSGVuZGVyaWNreCwgV2ltIChOb2tpYSAtIEJFL0FudHdlcnAp DQogICAgPiBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QG5va2lhLmNvbV0NCiAgICA+IOWPkemAgeaX tumXtDogMjAxN+W5tDjmnIgxNOaXpSAxNToxOA0KICAgID4g5pS25Lu25Lq6OiBYdXhpYW9odTsg VW1hIENodW5kdXJpOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBzcHJpbmdAaWV0Zi5vcmcNCiAgICA+ IOS4u+mimDogUmU6IOetlOWkjTog562U5aSNOiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KICAgID4gZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50 eHQNCiAgICA+IA0KICAgID4gTW9yZSBpbi1saW5lDQogICAgPiANCiAgICA+IE9uIDE0LzA4LzIw MTcsIDA5OjExLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCiAgICA+ IA0KICAgID4gICAgIEhpIFdpbSwNCiAgICA+IA0KICAgID4gICAgID4gLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KICAgID4gICAgID4g5Y+R5Lu25Lq6OiBIZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0g QkUvQW50d2VycCkNCiAgICA+ICAgICA+IFttYWlsdG86d2ltLmhlbmRlcmlja3hAbm9raWEuY29t XQ0KICAgID4gICAgID4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDE05pelIDE1OjAzDQogICAg PiAgICAgPiDmlLbku7bkuro6IFh1eGlhb2h1OyBVbWEgQ2h1bmR1cmk7IGFkcmlhbkBvbGRkb2cu Y28udWs7IHNwcmluZ0BpZXRmLm9yZw0KICAgID4gICAgID4g5Li76aKYOiBSZTog562U5aSNOiBb c3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KICAgID4gICAgID4gZHJh ZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCiAgICA+ICAgICA+DQogICAgPiAg ICAgPiBJbi1saW5lDQogICAgPiAgICAgPg0KICAgID4gICAgID4gT24gMTQvMDgvMjAxNywgMDg6 NDEsICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KICAgID4gICAgID4N CiAgICA+ICAgICA+ICAgICBIaSBXaW0sDQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgID4g LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KICAgID4gICAgID4gICAgID4g5Y+R5Lu25Lq6OiBzcHJp bmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQogICAgPiBIZW5kZXJp Y2t4LCBXaW0NCiAgICA+ICAgICA+IChOb2tpYQ0KICAgID4gICAgID4gICAgID4gLSBCRS9BbnR3 ZXJwKQ0KICAgID4gICAgID4gICAgID4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDE05pelIDE0 OjI3DQogICAgPiAgICAgPiAgICAgPiDmlLbku7bkuro6IFVtYSBDaHVuZHVyaTsgYWRyaWFuQG9s ZGRvZy5jby51azsgc3ByaW5nQGlldGYub3JnDQogICAgPiAgICAgPiAgICAgPiDkuLvpopg6IFJl OiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KICAgID4gICAgID4g ICAgID4gZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMS50eHQNCiAgICA+ICAgICA+ ICAgICA+DQogICAgPiAgICAgPiAgICAgPiBBbHNvIHRoaXMgZHJhZnQgZG9lc27igJl0IGRlc2Ny aWJlIHRoaXMgdXNlIGNhc2UgYWZhaXMuIFdoYXQgSSBhbQ0KICAgID4gdGFraW5nDQogICAgPiAg ICAgPiBhYm91dCBpcw0KICAgID4gICAgID4gICAgID4gdGhpczoNCiAgICA+ICAgICA+ICAgICA+ IFVzaW5nIE1QTFMtU1IgZm9yIHRoZSBTSUQgdG8gRyBhbmQgU0lEIHRvIEggaXNvIHVzaW5nIFNS LVVEUCBTSUQuDQogICAgPiBJcyB0aGlzDQogICAgPiAgICAgPiAgICAgPiBlbnZpc2lvbmVkPw0K ICAgID4gICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgPiAg ICAgICstLS0tLSsgICAgICAgKy0tLS0tKyAgICAgICArLS0tLS0rICAgICAgICArLS0tLS0rDQog ICAgPiArLS0tLS0rDQogICAgPiAgICAgPiAgICAgPiAgICAgIHwgIEEgICstLS0tLS0tKyAgQiAg Ky0tLS0tLS0rICBDICArLS0tLS0tLS0rICBEICArLS0tLS0tLS0rICBIDQogICAgPiB8DQogICAg PiAgICAgPiAgICAgPiAgICAgICstLS0tLSsgICAgICAgKy0tKy0tKyAgICAgICArLS0rLS0rICAg ICAgICArLS0rLS0rDQogICAgPiArLS0tLS0rDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQogICAgPiAgICAgPiAg ICAgPiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8 DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgICAgICAgICAgICAgKy0tKy0tKyAgICAgICArLS0r LS0rICAgICAgICArLS0rLS0rDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgICAgICAgICAgICAg fCAgRSAgKy0tLS0tLS0rICBGICArLS0tLS0tLS0rICBHICB8DQogICAgPiAgICAgPiAgICAgPiAg ICAgICAgICAgICAgICAgICAgKy0tLS0tKyAgICAgICArLS0tLS0rICAgICAgICArLS0tLS0rDQog ICAgPiAgICAgPiAgICAgPg0KICAgID4gICAgID4gICAgID4gICAgICAgICAgICstLS0tLS0tLSsN CiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgICB8SVAoQS0+RSl8DQogICAgPiAgICAgPiAgICAg PiAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KICAgID4g ICAgID4gICAgID4gICAgICAgICAgIHwgIEwoRykgIHwgICAgICAgICAgICAgICAgIHxMKEcpICAg fA0KICAgID4gICAgID4gICAgID4gICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAg ICstLS0tLS0tLSsgICAgICAgICstLS0tLS0tLSsNCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAg ICB8ICBMKEgpICB8ICAgICAgICAgICAgICAgICB8ICBMKEgpICB8DQogICAgPiB8TChIKXwNCiAg ICA+ICAgICA+ICAgICA+ICAgICAgICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICArLS0t LS0tLS0rICAgICAgICArLS0tLS0tLS0rDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgICAgfCBQ YWNrZXQgfCAgIC0tLT4gICAgfCBQYWNrZXQgfCAgLS0tPiAgfCBQYWNrZXQgfA0KICAgID4gICAg ID4gICAgID4gICAgICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICstLS0tLS0tLSsg ICAgICAgICstLS0tLS0tLSsNCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgSW4gZmFjdCwg dGhlIGZpcnN0IHVzZSBjYXNlIGxpc3RlZCBpbiB0aGUgVXNlIENhc2VzIHNlY3Rpb24gdGFsa3Mg YWJvdXQNCiAgICA+IHRoZQ0KICAgID4gICAgID4gaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiBN UExTLVNSLiBJZiB5b3UgYmVsaWV2ZSBpdCdzIG5vdCBjbGVhciBlbm91Z2gsDQogICAgPiB3ZQ0K ICAgID4gICAgID4gY2FuIGFkZCBtb3JlIHRleHQgdG8gY2xhcmlmeSBpdC4gQW55IHByb3Bvc2Vk IHRleHQgaXMgd2VsY29tZS4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBXSD4gaWYgd2Ugd2Fu dCB0byBzdXBwb3J0IHRoaXMgdXNlIGNhc2Ugd2Ugc2hvdWxkIHNwZWxsIHRoaXMgb3V0IG1vcmUN CiAgICA+IGV4cGxpY2l0bHkuDQogICAgPiAgICAgPiBPbiB0b3AgdGhpcyBjb21wbGljYXRlcyB0 aGUgdXNhZ2Ugb2YgZW50cm9weSBiZWNhdXNlIHdpdGggU1JvVURQIHdlDQogICAgPiB1c2UgdGhl DQogICAgPiAgICAgPiBzb3VyY2UgcG9ydCBhbmQgd2hlbiB3ZSB1c2UgbmF0aXZlIFNSb01QTFMg d2UgbG9vc2UgdGhpcy4gSSBiZWxpZXZlIHdlDQogICAgPiBuZWVkDQogICAgPiAgICAgPiB0byBl bmNvZGUgdGhlIGVudHJvcHkgbGFiZWwgaW4gdGhlIHBhY2tldCBmb3IgdGhlIE1QTFMgc2VnbWVu dC4gVGhlIG5leHQNCiAgICA+ICAgICA+IHF1ZXN0aW9uIGlzIHRoYW4gd2hvIHNob3VsZCBhZGQg dGhpcyBlbnRyb3B5IGxhYmVsLiBJcyBpdCB0aGUgc291cmNlIG9yIGlzIGl0DQogICAgPiB0aGUN CiAgICA+ICAgICA+IHRyYW5zaXQgYm94LiBJbiBteSB2aWV3IGl0IHNob3VsZCBiZSBhZGRlZCBh dCB0aGUgc291cmNlIHRha2luZyBSTEQvTVNEDQogICAgPiBpbnRvDQogICAgPiAgICAgPiBhY2Nv dW50LiBPbiB0b3AgeW91IGNhbiBhbHNvIGVudmlzaW9uIGEgdXNlIGNhc2Ugd2hlbiBTUm9NUExT IG5lZWRzDQogICAgPiB0byBtYXANCiAgICA+ICAgICA+IGJhY2sgdG8gU1JvVURQIGluIHdoaWNo IGNhc2UgeW91IHNob3VsZCB1c2UgdGhlIGVudHJvcHkgbGFiZWwgdG8gbWFwDQogICAgPiB0bw0K ICAgID4gICAgID4gU1JvVURQIHNQb3J0IGVudHJvcHkuDQogICAgPiANCiAgICA+ICAgICBWZXJ5 IHVzZWZ1bCBjb21tZW50IGFuZCBzdWdnZXN0aW9uLiBXZSB3aWxsIGluY29ycG9yYXRlIHRoZW0g aW4gdGhlIG5leHQNCiAgICA+IHJldmlzaW9uLg0KICAgID4gDQogICAgPiAgICAgPiAgICAgPiBB bHNvLCBpdCBpcyBhIGJpdCBvZGQgd2UgaGF2ZSBzbyBtYW55IGRyYWZ0cyBvbiB0aGUgc2FtZSB0 b3BpYy4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgVGhlIHNhbWUgZmVlbGluZzooDQog ICAgPiAgICAgPg0KICAgID4gICAgID4gICAgID4gQnR3IHdoYXQgYWJvdXQgQkdQIGV4dGVuc2lv bnM/DQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgIFNpbmNlIHRoZSBleGlzdGluZyBwcm90 b2NvbHMgZm9yIE1QTFMtU1IgYXJlIHJldXNlZCB3aXRob3V0IGFueQ0KICAgID4gY2hhbmdlLA0K ICAgID4gICAgID4gdGhlIEJHUCBleHRlbnNpb25zIGZvciBNUExTLVNSIGNvdWxkIGJlIHJldXNl ZC4gQXMgZm9yIHRoZSBCR1ANCiAgICA+IGV4dGVuc2lvbiBmb3INCiAgICA+ICAgICA+IHR1bm5l bCBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQsIHllcywgaXQgd29ya3MgYXMgd2VsbC4gd2Ugd2ls bCBhZGQgc29tZQ0KICAgID4gdGV4dCB0bw0KICAgID4gICAgID4gY2xhcmlmeSBpdC4gVGhhbmtz IGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+IFdI PiBteSB2aWV3IGlzIHRoYXQgaGF2aW5nIGEgcm91dGVyIGluZGljYXRlIGl0IHN1cHBvcnQgTVBM U29VRFAgaXMgbm90DQogICAgPiB0aGUNCiAgICA+ICAgICA+IHNhbWUgYXMgYSByb3V0ZXIgZG9p bmcgU1JvVURQLiBTbywgd2UgbWlnaHQgd2FudCB0byBkaXN0aW5ndWlzaA0KICAgID4gYmV0d2Vl biB0aGUNCiAgICA+ICAgICA+IGRpZmZlcmVudCBlbmNhcHN1bGF0aW9uIHRlY2huaXF1ZXMuDQog ICAgPiANCiAgICA+ICAgICBDb3VsZCB5b3UgcGxlYXNlIGdpdmUgbW9yZSBkZXRhaWxlZCBleHBs YW5hdGlvbiBvbiB0aGlzIHBvaW50Pw0KICAgID4gDQogICAgPiBXSD4gSSBzZWUgMiB1c2UgY2Fz ZSB3aGVuIHlvdSBpbmRpY2F0ZSBNUExTb1VEUCB5b3UgY2FuIGp1c3QgYWN0IGFzIGFuDQogICAg PiBlZ3Jlc3MgYW5kIHRlcm1pbmF0ZSB0aGUgdHVubmVsIGFuZCBiZSBhZ25vc3RpYyBvbiBlbnRy b3B5IGJlaGF2aW91ciwgdHJhbnNpdA0KICAgID4gYmVoYXZpb3VyLCBldGMuIElmIHlvdSBkbyBT Um9VRFAgYWxsIHRoZSBhYm92ZSBzaG91bGQgYmUgcGFydCBvZiB5b3VyDQogICAgPiBjYXBhYmls aXRpZXMgd2hlbiB5b3UgaW5kaWNhdGUgdGhpcyBpbiB0aGUgZW5jYXBzdWxhdGlvbiBjYXBhYmls aXRpZXMuIEhlbmNlIEkNCiAgICA+IGJlbGlldmUgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGRpc3Rp bmd1aXNoIHRoaXMgaW4gdGhlIHNpZ25hbGxpbmcuDQogICAgDQogICAgRGlkIHlvdSBtZWFuIHRo ZSB0dW5uZWwgZWdyZXNzIHJvdXRlciBzaG91bGQgYWR2ZXJ0aXNlIHdoZXRoZXIgaXQgY291bGQg cmV1c2UgdGhlIGVudHJ5IGZpZWxkIGNvbnRhaW5lZCBpbiB0aGUgVURQIHR1bm5lbCBoZWFkZXIg d2hlbiByZWVuY2Fwc3VsYXRpbmcgKHNlZSB0aGUgYmVsb3cgdGV4dCBxdW90ZWQgZnJvbSAtMDMg dmVyc2lvbiBvZiBkcmFmdC14dSopIGluIHRoZSBTUm9VRFAgY2FzZSwgaW4gYWRkaXRpb24gdG8g YWR2ZXJ0aXNpbmcgdGhhdCBpdCBjb3VsZCBkZWNhcHN1bGF0ZSBNUExTb1VEUCBwYWNrZXQ/DQog ICAgDQogICAgIi4uLlRvIGF2b2lkIHJlLXBlcmZvcm1pbmcgaGFzaCBvbiB0aGUgd2hvbGUgcGFj a2V0IHdoZW4gcmUtZW5jYXBzdWxhdGluZw0KICAgICAgIHRoZSBwYWNrZXQgd2l0aCBhbiBJUC1i YXNlZCB0dW5uZWwgaGVhZGVyLCBpdCdzIFJFQ09NTUVOREVEIHRoYXQgdGhlDQogICAgICAgZW50 cm9weSB2YWx1ZSBjb250YWluZWQgaW4gdGhlIHBhY2tldCAoZS5nLiwgdGhlIFVEUCBzb3VyY2Ug cG9ydA0KICAgICAgIHZhbHVlKSBpcyBrZXB0IHdoZW4gc3RyaXBwaW5nIHRoZSBJUC1iYXNlZCB0 dW5uZWwgaGVhZGVyIChlLmcuLCB0aGUNCiAgICAgICBVRFAgdHVubmVsIGhlYWRlcikuICBBcyBz dWNoLCB0aGUgZW50cm9weSB2YWx1ZSBjb3VsZCBiZSBkaXJlY3RseQ0KICAgICAgIGNvcGllZCB0 byB0aGUgZW50cm9weSBmaWVsZCAoZS5nLiwgdGhlIHNvdXJjZSBwb3J0IG9mIHRoZSBVRFAgdHVu bmVsDQogICAgICAgaGVhZGVyKSB3aGVuIHJlLWVuY2Fwc3VsYXRpbmcgdGhlIHBhY2tldCB3aXRo IGFuIElQLWJhc2VkIHR1bm5lbA0KICAgICAgIGhlYWRlciAoZS5nLiwgVURQIHR1bm5lbCBoZWFk ZXIpLiAgLi4uIg0KICAgIA0KV0gzPiBubyBJIGFtIHRyeWluZyB0byBkaXN0aW5ndWlzaCBiZXR3 ZWVuIGEgcmVndWxhciBNUExTb1VEUCBhbmQgU1JvVURQIGVuZHBvaW50DQoNCiAgICBCZXN0IHJl Z2FyZHMsDQogICAgWGlhb2h1DQogICAgDQogICAgDQogICAgPiAgICAgQmVzdCByZWdhcmRzLA0K ICAgID4gICAgIFhpYW9odQ0KICAgID4gDQogICAgPiAgICAgPiAgICAgQmVzdCByZWdhcmRzLA0K ICAgID4gICAgID4gICAgIFhpYW9odQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICA+IE9u IDE0LzA4LzIwMTcsIDA0OjU4LCAiVW1hIENodW5kdXJpIg0KICAgID4gPHVtYS5jaHVuZHVyaUBo dWF3ZWkuY29tPg0KICAgID4gICAgID4gd3JvdGU6DQogICAgPiAgICAgPiAgICAgPg0KICAgID4g ICAgID4gICAgID4gICAgIFdpbSAtDQogICAgPiAgICAgPiAgICAgPg0KICAgID4gICAgID4gICAg ID4gICAgIFRoYXQncyBiZWVuIGRlc2NyaWJlZCAgaGVyZToNCiAgICA+ICAgICA+ICAgICA+DQog ICAgPiAgICAgPiAgICAgPg0KICAgID4gICAgID4gICAgID4NCiAgICA+ICAgICA+DQogICAgPiBo dHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC14dS1tcGxzLXVuaWZpZWQtc291cmNlLXJvdXRp bmctaW5zdHJ1Y3Rpb24tMDMudHh0DQogICAgPiAgICAgPiAgICAgPg0KICAgID4gICAgID4gICAg ID4gICAgIC0tDQogICAgPiAgICAgPiAgICAgPiAgICAgVW1hIEMuDQogICAgPiAgICAgPiAgICAg Pg0KICAgID4gICAgID4gICAgID4gICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAg PiAgICAgPiAgICAgPiAgICAgRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0KICAgID4gICAgID4gSGVuZGVyaWNreCwNCiAgICA+ICAgICA+ ICAgICA+IFdpbSAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KICAgID4gICAgID4gICAgID4gICAgIFNl bnQ6IFN1bmRheSwgQXVndXN0IDEzLCAyMDE3IDY6NTUgUE0NCiAgICA+ICAgICA+ICAgICA+ICAg ICBUbzogYWRyaWFuQG9sZGRvZy5jby51azsgc3ByaW5nQGlldGYub3JnDQogICAgPiAgICAgPiAg ICAgPiAgICAgU3ViamVjdDogUmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQogICAgPiAgICAgPiAgICAgPiBkcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNy LTAxLnR4dA0KICAgID4gICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICA+ICAgICBUaGUgZHJh ZnQgb25seSBkZWZpbmVzIHByb2NlZHVyZXMgZm9yIFNSb0lQIEUyRSwgd2h5IGRvbuKAmXQNCiAg ICA+IHdlDQogICAgPiAgICAgPiBlbnZpc2lvbg0KICAgID4gICAgID4gICAgID4gU1JvSVAgdG8g SW50ZXJ3b3JrIHdpdGggbmF0aXZlIE1QTFMtU1IuDQogICAgPiAgICAgPiAgICAgPiAgICAgV2hh dCBJIG1lYW4gaXMgd2hlbiB1c2luZyB0aGUgU1JvSVAgcHJvY2VkdXJlcyB0aGUgZHJhZnQNCiAg ICA+IHVzZXMNCiAgICA+ICAgICA+IFNSb0lQIGF0DQogICAgPiAgICAgPiAgICAgPiBldmVyeSBo b3Agd2hpY2ggaXMgU1IgY2FwYWJsZS4NCiAgICA+ICAgICA+ICAgICA+ICAgICBZb3UgY291bGQg ZW52aXNpb24gY2VydGFpbiBzZWdtZW50cyB0byBkbyBTUm9JUCBhbmQgb3RoZXINCiAgICA+ICAg ICA+IHNlZ21lbnRzIHRvDQogICAgPiAgICAgPiAgICAgPiBoYXZlIG5hdGl2ZSBNUExTLVNSIGNh cGFiaWxpdHkuDQogICAgPiAgICAgPiAgICAgPg0KICAgID4gICAgID4gICAgID4gICAgIFNvIG15 IHF1ZXN0aW9uIGlzIHRoaXMgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdD8NCiAgICA+ICAgICA+ICAg ICA+DQogICAgPiAgICAgPiAgICAgPiAgICAgT24gMTEvMDgvMjAxNywgMjA6NDcsICJzcHJpbmcg b24gYmVoYWxmIG9mIEFkcmlhbiBGYXJyZWwiDQogICAgPiAgICAgPiAgICAgPiA8c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFkcmlhbkBvbGRkb2cuY28udWs+DQogICAgPiB3 cm90ZToNCiAgICA+ICAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgIEhpIGFs bCwNCiAgICA+ICAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgIFNQUklORyBk aWRuJ3QgbWVldCBpbiBQcmFndWUgc28gSSBwcmVzZW50ZWQgdGhpcyB3b3JrIGluDQogICAgPiBN UExTLg0KICAgID4gICAgID4gQnJ1bm8NCiAgICA+ICAgICA+ICAgICA+IHN1Z2dlc3RlZA0KICAg ID4gICAgID4gICAgID4gICAgICAgICB0aGF0IG1heWJlIFNQUklORyB3b3VsZCBiZSBhIGJldHRl ciB2ZW51ZS4NCiAgICA+ICAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgIEkn bSBub3Qgc3VyZSBhYm91dCB0aGF0LCBhbHRob3VnaCBJIGRvIHRoaW5rIGJvdGggV0dzDQogICAg PiBzaG91bGQNCiAgICA+ICAgICA+IGNoYXQNCiAgICA+ICAgICA+ICAgICA+IGFib3V0IHRoZQ0K ICAgID4gICAgID4gICAgID4gICAgICAgICBpZGVhcy4NCiAgICA+ICAgICA+ICAgICA+DQogICAg PiAgICAgPiAgICAgPiAgICAgICAgIFRoZSBlc3NlbmNlIG9mIHRoaXMgd29yayBpcyBub3RoaW5n IG1vcmUgdGhhdCBNUExTLVNSDQogICAgPiAgICAgPiBlbmNhcHN1bGF0ZWQNCiAgICA+ICAgICA+ ICAgICA+IGluIFVEUCBwZXINCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgUkZDIDc1MTAuIFdo YXQgaXQgYWNoaWV2ZXMgaXMgYSB3YXkgdG8gb2J0YWluIHRoZSBTUg0KICAgID4gICAgID4gZnVu Y3Rpb25hbGl0eSB0aGF0DQogICAgPiAgICAgPiAgICAgPiB3ZSBhbGwNCiAgICA+ICAgICA+ICAg ICA+ICAgICAgICAga25vdyBhbmQgbG92ZSBpbiBhbiBJUCBuZXR3b3JrLg0KICAgID4gICAgID4g ICAgID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgVGhlIGFwcHJvYWNoIGlzLCBvZiBjb3Vy c2UsIGNvbXBhdGlibGUgd2l0aCBNUExTLVNSLiBBcw0KICAgID4gdGhlDQogICAgPiAgICAgPiBk cmFmdA0KICAgID4gICAgID4gICAgID4gc2F5cy4uLg0KICAgID4gICAgID4gICAgID4NCiAgICA+ ICAgICA+ICAgICA+ICAgICAgICAgICAgVGhpcyBkb2N1bWVudCBtYWtlcyBubyBjaGFuZ2VzIHRv IHRoZSBzZWdtZW50DQogICAgPiByb3V0aW5nDQogICAgPiAgICAgPiAgICAgPiBhcmNoaXRlY3R1 cmUNCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgICAgYW5kIGJ1aWxkcyBvbiBleGlzdGluZyBw cm90b2NvbCBtZWNoYW5pc21zIHN1Y2ggYXMNCiAgICA+IHRoZQ0KICAgID4gICAgID4gICAgID4g ZW5jYXBzdWxhdGlvbg0KICAgID4gICAgID4gICAgID4gICAgICAgICAgICBvZiBNUExTIHdpdGhp biBVRFAgZGVmaW5lZCBpbiBSRkMgNzUxMC4NCiAgICA+ICAgICA+ICAgICA+DQogICAgPiAgICAg PiAgICAgPiAgICAgICAgICAgIE5vIG5ldyBwcm9jZWR1cmVzIGFyZSBpbnRyb2R1Y2VkLCBidXQg ZXhpc3RpbmcNCiAgICA+ICAgICA+IG1lY2hhbmlzbXMgYXJlDQogICAgPiAgICAgPiAgICAgPiAg ICAgICAgICAgIGNvbWJpbmVkIHRvIGFjaGlldmUgdGhlIGRlc2lyZWQgcmVzdWx0Lg0KICAgID4g ICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgVGhpcyBpcyBub3QgaW50ZW5k ZWQgdG8gYmUgYSBiZWF1dHkgY29udGVzdCB3aXRoIFNSdjYuIEFzDQogICAgPiB0aGUNCiAgICA+ ICAgICA+IGRyYWZ0DQogICAgPiAgICAgPiAgICAgPiBzYXlzLi4uDQogICAgPiAgICAgPiAgICAg Pg0KICAgID4gICAgID4gICAgID4gICAgICAgICAgICBUaGUgbWV0aG9kIGRlZmluZWQgaXMgYSBj b21wbGVtZW50YXJ5IHdheSBvZg0KICAgID4gcnVubmluZyBTUg0KICAgID4gICAgID4gaW4gYW4g SVANCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgICAgbmV0d29yayB0aGF0IGNhbiBiZSB1c2Vk IGFsb25nc2lkZSBvcg0KICAgID4gaW50ZXJjaGFuZ2VhYmx5IHdpdGgNCiAgICA+ICAgICA+IHRo YXQNCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgICAgZGVmaW5lZCBpbiBbSS1ELmlldGYtNm1h bi1zZWdtZW50LXJvdXRpbmctaGVhZGVyXS4NCiAgICA+ICAgICA+IEltcGxlbWVudGVycw0KICAg ID4gICAgID4gICAgID4gYW5kDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgICAgIGRlcGxveWVy cyBzaG91bGQgY29uc2lkZXIgdGhlIGJlbmVmaXRzIGFuZA0KICAgID4gZHJhd2JhY2tzIG9mDQog ICAgPiAgICAgPiBlYWNoDQogICAgPiAgICAgPiAgICAgPiBtZXRob2QNCiAgICA+ICAgICA+ICAg ICA+ICAgICAgICAgICAgYW5kIHNlbGVjdCB0aGUgYXBwcm9hY2ggbW9zdCBzdWl0ZWQgdG8gdGhl aXIgbmVlZHMuDQogICAgPiAgICAgPiAgICAgPg0KICAgID4gICAgID4gICAgID4gICAgICAgICBU aGFua3MsDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgIEFkcmlhbg0KICAgID4gICAgID4gICAg ID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gU2VudDogMTEg QXVndXN0IDIwMTcgMTk6Mzk6NTkgKFVUQyswMDowMCkgRHVibGluLA0KICAgID4gICAgID4gRWRp bmJ1cmdoLA0KICAgID4gICAgID4gICAgID4gTGlzYm9uLCBMb25kb24NCiAgICA+ICAgICA+ICAg ICA+ICAgICAgICAgPiBUbzogU3Rld2FydCBCcnlhbnQ7IEpvaG4gRSBEcmFrZTsgQWRyaWFuIEZh cnJlbA0KICAgID4gICAgID4gICAgID4gICAgICAgICA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCiAgICA+ICAgICA+ICAgICA+IGRyYWZ0LWJyeWFudC1tcGxzLXVuaWZp ZWQtaXAtc3ItMDEudHh0DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4NCiAgICA+ICAgICA+ ICAgICA+ICAgICAgICAgPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwNCiAgICA+IGRyYWZ0LWJyeWFu dC1tcGxzLXVuaWZpZWQtaXAtc3ItMDEudHh0DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4g aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBZHJpYW4gRmFycmVsIGFuZA0KICAg ID4gcG9zdGVkDQogICAgPiAgICAgPiB0byB0aGUNCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAg PiBJRVRGIHJlcG9zaXRvcnkuDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4NCiAgICA+ICAg ICA+ICAgICA+ICAgICAgICAgPiBOYW1lOiAgICAgICAgICAgZHJhZnQtYnJ5YW50LW1wbHMtdW5p ZmllZC1pcC1zcg0KICAgID4gICAgID4gICAgID4gICAgICAgICA+IFJldmlzaW9uOiAgICAgICAw MQ0KICAgID4gICAgID4gICAgID4gICAgICAgICA+IFRpdGxlOiAgICAgICAgICBBIFVuaWZpZWQg QXBwcm9hY2ggdG8gSVAgU2VnbWVudA0KICAgID4gUm91dGluZw0KICAgID4gICAgID4gICAgID4g ICAgICAgICA+IERvY3VtZW50IGRhdGU6ICAyMDE3LTA4LTExDQogICAgPiAgICAgPiAgICAgPiAg ICAgICAgID4gR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgID4gICAg ID4gICAgID4gICAgICAgICA+IFBhZ2VzOiAgICAgICAgICAxNg0KICAgID4gICAgID4gICAgID4g ICAgICAgICA+IFVSTDoNCiAgICA+ICAgICA+ICAgICA+DQogICAgPiAgICAgPiBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1z ci0NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiAwMS50eHQNCiAgICA+ICAgICA+ICAgICA+ ICAgICAgICAgPiBTdGF0dXM6DQogICAgPiAgICAgPiAgICAgPg0KICAgID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci8NCiAg ICA+ICAgICA+ICAgICA+ICAgICAgICAgPiBIdG1saXplZDoNCiAgICA+ICAgICA+ICAgICA+IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLXNy LTAxDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gSHRtbGl6ZWQ6DQogICAgPiAgICAgPiAg ICAgPg0KICAgID4gICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1icnlhbnQtbXBscy11bmlmaWVkLWlwLQ0KICAgID4gICAgID4gICAgID4gICAgICAgICA+ IHNyLTAxDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gRGlmZjoNCiAgICA+ICAgICA+ICAg ICA+DQogICAgPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt YnJ5YW50LW1wbHMtdW5pZmllZC1pcC1zci0wMQ0KICAgID4gICAgID4gICAgID4gICAgICAgICA+ DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gQWJzdHJhY3Q6DQogICAgPiAgICAgPiAgICAg PiAgICAgICAgID4gICAgU2VnbWVudCByb3V0aW5nIGlzIGEgc291cmNlIHJvdXRlZCBmb3J3YXJk aW5nDQogICAgPiBtZXRob2QNCiAgICA+ICAgICA+IHRoYXQNCiAgICA+ICAgICA+ICAgICA+IGFs bG93cw0KICAgID4gICAgID4gICAgID4gICAgICAgICA+ICAgIHBhY2tldHMgdG8gYmUgc3RlZXJl ZCB0aHJvdWdoIGEgbmV0d29yayBvbiBwYXRocw0KICAgID4gb3RoZXINCiAgICA+ICAgICA+IHRo YW4gdGhlDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gICAgc2hvcnRlc3QgcGF0aCBkZXJp dmVkIGZyb20gdGhlIHJvdXRpbmcgcHJvdG9jb2wuDQogICAgPiBUaGUNCiAgICA+ICAgICA+IGFw cHJvYWNoDQogICAgPiAgICAgPiAgICAgPiB1c2VzDQogICAgPiAgICAgPiAgICAgPiAgICAgICAg ID4gICAgaW5mb3JtYXRpb24gZW5jb2RlZCBpbiB0aGUgcGFja2V0IGhlYWRlciB0bw0KICAgID4g cGFydGlhbGx5IG9yDQogICAgPiAgICAgPiAgICAgPiBjb21wbGV0ZWx5DQogICAgPiAgICAgPiAg ICAgPiAgICAgICAgID4gICAgc3BlY2lmeSB0aGUgcm91dGUgdGhlIHBhY2tldCB0YWtlcyB0aHJv dWdoIHRoZQ0KICAgID4gbmV0d29yaywNCiAgICA+ICAgICA+IGFuZA0KICAgID4gICAgID4gICAg ID4gZG9lcyBub3QNCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBtYWtlIHVzZSBvZiBh IHNpZ25hbGluZyBwcm90b2NvbCB0byBwcmUtaW5zdGFsbA0KICAgID4gcGF0aHMgaW4gdGhlDQog ICAgPiAgICAgPiAgICAgPiBuZXR3b3JrLg0KICAgID4gICAgID4gICAgID4gICAgICAgICA+DQog ICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gICAgVHdvIGRpZmZlcmVudCBlbmNhcHN1bGF0aW9u cyBoYXZlIGJlZW4gZGVmaW5lZCB0bw0KICAgID4gZW5hYmxlDQogICAgPiAgICAgPiAgICAgPiBz ZWdtZW50DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gICAgcm91dGluZyBpbiBhbiBNUExT IG5ldHdvcmsgYW5kIGluIGFuIElQdjYNCiAgICA+IG5ldHdvcmsuDQogICAgPiAgICAgPiBXaGls ZQ0KICAgID4gICAgID4gICAgID4gICAgICAgICA+ICAgIGFja25vd2xlZGdpbmcgdGhhdCB0aGVy ZSBpcyBhIHN0cm9uZyBuZWVkIHRvDQogICAgPiBzdXBwb3J0DQogICAgPiAgICAgPiBzZWdtZW50 DQogICAgPiAgICAgPiAgICAgPiByb3V0aW5nDQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4g ICAgaW4gYm90aCBlbnZpcm9ubWVudHMsIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhDQogICAgPiAg ICAgPiBjb252ZXJnZWQsDQogICAgPiAgICAgPiAgICAgPiB1bmlmaWVkDQogICAgPiAgICAgPiAg ICAgPiAgICAgICAgID4gICAgYXBwcm9hY2ggdG8gc2VnbWVudCByb3V0aW5nIHRoYXQgZW5hYmxl cyBhIHNpbmdsZQ0KICAgID4gICAgID4gbWVjaGFuaXNtIHRvDQogICAgPiAgICAgPiAgICAgPiBi ZQ0KICAgID4gICAgID4gICAgID4gICAgICAgICA+ICAgIGFwcGxpZWQgaW4gYm90aCB0eXBlcyBv ZiBuZXR3b3JrLiAgVGhlIHJlc3VsdGluZw0KICAgID4gICAgID4gYXBwcm9hY2ggaXMNCiAgICA+ ICAgICA+ICAgICA+IGFsc28NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBhcHBsaWNh YmxlIHRvIElQdjQgbmV0d29ya3Mgd2l0aG91dCB0aGUgbmVlZCBmb3INCiAgICA+IGFueQ0KICAg ID4gICAgID4gY2hhbmdlcyB0bw0KICAgID4gICAgID4gICAgID4gdGhlDQogICAgPiAgICAgPiAg ICAgPiAgICAgICAgID4gICAgSVB2NCBzcGVjaWZpY2F0aW9uLg0KICAgID4gICAgID4gICAgID4g ICAgICAgICA+DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4gICAgVGhpcyBkb2N1bWVudCBt YWtlcyBubyBjaGFuZ2VzIHRvIHRoZSBzZWdtZW50DQogICAgPiByb3V0aW5nDQogICAgPiAgICAg PiAgICAgPiBhcmNoaXRlY3R1cmUNCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBhbmQg YnVpbGRzIG9uIGV4aXN0aW5nIHByb3RvY29sIG1lY2hhbmlzbXMgc3VjaA0KICAgID4gYXMgdGhl DQogICAgPiAgICAgPiAgICAgPiBlbmNhcHN1bGF0aW9uDQogICAgPiAgICAgPiAgICAgPiAgICAg ICAgID4gICAgb2YgTVBMUyB3aXRoaW4gVURQIGRlZmluZWQgaW4gUkZDIDc1MTAuDQogICAgPiAg ICAgPiAgICAgPiAgICAgICAgID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiAgICBObyBu ZXcgcHJvY2VkdXJlcyBhcmUgaW50cm9kdWNlZCwgYnV0IGV4aXN0aW5nDQogICAgPiAgICAgPiBt ZWNoYW5pc21zIGFyZQ0KICAgID4gICAgID4gICAgID4gICAgICAgICA+ICAgIGNvbWJpbmVkIHRv IGFjaGlldmUgdGhlIGRlc2lyZWQgcmVzdWx0Lg0KICAgID4gICAgID4gICAgID4gICAgICAgICA+ DQogICAgPiAgICAgPiAgICAgPiAgICAgICAgID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAg Pg0KICAgID4gICAgID4gICAgID4gICAgICAgICA+DQogICAgPiAgICAgPiAgICAgPiAgICAgICAg ID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbQ0KICAgID4gdGhlDQogICAgPiAgICAgPiB0aW1l IG9mDQogICAgPiAgICAgPiAgICAgPiBzdWJtaXNzaW9uDQogICAgPiAgICAgPiAgICAgPiAgICAg ICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dA0KICAgID4gICAgID4gdG9vbHMuaWV0Zi5vcmcuDQogICAgPiAgICAgPiAgICAgPiAgICAgICAg ID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAg ID4gICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgICA+ICAgICA+ICAgICAg ICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgID4gICAgID4gICAgID4gICAgICAgICBzcHJpbmdA aWV0Zi5vcmcNCiAgICA+ICAgICA+ICAgICA+ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCiAgICA+ICAgICA+ICAgICA+DQogICAgPiAgICAgPiAg ICAgPg0KICAgID4gICAgID4gICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgPiAgICAgPiAgICAgc3ByaW5nIG1haWxpbmcg bGlzdA0KICAgID4gICAgID4gICAgID4gICAgIHNwcmluZ0BpZXRmLm9yZw0KICAgID4gICAgID4g ICAgID4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQog ICAgPiAgICAgPiAgICAgPg0KICAgID4gICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgICA+DQog ICAgPiAgICAgPiAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgID4gICAgID4gICAgID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgID4gICAg ID4gICAgID4gc3ByaW5nQGlldGYub3JnDQogICAgPiAgICAgPiAgICAgPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KICAgID4gICAgID4NCiAgICA+IA0KICAg ID4gDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICBzcHJpbmcgbWFpbGluZyBsaXN0DQogICAgc3ByaW5nQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCiAgICANCg0K From nobody Mon Aug 14 21:03:40 2017 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 961521320BD for ; Mon, 14 Aug 2017 21:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 4KYLWUpJGzYs for ; Mon, 14 Aug 2017 21:03:37 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0108.outbound.protection.outlook.com [104.47.2.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340811241FC for ; Mon, 14 Aug 2017 21:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VgWntI8xvck287FikCoI9FzrnFcHHZ2hyIwRWt7W8lo=; b=K2CtHdvZIZS5chmO/EBT+1TrIOStDu5T0WCK61Lk5R/dgROF4kGSJkRxaOTOFwHua9ldp1mk5zzw+YmcBe6lqVG9QRbOrAcI8OgHiKi/UpDSXBt/zfjVRZzRnH1QR6byGLG+Lw/NtqM+IYLYR7AHam1WPNET5O0yIvZySnEY+ZY= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0899.eurprd07.prod.outlook.com (10.161.71.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Tue, 15 Aug 2017 04:03:35 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651%14]) with mapi id 15.01.1362.012; Tue, 15 Aug 2017 04:03:35 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "adrian@olddog.co.uk" , "spring@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAA79GAIAAdpmAgAE/swA= Date: Tue, 15 Aug 2017 04:03:34 +0000 Message-ID: <9A554684-CB3D-4A47-9965-AFE4B06C3E0A@nokia.com> References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com> <009b01d314ec$6156eb40$2404c1c0$@olddog.co.uk> In-Reply-To: <009b01d314ec$6156eb40$2404c1c0$@olddog.co.uk> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170725 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com; x-originating-ip: [135.245.212.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0899; 6:WMeEDaVbbz5Y+G4gInLMb453sY0F+rcT/KEzjoyjCGcu4N/SsXa+Px3C5d5SPMP5VRRf3xh0I9MFDB57jgZOT5Flz6Bdp7Hv6/s9wATtmy9QqsrRzhC6rpTVwzFOU32tqLcw9WQDisZlQPDPnGyuPeTDiv+UNK8U7LNA4Ss+rdwv86QjK5E52Gz5Bt7kMrJud5of8jqQ0hmmXJa3Bg4u+MJmQ0UfgjaUgI4CEOW0AyKhDg44GzbZrkp7Uy4b47JUVPYwVRvgNe2JhYO10RdSPXQOseLtRxpnrG4OA/scyG7XHZjVv2dK8a80KxDpA2Ng9YJ3YFdLTyiXRg7JS0bubg==; 5:C5O3EC0prnyY0mX3LRecJHVh85VZQeLdor4gNddxb8+P89DpAj2CixbsBpDb5S1nRntWQsCXFQmJ2eeqFLKz5KOKrlCh5ij2LLktz5u7DciWQlOOsYp/Qu8MVZyPlY6s/0wIc9F4NXg0mKCaqBlvzA==; 24:sYlh6hI7lFmoasAb+tV+dVAPQFub9CYAao69AnPG7GgHLmerSoc4ATPDOlX1HcmaABMk1H4soQYxY7od6KlSyzNwEpFZs3gqMW5Nu//urmA=; 7:QUxqyO/aifzpr5L9ik/wBJgDsghYIITp2aLXJhEG+gtTB60cWqaeEEpZzI7p3ZIBcy3pYE1iDXFyGq1eJDvvrpZq+bEwTeuuTwiiAKNyTIxgtQyxh9i14JlTWb1hGiWHZanfw//n26LK5NBK4qqIwQQkkUa9Xg+ldjLDGiwRkahs0iTUNZZ0554AJKCLvAu3nAzE7GVlEyxt+Me6ypr1jWGGpv+VJo/eBVWAMWb49Ds= x-ms-office365-filtering-correlation-id: 2b76e706-0fbb-49cc-fe7a-08d4e39299bc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0899; x-ms-traffictypediagnostic: AM2PR07MB0899: x-exchange-antispam-report-test: UriScan:(21532816269658); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0899; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0899; x-forefront-prvs: 04004D94E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(24454002)(189002)(229853002)(68736007)(8676002)(83716003)(8936002)(305945005)(81166006)(6512007)(81156014)(105586002)(106356001)(66066001)(230783001)(76176999)(53936002)(4001350100001)(50986999)(5660300001)(5250100002)(6486002)(7736002)(6506006)(97736004)(2501003)(6436002)(6246003)(99286003)(83506001)(3280700002)(2900100001)(189998001)(101416001)(3660700001)(93886004)(54356999)(2906002)(6116002)(82746002)(2950100002)(102836003)(25786009)(53546010)(478600001)(36756003)(33656002)(3846002)(14454004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0899; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9F7A489141B36F489CA0AF6EA475421C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 04:03:34.8706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0899 Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 04:03:39 -0000 QWRyaWFuIHNlZSBteSBvdGhlciBjb21tZW50cyBvbiB0aGUgbWFpbGluZyBsaXN0IHdoaWNoIHNl ZW0gdG8gY2xhcmlmeSBzb21lIG9mIHRoZSBjdHh0IEkgYW0gdGFraW5nIGFib3V0DQoNCk9uIDE0 LzA4LzIwMTcsIDAzOjU5LCAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+IHdy b3RlOg0KDQogICAgSGkgV2ltLA0KICAgIA0KICAgID4gVGhlIGRyYWZ0IG9ubHkgZGVmaW5lcyBw cm9jZWR1cmVzIGZvciBTUm9JUCBFMkUsIHdoeSBkb27igJl0IHdlIGVudmlzaW9uIFNSb0lQIHRv DQogICAgPiBJbnRlcndvcmsgd2l0aCBuYXRpdmUgTVBMUy1TUi4NCiAgICA6DQogICAgPiBZb3Ug Y291bGQgZW52aXNpb24gY2VydGFpbiBzZWdtZW50cyB0byBkbyBTUm9JUCBhbmQgb3RoZXIgc2Vn bWVudHMgdG8gaGF2ZQ0KICAgID4gbmF0aXZlIE1QTFMtU1IgY2FwYWJpbGl0eS4NCiAgICANCiAg ICBZZXMsIHRoZSAibWl4ZWQgbW9kZSIgaXMgYm90aCBpbnRlcmVzdGluZyBhbmQgdXNlZnVsLg0K ICAgIA0KICAgIEluIGZhY3QsIHRoaXMgY29tZXMgImZvciBmcmVlIi4gQ29uc2lkZXIgdGhlIGV4 YW1wbGUgaW4gRmlndXJlIDMgd2hlcmUgVURQIGlzIHVzZWQgdG8gY29ubmVjdCB0d28gU1IgZG9t YWlucy4gTm93IGNvbnNpZGVyIHRoYXQgdGhlIGRvbWFpbnMgY291bGQgYmUgYW55IHNpemUsIHRo ZSB0dW5uZWwgY291bGQgYmUgYW55IGxlbmd0aCwgYW5kIHRoZSBwaWN0dXJlIGNvdWxkIGJlIHJl cGVhdGVkIGNvbmNhdGVuYXRpbmcgbXVsdGlwbGUgaW5zdGFuY2UuDQogICAgDQogICAgRnVydGhl cm1vcmUsIHRoZSBwaWN0dXJlIG5lZWQgbm90IGJlIGZ1bGx5IHN5bW1ldHJpY2FsLiBUaGF0IGlz LCBvbmUgZW5kIG9mIHRoZSBmbG93IGNvdWxkIGJlIGEgImRvbWFpbiIgYW5kIHRoZSBvdGhlciBj b3VsZCBiZSBhIHNpbmdsZSAoaW5ncmVzcyBvciBlZ3Jlc3MpIHJvdXRlci4NCiAgICANCiAgICA+ IFNvIG15IHF1ZXN0aW9uIGlzIHRoaXMgaW4gc2NvcGUgb2YgdGhpcyBkcmFmdD8NCiAgICANCiAg ICBTbywgeWVzLCBkZWZpbml0ZWx5IGluIHNjb3BlLg0KICAgIA0KICAgIElmIHlvdSBmZWVsIHRo aXMgY291bGQgYmUgdXNlZnVsbHkgZGVzY3JpYmVkIHdlJ2xsIGFkZCB0ZXh0LCBidXQgSSBzdXNw ZWN0IGl0IGp1c3QgZm9sbG93cyBhbmQgd2Ugb25seSBuZWVkIHRvIGFkZCBhIHNob3J0IG5vdGUu DQogICAgDQogICAgQnV0Li4uDQogICAgDQogICAgPiBXaGF0IEkgbWVhbiBpcyB3aGVuIHVzaW5n IHRoZSBTUm9JUCBwcm9jZWR1cmVzIHRoZSBkcmFmdCB1c2VzIFNSb0lQIGF0IGV2ZXJ5DQogICAg PiBob3Agd2hpY2ggaXMgU1IgY2FwYWJsZS4NCiAgICANCiAgICBOb3QgdGhlIGNhc2UuIEFzIHNo b3duIGluIEZpZ3VyZSA0IGFuZCBkaXNjdXNzZWQgaW4gc2VjdGlvbnMgNS4zIGFuZCA1LjQsIHRo ZXJlIG1heSBiZSB0cmFuc2l0IHJvdXRlcnMgb24gdGhlIHBhdGguIFRoZXNlIG1heSBiZSBuYXRp dmUgSVAgKGkuZS4pIGxlZ2FjeSByb3V0ZXJzLCBvciBTUi1jYXBhYmxlIHJvdXRlcnMgdGhhdCBh cmUgc2ltcGx5IG5vdCBleHBsaWNpdGx5IHBhcnQgb2YgdGhlIFNSIHBhdGguIE9ubHkgdGhlIG5v ZGVzIGV4cGxpY2l0bHkgbWVudGlvbmVkIGluIHRoZSBTUiBwYXRoIGJlY29tZSBVRFAgZW5kIHBv aW50cyBhbmQgZG8gdGhlIFNSb0lQIHByb2NlZHVyZXMuDQogICAgDQogICAgQ2hlZXJzLA0KICAg IEFkcmlhbg0KICAgIA0KICAgIA0KDQo= From nobody Wed Aug 16 21:49:22 2017 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 A6C661321F6; Wed, 16 Aug 2017 21:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zekNmWctKKNb; Wed, 16 Aug 2017 21:49:12 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5489512009C; Wed, 16 Aug 2017 21:49:11 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7H4n9KI021160; Thu, 17 Aug 2017 05:49:09 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7H4n7ie021136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Aug 2017 05:49:08 +0100 Reply-To: From: "Adrian Farrel" To: "'Robert Raszuk'" Cc: , References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <053e01d312d3$1dcba0c0$5962e240$@olddog.co.uk> In-Reply-To: Date: Thu, 17 Aug 2017 05:49:05 +0100 Message-ID: <059e01d31714$27fb1ef0$77f15cd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_059F_01D3171C.89C41AD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDAWjbfWQBJH04OgGKdeMzoixuy5A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23264.002 X-TM-AS-Result: No--26.374-10.0-31-10 X-imss-scan-details: No--26.374-10.0-31-10 X-TMASE-MatchedRID: Z/tjqhsgM6dbJCKOm3VRCaj5v7I4/SgYq8k2QEqE4yUTyaVf7UjgsT3R Dhsyc984sznIV04I19FLEb8jQyOYXkOaNQ+STGGWOdl/GMFVBFszBHKsDHLon/yQkqwxgq4lu1H fushj2IMlr4UAbUFME1t3XMydUaMXAC8ufaKZ2BzfUZT83lbkEPTYLJi/AavY3MZ/LCP5vw03QQ KH+h23K9jTzYyhzXBG9UVHiwLx0/L2v20RxLDyN3yryS1js33QPrMcTVgfnXCAQFHYeOdeK5sZX bChjvKtImxAt97SdonTzWmGCXkX+SEdaywSZvzOsa7wMXMLrhak0xCU9zGy2eXA1O4kk7XxqEJt GIW6dQGiPXhbv/v9rie1T5r1VA3InS9YM7PCHZiCTJUvpDBm3Dl1BSviCTbCKADgxIx6VkhzYNa liAyMvYxYkErIAqjRW7gz/Gbgpl4jkrgJ37RqjyImYHvg8xhoBUz2Q+xpjHgUBgz2TpDbYVe/mD hUGtdRVatb/Qtg459NCH0Dib0S0enyXFanZ6WWWcNQC7Waq82Trr+C1WNmxeBmZBH3ZVRSZfPmK JtMluYCsjHNBKjIyv45MImNrSZy9pLnYtQ99xKiIlKMwQfMa4jA+sAfyIsyLJf50D62mqhcvoSy YffYE9qoygGFfC1GTVa+L3Zgqc70IWUUTIPdhFmmz7LVVfOp7fKxaM2xqkBh6R1V/b2StVvKLnw iAiVRqqrD2rq6EGCA6qv+vR34LFF5adRR2Ej1zO86RLKahv8nwf3kfmsrQzba6gSbbjl+gVo1o+ 4QhtKqDvek35mqXJ3bt4XlQMWjD+LwVja9M4GbKItl61J/yZUdXE/WGn0FxbYCTleOUf4Hd2pRm IqqGSIWyOG3VFHj6KOPt1yh+6CHHQtvygWztIUNRfoOduqwMj/+V4GlIPEgUJd9uKRYtT7qFUTu O1RWdydBcHzvVOQ= Archived-At: Subject: Re: [spring] [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 04:49:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_059F_01D3171C.89C41AD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Robert, =20 Thanks for the thoughtful comments. =20 You're right, MPLS-SR is not SRv6 and this is not the document to run a = comparison or beauty contest. Nor is this the right document to use to = consider making changes or additions to MPLS-SR to make it more like = SRv6. =20 We should focus this document on describing how to carry MPLS-SR over = UDP and the use cases for that. =20 I think your question about MTU discovery is a good one. We should look = into that and reference RFC 4023. =20 Cheers, Adrian =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: 11 August 2017 20:23 To: Adrian Farrel Cc: mpls@ietf.org; spring@ietf.org Subject: Re: [mpls] FW: New Version Notification for = draft-bryant-mpls-unified-ip-sr-01.txt =20 Sorry but forgot one more really useful advantage which your proposal is = lacking ...=20 =20 D)=20 =20 In SRv6 when you traverse SR node you move the pointer from one SID to = the next one. This allows you to maintain in the packet the entire = history of functions executed on a given packet. Something which to the = best of my knowledge we never had in the IP networks. Now how could you = accomplish the same or even close to that with SR-MPLS analogy ?=20 =20 Cheers, R. =20 On Fri, Aug 11, 2017 at 9:11 PM, Robert Raszuk = wrote: Hi Adrian, =20 I see few so to say "challenges" with the proposal=20 =20 A)=20 =20 SRv6 SID is 128 bits where first 64 is the locator and remaining 64 is = the function. So to "emulate" this directly with SR-MPLS you need for 1 = SRv6 SID stack of 8 labels ! And some use cases of SRv6 already talk = about using few SRv6 SIDs. Please show me the today's hardware which can = consume in single pass and make sense of stack of say 32 mpls labels ... = so here goes your "interchangeability".=20 =20 B)=20 =20 One of serious concerns with SRH insertion in transit as expressed by = 6man was MTU. How does this proposal solves this at all if what you are = doing here is taking nicely MTU discovered and negotiated IPv6 packet = and adding mpls stack or tower + UDP + IPv/v6 encap to it ? How would = end hosts now will get any awareness about this ? =20 C)=20 =20 One of the very nice applications for SRv6 is spray function with full = multicast address transparency. Please kindly elaborate how are you = going to map IPv4 or IPv6 multicast addresses into MPLS labels ? =20 - - -=20 =20 I think while it looks great on slides that now we will have two = different ways to do SR on IP networks if you really focus to specific = applications you will find a lot of them which are not going to be = compatible with your proposal. So maybe instead trying to squeeze the = balloon to fit the bottle we better collectively focus on making the = balloon fly ?=20 =20 Kind regards, Robert. =20 =20 =20 =20 =20 =20 On Fri, Aug 11, 2017 at 8:53 PM, Adrian Farrel = wrote: All, The presentation of this draft in Prague seemed to be well received and = we got some comments that we have stated to act on in this revision. One, non-technical request was to share the work with the SPRING working = group, and I have just done that. At the meeting I noted that... > The authors think this is in charter for MPLS > But polish and discussion is needed before we ask for adoption As this polish continues, I'd like to ask the list what they think of = this work. Is it going in the right direction? Is it work that you support? Thanks, Adrian > ________________________________________ > From: internet-drafts@ietf.org > Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, = London > To: Stewart Bryant; John E Drake; Adrian Farrel > Subject: New Version Notification for = draft-bryant-mpls-unified-ip-sr-01.txt > > A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. > > Name: draft-bryant-mpls-unified-ip-sr > Revision: 01 > Title: A Unified Approach to IP Segment Routing > Document date: 2017-08-11 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr- > 01.txt > Status: https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ > Htmlized: = https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip- > sr-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-bryant-mpls-unified-ip-sr-01 > > Abstract: > Segment routing is a source routed forwarding method that allows > packets to be steered through a network on paths other than the > shortest path derived from the routing protocol. The approach uses > information encoded in the packet header to partially or completely > specify the route the packet takes through the network, and does = not > make use of a signaling protocol to pre-install paths in the = network. > > Two different encapsulations have been defined to enable segment > routing in an MPLS network and in an IPv6 network. While > acknowledging that there is a strong need to support segment = routing > in both environments, this document defines a converged, unified > approach to segment routing that enables a single mechanism to be > applied in both types of network. The resulting approach is also > applicable to IPv4 networks without the need for any changes to the > IPv4 specification. > > This document makes no changes to the segment routing architecture > and builds on existing protocol mechanisms such as the = encapsulation > of MPLS within UDP defined in RFC 7510. > > No new procedures are introduced, but existing mechanisms are > combined to achieve the desired result. > > > > > > 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 =20 ------=_NextPart_000_059F_01D3171C.89C41AD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Robert,

 

Thanks for the thoughtful = comments.

 

You're right, MPLS-SR is not = SRv6 and this is not the document to run a comparison or beauty contest. = Nor is this the right document to use to consider making changes or = additions to MPLS-SR to make it more like SRv6.

 

We should focus this document = on describing how to carry MPLS-SR over UDP and the use cases for = that.

 

I think your question about = MTU discovery is a good one. We should look into that and reference RFC = 4023.

 

Cheers,

Adrian

 

From: rraszuk@gmail.com = [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: 11 August 2017 20:23
To: Adrian = Farrel
Cc: mpls@ietf.org; spring@ietf.org
Subject: = Re: [mpls] FW: New Version Notification for = draft-bryant-mpls-unified-ip-sr-01.txt

<= p class=3DMsoNormal> 

Sorry = but forgot one more really useful advantage which your proposal is = lacking ... 

 

D) 

=

 

In SRv6 when you traverse SR = node you move the pointer from one SID to the next one. This allows you = to maintain in the packet the entire history of functions executed on a = given packet. Something which to the best of my knowledge we never had = in the IP networks. Now how could you accomplish the same or even close = to that with SR-MPLS analogy ? 

 

Cheers,
R.

 

On Fri, Aug 11, 2017 at 9:11 PM, Robert Raszuk <robert@raszuk.net> = wrote:

Hi = Adrian,

 

I see few so to say = "challenges" with the = proposal 

 

A) 

=

 

SRv6 SID is 128 bits where = first 64 is the locator and remaining 64 is the function. So to = "emulate" this directly with SR-MPLS you need for 1 SRv6 SID = stack of 8 labels ! And some use cases of SRv6 already talk about using = few SRv6 SIDs. Please show me the today's hardware which can consume in = single pass and make sense of stack of say 32 mpls labels ... so here = goes your = "interchangeability". 

 

B) 

=

 

One of serious concerns with = SRH insertion in transit as expressed by 6man was MTU. How does this = proposal solves this at all if what you are doing here is taking nicely = MTU discovered and negotiated IPv6 packet and adding mpls stack or tower = + UDP + IPv/v6 encap to it ? How would end hosts now will get any = awareness about this ?

 

C) 

=

 

One of the very nice = applications for SRv6 is spray function with full multicast address = transparency. Please kindly elaborate how are you going to map IPv4 or = IPv6 multicast addresses into MPLS labels = ?

 

- - = - 

 

I think while it looks great = on slides that now we will have two different ways to do SR on IP = networks if you really focus to specific applications you will find a = lot of them which are not going to be compatible with your proposal. So = maybe instead trying to squeeze the balloon to fit the bottle we better = collectively focus on making the balloon fly = ? 

 

Kind = regards,

Robert.

<= /div>

 

 

 

 

 

 

On Fri, = Aug 11, 2017 at 8:53 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

All,

The presentation of this draft in Prague = seemed to be well received and we got
some comments that we have = stated to act on in this revision.

One, non-technical request was = to share the work with the SPRING working group,
and I have just done = that.

At the meeting I noted that...
> The authors think = this is in charter for MPLS
> But polish and discussion is needed = before we ask for adoption

As this polish continues, I'd like to = ask the list what they think of this work.
Is it going in the right = direction? Is it work that you support?


Thanks,
Adrian

> = ________________________________________
> From: internet-drafts@ietf.org
> Sent: 11 August = 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, London
> To: = Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version = Notification for draft-bryant-mpls-unified-ip-sr-01.txt
>
> = A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has = been successfully submitted by Adrian Farrel and posted to the
> = IETF repository.
>
> Name:          =  draft-bryant-mpls-unified-ip-sr
> Revision:    =    01
> Title:          A = Unified Approach to IP Segment Routing
> Document date:  = 2017-08-11
> Group:          Individual = Submission
> Pages:          16
> = URL:
https://www.ietf.org/internet-drafts/draft-bryant-mpls-= unified-ip-sr-
> 01.txt
> Status:
https://datatracker.ietf.org/doc/draft-bryant-mpls-unif= ied-ip-sr/
> Htmlized:       https://tools.ietf.org/html/draft-bryant-mpls-unified-i= p-sr-01
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls= -unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-bryant-mpls-u= nified-ip-sr-01
>
> Abstract:
>    = Segment routing is a source routed forwarding method that = allows
>    packets to be steered through a network on = paths other than the
>    shortest path derived from the = routing protocol.  The approach uses
>    = information encoded in the packet header to partially or = completely
>    specify the route the packet takes = through the network, and does not
>    make use of a = signaling protocol to pre-install paths in the = network.
>
>    Two different encapsulations have = been defined to enable segment
>    routing in an MPLS = network and in an IPv6 network.  While
>    = acknowledging that there is a strong need to support segment = routing
>    in both environments, this document defines = a converged, unified
>    approach to segment routing = that enables a single mechanism to be
>    applied in = both types of network.  The resulting approach is = also
>    applicable to IPv4 networks without the need = for any changes to the
>    IPv4 = specification.
>
>    This document makes no = changes to the segment routing architecture
>    and = builds on existing protocol mechanisms such as the = encapsulation
>    of MPLS within UDP defined in RFC = 7510.
>
>    No new procedures are introduced, but = existing mechanisms are
>    combined to achieve the = desired result.
>
>
>
>
>
> 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

_______________________________________________

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

 

 

------=_NextPart_000_059F_01D3171C.89C41AD0-- From nobody Sun Aug 20 10:07:12 2017 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 48CDF1326BB for ; Sun, 20 Aug 2017 10:07: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] 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 XJUhAr798SDN for ; Sun, 20 Aug 2017 10:07:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A03132661 for ; Sun, 20 Aug 2017 10:07:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7KH70NU010627; Sun, 20 Aug 2017 18:07:00 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7KH6wtt010603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Aug 2017 18:07:00 +0100 Reply-To: From: "Adrian Farrel" To: "'Xuxiaohu'" Cc: References: <00ae01d314f3$e48fe3c0$adafab40$@olddog.co.uk> In-Reply-To: <00ae01d314f3$e48fe3c0$adafab40$@olddog.co.uk> Date: Sun, 20 Aug 2017 18:06:57 +0100 Message-ID: <00d701d319d6$bc20ac70$34620550$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKuglHv1wUMqf8toUV0L3O+pRbEd6DWpXDg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23272.001 X-TM-AS-Result: No--15.725-10.0-31-10 X-imss-scan-details: No--15.725-10.0-31-10 X-TMASE-MatchedRID: X4bcv0S75KlZjh0+31OktoJzLQve4x1UQRPZCRdX9cLaqqH/oHw+kX/2 0wqGUabSTWLw2jvbfpxcQYBu5oPw5fUe3cF58v23e7MO8jvmPSzDHSNFHFxB88EJ21RN4HzLYqk wmiKYFxvNMonmPoyMtZpXEDfrUd+Lghwwq9GACbcAKzYLecaUGLb45+VjZiMp6ouYUIynB9TwTQ AUdTd/a5WPxGVBtRjfGZDrhRKC87Qobut7/12gAlv+fRXqSDSRgGa+oYp5i6pfP+XEiE4yhm8qn Fk+BWUX/NIOugvPDyx7vXaCWBtxtDIMh0gavIxo7nFyCFh/r3O7nrAU9KQxUbv408/GP5Hqdh1a 52zlmP+PWZvDr+0qazwxeGjpS2MHSpebgw+pOvaeAiCmPx4NwGNn8XPiALIb+gD2vYtOFhgqtq5 d3cxkNUcIn3wCvI9YKejNZavk4vVc3OoU+bqbEiJVYMX4qNuaJ8MgSz5HcEw= Archived-At: Subject: Re: [spring] Author/contributor [Was: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt] X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 17:07:10 -0000 Xiaohu, As I mentioned in my previous mail, if you want to be removed from this = document (and it looks like you do), you must send a note to the list disclaiming = all contribution to the text. Unless we see that, you'll remain listed as a Contributor. Thanks, Adrian > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Adrian = Farrel > Sent: 14 August 2017 12:53 > To: 'Xuxiaohu' > Cc: spring@ietf.org > Subject: [spring] Author/contributor [Was: New Version Notification = for draft- > bryant-mpls-unified-ip-sr-01.txt] >=20 > Greetings Xiaohu, >=20 > > When=A0you=A0submitted=A0the=A0-00 version=A0of=A0this=A0draft=A0with=A0my=A0name=A0being=A0listed=A0in > >=A0the=A0coauthor=A0list=A0but=A0without=A0my=A0permission,=A0I=A0tolera= ted=A0it=A0so=A0as=A0to=A0give=A0face > =A0to > >=A0you,=A0although=A0it=A0had=A0caused=A0unnecessary=A0confusion=A0in=A0= the=A0IETF,=A0especially=A0amon > g > = >=A0the=A0coauthors=A0of=A0draft-xu-mpls-unified-source-routing-instructi= on. >=20 > It was so very kind of you to consider my face and to not send any = mail about > this to a public list. >=20 > It might also have helped reduce the confusion if you had told me of = your > objection as soon as -00 was posted. Without that, I could not (of = course) have > any visibility into the intricacies of Huawei management and had to = assume that > all names of Huawei staff proposed for inclusion on the draft were = there because > they were supposed to be. >=20 > Still here we are... >=20 > > > This=A0time=A0you=A0submitted=A0- > = 01=A0version=A0with=A0my=A0name=A0being=A0added=A0into=A0the=A0contributo= > r > > > list=A0but=A0without=A0my=A0permission=A0as=A0well.=A0I=A0have=A0to=A0rem= ind=A0you:=A0don't=A0repeat=A0such > >=A0impolite=A0actions. >=20 > Yes, it is important to be polite at all times, isn't it? >=20 > We'd be delighted to remove your name from future revisions. But we = have to > navigate a small piece of IETF process to establish you as not an = author or > contributor for IPR and copyright reasons. The easiest way for you to = do this is > to send simple email to this list saying something like "I confirm = that I did > not write any of the text appearing in = draft-bryant-mpls-unified-ip-sr-01 and > there is no reason for me to be listed as an author or contributor." = If you can > do that we can issue the new revision. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Aug 23 19:39:02 2017 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 1F7BF12008A; Wed, 23 Aug 2017 19:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 u4b4klHODWRT; Wed, 23 Aug 2017 19:38:58 -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 CE8C31323A2; Wed, 23 Aug 2017 19:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28424; q=dns/txt; s=iport; t=1503542337; x=1504751937; h=from:to:cc:subject:date:message-id:mime-version; bh=fJ8oVpdiwGY63Gs7GH3Rm2d5zU6Xe4wn5NwVglHFhy8=; b=er2qOjTnynDZBijfBVLgIjpajshBRG6g6DdPZKV+5+c+wRTvP4uGLFpn VcxkKFJUjU0lkLj8XyZ1ZAoayZNGfYoRsNI5YW0sLuM/GMZmXB3TRyx7Z EOGZvSpqpmfl49InflNZV0KUkM3tLQ0UpjNDzwOdavzRoBDUajacs87e5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgCFO55Z/4kNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rZIEcg3CaNJgUDoIECYU+HIQtQRYBAgEBAQEBAQFrHQuFQgpMEgE?= =?us-ascii?q?GFBsVAgQwFxAEDolSZI8AnWaCJieLOQEBAQEBAQEBAQEBAQEBAQEBAQEBHoMqg?= =?us-ascii?q?gKBTIFiASuHLA11glQwgjEFmCKINgKUQoIShWOKb4lvjD4BJgwlgQp3FUkSAYU?= =?us-ascii?q?EBReBZ4ZngQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,419,1498521600"; d="scan'208,217";a="471047794" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Aug 2017 02:38:56 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7O2cu81004739 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Aug 2017 02:38:56 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 23 Aug 2017 21:38:55 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 23 Aug 2017 21:38:55 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-spring-segment-routing-mpls@ietf.org" CC: Martin Vigoureux , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-segment-routing-mpls-10 Thread-Index: AQHTHIIh4KJmZ7gcR0CZ8hGMO0nB2Q== Date: Thu, 24 Aug 2017 02:38:55 +0000 Message-ID: <74FB72FC-AD69-4EA3-ACA2-739168EE0A44@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.25.69] Content-Type: multipart/alternative; boundary="_000_74FB72FCAD694EA3ACA2739168EE0A44ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 02:39:01 -0000 --_000_74FB72FCAD694EA3ACA2739168EE0A44ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpJIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAg UGxlYXNlIHRha2UgYSBsb29rIGF0IG15IGNvbW1lbnRzIGJlbG93Lg0KDQpUaGUgbWFpbiBxdWVz dGlvbnMvY29uY2VybnMgdGhhdCBJIGhhdmUgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50IGlzIG5v dCBqdXN0IGZvciB0aGUgYXV0aG9ycywgYnV0IGZvciB0aGUgU2hlcGhlcmQgYW5kIHRoZSBDaGFp cnMgdG9vLg0KDQpRMS4gV2h5IGlzIHRoaXMgZG9jdW1lbnQgb24gdGhlIFN0YW5kYXJkcyBUcmFj az8gRnJvbSB0aGUgSW50cm9kdWN0aW9uOiDigJxUaGlzIGRyYWZ0cyBkZXNjcmliZXMgaG93IFNl Z21lbnQgUm91dGluZyBvcGVyYXRlcyBvbiB0b3Agb2YgdGhlIE1QTFMgZGF0YSBwbGFuZS7igJ0g IERlc2NyaWJlcywgeWVzLiAgT24gdGhlIG90aGVyIGhhbmQsIHRoZSBTaGVwaGVyZOKAmXMgd3Jp dGUtdXAgc2F5cyB0aGF0IGl0IOKAnHNwZWNpZmllcyB0aGUgZ2VuZXJpYyBmdW5jdGlvbnMgb2Yg dGhlIGFyY2hpdGVjdHVyZeKAnSDigJMgSSBkb27igJl0IHNlZSBhIHNwZWNpZmljYXRpb24sIGp1 c3QgYSBkZXNjcmlwdGlvbi4gIEFzIHN1Y2gsIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91bGQg YmUgSW5mb3JtYXRpb25hbC4NCg0KUTIuIFNlY3Rpb24gMi4gKE1QTFMgSW5zdGFudGlhdGlvbiBv ZiBTZWdtZW50IFJvdXRpbmcpIGlzIHRoZSBvbmx5IG9uZSB3aXRoIGFueSByZWFsIGNvbnRlbnTi gKZidXQgdGhlcmUgYXJlIG9ubHkgYSBjb3VwbGUgb2YgdGhpbmdzIGluIGl0IHRoYXQgYXJlIG5v dCBpbiB0aGUgQXJjaGl0ZWN0dXJlIGRvY3VtZW50OiB0aGUgaW50cm9kdWN0aW9uIG9mIHRoZSBT UkxCLCBhbmQgc29tZSB3b3JkcyBhYm91dCB0aGUgaW5kZXgg4oCTIGJvdGggb2Ygd2hpY2ggc2hv dWxkIGJlIHJlYWxseSBleHBsYWluZWQgaW4gdGhlIEFyY2hpdGVjdHVyZSBkb2N1bWVudCwgYW5k IG5vdCBoZXJlLiAgSSB3b25kZXIgd2hhdCB0aGUgdmFsdWUgb2YgcHVibGlzaGluZyB0aGlzIGRv Y3VtZW50IHJlYWxseSBpcy4gIFdoYXQgbG9uZy10ZXJtIGFyY2hpdmFsIHZhbHVlIGRvZXMgaXQg cHJvdmlkZT8NCg0KUTMuIEkgYWxzbyBoYXZlIHRvIHdvbmRlciBhYm91dCB0aGUgSVBSIGRlY2xh cmVkIGZvciB0aGlzIGRvY3VtZW50LiAgSWYgbW9zdCBvZiB0aGUgaW5mb3JtYXRpb24gaGVyZSBp cyBhbHJlYWR5IGRlZmluZWQsIGRlc2NyaWJlZCBvciBzcGVjaWZpZWQgaW4gZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLCBzaG91bGQgdGhlIElQUiBkZWNsYXJhdGlvbiBhcHBseSB0 byB0aGF0IGRvY3VtZW50IGFzIHdlbGwgKG9yIG1heWJlIGluc3RlYWQgb2YgdGhpcyBvbmUpPyAg SXQgaXMgbm90IHRoZSBJRVRG4oCZcyByb2xlIChpbmNsdWRpbmcgdGhlIFdHKSB0byBkaXNjdXNz IHdoZXRoZXIgYSBwaWVjZSBvZiBJUFIgaXMgdmFsaWQgb3Igbm90IOKAkyBJIGp1c3Qgd2FudCB0 byBtYWtlIHN1cmUgdGhlIGRpc2Nsb3N1cmVzIGFwcGx5IHRvIHRoZSByaWdodCBkb2N1bWVudC4N Cg0KDQpJIGRpZG7igJl0IGZpbmQgYSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGFib3V0IGFueSBv ZiB0aGVzZSBwb2ludHMuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCk1ham9yDQoNCk0xLiBT ZWN0aW9uIDIuIChNUExTIEluc3RhbnRpYXRpb24gb2YgU2VnbWVudCBSb3V0aW5nKSBleHBsYWlu cyBob3cg4oCcaW4gdGhlIE1QTFMgaW5zdGFudGlhdGlvbiwgdGhlIFNJRCB2YWx1ZXMgYXJlIGFs bG9jYXRlZCB3aXRoaW4gYSByZWR1Y2VkIDIwLWJpdCBzcGFjZSBvdXQgb2YgdGhlIDMyLWJpdCBT SUQgc3BhY2Uu4oCdICBIb3dldmVyLCBJIGNvdWxkbuKAmXQgZmluZCB3aGVyZSBkcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmcgZGVmaW5lcyB0aGUgU0lEIHNwYWNlIGFzIHVzaW5nIDMy IGJpdHMgKG9yIGFueSBvdGhlciBsZW5ndGgpLiAgSW4gZmFjdCwgdGhlIGNsb3Nlc3QgdGhhdCBk b2N1bWVudCBjb21lcyBpcyB3aGVuIGl0IGRlZmluZXMgYW4gU0lEIGFuZCBtZW50aW9ucyDigJxF eGFtcGxlcyBvZiBTSURzIGFyZTogYW4gTVBMUyBsYWJlbCwgYW4gaW5kZXggdmFsdWUgaW4gYW4g TVBMUyBsYWJlbCBzcGFjZSwgYW4gSVB2NiBhZGRyZXNzLuKAnSAgIEnigJltIGFzc3VtaW5nIHRo ZSDigJwzMi1iaXQgU0lEIHNwYWNl4oCdIGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCB0aGUgZXh0 ZW5zaW9ucyBkZWZpbmUgYW4gU0lEIG9mIHRoYXQgbGVuZ3RoLiAgQWxsIHRoaXMgaXMgdG8gc2F5 IHRoYXQgYXMgeW91IGRlc2NyaWJlIGhvdyBTUiBvcGVyYXRlcyBpbiB0aGUgTVBMUyBkYXRhcGxh bmUsIGRvIHNvIG5vdCBleHBsaWNpdGx5IGRlcGVuZGluZyBvbiB0aGUgaW1wbGVtZW50YXRpb24g b2YgdGhlIGV4dGVuc2lvbnMgKHdoaWNoIGluIGZhY3Qgc2VlbSB0byBhbHJlYWR5IGFjY291bnQg Zm9yIGRpZmZlcmVudCBsZW5ndGhzKS4NCg0KDQpNMi4gW0kgbWVudGlvbmVkIHRoZXNlIGlzc3Vl cyBpbiB0aGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZyBhcyB3 ZWxsLl0NCg0KTTIuMS4g4oCcVGhlIG5vdGlvbiBvZiBpbmRleGVkIGdsb2JhbCBzZWdtZW50LCBk ZWZpbmVkIGluIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nXeKApuKAnSAgVGhhdCBk b2N1bWVudCBkb2VzbuKAmXQgcHJvcGVybHkgZGVmaW5lIHRoZSBjb25jZXB0L3VzZSBvZiB0aGUg aW5kZXguICBUaGVyZSBhcmUgc2V2ZXJhbCBtZW50aW9ucyBpbiB0aGlzIGRvY3VtZW50IHRoYXQg SSB0aGluayByZWx5IG9uIGEgcHJvcGVyIGRlZmluaXRpb24vZGlzY3Vzc2lvbiBvZiB0aGUgY29u Y2VwdC4NCg0KTTIuMi4gVGhlIGNvbmNlcHQgb2YgYW4gU1JMQiBpcyBub3QgZGVmaW5lZCBpbiB0 aGUgQXJjaGl0ZWN0dXJlIGRvY3VtZW50IGVpdGhlci4NCg0KDQpNMy4gU3RpbGwgaW4gU2VjdGlv biAyLCBmcm9tIHRoaXMgdGV4dDoNCg0KICAgICAgKiAgV2hlbiBkaWZmZXJlbnQgU1JHQnMgYXJl IHVzZWQsIHRoZSBvdXRnb2luZyBsYWJlbCB2YWx1ZSBpcyBzZXQNCiAgICAgICAgIGFzOiBbU1JH QihuZXh0X2hvcCkraW5kZXhdLiAgSWYgdGhlIGluZGV4IGNhbid0IGJlIGFwcGxpZWQgdG8NCiAg ICAgICAgIHRoZSBTUkdCIChpLmUuOiBpZiB0aGUgaW5kZXggcG9pbnRzIG91dHNpZGUgdGhlIFNS R0Igb2YgdGhlDQogICAgICAgICBuZXh0LWhvcCBvciB0aGUgbmV4dC1ob3AgaGFzIG5vdCBhZHZl cnRpc2VkIGEgdmFsaWQgU1JHQiksIHRoZW4NCiAgICAgICAgIG5vIG91dGdvaW5nIGxhYmVsIHZh bHVlIGNhbiBiZSBjb21wdXRlZCBhbmQgdGhlIG5leHQtaG9wIE1VU1QNCiAgICAgICAgIGJlIGNv bnNpZGVyZWQgYXMgbm90IHN1cHBvcnRpbmcgdGhlIE1QTFMgb3BlcmF0aW9ucyBmb3IgdGhhdA0K ICAgICAgICAgcGFydGljdWxhciBTSUQuDQoNCuKApnNldmVyYWwgcXVlc3Rpb25zL2NvbW1lbnRz 4oCmDQoNCk0zLjEuIFttaW5vcl0gSSBob3BlIHRvIHNlZSBhbiBleHBsYW5hdGlvbiBvZiB0aGUg 4oCcW1NSR0IobmV4dF9ob3ApK2luZGV4XeKAnSBub3RhdGlvbi4NCg0KTTMuMi4gV2hhdCBpcyBh IOKAnHZhbGlkIFNSR0LigJ0/ICBJIGRvbuKAmXQgdGhpbmsgdGhlIHZhbGlkaXR5IG9mIHRoZSBT UkdCIGlzIGRlc2NyaWJlZCBpbiB0aGUgQXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KDQpNMy4zLiBJ 4oCZbSBhc3N1bWluZyB0aGF0IG9uY2UgdGhlIOKAnG5leHQtaG9wIE1VU1QgYmUgY29uc2lkZXJl ZCBhcyBub3Qgc3VwcG9ydGluZ+KAnSB0aGVuIHRoZSBwYWNrZXRzIGFyZSBkcm9wcGVkLCByaWdo dD8NCg0KTTMuNC4gW01heWJlIEnigJltIG1pc3Npbmcgc29tZXRoaW5nIG9idmlvdXMgaGVyZS5d ICBHb2luZyBiYWNrIHRvIHRoZSB2YWxpZGl0eSBvZiB0aGUgU1JHQiBhZHZlcnRpc2VkIGJ5IGEg c3BlY2lmaWMgbm9kZSwgc2hvdWxkbuKAmXQgdGhlIGluZ3Jlc3Mgbm9kZSB2ZXJpZnkgdGhhdCBi ZWZvcmUgaW1wb3NpbmcgYSBwYXRoIHRoYXQgd2lsbCBmYWlsPyAgQnV0IEkgY291bGRu4oCZdCBm aW5kIGFueXRoaW5nIGluIHRoZSBBcmNoaXRlY3R1cmUgZG9jdW1lbnQgdGhhdCB0YWxrcyBhYm91 dCB0aGUgaW5ncmVzcyBub2RlIHZlcmlmeWluZyB0aGF0IHRoZSBwYXRoIGlzIHZhbGlkIChpbmNs dWRpbmcgdGhlIHZhbGlkaXR5IG9mIHRoZSBTUkdCKS4NCg0KDQpNNC4gU3RpbGwgaW4gU2VjdGlv biAyOiDigJxBcyBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmdd LCB1c2luZyB0aGUgc2FtZSBTUkdCIG9uIGFsbCBub2RlcyB3aXRoaW4gdGhlIFNSIGRvbWFpbiBl YXNlcyBvcGVyYXRpb25zIGFuZCB0cm91Ymxlc2hvb3RpbmcgYW5kIGlzIGV4cGVjdGVkIHRvIGJl IGEgZGVwbG95bWVudCBndWlkZWxpbmUu4oCdICBBcyBJIG1lbnRpb25lZCBpbiBteSByZXZpZXcg b2YgdGhlIEFyY2hpdGVjdHVyZSBkb2N1bWVudCwgdGhhdCBkb2N1bWVudCBkb2VzbuKAmXQgY29u dGFpbiBkZXBsb3ltZW50IGd1aWRlbGluZXMgcmVsYXRlZCB0byB0aGUgU1JHQiwgYW5kIGl0IGRv ZXNu4oCZdCBkZXNjcmliZSBob3cg4oCcdXNpbmcgdGhlIHNhbWUgU1JHQuKApmVhc2VzIG9wZXJh dGlvbnMgYW5kIHRyb3VibGVzaG9vdGluZ+KAnS4NCg0KDQoNCk1pbm9yDQoNClAxLiBUaGUgdGVy bSDigJxzZXJ2aWNlIGNoYWlu4oCdIGlzIHVzZWQgaW4gdGhlIEFic3RyYWN0LiAgR2l2ZW4gdGhh dCB0aGUgY29uY2VwdCBpcyBub3Qgdml0YWwgdG8gdGhlIGFyY2hpdGVjdHVyZSBhbmQgdGhhdCB0 aGVyZSBtaWdodCBiZSB1bm5lY2Vzc2FyeSBjb25mdXNpb24gd2l0aCBTRkMsIEkgd291bGQgc3Vn Z2VzdCB0YWtpbmcgaXQgb3V0Lg0KDQpQMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyB0byBWUE4s IFZQTFMsIFZQV1MsIExEUCwgUlNWUC1UReKApndvdWxkIGJlIG5pY2UuDQoNClAzLiBTZWN0aW9u IDIuIChNUExTIEluc3RhbnRpYXRpb24gb2YgU2VnbWVudCBSb3V0aW5nKSBzYXlzIHRoYXQg4oCc YSBjb250cm9sbGVyLWRyaXZlbiBuZXR3b3Jr4oCmTUFZIHVzZSB0aGUgY29udHJvbCBwbGFuZSB0 byBkaXNjb3ZlciB0aGUgYXZhaWxhYmxlIHNldCBvZiBsb2NhbCBTSURz4oCdLiAgVGhlIOKAnE1B WeKAnSBpbXBsaWVzIHRoYXQgdGhlcmUgaXMgYSBjaG9pY2UgKGkuZS4gaXQgaXMgb3B0aW9uYWwp IGFuZCB0aGF0IG90aGVyIGRpc2NvdmVyeSBtZWNoYW5pc21zIGV4aXN0LiAgV2hhdCBhcmUgdGhv c2Ugb3RoZXIgY2hvaWNlcz8gIE5vdGUgdGhhdCBlYXJsaWVyIGluIHRoaXMgc2VjdGlvbiB5b3Ug YWxyZWFkeSB3cm90ZSB0aGF0IElHUHMgYXJlIHVzZWQgZm9yIGZsb29kaW5nIHRoZSBpbmZvcm1h dGlvbi4gIHMvTUFZL21heQ0KDQpQNC4gU2VjdGlvbiAyOiDigJzigKZ0aGUgdXNlIG9mIHRoZSBi aW5kaW5nIHNlZ21lbnQgYXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nXSwgYWxzbyBhbGxvd3MgdG8gc3Vic3RhbnRpYWxseSByZWR1Y2UgdGhlIGxlbmd0aCBv ZiB0aGUgc2VnbWVudCBsaXN04oCm4oCdICBOaWNlLCBidXQgdGhlcmUgaXMgbm8gZGVzY3JpcHRp b24gb2YgdGhlIGJpbmRpbmcgc2VnbWVudCBpbiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmcuDQoNClA1LiBSZWZlcmVuY2VzLiAgUGxlYXNlIHRha2UgYSBsb29rIGF0IHJmYzgxNzQg YW5kIHVwZGF0ZSB0aGUg4oCcUmVxdWlyZW1lbnRzIExhbmd1YWdl4oCdIGFuZCBhc3NvY2lhdGVk IHJlZmVyZW5jZXMuDQoNCg0KDQpOaXRzDQoNCk4xLiBJIHRoaW5rIHRoYXQgdGhlIHJlZmVyZW5j ZXMgdG8gKi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucyBhcmUgc3VwZXJmbHVvdXMuICBCVFcs IHRoZSBmb3VydGggcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rpb24gdXNlcyBhIHJlZmVyZW5j ZSB0byAqLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zIHRvIHBvaW50IGF0IElTSVMvT1NQRiAo dGhlIHByb3RvY29scyEpLg0KDQpOMi4gSXQgd291bGQgYmUgdmVyeSBuaWNlIGlmIHRoZSBleGFt cGxlcyB1c2VkIElQdjYgYWRkcmVzc2VzLg0K --_000_74FB72FCAD694EA3ACA2739168EE0A44ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <27C13886393F924FB0CB473FDE44B390@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNyIv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgYXV0aG9yczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkkganVzdCBmaW5pc2hlZCByZWFkaW5nIHRoaXMgZG9jdW1lbnQu Jm5ic3A7IFBsZWFzZSB0YWtlIGEgbG9vayBhdCBteSBjb21tZW50cyBiZWxvdy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBtYWluIHF1ZXN0aW9ucy9jb25j ZXJucyB0aGF0IEkgaGF2ZSByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQgaXMgbm90IGp1c3QgZm9y IHRoZSBhdXRob3JzLCBidXQgZm9yIHRoZSBTaGVwaGVyZCBhbmQgdGhlIENoYWlycyB0b28uJm5i c3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlExLiBXaHkg aXMgdGhpcyBkb2N1bWVudCBvbiB0aGUgU3RhbmRhcmRzIFRyYWNrPyBGcm9tIHRoZSBJbnRyb2R1 Y3Rpb246IOKAnFRoaXMgZHJhZnRzIGRlc2NyaWJlcyBob3cgU2VnbWVudCBSb3V0aW5nIG9wZXJh dGVzIG9uIHRvcCBvZiB0aGUgTVBMUyBkYXRhIHBsYW5lLuKAnSZuYnNwOyBEZXNjcmliZXMsIHll cy4mbmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIHRoZSBTaGVwaGVyZOKAmXMNCiB3cml0ZS11cCBz YXlzIHRoYXQgaXQg4oCcc3BlY2lmaWVzIHRoZSBnZW5lcmljIGZ1bmN0aW9ucyBvZiB0aGUgYXJj aGl0ZWN0dXJl4oCdIOKAkyBJIGRvbuKAmXQgc2VlIGEgc3BlY2lmaWNhdGlvbiwganVzdCBhIGRl c2NyaXB0aW9uLiZuYnNwOyBBcyBzdWNoLCBJIHRoaW5rIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJl IEluZm9ybWF0aW9uYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5RMi4gU2VjdGlvbiAyLiAoTVBMUyBJbnN0YW50aWF0aW9uIG9mIFNlZ21lbnQgUm91dGluZykg aXMgdGhlIG9ubHkgb25lIHdpdGggYW55IHJlYWwgY29udGVudOKApmJ1dCB0aGVyZSBhcmUgb25s eSBhIGNvdXBsZSBvZiB0aGluZ3MgaW4gaXQgdGhhdCBhcmUgbm90IGluIHRoZSBBcmNoaXRlY3R1 cmUgZG9jdW1lbnQ6IHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIFNSTEIsDQogYW5kIHNvbWUgd29y ZHMgYWJvdXQgdGhlIGluZGV4IOKAkyBib3RoIG9mIHdoaWNoIHNob3VsZCBiZSByZWFsbHkgZXhw bGFpbmVkIGluIHRoZSBBcmNoaXRlY3R1cmUgZG9jdW1lbnQsIGFuZCBub3QgaGVyZS4mbmJzcDsg SSB3b25kZXIgd2hhdCB0aGUgdmFsdWUgb2YgcHVibGlzaGluZyB0aGlzIGRvY3VtZW50IHJlYWxs eSBpcy4mbmJzcDsgV2hhdCBsb25nLXRlcm0gYXJjaGl2YWwgdmFsdWUgZG9lcyBpdCBwcm92aWRl PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UTMuIEkgYWxzbyBo YXZlIHRvIHdvbmRlciBhYm91dCB0aGUgSVBSIGRlY2xhcmVkIGZvciB0aGlzIGRvY3VtZW50LiZu YnNwOyBJZiBtb3N0IG9mIHRoZSBpbmZvcm1hdGlvbiBoZXJlIGlzIGFscmVhZHkgZGVmaW5lZCwg ZGVzY3JpYmVkIG9yIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmcsIHNob3VsZCB0aGUgSVBSIGRlY2xhcmF0aW9uDQogYXBwbHkgdG8gdGhhdCBkb2N1bWVudCBh cyB3ZWxsIChvciBtYXliZSBpbnN0ZWFkIG9mIHRoaXMgb25lKT8mbmJzcDsgSXQgaXMgbm90IHRo ZSBJRVRG4oCZcyByb2xlIChpbmNsdWRpbmcgdGhlIFdHKSB0byBkaXNjdXNzIHdoZXRoZXIgYSBw aWVjZSBvZiBJUFIgaXMgdmFsaWQgb3Igbm90IOKAkyBJIGp1c3Qgd2FudCB0byBtYWtlIHN1cmUg dGhlIGRpc2Nsb3N1cmVzIGFwcGx5IHRvIHRoZSByaWdodCBkb2N1bWVudC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J IGRpZG7igJl0IGZpbmQgYSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGFib3V0IGFueSBvZiB0aGVz ZSBwb2ludHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRo YW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFsdmFyby48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5NYWpvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+TTEuIFNlY3Rpb24gMi4gKE1QTFMgSW5zdGFudGlhdGlvbiBvZiBTZWdtZW50IFJvdXRpbmcp IGV4cGxhaW5zIGhvdyDigJxpbiB0aGUgTVBMUyBpbnN0YW50aWF0aW9uLCB0aGUgU0lEIHZhbHVl cyBhcmUgYWxsb2NhdGVkIHdpdGhpbiBhIHJlZHVjZWQgMjAtYml0IHNwYWNlIG91dCBvZiB0aGUg MzItYml0IFNJRCBzcGFjZS7igJ0mbmJzcDsgSG93ZXZlciwgSSBjb3VsZG7igJl0DQogZmluZCB3 aGVyZSBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmcgZGVmaW5lcyB0aGUgU0lEIHNw YWNlIGFzIHVzaW5nIDMyIGJpdHMgKG9yIGFueSBvdGhlciBsZW5ndGgpLiZuYnNwOyBJbiBmYWN0 LCB0aGUgY2xvc2VzdCB0aGF0IGRvY3VtZW50IGNvbWVzIGlzIHdoZW4gaXQgZGVmaW5lcyBhbiBT SUQgYW5kIG1lbnRpb25zIOKAnEV4YW1wbGVzIG9mIFNJRHMgYXJlOiBhbiBNUExTIGxhYmVsLCBh biBpbmRleCB2YWx1ZSBpbiBhbiBNUExTIGxhYmVsDQogc3BhY2UsIGFuIElQdjYgYWRkcmVzcy7i gJ0mbmJzcDsmbmJzcDsgSeKAmW0gYXNzdW1pbmcgdGhlIOKAnDMyLWJpdCBTSUQgc3BhY2XigJ0g Y29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZSBleHRlbnNpb25zIGRlZmluZSBhbiBTSUQgb2Yg dGhhdCBsZW5ndGguJm5ic3A7IEFsbCB0aGlzIGlzIHRvIHNheSB0aGF0IGFzIHlvdSBkZXNjcmli ZSBob3cgU1Igb3BlcmF0ZXMgaW4gdGhlIE1QTFMgZGF0YXBsYW5lLCBkbyBzbyBub3QgZXhwbGlj aXRseSBkZXBlbmRpbmcgb24gdGhlIGltcGxlbWVudGF0aW9uDQogb2YgdGhlIGV4dGVuc2lvbnMg KHdoaWNoIGluIGZhY3Qgc2VlbSB0byBhbHJlYWR5IGFjY291bnQgZm9yIGRpZmZlcmVudCBsZW5n dGhzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5NMi4gW0kgbWVudGlvbmVkIHRoZXNlIGlzc3VlcyBpbiB0aGUgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZyBhcyB3ZWxsLl08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLjEuIOKAnFRoZSBub3Rpb24g b2YgaW5kZXhlZCBnbG9iYWwgc2VnbWVudCwgZGVmaW5lZCBpbiBbSS1ELmlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZ13igKbigJ0mbmJzcDsgVGhhdCBkb2N1bWVudCBkb2VzbuKAmXQgcHJvcGVy bHkgZGVmaW5lIHRoZSBjb25jZXB0L3VzZSBvZiB0aGUgaW5kZXguJm5ic3A7IFRoZXJlIGFyZSBz ZXZlcmFsIG1lbnRpb25zIGluIHRoaXMgZG9jdW1lbnQNCiB0aGF0IEkgdGhpbmsgcmVseSBvbiBh IHByb3BlciBkZWZpbml0aW9uL2Rpc2N1c3Npb24gb2YgdGhlIGNvbmNlcHQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NMi4yLiBUaGUgY29uY2VwdCBvZiBhbiBT UkxCIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBBcmNoaXRlY3R1cmUgZG9jdW1lbnQgZWl0aGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPk0zLiBTdGlsbCBpbiBTZWN0aW9uIDIsIGZyb20gdGhpcyB0ZXh0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICombmJzcDsgV2hlbiBkaWZmZXJlbnQgU1JHQnMgYXJlIHVzZWQsIHRoZSBvdXRn b2luZyBsYWJlbCB2YWx1ZSBpcyBzZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzOiBbU1JHQihuZXh0X2hvcCkmIzQz O2luZGV4XS4mbmJzcDsgSWYgdGhlIGluZGV4IGNhbid0IGJlIGFwcGxpZWQgdG88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRoZSBTUkdCIChpLmUuOiBpZiB0aGUgaW5kZXggcG9pbnRzIG91dHNpZGUgdGhlIFNSR0Igb2Yg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBuZXh0LWhvcCBvciB0aGUgbmV4dC1ob3AgaGFzIG5vdCBhZHZlcnRpc2Vk IGEgdmFsaWQgU1JHQiksIHRoZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vIG91dGdvaW5nIGxhYmVsIHZhbHVlIGNh biBiZSBjb21wdXRlZCBhbmQgdGhlIG5leHQtaG9wIE1VU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIGNvbnNpZGVy ZWQgYXMgbm90IHN1cHBvcnRpbmcgdGhlIE1QTFMgb3BlcmF0aW9ucyBmb3IgdGhhdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcGFydGljdWxhciBTSUQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij7igKZzZXZlcmFsIHF1ZXN0aW9ucy9jb21tZW50c+KApjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTMuMS4gW21pbm9yXSBJIGhvcGUgdG8gc2VlIGFuIGV4 cGxhbmF0aW9uIG9mIHRoZSDigJxbU1JHQihuZXh0X2hvcCkmIzQzO2luZGV4XeKAnSBub3RhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0zLjIuIFdoYXQg aXMgYSDigJx2YWxpZCBTUkdC4oCdPyZuYnNwOyBJIGRvbuKAmXQgdGhpbmsgdGhlIHZhbGlkaXR5 IG9mIHRoZSBTUkdCIGlzIGRlc2NyaWJlZCBpbiB0aGUgQXJjaGl0ZWN0dXJlIGRvY3VtZW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTMuMy4gSeKAmW0gYXNz dW1pbmcgdGhhdCBvbmNlIHRoZSDigJxuZXh0LWhvcCBNVVNUIGJlIGNvbnNpZGVyZWQgYXMgbm90 IHN1cHBvcnRpbmfigJ0gdGhlbiB0aGUgcGFja2V0cyBhcmUgZHJvcHBlZCwgcmlnaHQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NMy40LiBbTWF5YmUgSeKAmW0g bWlzc2luZyBzb21ldGhpbmcgb2J2aW91cyBoZXJlLl0mbmJzcDsgR29pbmcgYmFjayB0byB0aGUg dmFsaWRpdHkgb2YgdGhlIFNSR0IgYWR2ZXJ0aXNlZCBieSBhIHNwZWNpZmljIG5vZGUsIHNob3Vs ZG7igJl0IHRoZSBpbmdyZXNzIG5vZGUgdmVyaWZ5IHRoYXQgYmVmb3JlIGltcG9zaW5nIGEgcGF0 aCB0aGF0IHdpbGwgZmFpbD8mbmJzcDsgQnV0IEkNCiBjb3VsZG7igJl0IGZpbmQgYW55dGhpbmcg aW4gdGhlIEFyY2hpdGVjdHVyZSBkb2N1bWVudCB0aGF0IHRhbGtzIGFib3V0IHRoZSBpbmdyZXNz IG5vZGUgdmVyaWZ5aW5nIHRoYXQgdGhlIHBhdGggaXMgdmFsaWQgKGluY2x1ZGluZyB0aGUgdmFs aWRpdHkgb2YgdGhlIFNSR0IpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk00LiBTdGlsbCBpbiBTZWN0aW9uIDI6IOKA nEFzIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ10sIHVzaW5n IHRoZSBzYW1lIFNSR0Igb24gYWxsIG5vZGVzIHdpdGhpbiB0aGUgU1IgZG9tYWluIGVhc2VzIG9w ZXJhdGlvbnMgYW5kIHRyb3VibGVzaG9vdGluZyBhbmQgaXMgZXhwZWN0ZWQgdG8gYmUgYSBkZXBs b3ltZW50IGd1aWRlbGluZS7igJ0mbmJzcDsNCiBBcyBJIG1lbnRpb25lZCBpbiBteSByZXZpZXcg b2YgdGhlIEFyY2hpdGVjdHVyZSBkb2N1bWVudCwgdGhhdCBkb2N1bWVudCBkb2VzbuKAmXQgY29u dGFpbiBkZXBsb3ltZW50IGd1aWRlbGluZXMgcmVsYXRlZCB0byB0aGUgU1JHQiwgYW5kIGl0IGRv ZXNu4oCZdCBkZXNjcmliZSBob3cg4oCcdXNpbmcgdGhlIHNhbWUgU1JHQuKApmVhc2VzIG9wZXJh dGlvbnMgYW5kIHRyb3VibGVzaG9vdGluZ+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+TWlub3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlAxLiBUaGUgdGVybSDigJxzZXJ2aWNlIGNoYWlu4oCdIGlzIHVzZWQgaW4gdGhlIEFic3RyYWN0 LiZuYnNwOyBHaXZlbiB0aGF0IHRoZSBjb25jZXB0IGlzIG5vdCB2aXRhbCB0byB0aGUgYXJjaGl0 ZWN0dXJlIGFuZCB0aGF0IHRoZXJlIG1pZ2h0IGJlIHVubmVjZXNzYXJ5IGNvbmZ1c2lvbiB3aXRo IFNGQywgSSB3b3VsZCBzdWdnZXN0IHRha2luZyBpdCBvdXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyB0byBWUE4s IFZQTFMsIFZQV1MsIExEUCwgUlNWUC1UReKApndvdWxkIGJlIG5pY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMy4gU2VjdGlvbiAyLiAoTVBMUyBJbnN0YW50 aWF0aW9uIG9mIFNlZ21lbnQgUm91dGluZykgc2F5cyB0aGF0IOKAnGEgY29udHJvbGxlci1kcml2 ZW4gbmV0d29ya+KApk1BWSB1c2UgdGhlIGNvbnRyb2wgcGxhbmUgdG8gZGlzY292ZXIgdGhlIGF2 YWlsYWJsZSBzZXQgb2YgbG9jYWwgU0lEc+KAnS4mbmJzcDsgVGhlIOKAnE1BWeKAnSBpbXBsaWVz IHRoYXQgdGhlcmUgaXMgYSBjaG9pY2UNCiAoaS5lLiBpdCBpcyBvcHRpb25hbCkgYW5kIHRoYXQg b3RoZXIgZGlzY292ZXJ5IG1lY2hhbmlzbXMgZXhpc3QuJm5ic3A7IFdoYXQgYXJlIHRob3NlIG90 aGVyIGNob2ljZXM/Jm5ic3A7IE5vdGUgdGhhdCBlYXJsaWVyIGluIHRoaXMgc2VjdGlvbiB5b3Ug YWxyZWFkeSB3cm90ZSB0aGF0IElHUHMgYXJlIHVzZWQgZm9yIGZsb29kaW5nIHRoZSBpbmZvcm1h dGlvbi4mbmJzcDsgcy9NQVkvbWF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5QNC4gU2VjdGlvbiAyOiDigJzigKZ0aGUgdXNlIG9mIHRoZSBiaW5kaW5nIHNlZ21l bnQgYXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nXSwgYWxz byBhbGxvd3MgdG8gc3Vic3RhbnRpYWxseSByZWR1Y2UgdGhlIGxlbmd0aCBvZiB0aGUgc2VnbWVu dCBsaXN04oCm4oCdJm5ic3A7IE5pY2UsIGJ1dCB0aGVyZSBpcyBubyBkZXNjcmlwdGlvbiBvZg0K IHRoZSBiaW5kaW5nIHNlZ21lbnQgaW4gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDUuIFJlZmVyZW5j ZXMuJm5ic3A7IFBsZWFzZSB0YWtlIGEgbG9vayBhdCByZmM4MTc0IGFuZCB1cGRhdGUgdGhlIOKA nFJlcXVpcmVtZW50cyBMYW5ndWFnZeKAnSBhbmQgYXNzb2NpYXRlZCByZWZlcmVuY2VzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OaXRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OMS4gSSB0aGluayB0aGF0IHRoZSByZWZlcmVuY2VzIHRv ICotc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMgYXJlIHN1cGVyZmx1b3VzLiZuYnNwOyBCVFcs IHRoZSBmb3VydGggcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rpb24gdXNlcyBhIHJlZmVyZW5j ZSB0byAqLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zIHRvIHBvaW50IGF0IElTSVMvT1NQRiAo dGhlIHByb3RvY29scyEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+TjIuIEl0IHdvdWxkIGJlIHZlcnkgbmljZSBpZiB0aGUgZXhhbXBsZXMgdXNlZCBJUHY2IGFk ZHJlc3Nlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_74FB72FCAD694EA3ACA2739168EE0A44ciscocom_-- From nobody Thu Aug 24 13:44:43 2017 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 DACE01321A3; Thu, 24 Aug 2017 13:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 zBrk3Ojnkg-U; Thu, 24 Aug 2017 13:44:39 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10105.outbound.protection.outlook.com [40.107.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FE11320D8; Thu, 24 Aug 2017 13:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mWj8ynVIJ2tiozM93zx1qbLqd0hs4QQ4hc1eDVQGbrQ=; b=B6Y3kD56JBnCz59y+wbqYpxHjjTIcXinLGumumL4YBC6OllitarxfC2vbeAOOX4R+XjBTIX53Vf6PDV4KzGkna7M4xuPQ3mKob1hJyqwhK9yuBlqaxH3GTZk9EGlxqVrTTrn14HIAs4ktCSO3Gate8UsqFlJOFd8vUS3HcKPYVE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [192.168.0.12] (88.182.48.47) by HE1PR0701MB2474.eurprd07.prod.outlook.com (2603:10a6:3:71::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Thu, 24 Aug 2017 20:44:32 +0000 To: "Alvaro Retana (aretana)" , "draft-ietf-spring-segment-routing-mpls@ietf.org" References: <74FB72FC-AD69-4EA3-ACA2-739168EE0A44@cisco.com> Cc: "spring-chairs@ietf.org" , "spring@ietf.org" From: Martin Vigoureux Message-ID: Date: Thu, 24 Aug 2017 22:44:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <74FB72FC-AD69-4EA3-ACA2-739168EE0A44@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [88.182.48.47] X-ClientProxiedBy: DB6PR07CA0092.eurprd07.prod.outlook.com (2603:10a6:6:2b::30) To HE1PR0701MB2474.eurprd07.prod.outlook.com (2603:10a6:3:71::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8eca833f-56e6-4493-a058-08d4eb30ed3d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB2474; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2474; 3:uKaESBXmccvZMX89KEVYQ9LNdsnFL4yTrphWukP29f+yH/K5Ad/hpHpK8VxzIIbHny7J/dBlB4bpjLZkvTFEWXm783TKcQBw0N6/1oqBTgv7EDvlOp79UOl75G5wIhg0KH/RGfryronKczn+mDLSBsqwqe1GIj6HFbDFAJWnqUe//EBwKq3nGiTzg3jMgknbtv+yhSw9yHxQL5+7Di07JlkGY3B4ijNmT2seWHj2BXtt3dJfFlYsbOfe0lYj8dJq; 25:Xr2qZEAO4oeEmY292WaQ2py2Y9p8Wq16zKpfFUamTZluT/MtxrZtrii2YVAXBkKQj4F7PLPTgrAmasGKL35cxSZe/zsmRHioO5cNwCasTFM3IBLN7l7SHNGqExGeg2ddo+kdLAduNRL93a20m4rY/zK3JPfUlgmhlK2b+/G1J8MtvRhzSerax8sAI+ZAujkHHSsO4i+4j89w2RnugaIeh81nNuWnyMD6YehVxCfMTg/aS+CdL/U9uq5KMSNuiAz6c94IM11Dh1E3bYGx/MMZyoBXVHE8EccklLvUw93b+CLWsdlKC/A+pznbIQGoKVLBzNBeM/Qe5g4xFWTDHdrvkQ==; 31:97U/pZKoS33RVavMFoJUd65hyGZTnyX9DuOleQ7VBHpyZL0iXeSEbOpNR4bM7p8oUxoSx7yBpByWI5YyTvzFNGgE0zpNfpq4xq7pkcdhTEm0nyKTo2glrS5OX5+xqWUkuHctpE1/LtjRLbeKY9mmqMvMqcvaMvjM+fXgUmvr3TIBRa7BQXu2FgOcXYHHhZ9wsw9EOZFroI25IoEz3gltmfRpqWZEFtr6shzjTOXI0SU= X-MS-TrafficTypeDiagnostic: HE1PR0701MB2474: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2474; 20:/fEhJ4rv2uIie9vPf8sn6G1NMWzpyz1JTgE/Weh51e4+l0rJcCZ9TS+8boif/N14Sp8Uab5WmFpV7nL1xXkcaAyXQK4bp267jloXs9bnhtzlhql4GbxJbLq9kLVAEomij8y2epFvLQGWphjbXfoiNu24fpS0OuI5hFUaKa6Q6i4mGMwCUjI3nw24JbmOBb/IZFpyI4wlYsYoSOw16+d1kE9ULEVRvfOaeVYYUGNybUuTTY2O1FpSnanbOB9VO9Uv7vVT4lABB3wyWs2Q5IezhoLgdlu5krUFk4IFDl8TkQGphvk7gPub0F6Tr5TEhZa+bANqazfYaNAaCNEs1drjFvCZlLYmBp499IYEbuvVwT2JxGI1UXDtI3TEHDJI7nrUdLmmVUw9+lxGwbCcHaqJ82mTBI3tFhB2ljRTmGcXp0Bg0w3mVMVvU49VRvTa8cCn4mBgK6I4JhV+1Cb21qCdfzYAF0SFIoqjM/gEIh/y9b82bcl7TEplqqxUMRdevAub; 4:uZLfmrVdBhQVGz7fhu/jqKtipEofFFXWGRkVx236Da5GxGkoiFvka43WIbMFIdXmEECJvldzLi04406N00QqzIBE+ufiZtBIEcOH77vLeHB6n9gXvCJfBpz0K5LQVJfkUVfD7WtqMoVc81x/scJkk4SwCVG8KZta6dJXhn4JScB/+Pql0HLU6+m6Xa6TjmT1SLPG/B4FJqboKQS/0nNeV6ppdXufLhBMDeqqhsQdB4ZZwDgB/2rLq7/Otnm6GKPL X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2474; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2474; X-Forefront-PRVS: 04097B7F7F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39860400002)(199003)(189002)(51444003)(37854004)(4326008)(31696002)(83506001)(8676002)(4001350100001)(106356001)(305945005)(53936002)(7736002)(105586002)(68736007)(81166006)(23676002)(6116002)(47776003)(2950100002)(478600001)(97736004)(3846002)(81156014)(5660300001)(65826007)(117156002)(36756003)(2906002)(50466002)(2870700001)(54906002)(189998001)(7350300001)(2501003)(86362001)(64126003)(54356999)(229853002)(65956001)(42186005)(50986999)(65806001)(101416001)(25786009)(76176999)(6246003)(230783001)(77096006)(6666003)(66066001)(31686004)(6486002)(33646002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2474; H:[192.168.0.12]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjI0NzQ7MjM6ZUNxSTRtSGNQQjFQVGRUZG1jSzhHY0RW?= =?utf-8?B?ZUNyeUQxQUF4ZHpia09URFJCL29rNld4QVNVbHgrRlF1Y253VUp1MmlUdTVm?= =?utf-8?B?VzBhdVo3NDJGUUhCQ1VLaEhxZU1lQWlod1dVd1BPTFhZQi9qVENObjZIeWZM?= =?utf-8?B?bHJwQXdqWjNUdUIzSWl1dFBIQUdCMDhweTNpY2xEZlBpOUtOMHA3RzY5VTBx?= =?utf-8?B?SnpocDdkcDZpZ1FhWU80NzFzaHRpNHhERWk1TUZJbVBJdUR5ajBUSnVianUr?= =?utf-8?B?Zlp6aWJRRGdpYjZ6bjl5L1JnWEptMjlseDNDTVlFaXJTdzhEVSt6bVRuaytC?= =?utf-8?B?VXBua3ZSTjN5U2g5YW5TSGZPRkpXdUtiOVBhMTBoeUlXNHpKK1ViSzJtc1M3?= =?utf-8?B?ZGtyZDFnS0l5M2RxeGZieWtqYVBBL041bDYzVm9kbkpkdHJnY29CTVVFSUda?= =?utf-8?B?aUpwakp4NXBteEtNVHFJdEZ5bUc0YkcxdENuVW51akNiWWJjbGpvWHdVdElD?= =?utf-8?B?OWNZKzlGL0ViN2N5eXdnQWh1ZVZJTG55NlZCRXc4U1Nkb1d5dzNCNExEUTdE?= =?utf-8?B?ZnU2bk9mcWtINlVHYjY2UUl5QmQzQTlLNUF0SWZxTHJSdEFRUjVXcjhvcDY5?= =?utf-8?B?aEVnSGsvRFplblJvMTN5WDg5WE9OUis3cjNoWFExcDhMa01Cd0ROaE9hV3Fy?= =?utf-8?B?dzZaajEzNUNJbUN6NmU4dVJmTFFHUUU2UllKS3BTb05NRUZxdk54a3hxc2RG?= =?utf-8?B?S3hnajV6YmE2MkJiMlJQSFBZY3RsczZpVDVsSlc4YjZSSGJBYlN3ZDdtcXRW?= =?utf-8?B?OXVZeHN6aTNiR2RCeHZRcWF6aHdab2NMVXdLemE3VXBKUjh4QkRaL0ZJNSt6?= =?utf-8?B?aVR4YjczRElwem1zd1hhNW92dkFhNjNmRkFpanhzR00vTitua2FoemphaUs3?= =?utf-8?B?eHU0OTNCY1dOSVYzVXpod1JZM2JZQVBnRGxmQUdvWDFZUkhqT29SSkd1RTQz?= =?utf-8?B?akxqZGhmZEVrd0Y4aW92eEtPYS9tUFBOaHFBc3dRZzJVSmhRc0o0cGtYdUs5?= =?utf-8?B?YWtySXJ6YUl2T0tGb05NRUtoSDJMY1VSWXlRdWYwNVkzZzY1aUZ2bmFtU29y?= =?utf-8?B?bFRtaHFWNWlJVm9XbGk4a2Zvb2pXRkNDVEV5QmJRcHh5SzdyZ1N6eFduTnl2?= =?utf-8?B?dkwvcEd0OVRQRWo3TzM2Q25nbFBub1FpUDMrVUE1Tk95ZUREYkF4Q2lwbEFP?= =?utf-8?B?Q3prMTg4TW1keDN3UDdYSEFLbzN2RmNUd21Zb2YrRGF2NHdzbDdpaUtJeFBj?= =?utf-8?B?Tkl4d0FVWDZ0K2xhZFBxWUIxUzB5dkN1TTZ5UlBtTDhCTjFPVmxPdXBocElC?= =?utf-8?B?ZW1wdHJ6TENRMmgvYy9NZ3BkS3dxMG5sK3gzVmZQTW9BTjR3R0NBdk5zWW5I?= =?utf-8?B?MFVNMVZZemsyWC9vS0FpRGplYUMzelRTeVB4MlNPQnNIM3c0RlVaOERrNmVV?= =?utf-8?B?dDhHbmNjTkl3TUdIREhrU0JnUE9XZXF5MDhRZCtTVzMxQkRqaEtBWkViTStr?= =?utf-8?B?RWNKa2c5bFczcm5vbXJQakZvczlZVFB5WkVjTUt5NWVWbXQvZmN1alZwTS8v?= =?utf-8?B?U3RxWDljZ1FrRnZ0dE4wWHErU1BRWmk2WnA1aDVOSjFRTXVCdm9YdGh4RnVs?= =?utf-8?B?d3ZWUThyUkZaSnFGNXNYMzZTRmRodHNkZUxvdnB6clJSZVV6WkZkZ1FjQkhQ?= =?utf-8?B?aVNPZUpkUVREYmhUNURDdzRjTno0V0k5OEFkVkZaSFZSQjBXanNFNit0RnBi?= =?utf-8?B?cnhpb2FuYmdCSS9EeWpSdDhlZHcrRTk0ZWVZeFFNNkhvUWdEbkJ4RkFsbk94?= =?utf-8?B?L0FscFlkdjNEQ1p5YjJ5QkxxcmhMYXpudUJkci9qdmZMMlpoV3pnWkppZVBj?= =?utf-8?B?anBmL1dXRmw2c0E9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2474; 6:hBilNQ3Z1YMPKrmjUsrFG2xg+0jGamcszA4/uxmIQH9HBe+OeY/TCOTZRYsCUHw6gDZ02EMxZ2AVZy/siUhtuJ0XvtBh1CBuesW8V6u2+d+pLsDgVGSwU8ECLga7zOws8/nw/aQzwRwviNvjtWkmzagi1Gp3SuXjfCAeEdVjAU773xgQxGKOPooSC40lAsvkLWbfsuzVu+HkQmiNydgTa6DcSGX4JtZnYIkbkUrWNk53BfsGK/iiYV1DbyXfA6k/4ordZiOLdypYZVJMwKz/H33s4tJJ7mfksJ2pVEjMVtO3LAx6tG6U89ahg2+UzB3f4elG5PRyE/hDev3cHSG1xw==; 5:lmx7L2a7NHa8wFCs01pJB1Q/HuS6/HCD5yPIqBAlA6w69jZ93oj9cMmq7irM7PCGGgQlBZy+wht39M16Fr3Eb4eVd9FPAPOGlbAXhAJzNIAG4Lu0V5OtQ431mMPWYHKqRjSovPwkrcOeFA0moi6bVA==; 24:zgnsE1HJ/WgosnwIuHnYlZ4K0XofSeLmqAl0pwgaFp0DsZBOiWi0FdWPl+L+4ONNuaxiZfeBeBUOlid9PNKtnxYCNQWdwiDZZb1owbmk0ac=; 7:zv2dQagie0sTiSoXwH6+tmtXxsPZ3qNtMyHaT9A7cXEjhrrLL9XtMYBsVRv66HutQcgK8dom3DJ+h3DZKMJLt0RjkkMP3oWv4xEVSejKf/ZiaueQ++dRASRIuIOEgHBHhsEIQaFiiLm+30klEwM1WW9JSbJvE4ULLdbYhqnAawnYw0WcjmCWk0ziAp0Nd5dvLaywb3Ypc+6wiUeXeHtzZD1coY/wIgRjI6XnYYtHlwo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2017 20:44:32.9779 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2474 Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:44:42 -0000 Alvaro, speaking as Shepherd. Regarding Q1&Q2: Indeed, Section 2 is the core of the document, and in my view the section containing what is worth standardizing. Document was already trimmed as part of the shepherd review. If Section 2 was to be moved out of the document then yes, I think it could naturally become an Informational document. Yet, I see value in having both a generic architecture and specific documents on how it can be implemented using a specific technology. Also, Standard Track documents do not need to be long to be useful. Regarding Q3: since, as you say, we can not state whether a given piece of IPR is valid or not, I am not sure whether we can discuss the applicability of IPR disclosures (made against other documents) to this document, and vice versa. -m Le 24/08/2017 à 04:38, Alvaro Retana (aretana) a écrit : > Dear authors: > > > > I just finished reading this document. Please take a look at my > comments below. > > > > The main questions/concerns that I have related to this document is not > just for the authors, but for the Shepherd and the Chairs too. > > > > Q1. Why is this document on the Standards Track? From the Introduction: > “This drafts describes how Segment Routing operates on top of the MPLS > data plane.†Describes, yes. On the other hand, the Shepherd’s > write-up says that it “specifies the generic functions of the > architecture†– I don’t see a specification, just a description. As > such, I think this document should be Informational. > > > > Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one > with any real content…but there are only a couple of things in it that > are not in the Architecture document: the introduction of the SRLB, and > some words about the index – both of which should be really explained in > the Architecture document, and not here. I wonder what the value of > publishing this document really is. What long-term archival value does > it provide? > > > > Q3. I also have to wonder about the IPR declared for this document. If > most of the information here is already defined, described or specified > in draft-ietf-spring-segment-routing, should the IPR declaration apply > to that document as well (or maybe instead of this one)? It is not the > IETF’s role (including the WG) to discuss whether a piece of IPR is > valid or not – I just want to make sure the disclosures apply to the > right document. > > > > > > I didn’t find a discussion on the list about any of these points. > > > > Thanks! > > > > Alvaro. > > > > > > Major > > > > M1. Section 2. (MPLS Instantiation of Segment Routing) explains how “in > the MPLS instantiation, the SID values are allocated within a reduced > 20-bit space out of the 32-bit SID space.†However, I couldn’t find > where draft-ietf-spring-segment-routing defines the SID space as using > 32 bits (or any other length). In fact, the closest that document comes > is when it defines an SID and mentions “Examples of SIDs are: an MPLS > label, an index value in an MPLS label space, an IPv6 address.†I’m > assuming the “32-bit SID space†comes from the fact that the extensions > define an SID of that length. All this is to say that as you describe > how SR operates in the MPLS dataplane, do so not explicitly depending on > the implementation of the extensions (which in fact seem to already > account for different lengths). > > > > > > M2. [I mentioned these issues in the review of > draft-ietf-spring-segment-routing as well.] > > > > M2.1. “The notion of indexed global segment, defined in > [I-D.ietf-spring-segment-routing]…†That document doesn’t properly > define the concept/use of the index. There are several mentions in this > document that I think rely on a proper definition/discussion of the concept. > > > > M2.2. The concept of an SRLB is not defined in the Architecture document > either. > > > > > > M3. Still in Section 2, from this text: > > > > * When different SRGBs are used, the outgoing label value is set > > as: [SRGB(next_hop)+index]. If the index can't be applied to > > the SRGB (i.e.: if the index points outside the SRGB of the > > next-hop or the next-hop has not advertised a valid SRGB), then > > no outgoing label value can be computed and the next-hop MUST > > be considered as not supporting the MPLS operations for that > > particular SID. > > > > …several questions/comments… > > > > M3.1. [minor] I hope to see an explanation of the > “[SRGB(next_hop)+index]†notation. > > > > M3.2. What is a “valid SRGBâ€? I don’t think the validity of the SRGB is > described in the Architecture document. > > > > M3.3. I’m assuming that once the “next-hop MUST be considered as not > supporting†then the packets are dropped, right? > > > > M3.4. [Maybe I’m missing something obvious here.] Going back to the > validity of the SRGB advertised by a specific node, shouldn’t the > ingress node verify that before imposing a path that will fail? But I > couldn’t find anything in the Architecture document that talks about the > ingress node verifying that the path is valid (including the validity of > the SRGB). > > > > > > M4. Still in Section 2: “As described in > [I-D.ietf-spring-segment-routing], using the same SRGB on all nodes > within the SR domain eases operations and troubleshooting and is > expected to be a deployment guideline.†As I mentioned in my review of > the Architecture document, that document doesn’t contain deployment > guidelines related to the SRGB, and it doesn’t describe how “using the > same SRGB…eases operations and troubleshootingâ€. > > > > > > > > Minor > > > > P1. The term “service chain†is used in the Abstract. Given that the > concept is not vital to the architecture and that there might be > unnecessary confusion with SFC, I would suggest taking it out. > > > > P2. Informative References to VPN, VPLS, VPWS, LDP, RSVP-TE…would be nice. > > > > P3. Section 2. (MPLS Instantiation of Segment Routing) says that “a > controller-driven network…MAY use the control plane to discover the > available set of local SIDsâ€. The “MAY†implies that there is a choice > (i.e. it is optional) and that other discovery mechanisms exist. What > are those other choices? Note that earlier in this section you already > wrote that IGPs are used for flooding the information. s/MAY/may > > > > P4. Section 2: “…the use of the binding segment as specified in > [I-D.ietf-spring-segment-routing], also allows to substantially reduce > the length of the segment list…†Nice, but there is no description of > the binding segment in draft-ietf-spring-segment-routing. > > > > P5. References. Please take a look at rfc8174 and update the > “Requirements Language†and associated references. > > > > > > > > Nits > > > > N1. I think that the references to *-segment-routing-extensions are > superfluous. BTW, the fourth paragraph of the Introduction uses a > reference to *-segment-routing-extensions to point at ISIS/OSPF (the > protocols!). > > > > N2. It would be very nice if the examples used IPv6 addresses. > From nobody Fri Aug 25 05:43:46 2017 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 24402132BE6; Fri, 25 Aug 2017 05:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 UemBnUPviix2; Fri, 25 Aug 2017 05:43:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E17132027; Fri, 25 Aug 2017 05:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1548; q=dns/txt; s=iport; t=1503665022; x=1504874622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y73OI1sXT9T5ogS1yfSVkYgDTQzE0qbSFUZyoNRz1fQ=; b=CQYzHmtTNqg5XU5tHBGsS0yhBAtFnTJY9+UFt0fh3B24RFesiEqFTKNK FMxltieZkhQAJtEBRvPeXfqsYCsp0SQEP048N1KqLHzPBWyeHyOySkjvr efuKeKaDBWTIZJ1sdp90znB8cYOR0GU6W6nzIbqgDhzRxlk/VOk2P0TiA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAQCRGqBZ/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeQeeJYFPIpg3hUcCGoNGQxQBAgEBAQEBAQFrKIUZAQQBIxF?= =?us-ascii?q?FBQsCAQgSCAImAgICMBUCDgIEAQ0FiikIrUaCJ4thAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYENgh2CAoFOgg4LgnKICDCCMQWYKYg4ApREDJJaljYBNiGBDXcVWwG?= =?us-ascii?q?HCHaJKYEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,425,1498521600"; d="scan'208";a="285095746" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Aug 2017 12:43:41 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7PChfiu013052 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2017 12:43:41 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 25 Aug 2017 07:43:40 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 25 Aug 2017 07:43:40 -0500 From: "Alvaro Retana (aretana)" To: Martin Vigoureux , "draft-ietf-spring-segment-routing-mpls@ietf.org" CC: "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-segment-routing-mpls-10 Thread-Index: AQHTHRnQ0x6IAH5oMUmjFV4q0zWDUKKVFh0A Date: Fri, 25 Aug 2017 12:43:40 +0000 Message-ID: References: <74FB72FC-AD69-4EA3-ACA2-739168EE0A44@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.236.208] Content-Type: text/plain; charset="utf-8" Content-ID: <081D823FCBB32944A0745AC3C6E65276@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 12:43:44 -0000 T24gOC8yNC8xNywgNDo0NCBQTSwgIk1hcnRpbiBWaWdvdXJldXgiIDxtYXJ0aW4udmlnb3VyZXV4 QG5va2lhLmNvbT4gd3JvdGU6DQoNCk1hcnRpbjoNCg0KSGkhDQoNCj4gc3BlYWtpbmcgYXMgU2hl cGhlcmQuDQo+IFJlZ2FyZGluZyBRMSZRMjogSW5kZWVkLCBTZWN0aW9uIDIgaXMgdGhlIGNvcmUg b2YgdGhlIGRvY3VtZW50LCBhbmQgaW4gDQo+IG15IHZpZXcgdGhlIHNlY3Rpb24gY29udGFpbmlu ZyB3aGF0IGlzIHdvcnRoIHN0YW5kYXJkaXppbmcuIA0KDQpXaGF0LCBleGFjdGx5LCBpcyB0aGlz IGRvY3VtZW50IHN0YW5kYXJkaXppbmc/DQoNCkl0IGlzIHByb2JhYmx5IHRvbyBsYXRlIHRvIGFy Z3VlIGFib3V0IG5vdCBoYXZpbmcgYSBzZXBhcmF0ZSBtcGxzLWZvY3VzZWQgZG9jdW1lbnQsIHNv IEnigJltIG5vdCBhcmd1aW5nIGFnYWluc3QgcHVibGljYXRpb24uICBJIGFtIGFsc28gbm90IGNv bmNlcm5lZCBhYm91dCB0aGUgbGVuZ3RoIOKAkyBpdCBpcyBnb29kIHRvIHNlZSBmb2N1c2VkLCBj bGVhciBkb2N1bWVudHMuDQoNCg0K4oCmDQo+IFJlZ2FyZGluZyBRMzogc2luY2UsIGFzIHlvdSBz YXksIHdlIGNhbiBub3Qgc3RhdGUgd2hldGhlciBhIGdpdmVuIHBpZWNlIA0KPiBvZiBJUFIgaXMg dmFsaWQgb3Igbm90LCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgd2UgY2FuIGRpc2N1c3MgdGhlIA0K PiBhcHBsaWNhYmlsaXR5IG9mIElQUiBkaXNjbG9zdXJlcyAobWFkZSBhZ2FpbnN0IG90aGVyIGRv Y3VtZW50cykgdG8gdGhpcyANCj4gZG9jdW1lbnQsIGFuZCB2aWNlIHZlcnNhLg0KDQpSaWdodC4g IFRoYXQgd2FzIGEgcXVlc3Rpb24vb2JzZXJ2YXRpb24gbW9zdGx5IGZvciB0aGUgSVBSIG93bmVy cy4gIEnigJltIGp1c3Qgd29uZGVyaW5nIHdoZXRoZXIgdGhlIGRlY2xhcmF0aW9uIHdhcyBkb25l IGFnYWluc3QgdGhlIHJpZ2h0IGRvY3VtZW50IHNpbmNlIEkgY2Fu4oCZdCByZWFsbHkgdGVsbCB3 aGF0IGlzIG5ldyBhbmQgZGlmZmVyZW50IGhlcmUgdGhhdCB3YXMgbm90IGluIHRoZSBBcmNoaXRl Y3R1cmUgZG9jdW1lbnQuICBJ4oCZbGwgYmUgaGFwcHkgd2l0aCB0aGUgSVBSIGhvbGRlcnMganVz dCB0aGlua2luZyBhYm91dCBpdOKApg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0K From nobody Sat Aug 26 02:41:58 2017 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 82F00132D02; Sat, 26 Aug 2017 02:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 bkkFsojgyw85; Sat, 26 Aug 2017 02:41:54 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5A51321ED; Sat, 26 Aug 2017 02:41:50 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7Q9fmAc021512; Sat, 26 Aug 2017 10:41:48 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7Q9flC0021497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Aug 2017 10:41:47 +0100 Reply-To: From: "Adrian Farrel" To: Cc: , , References: <0faf01d2e07a$72046bd0$560d4370$@olddog.co.uk> In-Reply-To: <0faf01d2e07a$72046bd0$560d4370$@olddog.co.uk> Date: Sat, 26 Aug 2017 10:41:38 +0100 Message-ID: <088101d31e4f$84882180$8d986480$@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: AQJV7Bkei/ZqSZu4tzpmz34tt0M85aGQxZBw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23282.006 X-TM-AS-Result: No--15.634-10.0-31-10 X-imss-scan-details: No--15.634-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkDSw3nP8ewgPKfXIl6Cf6Vrbv16+gil4jfKrGbGSA7+bT8q tc3Zp2f48p796sClznJtZliel/sLZVhrm8WNG8lC5gCHftmwEMK3dp6DuD+6wC62hjZS0WoY+YG jv0sHPzctNRqOBaz1mN6Mgp6awywNsaYKl6IqtEFu4W5gEinK6UDwlkRNC6PCyL0CMroLynVY7a a4/f753MJN1A4Xsa0XZ+YEU9eAbuVR6DT7jy4uvZMSBMTQNiSACAruoteJOhw6lp5/AQWW6oKM0 fljwGtVqVyIJogXqWdfd6LtPrs94+w8rrYji/741N5tiqLHMgspWss5kPUFdH4+AxzmIwY4Q74m Z61P8ps/8uFnLFtcsw0q7qx0Uti5S3NL9oZSa3P87vS8PQu3wDNzwULQwTBPMKZRiezcUtMCgiI aveBs0+LaOPhGKLVRQwmcaF4dD7kLK4dUlqy0pAXysW33GYMp6WNmYQcB5Ex9wRuXoX0dYRdBTl rT3i2i9s6zcm8kfaPfglOsiCnbLU+JxPPMj1PByqVHp2cvsp7cbNJY9S/K70ENV4Lwnu7Bgy7mJ xoEjXnBCNSSwytTaYEUqaUuM6hYJef8M2gKwRDcWo5Vvs8MQhkqnRJng/51/69r3NqBht6MW09z +C2iaENUxDSmLonTlDuDGeAwwU58XbDftE7IsxafLXbshfogQa2sDHLkQ07Z7ve0lygT2I2PN62 7X5nNpFfUrAT4zKDdQCMNC3B2JT6QPiRv82UQ51R1wVM1b2QxXH/dlhvLv2jGtN39AzybS3rCfI MyHrGcRlHlyu49h9a2DjHPVO5iI8jQZDyTiAWeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNevkniXtUAR8IZXruvdBhnLrFOsADI0gjD475t3myRzW78vStd8KKPM= Archived-At: Subject: Re: [spring] [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 09:41:57 -0000 All, I reviewed this draft just over 11 weeks ago, but have not heard = anything back. As I said in my review, I think this document is useful and should be = published. So I am concerned that there is no progress. I hope it isn't = my review that is slowing things down. What are the plans for this document? Thanks, Adrian > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian = Farrel > Sent: 08 June 2017 18:13 > To: rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; spring@ietf.org; = draft-ietf-spring-ipv6-use-cases@ietf.org > Subject: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10 >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. The > Routing Directorate seeks to review all routing or routing-related = drafts as they > pass through IETF last call and IESG review, and sometimes on special = request. > The purpose of the review is to provide assistance to the Routing ADs. = For more > information about the Routing Directorate, please see=20 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, = it would > be helpful if you could consider them along with any other IETF Last = Call > comments that you receive, and strive to resolve them through = discussion or by > updating the draft. >=20 > Apologies that this review comes well after the end of IETF last call, = however, I > have only recently received the request for review. >=20 > Adrian >=20 > =3D=3D=3D=3D >=20 > Document: draft-ietf-spring-ipv6-use-cases-10.txt > Reviewer: Adrian Farrel > Review Date: 8th June 2017 > IETF LC End Date: 4th May 2017 > Intended Status: Informational >=20 > Summary: >=20 > I have some minor concerns about this document that I think should be = resolved > before publication. >=20 > Comments: >=20 > This document supplies primary use cases for SRv6 in a variety of = environments. > While originally intended to help motivate the SR architecture, this = document > now provides a set of use cases that explain how the technology might = be used. >=20 > The document is easy to read and should be published as a helpful = explanation of > how SRv6 could be used. >=20 > =3D=3D=3D=3D >=20 > Major Issues: > None found. >=20 > =3D=3D=3D=3D >=20 > Minor Issues: >=20 > While I think this document is useful and should be published, the > motivation given in the Abstract suggests that the Architecture is > dependent on this draft. That is clearly not the case (since that I-D > has already progressed through IETF last call and only makes = Informative > reference to this document). That shouldn't be an issue of any > significance but probably some rewording is needed, such as... >=20 > The Source Packet Routing in Networking (SPRING) architecture > describes how Segment Routing can be used to steer packets through > an IPv6 or MPLS network using the source routing paradigm. >=20 > This document illustrates some use cases for Segment Routing in an > IPv6 environment. >=20 > --- >=20 > Terminology... >=20 > The document mixes "SPRING" and "spring". I think it should always be > upper case. >=20 > But I also think that the balance between "SPRING" and "Segment = Routing" > may reflect the age of the document. That maybe doesn't need to be > fixed, but the document might align better with other documents if it > was. >=20 > Finally, there is some confusion about what a "segment" is. I think we > previously had this conversation with regard to > draft-ietf-idr-bgp-prefix-sid and concluded that: > A segment represents either a topological instruction such > as "go to prefix P following shortest path" or a service = instruction > (e.g.: "pass through deep packet inspection"). >=20 > A segment is identified through a Segment Identifier (SID). >=20 > --- >=20 > I fully believe in the value of running SR in an IPv6 network, but I > think that some of the motivation provided in the Introduction is > dubious. The text reads... >=20 > In addition there are cases where the operators could have made the > design choice to disable IPv4, for ease of management and scale > (return to single-stack) or due to an address constraint, for = example > because they do not possess enough IPv4 addresses resources to = number > all the endpoints and other network elements on which they desire = to > run MPLS. >=20 > In such scenario the support for MPLS operations on an IPv6-only > network would be required. However today's IPv6-only networks are > not fully capable of supporting MPLS. >=20 > This point does not motivate SRv6 since today's IPv6-only networks are > also not fully capable of supporting SRv6. >=20 > There is ongoing work in the > MPLS Working Group, described in [RFC7439] to identify gaps that = must > be addressed in order to allow MPLS-related protocols and > applications to be used with IPv6-only networks. >=20 > RFC 7439 is now over two years old. Work on filling the gaps = identified > began when draft-mpls-ipv6-only-gap was first published in 2013. In = the > time since then a number of RFCs have been published to fill the gaps > and implementations have been upgraded. >=20 > This is an another > example of scenario where a solution relying on IPv6 without > requiring the use of MPLS could represent a valid option to solve = the > problem and meet operators' requirements. >=20 > My conclusion is that this document is trying to oversell the use of > SR in an IPv6 network where no such sale needs to be made. The result = is > that it appears to disparage MPLS where it should be enough to say = that > a choice can be made, and then lay out the use cases where that choice > is made and explain how the network works when the choice is made. >=20 > I would suggest simply removing these paragraphs with the result of a > stronger statement of use rather than an arguable statement of > motivation. >=20 > --- >=20 > Section 1 >=20 > 3. There is a need or desire to remove routing state from any node > other than the source, such that the source is the only node = that > knows and will know the path a packet will take, a priori >=20 > I think this is a little confused. Obviously, you still have routing > state in the nodes within the network for everything other than > adjacency SIDs. I think that what you are removing from the network is > path state (or control plane signaling state). How about... >=20 > 3. There is a need or desire to remove as much state as possible > from the nodes in the network such that the source is the only > node that knows the path a packet will take through the = network. >=20 > --- >=20 > Section 1 >=20 > I'm not really convinced by the fourth bullet. It's true that IP > addresses can be aggregated so that one advertisement can carry a = prefix > but this also applies to address advertisements that carry MPLS SIDs. > I think you are probably making a point about how an end-to-end SID = can > be routed across a network without the need for a SID stack, but it is = a > bit hard to extract from the text. >=20 > --- >=20 > The start of Section 2 has the same issue as the Abstract. I = suggest... >=20 > OLD >=20 > This section will describe some scenarios where MPLS may not be > present and it will highlight the need for the spring architecture = to > take them into account. >=20 > The use cases described in the section do not constitute an > exhaustive list of all the possible scenarios; this section only > includes some of the most common envisioned deployment models for > IPv6 Segment Routing. In addition to the use cases described in = this > document the spring architecture should be able to be applied to = all > the use cases described in [RFC7855] for the spring MPLS data = plane, > when an IPv6 data plane is present. >=20 > NEW >=20 > This section describes some scenarios where segment routing is > applicable in an IPv6 environment. >=20 > The use cases described in the section do not constitute an > exhaustive list of all the possible scenarios: this section only > includes some of the most common envisioned deployment models for > IPv6 Segment Routing. In addition to the use cases described in = this > document the spring architecture could be able to be applied to all > the use cases described in [RFC7855] for the spring MPLS data = plane, > when an IPv6 data plane is present. >=20 > =3D=3D=3D=3D >=20 > Nits: >=20 > You'll need to expand some abbreviations like QAM and DOCSIS. > You can check = https://www.rfc-editor.org/materials/abbrev.expansion.txt >=20 > --- >=20 > Section 2.3 >=20 > OLD > In such scenario Segment Routing > NEW > In such scenarios, Segment Routing > END >=20 > --- >=20 > OLD > 2.4. SPRING in the Content Delivery Networks > NEW > 2.4. SPRING in Content Delivery Networks > END >=20 > --- >=20 > OLD > 2.5. SPRING in the Core networks > NEW > 2.5. SPRING in Core Networks > END From nobody Sat Aug 26 05:21:40 2017 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 7CCFC1326E8; Sat, 26 Aug 2017 05:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 W5mDdw4m5032; Sat, 26 Aug 2017 05:21:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B9C12EC06; Sat, 26 Aug 2017 05:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=698; q=dns/txt; s=iport; t=1503750092; x=1504959692; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XyNuYUqOiWV7D5clNrqWUmHDqDRkvum9l42ghwoVHIo=; b=QgiSF34LzU2aeXTaOka638bBIHe77rYhnhyHIqbIF9AN/RYwevyyULO1 x3Bpgp0GJbm2L/D5FlY8s1DxeSzEBRmFP3pezkLwehIKwH+xQ6SIXichn F1CplyZp9nb4/2ABijHWTSgvtzlP81dgvuB6grDpIucQUpO295E0Ll8e9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAACeZqFZ/4YNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBeQeODZAXmBeCEoVHAhqDST8YAQIBAQEBAQEBayiFGQYjEUUQAgE?= =?us-ascii?q?IEggCJgICAjAVAg4CBAENBYoxsAyCJ4teAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YENgh2CAoFOgWMrgn2EdYMTMIIxAQSYKog6ApREgXqQbpY8AR84gQ13FVsBhQU?= =?us-ascii?q?cgWd2ihGBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,430,1498521600"; d="scan'208";a="285468293" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Aug 2017 12:21:31 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7QCLVZW009927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 26 Aug 2017 12:21:31 GMT Received: from xch-rtp-002.cisco.com (64.101.220.142) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 08:21:30 -0400 Received: from xch-rtp-002.cisco.com ([64.101.220.142]) by XCH-RTP-002.cisco.com ([64.101.220.142]) with mapi id 15.00.1263.000; Sat, 26 Aug 2017 08:21:30 -0400 From: "Alvaro Retana (aretana)" To: "adrian@olddog.co.uk" , "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-ipv6-use-cases@ietf.org" Thread-Topic: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10 Thread-Index: AQJV7Bkei/ZqSZu4tzpmz34tt0M85aGQxZBwgAAt7wA= Date: Sat, 26 Aug 2017 12:21:30 +0000 Message-ID: <2594C482-18AB-4FE7-B602-9C7315CAFC2C@cisco.com> References: <0faf01d2e07a$72046bd0$560d4370$@olddog.co.uk> <088101d31e4f$84882180$8d986480$@olddog.co.uk> In-Reply-To: <088101d31e4f$84882180$8d986480$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.236.208] Content-Type: text/plain; charset="utf-8" Content-ID: <3F789A30AFD7214280BCD3529F2D791F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 12:21:34 -0000 QWRyaWFuOg0KDQpObywgaXQgaXNu4oCZdCB5b3VyIHJldmlldy4NCg0KV2XigJlyZSBmb3J3YXJk aW5nIHRoZSB1c2UgY2FzZSBkb2N1bWVudHMgYWxvbmcgd2l0aCB0aGUgQXJjaGl0ZWN0dXJlIHRv IHRoZSBJRVNHIGF0IHRoZSBzYW1lIHRpbWUg4oCTIHdl4oCZcmUgd2FpdGluZyBmb3IgdGhhdCBs YXN0IGRvY3VtZW50Lg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KT24gOC8yNi8xNywgNTo0MiBB TSwgIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiB3cm90ZToNCg0KQXMgSSBz YWlkIGluIG15IHJldmlldywgSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHVzZWZ1bCBhbmQgc2hv dWxkIGJlIHB1Ymxpc2hlZC4gU28gSSBhbSBjb25jZXJuZWQgdGhhdCB0aGVyZSBpcyBubyBwcm9n cmVzcy4gSSBob3BlIGl0IGlzbid0IG15IHJldmlldyB0aGF0IGlzIHNsb3dpbmcgdGhpbmdzIGRv d24uDQoNCldoYXQgYXJlIHRoZSBwbGFucyBmb3IgdGhpcyBkb2N1bWVudD8NCg0KDQoNCg== From nobody Sat Aug 26 10:09:27 2017 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 03D2F132A97; Sat, 26 Aug 2017 10:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GwZnAEIUoFYa; Sat, 26 Aug 2017 10:09:17 -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 EAF1A132A69; Sat, 26 Aug 2017 10:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9856; q=dns/txt; s=iport; t=1503767357; x=1504976957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1XlJWpXIO56GEYxIXA3Feqnl7TjdZJ2jn0wTJY9KrKA=; b=VrqmtSclu1hNfmq/S0f+i8UFYYZ+RyCAscUgG31bPUS3UiCzJzYWqh+t BpljvDchdUed4pDfLmQ0oF9IGDlbP1+1gOZTzNrOahCTSlZteqR84I/yw EQEtYrRmKbbnS34DyRpqY3HeIBS4YHaWXtxb5EUZUy1LSMWwEBWjIgdxU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAAAqqFZ/5pdJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMtLWSBFY4UkBeBcZYmDoIELIUbAoNjPxgBAgEBAQEBAQFrHQu?= =?us-ascii?q?FGAEBAQECAQ4sKxQFBwQCAQgRAQIBAQEWCQkHMhQDBggBAQQOBRuKDggQskiLW?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKoICgzErgn2EMBoeDT+DBIIxBaBkAod?= =?us-ascii?q?Ug1aJGoISWoUMg32Gc5Y8AR84gQ13FUkSAYUFHIFndgEBiF+CPwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,431,1498521600"; d="scan'208";a="285828051" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Aug 2017 17:09:15 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7QH9Fgd019495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 26 Aug 2017 17:09:15 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 12:09:14 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1263.000; Sat, 26 Aug 2017 12:09:14 -0500 From: "Roberta Maglione (robmgl)" To: "adrian@olddog.co.uk" CC: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-ipv6-use-cases@ietf.org" Thread-Topic: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10 Thread-Index: AdLgele/v5PbrueZT72LZpEyNayhtw9/xSAAAAUnvws= Date: Sat, 26 Aug 2017 17:09:14 +0000 Message-ID: <1BDB0E47-C99F-4D57-A303-F99418A4A108@cisco.com> References: <0faf01d2e07a$72046bd0$560d4370$@olddog.co.uk>, <088101d31e4f$84882180$8d986480$@olddog.co.uk> In-Reply-To: <088101d31e4f$84882180$8d986480$@olddog.co.uk> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 17:09:20 -0000 Hello Adrian Your comments were addressed and integrated in version-11 published on June= 13 Please let us know if you have additional comments or if you find anything = missing=20 Thanks=20 Roberta Inviato da iPhone > Il giorno 26 ago 2017, alle ore 02:42, Adrian Farrel ha scritto: >=20 > All, >=20 > I reviewed this draft just over 11 weeks ago, but have not heard anything= back. >=20 > As I said in my review, I think this document is useful and should be pub= lished. So I am concerned that there is no progress. I hope it isn't my rev= iew that is slowing things down. >=20 > What are the plans for this document? >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farr= el >> Sent: 08 June 2017 18:13 >> To: rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; spring@ietf.org; draft-ietf-spring-ipv6-use-cases@= ietf.org >> Subject: [RTG-DIR] RtgDir Review draft-ietf-spring-ipv6-use-cases-10 >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this draft.= The >> Routing Directorate seeks to review all routing or routing-related draft= s as they >> pass through IETF last call and IESG review, and sometimes on special re= quest. >> The purpose of the review is to provide assistance to the Routing ADs. F= or more >> information about the Routing Directorate, please see=20 >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>=20 >> Although these comments are primarily for the use of the Routing ADs, it= would >> be helpful if you could consider them along with any other IETF Last Cal= l >> comments that you receive, and strive to resolve them through discussion= or by >> updating the draft. >>=20 >> Apologies that this review comes well after the end of IETF last call, h= owever, I >> have only recently received the request for review. >>=20 >> Adrian >>=20 >> =3D=3D=3D=3D >>=20 >> Document: draft-ietf-spring-ipv6-use-cases-10.txt >> Reviewer: Adrian Farrel >> Review Date: 8th June 2017 >> IETF LC End Date: 4th May 2017 >> Intended Status: Informational >>=20 >> Summary: >>=20 >> I have some minor concerns about this document that I think should be re= solved >> before publication. >>=20 >> Comments: >>=20 >> This document supplies primary use cases for SRv6 in a variety of enviro= nments. >> While originally intended to help motivate the SR architecture, this doc= ument >> now provides a set of use cases that explain how the technology might be= used. >>=20 >> The document is easy to read and should be published as a helpful explan= ation of >> how SRv6 could be used. >>=20 >> =3D=3D=3D=3D >>=20 >> Major Issues: >> None found. >>=20 >> =3D=3D=3D=3D >>=20 >> Minor Issues: >>=20 >> While I think this document is useful and should be published, the >> motivation given in the Abstract suggests that the Architecture is >> dependent on this draft. That is clearly not the case (since that I-D >> has already progressed through IETF last call and only makes Informative >> reference to this document). That shouldn't be an issue of any >> significance but probably some rewording is needed, such as... >>=20 >> The Source Packet Routing in Networking (SPRING) architecture >> describes how Segment Routing can be used to steer packets through >> an IPv6 or MPLS network using the source routing paradigm. >>=20 >> This document illustrates some use cases for Segment Routing in an >> IPv6 environment. >>=20 >> --- >>=20 >> Terminology... >>=20 >> The document mixes "SPRING" and "spring". I think it should always be >> upper case. >>=20 >> But I also think that the balance between "SPRING" and "Segment Routing" >> may reflect the age of the document. That maybe doesn't need to be >> fixed, but the document might align better with other documents if it >> was. >>=20 >> Finally, there is some confusion about what a "segment" is. I think we >> previously had this conversation with regard to >> draft-ietf-idr-bgp-prefix-sid and concluded that: >> A segment represents either a topological instruction such >> as "go to prefix P following shortest path" or a service instruction >> (e.g.: "pass through deep packet inspection"). >>=20 >> A segment is identified through a Segment Identifier (SID). >>=20 >> --- >>=20 >> I fully believe in the value of running SR in an IPv6 network, but I >> think that some of the motivation provided in the Introduction is >> dubious. The text reads... >>=20 >> In addition there are cases where the operators could have made the >> design choice to disable IPv4, for ease of management and scale >> (return to single-stack) or due to an address constraint, for example >> because they do not possess enough IPv4 addresses resources to number >> all the endpoints and other network elements on which they desire to >> run MPLS. >>=20 >> In such scenario the support for MPLS operations on an IPv6-only >> network would be required. However today's IPv6-only networks are >> not fully capable of supporting MPLS. >>=20 >> This point does not motivate SRv6 since today's IPv6-only networks are >> also not fully capable of supporting SRv6. >>=20 >> There is ongoing work in the >> MPLS Working Group, described in [RFC7439] to identify gaps that must >> be addressed in order to allow MPLS-related protocols and >> applications to be used with IPv6-only networks. >>=20 >> RFC 7439 is now over two years old. Work on filling the gaps identified >> began when draft-mpls-ipv6-only-gap was first published in 2013. In the >> time since then a number of RFCs have been published to fill the gaps >> and implementations have been upgraded. >>=20 >> This is an another >> example of scenario where a solution relying on IPv6 without >> requiring the use of MPLS could represent a valid option to solve the >> problem and meet operators' requirements. >>=20 >> My conclusion is that this document is trying to oversell the use of >> SR in an IPv6 network where no such sale needs to be made. The result is >> that it appears to disparage MPLS where it should be enough to say that >> a choice can be made, and then lay out the use cases where that choice >> is made and explain how the network works when the choice is made. >>=20 >> I would suggest simply removing these paragraphs with the result of a >> stronger statement of use rather than an arguable statement of >> motivation. >>=20 >> --- >>=20 >> Section 1 >>=20 >> 3. There is a need or desire to remove routing state from any node >> other than the source, such that the source is the only node that >> knows and will know the path a packet will take, a priori >>=20 >> I think this is a little confused. Obviously, you still have routing >> state in the nodes within the network for everything other than >> adjacency SIDs. I think that what you are removing from the network is >> path state (or control plane signaling state). How about... >>=20 >> 3. There is a need or desire to remove as much state as possible >> from the nodes in the network such that the source is the only >> node that knows the path a packet will take through the network. >>=20 >> --- >>=20 >> Section 1 >>=20 >> I'm not really convinced by the fourth bullet. It's true that IP >> addresses can be aggregated so that one advertisement can carry a prefix >> but this also applies to address advertisements that carry MPLS SIDs. >> I think you are probably making a point about how an end-to-end SID can >> be routed across a network without the need for a SID stack, but it is a >> bit hard to extract from the text. >>=20 >> --- >>=20 >> The start of Section 2 has the same issue as the Abstract. I suggest... >>=20 >> OLD >>=20 >> This section will describe some scenarios where MPLS may not be >> present and it will highlight the need for the spring architecture to >> take them into account. >>=20 >> The use cases described in the section do not constitute an >> exhaustive list of all the possible scenarios; this section only >> includes some of the most common envisioned deployment models for >> IPv6 Segment Routing. In addition to the use cases described in this >> document the spring architecture should be able to be applied to all >> the use cases described in [RFC7855] for the spring MPLS data plane, >> when an IPv6 data plane is present. >>=20 >> NEW >>=20 >> This section describes some scenarios where segment routing is >> applicable in an IPv6 environment. >>=20 >> The use cases described in the section do not constitute an >> exhaustive list of all the possible scenarios: this section only >> includes some of the most common envisioned deployment models for >> IPv6 Segment Routing. In addition to the use cases described in this >> document the spring architecture could be able to be applied to all >> the use cases described in [RFC7855] for the spring MPLS data plane, >> when an IPv6 data plane is present. >>=20 >> =3D=3D=3D=3D >>=20 >> Nits: >>=20 >> You'll need to expand some abbreviations like QAM and DOCSIS. >> You can check https://www.rfc-editor.org/materials/abbrev.expansion.txt >>=20 >> --- >>=20 >> Section 2.3 >>=20 >> OLD >> In such scenario Segment Routing >> NEW >> In such scenarios, Segment Routing >> END >>=20 >> --- >>=20 >> OLD >> 2.4. SPRING in the Content Delivery Networks >> NEW >> 2.4. SPRING in Content Delivery Networks >> END >>=20 >> --- >>=20 >> OLD >> 2.5. SPRING in the Core networks >> NEW >> 2.5. SPRING in Core Networks >> END >=20 From nobody Mon Aug 28 07:52:55 2017 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 EA9A3132A05; Mon, 28 Aug 2017 07:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 cQEeU3LJDJKx; Mon, 28 Aug 2017 07:52:48 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 4302E1328DB; Mon, 28 Aug 2017 07:52:48 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 83so2086185pgb.4; Mon, 28 Aug 2017 07:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:reply-to:user-agent:mime-version :content-transfer-encoding; bh=BsJjef1mq8dgnO7GnQykG/WlPLsoWLsy0RYnIj+5WcE=; b=e92b4Lp7m3Df9SvpMcmLXqAKqL3pYPRZuXssv4LV/+GS7NCU/P6C3EGPUwFiRt5pqs zhcbH7sYBNR0ShtYx8HAAx5ray8rJHFnPqjTYaDx5WXvNkLoQJUJ37HlGqHKk1S2tAg1 U44uMMpU02rkTe4BhJFbvtEmxLJEcJ/V6++UgIKi2k9hgr1AaOgE2ZlFDLLn3ZYRTg5m RGHCdFm6ZoRFFi46s8tgFSMcmdhcD5UukYqQuRzz6JIeOIiUvFUpnM9UeCvkCoGzDFlU Ps2oIVyAW7MWK8XZPPHzXAWsiYyBP2X0n+ukOmAc46cLGPb+5Ew5nj7/CblBSuC/UKsu hKPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:reply-to :user-agent:mime-version:content-transfer-encoding; bh=BsJjef1mq8dgnO7GnQykG/WlPLsoWLsy0RYnIj+5WcE=; b=fG5GxNI5SyedEbIcBzEC5YnuPjYWYGAmnmHm+xYlTJvYbe6pOZEF6ELGYaivglcX9u fu2xp3JkPu29Sq/JQwYBjWoyBX6YMlnZ25argjODlf29+BFTo6Crn99c2f963OW+LBi8 HxSQwEJhgwKIzbrHtuA3upUjAhthdPYuiYCDM6sEGBRcz59PQUrP/1BM2/puXE0BMlsd 4G41tP2Hajq5myE/R62dQXiD2KPMSaNU04ldl50DNzBxVulfQuC8HQXug7idpsExKRKH raYZgorlGxrWEjqWbzRbO4QyDlWbuO0D+UKzuI6UBZWy27dwnn0+mDtafBygNJzmZBgM 8BmQ== X-Gm-Message-State: AHYfb5g3n8Gz7QxAElaFaVP+pd+HhhP03Len/u/nGV5dT6nB9/Xm7EjY ze42xVDFV0GdKIQKWMw= X-Received: by 10.98.10.202 with SMTP id 71mr864068pfk.176.1503931967549; Mon, 28 Aug 2017 07:52:47 -0700 (PDT) Received: from [192.168.10.7] (122x210x140x66.ap122.ftth.ucom.ne.jp. [122.210.140.66]) by smtp.gmail.com with ESMTPSA id 74sm1098351pfo.74.2017.08.28.07.52.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 07:52:46 -0700 (PDT) From: "Kentaro Ebisawa" To: dmm@ietf.org, spring@ietf.org Cc: "Matsushima Satoru" Date: Mon, 28 Aug 2017 14:52:44 +0000 Message-Id: Reply-To: "Kentaro Ebisawa" User-Agent: eM_Client/7.1.30646.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [spring] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 14:52:50 -0000 Hi, I have a few questions about how Encoded SID should be placed in Segment=20 List and IPv6 Dst Address in Mobile User-Plane use case. # Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01. # I tried to check Slides from IETF 99 but link seems to be missing. #=20 https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobile-user-plane/ Q1) Up Link packet (existing network to SRv6) > outer IPv4 and tunnel header. And then the endpoint does T.Insert > process with the SID which consists of the allocated domain-wise SID > prefix, source and destination addresses, and tunnel identifier as > described in Figure 3. Then the endpoint send out the packet to the > SRv6 network along with its routing policy. How would IPv6 src/dst addr and Segment List look like for this Up Link=20 packet? (existing network to SRv6) My understanding is usually source address of the T.Insert node is not=20 included in Segment List. But from above description, it looks like you intend to require Encoded=20 SID (Fig 3) to be included in the Segment List of UL packet. For example, is below packet structure what you intended in case you=20 have n segments to traverse in SRv6 nework? IPv6 Src: Encoded SID or T.Insert node ?? IPv6 Dst: SL[n] Segment Left =3D n SL[0] =3D Segment 0 SL[n] =3D Segment n SL[n+1] =3D Encoded SID Q2) Down Link packet (SRv6 to existing network) > When the endpoint receives packet and the active segment of the > packet indicates the SID, the endpoint pop the SRH of the SID, and On the other hand, are there any reason that description in page 7 does=20 not mandate m to be zero while requiring to pop the SRH? My understanding of DL packet (SRv6 to existing network) is as below. IPv6 Src: Origin Host IPv6 Dst: SL[n] Segment Left =3D n SL[m] =3D Encoded SID SL[m+1] =3D Segment m+1 SL[n] =3D Segment n Regards, -- Ponto Networks, Inc. Kentaro Ebisawa From nobody Mon Aug 28 08:44:20 2017 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 1C6A51321B6; Mon, 28 Aug 2017 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 JW31n8GsQp_G; Mon, 28 Aug 2017 08:44:10 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 F039E126C7A; Mon, 28 Aug 2017 08:44:09 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id r133so2509075pgr.3; Mon, 28 Aug 2017 08:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=DzPt2i7klPth5n/zwfYD4/OXSjm4NaDrbGGaFuVC+L8=; b=gFBkw7xnnQ9ibtaa+JuPkrKevyzYG8ISE/V9i9HAwPoMH09hUm4ZVW0BrtayE0hSms NhV/QnFEpOgrBWR81zI4daE/kMseWRbXTqIBHUhjP6tQEyPobC99JihALjbDUnqumTlE Hv30FQ/K6FhUnAP8+Gbrh6xOTBw/KRMHNQIf6N1aBThBXUuTLL0Y4anD2b2jz1b7eRAl GGAtoD7IFEweO8gqxvKgwkWcH+Uj7lt2Gz6yUF1U7yxN52kp0yu1f/WMaCE+KIAVlOAM JoUtnM+ImupCe7kTAf3DCqSVJRV8LaCNIgGrNzlRuf7DL9bKkH6c/MxMhoRfpJmOo5dO mQ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=DzPt2i7klPth5n/zwfYD4/OXSjm4NaDrbGGaFuVC+L8=; b=OIymXKX6n+UzRCDlGb4y1Mc1u/A4EveRWqy1SCswBQIoKmBYHRCqMu7v0EzYFc7Atb 3+jNH8vQw+6FYCa8PZ8T9SqWiPWcSKNw69KwksJ1G4XM2L5EyuM0a67BduKKT7zfcR/4 GDbYFxUYvxzv1zcyzglRzLEkdDJHCWRRPdej7rLoWBWEYpDlbPa3/vqivWKyoM++yf5o t877kRbd8HulSLGqF+TIcyCrEsMKutUmm8wdHAKiGU7n2pIdQMVL6bGPWPEKsfxy5Icn Tjs+9f27jCZwl8JRMqHTEJapK2SzpZPObp8auvbfTxmpIEe5TXrygt1ZO0TLZg/eCua1 yPbQ== X-Gm-Message-State: AHYfb5jCGhiziQ9wka92SBme9BbXgJUlDu21cGjvDwV7rx+JizrKj/hL xMWVsEt6B9ffOOGUZtU= X-Received: by 10.84.231.15 with SMTP id f15mr1302084plk.334.1503935048871; Mon, 28 Aug 2017 08:44:08 -0700 (PDT) Received: from [192.168.10.7] (122x210x140x66.ap122.ftth.ucom.ne.jp. [122.210.140.66]) by smtp.gmail.com with ESMTPSA id t10sm1306552pgr.54.2017.08.28.08.44.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 08:44:07 -0700 (PDT) From: "Kentaro Ebisawa" To: dmm@ietf.org, spring@ietf.org Cc: "Matsushima Satoru" Date: Mon, 28 Aug 2017 15:44:05 +0000 Message-Id: In-Reply-To: References: Reply-To: "Kentaro Ebisawa" User-Agent: eM_Client/7.1.30646.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 15:44:12 -0000 Hi, > Q2) Down Link packet (SRv6 to existing network) > > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, and > ... > > IPv6 Src: Origin Host > IPv6 Dst: SL[n] > Segment Left =3D n > SL[m] =3D Encoded SID > SL[m+1] =3D Segment m+1 > SL[n] =3D Segment n Actually I think this differs for T.Insert case, where MN user packet is=20 IPv6. # Unless I missed description that Stateless Interworking will always=20 use encapsulation mode even if user packet is IPv6. IPv6 Src: Origin Host IPv6 Dst: SL[n] Segment Left =3D n SL[0] =3D MN address SL[1] =3D Encoded SID SL[n] =3D Segment n And interworking segment should behave like below. When the endpoint receives packet and the active segment of the packet indicates the SID, the endpoint pop the SRH of the SID, >> Set IPv6 destination address as SL[0] (MN's address), and then the endpoint encaps the payload with the encoded information in the SID which are tunnel identifier of tunnel header, source and destination IPv4 address of IPv4 header described in Figure 3. Maybe having example packet headers described for each cases=20 (encap/insert, User Packet =3D IPv4/IPv6) will help this makes more easier= =20 to understand. Thanks, -- Ponto Networks, Inc. Kentaro Ebisawa ------ Original Message ------ From: "Kentaro Ebisawa" To: dmm@ietf.org; spring@ietf.org Cc: "Matsushima Satoru" Sent: 2017/08/28 23:52:44 Subject: How Encoded SID should be placed in SL (SRv6-mobile-uplane) >Hi, > >I have a few questions about how Encoded SID should be placed in=20 >Segment List and IPv6 Dst Address in Mobile User-Plane use case. > ># Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01. ># I tried to check Slides from IETF 99 but link seems to be missing. >#=20 >https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobile-user-plane/ > > >Q1) Up Link packet (existing network to SRv6) > > > outer IPv4 and tunnel header. And then the endpoint does T.Insert > > process with the SID which consists of the allocated domain-wise SID > > prefix, source and destination addresses, and tunnel identifier as > > described in Figure 3. Then the endpoint send out the packet to the > > SRv6 network along with its routing policy. > >How would IPv6 src/dst addr and Segment List look like for this Up Link=20 >packet? (existing network to SRv6) >My understanding is usually source address of the T.Insert node is not=20 >included in Segment List. >But from above description, it looks like you intend to require Encoded=20 >SID (Fig 3) to be included in the Segment List of UL packet. > >For example, is below packet structure what you intended in case you=20 >have n segments to traverse in SRv6 nework? > >IPv6 Src: Encoded SID or T.Insert node ?? >IPv6 Dst: SL[n] >Segment Left =3D n >SL[0] =3D Segment 0 >SL[n] =3D Segment n >SL[n+1] =3D Encoded SID > > >Q2) Down Link packet (SRv6 to existing network) > > > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, and > >On the other hand, are there any reason that description in page 7 does=20 >not mandate m to be zero while requiring to pop the SRH? >My understanding of DL packet (SRv6 to existing network) is as below. > >IPv6 Src: Origin Host >IPv6 Dst: SL[n] >Segment Left =3D n >SL[m] =3D Encoded SID >SL[m+1] =3D Segment m+1 >SL[n] =3D Segment n > > >Regards, >-- >Ponto Networks, Inc. >Kentaro Ebisawa From nobody Mon Aug 28 18:24:59 2017 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 12AB11321A4; Mon, 28 Aug 2017 18:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kMgxXlqgjzLz; Mon, 28 Aug 2017 18:24:54 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95765126BF3; Mon, 28 Aug 2017 18:24:54 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id l132so5910400vke.5; Mon, 28 Aug 2017 18:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n65bbUHylp9kNvCJm0Jp5hnScyCFHtfvemxSKmZblzs=; b=uW733BZcfBVi9yBPfR/goFrRLuIk+Y2Alg9RU4ojnodp0FT9H9l8hTgOnD8SMAtcC4 JRgAYuZOgNCnMOax9Ofny+IAiEdsSm1WHPyf9yKCrHhm8Am+mWl8SMmHYZY831C9q8DG zTS1fv0V0s6z3c3TyeziJuZiVdFZUF90V22CRCcQnnyDGTGWbZeSyCIXhufjp4hbVi8t 5qAELfRdgXrC/YVY6CG/oxCYDNO7nyhzbLefEuyckV8JqPOh4J/yunlxTDhqtqFoZpHc v5+yQrwVC1njagqj9uLYrPQt7MQ9lF0dzBqVVdpOjlpEVAN3tMTU/fNW9Dp2hA1iF41s dXyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n65bbUHylp9kNvCJm0Jp5hnScyCFHtfvemxSKmZblzs=; b=ZOgajTZMxv1R+U1F40lV0IiqqcCQYWExpt9DAhNBU1jf982d1x85YiY0oALlNxjdPI /9VfRm4VhXcy6amPtkgMF/6JM0RtKsG6X31wClIwprxW3txIJcvsPj5FKucyOD6ShGgz zEGJIX0rrF1RbzQtpc4V2g/UwkHB8Qjt+mmUk1CZP3znZorWsby9HBW/Q1rhDmTZP5SV gWrpG5xdq2Wu1xHdDTkD4AnOFUE0aWs/qJ/ximcYekQhBRtxfHlmOfjFVaHTB11Bk8P1 pegB5CUDiyo6NYGmww6sCGRNbigH+/j4u1D3+nvRl4zZ/AawZN1VjiFSqJz2GJYHmOG2 FGVg== X-Gm-Message-State: AHYfb5ixkA0c1l3qn/+tIuevn7qjhgpWe3xk0vkYp8qsBRmSY3U2Zan2 cXGzA1c2CjhzeFTN8lsDW+AUthD50f6U X-Received: by 10.31.62.8 with SMTP id l8mr1646279vka.185.1503969893617; Mon, 28 Aug 2017 18:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.25 with HTTP; Mon, 28 Aug 2017 18:24:53 -0700 (PDT) In-Reply-To: References: From: Satoru Matsushima Date: Tue, 29 Aug 2017 10:24:53 +0900 Message-ID: To: Kentaro Ebisawa Cc: dmm , spring@ietf.org, Matsushima Satoru Content-Type: multipart/alternative; boundary="001a1144776e4316c70557da47ee" Archived-At: Subject: Re: [spring] [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 01:24:58 -0000 --001a1144776e4316c70557da47ee Content-Type: text/plain; charset="UTF-8" Hi Kentaro, On Mon, Aug 28, 2017 at 11:52 PM, Kentaro Ebisawa wrote: > Hi, > > I have a few questions about how Encoded SID should be placed in Segment > List and IPv6 Dst Address in Mobile User-Plane use case. > > # Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01. > # I tried to check Slides from IETF 99 but link seems to be missing. > # https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobi > le-user-plane/ That looks weird. It's not only for that document. All ietf99 meeting materials are mis-linked from " https://datatracker.ietf.org/meeting/99/agenda" page. > > Q1) Up Link packet (existing network to SRv6) > > > outer IPv4 and tunnel header. And then the endpoint does T.Insert > > process with the SID which consists of the allocated domain-wise SID > > prefix, source and destination addresses, and tunnel identifier as > > described in Figure 3. Then the endpoint send out the packet to the > > SRv6 network along with its routing policy. > In above text, we assumed that the payload encapsulated in the IPv4 tunnel is an IPv6 packet. So the source address of the packet should be an MN's address. > How would IPv6 src/dst addr and Segment List look like for this Up Link > packet? (existing network to SRv6) > My understanding is usually source address of the T.Insert node is not > included in Segment List. > But from above description, it looks like you intend to require Encoded > SID (Fig 3) to be included in the Segment List of UL packet. > > For example, is below packet structure what you intended in case you have > n segments to traverse in SRv6 nework? > > IPv6 Src: Encoded SID or T.Insert node ?? > IPv6 Dst: SL[n] > Segment Left = n > SL[0] = Segment 0 > SL[n] = Segment n > SL[n+1] = Encoded SID > > SL[0] must be original destination address of the IPv6 packet which the MN sends out. The SID which consists of the existing network tunnel info would be placed at SL[1]. In case of that it means that the endpoint which the SID indicates is egress of the SRv6 domain. If any other endpoints exist in the segment list, that SID would be placed at SL[n] where n >=2. > Q2) Down Link packet (SRv6 to existing network) > > > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, and > > On the other hand, are there any reason that description in page 7 does > not mandate m to be zero while requiring to pop the SRH? > As similar with UL, SL[0] must be original destination address. In DL direction the interworking node must be egress of the SRv6 domain so that the tunnel info encoded SID should be placed in SL[1]. Best regards, --satoru > My understanding of DL packet (SRv6 to existing network) is as below. > > IPv6 Src: Origin Host > IPv6 Dst: SL[n] > Segment Left = n > SL[m] = Encoded SID > SL[m+1] = Segment m+1 > SL[n] = Segment n > > > Regards, > -- > Ponto Networks, Inc. > Kentaro Ebisawa > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --001a1144776e4316c70557da47ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kentaro,


On Mon, Aug 28, 2017 at 11:52 PM, Kent= aro Ebisawa <ebiken.g@gmail.com> wrote:
Hi,

I have a few questions about how Encoded SID should be placed in Segment Li= st and IPv6 Dst Address in Mobile User-Plane use case.

# Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01.
# I tried to check Slides from IETF 99 but link seems to be missing.
# https://datatracker.ietf= .org/doc/slides-99-dmm-srv6-for-mobile-user-plane/

That looks weird. It's not only for that document= .=C2=A0
All ietf99 meeting materials are mis-linked from "https://datatracke= r.ietf.org/meeting/99/agenda" page.

=C2= =A0

Q1) Up Link packet (existing network to SRv6)

> outer IPv4 and tunnel header. And then the endpoint does T.Insert
> process with the SID which consists of the allocated domain-wise SID > prefix, source and destination addresses, and tunnel identifier as
> described in Figure 3. Then the endpoint send out the packet to the > SRv6 network along with its routing policy.

<= /div>

In above text, we assumed that the payload encapsu= lated in the IPv4 tunnel is an IPv6 packet.
So the source address= of the packet should be an MN's address.


How would IPv6 src/dst addr and Segment List look like for this Up Link pac= ket? (existing network to SRv6)
My understanding is usually source address of the T.Insert node is not incl= uded in Segment List.
But from above description, it looks like you intend to require Encoded SID= (Fig 3) to be included in the Segment List of UL packet.

For example, is below packet structure what you intended in case you have n= segments to traverse in SRv6 nework?

IPv6 Src: Encoded SID or T.Insert node ??
IPv6 Dst: SL[n]
Segment Left =3D n
SL[0] =3D Segment 0
SL[n] =3D Segment n
SL[n+1] =3D Encoded SID


SL[0] must be original destination add= ress of the IPv6 packet which the MN sends out.
The SID which con= sists of the existing network tunnel info would be placed at SL[1]. In case= of that it means that the endpoint which the SID indicates is egress of th= e SRv6 domain. If any other endpoints exist in the segment list, that SID w= ould be placed at SL[n] where n >=3D2.



Q2) Down Link packet (SRv6 to existing network)

> When the endpoint receives packet and the active segment of the
> packet indicates the SID, the endpoint pop the SRH of the SID, and

On the other hand, are there any reason that description in page 7 does not= mandate m to be zero while requiring to pop the SRH?
=
As similar with UL, SL[0] must be original destination addre= ss. In DL direction the interworking node must be egress of the SRv6 domain= so that the tunnel info encoded SID should be placed in SL[1].
<= br>
Best regards,
--satoru

=C2= =A0
My understanding of DL packet (SRv6 to existing network) is as below.

IPv6 Src: Origin Host
IPv6 Dst: SL[n]
Segment Left =3D n
SL[m] =3D Encoded SID
SL[m+1] =3D Segment m+1
SL[n] =3D Segment n


Regards,
--
Ponto Networks, Inc.
Kentaro Ebisawa <ebiken.g@gmail.com>

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

--001a1144776e4316c70557da47ee-- From nobody Mon Aug 28 18:44:21 2017 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 5E5BD1321AC; Mon, 28 Aug 2017 18:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6_fzWVIv0Vr; Mon, 28 Aug 2017 18:44:18 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 7E927126BF3; Mon, 28 Aug 2017 18:44:18 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id j7so6053243vke.0; Mon, 28 Aug 2017 18:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QPvl7t2PKxZC8sNgCCR9laPcvOZATm/OXUWAv35NRZU=; b=uCgk7lhh1FFj9GTulKDOzT4C7AY3UwEp7bdZzsHm+PbNDgUaqP0ayPwuzACT9YSltx PWLt04yI9FOJy89ZiHtq0NlNs3HaIwx+XQHM0rflwfcrU1NwhYICoVjgIhx+t/CDupk8 XJXl1M9aMDkaGzqgsR1Jf8IUZdEbRqI7lJHRFrEZuJiGK+uEflnJh/Qn13cr0uCUm6id C/+HRra3OwLaRxXSCxGMuiWZFMeY4Sh/6htxogd+RF9VBkmY9ho8lMEX4zBhckfnPbFm RtOSJEr98LwEIH1yp2QgaidGCL79r1Wjaf1i2bazSLTjUWtdQa2YZZ+3YgM4d7yW4jmx gGqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QPvl7t2PKxZC8sNgCCR9laPcvOZATm/OXUWAv35NRZU=; b=rhJyk1zcCFzM6xiYi+B+8TQkznNuTuB5HQ+InoF7+NnIohXMG4z89fRMDmtpUx/qm9 JDPhDCC6O6+ac1A8Qq9pus3U2ZD2YRi3ZmeedCp2hvUzF4iw+VqyFT7o0HA1gS5Y1IYJ Zl3c4EoBU2CnTbBYr+Gb+JHWG15mKb56eOvCfqFzdGoGW+yMd5UUyZ7KA2dopnJ0cfjL 8SrN1I2hBjqAZwQkDiM+j4eaGv3IdVIAdxJ6CQiaQ6kG2zjopn7iAuzdT5D7YlX+STHf Hg7W1VGdYjFCjV8tDGK/4FXoD+Bmvc5F9IpkLTGCAzmJUQ9WtvAltKHLvbP6bOy2FwwQ drcw== X-Gm-Message-State: AHYfb5h8dAECQGM07ZPR/REo5ZDz42QAVs8xVzSGDhZqWGH7/CeRaPJ0 6gD54oTy3hpxmWCBMWKTqeDK852K1Q== X-Received: by 10.31.108.215 with SMTP id j84mr1547083vki.7.1503971057549; Mon, 28 Aug 2017 18:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.25 with HTTP; Mon, 28 Aug 2017 18:44:16 -0700 (PDT) In-Reply-To: References: From: Satoru Matsushima Date: Tue, 29 Aug 2017 10:44:16 +0900 Message-ID: To: Kentaro Ebisawa Cc: dmm , spring@ietf.org, Matsushima Satoru Content-Type: multipart/alternative; boundary="001a1147a148a347c40557da8ce8" Archived-At: Subject: Re: [spring] [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 01:44:20 -0000 --001a1147a148a347c40557da8ce8 Content-Type: text/plain; charset="UTF-8" Hi Kentaro, I've replied to your previous mail that I hope it would answer to your questions. On Tue, Aug 29, 2017 at 12:44 AM, Kentaro Ebisawa wrote: > Hi, > > > Q2) Down Link packet (SRv6 to existing network) > > > When the endpoint receives packet and the active segment of the > > > packet indicates the SID, the endpoint pop the SRH of the SID, and > > ... > > > > IPv6 Src: Origin Host > > IPv6 Dst: SL[n] > > Segment Left = n > > SL[m] = Encoded SID > > SL[m+1] = Segment m+1 > > SL[n] = Segment n > > Actually I think this differs for T.Insert case, where MN user packet is > IPv6. > # Unless I missed description that Stateless Interworking will always use > encapsulation mode even if user packet is IPv6. In DL, Stateless Interworking uses encapsulation for original IPv6 packet with IPv4 and tunnel header. > > > IPv6 Src: Origin Host > IPv6 Dst: SL[n] > Segment Left = n > SL[0] = MN address > SL[1] = Encoded SID > SL[n] = Segment n > > As I mentioned in the previous mail, SL indicates SL[1] at the interworking node. > And interworking segment should behave like below. > > When the endpoint receives packet and the active segment of the > packet indicates the SID, the endpoint pop the SRH of the SID, > >> Set IPv6 destination address as SL[0] (MN's address), and > then the endpoint encaps the payload with the encoded information in > the SID which are tunnel identifier of tunnel header, source and > destination IPv4 address of IPv4 header described in Figure 3. > Right, it looks more precise description to it. Thanks! > > Maybe having example packet headers described for each cases > (encap/insert, User Packet = IPv4/IPv6) will help this makes more easier to > understand. > > Absolutely yes, it's helpful to understand. I'll update the I-D with that example in next revision. Thanks, --satoru --001a1147a148a347c40557da8ce8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kentaro,

I've replied to your pr= evious mail that I hope it would answer to your questions.

On Tue, Aug 29, 2017 at 12:= 44 AM, Kentaro Ebisawa <ebiken.g@gmail.com> wrote:
Hi,

> Q2) Down Link packet (SRv6 to existing network)
> > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, an= d
 > ...
>
> IPv6 Src: Origin Host
> IPv6 Dst: SL[n]
> Segment Left =3D n
> SL[m] =3D Encoded SID
> SL[m+1] =3D Segment m+1
> SL[n] =3D Segment n

 Actually I think this differs for T.Insert case, where MN user packet is IP= v6.
# Unless I missed description that Stateless Interworking will always use e= ncapsulation mode even if user packet is IPv6.

<= div>In DL, Stateless Interworking uses encapsulation for original IPv6 pack= et with IPv4 and tunnel header.

=C2=A0


IPv6 Src: Origin Host
IPv6 Dst: SL[n]
Segment Left =3D n
 SL[0] =3D MN address
SL[1] =3D Encoded SID
SL[n] =3D Segment n


As I mentioned in the previous = mail, SL indicates SL[1] at the interworking node.

=C2=A0
And interworking segment should behave like below.

When the endpoint receives packet and the active segment of the
packet indicates the SID, the endpoint pop the SRH of the SID,
 >> Set IPv6 destination address as SL[0] (MN's address), and
then the endpoint encaps the payload with the encoded information in
the SID which are tunnel identifier of tunnel header, source and
destination IPv4 address of IPv4 header described in Figure 3.


Right, it looks more precise descrip= tion to it. Thanks!

=C2=A0

Maybe having example packet headers described for each cases (encap/insert,= User Packet =3D IPv4/IPv6) will help this makes more easier to understand.=


Absolutely yes, it's helpful to un= derstand. I'll update the I-D with that example in next revision.
=

Thanks,
--satoru

--001a1147a148a347c40557da8ce8-- From nobody Tue Aug 29 09:10:17 2017 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 A8CBB132D52 for ; Tue, 29 Aug 2017 09:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dGvIptIJgUiB for ; Tue, 29 Aug 2017 09:10:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C0A132D0B for ; Tue, 29 Aug 2017 09:10:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7TGA504017746 for ; Tue, 29 Aug 2017 17:10:05 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7TGA3en017730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Aug 2017 17:10:05 +0100 Reply-To: From: "Adrian Farrel" To: Date: Tue, 29 Aug 2017 17:10:03 +0100 Message-ID: <0bee01d320e1$46f55510$d4dfff30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMg4UMSfj+A7R2MQ6a8WdFe8MKc2w== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23290.000 X-TM-AS-Result: No--11.435-10.0-31-10 X-imss-scan-details: No--11.435-10.0-31-10 X-TMASE-MatchedRID: TRwnPLYwJU/huaNyIeP+c/HkpkyUphL9Ud7Bjfo+5jTxaK2X6qQ65hRH GnUfHCcGYKXU5x6vEGMj9UCLTHyvuHJeBHR5wB19Vo6mn+xXmdX8d3gJRYhL8Q2Y8xyy93kWl0Q OeyQOr5aEkhRy/MTP2dREd1RnDg47FIgJ88TZUwuzI1v7J4hECofGLZ++QpQzWabPstVV86nt8r FozbGqQGHpHVX9vZK1eKeT1XBg9mnsfPvby6JqYNNtHlqACwPXziqLoIYKEFQR34ro7k23nbJUB icQ01GRgEBR2HjnXivaZiJAj8isJFYwdrAHWNZlHPCema1j/6va/szejBayyMJyVGyZPcv9o8WM kQWv6iV95l0nVeyiuEIhOWyY9/MAC24oEZ6SpSkj80Za3RRg8FeCmONWAtZUssquZZlrEIRkuV/ Ws6mcfnPh6o1IwNyUegYAQSDilXQ= Archived-At: Subject: [spring] Head up: draft-bryant-mpls-unified-ip-sr-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 16:10:16 -0000 Hi, MPLS Segment Routing in IP Networks Also known as "MPLS-SR-over-UDP" Discussion on the MPLS list. Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 29 August 2017 16:50 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-bryant-mpls-unified-ip-sr-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : MPLS Segment Routing in IP Networks > Authors : Stewart Bryant > Adrian Farrel > John Drake > Jeff Tantsura > Filename : draft-bryant-mpls-unified-ip-sr-02.txt > Pages : 18 > Date : 2017-08-29 > > Abstract: > Segment routing is a source routed forwarding method that allows > packets to be steered through a network on paths other than the > shortest path derived from the routing protocol. The approach uses > information encoded in the packet header to partially or completely > specify the route the packet takes through the network, and does not > make use of a signaling protocol to pre-install paths in the network. > > Two different encapsulations have been defined to enable segment > routing in an MPLS network or in an IPv6 network. While > acknowledging that there is a strong need to support segment routing > in both environments, this document defines a mechanism to carry MPLS > segment routing packets encapsulated in UDP. The resulting approach > is applicable to both IPv4 and IPv6 networks without the need for any > changes to the IP or segment routing specifications. > > This document makes no changes to the segment routing architecture > and builds on existing protocol mechanisms such as the encapsulation > of MPLS within UDP defined in RFC 7510. > > No new procedures are introduced, but existing mechanisms are > combined to achieve the desired result. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-02 > https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-sr-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-unified-ip-sr-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Aug 30 05:35:43 2017 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 9D423133159; Wed, 30 Aug 2017 05:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 4klR9KP_z3L4; Wed, 30 Aug 2017 05:35:33 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 49323133173; Wed, 30 Aug 2017 05:35:33 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id l87so9116981pfj.1; Wed, 30 Aug 2017 05:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version; bh=ZgpdpUJXVI6vWu/MlYK4rj6y9Sjuth0dDtMG3MO+apY=; b=O1Cxny4W0yvDTkC3TB354oS5AbO3IB9WXTZukcUbHdUM9khyjlHaGvh5yQK3J933wo IaDT439KHWs31NneKUF9tTs94DG7MGej5Vg0UE/9sbPpSipUnT8Q1hLUCmqY59tneghR cJXECAu32bAfcn7TCAl75pWFYi2+HHTktOEPUBUQ3v+lYEVTal7FmGljRAiIlhfYVcql /EpoPlgDO2/ib8SiWIHoiHK8sGka6CUoOPEeEOMRemIyag8VvUnuqfaNZOIuJkzzAVC0 Z+8o86j91dJ+ekOvCd5VLbgXGxaiRTdi4J2IP6Q7zatHHciq85HWHakWM9dFnGIP/haV +3og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version; bh=ZgpdpUJXVI6vWu/MlYK4rj6y9Sjuth0dDtMG3MO+apY=; b=dUfYcFLZ6Wrgpkbof1YLp5xzb4wX+zY4UKmfLb8UCARNuH9WanxR73jmMO681hadF6 /ji/RNz7NmphX+zEKJ7wLrIwP7qlu/4hU10u2qtnU5yzwOgog6Xgcg48H0B2lFowOZTx rJpvl9F2gb/cwANLGqw690Lh/Hp+35VL3Tnp+qDJk6n0SvRA4PUEf7LqTZxx4v7eZAgi ujVEvo4bEoeLTWXuHE/7JZDqeny3OJoJLCGJzeFihbIRVrQy91a3PO0eneXdZqnKsAlp rt0fBq/suDfUQMY6vFu09Mv6E4ODUrs2kZbxyj8EurrIJPIiE96ToGQRfJzCaFtecAtN jKJQ== X-Gm-Message-State: AHYfb5jmk9QmRqJwg+sqhhdFaKNkzThv6V+DnExDc5QbgV8U+MX+gcbr P3Pra7Lzu9o4Nw== X-Received: by 10.101.85.193 with SMTP id k1mr1419718pgs.88.1504096532606; Wed, 30 Aug 2017 05:35:32 -0700 (PDT) Received: from [192.168.10.7] (122x210x140x66.ap122.ftth.ucom.ne.jp. [122.210.140.66]) by smtp.gmail.com with ESMTPSA id q13sm9740815pfk.6.2017.08.30.05.35.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 05:35:31 -0700 (PDT) From: "Kentaro Ebisawa" To: "Satoru Matsushima" Cc: dmm , spring@ietf.org Date: Wed, 30 Aug 2017 12:35:30 +0000 Message-Id: In-Reply-To: References: Reply-To: "Kentaro Ebisawa" User-Agent: eM_Client/7.1.30646.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329" Archived-At: Subject: Re: [spring] [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 12:35:35 -0000 --------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Satoru, Thank you for the email replies and taking time for offline discussion. Your explanation in the emails clarified my questions, and leaving a few=20 notes below to share clarification made during the offline chat for=20 others on the list. * In the draft, SRv6-mobile-uplane, IPv4 client packets will use Encap=20 and IPv6 packets will use Insert while traversing SRv6 network. * For UL, Encoded SID will be SL[1] * Exist side of SRv6 and not on the interworking node in DL. * SL[0] is an end host on external network who MN is communicating=20 with. * "Locater of interwork" differes for UL and DL. (as mentioned in the=20 draft) Regards, -- Kentaro Ebisawa ------ Original Message ------ From: "Satoru Matsushima" To: "Kentaro Ebisawa" Cc: "dmm" ; spring@ietf.org; "Matsushima Satoru"=20 Sent: 2017/08/29 10:44:16 Subject: Re: [DMM] How Encoded SID should be placed in SL=20 (SRv6-mobile-uplane) >Hi Kentaro, > >I've replied to your previous mail that I hope it would answer to your=20 >questions. > >On Tue, Aug 29, 2017 at 12:44 AM, Kentaro Ebisawa =20 >wrote: >>Hi, >> >> > Q2) Down Link packet (SRv6 to existing network) >> > > When the endpoint receives packet and the active segment of the >> > > packet indicates the SID, the endpoint pop the SRH of the SID, and >> > ... >> > >> > IPv6 Src: Origin Host >> > IPv6 Dst: SL[n] >> > Segment Left =3D n >> > SL[m] =3D Encoded SID >> > SL[m+1] =3D Segment m+1 >> > SL[n] =3D Segment n >> >>Actually I think this differs for T.Insert case, where MN user packet=20 >>is IPv6. >># Unless I missed description that Stateless Interworking will always=20 >>use encapsulation mode even if user packet is IPv6. > >In DL, Stateless Interworking uses encapsulation for original IPv6=20 >packet with IPv4 and tunnel header. > > >> >> >>IPv6 Src: Origin Host >>IPv6 Dst: SL[n] >>Segment Left =3D n >>SL[0] =3D MN address >>SL[1] =3D Encoded SID >>SL[n] =3D Segment n >> > >As I mentioned in the previous mail, SL indicates SL[1] at the=20 >interworking node. > > >>And interworking segment should behave like below. >> >>When the endpoint receives packet and the active segment of the >>packet indicates the SID, the endpoint pop the SRH of the SID, >> >> Set IPv6 destination address as SL[0] (MN's address), and >>then the endpoint encaps the payload with the encoded information in >>the SID which are tunnel identifier of tunnel header, source and >>destination IPv4 address of IPv4 header described in Figure 3. > > >Right, it looks more precise description to it. Thanks! > > >> >>Maybe having example packet headers described for each cases=20 >>(encap/insert, User Packet =3D IPv4/IPv6) will help this makes more=20 >>easier to understand. >> > >Absolutely yes, it's helpful to understand. I'll update the I-D with=20 >that example in next revision. > >Thanks, >--satoru > --------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Satoru,

Thank = you for the email replies and taking time for offline discussion.

Your explanation in the emails clarified my questions, a= nd leaving a few notes below to share clarification made during the offline = chat for others on the list.

* In the draft, SRv6-mobile-uplane, IPv4 client packets will use En= cap and IPv6 packets will use Insert while traversing SRv6 network.
* For UL, Encoded SID will be SL[1]
=C2=A0 =C2=A0 * Exist side of SRv6 and not on=C2= =A0the interworking node in DL.
=C2=A0 = =C2=A0 * SL[0] is an end host on external network who MN is communicating= with.
* "Locater of interwork" differes = for UL and DL. (as mentioned in the draft)

Regards,
--=C2=A0<= /div>
Kentaro Eb= isawa <ebiken.g@gmail.com><= /div>

------ Original Message ------
From: "Satoru Matsushima" <satoru.matsushima@gmail.com>
To: "Kentaro Ebisawa" <ebiken= .g@gmail.com>
Cc: "dmm" <dmm@ietf.org>; spring@ietf.org; "Matsushima Satoru" &= lt;satoru.matsushima@= g.softbank.co.jp>
Sent: 2017/08/29 10:44:16
Subject: Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile= -uplane)

Hi Kentaro,

I've replied to your prev= ious mail that I hope it would answer to your questions.

On Tue, Aug 29, 2017 at 12:4= 4 AM, Kentaro Ebisawa <ebiken.g@gmail.com> wrote:
Hi,

> Q2) Down Link packet (SRv6 to existing network)
> > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, an= d
 > ...
>
> IPv6 Src: Origin Host
> IPv6 Dst: SL[n]
> Segment Left =3D n
> SL[m] =3D Encoded SID
> SL[m+1] =3D Segment m+1
> SL[n] =3D Segment n

 Actually I think this differs for T.Insert case, where MN user packet is IP= v6.
# Unless I missed description that Stateless Interworking will always use e= ncapsulation mode even if user packet is IPv6.

In DL, Stateless Interworking uses encapsulation for original IPv6 pa= cket with IPv4 and tunnel header.

=C2=A0


IPv6 Src: Origin Host
IPv6 Dst: SL[n]
Segment Left =3D n
 SL[0] =3D MN address
SL[1] =3D Encoded SID
SL[n] =3D Segment n


As I mentioned in the previ= ous mail, SL indicates SL[1] at the interworking node.

=C2=A0
And interworking segment should behave like below.

When the endpoint receives packet and the active segment of the
packet indicates the SID, the endpoint pop the SRH of the SID,
 >> Set IPv6 destination address as SL[0] (MN's address), and
then the endpoint encaps the payload with the encoded information in
the SID which are tunnel identifier of tunnel header, source and
destination IPv4 address of IPv4 header described in Figure 3.


Right, it looks more precise d= escription to it. Thanks!

=C2=A0

Maybe having example packet headers described for each cases (encap/insert, = User Packet =3D IPv4/IPv6) will help this makes more easier to understand.=


Absolutely yes, it's helpful to un= derstand. I'll update the I-D with that example in next revision.

Thanks,
--satoru

--------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329-- From nobody Wed Aug 30 21:35:23 2017 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 C41CB124207; Wed, 30 Aug 2017 21:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TJ8q-uGmRUan; Wed, 30 Aug 2017 21:35:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30C913207A; Wed, 30 Aug 2017 21:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31108; q=dns/txt; s=iport; t=1504154118; x=1505363718; h=from:to:cc:subject:date:message-id:mime-version; bh=cqWg2yCQmiFRMBOrsIWJKyd0lapLVwp03knZFm74R44=; b=lhCoETSkChqFzdhowKUd6aw9xMcIvmV7hYKe3TeeZAan/U40yj6uq2yH qGfpb2Su1Tb1rj93XAhF7f/dGtNaZUqPg4G7/eRhwQhPsyHLBYqlkgJl0 FfZZ5cvVgttHG+n91gnkLBaqdBhty6SRyWe0EYOPp4d7CT158ueSPj90o 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAgDGkKdZ/5BdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEcg3CaPpgYDoIEhUcchA1BFgECAQEBAQEBAWsdC4VCCkw?= =?us-ascii?q?SAQYUJgoCBDAXEAQOGQeJMmSQMJ1mgicnixwBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdgyqCAoFOgWIBK4cuDBEBgzkwgjEFmC6IPgKUTYIShWeKcpZEASYHKoENdxV?= =?us-ascii?q?bAYUFHIFniGkBJYEMgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,451,1498521600"; d="scan'208,217";a="287385888" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 04:35:17 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v7V4ZHDp024918 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 04:35:17 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 23:35:16 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 23:35:16 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-spring-segment-routing-central-epe@Ietf.org" CC: "bruno.decraene@orange.com" , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-segment-routing-central-epe-06 Thread-Index: AQHTIhKLr09AAYeZSUuHhG5Bg19/8Q== Date: Thu, 31 Aug 2017 04:35:16 +0000 Message-ID: <90B793CC-B081-475E-AC71-89B5F575B303@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.171.228] Content-Type: multipart/alternative; boundary="_000_90B793CCB081475EAC7189B5F575B303ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 04:35:22 -0000 --_000_90B793CCB081475EAC7189B5F575B303ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpJIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAg SSBoYXZlIGEgY291cGxlIG9mIE1ham9yIGNvbmNlcm5zIChzZWUgYmVsb3cpIHdoaWNoIEkgd291 bGQgbGlrZSB0byBzZWUgYWRkcmVzc2VkIGJlZm9yZSBzdGFydGluZyB0aGUgSUVURiBMYXN0IENh bGwgb24gdGhpcyBkb2N1bWVudC4NCg0KVGhhbmtzISENCg0KQWx2YXJvLg0KDQoNCg0KTWFqb3I6 DQoNCk0xLiBUaGlzIGRvY3VtZW50IG1lbnRpb25zIGluIHNldmVyYWwgcGxhY2VzIHRoYXQgdGhl IHNlZ21lbnQgcm91dGluZyBpbmZvcm1hdGlvbiBjYW4gYmUgcHJvZ3JhbW1lZCBhdCBob3N0cyAo b3Ig4oCcY29udGVudCBzb3VyY2XigJ0pLiAgQXMgd2UgYWxsIGtub3csIHNpZ25pZmljYW50IGNv bmNlcm5zIGV4aXN0IGluIHRoZSBjb21tdW5pdHkgYWJvdXQgdXNpbmcgc291cmNlIHJvdXRpbmcg YWxsIHRoZSB3YXkgYXQgdGhlIGhvc3QgKGV2ZW4gaWYsIGFzIGluIHRoaXMgY2FzZSwgd2XigJly ZSB0YWxraW5nIGFib3V0IGEgY2VudHJhbGl6ZWQgcHJvZ3JhbWluZykuICBUaGUgQXJjaGl0ZWN0 dXJlIGRvY3VtZW50IGRvZXNu4oCZdCBleHBsaWNpdGx5IGVsaW1pbmF0ZSBob3N0cyBmcm9tIGFu IFNSIGRvbWFpbiAodGhlIGRlZmluaXRpb24gaXMg4oCcbm9kZXMgcGFydGljaXBhdGluZyBpbnRv IHRoZSBzb3VyY2Ugcm91dGluZyBtb2RlbOKAnSksIGJ1dCBpdCBhbHNvIGRvZXNu4oCZdCBleHBs aWNpdGx5IGluY2x1ZGUgdGhlbeKApmJ1dCB0aGUgdGV4dCBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMg ZXhjbHVkaW5nIChmb3IgZXhhbXBsZTog4oCcdGhlIGV4cGxpY2l0IHJvdXRpbmcgaW5mb3JtYXRp b24gTVVTVCBOT1QgYmUgbGVha2VkIHRocm91Z2ggdGhlIGJvdW5kYXJpZXMgb2YgdGhlIGFkbWlu aXN0ZXJlZCBkb21haW7igJ0sIG9yIOKAnEZpbHRlcmluZyBNVVNUIGJlIHBlcmZvcm1lZCBvbiB0 aGUgZm9yd2FyZGluZyBwbGFuZSBhdCB0aGUgYm91bmRhcmllcyBvZiB0aGUgU1IgZG9tYWlu4oCd LCBldGMuKS4gIFRoZXJlIGlzIG5vdGhpbmcgc3BlY2lmaWMgdGhhdCB0ZWxscyBtZSB0aGF0IHRo aXMgY2FzZSAoRVBFKSBpcyBkaWZmZXJlbnQgZnJvbSBhbnkgb3RoZXIgU1IgYXBwbGljYXRpb24g 4oCTIGlmIGhvc3RzIGFyZSB0byBiZSBleHBsaWNpdGx5IGNvbnNpZGVyZWQgcGFydCBvZiBhIGRv bWFpbiB0aGVuIHRoYXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgZGVzY3JpYmVkIGluIHRoZSBBcmNo aXRlY3R1cmUgZG9jdW1lbnQuICBJbiBzaG9ydCwgcGxlYXNlIHRha2UgcmVmZXJlbmNlcyB0byBo b3N0cyBvdXQgb2YgdGhpcyBkb2N1bWVudCAodW5sZXNzIHlvdSBkZWNpZGUgdG8gYWRkIGEgZGlz Y3Vzc2lvbiBhYm91dCB0aGVtIGluIHRoZSBBcmNoaXRlY3R1cmUgZG9jdW1lbnQpLg0KDQoNCk0y LiBUaGUgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gMS4xLiAoUHJvYmxlbSBTdGF0ZW1lbnQpIG1h a2Ugbm9uLWV4cGxpY2l0IHVzZSBvZiBub3JtYXRpdmUgbGFuZ3VhZ2U7IG1vc3Qgb2YgdGhlIHJl cXVpcmVtZW50cyBhcmUgbm9uLXRlY2huaWNhbCBhbmQgYXNwaXJhdGlvbmFsIGluIG5hdHVyZS4g IFdoaWxlIEkgdGhpbmsgdGhhdCB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGlzIG5vdCB1c2VkIGFz IGludGVuZGVkIGluIHJmYzIxMTkgKOKAnE1VU1Qgb25seSBiZSB1c2VkIHdoZXJlIGl0IGlzIGFj dHVhbGx5IHJlcXVpcmVkIGZvciBpbnRlcm9wZXJhdGlvbiBvciB0byBsaW1pdCBiZWhhdmlvciB3 aGljaCBoYXMgcG90ZW50aWFsIGZvciBjYXVzaW5nIGhhcm3igJ0pLCBJIHRoaW5rIGl0IGlzIG9r IGluIHRoaXMgY2FzZSB0byBleHByZXNzIHNvbWUgcmVxdWlyZW1lbnRzLiAgSSB3b3VsZCwgaG93 ZXZlciwgcHJlZmVyIGlmIHRoZWlyIHVzZSBsYXMgbGltaXRlZC4gIE5ldmVydGhlbGVzcywgaGVy ZSBhcmUgc29tZSBzdWdnZXN0aW9ucy9xdWVzdGlvbnMvY29tbWVudHM6DQoNCk0yLjEuIFdoYXQg ZG9lcyDigJxNVVNUIE5PVCBtYWtlIGFueSBhc3N1bXB0aW9u4oCdIG1lYW4/DQpPTEQ+DQogICAg IFRoZSBzb2x1dGlvbiBNVVNUIE5PVCBtYWtlIGFueSBhc3N1bXB0aW9uIG9uIHRoZSBjdXJyZW50 bHkNCiAgICAgIGRlcGxveWVkIGlCR1Agc2NoZW1lcyAoUlJzLCBjb25mZWRlcmF0aW9ucyBvciBp QkdQIGZ1bGwgbWVzaGVzKQ0KICAgICAgYW5kIE1VU1QgYmUgYWJsZSB0byBzdXBwb3J0IGFsbCBv ZiB0aGVtLg0KDQpORVc+DQogICAgICBUaGUgc29sdXRpb24gTVVTVCBzdXBwb3J0IGFueSBkZXBs b3llZCBpQkdQIHNjaGVtZXMNCiAgICAgIChSUnMsIGNvbmZlZGVyYXRpb25zIG9yIGlCR1AgZnVs bCBtZXNoZXMpLg0KDQpNLjIuMi4gVHdvIE1VU1RzIGRvZXNu4oCZdCBtYWtlIHRoZSB0ZXh0IGJl dHRlci4NCk9MRD4NCiAgICAgVGhlIHNvbHV0aW9uIE1VU1QgYmUgYXBwbGljYWJsZSB0byBhbnkg dHlwZSBvZiBFUEUgcm91dGVyLiAgV2hpbGUNCiAgICAgICJFZ3Jlc3MgUGVlciBFbmdpbmVlcmlu ZyIgcmVmZXJzIHRvICJFeHRlcm5hbCIgcGVlcmluZywgdGhlDQogICAgICBzb2x1dGlvbiBNVVNU IGFsc28gYmUgYXBwbGljYWJsZSB0byBhIHJvdXRlciBoYXZpbmcgaW50ZXJuYWwNCiAgICAgIHBl ZXJzLg0KDQpORVc+DQogICAgICBUaGUgc29sdXRpb24gTVVTVCBiZSBhcHBsaWNhYmxlIHRvIGJv dGggcm91dGVycyB3aXRoIGV4dGVybmFsDQogICAgICBhbmQgaW50ZXJuYWwgcGVlcnMuDQoNCk0y LjMuIOKAnFRoZSBzb2x1dGlvbiBTSE9VTEQgbWluaW1pemUgdGhlIG5lZWQgZm9yIG5ldyBCR1Ag Y2FwYWJpbGl0aWVzIGF0IHRoZSBpbmdyZXNzIFBFcy7igJ0gIFdoYXQgaXMgdGhlIGV4cGxpY2l0 IHJlcXVpcmVtZW50LCB0aGF0IG5lZWRzIHRoZSDigJxTSE9VTETigJ0sIGZyb20gYW4gaW50ZXJv cGVyYWJpbGl0eSBwb2ludCBvZiB2aWV3Pw0KDQpNMi40LiDigJxUaGUgc29sdXRpb24gTVVTVCBh Y2NvbW1vZGF0ZSBhbiBpbmdyZXNzIEJHUC1FUEUgcG9saWN5IGF0IGFuIGluZ3Jlc3MgUEUgb3Ig ZGlyZWN0bHkgYXQgYSBzb3VyY2UgaG9zdCB3aXRoaW4gdGhlIGRvbWFpbi7igJ0gIOKAnE1VU1Qg YWNjb21tb2RhdGXigJ0/PyAgV2hhdCBhcmUgeW91IGxvb2tpbmcgZm9yPyAgVGhlIGFiaWxpdHkg dG8gcHJvZ3JhbSBhdCB0aG9zZSBwb2ludHM/ICBUaGUgYWJpbGl0eSB0byBpbnN0YW50aWF0ZSBh bnkgcG9saWN5PyAgVGhlIEludHJvZHVjdGlvbiBzYXlzIHRoYXQg4oCcVGhlIGV4aGF1c3RpdmUg ZGVmaW5pdGlvbiBvZiBhbGwgdGhlIG1lYW5zIHRvIHByb2dyYW0gYW4gQkdQLUVQRSBpbnB1dCBw b2xpY3kgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC7igJ0sIHNvIG1hbmRh dGluZyBzb21ldGhpbmcgdGhhdCBpcyBvdXQgb2Ygc2NvcGUgc2VlbXMgbGlrZSBhIGNvbnRyYWRp Y3Rpb24uDQoNCk0yLjUuIOKAnFRoZSBzb2x1dGlvbiBNVVNUIHN1cHBvcnQgYXV0b21hdGVkIEZh c3QgUmVyb3V0ZSAoRlJSKSBhbmQgZmFzdCBjb252ZXJnZW5jZSBtZWNoYW5pc21zLuKAnSAgQnV0 IHRoZW4gc2VjdGlvbiAzLjYuIChGYXN0IFJlcm91dGUgKEZSUikpIHNheXMgdGhhdCBGUlIgaXMg b3B0aW9uYWwuDQoNCg0KTTMuIFRoZSByZWZlcmVuY2VzIHRvIEktRC5pZXRmLWlkci1iZ3Bscy1z ZWdtZW50LXJvdXRpbmctZXBlLCBJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nIGFuZCBS RkM3NzUyIHNob3VsZCBiZSBOb3JtYXRpdmUuDQoNCg0KTWlub3I6DQoNClAxLiBBcyBpbiBhbGwg dGhlIHJlbGF0ZWQgZG9jdW1lbnRzLCBwbGVhc2UgdGFrZSDigJxzZXJ2aWNlIGNoYWlu4oCdIG91 dCB0byBhdm9pZCBjb25mdXNpb24uDQoNCg0KUDIuIFRoZSBleGFtcGxlcyBpbiBTZWN0aW9ucyAz Lnggc2VlbSBpbmNvbXBsZXRlIGFuZCBpbmFjY3VyYXRlIHRvIG1lLiAgQWxzbywgdGhlIG5hbWVz IHVzZWQgZG9u4oCZdCBtYXRjaCB3aGF0IGlzIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRmLWlkci1i Z3Bscy1zZWdtZW50LXJvdXRpbmctZXBlLiAgSW4gZ2VuZXJhbCwgcGxlYXNlIGJlIGNvbnNpc3Rl bnQgd2l0aCB0aGUgbmFtZXMhICBGb3IgZXhhbXBsZToNCg0KU2VjdGlvbiAzLjEuIChQZWVyTm9k ZSBTSUQgdG8gRCk6DQrigJwNCiAgIERlc2NyaXB0b3JzOg0KDQogICBvICBOb2RlIERlc2NyaXB0 b3JzIChCR1Agcm91dGVyLUlELCBBU04pOiAxOTIuMC4yLjMsIEFTMQ0KDQogICBvICBQZWVyIERl c2NyaXB0b3JzIChwZWVyIEJHUCByb3V0ZXItSUQsIHBlZXIgQVNOKTogMTkyLjAuMi40LCBBUzIN Cg0KICAgbyAgTGluayBEZXNjcmlwdG9ycyAoSVAgaW50ZXJmYWNlIGFkZHJlc3MsIG5laWdoYm9y IElQIGFkZHJlc3MpOg0KICAgICAgMjAwMTpkYjg6Y2Q6OmMsIDIwMDE6ZGI4OmNkOjpkDQoNCiAg IEF0dHJpYnV0ZXM6DQoNCiAgIG8gIFBlZXJOb2RlIFNJRDogMTAxMg0K4oCcDQoNCkNvbW1lbnRz Pg0KLSBTZWN0aW9uIDUuMSBpbiBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmct ZXBlIHVzZXMg4oCcTG9jYWwgTm9kZSBEZXNjcmlwdG9y4oCdIGluc3RlYWQgb2Ygc2ltcGx5IOKA nE5vZGUgRGVzY3JpcHRvcuKAnSwgYW5kIHRoZSBCR1AtTFMgSUQgaXMgbWlzc2luZyBhYm92ZS4N Ci0gcy9QZWVyIERlc2NyaXB0b3JzL1JlbW90ZSBOb2RlIERlc2NyaXB0b3INCi0gVGhlIExpbmsg RGVzY3JpcHRvciB1c2VzIHRoZSB0ZXJtcyDigJxJUHY2IEludGVyZmFjZSBBZGRyZXNz4oCdIGFu ZCDigJxJUHY2IE5laWdoYm9yIEFkZHJlc3PigJ3igKYNCi0gcy9BdHRyaWJ1dGVzL0xpbmsgQXR0 cmlidXRlDQoNCg0KUDMuIFNlY3Rpb24gMy42LiAoRmFzdCBSZXJvdXRlIChGUlIpKTog4oCcQSBC R1AtRVBFIGVuYWJsZWQgYm9yZGVyIHJvdXRlciBNQVkgYWxsb2NhdGUgYSBGUlIgYmFja3VwIGVu dHJ5IG9uIGEgcGVyIEJHUCBQZWVyaW5nIFNJRCBiYXNpcyAoYXNzdW1pbmcgaW50ZXItQVMgYWdy ZWVtZW50IG9uIHRoZSBGUlIgc3RyYXRlZ3kvcG9saWN5KS7igJ0gIFdoeSBpcyBhbiDigJxpbnRl ci1BUyBhZ3JlZW1lbnTigJ0gbmVlZGVkPyAgRlJSIGlzIGEgbG9jYWwgZGVjaXNpb24sIGFuZCwg YXNzdW1pbmcgdGhhdCB0aGUgYm9yZGVyIHJvdXRlciBpcyBhdCB0aGUgZWRnZSBvZiB0aGUgU1Ig ZG9tYWlu4oCmd2h5IHdvdWxkIHRoZSBuZXh0IEFTIG5lZWQgdG8gYWdyZWU/ICBBbSBJIG1pc3Np bmcgc29tZXRoaW5nPw0KDQoNClA0LiBSZWZlcmVuY2VzOg0KLSBQbGVhc2UgYWRkIGEgcmVmZXJl bmNlIGZvciBCTVAgYW5kIElQRklYLg0KLSBQdXQgdGhlIHJlZmVyZW5jZSB0byBCR1AtTFMgb24g Zmlyc3QgbWVudGlvbiAoYW5kIG5vdCBqdXN0IHdheSBkb3duIGluIFNlY3Rpb24gOSkuDQotIFJl cGxhY2UgdGhlIHJlZmVyZW5jZSB0byBSRkMzMTA3IHdpdGggZHJhZnQtaWV0Zi1tcGxzLXJmYzMx MDdiaXMg4oCTIGFuZCBpdCBjYW4gYmUgbWFkZSBJbmZvcm1hdGl2ZS4NCi0gVGhlIHJlZmVyZW5j ZSB0byBSRkM2MjQxIHNob3VsZCBiZSBJbmZvcm1hdGl2ZS4NCg0KDQpQNS4gRnJvbSBTZWN0aW9u IDkuIChNYW5hZ2VhYmlsaXR5IENvbnNpZGVyYXRpb25zKTog4oCc4oCmdGhlIGFkdmVydGlzZW1l bnQgb2YgRVBFIGluZm9ybWF0aW9uIE1VU1QgY29uZm9ybSB0byBzdGFuZGFyZCBCR1AgYWR2ZXJ0 aXNlbWVudCBhbmQgcHJvcGFnYXRpb24gcnVsZXMgKGlCR1AsIGVCR1AsIFJvdXRlLVJlZmxlY3Rv cnMsIENvbmZlZGVyYXRpb25zKS7igJ0gIFdoYXQgZG9lcyB0aGlzIHRleHQgbWVhbj8gIEFzIGZh ciBhcyBJIGNhbiB0ZWxsLCB0aGVyZeKAmXMgbm8gY2hhbmdlIHRvIEJHUCB0byBiZSBhYmxlIHRv IGluc3RhbnRpYXRlIEVQReKApg0KDQoNCk5pdHM6DQoNCk4xLiBUaGUgc2Vjb25kIHBhcmFncmFw aCBpbiB0aGUgQWJzdHJhY3Qgc2VlbXMgdW5uZWNlc3NhcnkuDQoNCk4yLiBQbGVhc2UgYXZvaWQg dXNpbmcg4oCcd2XigJ0uDQoNCk4zLiBTZWN0aW9uIDUuMiBzZWVtcyB0byBpbnRyb2R1Y2UgdGhp cyBuZXcgbm90YXRpb246IOKAnElQIHJvdXRlIEwvOCBzZXQgbmV4dC1ob3AgVDHigJ3igKYgcGxl YXNlIGV4cGxhaW4uICBMLzggaXMg4oCcaGlkZGVu4oCdIGluIEZpZ3VyZSAxLCBhbmQgbm90IG9i dmlvdXMgc2luY2UgaXQgbG9va3MgbGlrZSBhbiBJUHY0IHByZWZpeCwgYnV0IHRoZSBleGFtcGxl cyBhcmUgYWxsIElQdjYuDQo= --_000_90B793CCB081475EAC7189B5F575B303ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1795195E18799740A5E3231942151399@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNyIv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgYXV0aG9yczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkkganVzdCBmaW5pc2hlZCByZWFkaW5nIHRoaXMgZG9jdW1lbnQu Jm5ic3A7IEkgaGF2ZSBhIGNvdXBsZSBvZiBNYWpvciBjb25jZXJucyAoc2VlIGJlbG93KSB3aGlj aCBJIHdvdWxkIGxpa2UgdG8gc2VlIGFkZHJlc3NlZCBiZWZvcmUgc3RhcnRpbmcgdGhlIElFVEYg TGFzdCBDYWxsIG9uIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5UaGFua3MhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NYWpv cjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0xLiBUaGlzIGRv Y3VtZW50IG1lbnRpb25zIGluIHNldmVyYWwgcGxhY2VzIHRoYXQgdGhlIHNlZ21lbnQgcm91dGlu ZyBpbmZvcm1hdGlvbiBjYW4gYmUgcHJvZ3JhbW1lZCBhdCBob3N0cyAob3Ig4oCcY29udGVudCBz b3VyY2XigJ0pLiZuYnNwOyBBcyB3ZSBhbGwga25vdywgc2lnbmlmaWNhbnQgY29uY2VybnMgZXhp c3QgaW4gdGhlIGNvbW11bml0eSBhYm91dCB1c2luZw0KIHNvdXJjZSByb3V0aW5nIGFsbCB0aGUg d2F5IGF0IHRoZSBob3N0IChldmVuIGlmLCBhcyBpbiB0aGlzIGNhc2UsIHdl4oCZcmUgdGFsa2lu ZyBhYm91dCBhIGNlbnRyYWxpemVkIHByb2dyYW1pbmcpLiZuYnNwOyBUaGUgQXJjaGl0ZWN0dXJl IGRvY3VtZW50IGRvZXNu4oCZdCBleHBsaWNpdGx5IGVsaW1pbmF0ZSBob3N0cyBmcm9tIGFuIFNS IGRvbWFpbiAodGhlIGRlZmluaXRpb24gaXMg4oCcbm9kZXMgcGFydGljaXBhdGluZyBpbnRvIHRo ZSBzb3VyY2Ugcm91dGluZw0KIG1vZGVs4oCdKSwgYnV0IGl0IGFsc28gZG9lc27igJl0IGV4cGxp Y2l0bHkgaW5jbHVkZSB0aGVt4oCmYnV0IHRoZSB0ZXh0IGNhbiBiZSBpbnRlcnByZXRlZCBhcyBl eGNsdWRpbmcgKGZvciBleGFtcGxlOiDigJx0aGUgZXhwbGljaXQgcm91dGluZyBpbmZvcm1hdGlv biBNVVNUIE5PVCBiZSBsZWFrZWQgdGhyb3VnaCB0aGUgYm91bmRhcmllcyBvZiB0aGUgYWRtaW5p c3RlcmVkIGRvbWFpbuKAnSwgb3Ig4oCcRmlsdGVyaW5nIE1VU1QgYmUgcGVyZm9ybWVkIG9uIHRo ZQ0KIGZvcndhcmRpbmcgcGxhbmUgYXQgdGhlIGJvdW5kYXJpZXMgb2YgdGhlIFNSIGRvbWFpbuKA nSwgZXRjLikuJm5ic3A7IFRoZXJlIGlzIG5vdGhpbmcgc3BlY2lmaWMgdGhhdCB0ZWxscyBtZSB0 aGF0IHRoaXMgY2FzZSAoRVBFKSBpcyBkaWZmZXJlbnQgZnJvbSBhbnkgb3RoZXIgU1IgYXBwbGlj YXRpb24g4oCTIGlmIGhvc3RzIGFyZSB0byBiZSBleHBsaWNpdGx5IGNvbnNpZGVyZWQgcGFydCBv ZiBhIGRvbWFpbiB0aGVuIHRoYXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkNCiBkZXNjcmliZWQgaW4g dGhlIEFyY2hpdGVjdHVyZSBkb2N1bWVudC4mbmJzcDsgSW4gc2hvcnQsIHBsZWFzZSB0YWtlIHJl ZmVyZW5jZXMgdG8gaG9zdHMgb3V0IG9mIHRoaXMgZG9jdW1lbnQgKHVubGVzcyB5b3UgZGVjaWRl IHRvIGFkZCBhIGRpc2N1c3Npb24gYWJvdXQgdGhlbSBpbiB0aGUgQXJjaGl0ZWN0dXJlIGRvY3Vt ZW50KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5NMi4gVGhlIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDEuMS4gKFBy b2JsZW0gU3RhdGVtZW50KSBtYWtlIG5vbi1leHBsaWNpdCB1c2Ugb2Ygbm9ybWF0aXZlIGxhbmd1 YWdlOyBtb3N0IG9mIHRoZSByZXF1aXJlbWVudHMgYXJlIG5vbi10ZWNobmljYWwgYW5kIGFzcGly YXRpb25hbCBpbiBuYXR1cmUuJm5ic3A7IFdoaWxlIEkgdGhpbmsgdGhhdCB0aGUgbm9ybWF0aXZl DQogbGFuZ3VhZ2UgaXMgbm90IHVzZWQgYXMgaW50ZW5kZWQgaW4gcmZjMjExOSAo4oCcTVVTVCBv bmx5IGJlIHVzZWQgd2hlcmUgaXQgaXMgYWN0dWFsbHkgcmVxdWlyZWQgZm9yIGludGVyb3BlcmF0 aW9uIG9yIHRvIGxpbWl0IGJlaGF2aW9yIHdoaWNoIGhhcyBwb3RlbnRpYWwgZm9yIGNhdXNpbmcg aGFybeKAnSksIEkgdGhpbmsgaXQgaXMgb2sgaW4gdGhpcyBjYXNlIHRvIGV4cHJlc3Mgc29tZSBy ZXF1aXJlbWVudHMuJm5ic3A7IEkgd291bGQsIGhvd2V2ZXIsIHByZWZlcg0KIGlmIHRoZWlyIHVz ZSBsYXMgbGltaXRlZC4mbmJzcDsgTmV2ZXJ0aGVsZXNzLCBoZXJlIGFyZSBzb21lIHN1Z2dlc3Rp b25zL3F1ZXN0aW9ucy9jb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPk0yLjEuIFdoYXQgZG9lcyDigJxNVVNUIE5PVCBtYWtlIGFueSBhc3N1bXB0aW9u 4oCdIG1lYW4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk9MRCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBzb2x1dGlvbiBNVVNUIE5PVCBtYWtlIGFueSBhc3N1 bXB0aW9uIG9uIHRoZSBjdXJyZW50bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRlcGxveWVkIGlCR1Agc2NoZW1lcyAoUlJzLCBjb25mZWRlcmF0aW9u cyBvciBpQkdQIGZ1bGwgbWVzaGVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYW5kIE1VU1QgYmUgYWJsZSB0byBzdXBwb3J0IGFsbCBvZiB0aGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TkVXJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHNvbHV0aW9uIE1V U1Qgc3VwcG9ydCBhbnkgZGVwbG95ZWQgaUJHUCBzY2hlbWVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KFJScywgY29uZmVkZXJhdGlvbnMg b3IgaUJHUCBmdWxsIG1lc2hlcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NLjIuMi4gVHdvIE1VU1RzIGRvZXNu4oCZdCBtYWtlIHRoZSB0ZXh0IGJldHRlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+T0xEJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhlIHNvbHV0aW9uIE1VU1QgYmUgYXBwbGljYWJsZSB0byBhbnkgdHlwZSBv ZiBFUEUgcm91dGVyLiZuYnNwOyBXaGlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7RWdyZXNzIFBlZXIgRW5naW5lZXJpbmcmcXVvdDsgcmVm ZXJzIHRvICZxdW90O0V4dGVybmFsJnF1b3Q7IHBlZXJpbmcsIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc29sdXRpb24gTVVTVCBhbHNvIGJlIGFw cGxpY2FibGUgdG8gYSByb3V0ZXIgaGF2aW5nIGludGVybmFsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwZWVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5FVyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBzb2x1dGlvbiBNVVNUIGJlIGFwcGxpY2FibGUgdG8g Ym90aCByb3V0ZXJzIHdpdGggZXh0ZXJuYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBpbnRlcm5hbCBwZWVycy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLjMuIOKAnFRoZSBzb2x1dGlvbiBTSE9VTEQgbWlu aW1pemUgdGhlIG5lZWQgZm9yIG5ldyBCR1AgY2FwYWJpbGl0aWVzIGF0IHRoZSBpbmdyZXNzIFBF cy7igJ0mbmJzcDsgV2hhdCBpcyB0aGUgZXhwbGljaXQgcmVxdWlyZW1lbnQsIHRoYXQgbmVlZHMg dGhlIOKAnFNIT1VMROKAnSwgZnJvbSBhbiBpbnRlcm9wZXJhYmlsaXR5IHBvaW50IG9mIHZpZXc/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NMi40LiDigJxUaGUg c29sdXRpb24gTVVTVCBhY2NvbW1vZGF0ZSBhbiBpbmdyZXNzIEJHUC1FUEUgcG9saWN5IGF0IGFu IGluZ3Jlc3MgUEUgb3IgZGlyZWN0bHkgYXQgYSBzb3VyY2UgaG9zdCB3aXRoaW4gdGhlIGRvbWFp bi7igJ0mbmJzcDsg4oCcTVVTVCBhY2NvbW1vZGF0ZeKAnT8/Jm5ic3A7IFdoYXQgYXJlIHlvdSBs b29raW5nIGZvcj8mbmJzcDsgVGhlIGFiaWxpdHkgdG8gcHJvZ3JhbSBhdA0KIHRob3NlIHBvaW50 cz8mbmJzcDsgVGhlIGFiaWxpdHkgdG8gaW5zdGFudGlhdGUgYW55IHBvbGljeT8mbmJzcDsgVGhl IEludHJvZHVjdGlvbiBzYXlzIHRoYXQg4oCcVGhlIGV4aGF1c3RpdmUgZGVmaW5pdGlvbiBvZiBh bGwgdGhlIG1lYW5zIHRvIHByb2dyYW0gYW4gQkdQLUVQRSBpbnB1dCBwb2xpY3kgaXMgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC7igJ0sIHNvIG1hbmRhdGluZyBzb21ldGhpbmcg dGhhdCBpcyBvdXQgb2Ygc2NvcGUgc2VlbXMgbGlrZQ0KIGEgY29udHJhZGljdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLjUuIOKAnFRoZSBzb2x1dGlv biBNVVNUIHN1cHBvcnQgYXV0b21hdGVkIEZhc3QgUmVyb3V0ZSAoRlJSKSBhbmQgZmFzdCBjb252 ZXJnZW5jZSBtZWNoYW5pc21zLuKAnSZuYnNwOyBCdXQgdGhlbiBzZWN0aW9uIDMuNi4gKEZhc3Qg UmVyb3V0ZSAoRlJSKSkgc2F5cyB0aGF0IEZSUiBpcyBvcHRpb25hbC4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0z LiBUaGUgcmVmZXJlbmNlcyB0byBJLUQuaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVw ZSwgSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZyBhbmQgUkZDNzc1MiBzaG91bGQgYmUg Tm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1pbm9yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+UDEuIEFzIGluIGFsbCB0aGUgcmVsYXRlZCBkb2N1bWVudHMsIHBsZWFz ZSB0YWtlIOKAnHNlcnZpY2UgY2hhaW7igJ0gb3V0IHRvIGF2b2lkIGNvbmZ1c2lvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5QMi4gVGhlIGV4YW1wbGVzIGluIFNlY3Rpb25zIDMueCBzZWVtIGluY29tcGxldGUgYW5k IGluYWNjdXJhdGUgdG8gbWUuJm5ic3A7IEFsc28sIHRoZSBuYW1lcyB1c2VkIGRvbuKAmXQgbWF0 Y2ggd2hhdCBpcyBzcGVjaWZpZWQgaW4gZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0 aW5nLWVwZS4mbmJzcDsgSW4gZ2VuZXJhbCwgcGxlYXNlIGJlIGNvbnNpc3RlbnQgd2l0aA0KIHRo ZSBuYW1lcyEmbmJzcDsgRm9yIGV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5TZWN0aW9uIDMuMS4gKFBlZXJOb2RlIFNJRCB0byBEKTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+4oCcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBEZXNjcmlwdG9yczo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBv Jm5ic3A7IE5vZGUgRGVzY3JpcHRvcnMgKEJHUCByb3V0ZXItSUQsIEFTTik6IDE5Mi4wLjIuMywg QVMxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsgbyZuYnNwOyBQZWVyIERlc2NyaXB0b3JzIChwZWVyIEJHUCByb3V0ZXItSUQsIHBlZXIgQVNO KTogMTkyLjAuMi40LCBBUzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IExpbmsgRGVzY3JpcHRvcnMgKElQIGludGVyZmFjZSBh ZGRyZXNzLCBuZWlnaGJvciBJUCBhZGRyZXNzKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMDE6ZGI4OmNkOjpjLCAyMDAxOmRiODpjZDo6ZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IEF0dHJp YnV0ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsgbyZuYnNwOyBQZWVyTm9kZSBTSUQ6IDEwMTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCcPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db21tZW50cyZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+LSBTZWN0aW9uIDUuMSBpbiBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdt ZW50LXJvdXRpbmctZXBlIHVzZXMg4oCcTG9jYWwgTm9kZSBEZXNjcmlwdG9y4oCdIGluc3RlYWQg b2Ygc2ltcGx5IOKAnE5vZGUgRGVzY3JpcHRvcuKAnSwgYW5kIHRoZSBCR1AtTFMgSUQgaXMgbWlz c2luZyBhYm92ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBzL1BlZXIgRGVzY3JpcHRvcnMvUmVtb3Rl IE5vZGUgRGVzY3JpcHRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIFRoZSBMaW5rIERlc2NyaXB0b3Ig dXNlcyB0aGUgdGVybXMg4oCcSVB2NiBJbnRlcmZhY2UgQWRkcmVzc+KAnSBhbmQg4oCcSVB2NiBO ZWlnaGJvciBBZGRyZXNz4oCd4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gcy9BdHRyaWJ1dGVzL0xp bmsgQXR0cmlidXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDMuIFNlY3Rpb24gMy42LiAoRmFzdCBSZXJvdXRlIChG UlIpKTog4oCcQSBCR1AtRVBFIGVuYWJsZWQgYm9yZGVyIHJvdXRlciBNQVkgYWxsb2NhdGUgYSBG UlIgYmFja3VwIGVudHJ5IG9uIGEgcGVyIEJHUCBQZWVyaW5nIFNJRCBiYXNpcyAoYXNzdW1pbmcg aW50ZXItQVMgYWdyZWVtZW50IG9uIHRoZSBGUlIgc3RyYXRlZ3kvcG9saWN5KS7igJ0mbmJzcDsg V2h5IGlzIGFuDQog4oCcaW50ZXItQVMgYWdyZWVtZW504oCdIG5lZWRlZD8mbmJzcDsgRlJSIGlz IGEgbG9jYWwgZGVjaXNpb24sIGFuZCwgYXNzdW1pbmcgdGhhdCB0aGUgYm9yZGVyIHJvdXRlciBp cyBhdCB0aGUgZWRnZSBvZiB0aGUgU1IgZG9tYWlu4oCmd2h5IHdvdWxkIHRoZSBuZXh0IEFTIG5l ZWQgdG8gYWdyZWU/Jm5ic3A7IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDQu IFJlZmVyZW5jZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gUGxlYXNlIGFkZCBhIHJlZmVyZW5jZSBm b3IgQk1QIGFuZCBJUEZJWC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBQdXQgdGhlIHJlZmVyZW5jZSB0 byBCR1AtTFMgb24gZmlyc3QgbWVudGlvbiAoYW5kIG5vdCBqdXN0IHdheSBkb3duIGluIFNlY3Rp b24gOSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gUmVwbGFjZSB0aGUgcmVmZXJlbmNlIHRvIFJGQzMx MDcgd2l0aCBkcmFmdC1pZXRmLW1wbHMtcmZjMzEwN2JpcyDigJMgYW5kIGl0IGNhbiBiZSBtYWRl IEluZm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIFRoZSByZWZlcmVuY2UgdG8gUkZDNjI0 MSBzaG91bGQgYmUgSW5mb3JtYXRpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDUuIEZyb20gU2VjdGlvbiA5LiAo TWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9ucyk6IOKAnOKApnRoZSBhZHZlcnRpc2VtZW50IG9m IEVQRSBpbmZvcm1hdGlvbiBNVVNUIGNvbmZvcm0gdG8gc3RhbmRhcmQgQkdQIGFkdmVydGlzZW1l bnQgYW5kIHByb3BhZ2F0aW9uIHJ1bGVzIChpQkdQLCBlQkdQLCBSb3V0ZS1SZWZsZWN0b3JzLCBD b25mZWRlcmF0aW9ucyku4oCdJm5ic3A7DQogV2hhdCBkb2VzIHRoaXMgdGV4dCBtZWFuPyZuYnNw OyBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlcmXigJlzIG5vIGNoYW5nZSB0byBCR1AgdG8gYmUg YWJsZSB0byBpbnN0YW50aWF0ZSBFUEXigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OaXRzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TjEuIFRoZSBzZWNvbmQgcGFyYWdyYXBoIGlu IHRoZSBBYnN0cmFjdCBzZWVtcyB1bm5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk4yLiBQbGVhc2UgYXZvaWQgdXNpbmcg4oCcd2XigJ0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OMy4gU2VjdGlvbiA1LjIgc2Vl bXMgdG8gaW50cm9kdWNlIHRoaXMgbmV3IG5vdGF0aW9uOiDigJxJUCByb3V0ZSBMLzggc2V0IG5l eHQtaG9wIFQx4oCd4oCmIHBsZWFzZSBleHBsYWluLiZuYnNwOyBMLzggaXMg4oCcaGlkZGVu4oCd IGluIEZpZ3VyZSAxLCBhbmQgbm90IG9idmlvdXMgc2luY2UgaXQgbG9va3MgbGlrZSBhbiBJUHY0 IHByZWZpeCwgYnV0IHRoZSBleGFtcGxlcyBhcmUNCiBhbGwgSVB2Ni48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_90B793CCB081475EAC7189B5F575B303ciscocom_-- From nobody Thu Aug 31 13:40:10 2017 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 588ED13292C; Thu, 31 Aug 2017 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 E1dTAgqZy1md; Thu, 31 Aug 2017 13:40:07 -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 ED2B7132941; Thu, 31 Aug 2017 13:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21870; q=dns/txt; s=iport; t=1504212006; x=1505421606; h=from:to:cc:subject:date:message-id:mime-version; bh=n4CtsbX5igv72vM5WgFePclnTFh9h5DcETM+ANJew7Q=; b=JBBWwEVIDVz0KQHor3mqTqAoKyBEmn3o3tw4E7kn97bhrleAUpYYoIxS OL2F9tID0lbMdG4V6wMaQvnVx8QUQYxBmoI9dTgT95OmHwf5by/ftv/+J wwESGHFSsG9Vy0N3h2GfWvhJPHFk/Bb2yGQji7MWtZo+hQq2s1ZQI46qB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAAC2c6hZ/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEcjhCQHpJahT4OggSFRxyDdT8YAQIBAQEBAQEBax0LhUJ?= =?us-ascii?q?WEgEGFDACBDAXEAQOiVJkkiSdZoInJ4s2AQEBAQEBAQEBAQEBAQEBAQEBAR+DK?= =?us-ascii?q?oICgU6BYyuHOoNLMIIxBZgxiD4ClE+CE4VninSWRAEfOIENdxVbAYUFHIFnikG?= =?us-ascii?q?BDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,455,1498521600"; d="scan'208,217";a="288038575" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 20:40:02 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7VKe2DY029470 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 20:40:02 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 15:40:02 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 15:40:02 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-spring-segment-routing-msdc@ietf.org" CC: "bruno.decraene@orange.com" , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-segment-routing-msdc-05 Thread-Index: AQHTIplRaR1S1gVL90eoIjw7WKwTtQ== Date: Thu, 31 Aug 2017 20:40:01 +0000 Message-ID: <3822F955-321A-4B53-AAB6-1628811E32B8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.225.239] Content-Type: multipart/alternative; boundary="_000_3822F955321A4B53AAB61628811E32B8ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [spring] AD Review of draft-ietf-spring-segment-routing-msdc-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:40:09 -0000 --_000_3822F955321A4B53AAB61628811E32B8ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpJIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRvY3VtZW50LiAg VGhhbmtzIGZvciBhIGNsZWFyIGFuZCBzdHJhaWdodCBmb3J3YXJkIGRyYWZ0IQ0KDQpJIGhhdmUg c29tZSBjb21tZW50cyAoc2VlIGJlbG93KS4gIFRoZSBtYWluIG9uZSBpcyBhYm91dCB0aGUgaW5j bHVzaW9uIG9mIGhvc3RzIGFzIGRlZmluaW5nIHRoZSBzb3VyY2Ugcm91dGVkIHBhdGgsIHdpdGhv dXQgdGhlbSBiZWluZyBleHBsaWNpdGx5IGNhbGxlZCBvdXQgaW4gdGhlIGRyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy4gIEtub3dpbmcgdGhhdCBzb21lIG9mIHRoZSBhdXRob3JzIG92 ZXJsYXAsIHBsZWFzZSBtYWtlIHN1cmUgdGhlcmUgYXJlIG5vIGhvbGVzIGluIHRoZSBBcmNoaXRl Y3R1cmUuICBJIHdpbGwgc3RhcnQgdGhlIElFVEYgTEMgb25jZSB0aGlzIGl0ZW0gaXMgYWRkcmVz c2VkLCBhbmQgYSByZXZpc2VkIElEIGlzIHByb2R1Y2VkIGRvIGFkZHJlc3MgdGhlIG90aGVyIGNv bW1lbnRzLCBhcyBuZWVkZWQuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCk1ham9yOg0KDQpN MS4gQXMgd2l0aCBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUs IGl0IHdvcnJpZXMgbWUgdGhhdCBob3N0cyBhcmUgY2FsbGVkIG91dCBhcyBiZWluZyBhYmxlIHRv IGRlZmluZSB0aGUgc291cmNlIHJvdXRlZCBwYXRoLiAgUGxlYXNlIG1ha2Ugc3VyZSB0aGF0IHRo ZSBBcmNoaXRlY3R1cmUgZG9jdW1lbnQgaGFzIHNvbWUgdGV4dCBhYm91dCB0aGUgdXNlIG9mIGhv c3RzIOKAkyBtYXliZSBjb25zdHJhaW5lZCB0byB0aGUgY2FzZSB3aGVyZSB0aGUgaG9zdHMgY2Fu IGJlIHByb2dyYW1tZWQuICBTZWN0aW9uIDYgcHJvdmlkZXMgc29tZSBnb29kIHRleHQgZm9yIHRo YXQuDQoNCg0KTWlub3I6DQoNClAxLiDigJxzZXJ2aWNlIGNoYWlu4oCdOiBwbGVhc2UgcmVtb3Zl IHRvIGF2b2lkIGNvbmZ1c2lvbiB3aXRoIFNGQyAoc2FtZSBjb21tZW50IGFzIGZvciBhbGwgdGhl IFNSIGRvY3VtZW50cykuDQoNClAyLiBSZWZlcmVuY2VzOg0KLSBzL3JmYzMxMDcvZHJhZnQtaWV0 Zi1tcGxzLXJmYzMxMDdiaXMNCi0gVGhlIHJlZmVyZW5jZXMgdG8gSS1ELmlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZy1jZW50cmFsLWVwZSBhbmQgcmZjNzkzOCBzaG91bGQgYmUgTm9ybWF0aXZl Lg0KDQpQMy4gVGhlcmUgYXJlIDIgaW5zdGFuY2VzIG9mIHVzaW5nIHJmYzIxMTkgbGFuZ3VhZ2Us IEkgZG9u4oCZdCB0aGluayB0aGF0IGVpdGhlciBpcyBuZWVkZWQgYmVjYXVzZSB5b3XigJlyZSBy ZWFsbHkgcGFyYXBocmFzaW5nIG90aGVyIGRvY3VtZW50cy4gIElPVywgSSByZWNvbW1lbmQgeW91 IHRha2UgdGhlIE5vcm1hdGl2ZSBsYW5ndWFnZSBvZmYuDQoNClAzLjEuIFNlY3Rpb24gNC4yLjEu IChDb250cm9sIFBsYW5lKTog4oCcVGhlIGltcGxpY2l0LW51bGwgbGFiZWwgaW4gdGhlIE5MUkkg dGVsbHMgTm9kZTEwIHRoYXQgaXQgaXMgdGhlIHBlbnVsdGltYXRlIGhvcCBhbmQgTVVTVCBwb3Ag dGhlIHRvcCBsYWJlbOKApuKAnSAgVGhpcyBpcyBub3JtYWwgTVBMUyBvcGVyYXRpb24sIHNvIHRo ZSBNVVNUIGlzIHJlYWxseSBub3QgaW50cm9kdWNpbmcgYW55dGhpbmcgbmV3LCBqdXN0IHBhcmFw aHJhc2luZyB0aGUgTVBMUyBhcmNoaXRlY3R1cmUuICBJbnN0ZWFkIG9mIHRoZSBNVVNULCBhIHJl ZmVyZW5jZSB0byBNUExTIHdvdWxkIGJlIG1vcmUgdGhhbiBlbm91Z2guICBzL01VU1QvbXVzdA0K DQpQMy4yLiBTZWN0aW9uIDExLiAoTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9ucyk6IOKAnEFz IHJlY29tbWVuZGVkIGluIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nXSwgdGhlIHNh bWUgU1JHQiBTSE9VTEQgYmUgYWxsb2NhdGVkIGluIGFsbCBub2Rlc+KApuKAnSAgIFRoZSBBcmNo aXRlY3R1cmUgZG9jdW1lbnQgZG9lc27igJl0ICh5ZXQpIG1ha2UgdGhhdCByZWNvbW1lbmRhdGlv biBleHBsaWNpdGx5LCBidXQgYSBwb2ludGVyIHRvIGl0IHNob3VsZCBiZSBlbm91Z2guICBzL1NI T1VMRC9zaG91bGQNCg0KUDQuIFNlY3Rpb24gNC4yLjQuIChHbG9iYWwgQkdQIFByZWZpeCBTZWdt ZW50IHRocm91Z2ggdGhlIGZhYnJpYyk6IOKAnOKApmEgcGFja2V0IHdpdGggdG9wIGxhYmVsIDE2 MDExIHJlY2VpdmVkIGJ5IGFueSBub2RlIGluIHRoZSBmYWJyaWPigKZhbmQgdGhlIGxhYmVsIDE2 MDExIGlzIHBlbnVsdGltYXRlLXBvcHBlZCBhdCBOb2RlMTDigJ0sIG9yIGF0IE5vZGU5LCByaWdo dD8NCg0KUDUuIFNlY3Rpb24gNC4zOiDigJzigKZhbmQgd2l0aCB0aGUgQkdQLVByZWZpeC1TSUQg YXR0cmlidXRlIGV4dGVuc2lvbiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnTigJ07IHRoYXQgd2Fz IG5vdCBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNClA2LiBTZWN0aW9uIDQuMy4gKGlCR1Ag TGFiZWxlZCBVbmljYXN0IChSRkMzMTA3KSkgY29udGFpbnMgdGhpcyB0ZXh0OiDigJxBSUdQIG1l dHJpYyAoW1JGQzczMTFdKSBpcyBsaWtlbHkgYXBwbGllZCB0byB0aGUgQkdQLVByZWZpeC1TSUQg YXMgcGFydCBvZiBhIGxhcmdlLXNjYWxlIG11bHRpLWRvbWFpbiBkZXNpZ24gc3VjaCBhcyBTZWFt bGVzcyBNUExTIFtJLUQuaWV0Zi1tcGxzLXNlYW1sZXNzLW1wbHNdLuKAnCAgVGhpcyBwYXJhZ3Jh cGggc291bmRzIHJhbmRvbSB0byBtZSBhcyB0aGVyZSBpcyBubyBmdXJ0aGVyIGV4cGxhbmF0aW9u IG9mIHRoZSB1c2UsIGltcGFjdCwgYWR2YW50YWdlcywgZXRjLiAgTmVpdGhlciBBSUdQL1NlYW1s ZXNzIE1QTFMgaXMgbWVudGlvbmVkIGFnYWluIGluIHRoZSBkb2N1bWVudCwgbm9yIGluIGRyYWZ0 LWlldGYtaWRyLWJncC1wcmVmaXgtc2lkIG9yIHJmYzc5MzguICBQbGVhc2UgZWl0aGVyIGV4cGFu ZCB0aGUgY29uY2VwdHMvdXNlIG9yIGRlbGV0ZSB0aGlzIHBhcmFncmFwaC4NCg0KUDcuIFNlY3Rp b24gNS4gKEFwcGx5aW5nIFNlZ21lbnQgUm91dGluZyBpbiB0aGUgREMgd2l0aCBJUHY2IGRhdGFw bGFuZSk6IOKAnE5vZGU1IG9yaWdpbmF0ZXMgMjAwMTpEQjg6OjUvMTI4IHdpdGggdGhlIGF0dGFj aGVkIEJHUC1QcmVmaXgtU0lEIGFkdmVydGlzaW5nIHRoZSBzdXBwb3J0IG9mIHRoZSBTZWdtZW50 IFJvdXRpbmcgZXh0ZW5zaW9uIGhlYWRlciAoU1JILCBbSS1ELmlldGYtNm1hbi1zZWdtZW50LXJv dXRpbmctaGVhZGVyXSnigKbigJ0gICBkcmFmdC1pZXRmLWlkci1iZ3AtcHJlZml4LXNpZCBzYXlz IG5vdGhpbmcgZXhwbGljaXRseSBhYm91dCB0aGUgQkdQLVByZWZpeC1TSUQgQXR0cmlidXRlIGFk dmVydGlzaW5nIHN1cHBvcnQgZm9yIHRoZSBTUkgg4oCTIG1heWJlIGl0IHNob3VsZCwgYnV0IGl0 IGRvZXNu4oCZdC4NCg0KTkVXPg0KICAgTm9kZTUgb3JpZ2luYXRlcyAyMDAxOkRCODo6NS8xMjgg d2l0aCB0aGUgYXR0YWNoZWQgQkdQLVByZWZpeC1TSUQNCiAgZm9yIElQdjYgcGFja2V0cyBkZXN0 aW5lZCB0bw0KICAgc2VnbWVudCAyMDAxOkRCODo6NSAoW0ktRC5pZXRmLWlkci1iZ3AtcHJlZml4 LXNpZF0pLg0KDQpJbnN0ZWFkLCBwdXQgdGhlIHJlZmVyZW5jZSBsYXRlciBpbiB0aGUgc2FtZSBz ZWN0aW9uIHdoZXJlIGl0IHNheXMg4oCc4oCmc2VuZGluZyBJUHY2IHBhY2tldHMgd2l0aCBhIFNS SCBleHRlbnNpb24gaGVhZGVy4oCm4oCdLg0KDQoNCk5pdHM6DQoNCk4xLiBzL0JHUDQvQkdQLTQN Cg0KTjIuIFNlY3Rpb24gMzog4oCcRnVydGhlciBpbiB0aGlzIGRvY3VtZW504oCm4oCdICBBIHJl ZmVyZW5jZSB0byBTZWN0aW9uIDcgd291bGQgYmUgbmljZS4NCg0KTjMuIHMvaW5kZXgxMSkvaW5k ZXgxMQ0KDQpONC4gSXQgd291bGQgaGF2ZSBiZWVuIG5pY2UgdG8gaWxsdXN0cmF0ZSB0aGUgb3Bl cmF0aW9uIGluIDQuMi54IHVzaW5nIElQdjYgYWRkcmVzc2VzLg0KDQpONS4gVGhyb3VnaG91dCBt b3N0IG9mIHRoZSBkb2N1bWVudCB0aGUgbm9kZXMgYXJlIHJlZmVycmVkIHRvIGFzIE5vZGV4LCBi dXQgdGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNlcyB3aGVyZSBUb3J4IGlzIHVzZWQuICBFdmVu IHRob3VnaCB0aGVzZSBub2RlcyBoYXZlIGJlZW4gaWRlbnRpZmllZCBhcyBUb1JzLCBpdCB3b3Vs ZCBiZSBuaWNlIHRvIGJlIGNvbnNpc3RlbnQgdG8gYXZvaWQgY29uZnVzaW9uLg0KDQpONi4gU2Vj dGlvbiA3OiBzL3Byb2JsZW1zIGRlc2NyaWJlIGFib3ZlL3Byb2JsZW1zIGRlc2NyaWJlZCBhYm92 ZSAgIEFsc28sIHB1dHRpbmcgYSByZWZlcmVuY2UgYmFjayB0byBTZWN0aW9uIDMgd291bGQgYmUg bmljZS4NCg0KTjcuIFRoZSBjb250ZW50IGluIFNlY3Rpb24gNyBpcyBnb29kLCBhbmQgdGhlIERD IGV4YW1wbGUgaGVscHMgaW4gdGhlIGlsbHVzdHJhdGlvbiDigJMgYnV0IHRoZSBhcHBsaWNhYmls aXR5IGlzIG5vdCBqdXN0IGNvbnN0cmFpbmVkIHRvIGl0LiAgSXQgbWlnaHQgYmUgYSBnb29kIGlk ZWEgdG8gYWRkIGF0IG5vdGUgYXQgdGhlIHN0YXJ0IG1lbnRpb25pbmcgdGhlIGJyb2FkZXIgYXBw bGljYWJpbGl0eS4NCg0KTjguIFBsZWFzZSBhdm9pZCB1c2luZyDigJx3ZeKAnS4NCg== --_000_3822F955321A4B53AAB61628811E32B8ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <19DD8E2E453FAE4F981F016B15797D39@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLm1z b0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+RGVhciBhdXRob3JzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSBqdXN0IGZpbmlzaGVkIHJlYWRpbmcgdGhpcyBkb2N1bWVudC4m bmJzcDsgVGhhbmtzIGZvciBhIGNsZWFyIGFuZCBzdHJhaWdodCBmb3J3YXJkIGRyYWZ0ITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBoYXZlIHNvbWUgY29tbWVu dHMgKHNlZSBiZWxvdykuJm5ic3A7IFRoZSBtYWluIG9uZSBpcyBhYm91dCB0aGUgaW5jbHVzaW9u IG9mIGhvc3RzIGFzIGRlZmluaW5nIHRoZSBzb3VyY2Ugcm91dGVkIHBhdGgsIHdpdGhvdXQgdGhl bSBiZWluZyBleHBsaWNpdGx5IGNhbGxlZCBvdXQgaW4gdGhlIGRyYWZ0LWlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZy4mbmJzcDsgS25vd2luZw0KIHRoYXQgc29tZSBvZiB0aGUgYXV0aG9ycyBv dmVybGFwLCBwbGVhc2UgbWFrZSBzdXJlIHRoZXJlIGFyZSBubyBob2xlcyBpbiB0aGUgQXJjaGl0 ZWN0dXJlLiZuYnNwOyBJIHdpbGwgc3RhcnQgdGhlIElFVEYgTEMgb25jZSB0aGlzIGl0ZW0gaXMg YWRkcmVzc2VkLCBhbmQgYSByZXZpc2VkIElEIGlzIHByb2R1Y2VkIGRvIGFkZHJlc3MgdGhlIG90 aGVyIGNvbW1lbnRzLCBhcyBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+TWFqb3I6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5NMS4gQXMgd2l0aCBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmctY2VudHJhbC1lcGUsIGl0IHdvcnJpZXMgbWUgdGhhdCBob3N0cyBhcmUgY2FsbGVkIG91 dCBhcyBiZWluZyBhYmxlIHRvIGRlZmluZSB0aGUgc291cmNlIHJvdXRlZCBwYXRoLiZuYnNwOyBQ bGVhc2UgbWFrZSBzdXJlIHRoYXQgdGhlIEFyY2hpdGVjdHVyZSBkb2N1bWVudCBoYXMgc29tZQ0K IHRleHQgYWJvdXQgdGhlIHVzZSBvZiBob3N0cyDigJMgbWF5YmUgY29uc3RyYWluZWQgdG8gdGhl IGNhc2Ugd2hlcmUgdGhlIGhvc3RzIGNhbiBiZSBwcm9ncmFtbWVkLiZuYnNwOyBTZWN0aW9uIDYg cHJvdmlkZXMgc29tZSBnb29kIHRleHQgZm9yIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TWlub3I6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMS4g4oCcc2VydmljZSBjaGFp buKAnTogcGxlYXNlIHJlbW92ZSB0byBhdm9pZCBjb25mdXNpb24gd2l0aCBTRkMgKHNhbWUgY29t bWVudCBhcyBmb3IgYWxsIHRoZSBTUiBkb2N1bWVudHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UDIuIFJlZmVyZW5jZXM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0g cy9yZmMzMTA3L2RyYWZ0LWlldGYtbXBscy1yZmMzMTA3YmlzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0g VGhlIHJlZmVyZW5jZXMgdG8gSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFs LWVwZSBhbmQgcmZjNzkzOCBzaG91bGQgYmUgTm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDMuIFRoZXJlIGFyZSAyIGluc3RhbmNlcyBvZiB1c2lu ZyByZmMyMTE5IGxhbmd1YWdlLCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBlaXRoZXIgaXMgbmVlZGVk IGJlY2F1c2UgeW914oCZcmUgcmVhbGx5IHBhcmFwaHJhc2luZyBvdGhlciBkb2N1bWVudHMuJm5i c3A7IElPVywgSSByZWNvbW1lbmQgeW91IHRha2UgdGhlIE5vcm1hdGl2ZSBsYW5ndWFnZSBvZmYu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMy4xLiBTZWN0aW9u IDQuMi4xLiAoQ29udHJvbCBQbGFuZSk6IOKAnFRoZSBpbXBsaWNpdC1udWxsIGxhYmVsIGluIHRo ZSBOTFJJIHRlbGxzIE5vZGUxMCB0aGF0IGl0IGlzIHRoZSBwZW51bHRpbWF0ZSBob3AgYW5kIE1V U1QgcG9wIHRoZSB0b3AgbGFiZWzigKbigJ0mbmJzcDsgVGhpcyBpcyBub3JtYWwgTVBMUyBvcGVy YXRpb24sIHNvIHRoZSBNVVNUIGlzIHJlYWxseSBub3QNCiBpbnRyb2R1Y2luZyBhbnl0aGluZyBu ZXcsIGp1c3QgcGFyYXBocmFzaW5nIHRoZSBNUExTIGFyY2hpdGVjdHVyZS4mbmJzcDsgSW5zdGVh ZCBvZiB0aGUgTVVTVCwgYSByZWZlcmVuY2UgdG8gTVBMUyB3b3VsZCBiZSBtb3JlIHRoYW4gZW5v dWdoLiZuYnNwOyBzL01VU1QvbXVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UDMuMi4gU2VjdGlvbiAxMS4gKE1hbmFnZWFiaWxpdHkgQ29uc2lkZXJhdGlvbnMp OiDigJxBcyByZWNvbW1lbmRlZCBpbiBbSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ10s IHRoZSBzYW1lIFNSR0IgU0hPVUxEIGJlIGFsbG9jYXRlZCBpbiBhbGwgbm9kZXPigKbigJ0mbmJz cDsmbmJzcDsgVGhlIEFyY2hpdGVjdHVyZSBkb2N1bWVudCBkb2VzbuKAmXQgKHlldCkgbWFrZSB0 aGF0DQogcmVjb21tZW5kYXRpb24gZXhwbGljaXRseSwgYnV0IGEgcG9pbnRlciB0byBpdCBzaG91 bGQgYmUgZW5vdWdoLiZuYnNwOyBzL1NIT1VMRC9zaG91bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA0LiBTZWN0aW9uIDQuMi40LiAoR2xvYmFsIEJHUCBQcmVm aXggU2VnbWVudCB0aHJvdWdoIHRoZSBmYWJyaWMpOiDigJzigKZhIHBhY2tldCB3aXRoIHRvcCBs YWJlbCAxNjAxMSByZWNlaXZlZCBieSBhbnkgbm9kZSBpbiB0aGUgZmFicmlj4oCmYW5kIHRoZSBs YWJlbCAxNjAxMSBpcyBwZW51bHRpbWF0ZS1wb3BwZWQgYXQgTm9kZTEw4oCdLCBvciBhdCBOb2Rl OSwgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QNS4g U2VjdGlvbiA0LjM6IOKAnOKApmFuZCB3aXRoIHRoZSBCR1AtUHJlZml4LVNJRCBhdHRyaWJ1dGUg ZXh0ZW5zaW9uIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudOKAnTsgdGhhdCB3YXMgbm90IGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlA2LiBTZWN0aW9uIDQuMy4gKGlCR1AgTGFiZWxlZCBVbmljYXN0IChSRkMzMTA3KSkg Y29udGFpbnMgdGhpcyB0ZXh0OiDigJxBSUdQIG1ldHJpYyAoW1JGQzczMTFdKSBpcyBsaWtlbHkg YXBwbGllZCB0byB0aGUgQkdQLVByZWZpeC1TSUQgYXMgcGFydCBvZiBhIGxhcmdlLXNjYWxlIG11 bHRpLWRvbWFpbiBkZXNpZ24gc3VjaCBhcyBTZWFtbGVzcyBNUExTIFtJLUQuaWV0Zi1tcGxzLXNl YW1sZXNzLW1wbHNdLuKAnCZuYnNwOw0KIFRoaXMgcGFyYWdyYXBoIHNvdW5kcyByYW5kb20gdG8g bWUgYXMgdGhlcmUgaXMgbm8gZnVydGhlciBleHBsYW5hdGlvbiBvZiB0aGUgdXNlLCBpbXBhY3Qs IGFkdmFudGFnZXMsIGV0Yy4mbmJzcDsgTmVpdGhlciBBSUdQL1NlYW1sZXNzIE1QTFMgaXMgbWVu dGlvbmVkIGFnYWluIGluIHRoZSBkb2N1bWVudCwgbm9yIGluIGRyYWZ0LWlldGYtaWRyLWJncC1w cmVmaXgtc2lkIG9yIHJmYzc5MzguJm5ic3A7IFBsZWFzZSBlaXRoZXIgZXhwYW5kIHRoZSBjb25j ZXB0cy91c2UNCiBvciBkZWxldGUgdGhpcyBwYXJhZ3JhcGguPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QNy4gU2VjdGlvbiA1LiAoQXBwbHlpbmcgU2VnbWVudCBS b3V0aW5nIGluIHRoZSBEQyB3aXRoIElQdjYgZGF0YXBsYW5lKTog4oCcTm9kZTUgb3JpZ2luYXRl cyAyMDAxOkRCODo6NS8xMjggd2l0aCB0aGUgYXR0YWNoZWQgQkdQLVByZWZpeC1TSUQgYWR2ZXJ0 aXNpbmcgdGhlIHN1cHBvcnQgb2YgdGhlIFNlZ21lbnQgUm91dGluZyBleHRlbnNpb24gaGVhZGVy IChTUkgsDQogW0ktRC5pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcl0p4oCm4oCdJm5i c3A7ICZuYnNwO2RyYWZ0LWlldGYtaWRyLWJncC1wcmVmaXgtc2lkIHNheXMgbm90aGluZyBleHBs aWNpdGx5IGFib3V0IHRoZSBCR1AtUHJlZml4LVNJRCBBdHRyaWJ1dGUgYWR2ZXJ0aXNpbmcgc3Vw cG9ydCBmb3IgdGhlIFNSSCDigJMgbWF5YmUgaXQgc2hvdWxkLCBidXQgaXQgZG9lc27igJl0Lg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ORVcmZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBOb2RlNSBvcmlnaW5hdGVzIDIwMDE6REI4Ojo1LzEy OCB3aXRoIHRoZSBhdHRhY2hlZCBCR1AtUHJlZml4LVNJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDtmb3IgSVB2NiBwYWNrZXRzIGRlc3RpbmVkIHRvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyBzZWdtZW50IDIwMDE6REI4Ojo1IChbSS1ELmlldGYtaWRyLWJncC1wcmVmaXgt c2lkXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbnN0ZWFk LCBwdXQgdGhlIHJlZmVyZW5jZSBsYXRlciBpbiB0aGUgc2FtZSBzZWN0aW9uIHdoZXJlIGl0IHNh eXMg4oCc4oCmc2VuZGluZyBJUHY2IHBhY2tldHMgd2l0aCBhIFNSSCBleHRlbnNpb24gaGVhZGVy 4oCm4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk5pdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5OMS4gcy9CR1A0L0JHUC00PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5OMi4gU2VjdGlvbiAzOiDigJxGdXJ0aGVyIGluIHRoaXMgZG9jdW1lbnTi gKbigJ0mbmJzcDsgQSByZWZlcmVuY2UgdG8gU2VjdGlvbiA3IHdvdWxkIGJlIG5pY2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OMy4gcy9pbmRleDExKS9pbmRl eDExPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ONC4gSXQgd291 bGQgaGF2ZSBiZWVuIG5pY2UgdG8gaWxsdXN0cmF0ZSB0aGUgb3BlcmF0aW9uIGluIDQuMi54IHVz aW5nIElQdjYgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TjUuIFRocm91Z2hvdXQgbW9zdCBvZiB0aGUgZG9jdW1lbnQgdGhlIG5vZGVzIGFyZSBy ZWZlcnJlZCB0byBhcyBOb2RleCwgYnV0IHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBwbGFjZXMgd2hl cmUgVG9yeCBpcyB1c2VkLiZuYnNwOyBFdmVuIHRob3VnaCB0aGVzZSBub2RlcyBoYXZlIGJlZW4g aWRlbnRpZmllZCBhcyBUb1JzLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGJlIGNvbnNpc3RlbnQNCiB0 byBhdm9pZCBjb25mdXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5ONi4gU2VjdGlvbiA3OiBzL3Byb2JsZW1zIGRlc2NyaWJlIGFib3ZlL3Byb2JsZW1zIGRl c2NyaWJlZCBhYm92ZSAmbmJzcDsmbmJzcDtBbHNvLCBwdXR0aW5nIGEgcmVmZXJlbmNlIGJhY2sg dG8gU2VjdGlvbiAzIHdvdWxkIGJlIG5pY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5ONy4gVGhlIGNvbnRlbnQgaW4gU2VjdGlvbiA3IGlzIGdvb2QsIGFuZCB0 aGUgREMgZXhhbXBsZSBoZWxwcyBpbiB0aGUgaWxsdXN0cmF0aW9uIOKAkyBidXQgdGhlIGFwcGxp Y2FiaWxpdHkgaXMgbm90IGp1c3QgY29uc3RyYWluZWQgdG8gaXQuJm5ic3A7IEl0IG1pZ2h0IGJl IGEgZ29vZCBpZGVhIHRvIGFkZCBhdCBub3RlIGF0IHRoZSBzdGFydCBtZW50aW9uaW5nIHRoZQ0K IGJyb2FkZXIgYXBwbGljYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPk44LiBQbGVhc2UgYXZvaWQgdXNpbmcg4oCcd2XigJ0uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3822F955321A4B53AAB61628811E32B8ciscocom_-- From nobody Thu Aug 31 14:15:25 2017 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 B48B21321C7; Thu, 31 Aug 2017 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aa52gmnT1FFI; Thu, 31 Aug 2017 14:15:20 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 C0CD11321AA; Thu, 31 Aug 2017 14:15:16 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 187so4887041wmn.1; Thu, 31 Aug 2017 14:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m+2sKqqSD3G+5yqNxyQmMY7CjHxiCyV98s6ASKhdLMo=; b=p5tKRAUJ7x0I5cWiADIClcVDaXCyDcKdLj7/BlSyWVxZfKoC9UlRtHfxVODXFTC4ic 3rqdxx66GR+r2OfJSPx/8rIMx8U9aLAof/qwlzWo0aeZZ0URM8vdmjWMA2PXl2IfLtMZ piACcMQu7T9ZAAsfN5DarzWCtqvC6vTyD/mTVH1QyOikuFoW43rg302UQCZu+mtIM1a5 Ym1E+dQiZPBqD5oVmxiazp7rlYnAvW290rTO2mpJhSGgiKQh1IqkU/oybP8Tdqa2gtDY 6gdSetmNXLv/g9IFEYvOIMSMPRAorY2aIqmTdtFpqGsTsX9qvlUn/JVZUd2gw+2e/BvH Y1kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m+2sKqqSD3G+5yqNxyQmMY7CjHxiCyV98s6ASKhdLMo=; b=tKx0BmJeiieiwlMlcdi2cJs8vILeIm0Oe3lopUESFsxTkH/vF7aCh7o+Wy7xY0xnDh vcHtQAJ/krTQIjp/iIeQX77HHO2U8pWWkX7M+54+wzMRhVt2qTu/MgdebH1gPYHjZa5q ApLcdIvsRn3oN60VLCJC73GctrhfGDfiBSdhyyE6NkHGKXS4F/enFj6AJLh/q5dNk//x Fe8YOKxF0WAARwHvdUZv4TtEgDc3VDRkVRlUTspNizreJHRbDGzYi9VGvdUyX+ZmJdFM D1Y/bajsUkPzaWbGAilpCtBS76oKCArYalvRZhvVZk5eLehtc8X/rrEMDID6ANNekzUB QIGA== X-Gm-Message-State: AHYfb5juK4Z7mpcbRnzXSo5j6CAsPJxQQ7HWOeFatYJOJ8NuRvsBNGMM rJn7OmDhsbJ3b0KBHynXvX60MIv6sQ== X-Google-Smtp-Source: ADKCNb6AB2sT7TLedCOkjGjxbIOVLylej52q7jdtXPcuTJo6GjTkQTpEm1kicUVVvee+RwRiMF5j8aS+Gh9Ssg9vMM4= X-Received: by 10.28.101.139 with SMTP id z133mr1231698wmb.32.1504214115049; Thu, 31 Aug 2017 14:15:15 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.170.199 with HTTP; Thu, 31 Aug 2017 14:15:14 -0700 (PDT) Received: by 10.28.170.199 with HTTP; Thu, 31 Aug 2017 14:15:14 -0700 (PDT) In-Reply-To: References: <3822F955-321A-4B53-AAB6-1628811E32B8@cisco.com> From: Robert Raszuk Date: Thu, 31 Aug 2017 23:15:14 +0200 X-Google-Sender-Auth: BheYlfdbALBMKO7uP87bNpIOA8o Message-ID: To: "Alvaro Retana (aretana)" Cc: bruno.decraene@orange.com, spring-chairs@ietf.org, draft-ietf-spring-segment-routing-msdc@ietf.org, spring@ietf.org Content-Type: multipart/alternative; boundary="001a114b315afe687005581323ac" Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-msdc-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 21:15:23 -0000 --001a114b315afe687005581323ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Please observe that in overlay networking it is reall hosts how can compute required path or exit gateway and apply it to packets. Think about Contrail or Nuage. It is also not about "programming hosts to apply a header" it is hosts itself determine based on the local application needs what the header is. This is naturally applicable to msdc. The times where the network nodes only do networking are long time gone. Best, R. On Aug 31, 2017 22:40, "Alvaro Retana (aretana)" wrote: Dear authors: I just finished reading this document. Thanks for a clear and straight forward draft! I have some comments (see below). The main one is about the inclusion of hosts as defining the source routed path, without them being explicitly called out in the draft-ietf-spring-segment-routing. Knowing that some of the authors overlap, please make sure there are no holes in the Architecture. I will start the IETF LC once this item is addressed, and a revised ID is produced do address the other comments, as needed. Thanks! Alvaro. Major: M1. As with draft-ietf-spring-segment-routing-central-epe, it worries me that hosts are called out as being able to define the source routed path. Please make sure that the Architecture document has some text about the use of hosts =E2=80=93 maybe constrained to the case where the hosts can be programmed. Section 6 provides some good text for that. Minor: P1. =E2=80=9Cservice chain=E2=80=9D: please remove to avoid confusion with = SFC (same comment as for all the SR documents). P2. References: - s/rfc3107/draft-ietf-mpls-rfc3107bis - The references to I-D.ietf-spring-segment-routing-central-epe and rfc7938 should be Normative. P3. There are 2 instances of using rfc2119 language, I don=E2=80=99t think = that either is needed because you=E2=80=99re really paraphrasing other documents= . IOW, I recommend you take the Normative language off. P3.1. Section 4.2.1. (Control Plane): =E2=80=9CThe implicit-null label in t= he NLRI tells Node10 that it is the penultimate hop and MUST pop the top label=E2= =80=A6=E2=80=9D This is normal MPLS operation, so the MUST is really not introducing anything new, just paraphrasing the MPLS architecture. Instead of the MUST, a reference to MPLS would be more than enough. s/MUST/must P3.2. Section 11. (Manageability Considerations): =E2=80=9CAs recommended i= n [I-D.ietf-spring-segment-routing], the same SRGB SHOULD be allocated in all nodes=E2=80=A6=E2=80=9D The Architecture document doesn=E2=80=99t (yet) m= ake that recommendation explicitly, but a pointer to it should be enough. s/SHOULD/should P4. Section 4.2.4. (Global BGP Prefix Segment through the fabric): =E2=80= =9C=E2=80=A6a packet with top label 16011 received by any node in the fabric=E2=80=A6and = the label 16011 is penultimate-popped at Node10=E2=80=9D, or at Node9, right? P5. Section 4.3: =E2=80=9C=E2=80=A6and with the BGP-Prefix-SID attribute ex= tension defined in this document=E2=80=9D; that was not defined in this document. P6. Section 4.3. (iBGP Labeled Unicast (RFC3107)) contains this text: =E2= =80=9CAIGP metric ([RFC7311]) is likely applied to the BGP-Prefix-SID as part of a large-scale multi-domain design such as Seamless MPLS [I-D.ietf-mpls-seamless-mpls].=E2=80=9C This paragraph sounds random to me= as there is no further explanation of the use, impact, advantages, etc. Neither AIGP/Seamless MPLS is mentioned again in the document, nor in draft-ietf-idr-bgp-prefix-sid or rfc7938. Please either expand the concepts/use or delete this paragraph. P7. Section 5. (Applying Segment Routing in the DC with IPv6 dataplane): =E2=80=9CNode5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID advertising the support of the Segment Routing extension header (SRH, [I-D.ietf-6man-segment-routing-header])=E2=80=A6=E2=80=9D draft-ietf-idr-= bgp-prefix-sid says nothing explicitly about the BGP-Prefix-SID Attribute advertising support for the SRH =E2=80=93 maybe it should, but it doesn=E2=80=99t. NEW> Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID for IPv6 packets destined to segment 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]). Instead, put the reference later in the same section where it says =E2=80=9C=E2=80=A6sending IPv6 packets with a SRH extension header=E2=80=A6= =E2=80=9D. Nits: N1. s/BGP4/BGP-4 N2. Section 3: =E2=80=9CFurther in this document=E2=80=A6=E2=80=9D A refer= ence to Section 7 would be nice. N3. s/index11)/index11 N4. It would have been nice to illustrate the operation in 4.2.x using IPv6 addresses. N5. Throughout most of the document the nodes are referred to as Nodex, but there are a couple of places where Torx is used. Even though these nodes have been identified as ToRs, it would be nice to be consistent to avoid confusion. N6. Section 7: s/problems describe above/problems described above Also, putting a reference back to Section 3 would be nice. N7. The content in Section 7 is good, and the DC example helps in the illustration =E2=80=93 but the applicability is not just constrained to it.= It might be a good idea to add at note at the start mentioning the broader applicability. N8. Please avoid using =E2=80=9Cwe=E2=80=9D. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --001a114b315afe687005581323ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

P= lease observe that in overlay networking it is reall hosts how can compute = required path or exit gateway and apply it to packets. Think about Contrail= or Nuage.

It is also no= t about "programming hosts to apply a header" it is hosts itself = determine based on the local application needs what the header is. This is = naturally applicable to msdc.

The times where the network nodes only do networking are long time go= ne.

Best,
R.

On Aug 31, 2017 22:40, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Dear authors:

=C2=A0

I just finished rea= ding this document.=C2=A0 Thanks for a clear and straight forward draft!=

=C2=A0

I have some comment= s (see below).=C2=A0 The main one is about the inclusion of hosts as defini= ng the source routed path, without them being explicitly called out in the = draft-ietf-spring-segment-routing.=C2=A0 Knowing that some of the authors overlap, please make sure there are no holes in t= he Architecture.=C2=A0 I will start the IETF LC once this item is addressed= , and a revised ID is produced do address the other comments, as needed.=

=C2=A0

Thanks!

=C2=A0

Alvaro.

=C2=A0

=C2=A0

Major:

=C2=A0

M1. As with draft-i= etf-spring-segment-routing-central-epe, it worries me that hosts are c= alled out as being able to define the source routed path.=C2=A0 Please make= sure that the Architecture document has some text about the use of hosts =E2=80=93 maybe constrained to the case where = the hosts can be programmed.=C2=A0 Section 6 provides some good text for th= at.

=C2=A0

=C2=A0

Minor:

=C2=A0

P1. =E2=80=9Cservic= e chain=E2=80=9D: please remove to avoid confusion with SFC (same comment a= s for all the SR documents).

=C2=A0

P2. References:<= /u>

- s/rfc3107/draft-i= etf-mpls-rfc3107bis

- The references to= I-D.ietf-spring-segment-routing-central-epe and rfc7938 should be Nor= mative.

=C2=A0

P3. There are 2 ins= tances of using rfc2119 language, I don=E2=80=99t think that either is need= ed because you=E2=80=99re really paraphrasing other documents.=C2=A0 IOW, I= recommend you take the Normative language off.

=C2=A0

P3.1. Section 4.2.1= . (Control Plane): =E2=80=9CThe implicit-null label in the NLRI tells Node1= 0 that it is the penultimate hop and MUST pop the top label=E2=80=A6=E2=80= =9D=C2=A0 This is normal MPLS operation, so the MUST is really not introducing anything new, just paraphrasing the MPLS architecture.=C2=A0 I= nstead of the MUST, a reference to MPLS would be more than enough.=C2=A0 s/= MUST/must

=C2=A0

P3.2. Section 11. (= Manageability Considerations): =E2=80=9CAs recommended in [I-D.ietf-spring-= segment-routing], the same SRGB SHOULD be allocated in all nodes=E2=80= =A6=E2=80=9D=C2=A0=C2=A0 The Architecture document doesn=E2=80=99t (yet) ma= ke that recommendation explicitly, but a pointer to it should be enough.=C2=A0 s/S= HOULD/should

=C2=A0

P4. Section 4.2.4. = (Global BGP Prefix Segment through the fabric): =E2=80=9C=E2=80=A6a packet = with top label 16011 received by any node in the fabric=E2=80=A6and the lab= el 16011 is penultimate-popped at Node10=E2=80=9D, or at Node9, right?

=C2=A0

P5. Section 4.3: = =E2=80=9C=E2=80=A6and with the BGP-Prefix-SID attribute extension defined i= n this document=E2=80=9D; that was not defined in this document.<= /u>

=C2=A0

P6. Section 4.3. (i= BGP Labeled Unicast (RFC3107)) contains this text: =E2=80=9CAIGP metric ([R= FC7311]) is likely applied to the BGP-Prefix-SID as part of a large-scale m= ulti-domain design such as Seamless MPLS [I-D.ietf-mpls-seamless-mpls].=E2=80=9C=C2=A0 This paragraph sounds random to me as there is no further explanation of t= he use, impact, advantages, etc.=C2=A0 Neither AIGP/Seamless MPLS is mentio= ned again in the document, nor in draft-ietf-idr-bgp-prefix-sid or rfc7938.= =C2=A0 Please either expand the concepts/use or delete this paragraph.

=C2=A0

P7. Section 5. (App= lying Segment Routing in the DC with IPv6 dataplane): =E2=80=9CNode5 origin= ates 2001:DB8::5/128 with the attached BGP-Prefix-SID advertising the suppo= rt of the Segment Routing extension header (SRH, [I-D.ietf-6man-segment-routing-header])=E2=80=A6=E2=80=9D=C2=A0 =C2= =A0draft-ietf-idr-bgp-prefix-sid says nothing explicitly about the BGP-Pref= ix-SID Attribute advertising support for the SRH =E2=80=93 maybe it should,= but it doesn=E2=80=99t.

=C2=A0

NEW>

=C2=A0=C2=A0 Node5 = originates 2001:DB8::5/128 with the attached BGP-Prefix-SID

=C2=A0=C2=A0for IPv= 6 packets destined to

=C2=A0=C2=A0 segmen= t 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]).

=C2=A0

Instead, put the re= ference later in the same section where it says =E2=80=9C=E2=80=A6sending I= Pv6 packets with a SRH extension header=E2=80=A6=E2=80=9D.

=C2=A0

=C2=A0

Nits:=

=C2=A0

N1. s/BGP4/BGP-4=

=C2=A0

N2. Section 3: =E2= =80=9CFurther in this document=E2=80=A6=E2=80=9D=C2=A0 A reference to Secti= on 7 would be nice.

=C2=A0

N3. s/index11)/inde= x11

=C2=A0

N4. It would have b= een nice to illustrate the operation in 4.2.x using IPv6 addresses.<= u>

=C2=A0

N5. Throughout most= of the document the nodes are referred to as Nodex, but there are a couple= of places where Torx is used.=C2=A0 Even though these nodes have been iden= tified as ToRs, it would be nice to be consistent to avoid confusion.

=C2=A0

N6. Section 7: s/pr= oblems describe above/problems described above =C2=A0=C2=A0Also, putting a = reference back to Section 3 would be nice.

=C2=A0

N7. The content in = Section 7 is good, and the DC example helps in the illustration =E2=80=93 b= ut the applicability is not just constrained to it.=C2=A0 It might be a goo= d idea to add at note at the start mentioning the broader applicability.

=C2=A0

N8. Please avoid us= ing =E2=80=9Cwe=E2=80=9D.


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

--001a114b315afe687005581323ac-- From nobody Thu Aug 31 14:50:06 2017 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 50183132328; Thu, 31 Aug 2017 14:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 b8Znnw7l-P33; Thu, 31 Aug 2017 14:50:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9591321AA; Thu, 31 Aug 2017 14:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7194; q=dns/txt; s=iport; t=1504216203; x=1505425803; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1nT3ciyIA2Rv/JuvXvNNmYyaeF6HALv5wy3jNKc3Qro=; b=GwhC2FCRE9zbA6vfSHH+B/xfpcqX409pEibN8SKdj5QXd9W4Q6B6nnDO JBn8GfxX05Z01aGCA/Peo7WWUCi/S/PF8ieTDqhX92H2BNBIv6zMRm0S2 V9ogvWPgGiM9ekrcBehiSTHP5EbaASdPxQG4KUzes9NoG4MHNMFYdcKC3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAABsg6hZ/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEVB44QkB6BT4hbiDCFPoIShUcCGoN1PxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUZBiNWEAIBCBItAwICAh8RFAMOAgQOBYlNTAMVr3+CJyeHEg2EGgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2DKoICgU6CDguCcoJXhTEwgjEFmDGIAjwCj1mEdoI?= =?us-ascii?q?ThWeKdIxOiXYBHziBDXcVWwGHCHaJS4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,455,1498521600"; d="scan'208,217";a="293547514" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 21:50:02 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v7VLo25Y017885 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 21:50:02 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 16:50:01 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 16:50:01 -0500 From: "Alvaro Retana (aretana)" To: Robert Raszuk CC: "bruno.decraene@orange.com" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing-msdc@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] AD Review of draft-ietf-spring-segment-routing-msdc-05 Thread-Index: AQHTIp4/lbjU1rcIckyJLsBqY8MRC6Ke8DCA Date: Thu, 31 Aug 2017 21:50:01 +0000 Message-ID: References: <3822F955-321A-4B53-AAB6-1628811E32B8@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.225.239] Content-Type: multipart/alternative; boundary="_000_DEE34F25AA1E49168ED6F6D66AAF3F9Fciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-msdc-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 21:50:05 -0000 --_000_DEE34F25AA1E49168ED6F6D66AAF3F9Fciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0Og0KDQpJIHVuZGVyc3RhbmQuDQoNCk15IG1haW4gcG9pbnQgaXMgdGhhdCB0aGUgc3By aW5nIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzaG91bGQgY2xlYXJseSBtYWtlIHRoYXQgY2xlYXIu ICBSaWdodCBub3csIGl0IGlzIHJlYWxseSBlYXN5IHRvIGludGVycHJldCB0aGUgU1IgZG9tYWlu IGVuZGluZyBhdCB0aGUgcm91dGluZyBlZGdlIChub3QgdGhlIGhvc3RzKS4gIEFsc28sIHRoZSBh cmNoaXRlY3R1cmUgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIGhhdmUgdGhpcyBkaXNjdXNzaW9uLg0K DQpUaGFua3MhDQoNCkFsdmFyby4NCg0KT24gOC8zMS8xNywgMzoxNSBQTSwgInJyYXN6dWtAZ21h aWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6 dWsiIDxycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IG9uIGJlaGFs ZiBvZiByb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+PiB3cm90ZToN Cg0KUGxlYXNlIG9ic2VydmUgdGhhdCBpbiBvdmVybGF5IG5ldHdvcmtpbmcgaXQgaXMgcmVhbGwg aG9zdHMgaG93IGNhbiBjb21wdXRlIHJlcXVpcmVkIHBhdGggb3IgZXhpdCBnYXRld2F5IGFuZCBh cHBseSBpdCB0byBwYWNrZXRzLiBUaGluayBhYm91dCBDb250cmFpbCBvciBOdWFnZS4NCg0KSXQg aXMgYWxzbyBub3QgYWJvdXQgInByb2dyYW1taW5nIGhvc3RzIHRvIGFwcGx5IGEgaGVhZGVyIiBp dCBpcyBob3N0cyBpdHNlbGYgZGV0ZXJtaW5lIGJhc2VkIG9uIHRoZSBsb2NhbCBhcHBsaWNhdGlv biBuZWVkcyB3aGF0IHRoZSBoZWFkZXIgaXMuIFRoaXMgaXMgbmF0dXJhbGx5IGFwcGxpY2FibGUg dG8gbXNkYy4NCg0KVGhlIHRpbWVzIHdoZXJlIHRoZSBuZXR3b3JrIG5vZGVzIG9ubHkgZG8gbmV0 d29ya2luZyBhcmUgbG9uZyB0aW1lIGdvbmUuDQoNCg0KDQo= --_000_DEE34F25AA1E49168ED6F6D66AAF3F9Fciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4E30670C9385E44586D1DF0F8E40C82D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5v cm1hbDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28t c3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9iZXJ0OjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHVuZGVyc3RhbmQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IG1h aW4gcG9pbnQgaXMgdGhhdCB0aGUgc3ByaW5nIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzaG91bGQg Y2xlYXJseSBtYWtlIHRoYXQgY2xlYXIuJm5ic3A7IFJpZ2h0IG5vdywgaXQgaXMgcmVhbGx5IGVh c3kgdG8gaW50ZXJwcmV0IHRoZSBTUiBkb21haW4gZW5kaW5nIGF0IHRoZSByb3V0aW5nIGVkZ2Ug KG5vdCB0aGUgaG9zdHMpLiZuYnNwOyBBbHNvLCB0aGUgYXJjaGl0ZWN0dXJlIGlzIHRoZSByaWdo dCBwbGFjZSB0byBoYXZlDQogdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdmFyby48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA4LzMxLzE3LCAzOjE1IFBNLCAmcXVvdDs8YSBocmVm PSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iPnJyYXN6dWtAZ21haWwuY29tPC9hPiBvbiBiZWhh bGYgb2YgUm9iZXJ0IFJhc3p1ayZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWls dG86cm9iZXJ0QHJhc3p1ay5uZXQiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss c2VyaWY7Y29sb3I6YmxhY2siPlBsZWFzZSBvYnNlcnZlIHRoYXQgaW4gb3ZlcmxheSBuZXR3b3Jr aW5nIGl0IGlzIHJlYWxsIGhvc3RzIGhvdyBjYW4gY29tcHV0ZSByZXF1aXJlZCBwYXRoIG9yIGV4 aXQgZ2F0ZXdheSBhbmQgYXBwbHkgaXQgdG8gcGFja2V0cy4gVGhpbmsgYWJvdXQgQ29udHJhaWwg b3IgTnVhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5JdCBp cyBhbHNvIG5vdCBhYm91dCAmcXVvdDtwcm9ncmFtbWluZyBob3N0cyB0byBhcHBseSBhIGhlYWRl ciZxdW90OyBpdCBpcyBob3N0cyBpdHNlbGYgZGV0ZXJtaW5lIGJhc2VkIG9uIHRoZSBsb2NhbCBh cHBsaWNhdGlvbiBuZWVkcyB3aGF0IHRoZSBoZWFkZXIgaXMuIFRoaXMgaXMgbmF0dXJhbGx5IGFw cGxpY2FibGUNCiB0byBtc2RjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+VGhlIHRpbWVzIHdoZXJlIHRoZSBuZXR3b3JrIG5vZGVzIG9ubHkgZG8gbmV0d29ya2lu ZyBhcmUgbG9uZyB0aW1lIGdvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DEE34F25AA1E49168ED6F6D66AAF3F9Fciscocom_--