From nobody Sat Jan 2 05:09:01 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44EF1A002F; Sat, 2 Jan 2016 05:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJp2QIwv2hgV; Sat, 2 Jan 2016 05:08:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43DC1A002D; Sat, 2 Jan 2016 05:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41167; q=dns/txt; s=iport; t=1451740134; x=1452949734; h=from:to:cc:subject:date:message-id:mime-version; bh=NyjEKLGQ9JRhvT0LVRSmN2vqE8NkjahrjzAaTm/O8mw=; b=XgnOrg/l9SjfJ/kzfuqwthoIdzPYcnxaC/tD5pReq/H71MqXv+lE0gkU GHXTyBTgR5RJrpeSrdp03UjciotmuCD5fUR0xun61ZwSwr8XxCkXsmyix uFrupekL+yUNjcUD/fjtHcNMQ6zEGjJs/LcDlS4z3TWOAHGzrh1GUfQhU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfBQADy4dW/4oNJK1egm5MgUWIU7N9g?= =?us-ascii?q?WSGD4ESORMBAQEBAQEBfwuENwQaWgUSARobCwE/FxAEDiCIFL93AQEBAQYBAQE?= =?us-ascii?q?BAQEdhlYBiRsUZYQmBYVcjS6DfAGIMIJlgjuBXIRGiFmOOQEjAUCECoQ4QoEIA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos; i="5.20,512,1444694400"; d="scan'208,217"; a="62893654" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jan 2016 13:08:52 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u02D8q0R012208 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Jan 2016 13:08:52 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.1104.5; Sat, 2 Jan 2016 07:08:52 -0600 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.1104.009; Sat, 2 Jan 2016 07:08:52 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" Subject: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Topic: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Index: AQHRRV6597SzUW9co02T3uxhrwX4Hw== Date: Sat, 2 Jan 2016 13:08:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_D29F3CC9F4D4Aaretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 13:08:59 -0000 --_000_D29F3CC9F4D4Aaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! Happy New Year! I just finished reviewing this document. I have several comments (please s= ee below) that I want to see addressed before starting the IETF Last Call. Out of the items marked as Major, the one that concerns me the most is the = one related to Operations/Management Considerations. It is surprising to m= e that such extensive work in the Standards Track didn't have any Operation= s/Management (or even Security!) Considerations until the current version. = My comments below echo some of the opinions on the list, but I can't claim= that they are all inclusive. As I pointed out below, I am not looking for= a dissertation on the topic, but much more than what's there should be inc= luded. Thanks! Alvaro. Major: 1. In general, I feel uncomfortable with documents making value statemen= ts related, for example, to how they perform against different solutions. = The purpose of this document should be to describe the technology, not to c= ompare against other solutions =97 that work (if wanted/needed) should be d= one in a different document. Please remove comparisons to other technology= and relative statements. Some examples: * Abstract: "MRT is also extremely computationally efficient=85compu= tation is less than the LFA computation..." As was expressed on the list, = maybe CPU cycles are not that important if compared to other aspects=85 * Introduction: "Other existing or proposed solutions are partial so= lutions or have significant issues, as described below." It is ok to descr= ibe other solutions, but please limit the description to the facts. * About the table: there are obviously other columns that could h= ave been included, which means that the table is not complete. * Section 4: "Modeling results comparing the alternate path lengths = obtained with MRT to other approaches are described in [I-D.ietf-rtgwg-mrt-= frr-algorithm]." I am also including the corresponding comment in my revie= w of that other document. * Section 5: "is an advantage of using MRT" In this case, at least = a reference to Section 15. (Applying Policy to Select from Multiple Possibl= e Alternates for FRR) might be in order. 2. References to Extensions. This document being where the architecture= for MRT is defined should set the stage/define requirements for extensions= that are to be defined elsewhere, and not concern itself with the solution= s themselves. In other words, please remove references to where solutions = (in the form of extensions) are being specified. Some pointers: * All references to I-D.ietf-ospf-mrt, I-D.ietf-isis-mrt and I-D.iet= f-mpls-ldp-mrt, except maybe the ones in Section 13. (Implementation Status= ). * There are two places where it is mentioned that the capabilities t= o advertise additional loopbacks "have not been defined". * Section 7. (MRT Island Formation) starts by talking about the "pur= pose of communicating support for MRT in the IGP" which is the first time i= n the document that is mentioned. While distribution with an IGP may be th= e obvious mechanism, please describe the requirement. * Another example of the same occurs in Section 8.2. (Router-specifi= c MRT paramaters) where it says that "additional router-specific MRT parame= ters may need to be distributed via the IGP", when I think the requirement = is that these additional parameters need to be known by all routers in the = MRT Island. [Again, distribution using the IGP may be the obvious choice..] 3. Algorithm. draft-ietf-rtgwg-mrt-frr-algorithm says that it "defines = the=85algorithm that is used in the default MRT profile". Please make the = text in this document consistent with that when referring to draft-ietf-rtg= wg-mrt-frr-algorithm. Some descriptions used in the text: "the exact MRT a= lgorithm", "the algorithm to compute MRTs", "Example algorithm" 4. Operations/Management Considerations * Given that the MRT paths don't follow the shortest paths, or even = potentially planned backup paths in the network, I think you should include= something about the potential impact related to capacity planning, congest= ion, stretch, etc. * What about address management? Are there considerations about ass= ignment and management for the additional loopbacks required for IP tunnels= ? * Section 15. (Applying Policy to Select from Multiple Possible Alte= rnates for FRR) basically says that policy can be applied "to select the be= st alternate from those provided by MRT and other FRR technologies". You'r= e right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses man= y of the potential criteria that one might take into account when evaluatin= g different alternates for selection". What are the considerations that sh= ould be taken into account when comparing between MRT and others? Are the = criteria and requirements outlined in I-D.ietf-rtgwg-lfa-manageability appl= icable? Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA= -specific, should it be a Normative reference? [Note that there's a similar= comment related to I-D.ietf-rtgwg-lfa-manageability in my review of draft= -ietf-rtgwg-mrt-frr-algorithm.] * Applicability/Guidance for Operators * Section 4. (Maximally Redundant Trees (MRT)) clearly explains a= bout the impact of not having a 2-connected network for MRT to be applicabl= e. Section 11.3. (MRT Alternates for Destinations Outside the MRT Island) = talks about partial implementation in an area. * I think it would be important to consolidate some of that guida= nce (there's probably more) in a single place. Note that I'm not looking f= or a 30 page extension (a la RFC6571), just some general guidance. * Given that both Sections 14 and 15 were added just in the latest v= ersion of the document, please consider taking a look at RFC5706. * [Nit] Consider making Section 15. (Applying Policy to Select from = Multiple Possible Alternates for FRR) a sub-section of Section 14. (Operati= ons and Management Considerations). 5. MRT Profile Selection and Algorithm Transition: * From Section 7.2. (Support for a specific MRT profile): "All route= rs in an MRT Island MUST support the same MRT profile"=85and=85"A given rou= ter can support multiple MRT profiles and participate in multiple MRT Islan= ds.". If I understand this correctly, routers can support multiple MRT pro= files for the same area/level, right? If so, how do the routers in the are= a/level agree on which profile will be the one supported? * Also, Section 8.1. (MRT Profile Options) says that "If a router ad= vertises support for multiple MRT profiles, then it MUST create the transit= forwarding topologies for each=85" Are these multiple profiles inside the= same area/level? These two pieces of text don't seem to be in sync. [But= I may be missing something somewhere.] * MRT Algorithm Transition: How is it done? In Section 8.1. (MRT Pr= ofile Options) says that "Algorithm transitions can be managed by advertisi= ng multiple MRT profiles", but there's no explanation of how. This comment= is related to the one above about MRT Profile Selection. * [Minor] I may have missed this somewhere.. * The MRT MPLS MT-ID value is associated with the MRT profile, so= that (for example) the MRT-Red MPLS MT-ID for the default profile is 3997,= right? If so, how does one introduce a new profile? I'm guessing that by= registering new MT-ID values. * What happens if the MT-ID for the Red and Blue MRTs don't co= rrespond to the same profile? 6. Section 17. (IANA Considerations) talks about the "MRT Profile TLV", = which is not defined anywhere in this document. I think that asking for th= e registry creation is enough. 7. Section 18. (Security Considerations) Even though I don't think this= document should make explicit references to extensions, clearly there will= be a transport that needs to be secured: authentication, privacy, etc. 8. References: RFC2119 should be Normative. Minor: 1. Section 1. (Introduction) says that: "Once traffic has been moved to = one of MRTs, it is not subject to further repair actions. Thus, the traffic= will not loop even if a worse failure (e.g. node) occurs when protection w= as only available for a simpler failure (e.g. link)." I'm sure you mean th= at the worse failure occurs in the original topology (not in the MRT). Ple= ase clarify. 2. Multicast protection is out of scope, right? There's a reference to = I-D.atlas-rtgwg-mrt-mc-arch in the Introduction (which is fine), but not ex= plicit indication of the scope. Section 8.1. (MRT Profile Options) also ta= lks about multicast then describing "MRT Forwarding Mechanism" ("The None o= ption in may be useful for multicast global protection."). * In Section 8.1. (MRT Profile Options), is the "Area/Level Border B= ehavior" specific to multicast? BTW, please avoid describing the options w= ith questions. 3. Section 1.1. (Importance of 100% Coverage) talks about how micro-loop= prevention is something that can be achieved with complete coverage, and S= ection 12. (Network Convergence and Preparing for the Next Failure) says it= is something that needs attention after a failure, but then the document d= oesn't say how MRT can be used: the use of MRT (to support Farside Tunneli= ng) is declared out of scope, and an "orphan" statement (no references and = no solution) about micro-loop mitigation is made ("Micro-loop mitigation me= chanisms can also work when combined with MRT."). * Section 12.1. (Micro-forwarding loop prevention and MRTs) does say= that "Managing micro-loops is an orthogonal issue to having alternates for= local repair=85", but I think you need to explain some more about how micr= o-loops may not be an issue or how MRT helps. 4. Section 6.3. (Forwarding IP Unicast Traffic over MRT Paths) says that= , for IP forwarding "consistency with LDP is RECOMMENDED". Why? I'm guess= ing it might be simpler to be consistent if both LDP and IP traffic are bei= ng repaired, but what about IP-only networks? 5. Section 7.3.1. (Existing IGP exclusion mechanisms) * "In OSPF=85a metric of 2^16-1 (0xFFFF)=85" RFC6987 defined a con= stant called MaxLinkMetric. * "=85to prevent transit traffic from using a particular router=85[R= FC6987] specifies setting all outgoing interface metrics to 0xFFFF" -- that= won't prevent traffic through the router if it's the only path, look at th= e R-bit in OSPFv3; for OSPFv2, I think the latest attempt is draft-ietf-osp= f-ospfv2-hbit. * All this doesn't result in an incorrect behavior per the rules at = the end of this section. 6. Section 8.3. (Default MRT profile): s/priority/GADAG Root Selection P= riority 7. Section 10. (Inter-area Forwarding Behavior) Are there cases where i= t is ok (or even desirable) to keep the traffic in MRT-Red/Blue? The circu= mstantial case where independent failures occur in different areas sounds l= ike one where the traffic shouldn't be forwarded onto the default topology = by the ABR =97 but this is a case where the ABR is the entry point to a new= repair. Are there others? I'm just wondering why this Section doesn't co= mmit (s/should/SHOULD or even MUST) to saying that the traffic has to be ta= ken off an MRT at an ABR. 8. Section 12.2. (MRT Recalculation for the Default MRT Profile) include= s in the MRT recalculation sequence "a configured (or advertised) period". = Even though this Section talks only about the Default MRT Profile, it seem= s to me that a "recalculation timer" might be a nice things to have as part= of any MRT Profile. * I peeked at the algorithm ID and didn't find a timer defined there= either. Nits: 1. Please put a reference to Section 7 (?) in 1.2 when talking about MR= T Islands. 2. "Any RT is an MRT but many MRTs are not RTs." Counterintuitive since= it sounds like an MRT is the maximal version of an RT. 3. Please expand on first use: SPT, PLR, MT-ID 4. Some substitutions: * s/it is used to described/it is used to describe * * s/choice of tunnel egress MAY be flexible/choice of tunnel egress = is flexible * s/either IPv4 and IPv6/either IPv4 or IPv6 * s/Forwarding Mechanisms( MRT/Forwarding Mechanisms (MRT * s/The key difference is whether the traffic, once out of the MRT I= sland, remains in the same area/level and=85/The key difference is whether = the traffic, once out of the MRT Island, remains in the same area/level or= =85 5. "=85we will use the terms area and ABR to indicate either an OSPF are= a and OSPF ABR or ISIS level and ISIS LBR", but then you use ABR/LBR and ar= ea/level anyway. Suggestion: generalize to domain and DBR, define it in th= e terminology.. 6. Shouldn't there be a reference to Appendix A somewhere in Section 11? --_000_D29F3CC9F4D4Aaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <34F531A3E4FC79469374C48CAF6C57B1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

Happy New Year!

I just finished reviewing this document.  I have several comments (ple= ase see below) that I want to see addressed before starting the IETF Last C= all.

Out of the items marked as Major, the one that concerns me the most is the = one related to Operations/Management Considerations.  It is surprising= to me that such extensive work in the Standards Track didn't have any Oper= ations/Management (or even Security!) Considerations until the current version.  My comments below echo som= e of the opinions on the list, but I can't claim that they are all inclusiv= e.  As I pointed out below, I am not looking for a dissertation on the= topic, but much more than what's there should be included.

Thanks!

Alvaro.


Major:
  1. In general, I feel uncomfortable with documents making value statements rel= ated, for example, to how they perform against different solutions.  T= he purpose of this document should be to describe the technology, not to co= mpare against other solutions =97 that work (if wanted/needed) should be done in a different document.  Plea= se remove comparisons to other technology and relative statements.  So= me examples:
    • Abstract: "MRT is also extremely computationally efficient=85computati= on is less than the LFA computation..."  As was expressed on the = list, maybe CPU cycles are not that important if compared to other aspects= =85
    • Introduction: "Other existing= or proposed solutions are partial solutions or have significant issue= s, as described below."  It is ok to describe other solutions, bu= t please limit the description to the facts.
      • About the table: there are obviously other columns that could have been= included, which means that the table is not complete.
    • Section 4: "Modeling results comparing the alternate path lengths obtained with MRT to other <= /font>approaches are described in [I-D.ietf-rtgwg-mrt-frr-algorithm]."  I am also inc= luding the corresponding comment in my review of that other document.
    • Section 5: "= is an advantage of using MRT"  In this case, at least a reference to Section&nbs= p;15. (Applying Policy to Select f= rom Multiple Possible Alternates for FRR) might be in order.
    • References to Extensions.  This document being where the architecture = for MRT is defined should set the stage/define requirements for extensions = that are to be defined elsewhere, and not concern itself with the solutions= themselves.  In other words, please remove references to where solutions (in the form of extensions) are being= specified.  Some pointers:
      • All references to I-D.ietf-ospf-mrt, I-D.ietf-isis-mrt and I-D.ietf-mpls-ld= p-mrt, except maybe the ones in Section 13. (Implementation Status).
      • There are two places where it is mentione= d that the capabilities to advertise additional loopbacks "have <= /font>not been defined".
      • 7. (MRT Island Form= ation) starts by talking about the "purpose of communicating support for MRT in the IGP" which is the first time = in the document that is mentioned.  While distribution with an IGP may= be the obvious mechanism, please describe the requirement.
      • Another example of the s= ame occurs in Section 8.2. (Router-specific MRT paramaters) where it s= ays that "additional router-specific MRT parameters may need to be distributed via the IGP", when I think the requ= irement is that these additional parameters need to be known by all routers= in the MRT Island. [Again, distribution using the IGP may be the obvious choice..]
    • Algorithm.  draft-ietf-rtgwg-mrt-frr-algorithm says that it "defi= nes the=85algorithm that is used in the default MRT profile".  Pl= ease make the text in this document consistent with that when referrin= g to draft-ietf-rtgwg-mrt-frr-algorithm.  Some descriptions used in the text: "the exact MRT algorithm", "the algorithm= to compute MRTs", "Example algorithm"
    • Operations/Management Considerations
      • Given that the MRT paths don't follow the shortest paths, or even potential= ly planned backup paths in the network, I think you should include somethin= g about the potential impact related to capacity planning, congestion, stre= tch, etc.
      • What about address management?  = Are there considerations about assignment and management for the additional= loopbacks required for IP tunnels?
      • Section 15. (Applying Policy to Select from Multip= le Possible Alternates for FRR) basically says that policy can be applied &= quot;to select the best alternate from those provided by MRT and other FRR technologies".  You're right to point ou= t that "[I-D.ietf-rtgwg-lfa-manageability] discusses many of the potential criteria = that one might take into account when evaluating different alternates for selection".  What are = the considerations that should be taken into account when comparing between= MRT and others?  Are the criteria and requirements outlined in I-D.ietf-rtgwg-lfa-manageabili= ty applicable?  Even though I-D.ietf-rtgwg-lfa-manageability is i= ntended to be LFA-specific, should it be a Normative reference? [Note that there's a similar comment related to&nbs= p; I-D.ietf-rtgwg-lfa-manageability in my review of draft-= ietf-rtgwg-mrt-frr-algorithm.]
      • Applicability/Guidance for Operators
        • Section 4. (Maximally Redundant Trees (MRT)) clearly explai= ns about the impact of not having a 2-connected network for MRT to be applicable.  Section 11.3. (MRT Alternates= for Destinations Outside the MRT Island) talks about partial implementatio= n in an area.  
        • I thi= nk it would be important to consolidate some of that guidance (there's prob= ably more) in a single place.  Note that I'm not looking for a 30= page extension (a la RFC6571), just some general guidance.
        • Given that both Sections 14 and = 15 were added just in the latest version of the document, please consider t= aking a look at RFC5706.
        • [Nit] Consider making Section 15. (Applying Policy to Select from Mult= iple Possible Alternates for FRR) a sub-section of Section 14. (Operat= ions and Management Considerations).
      • MRT Profile Selection and Algorithm Transition:
        • From Section 7.2. (Support for a specific= MRT profile): "All routers in an MRT Island MUST support the sam= e MRT profile"=85and=85"A given router can support multiple MRT profiles and participate in multiple MRT Islands.".  If I u= nderstand this correctly, routers can support multiple MRT profiles for the= same area/level, right?  If so, how do the routers in the area/level = agree on which profile will be the one supported?  
        • Also, Section 8.1. (MRT Profile Options) says that "If a router advertises support for multiple MRT profiles, t= hen it MUST c= reate the transit forwarding topologies for each=85"  Are these multiple profiles inside the same area/level?  These = two pieces of text don't seem to be in sync.  [But I may be = missing something somewhere.]
        • MRT Algo= rithm Transition: How is it done?  In Section 8.1. (MRT Profile Options) says that "<= font face=3D"Calibri,sans-serif">Algorithm transitions can be managed by advertising multiple MRT profiles", but there's no explanation o= f how.  This comment is related to the one above about MRT Profile Sel= ection.
        • [Minor] I may have missed this somewhere..  
          • The MRT MPLS MT-ID va= lue is associated with the MRT profile, so that (for example) the MRT-Red M= PLS MT-ID for the default profile is 3997, right?  If so, how does one= introduce a new profile?  I'm guessing that by registering new MT-ID values.
            1. What happens if the MT-ID for the Red= and Blue MRTs don't correspond to the same profile?
      • 17. (IANA Considera= tions) talks about the "MRT Profile TLV", which is not defined anywhere in this document.  I= think that asking for the registry creation is enough.
      • Section 18. (Security Considerations)  Even though I = don't think this document should make explicit references to extensions, clearly there will be a transport that needs to be secured:= authentication, privacy, etc.
      • References: RFC2119 should be Normative.<= /font>
Minor:
  1. Section 1. (Introduction) says that: &quo= t;Once traffic has been moved to one of MRTs, it is not subject to further = repair actions. Thus, the traffic will not loop even if a worse failure (e.= g. node) occurs when protection was only available for a simpler failure (e.g. link)."  I'm sure you mean= that the worse failure occurs in the original topology (not in the MRT). &= nbsp;Please clarify.
  2. Multicast protection is out of scope, rig= ht?  There's a reference to I-D.atlas-rtgwg-mrt-mc-arch in the Introdu= ction (which is fine), but not explicit indication of the scope.  Sect= ion 8.1. (MRT Profile Options) also talks about multicast then describing "MRT Forwarding Mechanism" ("The = None option in may be useful for multicast global protection.").
    • In Section 8.1. (MRT Profile Options)= , is the "Area/Level Border Behavior" specific to multicast? &nbs= p;BTW, please avoid describing the options with questions.
  3. Section 1.1. (Importance of 100% Coverage= ) talks about how micro-loop prevention is something that can be achieved w= ith complete coverage, and Section 12. (Network Convergence and Preparing f= or the Next Failure) says it is something that needs attention after a failure, but then the document doesn't say ho= w MRT can be used:  the use of MRT (to support Farside Tunneling) is d= eclared out of scope, and an "orphan" statement (no references an= d no solution) about micro-loop mitigation is made ("Micro-loop mitigation mechanisms can also work when combined with M= RT.").
    • Section 12.1. (Micro-forwarding loop preven= tion and MRTs) does say that "Managing micro-loops is an orthogonal issue to having alternates for local repair=85", but I think you= need to explain some more about how micro-loops may not be an issue or how= MRT helps.
  4. Section 6.3. (Forwarding IP Unicast Traff= ic over MRT Paths) says that, for IP forwarding "consistency with LDP = is RECOMMENDED".  Why?  I'm guessing it might be simpler to = be consistent if both LDP and IP traffic are being repaired, but what about IP-only networks?
  5. Section 7.3.1. (Existing IGP exclusion me= chanisms)
    • "In OSPF=85a metric of 2^16-1 (0= xFFFF)=85"   RFC6987 defined a constant called MaxLinkMetric.
    • "=85to prevent transit t= raffic from using a particular router=85[RFC6987] specifies setting all out= going interface metrics to 0xFFFF" -- that won't prevent traffic throu= gh the router if it's the only path, look at the R-bit in OSPFv3; for OSPFv2, I think the latest attempt is draft-ietf-ospf-ospfv2-h= bit.
    • All this doesn't resu= lt in an incorrect behavior per the rules at the end of this section.
  6. Section 8.3. (Default MRT profile): s/priority/GADAG Root Selection Pr= iority
  7. Section 10. (Inter-area Forwarding Behavior)  Are there cases whe= re it is ok (or even desirable) to keep the traffic in MRT-Red/Blue?  = The circumstantial case where independent failures occur in different areas sounds like one where the traffic shouldn't be fo= rwarded onto the default topology by the ABR =97 but this is a ca= se where the ABR is the entry point to a new repair.  Are there others= ?  I'm just wondering why this Section doesn't commit (s/should/SHOULD or even MUST) to saying that the traffic has to be taken = off an MRT at an ABR.
  8. Section 12= .2. (MRT Recalculation for the Default MRT Profile) includes in the MRT rec= alculation sequence "a&= nbsp;configured (o= r advertised) period".  Even though this Section talks only about= the Default MRT Profile, it seems to me that a "recalculation timer" might be a nice things to have as part of any MRT Profile.
    • I peeked at the algorithm ID and didn= 't find a timer defined there either.

Any RT is an MRT but many = MRTs are not RTs."  Counterintuitive since it sounds like an MRT is the maximal version of an RT.
  • Please expand on first use: SPT, PLR, MT-= ID
  • Some substitutions:
    • s/it is used to described/it is used = to describe
    • s/choice of tunnel egress MAY be flexible/choice of t= unnel egress is flexible
    • s/either IPv4 and IPv6/either IPv4 or IPv6
    • s/Forwarding Mechanisms( MRT/Forwarding Mechanisms (MRT
    • s/The key difference is whether the traffic, once out of th= e MRT Island, remains in the = same area/level and=85/The key difference is whether the traffic, once out of the MRT Island, remains in the same = area/level or=85
  • "=85we will u= se the terms = area and ABR to indicate either an OSPF area and OSPF ABR or ISIS = level and ISIS LBR", but then you use ABR/LBR and area/level anyway. &= nbsp;Suggestion: generalize to domain and DBR, define it in the terminology= ..
  • Appendix A somewhere in Section 11?
    • --_000_D29F3CC9F4D4Aaretanaciscocom_-- From nobody Sat Jan 2 05:09:58 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9D01A002D; Sat, 2 Jan 2016 05:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBqqE4B_vn1s; Sat, 2 Jan 2016 05:09:53 -0800 (PST) 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 7BF631A0027; Sat, 2 Jan 2016 05:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18935; q=dns/txt; s=iport; t=1451740193; x=1452949793; h=from:to:cc:subject:date:message-id:mime-version; bh=wiaAGpx3uVozDe0lmy9unk+wsJqbJ7c9zyvDA/zi530=; b=Nhi7o6BJwO2mufLLVsD6T3/iVzPPXWQgFfh6Y4bpPgU6M7Dpw/ktyakj qdfHN6RjJQXs2MtleJLpWEqJENaKNPnrMyPfe5XxGcmhcC6I1xvY4KyPv qy2uVL3CMwINqvcPbKeV8/fxQjkYRYoWQwts/j4snbdukncGfvvc3SMNr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeBQA3y4dW/5tdJa1egm5MgUWIU7N9g?= =?us-ascii?q?WSGD4ESOhIBAQEBAQEBfwuENwR5EgEaZhcQBA4giBS/dwEBAQEGAQEBAQEehlY?= =?us-ascii?q?BjjoFkwqDfAGNUIFchEaIWY45ASkJMoQKhHqBCAEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,512,1444694400"; d="scan'208,217"; a="63763714" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jan 2016 13:09:52 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u02D9qkw013591 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Jan 2016 13:09:52 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Jan 2016 07:09:51 -0600 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.1104.009; Sat, 2 Jan 2016 07:09:51 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-rtgwg-mrt-frr-algorithm@ietf.org" Subject: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07 Thread-Topic: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07 Thread-Index: AQHRRV7dgEWOmft+i0q5eg7hbSc74g== Date: Sat, 2 Jan 2016 13:09:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_D2A7EEA5F51B2aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 13:09:56 -0000 --_000_D2A7EEA5F51B2aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I just finished reviewing this document. I have several comments (below) t= hat I want to see addressed before starting the IETF Last Call. As with draft-ietf-rtgwg-mrt-frr-architecture, my main point of concern is = related to operational/management considerations =97 the Architecture docum= ent should carry the load of these considerations, but there are some that = I think are algorithm-specific and should be included here. Thanks! Alvaro. Major: 1. Operational/Management Considerations * Section 1. (Introduction): "This document defines an algorithm for= selecting an appropriate MRT alternate for consideration. Other alternate= s, e.g. LFAs that are downstream paths, may be preferred when available an= d that policy-based alternate selection process [I-D.ietf-rtgwg-lfa-managea= bility] is not captured in this document." This paragraph seems to say tha= t the criteria in I-D.ietf-rtgwg-lfa-manageability applies also to the sele= ction between MRT alternates and others. Is that the intent? * Later in Section 5.4. (Initialization) you mention the criteria= in I-D.ietf-rtgwg-lfa-manageability applied to MRT ("Due to FRR manageabil= ity considerations [I-D.ietf-rtgwg-lfa-manageability], it may also be desir= able to administratively configure some interfaces as ineligible to carry M= RT FRR traffic."). * I mention all this because I-D.ietf-rtgwg-lfa-manageability is = listed as an Informative Reference both in this document and in draft-ietf-= rtgwg-mrt-frr-architecture (where there's just a light mention of manageabi= lity). If the criteria/recommendations in I-D.ietf-rtgwg-lfa-manageability= are to be followed, then I would like to see a stronger statement about it= . [There is a corresponding comment included in my review of draft-ietf-rt= gwg-mrt-frr-architecture.] * I'm surprised that there are no Operational Considerations in this= document. I am hoping to see general considerations in draft-ietf-rtgwg-m= rt-frr-architecture, but some of the specifics are clearly algorithm relate= d =97 the resulting length of the alternate path, for example. Please incl= ude an Operational Considerations section where some of the guidance given = in the document can be reflected, for example: * Section 5.3. (GADAG Root Selection) "Analysis has shown that t= he centrality of a router can have a significant impact on the lengths of t= he alternate paths computed. Therefore, it is RECOMMENDED that off-line an= alysis that considers the centrality of a router be used to help determine = how good a choice a particular router is for the role of GADAG root." * Section 9. (Algorithm Alternatives and Evaluation) "In additio= n, it is possible to calculate Destination-Rooted GADAG=85Building GADAGs p= er destination is computationally more expensive, but may give somewhat sho= rter alternate paths. It may be useful for live-live multicast along MRTs.= " * [[Minor] BTW, it looks like multicast is outside the scope of d= raft-ietf-rtgwg-mrt-frr-architecture. That doesn't mean that the algorithm= may not be useful for it =97 but Section 9 is the only place that multicas= t is mentioned.] 2. Section 3. (Terminology and Definitions) Not all the common terms be= tween this document and draft-ietf-rtgwg-mrt-frr-architecture are defined t= he same way. Some differences are indeed small, but to avoid confusion and= misinterpretation please be consistent. Suggestion: include in this docum= ent only the terms that were not present in draft-ietf-rtgwg-mrt-frr-archit= ecture. 3. References to Extensions. This document describes an algorithm to be= used in the MRT Architecture..as such, please leave mention of the extensi= ons/specific solutions out =97 as those other drafts progress the picture w= ill be complete. Some pointers: * All references to I-D.ietf-ospf-mrt and I-D.ietf-isis-mrt. * Section 5.4. (Initialization): "This constraint MUST be consistent= ly flooded via the IGP [I-D.ietf-ospf-mrt] [I-D.ietf-isis-mrt]=85so that li= nks are known to be MRT-ineligible=85" I'm venturing to say that the requ= irement here is for all the routers in the area/level/island to have this i= nformation, while the specific mechanism (IGP flooding, magic central box, = manual configuration, etc.) is an implementation detail. I fully understan= d that IGP flooding may be the best/obvious choice and that implementations= are being worked in that direction, but I think that's the job of the exte= nsion drafts (to indicate how to meet the requirement with IGP flooding, or= the magic box, or etc..). 4. Section 9.1. (Algorithm Evaluation) I am disappointed that you chose= not to focus this section on MRT Algorithm Alternatives and Evaluation, an= d instead decided to compare MRT with solutions that don't provide complete= coverage =97 and kicked off the discussion precisely with the coverage (Fi= gure 30). Please remove the comparison to other technologies that are not = potential MRT algorithms. * Later in the text you do get back to data specific to the Lowpoint= Algorithm and the ones described in the Appendixes. Minor: 1. Other algorithms. In several places general statements about algorit= hms for MRT are made =97 I'm assuming that you are referring to the algorit= hms mentioned/considered in this document (and not making statements about = other yet-to-be-known algorithms), is that correct? If so, please be clear= about it. Here are some examples: * 1. (Introduction): "Algorithms for computing MRTs can handle arbit= rary network topologies=85" * 4. (Algorithm Key Concepts): "There are five key concepts that are= critical for understanding=85other algorithms for computing MRTs." * 9. (Algorithm Alternatives and Evaluation) "This specification defines the = MRT Lowpoint Algorithm, which is one option among several possible MRT algo= rithms. Other alternatives are described in the appendices." 2. Section 5. (Algorithm Sections) s/This algorithm/The MRT Lowpoint al= gorithm 3. Section 5.1. (Interface Ordering) * Why are the values in Figure 15 for ISIS-PCR not considered Normat= ive? * I'm a little bit confused because the Interface_Compare functio= n depends on the values; what happens if the values received are not the ex= pected ones? For ISIS-PRC, can I use some other source for those values? * [I took a quick peek at draft-ietf-isis-pcr, but didn't find a = mention of MRT Node ID, for example.] * The last paragraph in this Section seems superfluous to me as it d= oesn't add/change anything. Nits: 1. I would put the Python code in an Appendix. --_000_D2A7EEA5F51B2aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    Hi!

    I just finished reviewing this document.  I have several comments (bel= ow) that I want to see addressed before starting the IETF Last Call.

    As with draft-ietf-rtgwg-mrt-frr-architecture, my main point of concer= n is related to operational/management considerations =97 the Architecture = document should carry the load of these considerations, but there are some = that I think are algorithm-specific and should be included here.

    Thanks!

    Alvaro.

    Major:
    1. Operat= ional/Management Considerations
      • Section 1. (Introduction): "Thi= s document defines an algorithm for selecting an appropriate MRT alternate for considera= tion.  Other alternates, e.g.  LFAs that are downstream paths, may be preferred when available and that policy-based alternate selection process [I= -D.ietf-rtgwg-lfa-manageability] is not captured in this document."  This paragraph seems to say that the criteria in&nbs= p;I-D.ietf-rtgwg-lfa-manageability= applies also to the selection between MRT alternates and others.  Is that the intent?  
        • Later in Section 5.4. (Initialization) you mention the criteria in&n= bsp;I-D.ietf-rtgwg-lfa-manageabili= ty applied to MRT ("Due to FRR manageability considerations [I-D.ietf-rtgwg-lfa-manageability], it may also be desirabl= e to administratively configure some interfaces as ineligible to carry MRT = FRR traffic.").   
        • I mention all this because I-D.ietf-rtgwg-lfa-manageability is listed as an= Informative Reference both in this document and in draft-ietf-rtgwg-m= rt-frr-architecture (where there's just a light mention of manageability). =  If the criteria/recommendations in I-D.ietf-rtgwg-lfa-manageabil= ity are to be followed, then I would like to see a stronger statement about it= .  [There is a corresponding comment included in my review of dra= ft-ietf-rtgwg-mrt-frr-architecture.]
      • I'm surprised that there are no = Operational Considerations in this document.  I am hoping to see gener= al considerations in draft-ie= tf-rtgwg-mrt-frr-architecture, but some of the specifics are clearly algorithm related =97 the resulting length of the al= ternate path, for example.  Please include an Operational Consideratio= ns section where some of the guidance given in the document can be reflecte= d, for example:
        • Section 5.3. (GADAG Root Selection)  "Analysis ha= s shown that the centrality of a router can have a significant impact = on the lengths of the alternate paths computed.  Therefore, it is RECOMMENDED that off-line analysis that considers the centralit= y of a router be used to help determine how good a choice a particular= router is for the role of GADAG root."
        • Section 9. (Algor= ithm Alternatives and Evaluation)  "In addition, it is possible t= o calculate Destination-Rooted GADAG=85Bu= ilding GADAGs per destination is computationally more expensive= , but may give somewhat shorter alternate paths.  It may be useful for live-live multicast along MRTs.&quo= t;
        • [[Minor] BTW, it looks like multicast is outside the scope of&nb= sp;draft-ietf-rtgwg-mrt-frr-architecture.=  That doesn't mean that the algorithm may not be useful for it = =97 but Section 9 is the only place that multicast is mentioned.]
    2. Section 3. (Terminology and Definitions)  Not all the common terms bet= ween this document and draft-ietf-rtgwg-mrt-frr-architecture are defin= ed the same way.  Some differences are indeed small, but to avoid conf= usion and misinterpretation please be consistent.  Suggestion: include in this document only the terms that were not pr= esent in draft-ietf-rtgwg-mrt-frr-architecture.
    3. References to Extensions.  This document describes an algorithm to be = used in the MRT Architecture..as such, please leave mention of the extensio= ns/specific solutions out =97 as those other drafts progress the picture wi= ll be complete.  Some pointers:
      • All references to I-D.ietf-ospf-mrt a= nd I-D.ietf-isis-mrt.
      • Sect= ion 5.4. (Initialization): &q= uot;This constrain= t MUST be consistently flooded via the IGP [I-D.ietf-ospf-mrt] [I-D.ietf-isis-mrt]=85so that links are known to be MRT-ineligible=85" =   I'm venturing to say that the requirement here is for all the r= outers in the area/level/island to have this information, while the specific mechanism (IGP flooding, magic central box, manual conf= iguration, etc.) is an implementation detail.  I fully understand that= IGP flooding may be the best/obvious choice and that implementations are b= eing worked in that direction, but I think that's the job of the extension drafts (to indicate how to meet the = requirement with IGP flooding, or the magic box, or etc..).
      • Section 9.1. (Algorithm Evaluation)  I am disappo= inted that you chose not to focus this section on MRT Algorithm Alternatives and Evaluation, and instead decided to compare MRT with solutions that don't provide complete = coverage =97 and kicked off the discussion precisely wi= th the coverage (Figure 30).  Please remove the comparison to other te= chnologies that are not potential MRT algorithms.
        • Later in the text you do get back to = data specific to the Lowpoint Algorithm and the ones described in the = Appendixes. 
    Minor:
    1. Other algorithms.  In several places general statements about algorith= ms for MRT are made =97 I'm assuming that you are referring to the algorith= ms mentioned/considered in this document (and not making statements about o= ther yet-to-be-known algorithms), is that correct?  If so, please be clear about it.  Here are some exampl= es:
      • 1. (Introduction): "Algorithms for computing MRTs can handle arbitrary= network topologies=85"
      • 4. (Algorithm Key Concepts): "There are five key concepts that are cri= tical for understanding=85other algorithms for computing MRTs."
        • 9. (Algorithm Alternatives and Evalu= ation) "This = specification defines the MRT Lowpoint Algorithm, which is one = option among several possible MRT algorithms.  Other alternatives are <= /span>described in the ap= pendices."
    2. Section 5. (Algorithm Sections)  s/This algorithm/The MRT Lowpoin= t algorithm
    3. Section 5.1. (Interface Ordering)  
      • Why are the values in Figure 15 for ISIS-PCR not considered Normative?<= /li>
        • I'm a little bit confused because the Interface_Compare function depend= s on the values; what happens if the values received are not the expected o= nes?  For ISIS-PRC, can I use some other source for those values?
          • =
        • [I took a quick peek at draft-ietf-isis-pcr, but didn't find a men= tion of MRT Node ID, for example.]
      • The last paragraph in this Section seems superfluous to me as it doesn'= t add/change anything.

    Nits:
    1. I would put the Python code in an Appendix.
    --_000_D2A7EEA5F51B2aretanaciscocom_-- From nobody Wed Jan 6 12:36:52 2016 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 742421A0389; Wed, 6 Jan 2016 12:35:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: rtgwg - New Meeting Session Request for IETF 95 X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160106203529.26582.44871.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 12:35:29 -0800 Archived-At: X-Mailman-Approved-At: Wed, 06 Jan 2016 12:36:50 -0800 Cc: rtgwg@ietf.org, rtgwg-chairs@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:35:29 -0000 A new meeting session request has just been submitted by Jeff Tantsura, a Chair of the rtgwg working group. --------------------------------------------------------- Working Group Name: Routing Area Working Group Area Name: Routing Area Session Requester: Jeff Tantsura Number of Sessions: 2 Length of Session(s): 2 Hours, 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: isis mpls ospf pce idr spring Second Priority: bess l3sm bier teas ccamp i2rs Third Priority: bfd detnet lime nvo3 pim netmod Special Requests: --------------------------------------------------------- From nobody Sun Jan 10 09:09:46 2016 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D411ACD9B; Sun, 10 Jan 2016 09:09:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-mrt-frr-architecture-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160110170944.20108.57543.idtracker@ietfa.amsl.com> Date: Sun, 10 Jan 2016 09:09:44 -0800 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 17:09:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees Authors : Alia Atlas Chris Bowers Gábor Sándor Enyedi Filename : draft-ietf-rtgwg-mrt-frr-architecture-09.txt Pages : 47 Date : 2016-01-10 Abstract: This document defines the architecture for IP/LDP Fast-Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-architecture-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 10 09:17:22 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC301ACE50; Sun, 10 Jan 2016 09:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKaXF6zWUQdp; Sun, 10 Jan 2016 09:17:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FEE1ACE43; Sun, 10 Jan 2016 09:17:03 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sun, 10 Jan 2016 17:16:43 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0361.006; Sun, 10 Jan 2016 17:16:43 +0000 From: Chris Bowers To: "Alvaro Retana (aretana)" , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" Subject: RE: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Topic: RE: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Index: AdFLymRfrf/gcWOOTVmsW4QZcyGUtg== Date: Sun, 10 Jan 2016 17:16:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BY2PR05MB614; 5:Bq6QTjGbBzGaqE/ZvCT6Hq5IT1bcHcRxW0r86S3Sl5jeyQmyuPX+KWukj5l9PuMERKiLyhe47BSjPvDarsVHzZU0XIPtHznhTnDoUwjnxd+fuFL8c8zrtZyMZupwX3wtiXjKskSlpF/f1dpWogDKRg==; 24:vkl36EZJ3OB8Jt+MEwjD5QjOkqv/rFph8fJNk3m7Cp+Y49pbSWYCnxji3ohASLOsm4YKMIgS2Ybeym4qDqL4L7MfmVJlcmoOwDdVjRSiaS4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB614; x-ms-office365-filtering-correlation-id: 3743262e-4ecb-40d3-71ee-08d319e1cffc x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB614; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB614; x-forefront-prvs: 0817737FD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51444003)(164054003)(377454003)(76576001)(1220700001)(575784001)(6116002)(106356001)(3846002)(54356999)(97736004)(101416001)(122556002)(66066001)(81156007)(11100500001)(2906002)(50986999)(5004730100002)(15975445007)(74316001)(102836003)(86362001)(4326007)(19580395003)(5001770100001)(5003600100002)(2900100001)(586003)(77096005)(40100003)(10400500002)(33656002)(189998001)(5001960100002)(92566002)(19580405001)(105586002)(230783001)(99286002)(2501003)(1096002)(87936001)(5008740100001)(5002640100001)(427584002)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB614; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR05MB61465BA37FE49CCECF3B1DDA9C80BY2PR05MB614namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2016 17:16:43.3698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB614 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 17:17:22 -0000 --_000_BY2PR05MB61465BA37FE49CCECF3B1DDA9C80BY2PR05MB614namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alvaro, Thanks for your detailed feedback. I've posted a new revision incorporati= ng your comments as well as some of the outstanding comments from Stewart B= ryant and Rob Shakir related to the introduction. The new revision is here. https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-mrt-frr-architecture-= 09.txt The diff is here. https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-mrt-frr-architecture-0= 9 See specific responses and text inline with [CB]. I also included links to diffs on github containing the XML edits addressin= g particular issues or set of issues. They are intended to help with revie= wing the edits, but please refer to the version submitted for the latest de= finitive revision. Thanks, Chris From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Saturday, January 02, 2016 7:09 AM To: draft-ietf-rtgwg-mrt-frr-architecture@ietf.org Cc: rtgwg-chairs@ietf.org; rtgwg@ietf.org; Janos Farkas > Subject: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Hi! Happy New Year! I just finished reviewing this document. I have several comments (please s= ee below) that I want to see addressed before starting the IETF Last Call. Out of the items marked as Major, the one that concerns me the most is the = one related to Operations/Management Considerations. It is surprising to m= e that such extensive work in the Standards Track didn't have any Operation= s/Management (or even Security!) Considerations until the current version. = My comments below echo some of the opinions on the list, but I can't claim= that they are all inclusive. As I pointed out below, I am not looking for= a dissertation on the topic, but much more than what's there should be inc= luded. Thanks! Alvaro. Major: 1. In general, I feel uncomfortable with documents making value statem= ents related, for example, to how they perform against different solutions.= The purpose of this document should be to describe the technology, not to= compare against other solutions - that work (if wanted/needed) should be d= one in a different document. Please remove comparisons to other technology= and relative statements. Some examples: o Abstract: "MRT is also extremely computationally efficient...comput= ation is less than the LFA computation..." As was expressed on the list, m= aybe CPU cycles are not that important if compared to other aspects... o Introduction: "Other existing or proposed solutions are partial sol= utions or have significant issues, as described below." It is ok to descri= be other solutions, but please limit the description to the facts. * About the table: there are obviously other columns that could have = been included, which means that the table is not complete. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] The abstract and introduction have been significantly revised to try = to remove value statements. I modified the comparison table and added seve= ral columns, trying to provide a factual comparison of tradeoffs based on d= ifferent metrics without making value judgements. (See the revised docume= nt or main diff above.) However, I am also willing to simply remove the ta= ble and descriptions, if that makes more sense. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D o Section 4: "Modeling results comparing the alternate path lengths o= btained with MRT to other approaches are described in [I-D.ietf-rtgwg-mrt-f= rr-algorithm]." I am also including the corresponding comment in my review= of that other document. [CB] I removed that sentence. o Section 5: "is an advantage of using MRT" In this case, at least a= reference to Section 15. (Applying Policy to Select from Multiple Possible= Alternates for FRR) might be in order. [CB] I removed that sentence. 2. References to Extensions. This document being where the architectu= re for MRT is defined should set the stage/define requirements for extensio= ns that are to be defined elsewhere, and not concern itself with the soluti= ons themselves. In other words, please remove references to where solution= s (in the form of extensions) are being specified. Some pointers: o All references to I-D.ietf-ospf-mrt, I-D.ietf-isis-mrt and I-D.ietf= -mpls-ldp-mrt, except maybe the ones in Section 13. (Implementation Status)= . o There are two places where it is mentioned that the capabilities to= advertise additional loopbacks "have not been defined". o Section 7. (MRT Island Formation) starts by talking about the "purp= ose of communicating support for MRT in the IGP" which is the first time in= the document that is mentioned. While distribution with an IGP may be the= obvious mechanism, please describe the requirement. o Another example of the same occurs in Section 8.2. (Router-specific= MRT paramaters) where it says that "additional router-specific MRT paramet= ers may need to be distributed via the IGP", when I think the requirement i= s that these additional parameters need to be known by all routers in the M= RT Island. [Again, distribution using the IGP may be the obvious choice..] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] The changes removing references to extensions are reflected in the fol= lowing diff. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/c01= aaedf02124512ff2bc057ace6846c59f6733a =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Algorithm. draft-ietf-rtgwg-mrt-frr-algorithm says that it "define= s the...algorithm that is used in the default MRT profile". Please make th= e text in this document consistent with that when referring to draft-ietf-r= tgwg-mrt-frr-algorithm. Some descriptions used in the text: "the exact MRT= algorithm", "the algorithm to compute MRTs", "Example algorithm" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] These changes are shown in this diff: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/155= 5f58f0195a0f417d4b81bbaec9361edb01df6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4. Operations/Management Considerations o Given that the MRT paths don't follow the shortest paths, or even p= otentially planned backup paths in the network, I think you should include = something about the potential impact related to capacity planning, congesti= on, stretch, etc. o What about address management? Are there considerations about assi= gnment and management for the additional loopbacks required for IP tunnels? o Section 15. (Applying Policy to Select from Multiple Possible Alter= nates for FRR) basically says that policy can be applied "to select the bes= t alternate from those provided by MRT and other FRR technologies". You're= right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many= of the potential criteria that one might take into account when evaluating= different alternates for selection". What are the considerations that sho= uld be taken into account when comparing between MRT and others? Are the c= riteria and requirements outlined in I-D.ietf-rtgwg-lfa-manageability appli= cable? Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-= specific, should it be a Normative reference? [Note that there's a similar = comment related to I-D.ietf-rtgwg-lfa-manageability in my review of draft-= ietf-rtgwg-mrt-frr-algorithm.] o Applicability/Guidance for Operators * Section 4. (Maximally Redundant Trees (MRT)) clearly explains about= the impact of not having a 2-connected network for MRT to be applicable. = Section 11.3. (MRT Alternates for Destinations Outside the MRT Island) talk= s about partial implementation in an area. * I think it would be important to consolidate some of that guidance = (there's probably more) in a single place. Note that I'm not looking for a= 30 page extension (a la RFC6571), just some general guidance. o Given that both Sections 14 and 15 were added just in the latest ve= rsion of the document, please consider taking a look at RFC5706. o [Nit] Consider making Section 15. (Applying Policy to Select from M= ultiple Possible Alternates for FRR) a sub-section of Section 14. (Operatio= ns and Management Considerations). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] These changes are shown in this diff: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/c36= 1f37638390a1b0364d67726367aabef203976 Revised section 14 is also reproduced below. 14. Operational Considerations The following aspects of MRT-FRR are useful to consider when deploying the technology in different operational environments and network topologies. 14.1. Verifying Forwarding on MRT Paths The forwarding paths created by MRT-FRR are not used by normal (non- FRR) traffic. They are only used to carry FRR traffic for a short period of time after a failure has been detected. It is RECOMMENDED that an operator proactively monitor the MRT forwarding paths in order to be certain that the paths will be able to carry FRR traffic when needed. Therefore, an implementation SHOULD provide an operator with the ability to test MRT paths with OAM traffic. For example, when MRT paths are realized using LDP labels distributed for topology-scoped FECs, an implementation can use the MPLS ping and traceroute as defined in [RFC4379] and extended in [RFC7307] for topology-scoped FECs. 14.2. Traffic Capacity on Backup Paths During a fast-reroute event initiated by a PLR in response to a network failure, the flow of traffic in the network will generally not be identical to the flow of traffic after the IGP forwarding state has converged, taking the failure into account. Therefore, even if a network has been engineered to have enough capacity on the appropriate links to carry all traffic after the IGP has converged after the failure, the network may still not have enough capacity on the appropriate links to carry the flow of traffic during a fast- reroute event. This can result in more traffic loss during the fast- reroute event than might otherwise be expected. Note that there are two somewhat distinct aspects to this phenomenon. The first is that the path from the PLR to the destination during the fast-reroute event may be different from the path after the IGP converges. In this case, any traffic for the destination that reaches the PLR during the fast-reroute event will follow a different path from the PLR to the destination than will be followed after IGP convergence. The second aspect is that the amount of traffic arriving at the PLR for affected destinations during the fast-reroute event may be larger than the amount of traffic arriving at the PLR for affected destinations after IGP convergence. Immediately after a failure, any non-PLR routers that were sending traffic to the PLR before the failure will continue sending traffic to the PLR, and that traffic will be carried over backup paths from the PLR to the destinations. After IGP convergence, upstream non-PLR routers may direct some traffic away from the PLR. In order to reduce or eliminate the potential for transient traffic loss due to inadequate capacity during fast-reroute events, an operator can model the amount of traffic taking different paths during a fast-reroute event. If it is determined that there is not enough capacity to support a given fast-reroute event, the operator can address the issue either by augmenting capacity on certain links or modifying the backup paths themselves. The MRT Lowpoint algorithm produces a pair of diverse paths to each destination. These paths are generated by following the directed links on a common GADAG. MRT-FRR allows an operator to exclude a link from the MRT Island, and thus the GADAG, by advertising it as MRT-Ineligible. Such a link will not be used on the MRT forwarding path for any destination. Advertising links as MRT-Ineligible is the main tool provided by MRT-FRR for keeping backup traffic off of lower bandwidth links during fast-reroute events. Note that all of the backup paths produced by the MRT Lowpoint algorithm are closely tied to the common GADAG computed as part of that algorithm. Therefore, it is generally not possible to modify a subset of paths without affecting other paths. This precludes more fine-grained modification of individual backup paths when using only paths computed by the MRT Lowpoint algorithm. However, it may be desirable to allow an operator to use MRT-FRR alternates together with alternates provided by other FRR technologies. A policy-based alternate selection process can allow an operator to select the best alternate from those provided by MRT and other FRR technologies. As a concrete example, it may be desirable to implement a policy where a downstream LFA (if it exists for a given failure mode and destination) is preferred over a given MRT alternate. This combination gives the operator the ability to affect where traffic flows during a fast-reroute event, while still producing backup paths that use no additional labels for LDP traffic and will not loop under multiple failures. This and other choices of alternate selection policy can be evaluated in the context of their effect on fast-reroute traffic flow and available capacity, as well as other deployment considerations. Note that future documents may define MRT profiles in addition to the default profile defined here. Different MRT profiles will generally produce alternate paths with different properties. An implementation may allow an operator to use different MRT profiles instead of or in addition to the default profile. 14.3. MRT IP Tunnel Loopback Address Management As described in Section 6.1.2, if an implementation uses IP tunneling as the mechanism to realize MRT forwarding paths, each node must advertise an MRT-Red and an MRT-Blue loopback address. These IP addresses must be unique within the routing domain to the extent that they do not overlap with each other or with any other routing table entries. It is expected that operators will use existing tools and processes for managing infrastructure IP addresses to manage these additional MRT-related loopback addresses. 14.4. MRT-FRR in a Network with Degraded Connectivity Ideally, routers is a service provider network using MRT-FRR will be initially deployed in a 2-connected topology, allowing MRT-FRR to find completely diverse paths to all destinations. However, a network can differ from an ideal 2-connected topology for many possible reasons, including network failures and planned maintenance events. MRT-FRR is designed to continue to function properly when network connectivity is degraded. When a network contains cut-vertices or cut-links dividing the network into different 2-connected blocks, MRT-FRR will continue to provide completely diverse paths for destinations within the same block as the PLR. For a destination in a different block from the PLR, the redundant paths created by MRT- FRR will be link and node diverse within each block, and the paths will only share links and nodes that are cut-links or cut-vertices in the topology. If a network becomes partitioned with one set of routers having no connectivity to another set of routers, MRT-FRR will function independently in each set of connected routers, providing redundant paths to destinations in same set of connected routers as a given PLR. 14.5. Partial Deployment of MRT-FRR in a Network A network operator may choose to deploy MRT-FRR only on a subset of routers in an IGP area. MRT-FRR is designed to accommodate this partial deployment scenario. Only routers that advertise support for a given MRT profile will be included in a given MRT Island. For a PLR within the MRT Island, MRT-FRR will create redundant forwarding paths to all destinations with the MRT Island using maximally redundant trees all the way to those destinations. For destinations outside of the MRT Island, MRT-FRR creates paths to the destination which use forwarding state created by MRT-FRR within the MRT Island and shortest path forwarding state outside of the MRT Island. The paths created by MRT-FRR to non-Island destinations are guaranteed to be diverse within the MRT Island (if topologically possible). However, the part of the paths outside of the MRT Island may not be diverse. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. MRT Profile Selection and Algorithm Transition: o From Section 7.2. (Support for a specific MRT profile): "All router= s in an MRT Island MUST support the same MRT profile"...and..."A given rout= er can support multiple MRT profiles and participate in multiple MRT Island= s.". If I understand this correctly, routers can support multiple MRT prof= iles for the same area/level, right? If so, how do the routers in the area= /level agree on which profile will be the one supported? o Also, Section 8.1. (MRT Profile Options) says that "If a router adv= ertises support for multiple MRT profiles, then it MUST create the transit = forwarding topologies for each..." Are these multiple profiles inside the = same area/level? These two pieces of text don't seem to be in sync. [But = I may be missing something somewhere.] o MRT Algorithm Transition: How is it done? In Section 8.1. (MRT Pro= file Options) says that "Algorithm transitions can be managed by advertisin= g multiple MRT profiles", but there's no explanation of how. This comment = is related to the one above about MRT Profile Selection. o [Minor] I may have missed this somewhere.. * The MRT MPLS MT-ID value is associated with the MRT profile, so tha= t (for example) the MRT-Red MPLS MT-ID for the default profile is 3997, rig= ht? If so, how does one introduce a new profile? I'm guessing that by reg= istering new MT-ID values. 1. What happens if the MT-ID for the Red and Blue MRTs don't correspon= d to the same profile? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] The question may already be answered by the edits, but I will try to a= nswer here as well. All routers are expected to be using the same MT-ID va= lues for the same profile. But if a router receives LDP advertisements wit= h an MT-ID values it doesn't understand, based on RFC7307, it should respon= d with an "Invalid Topology ID" status code in the LDP Notification message= . [CB] Diff for this group of comments: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/226= 89df3b7b311ea34f1751f123ff4f161516943 I modified the text in section 7.2 to better explain simultaneous support f= or multiple profiles (included below.) Note that a router may advertise support for multiple different MRT profiles. The process of MRT Island formation takes place independently for each MRT profile advertised by a given router. For example, consider a network with 40 connected routers in the same area advertising support for MRT Profile A and MRT Profile B. Two distinct MRT Islands will be formed corresponding to Profile A and Profile B, with each island containing all 40 routers. A complete set of maximally redundant trees will be computed for each island following the rules defined for each profile. If we add a third MRT Profile to this example, with Profile C being advertised by a connected subset of 30 routers, there will be a third MRT Island formed corresponding to those 30 routers, and a third set of maximally redundant trees will be computed. In this example, 40 routers would compute and install two sets of MRT transit forwarding entries corresponding to Profiles A and B, while 30 routers would compute and install three sets of MRT transit forwarding entries corresponding to Profiles A, B, and C. Text explaining profile (or algorithm transition) The ability of MRT-FRR to support transit forwarding entries for multiple profiles can be used to facilitate a smooth transition from an existing deployed MRT Profile to a new MRT Profile. The new profile can be activated in parallel with the existing profile, installing the transit forwarding entries for the new profile without affecting the transit forwarding entries for the existing profile. Once the new transit forwarding state has been verified, the router can be configured to use the alternates computed by the new profile in the event of a failure. I also added text to clarify how a new MRT profile is defined with new MT-I= D values. When a new MRT Profile is defined, new values should be allocated from the MPLS Multi-Topology Identifiers Registry, corresponding to the MRT-Red and MRT-Blue MT-ID values for the new MRT Profile . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6. Section 17. (IANA Considerations) talks about the "MRT Profile TLV"= , which is not defined anywhere in this document. I think that asking for = the registry creation is enough. 7. Section 18. (Security Considerations) Even though I don't think th= is document should make explicit references to extensions, clearly there wi= ll be a transport that needs to be secured: authentication, privacy, etc. 8. References: RFC2119 should be Normative. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Major issue 6-8 are addressed in this diff. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/6ce= 1afdf59f9fe3f9037c0f76b3a00c0db932998 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minor: 1. Section 1. (Introduction) says that: "Once traffic has been moved t= o one of MRTs, it is not subject to further repair actions. Thus, the traff= ic will not loop even if a worse failure (e.g. node) occurs when protection= was only available for a simpler failure (e.g. link)." I'm sure you mean = that the worse failure occurs in the original topology (not in the MRT). P= lease clarify. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] new text to clarify. Once traffic has been moved to one of the MRTs by one PLR, that traffic is not subject to further repair actions by another PLR, even in the event of multiple simultaneous failures. Therefore, traffic repaired by MRT-FRR will not loop between different PLRs responding to different simultaneous failures. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2. Multicast protection is out of scope, right? There's a reference t= o I-D.atlas-rtgwg-mrt-mc-arch in the Introduction (which is fine), but not = explicit indication of the scope. Section 8.1. (MRT Profile Options) also = talks about multicast then describing "MRT Forwarding Mechanism" ("The None= option in may be useful for multicast global protection."). o In Section 8.1. (MRT Profile Options), is the "Area/Level Border Be= havior" specific to multicast? BTW, please avoid describing the options wi= th questions. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Area Border behavior is not specific to multicast. I removed the con= fusing reference to [I-D.atlas-rtgwg-mrt-mc-arch] in section 8.1 [CB] I made several edits throughout to clarify that multicast is out of sc= ope. Diff for minor issues 1 and 2 is found here. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/542= ead0a83f4e3572b57d16f01abca86b0fe31c2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Section 1.1. (Importance of 100% Coverage) talks about how micro-lo= op prevention is something that can be achieved with complete coverage, and= Section 12. (Network Convergence and Preparing for the Next Failure) says = it is something that needs attention after a failure, but then the document= doesn't say how MRT can be used: the use of MRT (to support Farside Tunne= ling) is declared out of scope, and an "orphan" statement (no references an= d no solution) about micro-loop mitigation is made ("Micro-loop mitigation = mechanisms can also work when combined with MRT."). o Section 12.1. (Micro-forwarding loop prevention and MRTs) does say = that "Managing micro-loops is an orthogonal issue to having alternates for = local repair...", but I think you need to explain some more about how micro= -loops may not be an issue or how MRT helps. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I rewrote section 12.1 to clarify, and added small edits elsewhere. C= omplete diff below. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/673= 580abf1ae331bf3964c4f7128163e77b85edf 12.1. Micro-loop prevention and MRTs A micro-loop is a transient packet forwarding loop among two or more routers that can occur during IGP convergence. [RFC5715] discusses several techniques for preventing micro-loops. This section discusses how MRT-FRR relates to two of the micro-loop prevention techniques discussed in [RFC5715], Nearside Tunneling and Farside Tunneling. In Nearside Tunneling, a router (PLR) adjacent to a failure perform local repair and inform remote routers of the failure. The remote routers initially tunnel affected traffic to the nearest PLR, using tunnels which are unaffected by the failure. Once the forwarding state for normal shortest path routing has converged, the remote routers return the traffic to shortest path forwarding. MRT-FRR is relevant for Nearside Tunneling for the following reason. The process of tunneling traffic to the PLRs and waiting a sufficient amount of time for IGP forwarding state convergence with Nearside Tunneling means that traffic will generally be relying on the local repair at the PLR for longer than it would in the absence of Nearside Tunneling. Since MRT-FRR provides 100% coverage for single link and node failure, it may be an attractive option to provide the local repair paths when Nearside Tunneling is deployed. MRT-FRR is also relevant for the Farside Tunneling micro-loop prevention technique. In Farside Tunneling, remote routers tunnel traffic affected by a failure to a node downstream of the failure with respect to traffic destination. This node can be viewed as being on the farside of the failure with respect to the node initiating the tunnel. Note that the discussion of Farside Tunneling in [RFC5715] focuses on the case where the farside node is immediately adjacent to a failed link or node. However, the farside node may be any node downstream of the failure with respect to traffic destination, including the destination itself. The tunneling mechanism used to reach the farside node must be unaffected by the failure. The alternative forwarding paths created by MRT-FRR have the potential to be used to forward traffic from the remote routers upstream of the failure all the way to the destination. In the event of failure, either the MRT-Red or MRT-Blue path from the remote upstream router to the destination is guaranteed to avoid a link failure or inferred node failure. The MRT forwarding paths are also guaranteed to not be subject to micro-loops because they are locked to the topology before the failure. We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm] address the case of a PLR adjacent to a failure determining which choice of MRT-Red or MRT-Blue will avoid a failed link or node. More computation may be required for an arbitrary remote upstream router to determine whether to choose MRT-Red or MRT-Blue for a given destination and failure. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4. Section 6.3. (Forwarding IP Unicast Traffic over MRT Paths) says th= at, for IP forwarding "consistency with LDP is RECOMMENDED". Why? I'm gue= ssing it might be simpler to be consistent if both LDP and IP traffic are b= eing repaired, but what about IP-only networks? [CB] I deleted the recommendation. 5. Section 7.3.1. (Existing IGP exclusion mechanisms) o "In OSPF...a metric of 2^16-1 (0xFFFF)..." RFC6987 defined a cons= tant called MaxLinkMetric. o "...to prevent transit traffic from using a particular router...[RF= C6987] specifies setting all outgoing interface metrics to 0xFFFF" -- that = won't prevent traffic through the router if it's the only path, look at the= R-bit in OSPFv3; for OSPFv2, I think the latest attempt is draft-ietf-ospf= -ospfv2-hbit. o All this doesn't result in an incorrect behavior per the rules at t= he end of this section. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I added text about the OSPFv3 V6-bit and R-bit and clarified how MaxLi= nkMetric only discourages transit traffic. For OSPFv2 and OSPFv3, [RFC6987] specifies setting all outgoing interface metrics to 0xFFFF to discourage transit traffic from using a router.( [RFC6987] defines the metric value 0xFFFF as MaxLinkMetric, a fixed architectural value for OSPF.) For OSPFv3, [RFC5340] specifies that a router be excluded from the intra-area shortest path tree computation if the V6-bit or R-bit of the LSA options is not set in the Router LSA. The following rules for MRT Island formation ensure that MRT FRR protection traffic does not use a link or router that is discouraged or prevented from carrying traffic by existing IGP mechanisms. 1. A bidirectional link MUST be excluded from an MRT Island if either the forward or reverse cost on the link is 0xFFFFFE (for ISIS) or 0xFFFF for OSPF. 2. A router MUST be excluded from an MRT Island if it is advertised with the overload bit set (for ISIS), or it is advertised with metric values of 0xFFFF on all of its outgoing interfaces (for OSPFv2 and OSPFv3). 3. A router MUST be excluded from an MRT Island if it is advertised with either the V6-bit or R-bit of the LSA options not set in the Router LSA. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Diff for minor 4-5. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/da0= 88b9b7749c10627e625759c6b4728b63acef9?diff=3Dsplit =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6. Section 8.3. (Default MRT profile): s/priority/GADAG Root Selection= Priority [CB] Done. 7. Section 10. (Inter-area Forwarding Behavior) Are there cases where= it is ok (or even desirable) to keep the traffic in MRT-Red/Blue? The cir= cumstantial case where independent failures occur in different areas sounds= like one where the traffic shouldn't be forwarded onto the default topolog= y by the ABR - but this is a case where the ABR is the entry point to a new= repair. Are there others? I'm just wondering why this Section doesn't co= mmit (s/should/SHOULD or even MUST) to saying that the traffic has to be ta= ken off an MRT at an ABR. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] For unicast FRR, I can't think of a scenario where one would want to s= tay on the red or blue MRT after crossing area borders. For multicast di= stribution on MRTs, it may be useful to stay on red or blue across borders.= The default MRT profile specifies ABRs/LBRs SHOULD ensure that traffic le= aving the area also exits the MRT-Red or MRT-Blue forwarding topology. I t= hink the draft can be somewhat less strict about this requirement because d= ifferent behavior by some ABRs won't cause routing loops or lost traffic, b= ut I'm open to changes here if you think it makes sense. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 8. Section 12.2. (MRT Recalculation for the Default MRT Profile) inclu= des in the MRT recalculation sequence "a configured (or advertised) period"= . Even though this Section talks only about the Default MRT Profile, it se= ems to me that a "recalculation timer" might be a nice things to have as pa= rt of any MRT Profile. o I peeked at the algorithm ID and didn't find a timer defined there = either. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Extensions are defined in draft-ietf-ospf-mrt and draft-ietf-isis-mrt= so I added this text. New protocol extensions for advertising the time needed to recompute shortest path routes and install them in the FIB will be defined elsewhere. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nits: 1. Please put a reference to Section 7 (?) in 1.2 when talking about = MRT Islands. 2. "Any RT is an MRT but many MRTs are not RTs." Counterintuitive sin= ce it sounds like an MRT is the maximal version of an RT. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Rewrote these definitions to clarify. Redundant Trees (RT): A pair of trees where the path from any node X to the root R along the first tree is node-disjoint with the path from the same node X to the root along the second tree. Redundant trees can always be computed in 2-connected graphs. Maximally Redundant Trees (MRT): A pair of trees where the path from any node X to the root R along the first tree and the path from the same node X to the root along the second tree share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cut-links. In graphs that are not 2-connected, it is not possible to compute RTs. However, it is possible to compute MRTs. MRTs are maximally redundant in the sense that they are as redundant as possible given the constraints of the network graph. [CB] Also took the opportunity to re-order the terminology section. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 3. Please expand on first use: SPT, PLR, MT-ID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D [CB] Diff for nits 1-3: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/520= 68aff5dfc9fb5ff2b42dfb2a19ce5447023fa =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 4. Some substitutions: o s/it is used to described/it is used to describe o s/choice of tunnel egress MAY be flexible/choice of tunnel egress i= s flexible o s/either IPv4 and IPv6/either IPv4 or IPv6 o s/Forwarding Mechanisms( MRT/Forwarding Mechanisms (MRT o s/The key difference is whether the traffic, once out of the MRT Is= land, remains in the same area/level and.../The key difference is whether t= he traffic, once out of the MRT Island, remains in the same area/level or..= . 5. "...we will use the terms area and ABR to indicate either an OSPF a= rea and OSPF ABR or ISIS level and ISIS LBR", but then you use ABR/LBR and = area/level anyway. Suggestion: generalize to domain and DBR, define it in = the terminology.. 6. Shouldn't there be a reference to Appendix A somewhere in Section 1= 1? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commi= t/94a247c426104b06862118149be9254fc553bb25 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_BY2PR05MB61465BA37FE49CCECF3B1DDA9C80BY2PR05MB614namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Alvaro,
     
    Thanks for your detailed feedback.  IR= 17;ve posted  a new revision incorporating your comments as well as so= me of the outstanding comments from Stewart Bryant and Rob Shakir related t= o the introduction.
     
    The new revision is here.
    https://www.ietf.org/int= ernet-drafts/draft-ietf-rtgwg-mrt-frr-architecture-09.txt
    The diff is here.
     
    See specific responses and text inline with [C= B]. 
     
    I also included links to diffs on github conta= ining the XML edits addressing particular issues or set of issues.  Th= ey are intended to help with reviewing the edits, but please refer to the v= ersion submitted for the latest definitive revision. 
     
    Thanks,
    Chris
     
    From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]
    Sent: Saturday, January 02, 2016 7:09 AM
    To: draft-ietf-rtgwg-mrt-frr-architecture@ietf.org=
    Cc: rtgwg-chairs@ietf.org; rtgwg@ietf.org; Janos Farkas <= ;ja= nos.farkas@ericsson.com>
    Subject: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08
     
    Hi!
     
    Happy New Year!
     
    I just finished rev= iewing this document.  I have several comments (please see below) that= I want to see addressed before starting the IETF Last Call.<= /div>
     
    Out of the items ma= rked as Major, the one that concerns me the most is the one related to Oper= ations/Management Considerations.  It is surprising to me that such ex= tensive work in the Standards Track didn't have any Operations/Management (or even Security!) Considerations until the= current version.  My comments below echo some of the opinions on the = list, but I can't claim that they are all inclusive.  As I pointed out= below, I am not looking for a dissertation on the topic, but much more than what's there should be included.
     
    Thanks!
     
    Alvaro.
     
     
    Major:
    1. In general, I feel uncomfor= table with documents making value statements related, for example, to how t= hey perform against different solutions.  The purpose of this document= should be to describe the technology, not to compare against other solutions — that work (if wanted/needed)= should be done in a different document.  Please remove comparisons to= other technology and relative statements.  Some examples:
    • Abstract: "MRT is also= extremely computationally efficient…computation is less than the LFA= computation..."  As was expressed on the list, maybe CPU cycles = are not that important if compared to other aspects…
    • Introduction: "Other existing or p= roposed solutions are partial solutions or have significant issues, as= described below."  It is ok to describe other solutions, but ple= ase limit the description to the facts.
    • About the table: there are = obviously other columns that could have been included, which means that the= table is not complete.
      •
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [C= B]  The abstract and introduction have been significantly revised to t= ry to remove value statements.  I modified the comparison table and ad= ded several columns, trying to provide a factual comparison of tradeoffs based on different metrics without making value jud= gements.   (See the revised document or main diff above.)  H= owever, I am also willing to simply remove the table and descriptions, if t= hat makes more sense.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    • Section 4: "Modeling r= esults comparing the alternate path lengths obtained with MRT to other=  approaches are described in [I-D.ietf-rtgwg-mrt-frr-algorithm]."=  I am also including the corresponding comment in my review of that other document.
      •
    [C= B] I removed that sentence.
    • Section 5: "is an adva= ntage of using MRT"  In this case, at least a reference to Sectio= n 15. (Applying Policy to Select from Multiple Possible Alternates for= FRR) might be in order.
      •
    [C= B] I removed that sentence.
    1. References to Extensions. &= nbsp;This document being where the architecture for MRT is defined should s= et the stage/define requirements for extensions that are to be defined else= where, and not concern itself with the solutions themselves.  In other words, please remove references to whe= re solutions (in the form of extensions) are being specified.  Some po= inters:
    • All references to I-D.ietf-= ospf-mrt, I-D.ietf-isis-mrt and I-D.ietf-mpls-ldp-mrt, except maybe the one= s in Section 13. (Implementation Status).
    • There are two places where it is mentioned that the= capabilities to advertise additional loopbacks "have not been de= fined".
    • Section&nb= sp;7. (MRT Island Formation) starts by talking about the "purpose of c= ommunicating support for MRT in the IGP" which is the first time in th= e document that is mentioned.  While distribution with an IGP may be the obvious mechanism, please describe the requirement.
      • Another example of the same o= ccurs in Section 8.2. (Router-specific MRT paramaters) where it says t= hat "additional router-specific MRT parameters may need to be dis= tributed via the IGP", when I think the requirement is that these additional parameters need to be known by all routers in the = MRT Island. [Again, distribution using the IGP may be the obvious choi= ce..]
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [C= B] The changes removing references to extensions are reflected in the follo= wing diff.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Algorithm.  draft-ietf= -rtgwg-mrt-frr-algorithm says that it "defines the…algorithm tha= t is used in the default MRT profile".  Please make the text in&n= bsp;this document consistent with that when referring to draft-ietf-rtgwg-m= rt-frr-algorithm.  Some descriptions used in the text: "the exact MRT algorithm&quo= t;, "the algorithm to compute MRTs", "Example algorithm"= ;
      2.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [C= B] These changes are shown in this diff:
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Operations/Management Consi= derations
    • Given that the MRT paths do= n't follow the shortest paths, or even potentially planned backup paths in = the network, I think you should include something about the potential impac= t related to capacity planning, congestion, stretch, etc.
    • What abou= t address management?  Are there considerations about assignment and m= anagement for the additional loopbacks required for IP tunnels?
    • Section 15. (Applying Policy = to Select from Multiple Possible Alternates for FRR) basically says that po= licy can be applied "to select the best alternate from those provided = by MRT and other FRR technologies".  You're right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses = many of the potential criteria that one might take into account when e= valuating different alternates for selection".  What are the= considerations that should be taken into account when comparing between MRT and others?  Are the criteria and requirements outlined in=  I-D.ietf-rtgwg-lfa-manageability applicable?  Even though I= -D.ietf-rtgwg-lfa-manageability is intended to be LFA-specific, should it&n= bsp;be a Normative reference? [Note that there's a similar comment related to  I-D.ietf-rtgwg-lfa-manageability in my review= of draft-ietf-rtgwg-mrt-frr-algorithm.]
    • Applicability/Guidance for Operators
    • Section 4. (Maximally = Redundant Trees (MRT)) clearly explains about the impact of not having a 2-= connected network for MRT to be applicable.  Section 11.3. (MRT A= lternates for Destinations Outside the MRT Island) talks about partial implementation in an area.  
    • I think it would be important to consolidate= some of that guidance (there's probably more) in a single place.  Not= e that I'm not looking for a 30 page extension (a la RFC6571), just so= me general guidance.
      •
    • Given that both Sections 14= and 15 were added just in the latest version of the document, please consi= der taking a look at RFC5706.
    • [Nit] Consider making Section 15. (Applying Policy to Select fr= om Multiple Possible Alternates for FRR) a sub-section of Section 14. = (Operations and Management Considerations).
      •
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [C= B] These changes are shown in this diff:
    Revised section 14 is also= reproduced below.
    = 14.  Operational Considerations
    =  
    =    The following aspects of MRT-FRR are useful to consider when
    =    deploying the technology in different operational environments= and
    =    network topologies.
    =  
    = 14.1.  Verifying Forwarding on MRT Paths
    =  
    =    The forwarding paths created by MRT-FRR are not used by normal= (non-
    =    FRR) traffic.  They are only used to carry FRR traffic fo= r a short
    =    period of time after a failure has been detected.  It is = RECOMMENDED
    =    that an operator proactively monitor the MRT forwarding paths = in
    =    order to be certain that the paths will be able to carry FRR t= raffic
    =    when needed.  Therefore, an implementation SHOULD provide= an operator
    =    with the ability to test MRT paths with OAM traffic.  For= example,
    =    when MRT paths are realized using LDP labels distributed for
    =    topology-scoped FECs, an implementation can use the MPLS ping = and
    =    traceroute as defined in [RFC4379] and extended in [RFC7307] f= or
    =    topology-scoped FECs.
    =  
    = 14.2.  Traffic Capacity on Backup Paths
    =  
    =    During a fast-reroute event initiated by a PLR in response to = a
    =    network failure, the flow of traffic in the network will gener= ally
    =    not be identical to the flow of traffic after the IGP forwardi= ng
    =    state has converged, taking the failure into account.  Th= erefore,
    =    even if a network has been engineered to have enough capacity = on the
    =    appropriate links to carry all traffic after the IGP has conve= rged
    =    after the failure, the network may still not have enough capac= ity on
    =    the appropriate links to carry the flow of traffic during a fa= st-
    =    reroute event.  This can result in more traffic loss duri= ng the fast-
    =    reroute event than might otherwise be expected.<= /div>
    =  
    =    Note that there are two somewhat distinct aspects to this phen= omenon.
    =    The first is that the path from the PLR to the destination dur= ing the
    =    fast-reroute event may be different from the path after the IG= P
    =    converges.  In this case, any traffic for the destination= that
    =    reaches the PLR during the fast-reroute event will follow a di= fferent
    =    path from the PLR to the destination than will be followed aft= er IGP
    =    convergence.
    =  
    =    The second aspect is that the amount of traffic arriving at th= e PLR
    =    for affected destinations during the fast-reroute event may be= larger
    =    than the amount of traffic arriving at the PLR for affected
    =    destinations after IGP convergence.  Immediately after a = failure, any
    =    non-PLR routers that were sending traffic to the PLR before th= e
    =    failure will continue sending traffic to the PLR, and that tra= ffic
    =    will be carried over backup paths from the PLR to the destinat= ions.
    =    After IGP convergence, upstream non-PLR routers may direct som= e
    =    traffic away from the PLR.
    =  
    =    In order to reduce or eliminate the potential for transient tr= affic
    =    loss due to inadequate capacity during fast-reroute events, an=
    =    operator can model the amount of traffic taking different path= s
    =    during a fast-reroute event.  If it is determined that th= ere is not
    =    enough capacity to support a given fast-reroute event, the ope= rator
    =    can address the issue either by augmenting capacity on certain= links
    =    or modifying the backup paths themselves.
    =  
    =    The MRT Lowpoint algorithm produces a pair of diverse paths to= each
    =    destination.  These paths are generated by following the = directed
    =    links on a common GADAG.  MRT-FRR allows an operator to e= xclude a
    =    link from the MRT Island, and thus the GADAG, by advertising i= t as
    =    MRT-Ineligible.  Such a link will not be used on the MRT = forwarding
    =    path for any destination.  Advertising links as MRT-Ineli= gible is the
    =    main tool provided by MRT-FRR for keeping backup traffic off o= f lower
    =    bandwidth links during fast-reroute events.
    =  
    =    Note that all of the backup paths produced by the MRT Lowpoint=
    =    algorithm are closely tied to the common GADAG computed as par= t of
    =    that algorithm.  Therefore, it is generally not possible = to modify a
    =    subset of paths without affecting other paths.  This prec= ludes more
    =    fine-grained modification of individual backup paths when usin= g only
    =    paths computed by the MRT Lowpoint algorithm.
    =  
    =    However, it may be desirable to allow an operator to use MRT-F= RR
    =    alternates together with alternates provided by other FRR
    =    technologies.  A policy-based alternate selection process= can allow
    =    an operator to select the best alternate from those provided b= y MRT
    =    and other FRR technologies.  As a concrete example, it ma= y be
    =    desirable to implement a policy where a downstream LFA (if it = exists
    =    for a given failure mode and destination) is preferred over a = given
    =    MRT alternate.  This combination gives the operator the a= bility to
    =    affect where traffic flows during a fast-reroute event, while = still
    =    producing backup paths that use no additional labels for LDP t= raffic
    =    and will not loop under multiple failures.  This and othe= r choices of
    =    alternate selection policy can be evaluated in the context of = their
    =    effect on fast-reroute traffic flow and available capacity, as= well
    =    as other deployment considerations.
    =  
    =    Note that future documents may define MRT profiles in addition= to the
    =    default profile defined here.  Different MRT profiles wil= l generally
    =    produce alternate paths with different properties.  An im= plementation
    =    may allow an operator to use different MRT profiles instead of= or in
    =    addition to the default profile.
    =  
    = 14.3.  MRT IP Tunnel Loopback Address Management
    =  
    =    As described in Section 6.1.2, if an implementation uses IP tu= nneling
    =    as the mechanism to realize MRT forwarding paths, each node mu= st
    =    advertise an MRT-Red and an MRT-Blue loopback address.  T= hese IP
    =    addresses must be unique within the routing domain to the exte= nt that
    =    they do not overlap with each other or with any other routing = table
    =    entries.  It is expected that operators will use existing= tools and
    =    processes for managing infrastructure IP addresses to manage t= hese
    =    additional MRT-related loopback addresses.
    =  
    = 14.4.  MRT-FRR in a Network with Degraded Connectivity
    =  
    =    Ideally, routers is a service provider network using MRT-FRR w= ill be
    =    initially deployed in a 2-connected topology, allowing MRT-FRR= to
    =    find completely diverse paths to all destinations.  Howev= er, a
    =    network can differ from an ideal 2-connected topology for many=
    =    possible reasons, including network failures and planned maint= enance
    =    events.
    =  
    =    MRT-FRR is designed to continue to function properly when netw= ork
    =    connectivity is degraded.  When a network contains cut-ve= rtices or
    =    cut-links dividing the network into different 2-connected bloc= ks,
    =    MRT-FRR will continue to provide completely diverse paths for<= /span>
    =    destinations within the same block as the PLR.  For a des= tination in
    =    a different block from the PLR, the redundant paths created by= MRT-
    =    FRR will be link and node diverse within each block, and the p= aths
    =    will only share links and nodes that are cut-links or cut-vert= ices in
    =    the topology.
    =  
    =    If a network becomes partitioned with one set of routers havin= g no
    =    connectivity to another set of routers, MRT-FRR will function<= /span>
    =    independently in each set of connected routers, providing redu= ndant
    =    paths to destinations in same set of connected routers as a gi= ven
    =    PLR.
    =  
    = 14.5.  Partial Deployment of MRT-FRR in a Network
    =  
    =    A network operator may choose to deploy MRT-FRR only on a subs= et of
    =    routers in an IGP area.  MRT-FRR is designed to accommoda= te this
    =    partial deployment scenario.  Only routers that advertise= support for
    =    a given MRT profile will be included in a given MRT Island.&nb= sp; For a
    =    PLR within the MRT Island, MRT-FRR will create redundant forwa= rding
    =    paths to all destinations with the MRT Island using maximally<= /span>
    =    redundant trees all the way to those destinations.  For d= estinations
    =    outside of the MRT Island, MRT-FRR creates paths to the destin= ation
    =    which use forwarding state created by MRT-FRR within the MRT I= sland
    =    and shortest path forwarding state outside of the MRT Island.&= nbsp; The
    =    paths created by MRT-FRR to non-Island destinations are guaran= teed to
    =    be diverse within the MRT Island (if topologically possible).<= /span>
    =    However, the part of the paths outside of the MRT Island may n= ot be
    =    diverse.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. MRT Profile Selection and A= lgorithm Transition:
    • From Section 7.2. (Support = for a specific MRT profile): "All routers in an MRT Island MUST s= upport the same MRT profile"…and…"A given router can = support multiple MRT profiles and participate in multiple MRT Islands.= ".  If I understand this correctly, routers can support multiple MRT= profiles for the same area/level, right?  If so, how do the routers i= n the area/level agree on which profile will be the one supported?  
    • Also, Section = 8.1. (MRT Profile Options) says that "If a router advertises support f= or multiple MRT profiles, then it MUST create the transit forwarding t= opologies for each…"  Are these multiple profiles inside the same area/level?  These two pieces of text don't seem to be i= n sync.  [But I may be missing something somewhere.]
    • MRT Algorithm Transition: How is it= done?  In Section 8.1. (MRT Profile Options) says that "Alg= orithm transitions can be managed by advertising multiple MRT profiles= ", but there's no explanation of how.  This comment is related to the one above about MRT Profile Selection.
    • [Minor] I may have missed this somew= here..  
    • The MRT MPLS MT-ID value is= associated with the MRT profile, so that (for example) the MRT-Red MPLS MT= -ID for the default profile is 3997, right?  If so, how does one intro= duce a new profile?  I'm guessing that by registering new MT-ID values.
    1. What happens if the MT-ID f= or the Red and Blue MRTs don't correspond to the same profile?
      2. <= /font>
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [CB] The question may already be answered by the e= dits, but I will try to answer here as well.  All routers are expected= to be using the same MT-ID values for the same profile.  But if a router receives LDP advertisements with an MT-= ID values it doesn’t understand, based on RFC7307, it should respond = with an "Invalid Topology ID" status code in the LDP Notification= message.
    [CB] Diff for this group of comments:
    I modified the text in section 7.2 to better expla= in simultaneous support for multiple profiles (included below.) 
     
    =    Note that a router may advertise support for multiple differen= t MRT
    =    profiles.  The process of MRT Island formation takes plac= e
    =    independently for each MRT profile advertised by a given route= r.  For
    =    example, consider a network with 40 connected routers in the s= ame
    =    area advertising support for MRT Profile A and MRT Profile B.&= nbsp; Two
    =    distinct MRT Islands will be formed corresponding to Profile A= and
    =    Profile B, with each island containing all 40 routers.  A= complete
    =    set of maximally redundant trees will be computed for each isl= and
    =    following the rules defined for each profile.  If we add = a third MRT
    =    Profile to this example, with Profile C being advertised by a<= /span>
    =    connected subset of 30 routers, there will be a third MRT Isla= nd
    =    formed corresponding to those 30 routers, and a third set of
    =    maximally redundant trees will be computed.  In this exam= ple, 40
    =    routers would compute and install two sets of MRT transit forw= arding
    =    entries corresponding to Profiles A and B, while 30 routers wo= uld
    =    compute and install three sets of MRT transit forwarding entri= es
    =    corresponding to Profiles A, B, and C.
    =  
    =    Text explaining profile (or algorithm transition)
    =    The ability of MRT-FRR to support transit forwarding entries f= or
    =    multiple profiles can be used to facilitate a smooth transitio= n from
    =    an existing deployed MRT Profile to a new MRT Profile.  T= he new
    =    profile can be activated in parallel with the existing profile= ,
    =    installing the transit forwarding entries for the new profile = without
    =    affecting the transit forwarding entries for the existing prof= ile.
    =    Once the new transit forwarding state has been verified, the r= outer
    =    can be configured to use the alternates computed by the new pr= ofile
    =    in the event of a failure.
    =  
    I also added text to clarify how a new MRT profile= is defined with new MT-ID values.
    =   When a new MRT Profile is defined, new values should be allocated
    =    from the MPLS Multi-Topology Identifiers Registry, correspondi= ng to
    =    the MRT-Red and MRT-Blue MT-ID values for the new MRT Profile = .
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Section 17. (IANA Cons= iderations) talks about the "MRT Profile TLV", which is not defin= ed anywhere in this document.  I think that asking for the registry cr= eation is enough.
    2. Secti= on 18. (Security Considerations)  Even though I don't think = this document should make explicit references to extensions, clearly there = will be a transport that needs to be secured: authentication, privacy, etc.
    3. References: RFC211= 9 should be Normative.
      4.
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [CB] Major issue 6-= 8 are addressed in this diff.
     
     
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Minor:
    1. Section 1. (Introduction) s= ays that: "Once traffic has been moved to one of MRTs, it is not subje= ct to further repair actions. Thus, the traffic will not loop even if a wor= se failure (e.g. node) occurs when protection was only available for a simpler failure (e.g. link)."  I'm sure = you mean that the worse failure occurs in the original topology (not in the= MRT).  Please clarify.
      2.
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
    [CB] new text to clarify.
    = Once traffic has been
    =    moved to one of the MRTs by one PLR, that traffic is not subje= ct to
    =    further repair actions by another PLR, even in the event of mu= ltiple
    =    simultaneous failures.  Therefore, traffic repaired by MR= T-FRR will
    =    not loop between different PLRs responding to different simult= aneous
    =    failures.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Multicast protection is out= of scope, right?  There's a reference to I-D.atlas-rtgwg-mrt-mc-arch = in the Introduction (which is fine), but not explicit indication of the sco= pe.  Section 8.1. (MRT Profile Options) also talks about multicast then describing "MRT Forwarding Mechanism&q= uot; ("The None option in may be useful for multicast global protectio= n.").
    • In Section 8.1. (MRT Profil= e Options), is the "Area/Level Border Behavior" specific to multi= cast?  BTW, please avoid describing the options with questions.
      •
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [CB]  Area Border behavior is not specific to= multicast.  I removed the confusing reference to [I-D.atlas-rtgwg-mrt= -mc-arch] in section 8.1
    [CB] I made several edits throughout to clarify th= at multicast is out of scope.
    Diff for minor issues 1 and 2 is found here.
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Section 1.1. (Importance of= 100% Coverage) talks about how micro-loop prevention is something that can= be achieved with complete coverage, and Section 12. (Network Convergence a= nd Preparing for the Next Failure) says it is something that needs attention after a failure, but then the doc= ument doesn't say how MRT can be used:  the use of MRT (to support Far= side Tunneling) is declared out of scope, and an "orphan" stateme= nt (no references and no solution) about micro-loop mitigation is made ("Micro-loop mitigation mechanisms can also work wh= en combined with MRT.").
    • Section 12.1. (Micro-f= orwarding loop prevention and MRTs) does say that "Managing micro-loop= s is an orthogonal issue to having alternates for local repair…&= quot;, but I think you need to explain some more about how micro-loops may not be an issue or how MRT helps.
      •
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [CB] I rewrote section 12.1 to clarify, and added = small edits elsewhere.  Complete diff below.
    = 12.1.  Micro-loop prevention and MRTs
    =  
    =    A micro-loop is a transient packet forwarding loop among two o= r more
    =    routers that can occur during IGP convergence.  [RFC5715]= discusses
    =    several techniques for preventing micro-loops.  This sect= ion
    =    discusses how MRT-FRR relates to two of the micro-loop prevent= ion
    =    techniques discussed in [RFC5715], Nearside Tunneling and Fars= ide
    =    Tunneling.
    =  
    =    In Nearside Tunneling, a router (PLR) adjacent to a failure pe= rform
    =    local repair and inform remote routers of the failure.  T= he remote
    =    routers initially tunnel affected traffic to the nearest PLR, = using
    =    tunnels which are unaffected by the failure.  Once the fo= rwarding
    =    state for normal shortest path routing has converged, the remo= te
    =    routers return the traffic to shortest path forwarding.  = MRT-FRR is
    =    relevant for Nearside Tunneling for the following reason. = ; The
    =    process of tunneling traffic to the PLRs and waiting a suffici= ent
    =    amount of time for IGP forwarding state convergence with Nears= ide
    =    Tunneling means that traffic will generally be relying on the = local
    =    repair at the PLR for longer than it would in the absence of N= earside
    =    Tunneling.  Since MRT-FRR provides 100% coverage for sing= le link and
    =    node failure, it may be an attractive option to provide the lo= cal
    =    repair paths when Nearside Tunneling is deployed.
    =  
    =    MRT-FRR is also relevant for the Farside Tunneling micro-loop<= /span>
    =   prevention technique.  In Farside Tunneling, remote routers tun= nel
    =   traffic affected by a failure to a node downstream of the failure
    =   with respect to traffic destination.  This node can be viewed a= s
    =    being on the farside of the failure with respect to the node
    =    initiating the tunnel.  Note that the discussion of Farsi= de Tunneling
    =    in [RFC5715] focuses on the case where the farside node is
    =    immediately adjacent to a failed link or node.  However, = the farside
    =    node may be any node downstream of the failure with respect to=
    =    traffic destination, including the destination itself.  T= he tunneling
    =    mechanism used to reach the farside node must be unaffected by= the
    =    failure.  The alternative forwarding paths created by MRT= -FRR have
    =    the potential to be used to forward traffic from the remote ro= uters
    =    upstream of the failure all the way to the destination.  = In the event
    =    of failure, either the MRT-Red or MRT-Blue path from the remot= e
    =    upstream router to the destination is guaranteed to avoid a li= nk
    =    failure or inferred node failure.  The MRT forwarding pat= hs are also
    =    guaranteed to not be subject to micro-loops because they are l= ocked
    =    to the topology before the failure.
    =  
    =    We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algor= ithm]
    =    address the case of a PLR adjacent to a failure determining wh= ich
    =    choice of MRT-Red or MRT-Blue will avoid a failed link or node= .  More
    =    computation may be required for an arbitrary remote upstream r= outer
    =    to determine whether to choose MRT-Red or MRT-Blue for a given=
    =    destination and failure.
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
    1. Section 6.3. (Forwarding IP= Unicast Traffic over MRT Paths) says that, for IP forwarding "consist= ency with LDP is RECOMMENDED".  Why?  I'm guessing it might = be simpler to be consistent if both LDP and IP traffic are being repaired, but what about IP-only networks?
      2.
    [CB] I deleted the recommendation.
    1. Section 7.3.1. (Existing IG= P exclusion mechanisms)
    • "In OSPF…a metri= c of 2^16-1 (0xFFFF)…"   RFC6987 defined a constant called = MaxLinkMetric.
    • "&#= 8230;to prevent transit traffic from using a particular router…[RFC69= 87] specifies setting all outgoing interface metrics to 0xFFFF" -- tha= t won't prevent traffic through the router if it's the only path, look at t= he R-bit in OSPFv3; for OSPFv2, I think the latest attempt is draft-ietf-ospf-= ospfv2-hbit.
    • All this d= oesn't result in an incorrect behavior per the rules at the end of this sec= tion.
      •
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
    [CB] I added text about the OSPFv3 V6-bit and R-bi= t and clarified how MaxLinkMetric only discourages transit traffic. =
    =    For OSPFv2 and OSPFv3, [RFC6987] specifies setting all outgoin= g
    =    interface metrics to 0xFFFF to discourage transit traffic from= using
    =    a router.( [RFC6987] defines the metric value 0xFFFF as=
    =    MaxLinkMetric, a fixed architectural value for OSPF.)  Fo= r OSPFv3,
    =    [RFC5340] specifies that a router be excluded from the intra-a= rea
    =    shortest path tree computation if the V6-bit or R-bit of the L= SA
    =    options is not set in the Router LSA.
    =  
    =    The following rules for MRT Island formation ensure that MRT F= RR
    =    protection traffic does not use a link or router that is disco= uraged
    =    or prevented from carrying traffic by existing IGP mechanisms.=
    =  
    =    1.  A bidirectional link MUST be excluded from an MRT Isl= and if
    =        either the forward or reverse cost on = the link is 0xFFFFFE (for
    =        ISIS) or 0xFFFF for OSPF.
    =  
    =    2.  A router MUST be excluded from an MRT Island if it is= advertised
    =        with the overload bit set (for ISIS), = or it is advertised with
    =        metric values of 0xFFFF on all of its = outgoing interfaces (for
    =        OSPFv2 and OSPFv3).
    =  
    =    3.  A router MUST be excluded from an MRT Island if it is= advertised
    =        with either the V6-bit or R-bit of the= LSA options not set in the
    =        Router LSA.
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
    [CB] Diff for minor 4-5. 
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
    1. Section 8.3. (Default = MRT profile): s/priority/GADAG Root Selection Priority
      2.
    [CB]  Done.
    1. Section 10. (Inter-are= a Forwarding Behavior)  Are there cases where it is ok (or even desira= ble) to keep the traffic in MRT-Red/Blue?  The circumstantial case whe= re independent failures occur in different areas sounds like one where the traffic shouldn't be forwarded onto the default t= opology by the ABR — but this is a case where the ABR is th= e entry point to a new repair.  Are there others?  I'm just wonde= ring why this Section doesn't commit (s/should/SHOULD or even MUST) to saying that the traffic has to be taken off an MRT at an ABR.
      2. =
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
    [CB] For unicast FRR, I can’t think of a sce= nario where one would want to stay on the red or blue MRT after crossing ar= ea borders.    For multicast distribution on MRTs, it may be useful to stay on red or blue across borders.  The def= ault MRT profile specifies ABRs/LBRs SHOULD ensure that traffic leaving the= area also exits the MRT-Red or MRT-Blue forwarding topology.  I think= the draft can be somewhat less strict about this requirement because different behavior by some ABRs won’t cause = routing loops or lost traffic, but I’m open to changes here if you th= ink it makes sense.
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Section 12.2. (MRT Rec= alculation for the Default MRT Profile) includes in the MRT recalculation s= equence "a configured (or advertised) period".  Even th= ough this Section talks only about the Default MRT Profile, it seems to me that a "recalculation timer" might be a nice thing= s to have as part of any MRT Profile.
    • I peeked at the algorithm I= D and didn't find a timer defined there either.
      •
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
    [CB]  Extensions are defined in draft-ietf-os= pf-mrt and draft-ietf-isis-mrt so I added this text.
    =    New protocol extensions for advertising the time needed to rec= ompute
    =    shortest path routes and install them in the FIB will be defin= ed
    =    elsewhere.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     
    Nits:=
    1. Please put a reference to S= ection 7 (?) in 1.2  when talking about MRT Islands.
    2. "Any RT is an MRT but many MRTs are= not RTs."  Counterintuitive since it sounds like an MRT is the m= aximal version of an RT.
      3.
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
    [CB]  Rewrote these definitions to clarify.
    =    Redundant Trees (RT):   A pair of trees where the pa= th from any node
    =       X to the root R along the first tree is node= -disjoint with the
    =       path from the same node X to the root along = the second tree.
    =       Redundant trees can always be computed in 2-= connected graphs.
    =  
    =    Maximally Redundant Trees (MRT):   A pair of trees w= here the path
    =       from any node X to the root R along the firs= t tree and the path
    =       from the same node X to the root along the s= econd tree share the
    =       minimum number of nodes and the minimum numb= er of links.  Each
    =       such shared node is a cut-vertex.  Any = shared links are cut-links.
    =       In graphs that are not 2-connected, it is no= t possible to compute
    =       RTs.  However, it is possible to comput= e MRTs.  MRTs are maximally
    =       redundant in the sense that they are as redu= ndant as possible
    =       given the constraints of the network graph.<= /span>
    =  
    = [CB] Also took the opportunity to re-order the terminology section.<= /font>
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Please expand on first use:= SPT, PLR, MT-ID
      2.
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [CB] Diff for nits 1-3:
    =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    1. Some substitutions:
    • s/it is used to described/i= t is used to describe
    • s= /choice of tunnel egress MAY be flexible/choice of tunnel egress is flexibl= e
    • s/either IPv4 and IPv= 6/either IPv4 or IPv6
    • s= /Forwarding Mechanisms( MRT/Forwarding Mechanisms (MRT
    • s/The key difference is whether the traffic= , once out of the MRT Island, remains in the same area/level and…= ;/The key difference is whether the traffic, once out of the MRT Islan= d, remains in the same area/level or…
      •
    1. "…we will use th= e terms area and ABR to indicate either an OSPF area and OSPF ABR or I= SIS level and ISIS LBR", but then you use ABR/LBR and area/level = anyway.  Suggestion: generalize to domain and DBR, define it in the terminology..
    2. Sh= ouldn't there be a reference to Appendix A somewhere in Section 11?
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     
     
     --_000_BY2PR05MB61465BA37FE49CCECF3B1DDA9C80BY2PR05MB614namprd_-- From nobody Sun Jan 10 09:57:52 2016 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 868691ACD41; Sun, 10 Jan 2016 09:57:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-rtgwg-mrt-frr-algorithm-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160110175749.16566.58037.idtracker@ietfa.amsl.com> Date: Sun, 10 Jan 2016 09:57:49 -0800 Archived-At: Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 17:57:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : An Algorithm for Computing Maximally Redundant Trees for IP/LDP Fast-Reroute Authors : Gábor Sándor Enyedi András Császár Alia Atlas Chris Bowers Abishek Gopalan Filename : draft-ietf-rtgwg-mrt-frr-algorithm-08.txt Pages : 116 Date : 2016-01-10 Abstract: A solution for IP and LDP Fast-Reroute using Maximally Redundant Trees is presented in draft-ietf-rtgwg-mrt-frr-architecture. This document defines the associated MRT Lowpoint algorithm that is used in the Default MRT profile to compute both the necessary Maximally Redundant Trees with their associated next-hops and the alternates to select for MRT-FRR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-algorithm/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-algorithm-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-algorithm-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 10 10:02:03 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3066F1ACE68; Sun, 10 Jan 2016 10:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR5fb2f2pqOv; Sun, 10 Jan 2016 10:01:51 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433BA1A88D4; Sun, 10 Jan 2016 10:01:51 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB613.namprd05.prod.outlook.com (10.141.218.145) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sun, 10 Jan 2016 18:01:45 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0361.006; Sun, 10 Jan 2016 18:01:45 +0000 From: Chris Bowers To: "Alvaro Retana (aretana)" , "draft-ietf-rtgwg-mrt-frr-algorithm@ietf.org" Subject: RE: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07 Thread-Topic: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07 Thread-Index: AQHRRV7dgEWOmft+i0q5eg7hbSc74p7rnG7Q Date: Sun, 10 Jan 2016 18:01:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BY2PR05MB613; 5:i0np9UH4vx3FqhhNbtEHLGxjFCoamFA4//tm71C1J5IDnffbs8A10+4EtGNn6FrmoiRpVV0uhyGOgb9hG1ztoX53UzAqLHoNcYmywMCjaUqm6cjSeNR6Y0zIsoYOY7NDXMwO+woCvLog7QRIXb1rwQ==; 24:sv2RFOPf6okS8CFMCn2bbVfjGoVene2/dFBrLsgSyuTVksYSNSIu63aKmuz4TNHg7mpb5RLfdY4LsB8pKKPmAIKwig3PsFV3ekuOXy+iK+w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB613; x-ms-office365-filtering-correlation-id: 23839f48-6fbb-4978-3866-08d319e81a89 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR05MB613; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB613; x-forefront-prvs: 0817737FD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(164054003)(189002)(199003)(377454003)(6116002)(19580405001)(87936001)(19580395003)(50986999)(76176999)(66066001)(33656002)(19300405004)(54356999)(19625215002)(86362001)(11100500001)(586003)(5003600100002)(10400500002)(15975445007)(40100003)(5004730100002)(77096005)(2900100001)(2501003)(4326007)(92566002)(575784001)(2906002)(2950100001)(5008740100001)(1096002)(106116001)(101416001)(230783001)(97736004)(122556002)(99286002)(102836003)(5001770100001)(106356001)(1220700001)(790700001)(5002640100001)(3846002)(81156007)(19617315012)(5001960100002)(189998001)(16236675004)(74316001)(76576001)(105586002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB613; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR05MB614E1B79923021EB4BCE996A9C80BY2PR05MB614namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2016 18:01:45.5648 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB613 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 18:02:00 -0000 --_000_BY2PR05MB614E1B79923021EB4BCE996A9C80BY2PR05MB614namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alvaro, Thanks for your detailed feedback. I've posted a new revision incorporati= ng your comments. The new revision is here. https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-mrt-frr-algorithm-08.= txt The diff is here. https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-mrt-frr-algorithm-08 See specific responses and text inline with [CB]. I also included links to diffs on github containing the XML edits addressin= g particular issues or set of issues. They are intended to help in reviewi= ng the edits, but refer to the version submitted for the latest definitive = revision. Thanks, Chris From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Saturday, January 02, 2016 7:10 AM To: draft-ietf-rtgwg-mrt-frr-algorithm@ietf.org Cc: rtgwg@ietf.org; rtgwg-chairs@ietf.org; Janos Farkas Subject: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07 Hi! I just finished reviewing this document. I have several comments (below) t= hat I want to see addressed before starting the IETF Last Call. As with draft-ietf-rtgwg-mrt-frr-architecture, my main point of concern is = related to operational/management considerations - the Architecture documen= t should carry the load of these considerations, but there are some that I = think are algorithm-specific and should be included here. Thanks! Alvaro. Major: 1. Operational/Management Considerations * Section 1. (Introduction): "This document defines an algorithm for= selecting an appropriate MRT alternate for consideration. Other alternate= s, e.g. LFAs that are downstream paths, may be preferred when available an= d that policy-based alternate selection process [I-D.ietf-rtgwg-lfa-managea= bility] is not captured in this document." This paragraph seems to say tha= t the criteria in I-D.ietf-rtgwg-lfa-manageability applies also to the sele= ction between MRT alternates and others. Is that the intent? * Later in Section 5.4. (Initialization) you mention the criteria= in I-D.ietf-rtgwg-lfa-manageability applied to MRT ("Due to FRR manageabil= ity considerations [I-D.ietf-rtgwg-lfa-manageability], it may also be desir= able to administratively configure some interfaces as ineligible to carry M= RT FRR traffic."). * I mention all this because I-D.ietf-rtgwg-lfa-manageability is = listed as an Informative Reference both in this document and in draft-ietf-= rtgwg-mrt-frr-architecture (where there's just a light mention of manageabi= lity). If the criteria/recommendations in I-D.ietf-rtgwg-lfa-manageability= are to be followed, then I would like to see a stronger statement about it= . [There is a corresponding comment included in my review of draft-ietf-rt= gwg-mrt-frr-architecture.] * I'm surprised that there are no Operational Considerations in this= document. I am hoping to see general considerations in draft-ietf-rtgwg-m= rt-frr-architecture, but some of the specifics are clearly algorithm relate= d - the resulting length of the alternate path, for example. Please includ= e an Operational Considerations section where some of the guidance given in= the document can be reflected, for example: * Section 5.3. (GADAG Root Selection) "Analysis has shown that t= he centrality of a router can have a significant impact on the lengths of t= he alternate paths computed. Therefore, it is RECOMMENDED that off-line an= alysis that considers the centrality of a router be used to help determine = how good a choice a particular router is for the role of GADAG root." * Section 9. (Algorithm Alternatives and Evaluation) "In additio= n, it is possible to calculate Destination-Rooted GADAG...Building GADAGs p= er destination is computationally more expensive, but may give somewhat sho= rter alternate paths. It may be useful for live-live multicast along MRTs.= " * [[Minor] BTW, it looks like multicast is outside the scope of d= raft-ietf-rtgwg-mrt-frr-architecture. That doesn't mean that the algorithm= may not be useful for it - but Section 9 is the only place that multicast = is mentioned.] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D [CB] I created the operational considerations section (copied below). So= me material could go in either this or the Operational Considerations secti= on of the architecture draft, so we could still shift items to or from that= section. I also removed the references to [I-D.ietf-rtgwg-lfa-manageabi= lity] and made edits to have the text stand on its own. The diff of change= s addressing the above issues is: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/9a18f3= 00dfddcc0829c980393f0e39eeb19b3813 10. Operational Considerations This sections discusses operational considerations related to the the MRT Lowpoint algorithm and other potential MRT algorithm variants. For a discussion of operational considerations related to MRT-FRR in general, see the Operational Considerations section of [I-D.ietf-rtgwg-mrt-frr-architecture]. 10.1. GADAG Root Selection The Default MRT Profile uses the GADAG Root Selection Priority advertised by routers as the primary criterion for selecting the GADAG root. It is RECOMMENDED that an operator designate a set of routers as good choices for selection as GADAG root by setting the GADAG Root Selection Priority for that set of routers to lower (more preferred) numerical values. Criteria for making this designation are discussed below. Analysis has shown that the centrality of a router can have a significant impact on the lengths of the alternate paths computed. Therefore, it is RECOMMENDED that off-line analysis that considers the centrality of a router be used to help determine how good a choice a particular router is for the role of GADAG root. If the router currently selected as GADAG root becomes unreachable in the IGP topology, then a new GADAG root will be selected. Changing the GADAG root can change the overall structure of the GADAG as well the paths of the red and blue MRT trees built using that GADAG. In order to minimize change in the associated red and blue MRT forwarding entries that can result from changing the GADAG root, it is RECOMMENDED that operators prioritize for selection as GADAG root those routers that are expected to consistently remain part of the IGP topology. 10.2. Destination-rooted GADAGs The MRT Lowpoint algorithm constructs a single GADAG rooted at a single node selected as the GADAG root. It is also possible to construct a different GADAG for each destination, with the GADAG rooted at the destination. A router can compute the MRT-Red and MRT- Blue next-hops for that destination based on the GADAG rooted at that destination. Building a different GADAG for each destination is computationally more expensive, but it may give somewhat shorter alternate paths. Using destination-rooted GADAGs would require a new MRT profile to be created with a new MRT algorithm specification, since all routers in the MRT Island would need to use destination- rooted GADAGs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 1. Section 3. (Terminology and Definitions) Not all the common terms be= tween this document and draft-ietf-rtgwg-mrt-frr-architecture are defined t= he same way. Some differences are indeed small, but to avoid confusion and= misinterpretation please be consistent. Suggestion: include in this docum= ent only the terms that were not present in draft-ietf-rtgwg-mrt-frr-archit= ecture. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Agreed. Changes in this diff. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/d70e29= a9d775f759b7ba21f4fcc8a9ddc3c55fc9 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. References to Extensions. This document describes an algorithm to be= used in the MRT Architecture..as such, please leave mention of the extensi= ons/specific solutions out - as those other drafts progress the picture wil= l be complete. Some pointers: * All references to I-D.ietf-ospf-mrt and I-D.ietf-isis-mrt. * Section 5.4. (Initialization): "This constraint MUST be consistent= ly flooded via the IGP [I-D.ietf-ospf-mrt] [I-D.ietf-isis-mrt]...so that li= nks are known to be MRT-ineligible..." I'm venturing to say that the requ= irement here is for all the routers in the area/level/island to have this i= nformation, while the specific mechanism (IGP flooding, magic central box, = manual configuration, etc.) is an implementation detail. I fully understan= d that IGP flooding may be the best/obvious choice and that implementations= are being worked in that direction, but I think that's the job of the exte= nsion drafts (to indicate how to meet the requirement with IGP flooding, or= the magic box, or etc..). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Removal of references is done in this diff: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/87f2ca= 3e340d372dd46898a9f39de2a6bd7197c4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Section 9.1. (Algorithm Evaluation) I am disappointed that you chose= not to focus this section on MRT Algorithm Alternatives and Evaluation, an= d instead decided to compare MRT with solutions that don't provide complete= coverage - and kicked off the discussion precisely with the coverage (Figu= re 30). Please remove the comparison to other technologies that are not po= tential MRT algorithms. * Later in the text you do get back to data specific to the Lowpoint= Algorithm and the ones described in the Appendixes. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] Done is this diff. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/561365= b49d04c65f9b98313de88ded0520f71340 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minor: 1. Other algorithms. In several places general statements about algorit= hms for MRT are made - I'm assuming that you are referring to the algorithm= s mentioned/considered in this document (and not making statements about ot= her yet-to-be-known algorithms), is that correct? If so, please be clear a= bout it. Here are some examples: * 1. (Introduction): "Algorithms for computing MRTs can handle arbit= rary network topologies..." * 4. (Algorithm Key Concepts): "There are five key concepts that are= critical for understanding...other algorithms for computing MRTs." * 9. (Algorithm Alternatives and Evaluation) "This specification def= ines the MRT Lowpoint Algorithm, which is one option among several possible= MRT algorithms. Other alternatives are described in the appendices." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D [CB] Done in diff below. Also changed title to "An Algorithm" as opposed = to "Algorithms" to focus on MRT Lowpoint algorithm. I also changes several= references to "algorithm" to "GADAG construction method" to avoid ambiguit= y. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/54c28c= 2206d7aa8844dd01fce9940fc15b323220 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 1. Section 5. (Algorithm Sections) s/This algorithm/The MRT Lowpoint al= gorithm 2. Section 5.1. (Interface Ordering) * Why are the values in Figure 15 for ISIS-PCR not considered Normat= ive? * I'm a little bit confused because the Interface_Compare functio= n depends on the values; what happens if the values received are not the ex= pected ones? For ISIS-PRC, can I use some other source for those values? * [I took a quick peek at draft-ietf-isis-pcr, but didn't find a = mention of MRT Node ID, for example.] * The last paragraph in this Section seems superfluous to me as it d= oesn't add/change anything. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D [CB] I changed the reference to 802.1Qca, where the normative reference is = found in clause 45.3.3., and pointed out that the normative reference is th= ere. The goal is to have the normative reference only defined in one place= . Done in this diff. https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/ef39e5= 99f305713825aa9f65e4445478eec40a80 The Interface_Compare function in Figure 14 relies on the interface.metric and the interface.neighbor.mrt_node_id values to order interfaces. The exact source of these values for different IGPs and applications is specified in Figure 15. The metric and mrt_node_id values for OSPFv2, OSPFv3, and IS-IS provided here is normative. The metric and mrt_node_id values for ISIS-PCR in this table should be considered informational. The normative values are specified in [IEEE8021Qca] . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Nits: 1. I would put the Python code in an Appendix. [CB] Done. --_000_BY2PR05MB614E1B79923021EB4BCE996A9C80BY2PR05MB614namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Alvaro,

     

    Thanks for your detailed feedback.&nb= sp; I’ve posted  a new revision incorporating your comments.

     

    The new revision is here.<= /span>

    https://www.ietf.org/= internet-drafts/draft-ietf-rtgwg-mrt-frr-algorithm-08.txt

     

    The diff is here.

    https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-rtgwg-mrt-frr-algorithm-08

     

    See specific responses and text inlin= e with [CB]. 

     

    I also included links to diffs on git= hub containing the XML edits addressing particular issues or set of issues.=   They are intended to help in reviewing the edits, but refer to the version submitted for the latest definitive revision.&nbs= p;

     

    Thanks,

    Chris

     

    From: Alvaro Retana (aretana) [mailt= o:aretana@cisco.com]
    Sent: Saturday, January 02, 2016 7:10 AM
    To: draft-ietf-rtgwg-mrt-frr-algorithm@ietf.org
    Cc: rtgwg@ietf.org; rtgwg-chairs@ietf.org; Janos Farkas <janos.fa= rkas@ericsson.com>
    Subject: AD Review of draft-ietf-rtgwg-mrt-frr-algorithm-07

     

    Hi!

     

    I just finished reviewing this document= .  I have several comments (below) that I want to see addressed before= starting the IETF Last Call.

     

    As with draft-ietf-rtgwg-mrt-frr-a= rchitecture, my main point of concern is related to operational/management = considerations — the Architecture document should carry the load of these considerations, but there are some that I think are algo= rithm-specific and should be included here.

     

    Thanks!

     

    Alvaro.

     

    Major:

    1. Operational/Management Considerations
      • Section 1. (Introduction): "This document defines an algorithm f= or selecting an appropriate MRT alternate for consideration.  Oth= er alternates, e.g.  LFAs that are downstream paths, may be prefe= rred when available and that policy-based alternate selection process [I-D.ietf= -rtgwg-lfa-manageability] is not captured in this document." &nbs= p;This paragraph seems to say that the criteria in I-D.ietf-rtgwg-lfa-= manageability applies also to the selection between MRT alternates and others.  Is that the intent?  
        • Later in Section 5.4. (Initialization) you mention the criteria in&nb= sp;I-D.ietf-rtgwg-lfa-manageability applied to MRT ("Due to FRR manage= ability considerations [I-D.ietf-rtgwg-lfa-manageability], it may also be desirable to administratively configure some interfaces as = ineligible to carry MRT FRR traffic.").   =
        • I mention all this because I-D.ietf-rtgwg-lfa-manageability is listed as a= n Informative Reference both in this document and in draft-ietf-rtgwg-= mrt-frr-architecture (where there's just a light mention of manageability).  If the criteria/recommendations in I= -D.ietf-rtgwg-lfa-manageability are to be followed, then I would like to se= e a stronger statement about it.  [There is a corresponding comment in= cluded in my review of draft-ietf-rtgwg-mrt-frr-architecture.]
      • I'm surprised that there are no Operational Considerations in this documen= t.  I am hoping to see general considerations in draft-ietf-rtgwg= -mrt-frr-architecture, but some of the specifics are clearly algorithm related — the resulting length of the alternate = path, for example.  Please include an Operational Considerations secti= on where some of the guidance given in the document can be reflected, for e= xample:
        • Section 5.3. (GADAG Root Selection)  "Analysis has shown th= at the centrality of a router can have a significant impact on the len= gths of the alternate paths computed.  Therefore, it is RECOMMENDED that off-line analysis that considers the centrality of a router be u= sed to help determine how good a choice a particular router is for the= role of GADAG root."
        • Section 9. (Algorithm Alternatives and Evaluation)  "In add= ition, it is possible to calculate Destination-Rooted GADAG…Building = GADAGs per destination is computationally more expensive, but may give somewhat shorter alternate paths.  It may be useful for liv= e-live multicast along MRTs."
        • [[Minor] BTW, it looks like multicast is outside the scope of draft-i= etf-rtgwg-mrt-frr-architecture.  That doesn't mean that the algorithm = may not be useful for it — but Section 9 is the only place that multicast is mentioned.]

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

    [CB]  I created the operational considerations s= ection (copied below).   Some material could go in either this or the Operational Considerations section of the architecture draft, = so we could still shift items to or from that section.   I also r= emoved the references to  [I-D.ietf-rtgwg-lfa-manageability] and made = edits to have the text stand on its own.  The diff of changes addressing the above issues is:

    https:= //github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/9a18f300dfdd= cc0829c980393f0e39eeb19b3813

    10.  Operational Considerations

     

       This sections discusses operational considera= tions related to the the

       MRT Lowpoint algorithm and other potential MR= T algorithm variants.

       For a discussion of operational consideration= s related to MRT-FRR in

       general, see the Operational Considerations s= ection of

       [I-D.ietf-rtgwg-mrt-frr-architecture].

     

    10.1.  GADAG Root Selection

     

       The Default MRT Profile uses the GADAG Root S= election Priority

       advertised by routers as the primary criterio= n for selecting the

       GADAG root.  It is RECOMMENDED that an o= perator designate a set of

       routers as good choices for selection as GADA= G root by setting the

       GADAG Root Selection Priority for that set of= routers to lower (more

       preferred) numerical values.  Criteria f= or making this designation

       are discussed below.

     

       Analysis has shown that the centrality of a r= outer can have a

       significant impact on the lengths of the alte= rnate paths computed.

       Therefore, it is RECOMMENDED that off-line an= alysis that considers

       the centrality of a router be used to help de= termine how good a

       choice a particular router is for the role of= GADAG root.

     

       If the router currently selected as GADAG roo= t becomes unreachable in

       the IGP topology, then a new GADAG root will = be selected.  Changing

       the GADAG root can change the overall structu= re of the GADAG as well

       the paths of the red and blue MRT trees built= using that GADAG.  In

       order to minimize change in the associated re= d and blue MRT

       forwarding entries that can result from chang= ing the GADAG root, it

       is RECOMMENDED that operators prioritize for = selection as GADAG root

       those routers that are expected to consistent= ly remain part of the

       IGP topology.

     

    10.2.  Destination-rooted GADAGs

     

       The MRT Lowpoint algorithm constructs a singl= e GADAG rooted at a

       single node selected as the GADAG root. = It is also possible to

       construct a different GADAG for each destinat= ion, with the GADAG

       rooted at the destination.  A router can= compute the MRT-Red and MRT-

       Blue next-hops for that destination based on = the GADAG rooted at that

       destination.  Building a different GADAG= for each destination is

       computationally more expensive, but it may gi= ve somewhat shorter

       alternate paths.  Using destination-root= ed GADAGs would require a new

       MRT profile to be created with a new MRT algo= rithm specification,

       since all routers in the MRT Island would nee= d to use destination-

       rooted GADAGs.

     

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    1. Section 3. (Terminology and Definitions)  Not all the common terms be= tween this document and draft-ietf-rtgwg-mrt-frr-architecture are defi= ned the same way.  Some differences are indeed small, but to avoid confusion and misinterpretation please be consistent.  S= uggestion: include in this document only the terms that were not present in=  draft-ietf-rtgwg-mrt-frr-architecture.

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    [CB] Agreed.  Changes in this diff.=

    https:= //github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/d70e29a9d775= f759b7ba21f4fcc8a9ddc3c55fc9

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    1. References to Extensions.  This document describes an algorithm to be= used in the MRT Architecture..as such, please leave mention of the extensi= ons/specific solutions out — as those other drafts progress the picture will be complete.  Some pointers:
      • All references to I-D.ietf-ospf-mrt and I-D.ietf-isis-mrt.
      • Section 5.4. (Initialization): "This constraint MUST be consiste= ntly flooded via the IGP [I-D.ietf-ospf-mrt] [I-D.ietf-isis-mrt]…= ;so that links are known to be MRT-ineligible…"   I'm = venturing to say that the requirement here is for all the routers in the area/level/isl= and to have this information, while the specific mechanism (IGP flooding, m= agic central box, manual configuration, etc.) is an implementation detail. =  I fully understand that IGP flooding may be the best/obvious choice and that implementations are being worked i= n that direction, but I think that's the job of the extension drafts (= to indicate how to meet the requirement with IGP flooding, or the magic box= , or etc..).

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    [CB]  Removal of references is done in this diff= :

    https:= //github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/87f2ca3e340d= 372dd46898a9f39de2a6bd7197c4

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    1. Section 9.1. (Algorithm Evaluation)  I am disappointed = ;that you chose not to focus this section on MRT Algorithm Alternative= s and Evaluation, and instead decided to compare MRT with solutions that don't provide complete coverage — and kicked off the = discussion precisely with the coverage (Figure 30).  Please remov= e the comparison to other technologies that are not potential MRT algorithm= s.
      • Later in the text you do get back to data specific to the Lowpoint Algorit= hm and the ones described in the Appendixes. 

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

    [CB]  Done is this diff.

    https:= //github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/561365b49d04= c65f9b98313de88ded0520f71340

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

    Minor:

    1. Other algorithms.  In several places general statements about algorit= hms for MRT are made — I'm assuming that you are referring to the alg= orithms mentioned/considered in this document (and not making statements about other yet-to-be-known algorithms), is that correct= ?  If so, please be clear about it.  Here are some examples:
      • 1. (Introduction): "Algorithms for computing MRTs can handle arbitrar= y network topologies…"
      • 4. (Algorithm Key Concepts): "There are five key concepts that are cr= itical for understanding…other algorithms for computing MRTs."
      • 9. (Algorithm Alternatives and Evaluation) "This specification define= s the MRT Lowpoint Algorithm, which is one option among several possib= le MRT algorithms.  Other alternatives are described in the appendices."

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    [CB]  Done in diff below.  Also changed tit= le to “An Algorithm” as opposed to “Algorithms” to = focus on MRT Lowpoint algorithm.  I also changes several references to “= algorithm” to “GADAG construction method” to avoid ambigu= ity.

    https:= //github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/54c28c2206d7= aa8844dd01fce9940fc15b323220

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    1. Section 5. (Algorithm Sections)  s/This algorithm/The MRT Lowpoi= nt algorithm
    2. Section 5.1. (Interface Ordering)  
      • Why are the values in Figure 15 for ISIS-PCR not considered Normative?
        • I'm a little bit confused because the Interface_Compare function depends o= n the values; what happens if the values received are not the expected ones= ?  For ISIS-PRC, can I use some other source for those values?
        • [I took a quick peek at draft-ietf-isis-pcr, but didn't find a mentio= n of MRT Node ID, for example.]
      • The last paragraph in this Section seems superfluous to me as it doesn't a= dd/change anything.

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    [CB] I changed the reference to 802.1Qc= a, where the normative reference is found in clause 45.3.3., and pointed ou= t that the normative reference is there.  The goal is to have the normative reference only defined in one place.

    Done in this diff.

    https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commi= t/ef39e599f305713825aa9f65e4445478eec40a80

     

     
       The Interface_Compare function in Figure 14 relies on the=

       interface.metric and the interface.neighbor.mrt_node_id v=
alues to
       order interfaces.  The exact source of these values =
for different
       IGPs and applications is specified in Figure 15.  Th=
e metric and
       mrt_node_id values for OSPFv2, OSPFv3, and IS-IS provided=
 here is
       normative.  The metric and mrt_node_id values for IS=
IS-PCR in this
       table should be considered informational.  The norma=
tive values are
       specified in [IEEE8021Qca] .

     

     

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     

    Nits:

    1. I would put the Python code in an Appendix.

    [CB] Done.

    --_000_BY2PR05MB614E1B79923021EB4BCE996A9C80BY2PR05MB614namprd_-- From nobody Sun Jan 10 10:43:39 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6374F1ACE90 for ; Sun, 10 Jan 2016 10:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnsPCZZAxh6x for ; Sun, 10 Jan 2016 10:43:31 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71811ACE8C for ; Sun, 10 Jan 2016 10:43:29 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB616.namprd05.prod.outlook.com (10.141.218.155) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sun, 10 Jan 2016 18:43:26 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0361.006; Sun, 10 Jan 2016 18:43:26 +0000 From: Chris Bowers To: Stewart Bryant , Rob Shakir Subject: RE: WGLC for draft-rtgwg-mrt-frr-architecture Thread-Topic: WGLC for draft-rtgwg-mrt-frr-architecture Thread-Index: AQHRLfTf9mV+PzSAtUyZECDvldWiE57NvqkAgArgcYCAAFy28A== Date: Sun, 10 Jan 2016 18:43:26 +0000 Message-ID: References: <566083D0.1020607@gmail.com> <567A938F.7060409@gmail.com> In-Reply-To: <567A938F.7060409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BY2PR05MB616; 5:xGVOqD9/ej6wjZybi2FPdObeA2CfcqAFQ+B1g81+JWIG/g+5F/2B1kqs9j0c06BkiX5WGw3JSdMB8pGVTDSCChnoO2EpUCqmRnIRJQpSGa0XAk7dhLDJFXvu305cQ7p9MMRttVZTq7B8XQdyFk0COw==; 24:RvbbHBP5WnhIp1T1tl+ZDusdvUtvo+8LwKr9aJsTdfOgIK6v5tOlQCFnfbQjKgOWV8un43lmLXL/TL3Ng6IKTc65wnhr4RJuT41yjlmrelM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB616; x-ms-office365-filtering-correlation-id: 7fb4b8e0-4835-4c91-a839-08d319edecfd x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BY2PR05MB616; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB616; x-forefront-prvs: 0817737FD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52604005)(377454003)(189002)(479174004)(51444003)(199003)(24454002)(164054003)(13464003)(189998001)(2950100001)(5003600100002)(77096005)(586003)(97736004)(5004730100002)(230783001)(1096002)(101416001)(4326007)(2900100001)(105586002)(74316001)(11100500001)(87936001)(40100003)(50986999)(66066001)(19580395003)(106116001)(5002640100001)(3846002)(19300405004)(122556002)(19580405001)(15975445007)(76176999)(16236675004)(1220700001)(92566002)(76576001)(54356999)(5001960100002)(86362001)(106356001)(19625215002)(99286002)(102836003)(33656002)(5001770100001)(81156007)(5008740100001)(2906002)(790700001)(6116002)(10400500002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB616; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR05MB61485BE58B3F2A3CCA10FC8A9C80BY2PR05MB614namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2016 18:43:26.2112 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB616 Archived-At: Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 18:43:37 -0000 --_000_BY2PR05MB61485BE58B3F2A3CCA10FC8A9C80BY2PR05MB614namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3Rld2FydCBhbmQgUm9iLA0KDQoNCg0KSSBwdWJsaXNoZWQgYSBuZXcgcmV2aXNpb24gb2YgdGhp cyBkcmFmdCBhdDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmUtMDkudHh0DQoNCg0KDQpUaGUgaW50cm9k dWN0aW9uIGhhcyBxdWl0ZSBhIGZldyBjaGFuZ2VzIHdoZXJlIEkgdHJpZWQgdG8gYWRkcmVzcyBz ZXZlcmFsIG9mIHRoZSBpc3N1ZXMgeW91IHJhaXNlZCBpbmNsdWRpbmcgdGhlIHRhYmxlIGFuZCB0 ZXh0IGNvbXBhcmluZyBkaWZmZXJlbnQgSVAvTERQIEZSUiBtZXRob2RzLiAgIFRoZSBuZXcgdGV4 dCBpcyBjb3BpZWQgYmVsb3cuDQoNCg0KDQpUaGFua3MsDQoNCkNocmlzDQoNCg0KDQo9PT09PT09 PT09PT09PT09PT09PQ0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCg0KDQogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhIHNvbHV0aW9uIGZvciBJUC9MRFAgZmFzdC1yZXJvdXRlIFtSRkM1NzE0XS4N Cg0KICAgTVJULUZSUiBjcmVhdGVzIHR3byBhbHRlcm5hdGUgdHJlZXMgc2VwYXJhdGUgZnJvbSB0 aGUgcHJpbWFyeSBuZXh0LQ0KDQogICBob3AgZm9yd2FyZGluZyB1c2VkIGR1cmluZyBzdGFibGUg b3BlcmF0aW9uLiAgVGhlc2UgdHdvIHRyZWVzIGFyZQ0KDQogICBtYXhpbWFsbHkgZGl2ZXJzZSBm cm9tIGVhY2ggb3RoZXIsIHByb3ZpZGluZyBsaW5rIGFuZCBub2RlIHByb3RlY3Rpb24NCg0KICAg Zm9yIDEwMCUgb2YgcGF0aHMgYW5kIGZhaWx1cmVzIGFzIGxvbmcgYXMgdGhlIGZhaWx1cmUgZG9l cyBub3QgY3V0DQoNCiAgIHRoZSBuZXR3b3JrIGludG8gbXVsdGlwbGUgcGllY2VzLiAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRoZQ0KDQogICBhcmNoaXRlY3R1cmUgZm9yIElQL0xEUCBmYXN0LXJl cm91dGUgd2l0aCBNUlQuDQoNCg0KDQogICBbSS1ELmlldGYtcnRnd2ctbXJ0LWZyci1hbGdvcml0 aG1dIGRlc2NyaWJlcyBob3cgdG8gY29tcHV0ZSBtYXhpbWFsbHkNCg0KICAgcmVkdW5kYW50IHRy ZWVzIHVzaW5nIGEgc3BlY2lmaWMgYWxnb3JpdGhtLCB0aGUgTVJUIExvd3BvaW50DQoNCiAgIGFs Z29yaXRobS4gIFRoZSBNUlQgTG93cG9pbnQgYWxnb3JpdGhtIGlzIHVzZWQgYnkgYSByb3V0ZXIg dGhhdA0KDQogICBJUC9MRFAgRmFzdC1SZXJvdXRlIHdpdGggTVJUIChNUlQtRlJSKSB1c2VzIHR3 byBtYXhpbWFsbHkgZGl2ZXJzZQ0KDQogICBmb3J3YXJkaW5nIHRvcG9sb2dpZXMgdG8gcHJvdmlk ZSBhbHRlcm5hdGVzLiAgQSBwcmltYXJ5IG5leHQtaG9wDQoNCiAgIHNob3VsZCBiZSBvbiBvbmx5 IG9uZSBvZiB0aGUgZGl2ZXJzZSBmb3J3YXJkaW5nIHRvcG9sb2dpZXM7IHRodXMsIHRoZQ0KDQog ICBvdGhlciBjYW4gYmUgdXNlZCB0byBwcm92aWRlIGFuIGFsdGVybmF0ZS4gIE9uY2UgdHJhZmZp YyBoYXMgYmVlbg0KDQogICBtb3ZlZCB0byBvbmUgb2YgdGhlIE1SVHMgYnkgb25lIHBvaW50IG9m IGxvY2FsIHJlcGFpciAoUExSKSwgdGhhdA0KDQogICB0cmFmZmljIGlzIG5vdCBzdWJqZWN0IHRv IGZ1cnRoZXIgcmVwYWlyIGFjdGlvbnMgYnkgYW5vdGhlciBQTFIsIGV2ZW4NCg0KICAgaW4gdGhl IGV2ZW50IG9mIG11bHRpcGxlIHNpbXVsdGFuZW91cyBmYWlsdXJlcy4gIFRoZXJlZm9yZSwgdHJh ZmZpYw0KDQogICByZXBhaXJlZCBieSBNUlQtRlJSIHdpbGwgbm90IGxvb3AgYmV0d2VlbiBkaWZm ZXJlbnQgUExScyByZXNwb25kaW5nDQoNCiAgIHRvIGRpZmZlcmVudCBzaW11bHRhbmVvdXMgZmFp bHVyZXMuDQoNCg0KDQogICBXaGlsZSBNUlQgcHJvdmlkZXMgMTAwJSBwcm90ZWN0aW9uIGZvciBh IHNpbmdsZSBsaW5rIG9yIG5vZGUgZmFpbHVyZSwNCg0KICAgaXQgbWF5IG5vdCBwcm90ZWN0IHRy YWZmaWMgaW4gdGhlIGV2ZW50IG9mIG11bHRpcGxlIHNpbXVsdGFuZW91cw0KDQogICBmYWlsdXJl cywgbm9yIGRvZXMgdGFrZSBpbnRvIGFjY291bnQgU2hhcmVkIFJpc2sgTGluayBHcm91cHMgKFNS TEdzKS4NCg0KICAgQWxzbywgd2hpbGUgdGhlIE1SVCBMb3dwb2ludCBhbGdvcml0aG0gaXMgY29t cHV0YXRpb25hbGx5IGVmZmljaWVudCwNCg0KICAgaXQgaXMgYWxzbyBuZXcuICBJbiBvcmRlciBm b3IgTVJULUZSUiB0byBmdW5jdGlvbiBwcm9wZXJseSwgYWxsIG9mDQoNCiAgIHRoZSBvdGhlciBu b2RlcyBpbiB0aGUgbmV0d29yayB0aGF0IHN1cHBvcnQgTVJUIG11c3QgY29ycmVjdGx5DQoNCiAg IGNvbXB1dGUgbmV4dC1ob3BzIGJhc2VkIG9uIHRoZSBzYW1lIGFsZ29yaXRobSwgYW5kIGluc3Rh bGwgdGhlDQoNCiAgIGNvcnJlc3BvbmRpbmcgZm9yd2FyZGluZyBzdGF0ZS4gIFRoaXMgaXMgaW4g Y29udHJhc3QgdG8gb3RoZXIgRlJSDQoNCiAgIG1ldGhvZHMgd2hlcmUgdGhlIGNhbGN1bGF0aW9u IG9mIGJhY2t1cCBwYXRocyBnZW5lcmFsbHkgaW52b2x2ZXMNCg0KICAgcmVwZWF0ZWQgYXBwbGlj YXRpb24gb2YgdGhlIHNpbXBsZXIgYW5kIHdpZGVseS1kZXBsb3llZCBTUEYNCg0KICAgYWxnb3Jp dGhtLCBhbmQgYmFja3VwIHBhdGhzIHRoZW1zZWx2ZXMgcmUtdXNlIHRoZSBmb3J3YXJkaW5nIHN0 YXRlDQoNCiAgIHVzZWQgZm9yIHNob3J0ZXN0IHBhdGggZm9yd2FyZGluZyBvZiBub3JtYWwgdHJh ZmZpYy4gIFNlY3Rpb24gMTQNCg0KICAgcHJvdmlkZXMgb3BlcmF0aW9uYWwgZ3VpZGFuY2UgcmVs YXRlZCB0byB2ZXJpZmljYXRpb24gb2YgTVJUDQoNCiAgIGZvcndhcmRpbmcgcGF0aHMuDQoNCg0K DQogIEluIGFkZGl0aW9uIHRvIHN1cHBvcnRpbmcgSVAgYW5kIExEUCB1bmljYXN0IGZhc3QtcmVy b3V0ZSwgdGhlDQoNCiAgIGRpdmVyc2UgZm9yd2FyZGluZyB0b3BvbG9naWVzIGFuZCBndWFyYW50 ZWUgb2YgMTAwJSBjb3ZlcmFnZSBwZXJtaXQNCg0KICAgZmFzdC1yZXJvdXRlIHRlY2hub2xvZ3kg dG8gYmUgYXBwbGllZCB0byBtdWx0aWNhc3QgdHJhZmZpYyBhcw0KDQogICBkZXNjcmliZWQgaW4g W0ktRC5hdGxhcy1ydGd3Zy1tcnQtbWMtYXJjaF0uICBIb3dldmVyLCB0aGUgY3VycmVudA0KDQog ICBkb2N1bWVudCBkb2VzIG5vdCBhZGRyZXNzIHRoZSBtdWx0aWNhc3QgYXBwbGljYXRpb25zIG9m IE1SVHMuDQoNCg0KDQogICBGaWd1cmUgMSBjb21wYXJlcyBkaWZmZXJlbnQgbWV0aG9kcyBvZiBw cm92aWRpbmcgRlJSIGZvciBJUCBhbmQgTERQDQoNCiAgIHRyYWZmaWMsIGlsbHVzdHJhdGluZyBz b21lIG9mIHRoZSB0cmFkZS1vZmZzIGJldHdlZW4gdGhlIGRpZmZlcmVudA0KDQogICBhcHByb2Fj aGVzLiAgRm9yIHNldmVyYWwgbWV0aG9kcywgdGhlIG1ldGhvZHMgYXJlIHNlcGFyYXRlZCBpbnRv DQoNCiAgIGxpbmstcHJvdGVjdGluZyAoTFApIGFuZCBub2RlLXByb3RlY3RpbmcgKE5QKSB2YXJp YW50cy4gIFRoZSBmaXJzdA0KDQogICBjb2x1bW4gaW5kaWNhdGVzIHdoZXRoZXIgdGhlIG1ldGhv ZCBwcm92aWRlcyAxMDAlIHByb3RlY3Rpb24gY292ZXJhZ2UNCg0KICAgKHdoZW4gdG9wb2xvZ2lj YWxseSBmZWFzaWJsZSkuICBUaGUgc2Vjb25kIGNvbHVtbiBpbmRpY2F0ZXMgd2hldGhlcg0KDQog ICBvciBub3QgdHJhZmZpYyB0cmF2ZXJzaW5nIGFsdGVybmF0ZSBwYXRoIGNhbiBsb29wIHdoZW4g bXVsdGlwbGUNCg0KICAgZmFpbHVyZXMgb2NjdXIuDQoNCg0KDQogICBUaGUgdGhpcmQgY29sdW1u IGdpdmVzIGFuIGVzdGltYXRlIG9mIHRoZSBhbW91bnQgb2YgY29tcHV0YXRpb24NCg0KICAgcmVx dWlyZWQgYXQgZWFjaCBub2RlIHRvIHN1cHBvcnQgdGhlIEZSUiBtZXRob2QsIGluIGFkZGl0aW9u IHRvIHRoZQ0KDQogICB1c3VhbCBTUEYgY29tcHV0YXRpb24gcm9vdGVkIGF0IHRoZSBjb21wdXRp bmcgbm9kZSBpdHNlbGYuICBUaGlzDQoNCiAgIG1ldHJpYyBvZiBjb21wYXJpc29uIGlzIGltcG9y dGFudCBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgc2VlayB0bw0KDQogICBxdWlja2x5IHJlY29t cHV0ZSByZXBhaXIgcGF0aHMgZm9sbG93aW5nIHRoZWlyIGluaXRpYWwgdXNlIGFmdGVyIGENCg0K ICAgdG9wb2xvZ3kgY2hhbmdlLCB3aXRob3V0IHJlbGlhbmNlIG9uIGFuIGV4dGVybmFsIHN5c3Rl bSwgaW4gb3JkZXIgdG8NCg0KICAgbWluaW1pemUgdGhlIHJpc2sgb2YgYSBuZXcgZmFpbHVyZSBv Y2N1cnJpbmcgYmVmb3JlIHRoZSBuZXcgcmVwYWlyDQoNCiAgIHBhdGhzIGFyZSBpbiBwbGFjZS4N Cg0KDQoNCiAgIFRoZSBmb3VydGggY29sdW1uIGluZGljYXRlcyB0aGUgbWF4aW11bSBudW1iZXIg b2YgYWRkaXRpb25hbCBsYWJlbHMNCg0KICAgdGhhdCBuZWVkIHRvIGJlIGFwcGxpZWQgdG8gcGFj a2V0cyB0byBzdXBwb3J0IHRoZSBGUlIgbWV0aG9kLCB3aGlsZQ0KDQogIHRoZSBmaWZ0aCBjb2x1 bW4gZ2l2ZXMgdGhlIHNpemUgb2YgdGhlIE1QTFMgbGFiZWwgdGFibGUgbmVlZGVkIHRvDQoNCiAg IHN1cHBvcnQgdGhlIEZSUiBtZXRob2QuICBUaGVzZSB0d28gbWV0cmljcyBtYXkgYmUgdXNlZnVs IGZvcg0KDQogICBldmFsdWF0aW5nIHJlcXVpcmVtZW50cyBwbGFjZWQgb24gaGFyZHdhcmUgdG8g c3VwcG9ydCB0aGUgZGlmZmVyZW50DQoNCiAgIEZSUiBtZXRob2RzLg0KDQoNCg0KICAgVGhlIGxh c3QgY29sdW1uIGluZGljYXRlcyB0aGUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgcGxhY2VkIG9u IHRoZQ0KDQogICBjb250cm9sIHBsYW5lIGJ5IHRoZSBGUlIgbWV0aG9kLCBiZXlvbmQgd2hhdCBp cyByZXF1aXJlZCBmb3IgSUdQDQoNCiAgIHNob3J0ZXN0IHBhdGggZm9yd2FyZGluZyB3aXRoIExE UC4NCg0KDQoNCistLS0tLS0tLS0rLS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLSst LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCnwgTWV0aG9kICB8MTAwJSB8IEFsdC4gfCBBZGRp dGlvbmFsICB8IE1heC4gIHwgTGFiZWwgdGFibGUgfCBDb250cm9sICB8DQoNCnwgICAgICAgICB8 cHJvdC58IGNhbiAgfCBjb21wdXRhdGlvbiB8IGFkZGl0LnwgICAgc2l6ZSAgICAgfCBwbGFuZSAg ICB8DQoNCnwgICAgICAgICB8Y292LiB8IGxvb3A/fCBhdCBlYWNoICAgICB8IGxhYmVsc3wocmVs YXRpdmUgdG8gfCByZXFzLiAgICB8DQoNCnwgICAgICAgICB8ICAgICB8ICAgICAgfCBub2RlICAg ICAgICB8ICAgICAgIHwgU1BGIGxhYmVscykgfCAgICAgICAgICB8DQoNCistLS0tLS0tLS0rLS0t LS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0r DQoNCnwgTVJULUZSUiB8IFllcyB8IE5vICAgfCBlcXVpdmFsZW50ICB8IDAoTERQKXwgICAgIDN4 ICAgICAgfCBNUlQtICAgICB8DQoNCnwgTFAgYW5kICB8ICAgICB8ICAgICAgfCBvZiBsZXNzICAg ICB8IDEoSVApIHwgICAgICAgICAgICAgfCBzcGVjaWZpYyB8DQoNCnwgTlAgICAgICB8ICAgICB8 ICAgICAgfCB0aGFuICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBwcm90b2NvbCB8DQoN CnwgICAgICAgICB8ICAgICB8ICAgICAgfCAzIFNQRnMgICAgICB8ICAgICAgIHwgICAgICAgICAg ICAgfCBleHRlbnMuICB8DQoNCistLS0tLS0tLS0rLS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCnwgTEZBIExQICB8IE5vICB8IFll cyAgfCAgU1BGIHBlciAgICB8ICAgMCAgIHwgICAgIDF4ICAgICAgfCBOb25lICAgICB8DQoNCnwg YW5kIE5QICB8ICAgICB8ICAgICAgfCAgbmVpZ2hib3IgICB8ICAgICAgIHwgICAgICAgICAgICAg fCAgICAgICAgICB8DQoNCistLS0tLS0tLS0rLS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0t LS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCnwgUmVtb3RlICB8IE5vICB8IFllcyAg fCAgU1BGIHBlciAgICB8ICAgMSAgIHwgICAgIDF4ICAgICAgfCBULUxEUCAgICB8DQoNCnwgTEZB IExQICB8ICAgICB8ICAgICAgfCAgbmVpZ2hib3IgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBz ZXNzaW9uICB8DQoNCnwgICAgICAgICB8ICAgICB8ICAgICAgfCAgICAgICAgICAgICB8ICAgICAg IHwgICAgICAgICAgICAgfCBmb3IgZWFjaCB8DQoNCnwgICAgICAgICB8ICAgICB8ICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBzZWxlY3RlZCB8DQoNCnwgICAgICAg ICB8ICAgICB8ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBQUSBu b2RlICB8DQoNCistLS0tLS0tLS0rLS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLSst LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCnwgUmVtb3RlICB8IE5vICB8IFllcyAgfCBTUEYg cGVyIG5iciB8ICAgMSAgIHwgICAgIDF4ICAgICAgfCBULUxEUCAgICB8DQoNCnwgTEZBIE5QICB8 ICAgICB8ICAgICAgfCBhbmQgU1BGIHBlciB8ICAgICAgIHwgICAgICAgICAgICAgfCBzZXNzaW9u ICB8DQoNCnwgICAgICAgICB8ICAgICB8ICAgICAgfCBwZXIgUFEgbm9kZSB8ICAgICAgIHwgICAg ICAgICAgICAgfCBmb3IgZWFjaCB8DQoNCnwgICAgICAgICB8ICAgICB8ICAgICAgfCBldmFsdWF0 ZWQgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBzZWxlY3RlZCB8DQoNCnwgICAgICAgICB8ICAg ICB8ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBQUSBub2RlICB8 DQoNCistLS0tLS0tLS0rLS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0rDQoNCnwgTm90LVZpYSB8IFllcyB8IE5vICAgfCBTUEYgcGVyICAg ICB8ICAgMSAgIHwgIChhdmVyYWdlICAgfCBULUxEUCAgICB8DQoNCnwgTFAgYW5kICB8ICAgICB8 ICAgICAgfCBsaW5rIGFuZCAgICB8ICAgICAgIHwgIG51bWJlciBvZiAgfCBzZXNzaW9uICB8DQoN CnwgTlAgICAgICB8ICAgICB8ICAgICAgfCBwZXIgbm9kZSAgICB8ICAgICAgIHwgIG5laWdoYm9y cykgfCBmb3IgZWFjaCB8DQoNCnwgICAgICAgICB8ICAgICB8ICAgICAgfCBpbiB0b3BvbG9neSB8 ICAgICAgIHwgICAgICB4ICAgICAgfCBuYnIncyBuYnJ8DQoNCistLS0tLS0tLS0rLS0tLS0rLS0t LS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCnwg VEktTEZBICB8IFllcyB8IFllcyAgfCBTUEYgcGVyICAgICB8ICAgMiAgIHwgICAgIDF4ICAgICAg fCB1c2VzICAgICB8DQoNCnwgTFAgd2l0aCB8ICAgICB8ICAgICAgfCBuZWlnaGJvciAgICB8ICAg ICAgIHwgICAgICAgICAgICAgfCBTUFJJTkcgICB8DQoNCnwgc3ltbS4gICB8ICAgICB8ICAgICAg fCAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBmb3IgICAgICB8DQoNCnwgbWV0 cmljcyB8ICAgICB8ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgfCBs YWJlbCAgICB8DQoNCnwgICAgICAgICB8ICAgICB8ICAgICAgfCAgICAgICAgICAgICB8ICAgICAg IHwgICAgICAgICAgICAgfCBkaXN0LiAgICB8DQoNCistLS0tLS0tLS0rLS0tLS0rLS0tLS0tKy0t LS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCnwgVEktTEZB ICB8IFllcyB8IFllcyAgfCAjIG9mIFNQRnMgICB8ZGVwdGggIHwgICAgIDF4ICAgICAgfCB1c2Vz ICAgICB8DQoNCnwgTlAgb3IgICB8ICAgICB8ICAgICAgfCBkZXBlbmRlbnQgICB8ZGVwZW5kLXwg ICAgICAgICAgICAgfCBTUFJJTkcgICB8DQoNCnwgTFAgd2l0aCB8ICAgICB8ICAgICAgfCBvbiB0 b3BvbG9neSB8ZW50IG9uIHwgICAgICAgICAgICAgfCBmb3IgICAgICB8DQoNCnwgYXN5bW0uICB8 ICAgICB8ICAgICAgfCAgICAgICAgICAgICB8dG9wby4gIHwgICAgICAgICAgICAgfCBsYWJlbCAg ICB8DQoNCnwgbWV0cmljcyB8ICAgICB8ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgIHwgICAg ICAgICAgICAgfCBkaXN0LiAgICB8DQoNCistLS0tLS0tLS0rLS0tLS0rLS0tLS0tKy0tLS0tLS0t LS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCg0KDQogICAgICAgICAg ICAgICAgRmlndXJlIDE6IENvbXBhcmlzb24gb2YgSVAvTERQIEZSUiBNZXRob2RzDQoNCg0KDQog ICBNUlQ6ICAgTVJUIHByb3ZpZGVzIDEwMCUgY292ZXJhZ2UgZm9yIGxpbmsgYW5kIG5vZGUgcHJv dGVjdGlvbiwgYW5kDQoNCiAgICAgIHRyYWZmaWMgb24gdGhlIGFsdGVybmF0ZSBwYXRocyB3aWxs IG5vdCBsb29wLiAgVGhlIGNvbXB1dGF0aW9uDQoNCiAgICAgIHJlcXVpcmVkIG9uIGVhY2ggbm9k ZSBpcyBlcXVpdmFsZW50IHRvIGxlc3MgdGhhbiAzIGFkZGl0aW9uYWwgU1BGcw0KDQogICAgICBp biB0ZXJtcyBvZiBjb21wdXRhdGlvbmFsIGNvbXBsZXhpdHkuICBGb3IgSVAgdHJhZmZpYywgTVJU DQoNCiAgICAgIHJlcXVpcmVzIG9uZSBhZGRpdGlvbmFsIGxhYmVsLCB3aGlsZSBmb3IgTERQIHRy YWZmaWMsIG5vDQoNCiAgICAgIGFkZGl0aW9uYWwgbGFiZWxzIGFyZSBuZWVkZWQuICBIb3dldmVy LCB0aGUgc2l6ZSBvZiB0aGUgTVBMUyBsYWJlbA0KDQogICAgICB0YWJsZSBpcyB0aHJlZSB0aW1l cyB3aGF0IHdvdWxkIG5vcm1hbGx5IGJlIHJlcXVpcmVkIGZvciBzaG9ydGVzdA0KDQogICAgICBw YXRoIExEUCBmb3J3YXJkaW5nLCBkdWUgdG8gdGhlIHByZXNlbmNlIG9mIGFkZGl0aW9uYWwgcmVk IGFuZA0KDQogICAgICBibHVlIGxhYmVscyBmb3IgZWFjaCBGRUMuICBNUlQgcmVxdWlyZXMgcHJv dG9jb2wgZXh0ZW5zaW9ucyBpbg0KDQogICAgICBvcmRlciB0byBhbGxvdyBhIG5vZGUgdG8gYWR2 ZXJ0aXNlIHN1cHBvcnQgZm9yIE1SVCBhcyB3ZWxsIGFzIGENCg0KICAgICAgdmFsdWUgZm9yIHRo ZSBHQURBRyBSb290IFNlbGVjdGlvbiBQcmlvcml0eS4gIEl0IGFsc28gcmVxdWlyZXMNCg0KICAg ICAgc3VwcG9ydCBmb3IgbXVsdGktdG9wb2xvZ3kgTERQIGV4dGVuc2lvbnMuDQoNCg0KDQogICBM b29wLUZyZWUgQWx0ZXJuYXRlcyAoTEZBKTogICBMRkFzIFtSRkM1Mjg2XSBwcm92aWRlIGxpbWl0 ZWQNCg0KICAgICAgdG9wb2xvZ3ktZGVwZW5kZW50IGNvdmVyYWdlIGZvciBsaW5rIGFuZCBub2Rl IHByb3RlY3Rpb24uDQoNCiAgICAgIFJlc3RyaWN0aW9ucyBvbiBjaG9pY2Ugb2YgYWx0ZXJuYXRl cyBjYW4gYmUgcmVsYXhlZCB0byBpbXByb3ZlDQoNCiAgICAgIGNvdmVyYWdlLCBidXQgdGhpcyBj YW4gY2F1c2UgZm9yd2FyZGluZyBsb29wcyBpZiBhIHdvcnNlIGZhaWx1cmUNCg0KICAgICAgaXMg ZXhwZXJpZW5jZWQgdGhhbiBwcm90ZWN0ZWQgYWdhaW5zdC4gIFtSRkM2NTcxXSBkaXNjdXNzZXMg dGhlDQoNCiAgICAgIGFwcGxpY2FiaWxpdHkgb2YgTEZBIHRvIGRpZmZlcmVudCB0b3BvbG9naWVz IHdpdGggYSBmb2N1cyBvbg0KDQogICAgICBjb21tb24gUG9QIGFyY2hpdGVjdHVyZXMuICBUaGUg Y29tcHV0YXRpb24gcmVxdWlyZWQgaXMgb25lIFNQRiBwZXINCg0KICAgICAgbmVpZ2hib3IuICBM RkEgaW1wb3NlcyBubyBhZGRpdGlvbmFsIGxhYmVscyBpbXBvc2VkLCBoYXMgbm8gaW1wYWN0DQoN CiAgICAgIG9uIHRoZSBsYWJlbCB0YWJsZSBzaXplLCBhbmQgaGFzIG5vIGFkZGl0aW9uYWwgY29u dHJvbCBwbGFuZQ0KDQogICAgICByZXF1aXJlbWVudHMuDQoNCg0KDQogIFJlbW90ZSBMRkE6ICAg UmVtb3RlIExGQSBbUkZDNzQ5MF0gaW1wcm92ZXMgY292ZXJhZ2Ugb3ZlciBMRkEgZm9yDQoNCiAg ICAgIGJvdGggbGluayBhbmQgbm9kZSBwcm90ZWN0aW9uLCBidXQgaXQgZG9lcyBub3QgZ3VhcmFu dGVlIDEwMCUNCg0KICAgICAgY292ZXJhZ2UuICBUaGUgYWx0ZXJuYXRlcyBjYW4gYWxzbyBsb29w IHdpdGggd29yc2UgdGhhbiBleHBlY3RlZA0KDQogICAgICBmYWlsdXJlcy4gIENvbXB1dGF0aW9u IGZvciBsaW5rIHByb3RlY3Rpb24gaXMgb25lIFNQRiBwZXINCg0KICAgICAgbmVpZ2hib3IsIHdo aWxlIGNvbXB1dGF0aW9uIGZvciBub2RlIHByb3RlY3Rpb24gcmVxdWlyZXMgYW4NCg0KICAgICAg YWRkaXRpb25hbCBTUEYgcGVyIFBRIG5vZGUgW0ktRC5pZXRmLXJ0Z3dnLXJsZmEtbm9kZS1wcm90 ZWN0aW9uXS4NCg0KICAgICAgUmVtb3RlIExGQSBjYW4gaW1wb3NlIHVwIHRvIG9uZSBhZGRpdGlv bmFsIGxhYmVsIG9uIHRoZSBwYWNrZXQsDQoNCiAgICAgIGJ1dCBkb2VzIG5vdCBpbmNyZWFzZSB0 aGUgc2l6ZSBvZiB0aGUgbGFiZWwgdGFibGUuICBJdCByZXF1aXJlcyBhDQoNCiAgICAgIFQtTERQ IHNlc3Npb24gZm9yIGVhY2ggc2VsZWN0ZWQgUFEgbm9kZS4NCg0KDQoNCiAgIE5vdC1WaWE6ICAg Tm90LVZpYSBbUkZDNjk4MV0gcHJvdmlkZXMgMTAwJSBjb3ZlcmFnZSBmb3IgbGluayBhbmQgbm9k ZQ0KDQogICAgICBmYWlsdXJlcyBhbmQgZG9lcyBub3QgaGF2ZSBwb3RlbnRpYWwgbG9vcGluZyBh bW9uZyBhbHRlcm5hdGVzLg0KDQogICAgICBUaGUgY29tcHV0YXRpb24gaXMgaGlnaCB3aXRoIGFu IFNQRiBwZXIgcG90ZW50aWFsIGZhaWx1cmUgcG9pbnQNCg0KICAgICAgKGFsbCBsaW5rcyBhbmQg bm9kZXMgaW4gdGhlIHRvcG9sb2d5KS4gIFdoZW4gaW1wbGVtZW50ZWQgd2l0aCBMRFAsDQoNCiAg ICAgIE5vdC1WaWEgYWRkcyBvbmUgYWRkaXRpb25hbCBsYWJlbCB0byBhIHR1bm5lbGxlZCBwYWNr ZXQuICBJdA0KDQogICAgICBzaWduaWZpY2FudGx5IGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUg bGFiZWwgdGFibGUsIG11bHRpcGx5aW5nDQoNCiAgICAgIGl0IGJ5IHJvdWdobHkgdGhlIGF2ZXJh Z2UgbnVtYmVyIG9mIG5laWdoYm9ycy4gIE5vdC1WaWEgYWxzbw0KDQogICAgICByZXF1aXJlcyB0 YXJnZXRlZCBMRFAgc2Vzc2lvbnMgdG8gZWFjaCBuZWlnaGJvcidzIG5laWdoYm9yLg0KDQoNCg0K ICAgVEktTEZBOiAgIFRvcG9sb2d5IEluZGVwZW5kZW50IExvb3AtZnJlZSBBbHRlcm5hdGUgRmFz dCBSZS1yb3V0ZSAoVEktDQoNCiAgICAgIExGQSkgW0ktRC5mcmFuY29pcy1ydGd3Zy1zZWdtZW50 LXJvdXRpbmctdGktbGZhXSBhaW1zIHRvIHByb3ZpZGUNCg0KICAgICAgbGluayBhbmQgbm9kZSBw cm90ZWN0aW9uIG9mIG5vZGUgYW5kIGFkamFjZW5jeSBzZWdtZW50cyB3aXRoaW4gdGhlDQoNCiAg ICAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGZyYW1ld29yay4gIEl0IGd1YXJhbnRlZXMgY29tcGxl dGUgY292ZXJhZ2UuDQoNCiAgICAgIFRoZSBUSS1MRkEgY29tcHV0YXRpb24gZm9yIGxpbmstcHJv dGVjdGlvbiBpcyBmYWlybHkNCg0KICAgICAgc3RyYWlnaHRmb3J3YXJkLCB3aGlsZSB0aGUgY29t cHV0YXRpb24gZm9yIG5vZGUtcHJvdGVjdGlvbiBpcyBtb3JlDQoNCiAgICAgIGNvbXBsZXguICBG b3IgbGluay1wcm90ZWN0aW9uIHdpdGggc3ltbWV0cmljIGxpbmsgY29zdHMsIFRJLUxGQQ0KDQog ICAgICBjYW4gcHJvdmlkZSBjb21wbGV0ZSBjb3ZlcmFnZSBieSBwdXNoaW5nIHVwIHRvIHR3byBh ZGRpdGlvbmFsDQoNCiAgICAgIGxhYmVscy4gIEZvciBub2RlIHByb3RlY3Rpb24gb24gYXJiaXRy YXJ5IHRvcG9sb2dpZXMsIHRoZSBsYWJlbA0KDQogICAgICBzdGFjayBzaXplIGNhbiBncm93IHNp Z25pZmljYW50bHkgYmFzZWQgb24gcmVwYWlyIHBhdGguICBOb3RlIHRoYXQNCg0KICAgICAgVEkt TEZBIHJlcXVpcmVzIHNob3J0ZXN0IHBhdGggZm9yd2FyZGluZyBiYXNlZCBvbiBTUiBOb2RlLVNJ RHMsIGFzDQoNCiAgICAgIG9wcG9zZWQgdG8gTERQIGxhYmVscywgaW4gb3JkZXIgdG8gY29uc3Ry dWN0IGxhYmVsIHN0YWNrcyBmb3INCg0KICAgICAgYmFja3VwcyBwYXRocyB3aXRob3V0IHJlbHlp bmcgb24gYSBsYXJnZSBudW1iZXIgb2YgdGFyZ2V0ZWQgTERQDQoNCiAgICAgIHNlc3Npb25zIHRv IGxlYXJuIHJlbW90ZSBGRUMtbGFiZWwgYmluZGluZ3MuICBJdCBhbHNvIHJlcXVpcmVzIHRoZQ0K DQogICAgICB1c2Ugb2YgQWRqLVNJRHMgdG8gYWNoaWV2ZSAxMDAlIGNvdmVyYWdlLg0KDQoNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IFN0ZXdhcnQgQnJ5YW50IFtt YWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tXQ0KDQpTZW50OiBXZWRuZXNkYXksIERlY2Vt YmVyIDIzLCAyMDE1IDY6MjkgQU0NCg0KVG86IENocmlzIEJvd2VycyA8Y2Jvd2Vyc0BqdW5pcGVy Lm5ldD47IGRyYWZ0LXJ0Z3dnLW1ydC1mcnItYXJjaGl0ZWN0dXJlQHRvb2xzLmlldGYub3JnOyBy dGd3Z0BpZXRmLm9yZzsgQWx2YXJvIFJldGFuYSA8YXJldGFuYUBjaXNjby5jb20+DQoNClN1Ympl Y3Q6IFJlOiBXR0xDIGZvciBkcmFmdC1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVyZQ0KDQoNCg0K SGkgQ2hyaXMNCg0KDQoNClRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBjb21tZW50cy4NCg0KDQoN Ckkgd2lsbCB0cmltIHRoZSBlbWFpbCB0byBqdXN0IHRoZSBhcmVhcyB0aGF0IG5lZWQgZnVyDQoN Cg0KDQpPbiAyMS8xMi8yMDE1IDE0OjQ3LCBDaHJpcyBCb3dlcnMgd3JvdGU6DQoNCj4NCg0KPg0K DQo+ID09PT09PT09PT09DQoNCj4NCg0KPg0KDQo+ICAgMS4gIEludHJvZHVjdGlvbg0KDQo+DQoN Cj4NCg0KPiBTQj4gVGhlIHRleHQgc2hvdWxkIHN0YXJ0IHdpdGggdGhlIGludmFyaWFudHMgYW5k IGFzc3VtcHRpb25zIHRvDQoNCj4gU0I+IGNvcnJlY3RseSBzY29wZSB0aGUgY2xhaW1zIGluIHRo ZSBpbnRyb2R1Y3Rpb24uDQoNCj4NCg0KPiBbQ0JdIENoYW5nZWQgdGhlIHRleHQgdG8gcmVhZDoN Cg0KPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNvbHV0aW9uIGZvciBJUC9MRFAgZmFzdC1y ZXJvdXRlICAgIFtSRkM1NzE0XS4NCg0KDQoNClNCPiBJIHRoaW5rIHRoZSBhc3N1bXB0aW9ucyBh cmUgZm9yIGV4YW1wbGU6DQoNCi0gU2luZ2xlIGxpbmsgb3Igbm9kZSBmYWlsdXJlDQoNCi0gQ2Fu J3QgcmVtZW1iZXIgaWYgeW91IGhhdmUgdGhlIG1lYW5zIHRvIGRlYWwgd2l0aCBTUkxHDQoNCi0g TEYgdGVjaG5pcXVlIGlzIGluIHBsYWNlDQoNCi0gbWV0aG9kIG9mIGRldGVjdGluZyBzaXR1YXRp b24gb3V0c2lkZSB5b3VyIGFzc3VtcHRpb25zIGlzIGluIHBsYWNlDQoNCg0KDQpJbiBvdGhlciB3 b3JkcywgeW91IG5lZWQgdG8gZGVzY3JpYmUgYXNzdW1wdGlvbnMgeW91IGFyZSBtYWtpbmcgbWFr aW5nIGFib3V0IHRoZSBlbnZpcm9ubWVudCBpbiB3aGljaCB0aGlzIHNvbHV0aW9uIHdvcmtzLiBX aGlsc3QNCg0KUkZDNTcxNCB0YWxrcyBhcm91bmQgdGhlIHByb2JsZW0sIGEgc29sdXRpb24gbmVl ZHMgdG8gYmUgcXVpdGUgc3BlY2lmaWMgYWJvdXQgd2hlbiBpdCBicmVha3MsIChhKSB0byBhbGVy dCB0aGUgb3BlcmF0b3IsIGFuZA0KDQooYikgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHNvbHV0aW9u IGNvbnNpZGVycyB0aGUgY29uc2VxdWVuY2VzIG9mIG9wZXJhdGluZyBvdXRzaWRlIHRoZSBzcGVj aWZpZWQgZW52ZWxvcGUuDQoNCg0KDQpbQ0JdIFRoZSAzcmQgcGFyYWdyYXBoIG9mIHRoZSByZXZp c2VkIGludHJvZHVjdGlvbiB3YXMgYWRkZWQgdG8gYWRkcmVzcyB0aGlzLg0KDQoNCg0KPg0KDQo+ DQoNCj4gU0I+IEkgdGhpbmsgeW91IGhhdmUgdG8gc2F5IHdoZXJlIHRoZSB0cmVlcyBhcmUgcm91 dGVkIHNpbmNlIG9ubHkgdHdvDQoNCj4gU0I+IG1lYW4geW91IG5lZWQgYSByb290LCBhbmQgeW91 IG5lZWQgdG8gbm90ZSB0aGF0IHRoaXMgaXMgZGlmZmVyZW50DQoNCj4gU0I+IGZyb20gdGhlIHVu ZGVybHlpbmcgSUdQIGluIHdoaWNoIHRoZXJlIGlzIGEgdHJlZSBwZXIgbm9kZS4NCg0KPg0KDQo+ DQoNCj4gW0NCXSAgSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGRpc3RpbmN0aW9uIHRoYXQgeW91 IHN1Z2dlc3Qgbm90aW5nLiAgVGhlIE1SVCBjb21wdXRhdGlvbiBydW4gYXQgZWFjaCBzb3VyY2Ug bm9kZSBwcm9kdWNlcyBhIGRpc3RpbmN0IHJlZCBhbmQgYmx1ZSB0cmVlIGZvciBlYWNoIGRlc3Rp bmF0aW9uIG5vZGUgd2l0aCBlYWNoIHRyZWUgcm9vdGVkIGF0IGFuZCBkaXJlY3RlZCB0b3dhcmRz IHRoZSBkZXN0aW5hdGlvbiBub2RlLiAgVGhlIGVuZCByZXN1bHQgaXMgc2ltaWxhciB0byB3YXkg dGhhdCB0aGUgZm9yd2FyZCBTUEYgY29tcHV0YXRpb24gcnVuIGF0IGVhY2ggc291cmNlIG5vZGUg cHJvZHVjZXMgYSBzaG9ydGVzdCBwYXRoIHRyZWUgZm9yIGVhY2ggZGVzdGluYXRpb24gbm9kZSB3 aXRoIGVhY2ggdHJlZSByb290ZWQgYXQgYW5kIGRpcmVjdGVkIHRvd2FyZHMgdGhlIGRlc3RpbmF0 aW9uIG5vZGUuDQoNCg0KDQpTQj4gTWF5YmUgSSBhbSBjb25mdXNlZC4gQXMgSSByZWNhbGwgeW91 IG5lZWQgdG8gZGV0ZXJtaW5lIGEgc2luZ2xlDQoNCmxvd3BvaW50IGFzIHRoZSBzdGFydGluZw0K DQpwb2ludCBmb3IgeW91ciByZXBhaXIgdG9wb2xvZ2llcy4gRG9lc24ndCB0aGF0IG1lYW4gdGhh dCBlZmZlY3RpdmVseSBiZWNvbWUgdGhlIHJvb3Qgb2YgYSBwYWlyIG9mIHJlcGFpciB0cmVlcz8N Cg0KDQoNCkFsc28gdGhlIGxvdyBwb2ludCBjYW4gbW92ZSB1bmRlciBjZXJ0YWluIGNpcmN1bXN0 YW5jZXMsIGFuZCBJIHRoaW5nIHRoYXQgd2lsbCBpbXBhY3QgdGhlIHJlcGFpciB0b3BvbG9neS4N Cg0KDQoNCltDQl0gVGhlIGFsZ29yaXRobSBpbiBkcmFmdC1pZXRmLXJ0Z3dnLW1ydC1mcnItYWxn b3JpdGhtIHVzZXMgbG93cG9pbnQgdmFsdWVzICB0byBpZGVudGlmeSBlYXJzIGFuZCBibG9ja3Mg d2hlbiBkb2luZyBhIGRlcHRoLWZpcnN0LXNlYXJjaCB0cmF2ZXJzYWwgb2YgdGhlIG5ldHdvcmsg Z3JhcGguICBUaGlzIGlzIGNvdmVyZWQgaW4gU2VjdGlvbiA0LjMgb2YgdGhhdCBkb2MuICBUaGUg REZTIHRyYXZlcnNhbCBzdGFydHMgYXQgdGhlIEdBREFHIHJvb3QsIGFuZCB0aGUgY2hvaWNlIG9m IEdBREFHIHJvb3Qgd2lsbCBnZW5lcmFsbHkgYWZmZWN0IHRoZSBHQURBRyBhbmQgdGhlIHJlZCBh bmQgYmx1ZSB0cmVlcy4gIEkgYWRkZWQgdGV4dCBpbiB0aGUgbGF0ZXN0IHJldmlzaW9uIHRoYXQg YWRkcmVzc2VzIHRoZSBjb25jZXJuIG9mIGhhdmluZyB0aGUgR0FEQUcgcm9vdCBjaGFuZ2UgdG9v IG9mdGVuLg0KDQoNCg0KPg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgICAgU3VtbWFyeSBDb21w YXJpc29uIG9mIElQL0xEUCBGUlIgTWV0aG9kcw0KDQo+DQoNCj4gICAgICstLS0tLS0tLS0rLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K DQo+ICAgICB8ICBNZXRob2QgfCAgIENvdmVyYWdlICB8ICBBbHRlcm5hdGUgIHwgICAgQ29tcHV0 YXRpb24gKGluIFNQRnMpICAgIHwNCg0KPiAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgfCAg IExvb3Bpbmc/ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCj4gICAgICstLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KDQo+ICAgICB8IE1SVC1GUlIgfCAgICAgMTAwJSAgICB8ICAgICBOb25lICAgIHwg ICAgICAgICBsZXNzIHRoYW4gMyAgICAgICAgIHwNCg0KPiAgICAgfCAgICAgICAgIHwgIExpbmsv Tm9kZSAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCj4g ICAgIHwgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KDQo+ICAgICB8ICAgTEZBICAgfCAgIFBhcnRpYWwgICB8ICAgUG9z c2libGUgIHwgICAgICAgICBwZXIgbmVpZ2hib3IgICAgICAgIHwNCg0KPiAgICAgfCAgICAgICAg IHwgIExpbmsvTm9kZSAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQoNCj4gICAgIHwgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQo+ICAgICB8ICBSZW1vdGUgfCAgIFBhcnRpYWwg ICB8ICAgUG9zc2libGUgIHwgICAgcGVyIG5laWdoYm9yIChsaW5rKSBvciAgIHwNCg0KPiAgICAg fCAgIExGQSAgIHwgIExpbmsvTm9kZSAgfCAgICAgICAgICAgICB8ICBuZWlnaGJvcidzIG5laWdo Ym9yIChub2RlKSB8DQoNCj4gICAgIHwgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQo+ICAgICB8IE5vdC1WaWEgfCAg ICAgMTAwJSAgICB8ICAgICBOb25lICAgIHwgICAgICBwZXIgbGluayBhbmQgbm9kZSAgICAgIHwN Cg0KPiAgICAgfCAgICAgICAgIHwgIExpbmsvTm9kZSAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQoNCj4gICAgIHwgICAgICAgICB8ICAgICAgICAgICAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQo+ICAgICB8ICBU SS1MRkEgfCAgICAgMTAwJSAgICB8ICAgUG9zc2libGUgIHwgICAgcGVyIG5laWdoYm9yIChsaW5r KSBvciAgIHwNCg0KPiAgICAgfCAgICAgICAgIHwgIExpbmsvTm9kZSAgfCAgICAgICAgICAgICB8 ICBuZWlnaGJvcidzIG5laWdoYm9yIChub2RlKSB8DQoNCj4NCg0KPiArLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0K Pg0KDQo+IFNCPiBJIHJlYWxseSB3b25kZXIgaG93IGltcG9ydGFudCB0aGUgY29tcHV0YXRpb25h bCBjb21wbGV4aXR5IGlzDQoNCj4gU0I+IGdpdmVuIHRoYXQgd2UgYXJlIG1vdmluZyB0byBhbiBT RE4gd29ybGQgd2hlcmUgdGhlc2UgY2FsY3VsYXRpb25zDQoNCj4gU0I+IGNhbiBiZSBvZmZsb2Fk ZWQ/DQoNCj4gU0I+DQoNCj4gU0I+IEkgdGhpbmsgdGhhdCBpdCBpcyBmYWlyIHRvIG5vdGUgdGhh dCB0aGUgb3RoZXIgbWV0aG9kIHVzZSB0aGUNCg0KPiBTQj4gZXhpc3Rpbmcgcm91dGluZyBwcm90 b2NvbCBhbmQgY2FsY3VsYXRlIGFsdGVybmF0ZSBwYXRocyB1c2luZyB0aGUNCg0KPiBTQj4gbWV0 aG9kcyBvZiB0aGF0IHJvdXRpbmcgcHJvdG9jb2wuIFdoZXJlYXMgd2l0aCBNUlQgeW91IHJlYWxs eSBoYXZlDQoNCj4gU0I+IGEgbmV3IHJvdXRpbmcgcHJvdG9jb2wgd2l0aCBhbGwgb2YgdGhlIGFz c29jaWF0ZWQgb3BlcmF0aW9ucyBvdmVyaGVhZC4NCg0KU0I+IEkgdGhpbmsgdGhpcyBkZXNlcnZl cyBjb25zaWRlcmF0aW9uLiBUaGUgcm91dGUgY29tcHV0YXRpb25hbCB3b3JsZA0KDQpoYXMgbW92 ZWQNCg0Kb24gc2luY2UgdGhpcyB3b3JrIHdhcyBzdGFydGVkLg0KDQoNCg0KW0NCXSAgVGhlIGxh dGVzdCByZXZpc2lvbiB0cmllcyB0byBwcm92aWRlIG1vcmUgY29udGV4dCBmb3Igd2hlbiByZWR1 Y2luZyBjb21wdXRhdGlvbiB0aW1lIG1heSBiZSB1c2VmdWwuDQoNCg0KDQoNCg0KPg0KDQo+DQoN Cj4NCg0KPiA2LjEuMS4xLiAgVG9wb2xvZ3ktc2NvcGVkIEZFQyBlbmNvZGVkIHVzaW5nIGEgc2lu Z2xlIGxhYmVsIChPcHRpb24gMUEpDQoNCj4NCg0KPiAgICAgW1JGQzczMDddIHByb3ZpZGVzIGEg bWVjaGFuaXNtIHRvIGRpc3RyaWJ1dGUgRkVDLUxhYmVsIGJpbmRpbmdzDQoNCj4gICAgIHNjb3Bl ZCB0byBhIGdpdmVuIE1QTFMgdG9wb2xvZ3kgKHJlcHJlc2VudGVkIGJ5IE1QTFMgTVQtSUQpLiAg VG8gdXNlDQoNCj4gICAgIG11bHRpLXRvcG9sb2d5IExEUCB0byBjcmVhdGUgTVJUIGZvcndhcmRp bmcgdG9wb2xvZ2llcywgd2UgYXNzb2NpYXRlDQoNCj4gICAgIHR3byBNUExTIE1ULUlEcyB3aXRo IHRoZSBNUlQtUmVkIGFuZCBNUlQtQmx1ZSBmb3J3YXJkaW5nIHRvcG9sb2dpZXMsDQoNCj4gICAg IGluIGFkZGl0aW9uIHRvIHRoZSBkZWZhdWx0IHNob3J0ZXN0IHBhdGggZm9yd2FyZGluZyB0b3Bv bG9neSB3aXRoIE1ULQ0KDQo+ICAgICBJRD0wLg0KDQo+DQoNCj4gU0I+IFByZXN1bWFibHkgeW91 IGNvdWxkIE1SVCBhIHRvcG9sb2d5IG90aGVyIHRoYW4gZGVmYXVsdD8NCg0KPg0KDQo+IFtDQl0g SXQgY291bGQgYmUgZG9uZSwgYnV0IHdlIGZvY3VzZWQgb24gc3VwcG9ydGluZyB0aGUgdXNlIGNh c2UgdXNpbmcgdGhlIGRlZmF1bHQgSUdQIHRvcG9sb2d5LiAgVGhlcmUgaXMgZXhpc3RpbmcgdGV4 dCBpbiBzZWN0aW9uIDcgZXhwbGFpbmluZyB0aGlzLg0KDQo+DQoNCj4gICBEZXBsb3ltZW50IHNj ZW5hcmlvcyB1c2luZyBtdWx0aS10b3BvbG9neSBPU1BGIG9yIElTLUlTLCBvciBydW5uaW5nDQoN Cj4gICAgIGJvdGggSVNJUyBhbmQgT1NQRiBvbiB0aGUgc2FtZSByb3V0ZXJzIGlzIG91dCBvZiBz Y29wZSBmb3IgdGhpcw0KDQo+ICAgICBzcGVjaWZpY2F0aW9uLg0KDQo+DQoNCj4NCg0KPg0KDQo+ IFNCPiBUbyBiZSBjbGVhciAtIHlvdSBuZWVkIDMgKiB0aGUgbnVtYmVyIG9mIGRlbGl2ZXJ5IGxh YmVscyBpbiB0aGUNCg0KPiBTQj4gbmV0d29yaywgYW5kIGluIHNvbWUgY2FzZXMgdGhlc2UgbGFi ZWxzIGlkZW50aWZ5IHByZWZpeCBvciBhIFZQTg0KDQo+IFNCPiBleGl0IHBvaW50Lg0KDQo+IFNC PiBUaGlzIGlzIGEgbG90IG1vcmUgbGFiZWxzIHRoYW4gc29tZSBvZiB0aGUgY29tcGV0aW5nIHNj aGVtZXMgYW5kDQoNCj4gU0I+IHNvIEkgdGhpbmsgd2UgcmVhbGx5IG5lZWQgYSBsYWJlbCB0YWJs ZSBzaXplIGNvbXBhcmlzb24gaW4gdGhlDQoNCj4gU0I+IGNvbXBhcmlzb24gc2VjdGlvbiBlYXJs aWVyIGluIHRoZSBkb2N1bWVudC4NCg0KU0I+IE5vIGNvbW1lbnQgb24gdGhlIGFib3ZlPw0KDQoN Cg0KW0NCXSBUaGlzIGlzIGluY2x1ZGVkIGluIHRoZSB0YWJsZSBhbmQgZGlzY3Vzc2lvbiBpbiB0 aGUgbGF0ZXN0IHJldmlzaW9uLg0KDQoNCg== --_000_BY2PR05MB61485BE58B3F2A3CCA10FC8A9C80BY2PR05MB614namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3Rld2FydCBhbmQgUm9iLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHB1Ymxpc2hlZCBhIG5ldyByZXZpc2lvbiBv ZiB0aGlzIGRyYWZ0IGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcnRnd2ctbXJ0 LWZyci1hcmNoaXRlY3R1cmUtMDkudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRo ZSBpbnRyb2R1Y3Rpb24gaGFzIHF1aXRlIGEgZmV3IGNoYW5nZXMgd2hlcmUgSSB0cmllZCB0byBh ZGRyZXNzIHNldmVyYWwgb2YgdGhlIGlzc3VlcyB5b3UgcmFpc2VkIGluY2x1ZGluZyB0aGUgdGFi bGUgYW5kIHRleHQgY29tcGFyaW5nIGRpZmZlcmVudCBJUC9MRFAgRlJSIG1ldGhvZHMuJm5ic3A7 Jm5ic3A7IFRoZSBuZXcgdGV4dCBpcyBjb3BpZWQNCiBiZWxvdy4gPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkNocmlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPj09PT09PT09PT09PT09PT09 PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xLiZuYnNwOyBJbnRy b2R1Y3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29sdXRpb24gZm9yIElQL0xEUCBmYXN0LXJlcm91dGUgW1JG QzU3MTRdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IE1SVC1GUlIgY3JlYXRlcyB0d28gYWx0ZXJuYXRlIHRyZWVzIHNlcGFyYXRlIGZyb20gdGhl IHByaW1hcnkgbmV4dC08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBob3AgZm9yd2FyZGluZyB1c2VkIGR1cmluZyBzdGFibGUgb3BlcmF0aW9uLiZu YnNwOyBUaGVzZSB0d28gdHJlZXMgYXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbWF4aW1hbGx5IGRpdmVyc2UgZnJvbSBlYWNoIG90aGVyLCBw cm92aWRpbmcgbGluayBhbmQgbm9kZSBwcm90ZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZm9yIDEwMCUgb2YgcGF0aHMgYW5kIGZhaWx1 cmVzIGFzIGxvbmcgYXMgdGhlIGZhaWx1cmUgZG9lcyBub3QgY3V0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIG5ldHdvcmsgaW50byBtdWx0 aXBsZSBwaWVjZXMuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhcmNoaXRlY3R1cmUgZm9y IElQL0xEUCBmYXN0LXJlcm91dGUgd2l0aCBNUlQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBbSS1ELmlldGYtcnRnd2ctbXJ0LWZyci1hbGdvcml0aG1dIGRlc2Ny aWJlcyBob3cgdG8gY29tcHV0ZSBtYXhpbWFsbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyByZWR1bmRhbnQgdHJlZXMgdXNpbmcgYSBzcGVjaWZp YyBhbGdvcml0aG0sIHRoZSBNUlQgTG93cG9pbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhbGdvcml0aG0uJm5ic3A7IFRoZSBNUlQgTG93cG9p bnQgYWxnb3JpdGhtIGlzIHVzZWQgYnkgYSByb3V0ZXIgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IElQL0xEUCBGYXN0LVJlcm91dGUgd2l0 aCBNUlQgKE1SVC1GUlIpIHVzZXMgdHdvIG1heGltYWxseSBkaXZlcnNlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZm9yd2FyZGluZyB0b3BvbG9n aWVzIHRvIHByb3ZpZGUgYWx0ZXJuYXRlcy4mbmJzcDsgQSBwcmltYXJ5IG5leHQtaG9wPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgc2hvdWxkIGJl IG9uIG9ubHkgb25lIG9mIHRoZSBkaXZlcnNlIGZvcndhcmRpbmcgdG9wb2xvZ2llczsgdGh1cywg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg b3RoZXIgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBhbiBhbHRlcm5hdGUuJm5ic3A7IE9uY2UgdHJh ZmZpYyBoYXMgYmVlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IG1vdmVkIHRvIG9uZSBvZiB0aGUgTVJUcyBieSBvbmUgcG9pbnQgb2YgbG9jYWwg cmVwYWlyIChQTFIpLCB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgdHJhZmZpYyBpcyBub3Qgc3ViamVjdCB0byBmdXJ0aGVyIHJlcGFpciBh Y3Rpb25zIGJ5IGFub3RoZXIgUExSLCBldmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW4gdGhlIGV2ZW50IG9mIG11bHRpcGxlIHNpbXVsdGFu ZW91cyBmYWlsdXJlcy4mbmJzcDsgVGhlcmVmb3JlLCB0cmFmZmljPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcmVwYWlyZWQgYnkgTVJULUZSUiB3 aWxsIG5vdCBsb29wIGJldHdlZW4gZGlmZmVyZW50IFBMUnMgcmVzcG9uZGluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRvIGRpZmZlcmVudCBz aW11bHRhbmVvdXMgZmFpbHVyZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBXaGlsZSBNUlQgcHJvdmlkZXMgMTAwJSBwcm90ZWN0aW9uIGZvciBhIHNpbmdsZSBs aW5rIG9yIG5vZGUgZmFpbHVyZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBpdCBtYXkgbm90IHByb3RlY3QgdHJhZmZpYyBpbiB0aGUgZXZlbnQg b2YgbXVsdGlwbGUgc2ltdWx0YW5lb3VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZmFpbHVyZXMsIG5vciBkb2VzIHRha2UgaW50byBhY2NvdW50 IFNoYXJlZCBSaXNrIExpbmsgR3JvdXBzIChTUkxHcykuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQWxzbywgd2hpbGUgdGhlIE1SVCBMb3dwb2lu dCBhbGdvcml0aG0gaXMgY29tcHV0YXRpb25hbGx5IGVmZmljaWVudCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpdCBpcyBhbHNvIG5ldy4mbmJz cDsgSW4gb3JkZXIgZm9yIE1SVC1GUlIgdG8gZnVuY3Rpb24gcHJvcGVybHksIGFsbCBvZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoZSBvdGhl ciBub2RlcyBpbiB0aGUgbmV0d29yayB0aGF0IHN1cHBvcnQgTVJUIG11c3QgY29ycmVjdGx5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY29tcHV0 ZSBuZXh0LWhvcHMgYmFzZWQgb24gdGhlIHNhbWUgYWxnb3JpdGhtLCBhbmQgaW5zdGFsbCB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjb3Jy ZXNwb25kaW5nIGZvcndhcmRpbmcgc3RhdGUuJm5ic3A7IFRoaXMgaXMgaW4gY29udHJhc3QgdG8g b3RoZXIgRlJSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgbWV0aG9kcyB3aGVyZSB0aGUgY2FsY3VsYXRpb24gb2YgYmFja3VwIHBhdGhzIGdlbmVy YWxseSBpbnZvbHZlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IHJlcGVhdGVkIGFwcGxpY2F0aW9uIG9mIHRoZSBzaW1wbGVyIGFuZCB3aWRlbHkt ZGVwbG95ZWQgU1BGPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgYWxnb3JpdGhtLCBhbmQgYmFja3VwIHBhdGhzIHRoZW1zZWx2ZXMgcmUtdXNlIHRo ZSBmb3J3YXJkaW5nIHN0YXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgdXNlZCBmb3Igc2hvcnRlc3QgcGF0aCBmb3J3YXJkaW5nIG9mIG5vcm1h bCB0cmFmZmljLiZuYnNwOyBTZWN0aW9uIDE0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcHJvdmlkZXMgb3BlcmF0aW9uYWwgZ3VpZGFuY2UgcmVs YXRlZCB0byB2ZXJpZmljYXRpb24gb2YgTVJUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZm9yd2FyZGluZyBwYXRocy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7SW4gYWRkaXRpb24gdG8gc3VwcG9ydGluZyBJUCBh bmQgTERQIHVuaWNhc3QgZmFzdC1yZXJvdXRlLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBkaXZlcnNlIGZvcndhcmRpbmcgdG9wb2xvZ2ll cyBhbmQgZ3VhcmFudGVlIG9mIDEwMCUgY292ZXJhZ2UgcGVybWl0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZmFzdC1yZXJvdXRlIHRlY2hub2xv Z3kgdG8gYmUgYXBwbGllZCB0byBtdWx0aWNhc3QgdHJhZmZpYyBhczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGRlc2NyaWJlZCBpbiBbSS1ELmF0 bGFzLXJ0Z3dnLW1ydC1tYy1hcmNoXS4mbmJzcDsgSG93ZXZlciwgdGhlIGN1cnJlbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBkb2N1bWVudCBk b2VzIG5vdCBhZGRyZXNzIHRoZSBtdWx0aWNhc3QgYXBwbGljYXRpb25zIG9mIE1SVHMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBGaWd1cmUgMSBjb21wYXJlcyBk aWZmZXJlbnQgbWV0aG9kcyBvZiBwcm92aWRpbmcgRlJSIGZvciBJUCBhbmQgTERQPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdHJhZmZpYywgaWxs dXN0cmF0aW5nIHNvbWUgb2YgdGhlIHRyYWRlLW9mZnMgYmV0d2VlbiB0aGUgZGlmZmVyZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYXBwcm9h Y2hlcy4mbmJzcDsgRm9yIHNldmVyYWwgbWV0aG9kcywgdGhlIG1ldGhvZHMgYXJlIHNlcGFyYXRl ZCBpbnRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgbGluay1wcm90ZWN0aW5nIChMUCkgYW5kIG5vZGUtcHJvdGVjdGluZyAoTlApIHZhcmlhbnRz LiZuYnNwOyBUaGUgZmlyc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBjb2x1bW4gaW5kaWNhdGVzIHdoZXRoZXIgdGhlIG1ldGhvZCBwcm92aWRl cyAxMDAlIHByb3RlY3Rpb24gY292ZXJhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAod2hlbiB0b3BvbG9naWNhbGx5IGZlYXNpYmxlKS4mbmJz cDsgVGhlIHNlY29uZCBjb2x1bW4gaW5kaWNhdGVzIHdoZXRoZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvciBub3QgdHJhZmZpYyB0cmF2ZXJz aW5nIGFsdGVybmF0ZSBwYXRoIGNhbiBsb29wIHdoZW4gbXVsdGlwbGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBmYWlsdXJlcyBvY2N1ci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSB0aGlyZCBjb2x1bW4g Z2l2ZXMgYW4gZXN0aW1hdGUgb2YgdGhlIGFtb3VudCBvZiBjb21wdXRhdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmVkIGF0IGVh Y2ggbm9kZSB0byBzdXBwb3J0IHRoZSBGUlIgbWV0aG9kLCBpbiBhZGRpdGlvbiB0byB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1c3VhbCBT UEYgY29tcHV0YXRpb24gcm9vdGVkIGF0IHRoZSBjb21wdXRpbmcgbm9kZSBpdHNlbGYuJm5ic3A7 IFRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBtZXRyaWMgb2YgY29tcGFyaXNvbiBpcyBpbXBvcnRhbnQgZm9yIGltcGxlbWVudGF0aW9ucyB0 aGF0IHNlZWsgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBxdWlja2x5IHJlY29tcHV0ZSByZXBhaXIgcGF0aHMgZm9sbG93aW5nIHRoZWlyIGlu aXRpYWwgdXNlIGFmdGVyIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyB0b3BvbG9neSBjaGFuZ2UsIHdpdGhvdXQgcmVsaWFuY2Ugb24gYW4gZXh0 ZXJuYWwgc3lzdGVtLCBpbiBvcmRlciB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1pbmltaXplIHRoZSByaXNrIG9mIGEgbmV3IGZhaWx1cmUg b2NjdXJyaW5nIGJlZm9yZSB0aGUgbmV3IHJlcGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBhdGhzIGFyZSBpbiBwbGFjZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBmb3VydGggY29sdW1uIGluZGlj YXRlcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgYWRkaXRpb25hbCBsYWJlbHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGF0IG5lZWQgdG8gYmUg YXBwbGllZCB0byBwYWNrZXRzIHRvIHN1cHBvcnQgdGhlIEZSUiBtZXRob2QsIHdoaWxlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDt0aGUgZmlmdGgg Y29sdW1uIGdpdmVzIHRoZSBzaXplIG9mIHRoZSBNUExTIGxhYmVsIHRhYmxlIG5lZWRlZCB0bzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN1cHBv cnQgdGhlIEZSUiBtZXRob2QuJm5ic3A7IFRoZXNlIHR3byBtZXRyaWNzIG1heSBiZSB1c2VmdWwg Zm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg ZXZhbHVhdGluZyByZXF1aXJlbWVudHMgcGxhY2VkIG9uIGhhcmR3YXJlIHRvIHN1cHBvcnQgdGhl IGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IEZSUiBtZXRob2RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgVGhlIGxhc3QgY29sdW1uIGluZGljYXRlcyB0aGUgYWRkaXRpb25hbCByZXF1aXJlbWVu dHMgcGxhY2VkIG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IGNvbnRyb2wgcGxhbmUgYnkgdGhlIEZSUiBtZXRob2QsIGJleW9uZCB3aGF0 IGlzIHJlcXVpcmVkIGZvciBJR1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBzaG9ydGVzdCBwYXRoIGZvcndhcmRpbmcgd2l0aCBMRFAuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLSYjNDM7LS0t LS0tJiM0MzstLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwg TWV0aG9kJm5ic3A7IHwxMDAlIHwgQWx0LiB8IEFkZGl0aW9uYWwmbmJzcDsgfCBNYXguJm5ic3A7 IHwgTGFiZWwgdGFibGUgfCBDb250cm9sJm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfHByb3QufCBjYW4mbmJzcDsgfCBjb21wdXRhdGlvbiB8IGFkZGl0LnwmbmJzcDsm bmJzcDsmbmJzcDsgc2l6ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHBsYW5lJm5ic3A7Jm5i c3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfGNvdi4gfCBsb29w P3wgYXQgZWFjaCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IGxhYmVsc3wocmVsYXRpdmUgdG8g fCByZXFzLiZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IG5vZGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFNQRiBsYWJlbHMpIHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0mIzQzOy0tLS0t JiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+fCBNUlQtRlJSIHwgWWVzIHwgTm8mbmJzcDsmbmJzcDsgfCBlcXVpdmFsZW50Jm5ic3A7 IHwgMChMRFApfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzeCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8IE1SVC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCBMUCBhbmQmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgb2YgbGVzcyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IDEoSVApIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBzcGVjaWZpYyB8 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58IE5QJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IHRoYW4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgcHJvdG9jb2wgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCAzIFNQRnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgZXh0ZW5zLiZuYnNwOyB8PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLSYjNDM7 LS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij58IExGQSBMUCZuYnNwOyB8IE5vJm5ic3A7IHwgWWVzJm5ic3A7IHwmbmJzcDsg U1BGIHBlciZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxeCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IE5vbmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+fCBhbmQgTlAmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgbmVpZ2hib3ImbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0m IzQzOy0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0t LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+fCBSZW1vdGUmbmJzcDsgfCBObyZuYnNwOyB8IFllcyZuYnNwOyB8Jm5i c3A7IFNQRiBwZXImbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCBULUxEUCZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij58IExGQSBMUCZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBuZWlnaGJvciZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCBzZXNzaW9uJm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgZm9yIGVhY2ggfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCBzZWxlY3RlZCB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IFBRIG5vZGUmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tJiM0MzstLS0tLS0m IzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCBSZW1v dGUmbmJzcDsgfCBObyZuYnNwOyB8IFllcyZuYnNwOyB8IFNQRiBwZXIgbmJyIHwmbmJzcDsmbmJz cDsgMSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDF4Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgVC1MRFAmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCBMRkEgTlAmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgYW5kIFNQRiBw ZXIgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgc2Vzc2lvbiZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHBl ciBQUSBub2RlIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IGZvciBlYWNoIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwg ZXZhbHVhdGVkJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IHNlbGVjdGVkIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgUFEgbm9kZSZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLSYjNDM7LS0tLS0mIzQzOy0t LS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58 IE5vdC1WaWEgfCBZZXMgfCBObyZuYnNwOyZuYnNwOyB8IFNQRiBwZXImbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7IHwmbmJzcDsgKGF2ZXJhZ2UmbmJz cDsmbmJzcDsgfCBULUxEUCZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij58IExQIGFuZCZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBsaW5rIGFuZCZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgbnVt YmVyIG9mJm5ic3A7IHwgc2Vzc2lvbiZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij58IE5QJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHBlciBu b2RlJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyBuZWlnaGJvcnMpIHwgZm9yIGVhY2ggfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBpbiB0b3BvbG9neSB8ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IG5icidzIG5icnw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0t LS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tJiM0Mzs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwgVEktTEZBJm5ic3A7IHwg WWVzIHwgWWVzJm5ic3A7IHwgU1BGIHBlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7IDImbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxeCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHVzZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCBMUCB3aXRoIHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IG5laWdo Ym9yJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IFNQUklORyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58IHN5bW0uJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IGZvciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58IG1ldHJpY3MgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgbGFi ZWwmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCBkaXN0LiZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLSYjNDM7LS0tLS0mIzQzOy0t LS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58 IFRJLUxGQSZuYnNwOyB8IFllcyB8IFllcyZuYnNwOyB8ICMgb2YgU1BGcyZuYnNwOyZuYnNwOyB8 ZGVwdGgmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxeCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IHVzZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCBOUCBvciZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBkZXBl bmRlbnQmbmJzcDsmbmJzcDsgfGRlcGVuZC18Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgU1BSSU5HJm5ic3A7 Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwgTFAgd2l0 aCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCBvbiB0b3BvbG9neSB8ZW50IG9uIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBmb3ImbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+fCBhc3ltbS4mbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfHRvcG8uJm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBsYWJlbCZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58IG1ldHJpY3MgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgZGlzdC4m bmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+JiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0m IzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RmlndXJlIDE6IENvbXBhcmlzb24gb2YgSVAvTERQIEZSUiBNZXRob2RzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBNUlQ6Jm5ic3A7Jm5ic3A7IE1SVCBwcm92aWRl cyAxMDAlIGNvdmVyYWdlIGZvciBsaW5rIGFuZCBub2RlIHByb3RlY3Rpb24sIGFuZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRyYWZmaWMgb24gdGhlIGFsdGVybmF0ZSBwYXRocyB3aWxsIG5vdCBsb29wLiZuYnNw OyBUaGUgY29tcHV0YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXF1aXJlZCBvbiBlYWNoIG5vZGUgaXMg ZXF1aXZhbGVudCB0byBsZXNzIHRoYW4gMyBhZGRpdGlvbmFsIFNQRnM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp biB0ZXJtcyBvZiBjb21wdXRhdGlvbmFsIGNvbXBsZXhpdHkuJm5ic3A7IEZvciBJUCB0cmFmZmlj LCBNUlQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyByZXF1aXJlcyBvbmUgYWRkaXRpb25hbCBsYWJlbCwgd2hpbGUg Zm9yIExEUCB0cmFmZmljLCBubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZGl0aW9uYWwgbGFiZWxzIGFyZSBu ZWVkZWQuJm5ic3A7IEhvd2V2ZXIsIHRoZSBzaXplIG9mIHRoZSBNUExTIGxhYmVsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGFibGUgaXMgdGhyZWUgdGltZXMgd2hhdCB3b3VsZCBub3JtYWxseSBiZSByZXF1aXJl ZCBmb3Igc2hvcnRlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtwYXRoIExEUCBmb3J3YXJkaW5nLCBkdWUgdG8g dGhlIHByZXNlbmNlIG9mIGFkZGl0aW9uYWwgcmVkIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJsdWUgbGFi ZWxzIGZvciBlYWNoIEZFQy4mbmJzcDsgTVJUIHJlcXVpcmVzIHByb3RvY29sIGV4dGVuc2lvbnMg aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBvcmRlciB0byBhbGxvdyBhIG5vZGUgdG8gYWR2ZXJ0aXNlIHN1cHBv cnQgZm9yIE1SVCBhcyB3ZWxsIGFzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSBmb3IgdGhlIEdBREFH IFJvb3QgU2VsZWN0aW9uIFByaW9yaXR5LiAmbmJzcDtJdCBhbHNvIHJlcXVpcmVzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgc3VwcG9ydCBmb3IgbXVsdGktdG9wb2xvZ3kgTERQIGV4dGVuc2lvbnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBMb29wLUZyZWUgQWx0ZXJuYXRlcyAo TEZBKTombmJzcDsmbmJzcDsgTEZBcyBbUkZDNTI4Nl0gcHJvdmlkZSBsaW1pdGVkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdG9wb2xvZ3ktZGVwZW5kZW50IGNvdmVyYWdlIGZvciBsaW5rIGFuZCBub2RlIHByb3Rl Y3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzdHJpY3Rpb25zIG9uIGNob2ljZSBvZiBhbHRlcm5hdGVz IGNhbiBiZSByZWxheGVkIHRvIGltcHJvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb3ZlcmFnZSwgYnV0IHRo aXMgY2FuIGNhdXNlIGZvcndhcmRpbmcgbG9vcHMgaWYgYSB3b3JzZSBmYWlsdXJlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaXMgZXhwZXJpZW5jZWQgdGhhbiBwcm90ZWN0ZWQgYWdhaW5zdC4mbmJzcDsgW1JGQzY1 NzFdIGRpc2N1c3NlcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcHBsaWNhYmlsaXR5IG9mIExGQSB0byBk aWZmZXJlbnQgdG9wb2xvZ2llcyB3aXRoIGEgZm9jdXMgb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tb24g UG9QIGFyY2hpdGVjdHVyZXMuJm5ic3A7IFRoZSBjb21wdXRhdGlvbiByZXF1aXJlZCBpcyBvbmUg U1BGIHBlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5laWdoYm9yLiZuYnNwOyBMRkEgaW1wb3NlcyBubyBhZGRp dGlvbmFsIGxhYmVscyBpbXBvc2VkLCBoYXMgbm8gaW1wYWN0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb24gdGhl IGxhYmVsIHRhYmxlIHNpemUsIGFuZCBoYXMgbm8gYWRkaXRpb25hbCBjb250cm9sIHBsYW5lPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDtSZW1vdGUgTEZBOiZuYnNwOyZuYnNwOyBSZW1vdGUgTEZBIFtSRkM3NDkwXSBp bXByb3ZlcyBjb3ZlcmFnZSBvdmVyIExGQSBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib3RoIGxpbmsgYW5k IG5vZGUgcHJvdGVjdGlvbiwgYnV0IGl0IGRvZXMgbm90IGd1YXJhbnRlZSAxMDAlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgY292ZXJhZ2UuJm5ic3A7IFRoZSBhbHRlcm5hdGVzIGNhbiBhbHNvIGxvb3Agd2l0aCB3 b3JzZSB0aGFuIGV4cGVjdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmFpbHVyZXMuJm5ic3A7IENvbXB1dGF0 aW9uIGZvciBsaW5rIHByb3RlY3Rpb24gaXMgb25lIFNQRiBwZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZWln aGJvciwgd2hpbGUgY29tcHV0YXRpb24gZm9yIG5vZGUgcHJvdGVjdGlvbiByZXF1aXJlcyBhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGFkZGl0aW9uYWwgU1BGIHBlciBQUSBub2RlIFtJLUQuaWV0Zi1ydGd3Zy1y bGZhLW5vZGUtcHJvdGVjdGlvbl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVtb3RlIExGQSBjYW4gaW1wb3Nl IHVwIHRvIG9uZSBhZGRpdGlvbmFsIGxhYmVsIG9uIHRoZSBwYWNrZXQsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YnV0IGRvZXMgbm90IGluY3JlYXNlIHRoZSBzaXplIG9mIHRoZSBsYWJlbCB0YWJsZS4mbmJzcDsg SXQgcmVxdWlyZXMgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFQtTERQIHNlc3Npb24gZm9yIGVhY2ggc2VsZWN0 ZWQgUFEgbm9kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE5v dC1WaWE6Jm5ic3A7Jm5ic3A7IE5vdC1WaWEgW1JGQzY5ODFdIHByb3ZpZGVzIDEwMCUgY292ZXJh Z2UgZm9yIGxpbmsgYW5kIG5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmYWlsdXJlcyBhbmQgZG9lcyBub3Qg aGF2ZSBwb3RlbnRpYWwgbG9vcGluZyBhbW9uZyBhbHRlcm5hdGVzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBjb21wdXRhdGlvbiBpcyBoaWdoIHdpdGggYW4gU1BGIHBlciBwb3RlbnRpYWwgZmFpbHVyZSBw b2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IChhbGwgbGlua3MgYW5kIG5vZGVzIGluIHRoZSB0b3BvbG9neSku Jm5ic3A7IFdoZW4gaW1wbGVtZW50ZWQgd2l0aCBMRFAsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm90LVZpYSBh ZGRzIG9uZSBhZGRpdGlvbmFsIGxhYmVsIHRvIGEgdHVubmVsbGVkIHBhY2tldC4mbmJzcDsgSXQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBzaWduaWZpY2FudGx5IGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgbGFi ZWwgdGFibGUsIG11bHRpcGx5aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aXQgYnkgcm91Z2hseSB0aGUgYXZl cmFnZSBudW1iZXIgb2YgbmVpZ2hib3JzLiZuYnNwOyBOb3QtVmlhIGFsc288bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyByZXF1aXJlcyB0YXJnZXRlZCBMRFAgc2Vzc2lvbnMgdG8gZWFjaCBuZWlnaGJvcidzIG5laWdo Ym9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVEktTEZBOiZu YnNwOyZuYnNwOyBUb3BvbG9neSBJbmRlcGVuZGVudCBMb29wLWZyZWUgQWx0ZXJuYXRlIEZhc3Qg UmUtcm91dGUgKFRJLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExGQSkgW0ktRC5mcmFuY29pcy1ydGd3Zy1zZWdt ZW50LXJvdXRpbmctdGktbGZhXSBhaW1zIHRvIHByb3ZpZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaW5rIGFu ZCBub2RlIHByb3RlY3Rpb24gb2Ygbm9kZSBhbmQgYWRqYWNlbmN5IHNlZ21lbnRzIHdpdGhpbiB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBTZWdtZW50IFJvdXRpbmcgKFNSKSBmcmFtZXdvcmsuJm5ic3A7IEl0 IGd1YXJhbnRlZXMgY29tcGxldGUgY292ZXJhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIFRJLUxGQSBj b21wdXRhdGlvbiBmb3IgbGluay1wcm90ZWN0aW9uIGlzIGZhaXJseTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0 cmFpZ2h0Zm9yd2FyZCwgd2hpbGUgdGhlIGNvbXB1dGF0aW9uIGZvciBub2RlLXByb3RlY3Rpb24g aXMgbW9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbXBsZXguJm5ic3A7IEZvciBsaW5rLXByb3RlY3Rpb24g d2l0aCBzeW1tZXRyaWMgbGluayBjb3N0cywgVEktTEZBPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FuIHByb3Zp ZGUgY29tcGxldGUgY292ZXJhZ2UgYnkgcHVzaGluZyB1cCB0byB0d28gYWRkaXRpb25hbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxhYmVscy4mbmJzcDsgRm9yIG5vZGUgcHJvdGVjdGlvbiBvbiBhcmJpdHJhcnkg dG9wb2xvZ2llcywgdGhlIGxhYmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RhY2sgc2l6ZSBjYW4gZ3JvdyBz aWduaWZpY2FudGx5IGJhc2VkIG9uIHJlcGFpciBwYXRoLiZuYnNwOyBOb3RlIHRoYXQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUSS1MRkEgcmVxdWlyZXMgc2hvcnRlc3QgcGF0aCBmb3J3YXJkaW5nIGJhc2VkIG9u IFNSIE5vZGUtU0lEcywgYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvcHBvc2VkIHRvIExEUCBsYWJlbHMsIGlu IG9yZGVyIHRvIGNvbnN0cnVjdCBsYWJlbCBzdGFja3MgZm9yPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmFja3Vw cyBwYXRocyB3aXRob3V0IHJlbHlpbmcgb24gYSBsYXJnZSBudW1iZXIgb2YgdGFyZ2V0ZWQgTERQ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgc2Vzc2lvbnMgdG8gbGVhcm4gcmVtb3RlIEZFQy1sYWJlbCBiaW5kaW5n cy4mbmJzcDsgSXQgYWxzbyByZXF1aXJlcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2Ugb2YgQWRqLVNJ RHMgdG8gYWNoaWV2ZSAxMDAlIGNvdmVyYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5Gcm9tOiBTdGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbV0N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VudDogV2VkbmVzZGF5 LCBEZWNlbWJlciAyMywgMjAxNSA2OjI5IEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5UbzogQ2hyaXMgQm93ZXJzICZsdDtjYm93ZXJzQGp1bmlwZXIubmV0Jmd0Ozsg ZHJhZnQtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmVAdG9vbHMuaWV0Zi5vcmc7IHJ0Z3dnQGll dGYub3JnOyBBbHZhcm8gUmV0YW5hICZsdDthcmV0YW5hQGNpc2NvLmNvbSZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YmplY3Q6IFJlOiBXR0xDIGZvciBkcmFm dC1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5IaSBDaHJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFua3MgZm9yIGFkZHJl c3NpbmcgbXkgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgd2lsbCB0 cmltIHRoZSBlbWFpbCB0byBqdXN0IHRoZSBhcmVhcyB0aGF0IG5lZWQgZnVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPk9uIDIxLzEyLzIwMTUgMTQ6NDcsIENocmlzIEJvd2VycyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgPT09PT09PT09PT08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgMS4mbmJzcDsgSW50cm9kdWN0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFNCJmd0OyBUaGUgdGV4dCBzaG91bGQg c3RhcnQgd2l0aCB0aGUgaW52YXJpYW50cyBhbmQgYXNzdW1wdGlvbnMgdG8NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBTQiZndDsgY29ycmVjdGx5IHNjb3Bl IHRoZSBjbGFpbXMgaW4gdGhlIGludHJvZHVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZndDsgW0NCXSBDaGFuZ2VkIHRoZSB0ZXh0IHRvIHJlYWQ6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IGEgc29sdXRpb24gZm9yIElQL0xEUCBmYXN0LXJlcm91dGUmbmJzcDsmbmJzcDsmbmJzcDsgW1JG QzU3MTRdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TQiZndDsgSSB0aGluayB0aGUg YXNzdW1wdGlvbnMgYXJlIGZvciBleGFtcGxlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+LSBTaW5nbGUgbGluayBvciBub2RlIGZhaWx1cmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gQ2FuJ3QgcmVtZW1iZXIgaWYgeW91IGhhdmUgdGhl IG1lYW5zIHRvIGRlYWwgd2l0aCBTUkxHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4tIExGIHRlY2huaXF1ZSBpcyBpbiBwbGFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+LSBtZXRob2Qgb2YgZGV0ZWN0aW5nIHNpdHVhdGlvbiBvdXRzaWRl IHlvdXIgYXNzdW1wdGlvbnMgaXMgaW4gcGxhY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+SW4gb3RoZXIgd29yZHMsIHlvdSBuZWVkIHRvIGRlc2NyaWJlIGFzc3VtcHRpb25zIHlvdSBh cmUgbWFraW5nIG1ha2luZyBhYm91dCB0aGUgZW52aXJvbm1lbnQgaW4gd2hpY2ggdGhpcyBzb2x1 dGlvbiB3b3Jrcy4gV2hpbHN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5SRkM1NzE0IHRhbGtzIGFyb3VuZCB0aGUgcHJvYmxlbSwgYSBzb2x1dGlvbiBuZWVkcyB0byBi ZSBxdWl0ZSBzcGVjaWZpYyBhYm91dCB3aGVuIGl0IGJyZWFrcywgKGEpIHRvIGFsZXJ0IHRoZSBv cGVyYXRvciwgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4oYikg dG8gbWFrZSBzdXJlIHRoYXQgdGhlIHNvbHV0aW9uIGNvbnNpZGVycyB0aGUgY29uc2VxdWVuY2Vz IG9mIG9wZXJhdGluZyBvdXRzaWRlIHRoZSBzcGVjaWZpZWQgZW52ZWxvcGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPltDQl0gVGhlIDM8c3VwPnJkPC9zdXA+IHBhcmFncmFwaCBvZiB0 aGUgcmV2aXNlZCBpbnRyb2R1Y3Rpb24gd2FzIGFkZGVkIHRvIGFkZHJlc3MgdGhpcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZndDsgU0ImZ3Q7IEkgdGhpbmsgeW91IGhhdmUgdG8gc2F5IHdo ZXJlIHRoZSB0cmVlcyBhcmUgcm91dGVkIHNpbmNlIG9ubHkgdHdvDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgU0ImZ3Q7IG1lYW4geW91IG5lZWQgYSByb290 LCBhbmQgeW91IG5lZWQgdG8gbm90ZSB0aGF0IHRoaXMgaXMgZGlmZmVyZW50DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgU0ImZ3Q7IGZyb20gdGhlIHVuZGVy bHlpbmcgSUdQIGluIHdoaWNoIHRoZXJlIGlzIGEgdHJlZSBwZXIgbm9kZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZndDsgW0NCXSZuYnNwOyBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUg ZGlzdGluY3Rpb24gdGhhdCB5b3Ugc3VnZ2VzdCBub3RpbmcuJm5ic3A7IFRoZSBNUlQgY29tcHV0 YXRpb24gcnVuIGF0IGVhY2ggc291cmNlIG5vZGUgcHJvZHVjZXMgYSBkaXN0aW5jdCByZWQgYW5k IGJsdWUgdHJlZSBmb3IgZWFjaCBkZXN0aW5hdGlvbiBub2RlIHdpdGggZWFjaCB0cmVlIHJvb3Rl ZA0KIGF0IGFuZCBkaXJlY3RlZCB0b3dhcmRzIHRoZSBkZXN0aW5hdGlvbiBub2RlLiZuYnNwOyBU aGUgZW5kIHJlc3VsdCBpcyBzaW1pbGFyIHRvIHdheSB0aGF0IHRoZSBmb3J3YXJkIFNQRiBjb21w dXRhdGlvbiBydW4gYXQgZWFjaCBzb3VyY2Ugbm9kZSBwcm9kdWNlcyBhIHNob3J0ZXN0IHBhdGgg dHJlZSBmb3IgZWFjaCBkZXN0aW5hdGlvbiBub2RlIHdpdGggZWFjaCB0cmVlIHJvb3RlZCBhdCBh bmQgZGlyZWN0ZWQgdG93YXJkcyB0aGUgZGVzdGluYXRpb24gbm9kZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+U0ImZ3Q7IE1heWJlIEkgYW0gY29uZnVzZWQuIEFzIEkgcmVjYWxsIHlv dSBuZWVkIHRvIGRldGVybWluZSBhIHNpbmdsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+bG93cG9pbnQgYXMgdGhlIHN0YXJ0aW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5wb2ludCBmb3IgeW91ciByZXBhaXIgdG9wb2xvZ2llcy4gRG9l c24ndCB0aGF0IG1lYW4gdGhhdCBlZmZlY3RpdmVseSBiZWNvbWUgdGhlIHJvb3Qgb2YgYSBwYWly IG9mIHJlcGFpciB0cmVlcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QWxzbyB0aGUg bG93IHBvaW50IGNhbiBtb3ZlIHVuZGVyIGNlcnRhaW4gY2lyY3Vtc3RhbmNlcywgYW5kIEkgdGhp bmcgdGhhdCB3aWxsIGltcGFjdCB0aGUgcmVwYWlyIHRvcG9sb2d5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5bQ0JdIFRoZSBhbGdvcml0aG0gaW4gZHJhZnQtaWV0Zi1ydGd3Zy1tcnQt ZnJyLWFsZ29yaXRobSB1c2VzIGxvd3BvaW50IHZhbHVlcyZuYnNwOyB0byBpZGVudGlmeSBlYXJz IGFuZCBibG9ja3Mgd2hlbiBkb2luZyBhIGRlcHRoLWZpcnN0LXNlYXJjaCB0cmF2ZXJzYWwgb2Yg dGhlIG5ldHdvcmsgZ3JhcGguJm5ic3A7IFRoaXMgaXMgY292ZXJlZCBpbiBTZWN0aW9uDQogNC4z IG9mIHRoYXQgZG9jLiZuYnNwOyBUaGUgREZTIHRyYXZlcnNhbCBzdGFydHMgYXQgdGhlIEdBREFH IHJvb3QsIGFuZCB0aGUgY2hvaWNlIG9mIEdBREFHIHJvb3Qgd2lsbCBnZW5lcmFsbHkgYWZmZWN0 IHRoZSBHQURBRyBhbmQgdGhlIHJlZCBhbmQgYmx1ZSB0cmVlcy4mbmJzcDsgSSBhZGRlZCB0ZXh0 IGluIHRoZSBsYXRlc3QgcmV2aXNpb24gdGhhdCBhZGRyZXNzZXMgdGhlIGNvbmNlcm4gb2YgaGF2 aW5nIHRoZSBHQURBRyByb290IGNoYW5nZSB0b28gb2Z0ZW4uJm5ic3A7DQogJm5ic3A7Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU3VtbWFyeSBDb21wYXJpc29uIG9mIElQL0xEUCBGUlIgTWV0aG9k czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7IE1ldGhvZCB8Jm5ic3A7Jm5ic3A7IENvdmVyYWdlJm5ic3A7IHwmbmJzcDsgQWx0ZXJuYXRl Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgQ29tcHV0YXRpb24gKGluIFNQRnMpJm5ic3A7Jm5i c3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgTG9vcGluZz8m bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgTVJULUZSUiB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwMCUmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOb25lJm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVzcyB0 aGFuIDMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsgTGluay9Ob2RlJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IExG QSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IFBhcnRpYWwmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyBQb3NzaWJsZSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHBlciBuZWlnaGJvciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBMaW5rL05vZGUmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsgUmVtb3RlIHwmbmJzcDsmbmJzcDsgUGFydGlhbCZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7IFBvc3NpYmxlJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgcGVyIG5laWdoYm9yIChsaW5r KSBvciZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgTEZBJm5ic3A7Jm5i c3A7IHwmbmJzcDsgTGluay9Ob2RlJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBuZWln aGJvcidzIG5laWdoYm9yIChub2RlKSB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IE5vdC1WaWEgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAx MDAlJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm9uZSZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlciBsaW5rIGFu ZCBub2RlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IExpbmsv Tm9kZSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7fCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBUSS1MRkEgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAxMDAlJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgUG9zc2libGUmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBwZXIgbmVpZ2hib3IgKGxpbmspIG9yJm5ic3A7Jm5ic3A7 IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7IExpbmsvTm9kZSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsg bmVpZ2hib3IncyBuZWlnaGJvciAobm9kZSkgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tLS0t LS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t JiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgU0ImZ3Q7IEkgcmVh bGx5IHdvbmRlciBob3cgaW1wb3J0YW50IHRoZSBjb21wdXRhdGlvbmFsIGNvbXBsZXhpdHkgaXMN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBTQiZndDsgZ2l2 ZW4gdGhhdCB3ZSBhcmUgbW92aW5nIHRvIGFuIFNETiB3b3JsZCB3aGVyZSB0aGVzZSBjYWxjdWxh dGlvbnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBTQiZn dDsgY2FuIGJlIG9mZmxvYWRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZndDsgU0ImZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m Z3Q7IFNCJmd0OyBJIHRoaW5rIHRoYXQgaXQgaXMgZmFpciB0byBub3RlIHRoYXQgdGhlIG90aGVy IG1ldGhvZCB1c2UgdGhlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZndDsgU0ImZ3Q7IGV4aXN0aW5nIHJvdXRpbmcgcHJvdG9jb2wgYW5kIGNhbGN1bGF0ZSBhbHRl cm5hdGUgcGF0aHMgdXNpbmcgdGhlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZndDsgU0ImZ3Q7IG1ldGhvZHMgb2YgdGhhdCByb3V0aW5nIHByb3RvY29sLiBXaGVy ZWFzIHdpdGggTVJUIHlvdSByZWFsbHkgaGF2ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFNCJmd0OyBhIG5ldyByb3V0aW5nIHByb3RvY29sIHdpdGggYWxs IG9mIHRoZSBhc3NvY2lhdGVkIG9wZXJhdGlvbnMgb3ZlcmhlYWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TQiZndDsgSSB0aGluayB0aGlzIGRlc2VydmVzIGNvbnNp ZGVyYXRpb24uIFRoZSByb3V0ZSBjb21wdXRhdGlvbmFsIHdvcmxkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5oYXMgbW92ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPm9uIHNpbmNlIHRoaXMgd29yayB3YXMgc3RhcnRlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+W0NCXSZuYnNwOyBUaGUgbGF0ZXN0IHJldmlzaW9uIHRyaWVz IHRvIHByb3ZpZGUgbW9yZSBjb250ZXh0IGZvciB3aGVuIHJlZHVjaW5nIGNvbXB1dGF0aW9uIHRp bWUgbWF5IGJlIHVzZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IDYuMS4xLjEuJm5ic3A7IFRvcG9sb2d5LXNjb3BlZCBG RUMgZW5jb2RlZCB1c2luZyBhIHNpbmdsZSBsYWJlbCAoT3B0aW9uIDFBKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUkZDNzMw N10gcHJvdmlkZXMgYSBtZWNoYW5pc20gdG8gZGlzdHJpYnV0ZSBGRUMtTGFiZWwgYmluZGluZ3M8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc2NvcGVkIHRvIGEgZ2l2ZW4gTVBMUyB0b3BvbG9neSAocmVwcmVzZW50ZWQg YnkgTVBMUyBNVC1JRCkuJm5ic3A7IFRvIHVzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtdWx0aS10b3BvbG9neSBM RFAgdG8gY3JlYXRlIE1SVCBmb3J3YXJkaW5nIHRvcG9sb2dpZXMsIHdlIGFzc29jaWF0ZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0d28gTVBMUyBNVC1JRHMgd2l0aCB0aGUgTVJULVJlZCBhbmQgTVJULUJsdWUgZm9y d2FyZGluZyB0b3BvbG9naWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiBhZGRpdGlvbiB0byB0aGUgZGVmYXVs dCBzaG9ydGVzdCBwYXRoIGZvcndhcmRpbmcgdG9wb2xvZ3kgd2l0aCBNVC08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SUQ9MC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgU0ImZ3Q7IFByZXN1 bWFibHkgeW91IGNvdWxkIE1SVCBhIHRvcG9sb2d5IG90aGVyIHRoYW4gZGVmYXVsdD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgW0NCXSBJdCBjb3VsZCBiZSBkb25lLCBi dXQgd2UgZm9jdXNlZCBvbiBzdXBwb3J0aW5nIHRoZSB1c2UgY2FzZSB1c2luZyB0aGUgZGVmYXVs dCBJR1AgdG9wb2xvZ3kuJm5ic3A7IFRoZXJlIGlzIGV4aXN0aW5nIHRleHQgaW4gc2VjdGlvbiA3 IGV4cGxhaW5pbmcgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IERlcGxveW1lbnQgc2NlbmFyaW9zIHVzaW5nIG11bHRp LXRvcG9sb2d5IE9TUEYgb3IgSVMtSVMsIG9yIHJ1bm5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm90aCBJU0lT IGFuZCBPU1BGIG9uIHRoZSBzYW1lIHJvdXRlcnMgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFNCJmd0 OyBUbyBiZSBjbGVhciAtIHlvdSBuZWVkIDMgKiB0aGUgbnVtYmVyIG9mIGRlbGl2ZXJ5IGxhYmVs cyBpbiB0aGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBT QiZndDsgbmV0d29yaywgYW5kIGluIHNvbWUgY2FzZXMgdGhlc2UgbGFiZWxzIGlkZW50aWZ5IHBy ZWZpeCBvciBhIFZQTg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m Z3Q7IFNCJmd0OyBleGl0IHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jmd0OyBTQiZndDsgVGhpcyBpcyBhIGxvdCBtb3JlIGxhYmVscyB0aGFuIHNvbWUgb2Yg dGhlIGNvbXBldGluZyBzY2hlbWVzIGFuZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mZ3Q7IFNCJmd0OyBzbyBJIHRoaW5rIHdlIHJlYWxseSBuZWVkIGEgbGFiZWwg dGFibGUgc2l6ZSBjb21wYXJpc29uIGluIHRoZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFNCJmd0OyBjb21wYXJpc29uIHNlY3Rpb24gZWFybGllciBpbiB0 aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TQiZn dDsgTm8gY29tbWVudCBvbiB0aGUgYWJvdmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PltDQl0gVGhpcyBpcyBpbmNsdWRlZCBpbiB0aGUgdGFibGUgYW5kIGRpc2N1c3Npb24gaW4gdGhl IGxhdGVzdCByZXZpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR05MB61485BE58B3F2A3CCA10FC8A9C80BY2PR05MB614namprd_-- From nobody Wed Jan 13 01:31:34 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5AE1ACD3F; Wed, 13 Jan 2016 01:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDMFHYZ4N5F3; Wed, 13 Jan 2016 01:31:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935911ACD3E; Wed, 13 Jan 2016 01:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2254; q=dns/txt; s=iport; t=1452677491; x=1453887091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9rYGX0lQFYMH2GV7vLw9N0i90bLNkNvCPN3V0NnDmr0=; b=kHsbnJK8rJlU4jJo1O6B+XByzCrRygn6hX/oE4FWJyj4s6uUwyBePpXm 7TpEnU7YNwp7yq8GwFQaE3vbiZCgakMxHpu+HqtnFmTTNkx2120TXEYHS JZZEFmDLwpQUfsMB1GdBfDdeRFiYUyWdDheYefElWg8+ALID9/oDEhFpQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgAlGZZW/5BdJa1egzpSbQaIU7McA?= =?us-ascii?q?Q2BZCKFbQKBKzgUAQEBAQEBAYEKhDUBAQQ6PQIQAgEINhAyJQIEAQ0FiC4Ov3A?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlaEf4k9BY1BiVQBhUKIF4FeSoN6iF6OU?= =?us-ascii?q?wEgAQFChApyAYUTgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,288,1449532800"; d="scan'208";a="65798378" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 09:31:30 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0D9VUac024389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 09:31:30 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Jan 2016 04:31:29 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 13 Jan 2016 04:31:29 -0500 From: "Nitish Gupta (nitisgup)" To: "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjAA= Date: Wed, 13 Jan 2016 09:31:29 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.34.49] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "jhaas@juniper.net" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:31:33 -0000 Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had taken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific comments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 at >prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt >>has been successfully submitted by Nitish Gupta and posted to the >>IETF repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > From nobody Thu Jan 14 13:58:46 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617DC1B2C6A; Thu, 14 Jan 2016 13:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWtwi6rZln7J; Thu, 14 Jan 2016 13:58:41 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5711B2C69; Thu, 14 Jan 2016 13:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14677; q=dns/txt; s=iport; t=1452808721; x=1454018321; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vBEg9Yee2yldCQlkFbVzPnCkXD1ErKpgJZ8yyufcJ/I=; b=C1gFGBPrvGpvXqC9SJ4zh7DPaAHsHPzP1v+ylV10KLaOm23PJPbJZbe0 8rT02p7Jd2RNAq/8AIKZ1qhCGPipqcpx10dINFlUtfVCLz9pFlZ5Y2XmY mdSJuG5qc85ZM3nR659iSGxo4V/c3pK783ZeKs0+CjZm8XzvdAiSLx/l9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgBHGZhW/5JdJa1egm5MUm0GhCWEL?= =?us-ascii?q?bMVAQ2BYyaFLzoCgT84FAEBAQEBAQGBCoQ1AQEEeRACAQgOBBsSBzIUAw4BAQQ?= =?us-ascii?q?BDQUbiA4OwF8BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZVAYN6gQSEHRRTEoQnB?= =?us-ascii?q?ZMThAMBhUOIF4FehESDK4U0jlYBIAEBQoQKcgWEYkKBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,296,1449532800"; d="scan'208,217";a="227708296" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2016 21:58:40 +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 u0ELwePO015280 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jan 2016 21:58:40 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.1104.5; Thu, 14 Jan 2016 15:58:39 -0600 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.1104.009; Thu, 14 Jan 2016 15:58:39 -0600 From: "Alvaro Retana (aretana)" To: Chris Bowers , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Topic: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Index: AdFLymRfrf/gcWOOTVmsW4QZcyGUtgDVLR6A Date: Thu, 14 Jan 2016 21:58:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_D2BD4A66100DB9aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 21:58:44 -0000 --_000_D2BD4A66100DB9aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 1/10/16, 12:16 PM, "Chris Bowers" > wrote: Chris: Hi! Thanks for the work in addressing my comments. I just have a couple of min= or comments (below). I will start the IETF Last Call. Thanks! Alvaro. =85 Major: 1. In general, I feel uncomfortable with documents making value statemen= ts related, for example, to how they perform against different solutions. = The purpose of this document should be to describe the technology, not to c= ompare against other solutions =97 that work (if wanted/needed) should be d= one in a different document. Please remove comparisons to other technology= and relative statements. Some examples: * Abstract: "MRT is also extremely computationally efficient=85computat= ion is less than the LFA computation..." As was expressed on the list, may= be CPU cycles are not that important if compared to other aspects=85 * Introduction: "Other existing or proposed solutions are partial solut= ions or have significant issues, as described below." It is ok to describe= other solutions, but please limit the description to the facts. * About the table: there are obviously other columns that could have be= en included, which means that the table is not complete. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] The abstract and introduction have been significantly revised to try = to remove value statements. I modified the comparison table and added seve= ral columns, trying to provide a factual comparison of tradeoffs based on d= ifferent metrics without making value judgements. (See the revised docume= nt or main diff above.) However, I am also willing to simply remove the ta= ble and descriptions, if that makes more sense. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am not crazy about the table. The added columns make it a little better= , but even if there are no judgements people will read into it.. I think Stewart had commented on it as well =97 I would like to see his opi= nion as well. =85 1. Operations/Management Considerations * Given that the MRT paths don't follow the shortest paths, or even pot= entially planned backup paths in the network, I think you should include so= mething about the potential impact related to capacity planning, congestion= , stretch, etc. * What about address management? Are there considerations about assign= ment and management for the additional loopbacks required for IP tunnels? * Section 15. (Applying Policy to Select from Multiple Possible Alterna= tes for FRR) basically says that policy can be applied "to select the best = alternate from those provided by MRT and other FRR technologies". You're r= ight to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many o= f the potential criteria that one might take into account when evaluating d= ifferent alternates for selection". What are the considerations that shoul= d be taken into account when comparing between MRT and others? Are the cri= teria and requirements outlined in I-D.ietf-rtgwg-lfa-manageability applica= ble? Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-sp= ecific, should it be a Normative reference? [Note that there's a similar co= mment related to I-D.ietf-rtgwg-lfa-manageability in my review of draft-ie= tf-rtgwg-mrt-frr-algorithm.] * Applicability/Guidance for Operators * Section 4. (Maximally Redundant Trees (MRT)) clearly explains about t= he impact of not having a 2-connected network for MRT to be applicable. Se= ction 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks = about partial implementation in an area. * I think it would be important to consolidate some of that guidance (t= here's probably more) in a single place. Note that I'm not looking for a 3= 0 page extension (a la RFC6571), just some general guidance. * Given that both Sections 14 and 15 were added just in the latest vers= ion of the document, please consider taking a look at RFC5706. * [Nit] Consider making Section 15. (Applying Policy to Select from Mul= tiple Possible Alternates for FRR) a sub-section of Section 14. (Operations= and Management Considerations). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] These changes are shown in this diff: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/c36= 1f37638390a1b0364d67726367aabef203976 After those changes it looks like the reference to I-D.ietf-rtgwg-lfa-manag= eability is no longer needed. =85 We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm] Just taking advantage of this text to say that you may want to edit away th= e use of "we" in the text. "We" who? Most of the statements may be cleare= r in the third person. Just a style nit.. --_000_D2BD4A66100DB9aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <93DB100848CEB94C8387F428225C719A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    On 1/10/16, 12:16 PM, "Chris Bowers" <cbowers@juniper.net> wrote:

    Chris:

    Hi!

    Thanks for the work in addressing my comments.  I just have a cou= ple of minor comments (below).  I will start the IETF Last Call.

    Thanks!

    Alvaro.


    =85
    Major:
    1. In general= , I feel uncomfortable with documents making value statements related, for = example, to how they perform against different solutions.  The purpose= of this document should be to describe the technology, not to compare against other solutions =97 that work (if wante= d/needed) should be done in a different document.  Please remove compa= risons to other technology and relative statements.  Some examples:
    • Abstract: "MRT is also= extremely computationally efficient=85computation is less than the LFA com= putation..."  As was expressed on the list, maybe CPU cycles are = not that important if compared to other aspects=85
    • Introduction: &q= uot;Other existing or proposed solutions are partial solutions or have = ;significant issues, as described below."  It is ok to describe o= ther solutions, but please limit the description to the facts.
    • About the = table: there are obviously other columns that could have been included, whi= ch means that the table is not complete.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [C= B]  The abstract and introduction have been significantly revised to t= ry to remove value statements.  I modified the comparison table and ad= ded several columns, trying to provide a factual comparison of tradeoffs based on different metrics without making value ju= dgements.   (See the revised document or main diff above.)  = However, I am also willing to simply remove the table and descriptions, if = that makes more sense.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    I am not crazy about the table.   The added columns make it a lit= tle better, but even if there are no judgements people will read into it.. =  

    I think Stewart had commented on it as well =97 I would like to see hi= s opinion as well.

    =85
    1. Operations= /Management Considerations
    • Given that the MRT paths do= n't follow the shortest paths, or even potentially planned backup paths in = the network, I think you should include something about the potential impac= t related to capacity planning, congestion, stretch, etc.
    • What abo= ut address management?  Are there considerations about assignment and = management for the additional loopbacks required for IP tunnels?
    • Section 15. (Applying Policy= to Select from Multiple Possible Alternates for FRR) basically says that p= olicy can be applied "to select the best alternate from those provided= by MRT and other FRR technologies".  You're right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses= many of the potential criteria that one might take into account when = evaluating different alternates for selection".  What are th= e considerations that should be taken into account when comparing between MRT and others?  Are the criteria and requirements outlined i= n I-D.ietf-rtgwg-lfa-manageability applicable?  Even though = I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-specific, should it&= nbsp;be a Normative reference? [Note that there's a similar comment related to  I-D.ietf-rtgwg-lfa-manageability in my revie= w of draft-ietf-rtgwg-mrt-frr-algorithm.]
    • Applicability/Guida= nce for Operators
    • Section 4. (Maximally = Redundant Trees (MRT)) clearly explains about the impact of not having a 2-= connected network for MRT to be applicable.  Section 11.3. (MRT A= lternates for Destinations Outside the MRT Island) talks about partial implementation in an area.  
      • I think it w= ould be important to consolidate some of that guidance (there's probably mo= re) in a single place.  Note that I'm not looking for a 30 page e= xtension (a la RFC6571), just some general guidance.
    • Given that both Sections 14= and 15 were added just in the latest version of the document, please consi= der taking a look at RFC5706.
    • [Nit] Consider making Section 15= . (Applying Policy to Select from Multiple Possible Alternates for FRR) a s= ub-section of Section 14. (Operations and Management Considerations).<= /font>
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [C= B] These changes are shown in this diff:

    After those changes it looks like the reference to I-D.ietf-rtgwg= -lfa-manageability is no longer needed.

    =85
    =    We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algor= ithm]

    Just taking advantage of this text to say that you may want to edit aw= ay the use of "we" in the text.  "We" who?  M= ost of the statements may be clearer in the third person.  Just a styl= e nit..
    --_000_D2BD4A66100DB9aretanaciscocom_-- From nobody Thu Jan 14 14:16:35 2016 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA841A00E5; Thu, 14 Jan 2016 14:16:34 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160114221634.5352.75758.idtracker@ietfa.amsl.com> Date: Thu, 14 Jan 2016 14:16:34 -0800 Archived-At: Cc: draft-ietf-rtgwg-mrt-frr-architecture@ietf.org, rtgwg@ietf.org, rtgwg-chairs@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 22:16:34 -0000 The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-01-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the architecture for IP/LDP Fast-Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1801/ https://datatracker.ietf.org/ipr/1594/ https://datatracker.ietf.org/ipr/1733/ From nobody Thu Jan 14 14:42:16 2016 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E56011A0149; Thu, 14 Jan 2016 14:42:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (An Algorithm for Computing Maximally Redundant Trees for IP/LDP Fast-Reroute) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160114224214.12421.79779.idtracker@ietfa.amsl.com> Date: Thu, 14 Jan 2016 14:42:14 -0800 Archived-At: Cc: rtgwg-chairs@ietf.org, draft-ietf-rtgwg-mrt-frr-algorithm@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 22:42:15 -0000 The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'An Algorithm for Computing Maximally Redundant Trees for IP/LDP Fast- Reroute' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-01-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A solution for IP and LDP Fast-Reroute using Maximally Redundant Trees is presented in draft-ietf-rtgwg-mrt-frr-architecture. This document defines the associated MRT Lowpoint algorithm that is used in the Default MRT profile to compute both the necessary Maximally Redundant Trees with their associated next-hops and the alternates to select for MRT-FRR. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-algorithm/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-algorithm/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Jan 17 02:05:00 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4787E1B2F2B; Sun, 17 Jan 2016 02:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mj4YdYAWHpv; Sun, 17 Jan 2016 02:04:54 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0093.outbound.protection.outlook.com [104.47.1.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5641B2F2C; Sun, 17 Jan 2016 02:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R+UkqflSEq3M4WCtFr8diFe2eQUxNl21uv8nhQWRXHU=; b=Iv5Is3YbVkC2yw5awIpMrBoZS0tTuOfbOiGn9IBEEme0MIviB2QJgFEC8J6OdoG+dRSmWHAsk0+EI7CBLQgwIRc5XbWQ7Yyec94DTgSSRb8iTliZC1l4lVcH2pusI8hsewZElo/Ypjjk6bGAitbPUF9PaLm2Xz4LgbOKekxTGsA= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sun, 17 Jan 2016 10:04:49 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0365.023; Sun, 17 Jan 2016 10:04:49 +0000 From: Alexander Vainshtein To: "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACABaF0QA== Date: Sun, 17 Jan 2016 10:04:49 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:/mPBV0hzEUSwIS8CkX+j2l3LSNpLbOl1GbA+exRqdfsjgJSF0zFtxH0kHx6Ae7hhDr+yJTR1SQFJpHRo8B1hgdZnG58Kz4ih929p2H4R7QNq+E1S+mRfbCTG8uX4haw4m5vCKli+B8cuxQ/yqvD0Yg==; 24:NgrjrHk38C5ENJrQT5rkfeasAAALPsBn3/V0nAnfpRXtD9RCOoyTkRVhCVOqqm6Yf3FVks+EH4+9BhzGtMfmNXHJ9+O44MFQfYF100fM/HA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; x-ms-office365-filtering-correlation-id: 60f2bd5a-4012-498b-ae51-08d31f25a302 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 082465FB26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(164054003)(53754006)(252514010)(479174004)(377424004)(199003)(189002)(377454003)(19580395003)(15975445007)(74316001)(4001150100001)(5001960100002)(6116002)(105586002)(4326007)(11100500001)(586003)(106116001)(101416001)(106356001)(2900100001)(5008740100001)(1720100001)(2950100001)(102836003)(19580405001)(5004730100002)(3846002)(54356999)(76176999)(87936001)(50986999)(66066001)(5003600100002)(5002640100001)(230783001)(1096002)(76576001)(1220700001)(33656002)(5001770100001)(97736004)(81156007)(92566002)(77096005)(10710500007)(10400500002)(2420400006)(2201001)(189998001)(122556002)(86362001)(2906002)(7110500001)(40100003)(2501003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2016 10:04:49.5829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: "jhaas@juniper.net" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 10:04:57 -0000 Hi all, I have read the draft and I have one (presumably, minor) comment: - The IANA Considerations section of says that there are no IANA request. - At the same time the draft defines a new type of VRRP messages (2 - Backu= p Advertisement). As long as here was just one type of VRRP messages (1 - Advertisement), we = could avoid setting up a IANA registry for VRRP message types. If we are go= ing to have two, does not this justify setting up such a registry? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nitish Gupta (= nitisgup) Sent: Wednesday, January 13, 2016 11:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: jhaas@juniper.net; colin@doch.org.uk; Aditya Dogra (addogra) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93=20 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the=20 >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org"=20 > >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been=20 >>successfully submitted by Nitish Gupta and posted to the IETF=20 >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>The IETF Secretariat >> > From nobody Sun Jan 17 20:10:40 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015971AD09C; Sun, 17 Jan 2016 20:10:39 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe4j9vOYn6XY; Sun, 17 Jan 2016 20:10:37 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7991AD09A; Sun, 17 Jan 2016 20:10:37 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id ho8so166084734pac.2; Sun, 17 Jan 2016 20:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=l8kE3X6k3znlLuMJvuH2hZe+k0vr/aSWYRvsVlAAYoo=; b=SrJEA4El9yc7tpj71a+RL1uh2EPN1edi7ln/YVc0vgtUPZMCv0rohdqEsXBfrIzg4Z Uv1eCLwqDqYdVU+gmHt8PZQ3DiPdvOrNT/NSGTL0WUg+LnUGTFanSfRurc12cEnHoF6q NlgCGTa9/FjsiYeJcOUAlCLFiudkIZXyB/AGPB/zIHvqleYe/52KOquEPbJvKwlZqevJ LJ1cz0qZhw+C56NTGUHFKXyFiSByKswJpDoLGKVP4hvs0PgICRr8FuyIcM4RV5YviIuL 72mdg7qJGmOqKk5v6DLG4dzI4hc2DV7gKZAOb67tJ5BmaGwBLAbi9b8KowNDfrUDelZ2 Ew/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=l8kE3X6k3znlLuMJvuH2hZe+k0vr/aSWYRvsVlAAYoo=; b=MejfCRkCDPDddHRAog1N+Cdboi4tag7BTN2gkdjWHy4De3hTh2wfMrcanOePUmqEa4 aeawP4g/41/U3VFtOCr/+SU63SNzwksGFB5RfTR+0bSWWqi4yixheRd5SjL+GnDXd8Cd rjgVDvf8COvzxmYoW+gBVQmMNuaQvq24RwJkBUMLu3L/8Y4jK8zcplB5SK8qQWd6zUE1 TJ3UXGdr45nznUyO+uasfaQv9v+QmT/sDC67LNkz0XEDaAyzvsxBQ+NfOx+ciNdIeEsA BOiFKVxMjjV0Wrm3ulYBMIWBtYYqNv/9JHhQn3OYtCP/xPvg0Z1swF61KsHe3t2yyps6 XcBA== X-Gm-Message-State: ALoCoQmsnhrBNImcMZiW3Rrd3u3GFtK8aMpkA5soIjZfTB3LYDfdvrPq4Hh/N4YxFLWrwlzYQy8dplrwaDHyGclcqaXR7vKErQ== X-Received: by 10.66.219.38 with SMTP id pl6mr33607384pac.147.1453090236719; Sun, 17 Jan 2016 20:10:36 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1003::227? ([2001:420:c0c8:1003::227]) by smtp.gmail.com with ESMTPSA id l73sm30049479pfi.37.2016.01.17.20.10.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Jan 2016 20:10:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt From: Mahesh Jethanandani In-Reply-To: Date: Sun, 17 Jan 2016 20:10:31 -0800 Message-Id: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> To: "Nitish Gupta (nitisgup)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "jhaas@juniper.net" , "rtg-bfd@ietf.org" , "Aditya Dogra \(addogra\)" , "colin@doch.org.uk" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 04:10:39 -0000 --Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or something = like that to follow the naming convention described in RFC 7221? > On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) = wrote: >=20 > Hi, >=20 > We have submitted a new version of the draft. As discussed in IETF 93 = at > prague. >=20 > We have merged the following drafts: > http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >=20 > https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >=20 >=20 >=20 > We have also taken care of all the comments that were discussed in the > RTGWG meeting. > We welcome any comments and suggestions on the draft. >=20 > Thanks, > Nitish >=20 > On 13/10/15 9:09 pm, "internet-drafts@ietf.org" = > wrote: >=20 >>=20 >> A new version of I-D, draft-nitish-vrrp-bfd-02.txt >> has been successfully submitted by Nitish Gupta and posted to the >> IETF repository. >>=20 >> Name: draft-nitish-vrrp-bfd >> Revision: 02 >> Title: Fast failure detection in VRRP with BFD >> Document date: 2015-10-13 >> Group: Individual Submission >> Pages: 10 >> URL: =20 >> https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >> Status: = https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >> Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >>=20 >> Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or = something like that to follow the naming convention described in RFC = 7221?

    On Oct 25, 2015, at 11:27 PM, Nitish Gupta = (nitisgup) <nitisgup@cisco.com> wrote:

    Hi,

    We have submitted a new version of the draft. As discussed in = IETF 93 at
    prague.

    We have = merged the following drafts:
    http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case= -00



    We have = also taken care of all the comments that were discussed in the
    RTGWG meeting.
    We welcome any comments and = suggestions on the draft.

    Thanks,
    Nitish

    On 13/10/15 9:09 pm, = "internet-drafts@ietf.org" <internet-drafts@ietf.org>
    wrote:


    A new version of I-D, = draft-nitish-vrrp-bfd-02.txt
    has been successfully = submitted by Nitish Gupta and posted to the
    IETF = repository.

    Name: = draft-nitish-vrrp-bfd
    Revision: 02
    Title:= = Fast failure detection in VRRP with BFD
    Document = date: = 2015-10-13
    Group: Individual Submission
    Pages:= = 10
    URL: =            
    https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.t= xt
    Status: =         https://datatracker.ietf.o= rg/doc/draft-nitish-vrrp-bfd/
    Htmlized: =       https://tools.ietf.org/html/draft-niti= sh-vrrp-bfd-02
    Diff: =           https://www.ie= tf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

    Abstract:
     This document describes how = Bidirectional Forwarding Detection (BFD)
     can be = used to support sub-second detection of a Master Router
    =  failure in the Virtual Router Redundancy Protocol (VRRP).




    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



    Mahesh Jethanandani
    mjethanandani@gmail.com





    = --Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A-- From nobody Mon Jan 18 10:38:51 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1945F1B3B71; Mon, 18 Jan 2016 10:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IBGFDngy5zk; Mon, 18 Jan 2016 10:38:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.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 EC1001B3B73; Mon, 18 Jan 2016 10:38:45 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by BLUPR0501MB1809.namprd05.prod.outlook.com (10.163.121.144) with Microsoft SMTP Server (TLS) id 15.1.365.19; Mon, 18 Jan 2016 18:38:41 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0361.006; Mon, 18 Jan 2016 18:38:41 +0000 From: Chris Bowers To: Mahesh Jethanandani , "Nitish Gupta (nitisgup)" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgIMthoCAAOOy8A== Date: Mon, 18 Jan 2016 18:38:40 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1809; 5:RLPdjFPIUWnF4AVk6C7Qyj9GthdbSb4O8C5s1WAkYjV0VAk4PRymTrD1AbUus2KFcu9/JESjtwiS5YT97VZw7+Ero2UYYNd71JDhy5NH4F5rEslbuWbkIrFQQ+RmAijBWw7Z/HaKBprH0pn6X2R8ug==; 24:grt4AI3uMjUcgwHaLjz6F9O0XYWSluJDMuq6QWJYvUCOUoQOPrNK6BAQG3vi62S9DN6XmOU+HfjIX3qrOEO0qFjc/JdsjZzYLyR1A07dN18= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1809; x-ms-office365-filtering-correlation-id: d5222864-002e-447c-ca3d-08d32036967c x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BLUPR0501MB1809; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1809; x-forefront-prvs: 08252193F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(189002)(199003)(377454003)(479174004)(377424004)(24454002)(230783001)(19609705001)(1220700001)(5002640100001)(2950100001)(586003)(790700001)(97736004)(122556002)(5001770100001)(101416001)(81156007)(1096002)(10710500007)(102836003)(11100500001)(76576001)(4001150100001)(3846002)(4326007)(76176999)(5008740100001)(66066001)(19617315012)(5001960100002)(86362001)(19580395003)(10400500002)(2900100001)(33656002)(2420400006)(54356999)(50986999)(6116002)(92566002)(105586002)(77096005)(7110500001)(19580405001)(87936001)(99286002)(5004730100002)(15975445007)(19300405004)(2906002)(16236675004)(40100003)(106356001)(74316001)(5003600100002)(189998001)(19625215002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1809; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2016 18:38:40.9455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1809 Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "Aditya Dogra \(addogra\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 18:38:49 -0000 --_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFoZXNoLA0KDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3JzIGV2ZW50dWFsbHkgd2Fu dCB0aGlzIGRyYWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiAgVGhpcyBtYWtlcyBzZW5z ZSBiZWNhdXNlIGl0IGluY2x1ZGVzIFZSUlAgcHJvdG9jb2wgZXh0ZW5zaW9ucywgc28gaXQgd291 bGQgbm9ybWFsbHkgZ28gdG8gdGhlIFZSUlAgV0cuICAgU2luY2UgdGhlIFZSUlAgV0cgaXMgY29u Y2x1ZGVkLCB0aGUgUlRHV0cgaXMgYSByZWFzb25hYmxlIHBsYWNlIHRvIGRvIHRoaXMgd29yay4N Cg0KT25lIG1pZ2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBCRkQgV0cg dG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2YgQkZEIGV4cGVydGlzZSB0 aGVyZS4gIEhvd2V2ZXIsIHNpbmNlIHRoZSBtYWluIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50IGRl YWxzIHdpdGggVlJSUCBiZWhhdmlvciBhbmQgZGVmaW5pbmcgYSBuZXcgVlJSUCBwYWNrZXQgdHlw ZSwgaXQgc2VlbXMgbGlrZSBpdCBtaWdodCBiZSBhIGRpdmVyc2lvbiBmcm9tIHRoZSBtYWluIHdv cmsgb2YgdGhlIEJGRCBXRy4NCg0KSWYgdGhlIFJUR1dHIGRvZXMgYWRvcHQgdGhlIGRyYWZ0LCB0 aGUgbmFtZSBvZiB0aGUgYWRvcHRlZCBkcmFmdCBzaG91bGQgc3RhcnQgd2l0aCBkcmFmdC1pZXRm LXJ0Z3dnIChhcyB5b3UgcG9pbnQgb3V0LCBmb2xsb3dpbmcgUkZDNzIyMSkuDQoNCkFzIGFuIGlu ZGl2aWR1YWwgc3VibWlzc2lvbiBhdCB0aGlzIHBvaW50LCB0aGVyZSBhcmUgbm8gaGFyZCByZXF1 aXJlbWVudHMgb24gdGhlIG5hbWUgb2YgdGhlIGRyYWZ0LCBleGNlcHQgdGhhdCBpdCBub3Qgc3Rh cnQgd2l0aCBkcmFmdC1pZXRmLiAgSG93ZXZlciwgd2hlbiBhdXRob3JzIGFyZSBzdWJtaXR0aW5n IGRyYWZ0cyB0aGF0IHRoZXkgaW50ZW5kIHRvIGV2ZW50dWFsbHkgYmUgY29uc2lkZXJlZCBmb3Ig YWRvcHRpb24gYnkgdGhlIFJUR1dHLCBpdCBpcyBxdWl0ZSB1c2VmdWwgdG8gbmFtZSB0aGVtIGRy YWZ0LWF1dGhvcm5hbWUtcnRnd2cteXl5eSwgc28gdGhhdCB0aGV5IGF1dG9tYXRpY2FsbHkgc2hv dyB1cCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3J0Z3dnL2RvY3VtZW50cy8g YXQgdGhlIGJvdHRvbSB1bmRlciB0aGUgaGVhZGVyIG9mIOKAnFJlbGF0ZWQgSW50ZXJuZXQtRHJh ZnRz4oCdLg0KDQpUaGFua3MsDQpDaHJpcw0KDQpGcm9tOiBydGd3ZyBbbWFpbHRvOnJ0Z3dnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpTZW50OiBT dW5kYXksIEphbnVhcnkgMTcsIDIwMTYgMTA6MTEgUE0NClRvOiBOaXRpc2ggR3VwdGEgKG5pdGlz Z3VwKSA8bml0aXNndXBAY2lzY28uY29tPg0KQ2M6IEplZmYgSGFhcyA8amhhYXNAanVuaXBlci5u ZXQ+OyBydGctYmZkQGlldGYub3JnOyBBZGl0eWEgRG9ncmEgKGFkZG9ncmEpIDxhZGRvZ3JhQGNp c2NvLmNvbT47IGNvbGluQGRvY2gub3JnLnVrOyBydGd3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4 dA0KDQpTaG91bGRu4oCZdCB0aGUgZHJhZnQgYmUgbmFtZWQgZHJhZnQtbml0aXNoLWJmZC12cnJw IG9yIHNvbWV0aGluZyBsaWtlIHRoYXQgdG8gZm9sbG93IHRoZSBuYW1pbmcgY29udmVudGlvbiBk ZXNjcmliZWQgaW4gUkZDIDcyMjE/DQoNCk9uIE9jdCAyNSwgMjAxNSwgYXQgMTE6MjcgUE0sIE5p dGlzaCBHdXB0YSAobml0aXNndXApIDxuaXRpc2d1cEBjaXNjby5jb208bWFpbHRvOm5pdGlzZ3Vw QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVy c2lvbiBvZiB0aGUgZHJhZnQuIEFzIGRpc2N1c3NlZCBpbiBJRVRGIDkzIGF0DQpwcmFndWUuDQoN CldlIGhhdmUgbWVyZ2VkIHRoZSBmb2xsb3dpbmcgZHJhZnRzOg0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAxDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0wMA0KDQoNCg0KV2Ug aGF2ZSBhbHNvIHRha2VuIGNhcmUgb2YgYWxsIHRoZSBjb21tZW50cyB0aGF0IHdlcmUgZGlzY3Vz c2VkIGluIHRoZQ0KUlRHV0cgbWVldGluZy4NCldlIHdlbGNvbWUgYW55IGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBvbiB0aGUgZHJhZnQuDQoNClRoYW5rcywNCk5pdGlzaA0KDQpPbiAxMy8xMC8x NSA5OjA5IHBtLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+Pg0Kd3JvdGU6DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBOaXRpc2ggR3VwdGEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogICAgICAgICAgICAgIGRyYWZ0LW5pdGlzaC12cnJwLWJmZA0KUmV2aXNpb246ICAgICAg ICAgMDINClRpdGxlOiAgICAgICAgICAgICAgICBGYXN0IGZhaWx1cmUgZGV0ZWN0aW9uIGluIFZS UlAgd2l0aCBCRkQNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgIDIwMTUtMTAtMTMNCkdyb3VwOiAg ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAgICAgMTAN ClVSTDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXRpc2gt dnJycC1iZmQtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbml0aXNoLXZycnAtYmZkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDINCkRpZmY6ICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbml0aXNoLXZycnAt YmZkLTAyDQoNCkFic3RyYWN0Og0KIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBCaWRpcmVj dGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpDQogY2FuIGJlIHVzZWQgdG8gc3VwcG9y dCBzdWItc2Vjb25kIGRldGVjdGlvbiBvZiBhIE1hc3RlciBSb3V0ZXINCiBmYWlsdXJlIGluIHRo ZSBWaXJ0dWFsIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKS4NCg0KDQoNCg0KDQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg== --_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFu DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5NYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5BcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3JzIGV2ZW50dWFsbHkgd2FudCB0 aGlzIGRyYWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiZuYnNwOyBUaGlzIG1ha2VzIHNl bnNlIGJlY2F1c2UgaXQgaW5jbHVkZXMgVlJSUCBwcm90b2NvbCBleHRlbnNpb25zLCBzbyBpdCB3 b3VsZA0KIG5vcm1hbGx5IGdvIHRvIHRoZSBWUlJQIFdHLiAmbmJzcDsmbmJzcDtTaW5jZSB0aGUg VlJSUCBXRyBpcyBjb25jbHVkZWQsIHRoZSBSVEdXRyBpcyBhIHJlYXNvbmFibGUgcGxhY2UgdG8g ZG8gdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ T25lIG1pZ2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBCRkQgV0cgdG8g dGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2YgQkZEIGV4cGVydGlzZSB0aGVy ZS4mbmJzcDsgSG93ZXZlciwgc2luY2UgdGhlIG1haW4gY29udGVudCBvZiB0aGUgZG9jdW1lbnQN CiBkZWFscyB3aXRoIFZSUlAgYmVoYXZpb3IgYW5kIGRlZmluaW5nIGEgbmV3IFZSUlAgcGFja2V0 IHR5cGUsIGl0IHNlZW1zIGxpa2UgaXQgbWlnaHQgYmUgYSBkaXZlcnNpb24gZnJvbSB0aGUgbWFp biB3b3JrIG9mIHRoZSBCRkQgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JZiB0aGUgUlRHV0cgZG9lcyBhZG9wdCB0aGUgZHJhZnQsIHRoZSBuYW1lIG9mIHRo ZSBhZG9wdGVkIGRyYWZ0IHNob3VsZCBzdGFydCB3aXRoIGRyYWZ0LWlldGYtcnRnd2cgKGFzIHlv dSBwb2ludCBvdXQsIGZvbGxvd2luZyBSRkM3MjIxKS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGF0 IHRoaXMgcG9pbnQsIHRoZXJlIGFyZSBubyBoYXJkIHJlcXVpcmVtZW50cyBvbiB0aGUgbmFtZSBv ZiB0aGUgZHJhZnQsIGV4Y2VwdCB0aGF0IGl0IG5vdCBzdGFydCB3aXRoIGRyYWZ0LWlldGYuJm5i c3A7IEhvd2V2ZXIsIHdoZW4gYXV0aG9ycw0KIGFyZSBzdWJtaXR0aW5nIGRyYWZ0cyB0aGF0IHRo ZXkgaW50ZW5kIHRvIGV2ZW50dWFsbHkgYmUgY29uc2lkZXJlZCBmb3IgYWRvcHRpb24gYnkgdGhl IFJUR1dHLCBpdCBpcyBxdWl0ZSB1c2VmdWwgdG8gbmFtZSB0aGVtIGRyYWZ0LWF1dGhvcm5hbWUt cnRnd2cteXl5eSwgc28gdGhhdCB0aGV5IGF1dG9tYXRpY2FsbHkgc2hvdyB1cCBhdA0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9ydGd3Zy9kb2N1bWVudHMvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3J0Z3dnL2RvY3VtZW50cy88L2E+IGF0IHRoZSBi b3R0b20gdW5kZXIgdGhlIGhlYWRlciBvZiDigJxSZWxhdGVkIEludGVybmV0LURyYWZ0c+KAnS4m bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gcnRnd2cgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5NYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgSmFudWFyeSAxNywgMjAxNiAxMDoxMSBQTTxicj4NCjxiPlRvOjwvYj4gTml0aXNoIEd1cHRh IChuaXRpc2d1cCkgJmx0O25pdGlzZ3VwQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEpl ZmYgSGFhcyAmbHQ7amhhYXNAanVuaXBlci5uZXQmZ3Q7OyBydGctYmZkQGlldGYub3JnOyBBZGl0 eWEgRG9ncmEgKGFkZG9ncmEpICZsdDthZGRvZ3JhQGNpc2NvLmNvbSZndDs7IGNvbGluQGRvY2gu b3JnLnVrOyBydGd3Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIudHh0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hvdWxkbuKAmXQgdGhlIGRy YWZ0IGJlIG5hbWVkIGRyYWZ0LW5pdGlzaC1iZmQtdnJycCBvciBzb21ldGhpbmcgbGlrZSB0aGF0 IHRvIGZvbGxvdyB0aGUgbmFtaW5nIGNvbnZlbnRpb24gZGVzY3JpYmVkIGluIFJGQyA3MjIxPzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAyNSwg MjAxNSwgYXQgMTE6MjcgUE0sIE5pdGlzaCBHdXB0YSAobml0aXNndXApICZsdDs8YSBocmVmPSJt YWlsdG86bml0aXNndXBAY2lzY28uY29tIj5uaXRpc2d1cEBjaXNjby5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJyPg0K V2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEFzIGRpc2N1c3Nl ZCBpbiBJRVRGIDkzIGF0PGJyPg0KcHJhZ3VlLjxicj4NCjxicj4NCldlIGhhdmUgbWVyZ2VkIHRo ZSBmb2xsb3dpbmcgZHJhZnRzOjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbml0aXNoLXZycnAtYmZkLTAxPC9hPjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0w MCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1iZmQtcDJtcC12cnJw LXVzZS1jYXNlLTAwPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCldlIGhhdmUgYWxzbyB0YWtl biBjYXJlIG9mIGFsbCB0aGUgY29tbWVudHMgdGhhdCB3ZXJlIGRpc2N1c3NlZCBpbiB0aGU8YnI+ DQpSVEdXRyBtZWV0aW5nLjxicj4NCldlIHdlbGNvbWUgYW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0 aW9ucyBvbiB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCk5pdGlzaDxicj4NCjxi cj4NCk9uIDEzLzEwLzE1IDk6MDkgcG0sICZxdW90OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0Kd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMi50eHQ8 YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE5pdGlzaCBHdXB0YSBhbmQg cG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOjxzcGFu IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5kcmFm dC1uaXRpc2gtdnJycC1iZmQ8YnI+DQpSZXZpc2lvbjo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+MDI8YnI+DQpUaXRsZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+RmFzdCBmYWlsdXJlIGRldGVjdGlvbiBpbiBW UlJQIHdpdGggQkZEPGJyPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+MjAxNS0xMC0xMzxicj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdl czo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+MTA8YnI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIudHh0Ij5odHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4 dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW5pdGlzaC12cnJwLWJmZC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW5pdGlzaC12cnJwLWJmZC88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1uaXRpc2gtdnJycC1iZmQtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1u aXRpc2gtdnJycC1iZmQtMDI8L2E+PGJyPg0KRGlmZjogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMjwvYT48YnI+ DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKTxicj4NCiZuYnNwO2NhbiBi ZSB1c2VkIHRvIHN1cHBvcnQgc3ViLXNlY29uZCBkZXRlY3Rpb24gb2YgYSBNYXN0ZXIgUm91dGVy PGJyPg0KJm5ic3A7ZmFpbHVyZSBpbiB0aGUgVmlydHVhbCBSb3V0ZXIgUmVkdW5kYW5jeSBQcm90 b2NvbCAoVlJSUCkuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8 YnI+DQpzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_-- From nobody Mon Jan 18 11:13:32 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDFC1B3C08; Mon, 18 Jan 2016 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1_6dth-mDCm; Mon, 18 Jan 2016 11:13:27 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098861B3C06; Mon, 18 Jan 2016 11:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23723; q=dns/txt; s=iport; t=1453144407; x=1454354007; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1ZVHV+RkMiwTZDNh7VaFUg1KI47+ZFvoGgxJKcpVUjQ=; b=CpijbAxNWUlpSw0cuzApu1XAYY9Fzmxp+XDRYtl09JUcgwK5lEw7TOTi E5nEEIKNhXFInxxdlQURu60RAGK0JobJvUWXa/0X6NyHYkMCeSk2rriq3 EXlo0LcBcdC1DLHOGxhj6GMs7iiFfze4J6Q7KebSR7XP8R471FOC+BhfZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQCdOJ1W/4YNJK1egm5MUm0GiFCzR?= =?us-ascii?q?QENgWMihW0CHIEbOBQBAQEBAQEBgQqENAEBAQQjCj4MAhACAQgOAwMBAQEoAwI?= =?us-ascii?q?CAh8RFAkIAgQBDQWIBgMSDq8TjDUNg0cBAQEBAQEBAQEBAQEBAQEBAQEBAQEYi?= =?us-ascii?q?1SCT4IeCg0JCIJfgUkFjUKJWAGFR4YfgXiBXkqDeohfhn+HXQERDwEBQoQLcgG?= =?us-ascii?q?GM4EIAQEB?= X-IronPort-AV: E=Sophos; i="5.22,313,1449532800"; d="scan'208,217"; a="68140074" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jan 2016 19:13:25 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u0IJDPcl003959 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jan 2016 19:13:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Jan 2016 14:13:24 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 18 Jan 2016 14:13:24 -0500 From: "Acee Lindem (acee)" To: Chris Bowers , Mahesh Jethanandani , "Nitish Gupta (nitisgup)" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRUaYrTS9LHO0Rck2198aSpBcKKZ8B72sA//+13AA= Date: Mon, 18 Jan 2016 19:13:24 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.205] Content-Type: multipart/alternative; boundary="_000_D2C2A3524A104aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 19:13:30 -0000 --_000_D2C2A3524A104aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXMsIE1haGVzaCwNCkkgYWdyZWUgd2l0aCB0aGlzIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhl IGRyYWZ0IGFuZCBiZWxpZXZlIHRoYXQsIGlmIGFkb3B0ZWQsIGl0IGJlbG9uZ3MgaW4gdGhlIFJU RyBXRy4NClRoYW5rcywNCkFjZWUNCg0KDQpGcm9tOiBydGd3ZyA8cnRnd2ctYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBDaHJpcyBC b3dlcnMgPGNib3dlcnNAanVuaXBlci5uZXQ8bWFpbHRvOmNib3dlcnNAanVuaXBlci5uZXQ+Pg0K RGF0ZTogTW9uZGF5LCBKYW51YXJ5IDE4LCAyMDE2IGF0IDE6MzggUE0NClRvOiBNYWhlc2ggSmV0 aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20+PiwgIk5pdGlzaCBHdXB0YSAobml0aXNndXApIiA8bml0aXNndXBAY2lzY28uY29t PG1haWx0bzpuaXRpc2d1cEBjaXNjby5jb20+Pg0KQ2M6IEplZmYgSGFhcyA8amhhYXNAanVuaXBl ci5uZXQ8bWFpbHRvOmpoYWFzQGp1bmlwZXIubmV0Pj4sICJjb2xpbkBkb2NoLm9yZy51azxtYWls dG86Y29saW5AZG9jaC5vcmcudWs+IiA8Y29saW5AZG9jaC5vcmcudWs8bWFpbHRvOmNvbGluQGRv Y2gub3JnLnVrPj4sICJydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPiIg PHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+PiwgIkFkaXR5YSBEb2dy YSAoYWRkb2dyYSkiIDxhZGRvZ3JhQGNpc2NvLmNvbTxtYWlsdG86YWRkb2dyYUBjaXNjby5jb20+ PiwgUm91dGluZyBXRyA8cnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPj4NClN1 YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW5pdGlzaC12cnJw LWJmZC0wMi50eHQNCg0KTWFoZXNoLA0KDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3Jz IGV2ZW50dWFsbHkgd2FudCB0aGlzIGRyYWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiAg VGhpcyBtYWtlcyBzZW5zZSBiZWNhdXNlIGl0IGluY2x1ZGVzIFZSUlAgcHJvdG9jb2wgZXh0ZW5z aW9ucywgc28gaXQgd291bGQgbm9ybWFsbHkgZ28gdG8gdGhlIFZSUlAgV0cuICAgU2luY2UgdGhl IFZSUlAgV0cgaXMgY29uY2x1ZGVkLCB0aGUgUlRHV0cgaXMgYSByZWFzb25hYmxlIHBsYWNlIHRv IGRvIHRoaXMgd29yay4NCg0KT25lIG1pZ2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3Jr IGluIHRoZSBCRkQgV0cgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2Yg QkZEIGV4cGVydGlzZSB0aGVyZS4gIEhvd2V2ZXIsIHNpbmNlIHRoZSBtYWluIGNvbnRlbnQgb2Yg dGhlIGRvY3VtZW50IGRlYWxzIHdpdGggVlJSUCBiZWhhdmlvciBhbmQgZGVmaW5pbmcgYSBuZXcg VlJSUCBwYWNrZXQgdHlwZSwgaXQgc2VlbXMgbGlrZSBpdCBtaWdodCBiZSBhIGRpdmVyc2lvbiBm cm9tIHRoZSBtYWluIHdvcmsgb2YgdGhlIEJGRCBXRy4NCg0KSWYgdGhlIFJUR1dHIGRvZXMgYWRv cHQgdGhlIGRyYWZ0LCB0aGUgbmFtZSBvZiB0aGUgYWRvcHRlZCBkcmFmdCBzaG91bGQgc3RhcnQg d2l0aCBkcmFmdC1pZXRmLXJ0Z3dnIChhcyB5b3UgcG9pbnQgb3V0LCBmb2xsb3dpbmcgUkZDNzIy MSkuDQoNCkFzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiBhdCB0aGlzIHBvaW50LCB0aGVyZSBh cmUgbm8gaGFyZCByZXF1aXJlbWVudHMgb24gdGhlIG5hbWUgb2YgdGhlIGRyYWZ0LCBleGNlcHQg dGhhdCBpdCBub3Qgc3RhcnQgd2l0aCBkcmFmdC1pZXRmLiAgSG93ZXZlciwgd2hlbiBhdXRob3Jz IGFyZSBzdWJtaXR0aW5nIGRyYWZ0cyB0aGF0IHRoZXkgaW50ZW5kIHRvIGV2ZW50dWFsbHkgYmUg Y29uc2lkZXJlZCBmb3IgYWRvcHRpb24gYnkgdGhlIFJUR1dHLCBpdCBpcyBxdWl0ZSB1c2VmdWwg dG8gbmFtZSB0aGVtIGRyYWZ0LWF1dGhvcm5hbWUtcnRnd2cteXl5eSwgc28gdGhhdCB0aGV5IGF1 dG9tYXRpY2FsbHkgc2hvdyB1cCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3J0 Z3dnL2RvY3VtZW50cy8gYXQgdGhlIGJvdHRvbSB1bmRlciB0aGUgaGVhZGVyIG9mIOKAnFJlbGF0 ZWQgSW50ZXJuZXQtRHJhZnRz4oCdLg0KDQpUaGFua3MsDQpDaHJpcw0KDQpGcm9tOiBydGd3ZyBb bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFu YW5kYW5pDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMTcsIDIwMTYgMTA6MTEgUE0NClRvOiBOaXRp c2ggR3VwdGEgKG5pdGlzZ3VwKSA8bml0aXNndXBAY2lzY28uY29tPG1haWx0bzpuaXRpc2d1cEBj aXNjby5jb20+Pg0KQ2M6IEplZmYgSGFhcyA8amhhYXNAanVuaXBlci5uZXQ8bWFpbHRvOmpoYWFz QGp1bmlwZXIubmV0Pj47IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+ OyBBZGl0eWEgRG9ncmEgKGFkZG9ncmEpIDxhZGRvZ3JhQGNpc2NvLmNvbTxtYWlsdG86YWRkb2dy YUBjaXNjby5jb20+PjsgY29saW5AZG9jaC5vcmcudWs8bWFpbHRvOmNvbGluQGRvY2gub3JnLnVr PjsgcnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dA0K DQpTaG91bGRu4oCZdCB0aGUgZHJhZnQgYmUgbmFtZWQgZHJhZnQtbml0aXNoLWJmZC12cnJwIG9y IHNvbWV0aGluZyBsaWtlIHRoYXQgdG8gZm9sbG93IHRoZSBuYW1pbmcgY29udmVudGlvbiBkZXNj cmliZWQgaW4gUkZDIDcyMjE/DQoNCk9uIE9jdCAyNSwgMjAxNSwgYXQgMTE6MjcgUE0sIE5pdGlz aCBHdXB0YSAobml0aXNndXApIDxuaXRpc2d1cEBjaXNjby5jb208bWFpbHRvOm5pdGlzZ3VwQGNp c2NvLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQuIEFzIGRpc2N1c3NlZCBpbiBJRVRGIDkzIGF0DQpwcmFndWUuDQoNCldl IGhhdmUgbWVyZ2VkIHRoZSBmb2xsb3dpbmcgZHJhZnRzOg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAxDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0wMA0KDQoNCg0KV2UgaGF2 ZSBhbHNvIHRha2VuIGNhcmUgb2YgYWxsIHRoZSBjb21tZW50cyB0aGF0IHdlcmUgZGlzY3Vzc2Vk IGluIHRoZQ0KUlRHV0cgbWVldGluZy4NCldlIHdlbGNvbWUgYW55IGNvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucyBvbiB0aGUgZHJhZnQuDQoNClRoYW5rcywNCk5pdGlzaA0KDQpPbiAxMy8xMC8xNSA5 OjA5IHBtLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+Pg0Kd3JvdGU6DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bml0aXNoLXZycnAtYmZkLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBOaXRpc2ggR3VwdGEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogICAgICAgICAgICAgIGRyYWZ0LW5pdGlzaC12cnJwLWJmZA0KUmV2aXNpb246ICAgICAgICAg MDINClRpdGxlOiAgICAgICAgICAgICAgICBGYXN0IGZhaWx1cmUgZGV0ZWN0aW9uIGluIFZSUlAg d2l0aCBCRkQNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgIDIwMTUtMTAtMTMNCkdyb3VwOiAgICAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAgICAgMTANClVS TDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXRpc2gtdnJy cC1iZmQtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbml0aXNoLXZycnAtYmZkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDINCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbml0aXNoLXZycnAtYmZk LTAyDQoNCkFic3RyYWN0Og0KIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpDQogY2FuIGJlIHVzZWQgdG8gc3VwcG9ydCBz dWItc2Vjb25kIGRldGVjdGlvbiBvZiBhIE1hc3RlciBSb3V0ZXINCiBmYWlsdXJlIGluIHRoZSBW aXJ0dWFsIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKS4NCg0KDQoNCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K DQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg== --_000_D2C2A3524A104aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <87419EF930490F41BEAB99E8CBF74C6D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5DaHJpcywgTWFo ZXNoLCZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFncmVlIHdpdGggdGhpcyBjaGFyYWN0ZXJpemF0aW9u IG9mIHRoZSBkcmFmdCBhbmQgYmVsaWV2ZSB0aGF0LCBpZiBhZG9wdGVkLCBpdCBiZWxvbmdzIGlu IHRoZSBSVEcgV0cuJm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+cnRnd2cg Jmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnIj5ydGd3Zy1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIENocmlzIEJvd2VycyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNib3dlcnNAanVuaXBlci5uZXQiPmNib3dlcnNAanVuaXBlci5uZXQ8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBK YW51YXJ5IDE4LCAyMDE2IGF0IDE6MzggUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+VG86IDwvc3Bhbj5NYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDss ICZxdW90O05pdGlzaCBHdXB0YSAobml0aXNndXApJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 bml0aXNndXBAY2lzY28uY29tIj5uaXRpc2d1cEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkplZmYgSGFhcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpoYWFzQGp1bmlwZXIubmV0Ij5qaGFhc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86Y29saW5AZG9jaC5vcmcudWsiPmNvbGluQGRvY2gub3JnLnVr PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvbGluQGRvY2gub3JnLnVrIj5jb2xpbkBk b2NoLm9yZy51azwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9y ZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1i ZmRAaWV0Zi5vcmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7QWRpdHlhIERvZ3Jh IChhZGRvZ3JhKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZG9ncmFAY2lzY28uY29tIj5h ZGRvZ3JhQGNpc2NvLmNvbTwvYT4mZ3Q7LCBSb3V0aW5nIFdHICZsdDs8YSBocmVmPSJtYWlsdG86 cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMi50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAw IDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5l cmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWIt c3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5NYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5BcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3JzIGV2ZW50dWFsbHkgd2FudCB0aGlzIGRy YWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiZuYnNwOyBUaGlzIG1ha2VzIHNlbnNlIGJl Y2F1c2UgaXQgaW5jbHVkZXMgVlJSUCBwcm90b2NvbCBleHRlbnNpb25zLCBzbyBpdCB3b3VsZA0K IG5vcm1hbGx5IGdvIHRvIHRoZSBWUlJQIFdHLiAmbmJzcDsmbmJzcDtTaW5jZSB0aGUgVlJSUCBX RyBpcyBjb25jbHVkZWQsIHRoZSBSVEdXRyBpcyBhIHJlYXNvbmFibGUgcGxhY2UgdG8gZG8gdGhp cyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T25lIG1p Z2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBCRkQgV0cgdG8gdGFrZSBh ZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2YgQkZEIGV4cGVydGlzZSB0aGVyZS4mbmJz cDsgSG93ZXZlciwgc2luY2UgdGhlIG1haW4gY29udGVudCBvZiB0aGUgZG9jdW1lbnQNCiBkZWFs cyB3aXRoIFZSUlAgYmVoYXZpb3IgYW5kIGRlZmluaW5nIGEgbmV3IFZSUlAgcGFja2V0IHR5cGUs IGl0IHNlZW1zIGxpa2UgaXQgbWlnaHQgYmUgYSBkaXZlcnNpb24gZnJvbSB0aGUgbWFpbiB3b3Jr IG9mIHRoZSBCRkQgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JZiB0aGUgUlRHV0cgZG9lcyBhZG9wdCB0aGUgZHJhZnQsIHRoZSBuYW1lIG9mIHRoZSBhZG9w dGVkIGRyYWZ0IHNob3VsZCBzdGFydCB3aXRoIGRyYWZ0LWlldGYtcnRnd2cgKGFzIHlvdSBwb2lu dCBvdXQsIGZvbGxvd2luZyBSRkM3MjIxKS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGF0IHRoaXMg cG9pbnQsIHRoZXJlIGFyZSBubyBoYXJkIHJlcXVpcmVtZW50cyBvbiB0aGUgbmFtZSBvZiB0aGUg ZHJhZnQsIGV4Y2VwdCB0aGF0IGl0IG5vdCBzdGFydCB3aXRoIGRyYWZ0LWlldGYuJm5ic3A7IEhv d2V2ZXIsIHdoZW4gYXV0aG9ycw0KIGFyZSBzdWJtaXR0aW5nIGRyYWZ0cyB0aGF0IHRoZXkgaW50 ZW5kIHRvIGV2ZW50dWFsbHkgYmUgY29uc2lkZXJlZCBmb3IgYWRvcHRpb24gYnkgdGhlIFJUR1dH LCBpdCBpcyBxdWl0ZSB1c2VmdWwgdG8gbmFtZSB0aGVtIGRyYWZ0LWF1dGhvcm5hbWUtcnRnd2ct eXl5eSwgc28gdGhhdCB0aGV5IGF1dG9tYXRpY2FsbHkgc2hvdyB1cCBhdA0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9ydGd3Zy9kb2N1bWVudHMvIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL3dnL3J0Z3dnL2RvY3VtZW50cy88L2E+IGF0IHRoZSBib3R0b20g dW5kZXIgdGhlIGhlYWRlciBvZiDigJxSZWxhdGVkIEludGVybmV0LURyYWZ0c+KAnS4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5DaHJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gcnRnd2cgWzxhIGhyZWY9Im1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1haGVz aCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDE3LCAyMDE2 IDEwOjExIFBNPGJyPg0KPGI+VG86PC9iPiBOaXRpc2ggR3VwdGEgKG5pdGlzZ3VwKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5pdGlzZ3VwQGNpc2NvLmNvbSI+bml0aXNndXBAY2lzY28uY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IEplZmYgSGFhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFzQGp1 bmlwZXIubmV0Ij5qaGFhc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86cnRn LWJmZEBpZXRmLm9yZyI+DQpydGctYmZkQGlldGYub3JnPC9hPjsgQWRpdHlhIERvZ3JhIChhZGRv Z3JhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZG9ncmFAY2lzY28uY29tIj5hZGRvZ3JhQGNpc2Nv LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmNvbGluQGRvY2gub3JnLnVrIj5jb2xpbkBk b2NoLm9yZy51azwvYT47IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+DQpydGd3Z0Bp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZG7igJl0IHRoZSBkcmFmdCBiZSBuYW1l ZCBkcmFmdC1uaXRpc2gtYmZkLXZycnAgb3Igc29tZXRoaW5nIGxpa2UgdGhhdCB0byBmb2xsb3cg dGhlIG5hbWluZyBjb252ZW50aW9uIGRlc2NyaWJlZCBpbiBSRkMgNzIyMT88bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjUsIDIwMTUsIGF0IDEx OjI3IFBNLCBOaXRpc2ggR3VwdGEgKG5pdGlzZ3VwKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pdGlz Z3VwQGNpc2NvLmNvbSI+bml0aXNndXBAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCldlIGhhdmUgc3Vi bWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBBcyBkaXNjdXNzZWQgaW4gSUVURiA5 MyBhdDxicj4NCnByYWd1ZS48YnI+DQo8YnI+DQpXZSBoYXZlIG1lcmdlZCB0aGUgZm9sbG93aW5n IGRyYWZ0czo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1u aXRpc2gtdnJycC1iZmQtMDEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5pdGlz aC12cnJwLWJmZC0wMTwvYT48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWlyc2t5LWJmZC1wMm1wLXZycnAtdXNlLWNhc2UtMDAiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0w MDwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpXZSBoYXZlIGFsc28gdGFrZW4gY2FyZSBvZiBh bGwgdGhlIGNvbW1lbnRzIHRoYXQgd2VyZSBkaXNjdXNzZWQgaW4gdGhlPGJyPg0KUlRHV0cgbWVl dGluZy48YnI+DQpXZSB3ZWxjb21lIGFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgb24gdGhl IGRyYWZ0Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpOaXRpc2g8YnI+DQo8YnI+DQpPbiAxMy8x MC8xNSA5OjA5IHBtLCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCndyb3RlOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIudHh0PGJyPg0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOaXRpc2ggR3VwdGEgYW5kIHBvc3RlZCB0byB0 aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTo8c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ZHJhZnQtbml0aXNoLXZy cnAtYmZkPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjAyPGJyPg0K VGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPkZhc3QgZmFpbHVyZSBkZXRlY3Rpb24gaW4gVlJSUCB3aXRoIEJG RDxicj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjIw MTUtMTAtMTM8YnI+DQpHcm91cDo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjEwPGJyPg0K VVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMi50eHQ8L2E+PGJyPg0K U3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1uaXRpc2gtdnJy cC1iZmQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1uaXRpc2gtdnJy cC1iZmQvPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbml0aXNoLXZy cnAtYmZkLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbml0aXNoLXZycnAt YmZkLTAyPC9hPjxicj4NCkRpZmY6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDI8L2E+PGJyPg0KPGJyPg0KQWJz dHJhY3Q6PGJyPg0KJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IEJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCk8YnI+DQombmJzcDtjYW4gYmUgdXNlZCB0byBz dXBwb3J0IHN1Yi1zZWNvbmQgZGV0ZWN0aW9uIG9mIGEgTWFzdGVyIFJvdXRlcjxicj4NCiZuYnNw O2ZhaWx1cmUgaW4gdGhlIFZpcnR1YWwgUm91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wgKFZSUlAp Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mPGJyPg0Kc3VibWlz c2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWFoZXNo IEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_D2C2A3524A104aceeciscocom_-- From nobody Mon Jan 18 22:14:02 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FDF1AC3B1; Mon, 18 Jan 2016 22:13:59 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZQrGYxoIjc7; Mon, 18 Jan 2016 22:13:57 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 0E9D71AC3B7; Mon, 18 Jan 2016 22:13:57 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id 65so169727116pff.2; Mon, 18 Jan 2016 22:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=25aOxGMsyUoQrdgb/HJ+Rjl1YGaoeMXOP3mSDyAOc+Q=; b=kdybrUp6RhQV6iira1dbXI9sTFlbSb3p4fAzRwk+mLXV/XfqgmZt+mfNnsLzjcqDs1 /vFmijCPGrAkM6GBMrqvFshsiCz/oAwx7D8FsATFGPrGP0ExQrJTN8T1FEq0z10fMRXz hGzLCDpsLqGfdSrKAPfhAIqtnkoXMEeMkQRD9Ww0Siof5X1nX6ZDpLU3cPN0eqFnuoAC yHT919J8OHm1coKHOVf6bIWrttmPo34krW4OB1DaxcVylf3Ri+4rxcwizr//RDsOmSkL 4gVbgsFSngpiOlH74jMis0nnZUtydFw5Mu2pvIGXbCG9Vf5kV9da7be92KzQFsdVdXhB xMrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=25aOxGMsyUoQrdgb/HJ+Rjl1YGaoeMXOP3mSDyAOc+Q=; b=mFCMEp4j+IdbqeD/QQEte9+rUn2uaDdyAI9CVOytyimgoHNx75Eo/dkQIbuXlMv/ze 00HGftP2YuTu+Enzw6gKUruqW9ywm7FFlFERbDGsJ/x2YIpPauXIdzqoWYhPsJFftXK3 IEJeaCrMTaQ1u4ytb6Gwh4UWNYkDCQR0BivG92mHhkeH7kMRjEtuhfzfKUkeo0X2n8sD Sg98Sj7CkBmvypJ43vZHDT16qdRFlGzTetfp5VOV2wpjTWbQ5obXDULlTxcCNRwaHn+K OQF2F6FpCv5LC4F1zJMo0JsWzWUiaSeXxhMSnKGTJoIjtkzos24gyVZ4bkKRTFGZLqwF xD7w== X-Gm-Message-State: ALoCoQkUCdNejUFtoHavf9sRz4wGml5BS/QgqkG1Pm8um5kgphzvVn7rfzS3rjcBbDaJFAl3i5WcE4L065qA0EP03k0S6hA6hA== X-Received: by 10.98.68.199 with SMTP id m68mr41763029pfi.6.1453184036686; Mon, 18 Jan 2016 22:13:56 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1004::254? ([2001:420:c0c8:1004::254]) by smtp.gmail.com with ESMTPSA id cl3sm38476044pad.11.2016.01.18.22.13.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Jan 2016 22:13:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt From: Mahesh Jethanandani In-Reply-To: Date: Mon, 18 Jan 2016 22:13:49 -0800 Message-Id: <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> To: Chris Bowers X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Nitish Gupta \(nitisgup\)" , Jeff Haas , "Aditya Dogra \(addogra\)" , "rtg-bfd@ietf.org" , "colin@doch.org.uk" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 06:14:00 -0000 --Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Chris, Thanks for the clarification. Please cross-post the draft to rtg-bfd (as = you have been doing) to make sure you get the BFD experts to review the = draft. One clarification and then a question in section 3 of the document. You = say that BFD requires that a session be formed by both peers. You can = very well form a one way session from the VRRP Master router to your = Backup router. When the Backup Router detects loss of 3 BFD packets, it = can declare the Master as Down and take over as the new Master router. = The question is why do you need a BFD session from the Backup router to = the Master router? The other thing I want to make sure if there is any particular = configuration requirement from a BFD YANG model perspective. I = understand that you are using the fast timer in BFD to detect next-hop = IP address liveliness check. We address that configuration in the BFD = YANG model today. However, we have not addressed the issue of p2mp BFD = configuration as yet. Depending on how that discussion proceeds we might = want to look at that also. Cheers. > On Jan 18, 2016, at 10:38 AM, Chris Bowers = wrote: >=20 > Mahesh, > =20 > As I understand it, the authors eventually want this draft to be = adopted by the RTGWG. This makes sense because it includes VRRP = protocol extensions, so it would normally go to the VRRP WG. Since the = VRRP WG is concluded, the RTGWG is a reasonable place to do this work. > =20 > One might also consider doing this work in the BFD WG to take = advantage of the concentration of BFD expertise there. However, since = the main content of the document deals with VRRP behavior and defining a = new VRRP packet type, it seems like it might be a diversion from the = main work of the BFD WG. > =20 > If the RTGWG does adopt the draft, the name of the adopted draft = should start with draft-ietf-rtgwg (as you point out, following = RFC7221).=20 > =20 > As an individual submission at this point, there are no hard = requirements on the name of the draft, except that it not start with = draft-ietf. However, when authors are submitting drafts that they = intend to eventually be considered for adoption by the RTGWG, it is = quite useful to name them draft-authorname-rtgwg-yyyy, so that they = automatically show up athttps://datatracker.ietf.org/wg/rtgwg/documents/ = at the bottom under = the header of =E2=80=9CRelated Internet-Drafts=E2=80=9D.=20 > =20 > Thanks, > Chris > =20 > From: rtgwg [mailto:rtgwg-bounces@ietf.org = ] On Behalf Of Mahesh Jethanandani > Sent: Sunday, January 17, 2016 10:11 PM > To: Nitish Gupta (nitisgup) > > Cc: Jeff Haas >; = rtg-bfd@ietf.org ; Aditya Dogra (addogra) = >; colin@doch.org.uk = ; rtgwg@ietf.org > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt > =20 > Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or = something like that to follow the naming convention described in RFC = 7221? > =20 > On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) = > wrote: > =20 > Hi, >=20 > We have submitted a new version of the draft. As discussed in IETF 93 = at > prague. >=20 > We have merged the following drafts: > http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 = >=20 > https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 = >=20 >=20 >=20 > We have also taken care of all the comments that were discussed in the > RTGWG meeting. > We welcome any comments and suggestions on the draft. >=20 > Thanks, > Nitish >=20 > On 13/10/15 9:09 pm, "internet-drafts@ietf.org = " > > wrote: >=20 >=20 >=20 > A new version of I-D, draft-nitish-vrrp-bfd-02.txt > has been successfully submitted by Nitish Gupta and posted to the > IETF repository. >=20 > Name: draft-nitish-vrrp-bfd > Revision: 02 > Title: Fast failure detection in VRRP with BFD > Document date: 2015-10-13 > Group: Individual Submission > Pages: 10 > URL: =20 > https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt = > Status: = https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ = > Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 = >=20 > Abstract: > This document describes how Bidirectional Forwarding Detection (BFD) > can be used to support sub-second detection of a Master Router > failure in the Virtual Router Redundancy Protocol (VRRP). >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 > =20 > =20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Chris,

    Thanks for the clarification. Please cross-post the draft to = rtg-bfd (as you have been doing) to make sure you get the BFD experts to = review the draft.

    One clarification and then a question in section 3 of the = document. You say that BFD requires that a session be formed by both = peers. You can very well form a one way session from the VRRP Master = router to your Backup router. When the Backup Router detects loss of 3 = BFD packets, it can declare the Master as Down and take over as the new = Master router. The question is why do you need a BFD session from the = Backup router to the Master router?

    The other thing I want to make sure if = there is any particular configuration requirement from a BFD YANG model = perspective. I understand that you are using the fast timer in BFD to = detect next-hop IP address liveliness check. We address that = configuration in the BFD YANG model today. However, we have not = addressed the issue of p2mp BFD configuration as yet. Depending on how = that discussion proceeds we might want to look at that also.

    Cheers.

    On Jan 18, 2016, at 10:38 AM, Chris Bowers <cbowers@juniper.net>= wrote:

    Mahesh,
     
    As I understand it, the = authors eventually want this draft to be adopted by the RTGWG.  = This makes sense because it includes VRRP protocol extensions, so it = would normally go to the VRRP WG.   Since the VRRP WG is = concluded, the RTGWG is a reasonable place to do this work.
     
    One might also consider = doing this work in the BFD WG to take advantage of the concentration of = BFD expertise there.  However, since the main content of the = document deals with VRRP behavior and defining a new VRRP packet type, = it seems like it might be a diversion from the main work of the BFD = WG.
     
    If = the RTGWG does adopt the draft, the name of the adopted draft should = start with draft-ietf-rtgwg (as you point out, following = RFC7221). 
     
    As = an individual submission at this point, there are no hard requirements = on the name of the draft, except that it not start with = draft-ietf.  However, when authors are submitting drafts that they = intend to eventually be considered for adoption by the RTGWG, it is = quite useful to name them draft-authorname-rtgwg-yyyy, so that they = automatically show up athttps://datatracker.ietf.org/wg/rtgwg/documents/ at the bottom under the = header of =E2=80=9CRelated Internet-Drafts=E2=80=9D. 
     
    Thanks,
    Chris
     
    From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf = Of Mahesh = Jethanandani
    Sent: Sunday, January 17, 2016 = 10:11 PM
    To: Nitish Gupta (nitisgup) = <nitisgup@cisco.com>
    Cc: Jeff Haas <jhaas@juniper.net>; rtg-bfd@ietf.org; Aditya = Dogra (addogra) <addogra@cisco.com>; colin@doch.org.uk; rtgwg@ietf.org
    Subject: Re: New Version = Notification for draft-nitish-vrrp-bfd-02.txt
     
    Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or = something like that to follow the naming convention described in RFC = 7221?
     
    On = Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) <nitisgup@cisco.com> = wrote:
     
    Hi,

    We have = submitted a new version of the draft. As discussed in IETF 93 at
    prague.

    We have merged the = following drafts:
    http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case= -00



    We = have also taken care of all the comments that were discussed in the
    RTGWG meeting.
    We welcome any comments and = suggestions on the draft.

    Thanks,
    Nitish

    On 13/10/15 9:09 pm, "internet-drafts@ietf.org" = <internet-drafts@ietf.org>
    wrote:



    A new version of I-D, = draft-nitish-vrrp-bfd-02.txt
    has been successfully = submitted by Nitish Gupta and posted to the
    IETF = repository.

    Name:        &= nbsp;     draft-nitish-vrrp-bfd<= br class=3D"">Revision:        <= span class=3D"Apple-converted-space"> 02
    Title:        &= nbsp;       Fast failure = detection in VRRP with BFD
    Document date:        &= nbsp; 2015-10-13
    Group:        &= nbsp;    Individual = Submission
    Pages:        &= nbsp;     10
    URL: =            
    https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.t= xt
    Status: =         https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/
    Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02
    Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

    Abstract:
     This = document describes how Bidirectional Forwarding Detection (BFD)
     can be used to support sub-second detection of a Master = Router
     failure in the Virtual Router Redundancy = Protocol (VRRP).





    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

     
     
    Mahesh = Jethanandani
    mjethanandani@gmail.com

    Mahesh Jethanandani
    mjethanandani@gmail.com





    = --Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98-- From nobody Tue Jan 19 06:36:57 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DDE1B2FA2; Tue, 19 Jan 2016 06:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 J01ipk3geocl; Tue, 19 Jan 2016 06:36:53 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6819A1B2F67; Tue, 19 Jan 2016 06:36:53 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 72C741E7DC; Tue, 19 Jan 2016 09:39:05 -0500 (EST) Date: Tue, 19 Jan 2016 09:39:05 -0500 From: Jeffrey Haas To: Chris Bowers Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Message-ID: <20160119143904.GA28732@pfrc.org> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Nitish Gupta \(nitisgup\)" , Jeff Haas , "Aditya Dogra \(addogra\)" , Mahesh Jethanandani , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:36:54 -0000 [Wearing my BFD co-chair hat.] On Mon, Jan 18, 2016 at 06:38:40PM +0000, Chris Bowers wrote: > One might also consider doing this work in the BFD WG to take advantage of > the concentration of BFD expertise there. However, since the main content > of the document deals with VRRP behavior and defining a new VRRP packet > type, it seems like it might be a diversion from the main work of the BFD > WG. The general policy of the BFD Working Group has been that protocol changes to BFD belong in the BFD working group. Uses of BFD should be carried out in the Working Group that carries the appropriate expertise, but BFD is chartered to help with review of uses of BFD elsewhere. Thus, rtgwg is a perfectly fine place for this draft. If the rtgwg chairs think it's appropriate, last call can occur also in BFD for additional review. -- Jeff From nobody Tue Jan 19 11:54:20 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C551B3514; Tue, 19 Jan 2016 11:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bKtnq-S8JaT; Tue, 19 Jan 2016 11:54:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682401B3511; Tue, 19 Jan 2016 11:54:12 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by SN1PR0501MB1822.namprd05.prod.outlook.com (10.163.131.145) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 19 Jan 2016 19:53:50 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0361.006; Tue, 19 Jan 2016 19:53:50 +0000 From: Chris Bowers To: "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACACWswAA== Date: Tue, 19 Jan 2016 19:53:49 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1822; 5:3lNtDE8CXgs68MjXyozeE9W5UNhn8IGIiWP+9Y4nz3Wyt7lb6FMGO9AJ2I+VcHZtNa3RItYeWPvP9AmK1V8Jefe6Ya2o8xuvZxb0ubvN0wlQctnW4S1glSz6S02rNG4yP9rTHsUQfQY7471NGm25kw==; 24:plgw35mYzvtDZoE4XNvNsbmVTfAIU2N3ey8ayZlOiZAlsIqdz/29R0z/v51UeuJEgfROLCZgPGRbPF9xAAZa3WCNCU67o/x2rF1U/VRZU1Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1822; x-ms-office365-filtering-correlation-id: 443e74ce-0219-4cfe-c53d-08d3210a4053 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR0501MB1822; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1822; x-forefront-prvs: 0826B2F01B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(13464003)(24454002)(189002)(377424004)(199003)(164054003)(377454003)(2201001)(19580405001)(19580395003)(2501003)(15975445007)(33656002)(66066001)(54356999)(2950100001)(99286002)(101416001)(76176999)(77096005)(5002640100001)(7110500001)(105586002)(2420400006)(5003600100002)(106116001)(5004730100002)(4001150100001)(97736004)(230783001)(106356001)(189998001)(122556002)(5001960100002)(40100003)(11100500001)(74316001)(76576001)(5001770100001)(4326007)(50986999)(81156007)(6116002)(2900100001)(86362001)(10400500002)(5008740100001)(2906002)(1220700001)(3846002)(10710500007)(1096002)(102836003)(586003)(92566002)(1720100001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1822; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2016 19:53:50.0587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1822 Archived-At: Cc: Gregory Mirsky , Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 19:54:16 -0000 Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach.=20 So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= .=20 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. =20 A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky ; Jeff Haas ; colin@doch.org.uk; Aditya Dogra (addogra) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93=20 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the=20 >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org"=20 > >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been=20 >>successfully submitted by Nitish Gupta and posted to the IETF=20 >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>The IETF Secretariat >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From nobody Tue Jan 19 21:11:21 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952BB1A1EB7; Tue, 19 Jan 2016 21:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRPoX05qm2bx; Tue, 19 Jan 2016 21:11:16 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABB61A1E0F; Tue, 19 Jan 2016 21:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3563; q=dns/txt; s=iport; t=1453266676; x=1454476276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nBs4D1I1Ql6jbVp+RzzWUm2kCdvgvFNV2BAc5ZKuMY0=; b=mnD/BQB6IMqcxH8/plJkrFhmJCqZw2ci1gX426qKkz51ezVrQ26bvB26 98vkgS2yFpoCgIqOtMaJiVpHfFq8uSkpvn5bia5FSLgvwQBhI7y2/F2F2 /sA6+d5crzf45XikQ7X2JtbttTTtbQ2tVzcuhbYp51MJCzLpxwXbS7/2s M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgA4Fp9W/51dJa1egzpSbQaIUbJyA?= =?us-ascii?q?Q2BYyKFbQKBRzgUAQEBAQEBAYEKhDQBAQEEOj0CDAICAgEIEQQBAR8JBxYcFAk?= =?us-ascii?q?IAgQBDQWIGw6/SAEBAQEBAQEBAQEBAQEBAQEBAQEBARUEhjaEdIQYCREBJIRaB?= =?us-ascii?q?Y1CiVgBhUeIF4FeSoN6gyuFNIpsg28BIAEBQoQJcgGFbzqBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,319,1449532800"; d="scan'208";a="229370339" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 05:11:15 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0K5BF6u032015 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 05:11:15 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 00:11:14 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 00:11:14 -0500 From: "Nitish Gupta (nitisgup)" To: Alexander Vainshtein , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACABaF0QIAFFiWA Date: Wed, 20 Jan 2016 05:11:14 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "jhaas@juniper.net" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:11:18 -0000 Hi Alexander, Thanks for your comments. We would be adding the IANA considerations in the next version of the draft for setting up a registry for VRRP Advert types. Thanks, Nitish On 17/01/16 3:34 pm, "Alexander Vainshtein" wrote: >Hi all, >I have read the draft and I have one (presumably, minor) comment: >- The IANA Considerations section of says that there are no IANA request. >- At the same time the draft defines a new type of VRRP messages (2 - >Backup Advertisement). > >As long as here was just one type of VRRP messages (1 - Advertisement), >we could avoid setting up a IANA registry for VRRP message types. If we >are going to have two, does not this justify setting up such a registry? > >Regards, >Sasha > >Office: +972-39266302 >Cell: +972-549266302 >Email: Alexander.Vainshtein@ecitele.com > >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nitish Gupta >(nitisgup) >Sent: Wednesday, January 13, 2016 11:31 AM >To: rtgwg@ietf.org; rtg-bfd@ietf.org >Cc: jhaas@juniper.net; colin@doch.org.uk; Aditya Dogra (addogra) >Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt > >Hi, > >We had presented the Draft for VRRP BFD integration in IETF 93 and we had >taken care of all the comments that came as part of the WG meeting. >We had also merged the two drafts as per the comments in IETF 93: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > >We had presented the merged draft in IETF 94 and there were no specific >comments on the draft. >We would like to ask the RTGWG to adopt the Draft as a WG document. > >Thanks, >Nitish > > >On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" >wrote: > >>Hi, >> >>We have submitted a new version of the draft. As discussed in IETF 93 >>at prague. >> >>We have merged the following drafts: >>http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >> >>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >> >> >> >>We have also taken care of all the comments that were discussed in the >>RTGWG meeting. >>We welcome any comments and suggestions on the draft. >> >>Thanks, >>Nitish >> >>On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>>successfully submitted by Nitish Gupta and posted to the IETF >>>repository. >>> >>>Name: draft-nitish-vrrp-bfd >>>Revision: 02 >>>Title: Fast failure detection in VRRP with BFD >>>Document date: 2015-10-13 >>>Group: Individual Submission >>>Pages: 10 >>>URL: =20 >>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>>Diff: =20 >>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >>> >>>Abstract: >>> This document describes how Bidirectional Forwarding Detection (BFD) >>> can be used to support sub-second detection of a Master Router >>> failure in the Virtual Router Redundancy Protocol (VRRP). >>> >>> =20 >>> =20 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> > From nobody Tue Jan 19 21:32:56 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63251A6EF9; Tue, 19 Jan 2016 21:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LiWbhEJ3IdP; Tue, 19 Jan 2016 21:32:51 -0800 (PST) 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 4C3AC1A6EF2; Tue, 19 Jan 2016 21:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28849; q=dns/txt; s=iport; t=1453267971; x=1454477571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4OF+DNh/0cxok/lnEG6qZWweYYRIps/q6msKqoYRD44=; b=mN5qTfDlhZ9laDEhZqfv9UT0YgPu2NBZ45P5st0j4cprTLkrteo8u+s2 JBqakzFGfrHT8k/s0muKUx9bTdK8gqspRdgi15bN1dB1iBI9k3mIt1pJK KIQT0/KMk5ChjcOWRp2Q2LjesyJdUwkUACOLakt07ZZTOTv6OAOWCbwwo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgBjG59W/5RdJa1egm5MUm0GiFGyc?= =?us-ascii?q?gENgWMihBaBVwKBSDgUAQEBAQEBAYEKhDQBAQEEawwCEAIBCA4DAwEBASEHByE?= =?us-ascii?q?RFAkIAgQBDQWIBgMSDrtsDYNMAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYY6hHSCT?= =?us-ascii?q?oFKWQ0JCIQiBY1ChVGEBwGFR4YfgXiBXkqDeohfhn+DbYNvAREPAQFChAlyAYY?= =?us-ascii?q?pgQgBAQE?= X-IronPort-AV: E=Sophos; i="5.22,319,1449532800"; d="scan'208,217"; a="68911684" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 05:32:49 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u0K5WnAT002295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 05:32:50 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 00:32:48 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 00:32:48 -0500 From: "Nitish Gupta (nitisgup)" To: Mahesh Jethanandani , Chris Bowers Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgIOBV4CAAPKPAIAAwjmAgAHjCoA= Date: Wed, 20 Jan 2016 05:32:48 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> In-Reply-To: <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.195] Content-Type: multipart/alternative; boundary="_000_D2C514DF5CE46nitisgupciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jeff Haas , Gregory Mirsky , "Aditya Dogra \(addogra\)" , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:32:54 -0000 --_000_D2C514DF5CE46nitisgupciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Thanks for your comments please see inline. Thanks, Nitish From: Mahesh Jethanandani > Date: Tuesday, 19 January 2016 11:43 am To: Chris Bowers > Cc: Nitish Gupta >, Jeff Haas= >, "rtg-bfd@ietf.org" >, "Aditya Dogra= (addogra)" >, "colin@doch.org.= uk" >= , "rtgwg@ietf.org" > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Chris, Thanks for the clarification. Please cross-post the draft to rtg-bfd (as yo= u have been doing) to make sure you get the BFD experts to review the draft= . One clarification and then a question in section 3 of the document. You say= that BFD requires that a session be formed by both peers. You can very wel= l form a one way session from the VRRP Master router to your Backup router.= When the Backup Router detects loss of 3 BFD packets, it can declare the M= aster as Down and take over as the new Master router. The question is why d= o you need a BFD session from the Backup router to the Master router? [nitish] I just want to clarify one point that there will be only one sessi= on between a pair of VRRP router instance for example in this case if there= is only one VRRP Master and one VRRP backup Router there will be only one = BFD session. Though both the devices would require to initiate BFD bootup = sequence but there will be only one BFD session formed between them. As Sec= tion 3 of RFC 5881 (Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) ) mandates that the session be initiated by both the participating peers fo= r a session to be formed between them. Hence the Backup router needs to kno= w the Master IPVX address to initiate a BFD session. The other thing I want to make sure if there is any particular configuratio= n requirement from a BFD YANG model perspective. I understand that you are = using the fast timer in BFD to detect next-hop IP address liveliness check.= We address that configuration in the BFD YANG model today. However, we hav= e not addressed the issue of p2mp BFD configuration as yet. Depending on ho= w that discussion proceeds we might want to look at that also. [nitish] There is no particular requirement that we can see from BFD YANG m= odel perspective. As VRRP should interface with BFD as another protocol usi= ng BFD as a means of fast failure detection of its peer. Cheers. On Jan 18, 2016, at 10:38 AM, Chris Bowers > wrote: Mahesh, As I understand it, the authors eventually want this draft to be adopted by= the RTGWG. This makes sense because it includes VRRP protocol extensions,= so it would normally go to the VRRP WG. Since the VRRP WG is concluded, = the RTGWG is a reasonable place to do this work. One might also consider doing this work in the BFD WG to take advantage of = the concentration of BFD expertise there. However, since the main content = of the document deals with VRRP behavior and defining a new VRRP packet typ= e, it seems like it might be a diversion from the main work of the BFD WG. If the RTGWG does adopt the draft, the name of the adopted draft should sta= rt with draft-ietf-rtgwg (as you point out, following RFC7221). As an individual submission at this point, there are no hard requirements o= n the name of the draft, except that it not start with draft-ietf. However= , when authors are submitting drafts that they intend to eventually be cons= idered for adoption by the RTGWG, it is quite useful to name them draft-aut= horname-rtgwg-yyyy, so that they automatically show up athttps://datatracke= r.ietf.org/wg/rtgwg/documents/ at the bottom under the header of =93Related= Internet-Drafts=94. Thanks, Chris From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Mahesh Jethanandan= i Sent: Sunday, January 17, 2016 10:11 PM To: Nitish Gupta (nitisgup) > Cc: Jeff Haas >; rtg-bfd@ietf.o= rg; Aditya Dogra (addogra) >; colin@doch.org.uk; rtgwg@= ietf.org Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Shouldn=92t the draft be named draft-nitish-bfd-vrrp or something like that= to follow the naming convention described in RFC 7221? On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) > wrote: Hi, We have submitted a new version of the draft. As discussed in IETF 93 at prague. We have merged the following drafts: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We have also taken care of all the comments that were discussed in the RTGWG meeting. We welcome any comments and suggestions on the draft. Thanks, Nitish On 13/10/15 9:09 pm, "internet-drafts@ietf.org" > wrote: A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been successfully submitted by Nitish Gupta and posted to the IETF repository. Name: draft-nitish-vrrp-bfd Revision: 02 Title: Fast failure detection in VRRP with BFD Document date: 2015-10-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-0= 2 Abstract: This document describes how Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Master Router failure in the Virtual Router Redundancy Protocol (VRRP). 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 Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --_000_D2C514DF5CE46nitisgupciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2AB9819CFE9B4E40AF22EADBBA303D49@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    Hi Mahesh,

    Thanks for your comments please see inline.

    Thanks,
    Nitish

    From: Mahesh Jethanandani <mjethanandani@gmail.com>
    Date: Tuesday, 19 January 2016 11:4= 3 am
    To: Chris Bowers <cbowers@juniper.net>
    Cc: Nitish Gupta <nitisgup@cisco.com>, Jeff Haas <jhaas@juniper.net>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Aditya Dogra (addogra)" <addogra@cisco.com>, "col= in@doch.org.uk" <colin@doc= h.org.uk>, "rtgwg@ietf.org" <rtgwg@ietf.org>
    Subject: Re: New Version Notificati= on for draft-nitish-vrrp-bfd-02.txt

    Chris,

    Thanks for the clarification. Please cross-post the draft t= o rtg-bfd (as you have been doing) to make sure you get the BFD experts to = review the draft.

    One clarification and then a question in section 3 of the d= ocument. You say that BFD requires that a session be formed by both peers. = You can very well form a one way session from the VRRP Master router to you= r Backup router. When the Backup Router detects loss of 3 BFD packets, it can declare the Master as Down and take = over as the new Master router. The question is why do you need a BFD sessio= n from the Backup router to the Master router?

    [nitish] I just want to clarify one point that there will be only one = session between a pair of VRRP router instance for example in this case if = there is only one VRRP Master and one VRRP backup Router there will be only= one BFD session.  Though both the devices would require to initiate BFD bootup sequence but there will be on= ly one BFD session formed between them. As Section 3 of RFC 5881 (Bidi= rectional Forwarding Detection (BFD)

    for IPv4 a= nd IPv6 (Single Hop)

    ) mandates that the session be initiated by both the participating p= eers for a session to be formed between them. Hence the Backup router needs= to know the Master IPVX address to initiate a BFD session.

    The other thing I want to make sure if there is any particu= lar configuration requirement from a BFD YANG model perspective. I understa= nd that you are using the fast timer in BFD to detect next-hop IP address l= iveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue of p= 2mp BFD configuration as yet. Depending on how that discussion proceeds we = might want to look at that also.

    [nitish] There is no particular requirement that we can see= from BFD YANG model perspective. As VRRP should interface with BFD as anot= her protocol using BFD as a means of fast failure detection of its peer.

    Cheers.

    On Jan 18, 2016, at 10:38 AM, Chris Bowers <cbowers@juniper.net> wrote:
    Mahesh,
     
    As I understand it, the authors eventually want= this draft to be adopted by the RTGWG.  This makes sense because it i= ncludes VRRP protocol extensions, so it would normally go to the VRRP WG.   Since the VRRP WG is concluded, th= e RTGWG is a reasonable place to do this work.=
     
    One might also consider doing this work in the = BFD WG to take advantage of the concentration of BFD expertise there. = However, since the main content of the document deals with VRRP behavior and defining a new VRRP packet type, it seems lik= e it might be a diversion from the main work of the BFD WG.=
     
    If the RTGWG does adopt the draft, the name of = the adopted draft should start with draft-ietf-rtgwg (as you point out, fol= lowing RFC7221). 
     
    As an individual submission at this point, ther= e are no hard requirements on the name of the draft, except that it not sta= rt with draft-ietf.  However, when authors are submitting drafts that they intend to eventually be considered for ado= ption by the RTGWG, it is quite useful to name them draft-authorname-rtgwg-= yyyy, so that they automatically show up athttps://datatracker.ietf.org/wg/rtgwg/documents/ at the bottom under the header of =93Related Internet-Drafts=94. 
     
    Thanks,
    Chris
     
    From:&= nbsp;rtgwg [mailto:rtgwg-bounces@ietf= .org] O= n Behalf Of Mahesh Jet= hanandani
    Sent: S= unday, January 17, 2016 10:11 PM
    To: Nit= ish Gupta (nitisgup) <nitisgup@cisco.com&= gt;
    Cc: Jef= f Haas <jhaas@juniper.net>; rtg-bfd@ie= tf.org; Aditya Dogra (addogra) <addogra@cisco.com= >; colin@doch.org.uk; rtgwg@ietf.org
    Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
     
    Shouldn=92t the draft be named draft-nitish-bfd-vrrp or something like that= to follow the naming convention described in RFC 7221?
     
    On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) <nitisgup@cisco.com> wrote:
     
    Hi,

    We have submitted a new version of the draft. As discussed in IETF 93 at prague.

    We have merged the following drafts:
    http://tools.ietf.org/= html/draft-nitish-vrrp-bfd-01

    https:/= /tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00



    We have also taken care of all the comments that were discussed in the
    RTGWG meeting.
    We welcome any comments and suggestions on the draft.

    Thanks,
    Nitish

    On 13/10/15 9:09 pm, "internet-drafts= @ietf.org" <internet-drafts@= ietf.org>
    wrote:



    A new version of I-D, draft-nitish-vrrp-bfd-02.txt
    has been successfully submitted by Nitish Gupta and posted to the
    IETF repository.

    Name:      &nb= sp;       draft-nitish-vrrp-bfd
    Revision:      = ;   02 Title:      &n= bsp;         Fast failure detection in VRRP with BFD<= br class=3D""> Document date:     =      = 2015-10-13
    Group:      &n= bsp;     &nb= sp;Individual Submission
    Pages:      &n= bsp;       10
    URL:            
    https://= www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt
    Status:         https://datatracker.ietf.org/doc/draf= t-nitish-vrrp-bfd/
    Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-= 02
    Diff:           https://www.ietf.org= /rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

    Abstract:
     This document describes how Bidirectional Forwarding Detection (BFD)<= br class=3D"">  can be used to support sub-second detection of a Master Router
     failure in the Virtual Router Redundancy Protocol (VRRP).





    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

     
     
    Mahesh Jethanandani
    mjethanandani@g= mail.com

    Mahesh Jethanandani
    mjeth= anandani@gmail.com





     --_000_D2C514DF5CE46nitisgupciscocom_-- From nobody Tue Jan 19 23:06:25 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745BA1A8703; Tue, 19 Jan 2016 23:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh4fcUHan0bk; Tue, 19 Jan 2016 23:06:20 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71561A86E3; Tue, 19 Jan 2016 23:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7343; q=dns/txt; s=iport; t=1453273580; x=1454483180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t/xVzZ9Etkms2HS7xL6Y5KNG6pTeWc3hKkhBc2Kxeuk=; b=MO3maKc3o/VKXBaOTBjDK+TX/R19n8uZuKVjGkEJ63N2YJTFAxcFAS5K mWsJDrTBEOGTyOwTzKPQ7VL9RzAXDDyNNCCqYN2NSUXKlNjf8RaKAWd4n t1vCl1Y6YuCaiMAJlEnAJEvvkhDBC08w0zMEJMef+nA1ue1R3n/yuEzvL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgBxMZ9W/5tdJa1egzpSbQaIUbJyA?= =?us-ascii?q?Q2BYxgKhW0CgUE4FAEBAQEBAQGBCoQ0AQEBBAEBATc0CQIMBAIBCA4DBAEBHwk?= =?us-ascii?q?HJwsUCQgCBAENBYgbDr9OAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYY6g3CBBIQYC?= =?us-ascii?q?REBhH4FjUKJWAGFR4gXgV5Kg3qDK4U0imyDbwEgAQFCghEbgV1yAYVvOoEIAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.22,320,1449532800"; d="scan'208";a="227616537" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 07:06:18 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0K76ISn024713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 07:06:18 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 02:06:17 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 02:06:17 -0500 From: "Nitish Gupta (nitisgup)" To: Chris Bowers , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACACWswAIABbJEA Date: Wed, 20 Jan 2016 07:06:17 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <32EEA8A063007C4FB002A374F8B4811D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 07:06:23 -0000 Hi Chris, Thanks for your comments. We would like to take care of the comments you have given before we ask the WG for adoption. Thanks, Nitish On 20/01/16 1:23 am, "Chris Bowers" wrote: >Nitish and co-authors, > >I have read this draft and have several comments below. In general, I >prefer that authors address outstanding comments in a new revision before >we conduct a poll for adoption in RTGWG. Since an adoption poll usually >triggers quite a few people read a draft in detail, it makes better use >of the working groups time to have them reading the most up-to-date >version. However, an argument could also be made for filling in some of >the additional detail that I am asking for below after WG adoption >(assuming it is adopted), when the WG has more direct control of the >document. So I am open to either approach. > >So please respond to the feedback below and tell me if you would like to >address some of it in a new revision before I conduct a poll for WG >adoption, or if you would prefer to do the WG adoption poll using the >current revision. There has also been feedback from others on this draft >in response to your email, so you should respond to that as well. > >In general, I think the draft would benefit from specifying the VRRP >state machine for this BFD mode of operation at the same level of detail >that RFC5798 specifies the existing VRRP state machine. There are >several places where it is probably possible to infer the correct >behavior, but making it very explicit will make for a better document. > >1) Section 3.5 of this draft defines the Critical BFD session which is >the BFD session between the VRRP Master and the next best VRRP backup. >In the existing VRRP state machine, a VRRP router in the backup state is >not able to determine if it is the next best VRRP backup. Presumably, in >the VRRP state machine for the BFD mode of operation, a VRRP router in >the backup state will look at the peer table populated by the Backup >Advertisements and figure out which router is the next best VRRP router >based on highest priority value with highest IPvX address as tie breaker. > However, it would be better to be as explicit as RFC5798 about how this >new state machine operates. > >2) Section 5 says that "To reduce the number of packets generated at a >regular interval, Backup Advert packets may be sent at a reduced rate as >compared to Advert packets sent by the VRRP Master." It seems that the >state machine for VRRP BFD mode will have to be enhanced in some way to >support this. One way to do this would be for each router to have a >Backup_Advertisement_Interval which it uses to populate the Maximum >Advertisement Interval in the BACKUP ADVERTISEMENT, and have each >receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and >remove a peer entry when a BACKUP ADVERTISEMENT is not received from P >for 3* Peer_Advert_Interval(P). But this is just one possible approach. >In any case, it would be good to choose a mechanism and describe the >corresponding state machine. > >3) The text should clarify how the VRRP state machine interacts with the >BFD state machine. One can imagine scenarios where a BFD session stays >up but the VRRP advertisements stop being received, or vice versa. This >scenario is not very far-fetched because BFD may use unicast and VRRP >uses multicast. Behavior can probably be inferred from existing text, >but I think more precision is better here. > >4) I don't understand Section 4 which describes how to use p2mp BFD. > >A) The text says that "The Master router starts transmitting BFD control >packets with VRID as source IP address." According to RFC5798, the VRID >is an integer in the range from 1-255. Is the idea to encode the integer >VRID as an IP address? Or should the BFD control packets be sent with >the source IP address set to an IPvX address associated with the virtual >router? Or are both used? In any case, it seems like this needs >clarification. > >B) What is the destination IP address of the p2mp BFD control packet? Is >it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast >addresses for VRRP? If so, this should be made explicit. > >C) Again, a state machine description would help readers and future >implementers understand exactly what is intended. > >Thanks, >Chris > >-----Original Message----- >From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta >(nitisgup) >Sent: Wednesday, January 13, 2016 3:31 AM >To: rtgwg@ietf.org; rtg-bfd@ietf.org >Cc: Gregory Mirsky ; Jeff Haas >; colin@doch.org.uk; Aditya Dogra (addogra) > >Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt > >Hi, > >We had presented the Draft for VRRP BFD integration in IETF 93 and we had >taken care of all the comments that came as part of the WG meeting. >We had also merged the two drafts as per the comments in IETF 93: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > >We had presented the merged draft in IETF 94 and there were no specific >comments on the draft. >We would like to ask the RTGWG to adopt the Draft as a WG document. > >Thanks, >Nitish > > >On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" >wrote: > >>Hi, >> >>We have submitted a new version of the draft. As discussed in IETF 93 >>at prague. >> >>We have merged the following drafts: >>http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >> >>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >> >> >> >>We have also taken care of all the comments that were discussed in the >>RTGWG meeting. >>We welcome any comments and suggestions on the draft. >> >>Thanks, >>Nitish >> >>On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>>successfully submitted by Nitish Gupta and posted to the IETF >>>repository. >>> >>>Name: draft-nitish-vrrp-bfd >>>Revision: 02 >>>Title: Fast failure detection in VRRP with BFD >>>Document date: 2015-10-13 >>>Group: Individual Submission >>>Pages: 10 >>>URL: =20 >>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>>Diff: =20 >>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >>> >>>Abstract: >>> This document describes how Bidirectional Forwarding Detection (BFD) >>> can be used to support sub-second detection of a Master Router >>> failure in the Virtual Router Redundancy Protocol (VRRP). >>> >>> =20 >>> =20 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From nobody Wed Jan 20 07:36:31 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACF11A8ADC for ; Wed, 20 Jan 2016 07:36:30 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TRne2I1uswL for ; Wed, 20 Jan 2016 07:36:29 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46121A8F39 for ; Wed, 20 Jan 2016 07:36:28 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-5d-569fa96b967a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C7.41.32102.B69AF965; Wed, 20 Jan 2016 16:36:11 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 10:36:27 -0500 From: Uma Chunduri To: "rtgwg@ietf.org" Subject: FW: New Version Notification for draft-psarkar-rtgwg-multihomed-prefix-lfa-03.txt Thread-Topic: New Version Notification for draft-psarkar-rtgwg-multihomed-prefix-lfa-03.txt Thread-Index: AQHRU1mD/KaBz+tsS0uVrZ4zYBE9qZ8EiMKg Date: Wed, 20 Jan 2016 15:36:26 +0000 Message-ID: <1B502206DFA0C544B7A60469152008635148C8EE@eusaamb105.ericsson.se> References: <20160120080645.21304.27707.idtracker@ietfa.amsl.com> In-Reply-To: <20160120080645.21304.27707.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXSPt272yvlhBs96lC0uvPnN7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEeLl7IUzBKr2LB0K3sD4wXRLkZODgkBE4ktv56yQthiEhfu rWfrYuTiEBI4wijx/NNPJghnOaPEu0/fmECq2AT0JD5O/ckOYosIqEr0zmplA7GFBWIkzj5+ zwQRj5W4PvsCSxcjB5BtJPFsFiNImAWovHnRdBYQm1fAV2LV249gcSEBR4l/3cvAxnAKOElM fr8fLM4IdND3U2vARjILiEvcejKfCeJQAYkle84zQ9iiEi8f/4N6QEni4+/57CBrmQU0Jdbv 0odoVZSY0v2QHWKtoMTJmU9YJjCKzkIydRZCxywkHbOQdCxgZFnFyFFaXJCTm25kuIkRGPTH JNgcdzDu7fU8xCjAwajEw7uhfV6YEGtiWXFl7iFGCQ5mJRFe8aXzw4R4UxIrq1KL8uOLSnNS iw8xSnOwKInzJso0hgkJpCeWpGanphakFsFkmTg4pRoYrS5czr2+JmJ+X3rU99icrrTvNv65 H6ov+jEaTkyp6qk4ESVdaHBstW3IjM//bx7494Vhz2lvPpfbz2rCnz1ZU9rOPJnz+xo1geWv 2HXe/fG9/1DgyePPS5Uy2C9kTFid+OpVlUQyq6RgiTo3SwR/lv7H8MxGbi6GM4y/Ob+sC/8Q KHSvcqKaEktxRqKhFnNRcSIARhpLTnYCAAA= Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:36:30 -0000 RGVhciBSdGdXRywNCg0KVGhpcyB1cGRhdGUgZ2V0cyB0aGUgY29udGVudCBmcm9tIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaHVuZHVyaS1ydGd3Zy1sZmEtZXh0ZW5kZWQtcHJv Y2VkdXJlcy0wMyB0byBtYWtlIGFuIHVuaWZpZWQgZHJhZnQgZm9yIE1IUCBoYW5kbGluZyBhbmQg b3RoZXIgcHJvY2VkdXJlcyByZWxhdGVkIExGQS9SRkMgNTI4Ni4NCg0KWW91ciBjb21tZW50cywg c3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZS4NCg0KLS0NClVtYSBDLg0KKG9uZSBiZWhhbGYg b2YgYWxsIGNvLWF1dGhvcnMpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAyMDE2IDEyOjA3IEFNDQpUbzogU2hyYWRk aGEgSGVnZGU7IEplZmYgVGFudHN1cmE7IFB1c2hwYXNpcyBTYXJrYXI7IEhhbm5lcyBHcmVkbGVy OyBDaHJpcyBCb3dlcnM7IEJydW5vIERlY3JhZW5lOyBVbWEgQ2h1bmR1cmkNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcHNhcmthci1ydGd3Zy1tdWx0aWhvbWVk LXByZWZpeC1sZmEtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBzYXJr YXItcnRnd2ctbXVsdGlob21lZC1wcmVmaXgtbGZhLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBVbWEgQ2h1bmR1cmkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtcHNhcmthci1ydGd3Zy1tdWx0aWhvbWVkLXByZWZpeC1s ZmENClJldmlzaW9uOgkwMw0KVGl0bGU6CQlMRkEgc2VsZWN0aW9uIGZvciBNdWx0aS1Ib21lZCBQ cmVmaXhlcw0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wMS0xOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJMTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcHNhcmthci1ydGd3Zy1tdWx0aWhvbWVkLXByZWZpeC1s ZmEtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtcHNhcmthci1ydGd3Zy1tdWx0aWhvbWVkLXByZWZpeC1sZmEvDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBzYXJrYXItcnRnd2ctbXVs dGlob21lZC1wcmVmaXgtbGZhLTAzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LXBzYXJrYXItcnRnd2ctbXVsdGlob21lZC1wcmVmaXgtbGZh LTAzDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzaGFyZXMgZXhwZXJpZW5jZSBnYWlu ZWQgZnJvbSBpbXBsZW1lbnRpbmcgYWxnb3JpdGhtcw0KICAgdG8gZGV0ZXJtaW5lIExvb3AtRnJl ZSBBbHRlcm5hdGVzIGZvciBtdWx0aS1ob21lZCBwcmVmaXhlcy4gIEluDQogICBwYXJ0aWN1bGFy LCB0aGlzIGRvY3VtZW50IHByb3ZpZGVzIGV4cGxpY2l0IGluZXF1YWxpdGllcyB0aGF0IGNhbiBi ZQ0KICAgdXNlZCB0byBldmFsdWF0ZSBuZWlnaGJvcnMgYXMgYSBwb3RlbnRpYWwgYWx0ZXJuYXRl cyBmb3IgbXVsdGktaG9tZWQNCiAgIHByZWZpeGVzLiAgSXQgYWxzbyBwcm92aWRlcyBkZXRhaWxl ZCBjcml0ZXJpYSBmb3IgZXZhbHVhdGluZw0KICAgcG90ZW50aWFsIGFsdGVybmF0ZXMgZm9yIGV4 dGVybmFsIHByZWZpeGVzIGFkdmVydGlzZWQgYnkgT1NQRiBBU0JScy4NCg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Jan 20 08:21:47 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89B81A8AAD; Wed, 20 Jan 2016 07:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu9jpFJpfZy4; Wed, 20 Jan 2016 07:10:41 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30491A8AAC; Wed, 20 Jan 2016 07:10:39 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jhaas@juniper.net; Received: from [172.29.32.70] (66.129.241.13) by CY1PR0501MB1817.namprd05.prod.outlook.com (10.163.141.143) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 15:10:35 +0000 Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89" From: Jeff Haas In-Reply-To: Date: Wed, 20 Jan 2016 10:10:29 -0500 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> To: "Nitish Gupta (nitisgup)" X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY1PR18CA0028.namprd18.prod.outlook.com (25.162.126.38) To CY1PR0501MB1817.namprd05.prod.outlook.com (25.163.141.143) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1817; 2:zokglNlVTSMt+vQ7/YWpzEXBuLr+zI6iqKaZhKuyL6m5KzzJrK6svBxtxVaYU9ojBDsAUD6rJ/G3f2n0VUzPwc9FgmJ5SoaHO4qD9f4YNsGwMUC6QVDytjPVECJ0I9ieHum24+mvOqQaTf8RZAkhrg==; 3:CT1DeSiBXR/1y3BmIigzplTuL51WrmZ38JvEzKVICa/wkkqEH8d59S85kzBHSvk/xpqcYo2dO8uYUAoMGwX+wHPF4vC9x4/CfTox5Yx8t2RnbmHj6YQ7GZ5HLRH00T1n; 25:Ms9sF08wrgXkXmtPLrqpzx9lpjjWtv7xBiOnWdRT3HmQUwOpbgjDLL0eDl7qaKEAm25F/jK0vDb1CD4WDma8rPRO8KdpnnEztBla7TjFc7eDCGrng1fZTzGjYh1lhwtRDAY5rZ7R7IRVZAbpJGJA86SiKq/2IWe5A3uqmA20dqPhLtx0tgQXYbcUfUI1qI5oZ0D+G9vdpH/G/XjI8t/xEy297LMuhyfyx/i8DnpUjzvU95prXi1IUDWOkHY0OFrq X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1817; X-MS-Office365-Filtering-Correlation-Id: 1d2b4209-2659-474d-7808-08d321abda88 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1817; 20:CWBCC1Ca+fMS40Em4/Z72WHQLfMr1jaxlLpMJIi5HuOl/6p4pRWcivjFtTTjX/KpEETVcvU2Mu1tXDOxWJrtCZaKoBEWQhdbSsXYCBIV1RsWGeWsP+zmZY3vHK7rjaU7jsf0JKNuaUHRF4iR1aIZTRhuYg7XS9rsPXvJGtg7vcy0nNIKMuK7OeKFY8W+FWQl4fe6ulL3vIn3rd5R8TU1q/xJr87OZev0FCiiUcd4LvMiO+X33Vb83Erj4EZsvKjg1LSILKu9nx8GsV+U+yj6bmyh63sfU/5dHA0dlj+gjeW94Ks9OWPaj5+BmyH8xj/kPG2XHG23DAsFa7xVjhp2dJMTKLvl6YSRRnVdaERRM7BjWmBxXS5bXAcDe+WaobwqJzMePZ0sKRSXIrLhlkAF39q6mOBCPpsmV0wgRHYYhzGS/zfL0hPPGvt04GtMStAUpvd9KnE6IiZFSOM3Iy7tjIF9REh3tKA/VDHIr9NGF5B5WrGbpxPL/cePukzWJIFB; 4:b43piWshfJTm9E+kLmapC4SxG4FQ1i4x+kciVdBngQXhkSPt0b9CAK4ObS5fvU94PTDLRPI0Rbi6UsyQz0PlotN43ptULxyAcAD5CMv4rnpA0cHdg4eKgQarfVC3211yNIFm9Ep2p+nrUDgz3BBqkofhdwYJjJjQxv1aEGMa7gto/BYfRc4502Wcs8kAdaf32fNCrya5yqroYJKd80AQ4wvmfuV8ALWaVyGkXO/gd0cwEdNFzkPyH80/9Rtj96kwabsHACwmvHllJKubS7KRBLqySOrsm/0OCDQlAv9UF4HCLr7Xl2Soy6MVIVgRepSSuTuhuFScY7XzhlDVHMmvr00B7FwxNzv2h1y8NmZsBkjlMIp8aLAk5nPGWgcFiGurinSeKZd1R8yA4lRfHf7iai6RRnNelKBkNv3T5UBKnBk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1817; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1817; X-Forefront-PRVS: 0827D7ACB9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(24454002)(199003)(377454003)(189002)(106356001)(92566002)(1096002)(77096005)(4326007)(82746002)(86362001)(93886004)(230783001)(19580395003)(2950100001)(5004730100002)(5008740100001)(19580405001)(3846002)(512944002)(6116002)(40100003)(76176999)(66066001)(50986999)(122386002)(101416001)(33656002)(69556001)(189998001)(84326002)(5001960100002)(110136002)(87976001)(36756003)(83716003)(97736004)(81156007)(105586002)(42186005)(57306001)(2906002)(50226001)(586003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1817; H:[172.29.32.70]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR0501MB1817; 23:pD9Q8efwz4hkY9WnCTi8sSCyRHBnL0yvTSf?= =?Windows-1252?Q?U0ysHwWDmf8Izv8EE/fa4zMf4GyjbwtmxSNbEv/0S5hrLjBRhlyJBOCR?= =?Windows-1252?Q?F3VDeI/odhYqW9s9ER/8Pi+3rWEja3Zs2AORlhli8D89xoyMobyP3Fun?= =?Windows-1252?Q?Ss2VO0utxc6SWk4yAIq7PR2VQOunxahYyu+sxk8a89lw+Css797yGvyB?= =?Windows-1252?Q?Sri5zwRaQysIoU+lx50aBWTgLbyMBcJhfVQVmjaeltm/8sTW1uYkGRhH?= =?Windows-1252?Q?Q2DXFh8MDWxaNJ/YXYvdOxDYWcbxLpfpExYgxow1XDdQSRH6Kgot0NFR?= =?Windows-1252?Q?zlti0lUkLp1Xp6uMIzYsHNlLYBnlXdfCwSaO7wYB9MSI8F5ld+t2OZQc?= =?Windows-1252?Q?7lU02X4VR2bIUIfHn1YKTOyPz3OZ3b1K5EbSk3YlDJUGDnqeV6P/1zoa?= =?Windows-1252?Q?PsgTAUjcC0z+J1lSqJO0bmping21cs9dAKAlFGcRmyeZd0JI6Gu9P134?= =?Windows-1252?Q?xcjD8AxFaoO4lOOplK7p90V29/Ti5k+Wrs6QcCVSg+2Pd5PrT+47OydA?= =?Windows-1252?Q?3sAC10wpkHwCH8yby2qQLBikTo3JWAU+xbkJYuTXg5WMdDQAU85qAHTn?= =?Windows-1252?Q?AuV7JFK3jYzwPXogyU3FnLWJawsMeaPFdJGMPc1JToClrIozFIF9d5gT?= =?Windows-1252?Q?/Z/7r9j9k7Hmatwi5K7oR0rlHEKO1SL4IibzLKhvk0aBGA6i4bSYHMLg?= =?Windows-1252?Q?qVAxpRB0h8vxaJ+R7i29mVS/9gppTOgv6nyTqutIv02CMJRFozqrb5aO?= =?Windows-1252?Q?1mkor0+8Q5OjWTNyf+rhj8kwB3MvFc8GDRYb1ZNwR96pgDyS3/2QcDcx?= =?Windows-1252?Q?h70Voegb3MeYIEt84jA2XE3D8FZGqoNxLDPN4A9L372g7iKd4RLzg0DU?= =?Windows-1252?Q?Ep7mGvfMa7pGdYrIlNEPfaw7x3gdCoO7QVqSMDW/fadx+cUbYDnHKVNJ?= =?Windows-1252?Q?NGHkuez/cTXJzvNUDfdnDyZqjJ6jUyDsioA9XbUsrrVEmdT2Quv3dnsJ?= =?Windows-1252?Q?4asVRfebHxcJ2H7NiCx/t6AWGELN/s8pxsGV/UiNMj63E/0ubqmf7OJo?= =?Windows-1252?Q?/ydDDDooLHEMYTpzZJmXDlNGYUNQ5jo3/7cqp03TqmtcYE9cN/5PIJwF?= =?Windows-1252?Q?pkYyf22r7vM8JyCPen5tKY2EPjh/P4QbWPsDrj/51n2Ym0blypTIvYz5?= =?Windows-1252?Q?QI8Qaw6KaNYGNnevH1u/XTEgb2BJ+t+jQx3sqoqA=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1817; 5:5PpSl9t8Te6hgS7pF/aTWfDHl8MGMquAyInd/p28QvMDOWIFoqvrODy/yYVDx3n/bEspsc1zT1BM7j9BI2fd6Ada3p0FV+iesz6C3NkfPbAKnVQlRiYG1bL9N07bsB2Eni7WwvNSaFr+VOQD64/flQ==; 24:+FqY28Dx0xs2/syzyPmJn4shfRAOnjHkkXwP8PsE3v8OKJJFFt4ml7WACoav9W2tchAEXdFUURTkFsA1eLbQTZoTeitgaPqB1ObGzVJTpqo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2016 15:10:35.9496 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1817 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2016 08:21:45 -0800 Cc: Gregory Mirsky , "Aditya Dogra \(addogra\)" , Mahesh Jethanandani , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:10:42 -0000 --Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" > On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) = wrote: >=20 > The other thing I want to make sure if there is any particular = configuration requirement from a BFD YANG model perspective. I = understand that you are using the fast timer in BFD to detect next-hop = IP address liveliness check. We address that configuration in the BFD = YANG model today. However, we have not addressed the issue of p2mp BFD = configuration as yet. Depending on how that discussion proceeds we might = want to look at that also. >=20 > [nitish] There is no particular requirement that we can see from BFD = YANG model perspective. As VRRP should interface with BFD as another = protocol using BFD as a means of fast failure detection of its peer. The desired behavior we're looking for in yang is ideally making use of = the groupings exported by the BFD yang module. This permits a simple = maintainable place to put BFD session parameters. There are two issues Mahesh is alluding to: 1. Multipoint is currently not in the BFD yang spec. Thus, the BFD yang = team has homework to provide support for that option to allow modules = such as a vrrp module supporting this feature to import it. 2. VRRP would only utilize this in *some* circumstances; namely the = master/backup scenario rather than each backup. Configuration state = would likely be consistent, but ti does make the operational state a bit = trickier. The session is provisioned, but may not be started - and it = may not even be *instantiated* depending on the implementation and = whether the priority of the VRRP router is lower than the first = available backup. -- Jeff --Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
    On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <nitisgup@cisco.com> = wrote:

    The other thing I want to make sure if there is any = particular configuration requirement from a BFD YANG model perspective. = I understand that you are using the fast timer in BFD to detect next-hop = IP address liveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue = of p2mp BFD configuration as yet. Depending on how that discussion = proceeds we might want to look at that also.

    [nitish] There is no particular requirement that we can = see from BFD YANG model perspective. As VRRP should interface with BFD = as another protocol using BFD as a means of fast failure detection of = its peer.

    The desired behavior we're looking for in yang is = ideally making use of the groupings exported by the BFD yang module. =  This permits a simple maintainable place to put BFD session = parameters.

    There are two issues = Mahesh is alluding to:
    1. Multipoint is currently not in the = BFD yang spec.  Thus, the BFD yang team has homework to provide = support for that option to allow modules such as a vrrp module = supporting this feature to import it.
    2. VRRP would only = utilize this in *some* circumstances; namely the master/backup scenario = rather than each backup.  Configuration state would likely be = consistent, but ti does make the operational state a bit trickier. =  The session is provisioned, but may not be started - and it may = not even be *instantiated* depending on the implementation and whether = the priority of the VRRP router is lower than the first available = backup.

    -- Jeff

    = --Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89-- From nobody Thu Jan 21 04:25:12 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693AD1B2BA9; Thu, 21 Jan 2016 04:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAOA50O3X4ye; Thu, 21 Jan 2016 04:25:07 -0800 (PST) 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 46B831A898F; Thu, 21 Jan 2016 04:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20195; q=dns/txt; s=iport; t=1453379107; x=1454588707; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ILY29tGqgI4nKiR01h764V2IntAz6u1RmfBsfloEfrQ=; b=EJY00Drk6OszqTDlzju+UzxRtreJO5/tfjF/4r8wDTLco5PeGtOhbdME tgYX0w9bP/rX4y+HcIsktn9FDcwbiCas2nJlsD8H4Hm7CiUwZj2QuPLrw KQ5UltX6uT75WHdfvRt3l5PidI02uNMsXW81pHKDLqofzTBZXTNPCKPHQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCfzaBW/5ldJa1egm5MUm0GiFGyF?= =?us-ascii?q?wENgWMmhS86AoEyOBQBAQEBAQEBgQqENAEBAQR5EAIBCBEBAgECFhIHMhQDBgg?= =?us-ascii?q?BAQQBDQUbiAAOvGsBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIY5g3CBBIQXFEUNE?= =?us-ascii?q?oN8BZJ5hAUBhUWIE4FehESDKYUxjj8BHgEBQoNmagWFVTx8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,325,1449532800"; d="scan'208,217";a="229830779" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 12:25:06 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0LCP5u5000495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 12:25:06 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Jan 2016 07:25:05 -0500 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.1104.009; Thu, 21 Jan 2016 07:25:04 -0500 From: "Pierre Francois (pifranco)" To: "Alvaro Retana (aretana)" , Chris Bowers , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Topic: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Index: AdFLymRfrf/gcWOOTVmsW4QZcyGUtgDVLR6AAVZ8DYA= Date: Thu, 21 Jan 2016 12:25:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.90.165] Content-Type: multipart/alternative; boundary="_000_D2C68BB16B20Dpifrancociscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 12:25:10 -0000 --_000_D2C68BB16B20Dpifrancociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello everyone, I would tend to agree with Alvaro on the fact that the comparison table sho= uld completely disappear from the work. More generally, comparison with other solutions should not be present in this draft, at all. The reason is that the points of comparison currently featured in the draft look quite incomplete, not taking some aspects stemming from requirements a= nd experience with FRR into account, or not discussing them deeply enough, giving the unnecess= ary feeling of a biased analysis. Adapting the draft to provide a completely thorough comparison would requir= e a substantial amount of work. Given the state of advancement of the draft, I would find it unfortunate to start such a lengthy process here and delay th= e draft further. To me, the results of such an interesting comparison work should go in a separate document fully dedicated to this task. Cheers, Pierre. From: "Alvaro Retana (aretana)" > Date: Thursday 14 January 2016 22:58 To: Chris Bowers >, "draft-= ietf-rtgwg-mrt-frr-architecture@ietf.org" > Cc: "rtgwg-chairs@ietf.org" >, "rtgwg@ietf.org" > Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 On 1/10/16, 12:16 PM, "Chris Bowers" > wrote: Chris: Hi! Thanks for the work in addressing my comments. I just have a couple of min= or comments (below). I will start the IETF Last Call. Thanks! Alvaro. =85 Major: 1. In general, I feel uncomfortable with documents making value statemen= ts related, for example, to how they perform against different solutions. = The purpose of this document should be to describe the technology, not to c= ompare against other solutions =97 that work (if wanted/needed) should be d= one in a different document. Please remove comparisons to other technology= and relative statements. Some examples: * Abstract: "MRT is also extremely computationally efficient=85computat= ion is less than the LFA computation..." As was expressed on the list, may= be CPU cycles are not that important if compared to other aspects=85 * Introduction: "Other existing or proposed solutions are partial solut= ions or have significant issues, as described below." It is ok to describe= other solutions, but please limit the description to the facts. * About the table: there are obviously other columns that could have be= en included, which means that the table is not complete. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] The abstract and introduction have been significantly revised to try = to remove value statements. I modified the comparison table and added seve= ral columns, trying to provide a factual comparison of tradeoffs based on d= ifferent metrics without making value judgements. (See the revised docume= nt or main diff above.) However, I am also willing to simply remove the ta= ble and descriptions, if that makes more sense. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am not crazy about the table. The added columns make it a little better= , but even if there are no judgements people will read into it.. I think Stewart had commented on it as well =97 I would like to see his opi= nion as well. =85 1. Operations/Management Considerations * Given that the MRT paths don't follow the shortest paths, or even pot= entially planned backup paths in the network, I think you should include so= mething about the potential impact related to capacity planning, congestion= , stretch, etc. * What about address management? Are there considerations about assign= ment and management for the additional loopbacks required for IP tunnels? * Section 15. (Applying Policy to Select from Multiple Possible Alterna= tes for FRR) basically says that policy can be applied "to select the best = alternate from those provided by MRT and other FRR technologies". You're r= ight to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many o= f the potential criteria that one might take into account when evaluating d= ifferent alternates for selection". What are the considerations that shoul= d be taken into account when comparing between MRT and others? Are the cri= teria and requirements outlined in I-D.ietf-rtgwg-lfa-manageability applica= ble? Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-sp= ecific, should it be a Normative reference? [Note that there's a similar co= mment related to I-D.ietf-rtgwg-lfa-manageability in my review of draft-ie= tf-rtgwg-mrt-frr-algorithm.] * Applicability/Guidance for Operators * Section 4. (Maximally Redundant Trees (MRT)) clearly explains about t= he impact of not having a 2-connected network for MRT to be applicable. Se= ction 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks = about partial implementation in an area. * I think it would be important to consolidate some of that guidance (t= here's probably more) in a single place. Note that I'm not looking for a 3= 0 page extension (a la RFC6571), just some general guidance. * Given that both Sections 14 and 15 were added just in the latest vers= ion of the document, please consider taking a look at RFC5706. * [Nit] Consider making Section 15. (Applying Policy to Select from Mul= tiple Possible Alternates for FRR) a sub-section of Section 14. (Operations= and Management Considerations). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] These changes are shown in this diff: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/c36= 1f37638390a1b0364d67726367aabef203976 After those changes it looks like the reference to I-D.ietf-rtgwg-lfa-manag= eability is no longer needed. =85 We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm] Just taking advantage of this text to say that you may want to edit away th= e use of "we" in the text. "We" who? Most of the statements may be cleare= r in the third person. Just a style nit.. --_000_D2C68BB16B20Dpifrancociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9D01B31D7203AE4F9CB7B2A0C6FD8581@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    Hello everyone,

    I would tend to agree with Alvaro on the fa= ct that the comparison table should

    completely disappear from the work. More ge= nerally, comparison with other

    solutions should not be present in this dra= ft, at all. 


    The reason is that the points of comparison= currently featured in the draft

    look quite incomplete, not taking some aspe= cts stemming from requirements and experience with

    FRR into account, or not discussing them de= eply enough, giving the unnecessary

    feeling of a biased analysis. <= /p>


    Adapting the draft to provide a completely = thorough comparison would require a

    substantial amount of work. Given the state= of advancement of the draft, I

    would find it unfortunate to start such a l= engthy process here and delay the 

    draft further.


    To me, the results of such an interesting c= omparison work should go in a

    separate document fully dedicated to this t= ask.


    Cheers,


    Pierre.


    From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Thursday 14 January 2016 22:5= 8
    To: Chris Bowers <cbowers@juniper.net>, "draft-ietf-rtgwg-mrt-frr= -architecture@ietf.org" <draft-ietf-rtgwg-mrt-frr-architecture@ietf.org<= /a>>
    Cc: "    rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
    Subject: Re: AD Review of draft-iet= f-rtgwg-mrt-frr-architecture-08

    On 1/10/16, 12:16 PM, "Chris Bowers" <cbowers@juniper.net> wrote:

    Chris:

    Hi!

    Thanks for the work in addressing my comments.  I just have a cou= ple of minor comments (below).  I will start the IETF Last Call.

    Thanks!

    Alvaro.


    =85
    Major:
    1. In general= , I feel uncomfortable with documents making value statements related, for = example, to how they perform against different solutions.  The purpose= of this document should be to describe the technology, not to compare against other solutions =97 that work (if wante= d/needed) should be done in a different document.  Please remove compa= risons to other technology and relative statements.  Some examples:
    • Abstract: = "MRT is also extremely computationally efficient=85computation is less= than the LFA computation..."  As was expressed on the list, mayb= e CPU cycles are not that important if compared to other aspects=85
    • Introduction: "Other existing or proposed solutions are p= artial solutions or have significant issues, as described below."=  It is ok to describe other solutions, but please limit the descripti= on to the facts.
    • About the = table: there are obviously other columns that could have been included, whi= ch means that the table is not complete.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [C= B]  The abstract and introduction have been significantly revised to t= ry to remove value statements.  I modified the comparison table and ad= ded several columns, trying to provide a factual comparison of tradeoffs based on different metrics without making value ju= dgements.   (See the revised document or main diff above.)  = However, I am also willing to simply remove the table and descriptions, if = that makes more sense.
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    I am not crazy about the table.   The added columns make it a lit= tle better, but even if there are no judgements people will read into it.. =  

    I think Stewart had commented on it as well =97 I would like to see hi= s opinion as well.

    =85
    1. Operations= /Management Considerations
    • Given that the MRT paths do= n't follow the shortest paths, or even potentially planned backup paths in = the network, I think you should include something about the potential impac= t related to capacity planning, congestion, stretch, etc.
    • What abo= ut address management?  Are there considerations about assignment and = management for the additional loopbacks required for IP tunnels?
    • Se= ction 15. (Applying Policy to Select from Multiple Possible Alternates= for FRR) basically says that policy can be applied "to select the bes= t alternate from those provided by MRT and other FRR technologies"= ;.  You're right to point out that "[I-D.ietf-rtgwg-lfa-manageabili= ty] discusses many of the potential criteria that one might take into = account when evaluating different alternates for selection". &nbs= p;What are the considerations that should be taken into account when comparing between MRT and others?  Are the criteria and requirem= ents outlined in I-D.ietf-rtgwg-lfa-manageability applicable?  Ev= en though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-speci= fic, should it be a Normative reference? [Note that there's a similar comment related to  I-D.ietf-rtgwg-lfa-managea= bility in my review of draft-ietf-rtgwg-mrt-frr-algorithm.]
    • Applicabi= lity/Guidance for Operators
    • Section&nb= sp;4. (Maximally Redundant Trees (MRT)) clearly explains about the impact o= f not having a 2-connected network for MRT to be applicable.  Section&= nbsp;11.3. (MRT Alternates for Destinations Outside the MRT Island) talks about partial implementation in an area.  
    • I t= hink it would be important to consolidate some of that guidance (there's pr= obably more) in a single place.  Note that I'm not looking for a = 30 page extension (a la RFC6571), just some general guidance.
      • Given that= both Sections 14 and 15 were added just in the latest version of the docum= ent, please consider taking a look at RFC5706.
      • [Nit] Consider making Secti= on 15. (Applying Policy to Select from Multiple Possible Alternates fo= r FRR) a sub-section of Section 14. (Operations and Management Conside= rations).
      = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [C= B] These changes are shown in this diff:

    After those changes it looks like the reference to I-D.ietf-rtgwg= -lfa-manageability is no longer needed.

    =85
    =    We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algor= ithm]

    Just taking advantage of this text to say that you may want to edit aw= ay the use of "we" in the text.  "We" who?  M= ost of the statements may be clearer in the third person.  Just a styl= e nit..
     --_000_D2C68BB16B20Dpifrancociscocom_-- From nobody Thu Jan 21 04:34:38 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8579B1B2D14; Thu, 21 Jan 2016 04:34:37 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPGF6hOKqnKz; Thu, 21 Jan 2016 04:34:34 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136C01B2F83; Thu, 21 Jan 2016 04:34:34 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id r129so170249753wmr.0; Thu, 21 Jan 2016 04:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=ZkA/PikIv7vPTnfhSS3DLG+jpw85/5bpwjRsfKX6DtY=; b=Th6+bEVga+rdiaKnnIDVBd7dYXS9zM2fWpp7nlnrET8Qny/lIe1CQB4OXQhrEwjA2L 2BzBQbmUkzriQx8Zs3bLDw9D0mUYiCO3KIlgwhA7R9skxQau1z5bupZ0tkomQRxS2d6u KqVZu+uFXHyW/8q7FtLO/MgQJhISENzPu2YzcJ99HEW9pLyfWobLKiSpg+t9yKrb4M8J xNxRo25djIqZnNJova7YMDZffq7SpZzoYHRq+vsJysStDx5PDCGl/9BWjrkOBjvMUXYY c6CRjfpmPEWDYgFCFO/Tb68Y7BkVRxBe0WwCM1vc4TAigXEyIgmcmOJW+1Pg4H37fLpX FdfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=ZkA/PikIv7vPTnfhSS3DLG+jpw85/5bpwjRsfKX6DtY=; b=nAPiv/txF74W1QghwEyglLOojfHqWqDnt7YxXf6QGAjIB7Ie/yz6YQW8UrZkjKC4s3 gjeW8rUZT5YDhiH2rhVQhsLhPD/2a22xjoAjmlaNkI1Iuq3Wro1oNSE4OUHnyrnkUq4y 9BUmbeOrxxaA7fxA80ANNYJi8VvScgv1ds5ampAxzRUQNpFii5cMah/t4VCpuQNb+hOn 1pw9O+LM/O5JpRb/8GrdP0fGokohH5pd94GMsP+DMxn/xCS4T9gmE/0JGmbKGuZ9s4o4 G6qdLW3GXovQgDPs2yPpCiXY1DmHa2BebEehmwr0djwWU3ZlnmnRsmsLM71Sm8JgOu6s F7wA== X-Gm-Message-State: AG10YORPsquw5pyxGXdpSYswHSaWv+D3PDc1hbBUbxCWXf3wfwvVtGzHo9rT2XnqZMu5sw== X-Received: by 10.28.142.8 with SMTP id q8mr9853491wmd.47.1453379672589; Thu, 21 Jan 2016 04:34:32 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id ha9sm1323007wjc.3.2016.01.21.04.34.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 04:34:31 -0800 (PST) Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 To: "Pierre Francois (pifranco)" , "Alvaro Retana (aretana)" , Chris Bowers , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" References: From: Stewart Bryant Message-ID: <56A0D05A.6020608@gmail.com> Date: Thu, 21 Jan 2016 12:34:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080004000108020109050905" Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 12:34:37 -0000 This is a multi-part message in MIME format. --------------080004000108020109050905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 Stewart On 21/01/2016 12:25, Pierre Francois (pifranco) wrote: > Hello everyone, > > I would tend to agree with Alvaro on the fact that the comparison > table should > > completely disappear from the work. More generally, comparison with other > > solutions should not be present in this draft, at all. > > > The reason is that the points of comparison currently featured in the > draft > > look quite incomplete, not taking some aspects stemming from > requirements and experience with > > FRR into account, or not discussing them deeply enough, giving the > unnecessary > > feeling of a biased analysis. > > > Adapting the draft to provide a completely thorough comparison would > require a > > substantial amount of work. Given the state of advancement of the draft, I > > would find it unfortunate to start such a lengthy process here and > delay the > > draft further. > > > To me, the results of such an interesting comparison work should go in a > > separate document fully dedicated to this task. > > > Cheers, > > > Pierre. > > > From: "Alvaro Retana (aretana)" > > Date: Thursday 14 January 2016 22:58 > To: Chris Bowers >, > "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org > " > > > Cc: "rtgwg-chairs@ietf.org " > >, > "rtgwg@ietf.org " > > Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 > > On 1/10/16, 12:16 PM, "Chris Bowers" > wrote: > > Chris: > > Hi! > > Thanks for the work in addressing my comments. I just have a couple > of minor comments (below). I will start the IETF Last Call. > > Thanks! > > Alvaro. > > > … > > Major: > > 1. In general, I feel uncomfortable with documents making value > statements related, for example, to how they perform against > different solutions. The purpose of this document should be > to describe the technology, not to compare against other > solutions — that work (if wanted/needed) should be done in a > different document. Please remove comparisons to other > technology and relative statements. Some examples: > > * Abstract: "MRT is also extremely computationally > efficient…computation is less than the LFA computation..." As > was expressed on the list, maybe CPU cycles are not that > important if compared to other aspects… > * Introduction: "Other existing or proposed solutions are > partial solutions or have significant issues, as described > below." It is ok to describe other solutions, but please > limit the description to the facts. > > * About the table: there are obviously other columns that could > have been included, which means that the table is not complete. > > ========== > [CB] The abstract and introduction have been significantly > revised to try to remove value statements. I modified the > comparison table and added several columns, trying to provide a > factual comparison of tradeoffs based on different metrics without > making value judgements. (See the revised document or main diff > above.) However, I am also willing to simply remove the table and > descriptions, if that makes more sense. > ========== > > > I am not crazy about the table. The added columns make it a little > better, but even if there are no judgements people will read into it.. > > I think Stewart had commented on it as well — I would like to see his > opinion as well. > > … > > 4. Operations/Management Considerations > > * Given that the MRT paths don't follow the shortest paths, or > even potentially planned backup paths in the network, I think > you should include something about the potential impact > related to capacity planning, congestion, stretch, etc. > * What about address management? Are there considerations about > assignment and management for the additional loopbacks > required for IP tunnels? > * Section 15. (Applying Policy to Select from Multiple Possible > Alternates for FRR) basically says that policy can be applied > "to select the best alternate from those provided by MRT and > other FRR technologies". You're right to point out that > "[I-D.ietf-rtgwg-lfa-manageability] discusses many of > the potential criteria that one might take into account when > evaluating different alternates for selection". What are the > considerations that should be taken into account when > comparing between MRT and others? Are the criteria and > requirements outlined in I-D.ietf-rtgwg-lfa-manageability > applicable? Even though I-D.ietf-rtgwg-lfa-manageability is > intended to be LFA-specific, should it be a Normative > reference? [Note that there's a similar comment related > to I-D.ietf-rtgwg-lfa-manageability in my review > of draft-ietf-rtgwg-mrt-frr-algorithm.] > * Applicability/Guidance for Operators > > * Section 4. (Maximally Redundant Trees (MRT)) clearly explains > about the impact of not having a 2-connected network for MRT > to be applicable. Section 11.3. (MRT Alternates for > Destinations Outside the MRT Island) talks about partial > implementation in an area. > * I think it would be important to consolidate some of that > guidance (there's probably more) in a single place. Note > that I'm not looking for a 30 page extension (a la RFC6571), > just some general guidance. > > * Given that both Sections 14 and 15 were added just in the > latest version of the document, please consider taking a look > at RFC5706. > * [Nit] Consider making Section 15. (Applying Policy to Select > from Multiple Possible Alternates for FRR) a sub-section of > Section 14. (Operations and Management Considerations). > > ========== > [CB] These changes are shown in this diff: > _https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/c361f37638390a1b0364d67726367aabef203976_ > > > After those changes it looks like the reference > to I-D.ietf-rtgwg-lfa-manageability is no longer needed. > > … > > We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm] > > > Just taking advantage of this text to say that you may want to edit > away the use of "we" in the text. "We" who? Most of the statements > may be clearer in the third person. Just a style nit.. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --------------080004000108020109050905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1

    Stewart


    On 21/01/2016 12:25, Pierre Francois (pifranco) wrote:
    Hello everyone,

    I would tend to agree with Alvaro on the fact that the comparison table should

    completely disappear from the work. More generally, comparison with other

    solutions should not be present in this draft, at all. 


    The reason is that the points of comparison currently featured in the draft

    look quite incomplete, not taking some aspects stemming from requirements and experience with

    FRR into account, or not discussing them deeply enough, giving the unnecessary

    feeling of a biased analysis. 


    Adapting the draft to provide a completely thorough comparison would require a

    substantial amount of work. Given the state of advancement of the draft, I

    would find it unfortunate to start such a lengthy process here and delay the 

    draft further.


    To me, the results of such an interesting comparison work should go in a

    separate document fully dedicated to this task.


    Cheers,


    Pierre.


    From: "Alvaro Retana (aretana)" <aretana@cisco.com>
    Date: Thursday 14 January 2016 22:58
    To: Chris Bowers <cbowers@juniper.net>, "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" <draft-ietf-rtgwg-mrt-frr-architecture@ietf.org>
    Cc: "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
    Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08

    On 1/10/16, 12:16 PM, "Chris Bowers" <cbowers@juniper.net> wrote:

    Chris:

    Hi!

    Thanks for the work in addressing my comments.  I just have a couple of minor comments (below).  I will start the IETF Last Call.

    Thanks!

    Alvaro.


    …
    Major:
    1. In general, I feel uncomfortable with documents making value statements related, for example, to how they perform against different solutions.  The purpose of this document should be to describe the technology, not to compare against other solutions — that work (if wanted/needed) should be done in a different document.  Please remove comparisons to other technology and relative statements.  Some examples:
    • Abstract: "MRT is also extremely computationally efficient…computation is less than the LFA computation..."  As was expressed on the list, maybe CPU cycles are not that important if compared to other aspects…
    • Introduction: "Other existing or proposed solutions are partial solutions or have significant issues, as described below."  It is ok to describe other solutions, but please limit the description to the facts.
    • About the table: there are obviously other columns that could have been included, which means that the table is not complete.
    ==========
    [CB]  The abstract and introduction have been significantly revised to try to remove value statements.  I modified the comparison table and added several columns, trying to provide a factual comparison of tradeoffs based on different metrics without making value judgements.   (See the revised document or main diff above.)  However, I am also willing to simply remove the table and descriptions, if that makes more sense.
    ==========

    I am not crazy about the table.   The added columns make it a little better, but even if there are no judgements people will read into it..  

    I think Stewart had commented on it as well — I would like to see his opinion as well.

    …
    1. Operations/Management Considerations
    • Given that the MRT paths don't follow the shortest paths, or even potentially planned backup paths in the network, I think you should include something about the potential impact related to capacity planning, congestion, stretch, etc.
      •
    • What about address management?  Are there considerations about assignment and management for the additional loopbacks required for IP tunnels?
    • Section 15. (Applying Policy to Select from Multiple Possible Alternates for FRR) basically says that policy can be applied "to select the best alternate from those provided by MRT and other FRR technologies".  You're right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many of the potential criteria that one might take into account when evaluating different alternates for selection".  What are the considerations that should be taken into account when comparing between MRT and others?  Are the criteria and requirements outlined in I-D.ietf-rtgwg-lfa-manageability applicable?  Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-specific, should it be a Normative reference? [Note that there's a similar comment related to  I-D.ietf-rtgwg-lfa-manageability in my review of draft-ietf-rtgwg-mrt-frr-algorithm.]
    • Applicability/Guidance for Operators
    • Section 4. (Maximally Redundant Trees (MRT)) clearly explains about the impact of not having a 2-connected network for MRT to be applicable.  Section 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks about partial implementation in an area.  
    • I think it would be important to consolidate some of that guidance (there's probably more) in a single place.  Note that I'm not looking for a 30 page extension (a la RFC6571), just some general guidance.
    • Given that both Sections 14 and 15 were added just in the latest version of the document, please consider taking a look at RFC5706.
    • [Nit] Consider making Section 15. (Applying Policy to Select from Multiple Possible Alternates for FRR) a sub-section of Section 14. (Operations and Management Considerations).
    ==========
    [CB] These changes are shown in this diff:

    After those changes it looks like the reference to I-D.ietf-rtgwg-lfa-manageability is no longer needed.

    …
       We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm]

    Just taking advantage of this text to say that you may want to edit away the use of "we" in the text.  "We" who?  Most of the statements may be clearer in the third person.  Just a style nit..
     

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

    --------------080004000108020109050905-- From nobody Thu Jan 21 07:14:11 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766FF1B31C1; Thu, 21 Jan 2016 07:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gGD9aqIuNSY; Thu, 21 Jan 2016 07:14:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308161B31B5; Thu, 21 Jan 2016 07:14:03 -0800 (PST) Received: from CO2PR05MB619.namprd05.prod.outlook.com (10.141.198.148) by CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 21 Jan 2016 15:13:42 +0000 Received: from CO2PR05MB619.namprd05.prod.outlook.com ([10.141.198.148]) by CO2PR05MB619.namprd05.prod.outlook.com ([10.141.198.148]) with mapi id 15.01.0361.006; Thu, 21 Jan 2016 15:13:43 +0000 From: Chris Bowers To: Stewart Bryant , "Pierre Francois (pifranco)" , "Alvaro Retana (aretana)" , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" Subject: RE: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Topic: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Index: AQHRTxa8llP1J7ydZ0W7J7IIYanxsZ8F71UAgAACpwCAACD58A== Date: Thu, 21 Jan 2016 15:13:43 +0000 Message-ID: References: <56A0D05A.6020608@gmail.com> In-Reply-To: <56A0D05A.6020608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; CO2PR05MB618; 5:vmkCXCB0ttAaQ4M98YWRzSRC4+wGiU6O0wQPkZyus+VE79V1tS9caadrvzNh6wrAp0nXBI5xkZN+iHOQbVTOZMTSSq0EWAby6T5ufHHRxS8gT0cDeioCB8knrl2i4Fz4ZTJ52DyCIyMacHUbeHTJaQ==; 24:uWL2y1OxYTnj6idgZ7uphSYz2Lj9Tx9uD0sOjZEIA+mb9s8LibQYID2OwxhzqK5KiOqsQa/eIkoqLt2NeOdphz0hOG/N/1GWwg3cEetVg4g= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB618; x-ms-office365-filtering-correlation-id: 2a609543-7f69-4da0-39c5-08d32275736b x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:CO2PR05MB618; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB618; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(189002)(199003)(377454003)(51914003)(53754006)(164054003)(24454002)(105586002)(19625215002)(19300405004)(86362001)(189998001)(230783001)(66066001)(40100003)(5008740100001)(2501003)(77096005)(97736004)(5003600100002)(5002640100001)(16236675004)(54356999)(50986999)(10400500002)(87936001)(76176999)(5001770100001)(122556002)(33656002)(102836003)(101416001)(586003)(106116001)(93886004)(74316001)(5001960100002)(106356001)(2950100001)(76576001)(19617315012)(2906002)(790700001)(15975445007)(2900100001)(19580395003)(1096002)(19580405001)(1220700001)(3846002)(81156007)(99286002)(6116002)(4326007)(92566002)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB618; H:CO2PR05MB619.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR05MB619A2E6F5EDDC6FD8BBBB6DA9C30CO2PR05MB619namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 15:13:43.1046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB618 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 15:14:10 -0000 --_000_CO2PR05MB619A2E6F5EDDC6FD8BBBB6DA9C30CO2PR05MB619namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pierre and Stewart, Thanks for the feedback. I will remove the comparison table and text from = the next revision. Alvaro, Would you like a new revision without the comparison table sometime before = the IESG telechat on 2/4, or should I wait to incorporate this change with = other potential changes requested by the IESG? I will remove the unused reference to I-D.ietf-rtgwg-lfa-manageability. With respect to the use of "we", "we" generally refers to the authors. In = general, we use "we" to explain why we (the authors) are explaining things = in a particular order. I did a quick search for the usage of "we note" a= nd "we consider" in RFCs, and it seems fairly common to use we in this way.= The usages of "we" could be changed to passive or imperative form, but = in many cases I think it would make the text more awkward. Thanks, Chris From: Stewart Bryant [mailto:stewart.bryant@gmail.com] Sent: Thursday, January 21, 2016 6:35 AM To: Pierre Francois (pifranco) ; Alvaro Retana (aretana= ) ; Chris Bowers ; draft-ietf-rtgwg= -mrt-frr-architecture@ietf.org Cc: rtgwg-chairs@ietf.org; rtgwg@ietf.org Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 +1 Stewart On 21/01/2016 12:25, Pierre Francois (pifranco) wrote: Hello everyone, I would tend to agree with Alvaro on the fact that the comparison table sho= uld completely disappear from the work. More generally, comparison with other solutions should not be present in this draft, at all. The reason is that the points of comparison currently featured in the draft look quite incomplete, not taking some aspects stemming from requirements a= nd experience with FRR into account, or not discussing them deeply enough, giving the unnecess= ary feeling of a biased analysis. Adapting the draft to provide a completely thorough comparison would requir= e a substantial amount of work. Given the state of advancement of the draft, I would find it unfortunate to start such a lengthy process here and delay th= e draft further. To me, the results of such an interesting comparison work should go in a separate document fully dedicated to this task. Cheers, Pierre. From: "Alvaro Retana (aretana)" > Date: Thursday 14 January 2016 22:58 To: Chris Bowers >, "draft-= ietf-rtgwg-mrt-frr-architecture@ietf.org" > Cc: "rtgwg-chairs@ietf.org" >, "rtgwg@ietf.org" > Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 On 1/10/16, 12:16 PM, "Chris Bowers" > wrote: Chris: Hi! Thanks for the work in addressing my comments. I just have a couple of min= or comments (below). I will start the IETF Last Call. Thanks! Alvaro. ... Major: 1. In general, I feel uncomfortable with documents making value state= ments related, for example, to how they perform against different solutions= . The purpose of this document should be to describe the technology, not t= o compare against other solutions - that work (if wanted/needed) should be = done in a different document. Please remove comparisons to other technolog= y and relative statements. Some examples: * Abstract: "MRT is also extremely computationally efficient...computation = is less than the LFA computation..." As was expressed on the list, maybe C= PU cycles are not that important if compared to other aspects... * Introduction: "Other existing or proposed solutions are partial solutions= or have significant issues, as described below." It is ok to describe oth= er solutions, but please limit the description to the facts. * About the table: there are obviously other columns that could have been i= ncluded, which means that the table is not complete. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] The abstract and introduction have been significantly revised to try = to remove value statements. I modified the comparison table and added seve= ral columns, trying to provide a factual comparison of tradeoffs based on d= ifferent metrics without making value judgements. (See the revised docume= nt or main diff above.) However, I am also willing to simply remove the ta= ble and descriptions, if that makes more sense. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am not crazy about the table. The added columns make it a little better= , but even if there are no judgements people will read into it.. I think Stewart had commented on it as well - I would like to see his opini= on as well. ... 4. Operations/Management Considerations * Given that the MRT paths don't follow the shortest paths, or even potenti= ally planned backup paths in the network, I think you should include someth= ing about the potential impact related to capacity planning, congestion, st= retch, etc. * What about address management? Are there considerations about assignment= and management for the additional loopbacks required for IP tunnels? * Section 15. (Applying Policy to Select from Multiple Possible Alternates = for FRR) basically says that policy can be applied "to select the best alte= rnate from those provided by MRT and other FRR technologies". You're right= to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many of th= e potential criteria that one might take into account when evaluating diffe= rent alternates for selection". What are the considerations that should be= taken into account when comparing between MRT and others? Are the criteri= a and requirements outlined in I-D.ietf-rtgwg-lfa-manageability applicable?= Even though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-specif= ic, should it be a Normative reference? [Note that there's a similar commen= t related to I-D.ietf-rtgwg-lfa-manageability in my review of draft-ietf-r= tgwg-mrt-frr-algorithm.] * Applicability/Guidance for Operators * Section 4. (Maximally Redundant Trees (MRT)) clearly explains about the i= mpact of not having a 2-connected network for MRT to be applicable. Sectio= n 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks abou= t partial implementation in an area. * I think it would be important to consolidate some of that guidance (there= 's probably more) in a single place. Note that I'm not looking for a 30 pa= ge extension (a la RFC6571), just some general guidance. * Given that both Sections 14 and 15 were added just in the latest version = of the document, please consider taking a look at RFC5706. * [Nit] Consider making Section 15. (Applying Policy to Select from Multipl= e Possible Alternates for FRR) a sub-section of Section 14. (Operations and= Management Considerations). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] These changes are shown in this diff: https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture/commit/c36= 1f37638390a1b0364d67726367aabef203976 After those changes it looks like the reference to I-D.ietf-rtgwg-lfa-manag= eability is no longer needed. ... We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm] Just taking advantage of this text to say that you may want to edit away th= e use of "we" in the text. "We" who? Most of the statements may be cleare= r in the third person. Just a style nit.. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_CO2PR05MB619A2E6F5EDDC6FD8BBBB6DA9C30CO2PR05MB619namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Pierre and Stewart,=

     

    Thanks for the feedback.  I will= remove the comparison table and text from the next revision. 

     

    Alvaro, 

     

    Would you like a new revision without= the comparison table sometime before the IESG telechat on 2/4, or should I= wait to incorporate this change with other potential changes requested by the IESG?

     

    I will remove the unused reference to= I-D.ietf-rtgwg-lfa-manageability.

     

    With respect to the use of “we&= #8221;, “we” generally refers to the authors.  In general,= we use “we” to explain why we (the authors) are explaining thi= ngs in a particular order.    I did a quick search for the usage of “we n= ote” and ”we consider” in RFCs, and it seems fairly commo= n to use we in this way.    The usages of “we” c= ould be changed to passive or imperative form, but in many cases I think it= would make the text more awkward.

     

    Thanks,

    Chris

     

     

    From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
    Sent: Thursday, January 21, 2016 6:35 AM
    To: Pierre Francois (pifranco) <pifranco@cisco.com>; Alvaro Re= tana (aretana) <aretana@cisco.com>; Chris Bowers <cbowers@juniper.= net>; draft-ietf-rtgwg-mrt-frr-architecture@ietf.org
    Cc: rtgwg-chairs@ietf.org; rtgwg@ietf.org
    Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08

     

    +1

    Stewart

    On 21/01/2016 12:25, Pierre Francois (pifranco) wrot= e:

    Hello everyone,

     

    I would tend to agree with Al= varo on the fact that the comparison table should

    completely disappear from the= work. More generally, comparison with other

    solutions should not be prese= nt in this draft, at all. 

     

    The reason is that the points= of comparison currently featured in the draft

    look quite incomplete, not ta= king some aspects stemming from requirements and experience with=

    FRR into account, or not disc= ussing them deeply enough, giving the unnecessary

    feeling of a biased analysis.=  

     

    Adapting the draft to provide= a completely thorough comparison would require a

    substantial amount of work. G= iven the state of advancement of the draft, I

    would find it unfortunate to = start such a lengthy process here and delay the 

    draft further.

     

    To me, the results of such an= interesting comparison work should go in a

    separate document fully dedic= ated to this task.

     

    Cheers,

     

    Pierre.

     

    From: "Alvaro Retana (aretana)" <aretana@cisco.com>
    Date: Thursday 14 January 2016 22:58
    To: Chris Bowers <cbowers@= juniper.net>, "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" = <draft= -ietf-rtgwg-mrt-frr-architecture@ietf.org>
    Cc: "rtgwg-chairs@ietf= .org" <rtgwg-chairs@ie= tf.org>, "rtgwg@ietf.org&= quot; <rtgwg@ietf.org>
    Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08

     

    On 1/10/16, 12:16 PM, "Chris Bowers" <= cbowers@juniper.net> wrote:

     

    Chris:

     

    Hi!

     

    Thanks for the work in addressing my comments. &nbs= p;I just have a couple of minor comments (below).  I will start the IE= TF Last Call.

     

    Thanks!

     

    Alvaro.

     

     

    …

    Major:

    1.       In general, I feel uncomfortable with docum= ents making value statements related, for example, to how they perform agai= nst different solutions.  The purpose of this document should be to describe the technology, not to compare against othe= r solutions — that work (if wanted/needed) should be done in a differ= ent document.  Please remove comparisons to other technology and relat= ive statements.  Some examples:

    · Abstract: "MRT is also extremely compu= tationally efficient…computation is less than the LFA computation...&= quot;  As was expressed on the list, maybe CPU cycles are not that important if compared to other aspects…

    · Introduction: "Other existing or propo= sed solutions are partial solutions or have significant issues, as des= cribed below."  It is ok to describe other solutions, but please limit the description to the facts. <= /p>

    · About the table: there are obviously other = columns that could have been included, which means that the table is not co= mplete.

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

    [CB]  The abstract and introduct= ion have been significantly revised to try to remove value statements. = ; I modified the comparison table and added several columns, trying to provide a factual comparison of tradeoffs based on different met= rics without making value judgements.   (See the revised document= or main diff above.)  However, I am also willing to simply remove the= table and descriptions, if that makes more sense.

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

     

    I am not crazy about the table.   The added co= lumns make it a little better, but even if there are no judgements people w= ill read into it..  

     

    I think Stewart had commented on it as well —= I would like to see his opinion as well.

     

    …

    4.       Operations/Management Considerations

    · Given that the MRT paths don't follow the s= hortest paths, or even potentially planned backup paths in the network, I t= hink you should include something about the potential impact related to capacity planning, congestion, stretch, etc.

    · What about address management?  Are th= ere considerations about assignment and management for the additional loopb= acks required for IP tunnels?

    · Section 15. (Applying Policy to Select= from Multiple Possible Alternates for FRR) basically says that policy can = be applied "to select the best alternate from those provided by MRT and other FRR technologies".  You're right = to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many o= f the potential criteria that one might take into account when evaluat= ing different alternates for selection".  What are the consi= derations that should be taken into account when comparing between MRT and others? &= nbsp;Are the criteria and requirements outlined in I-D.ietf-rtgwg-lfa-= manageability applicable?  Even though I-D.ietf-rtgwg-lfa-managea= bility is intended to be LFA-specific, should it be a Normative reference? [Note that there's a similar comment related to&nbs= p; I-D.ietf-rtgwg-lfa-manageability in my review of draft-ietf-rt= gwg-mrt-frr-algorithm.]

    · Applicability/Guidance for Operators

    · Section 4. (Maximally Redundant Trees = (MRT)) clearly explains about the impact of not having a 2-connected networ= k for MRT to be applicable.  Section 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks about partial implementatio= n in an area.  

    · I think it would be important to consolidat= e some of that guidance (there's probably more) in a single place.  No= te that I'm not looking for a 30 page extension (a la RFC6571), just some general guidance.

    · Given that both Sections 14 and 15 were add= ed just in the latest version of the document, please consider taking a loo= k at RFC5706.

    · [Nit] Consider making Section 15. (App= lying Policy to Select from Multiple Possible Alternates for FRR) a sub-sec= tion of Section 14. (Operations and Management Considerations).=

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

    [CB] These changes are shown in this = diff:

     

    After those changes it looks like the reference to&= nbsp;I-D.ietf-rtgwg-lfa-manageability is no longer needed.

     

    …

       We note that the computations in [I-D.ietf-rt= gwg-mrt-frr-algorithm]

     

    Just taking advantage of this text to say that you = may want to edit away the use of "we" in the text.  "We= " who?  Most of the statements may be clearer in the third person= .  Just a style nit..




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

     

    --_000_CO2PR05MB619A2E6F5EDDC6FD8BBBB6DA9C30CO2PR05MB619namprd_-- From nobody Thu Jan 21 08:46:20 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1C1B32DE; Thu, 21 Jan 2016 08:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SouHjGmO4NXH; Thu, 21 Jan 2016 08:46:16 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102A31B32DD; Thu, 21 Jan 2016 08:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21198; q=dns/txt; s=iport; t=1453394776; x=1454604376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TqltZ7BTJknSLnhr2KH80nJ5Mj8gAlf/zQcx9ZBT148=; b=KEJ2+nrjq+PXEkNK4SlQxyEi6FkIEMoS/AUSbV/KP1IRrv8T55v6s0qN w9Pv+tdzg4aCQPyBH6DRjBygCQLyaOEahUvgx8WEXoDjaZBIk2jwSUm6j VYOFEPTreJSVT/fXnp6lAGXg+rs1oUJyyj+GSapYj+KME+z7dZXTgRpuW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgAyCqFW/5FdJa1egm5MUm0GiFGyH?= =?us-ascii?q?gENgWKGDwKBPTgUAQEBAQEBAYEKhDUBAQQtTBACAQgOBCYHBzIUAw4BAQQBDQW?= =?us-ascii?q?IG71pAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYY4AYRziQgFjWGFEYQDAYg3hR+BX?= =?us-ascii?q?oREiFeFa4hQAR4BAUKBfhiBUGqGJ3wBAQE?= X-IronPort-AV: E=Sophos; i="5.22,326,1449532800"; d="scan'208,217"; a="69241213" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 16:46:15 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u0LGkE7p011441 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 16:46:14 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Jan 2016 10:46:14 -0600 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.1104.009; Thu, 21 Jan 2016 10:46:14 -0600 From: "Alvaro Retana (aretana)" To: Chris Bowers , Stewart Bryant , "Pierre Francois (pifranco)" , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" Subject: Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Topic: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08 Thread-Index: AdFLymRfrf/gcWOOTVmsW4QZcyGUtgDVLR6AAVZ8DYAAAFWuAAAFjuqA///GAAA= Date: Thu, 21 Jan 2016 16:46:14 +0000 Message-ID: References: <56A0D05A.6020608@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_D2C67457109D49aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:46:18 -0000 --_000_D2C67457109D49aretanaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 1/21/16, 10:13 AM, "Chris Bowers" > wrote: Chris: Hi! Pierre and Stewart, Thanks for the feedback. I will remove the comparison table and text from = the next revision. Alvaro, Would you like a new revision without the comparison table sometime before = the IESG telechat on 2/4, or should I wait to incorporate this change with = other potential changes requested by the IESG? Yes, please post a new revision. We need it by the end of next week (Jan/2= 9). I haven't seen other IETF LC comments yet, but you may want to wait ju= st in case (and still publish an update by the 29th). I will remove the unused reference to I-D.ietf-rtgwg-lfa-manageability. With respect to the use of "we", "we" generally refers to the authors. In = general, we use "we" to explain why we (the authors) are explaining things = in a particular order. I did a quick search for the usage of "we note" a= nd "we consider" in RFCs, and it seems fairly common to use we in this way.= The usages of "we" could be changed to passive or imperative form, but = in many cases I think it would make the text more awkward. Yeah, as I said, it is a style nit. Given that this is a Standards Track d= ocument (ie. A rough consensus document), it is a little awkward that "we" = refers to the authors and not the WG, or the IETF.. Again, just a style ni= t.. Thanks! Alvaro. --_000_D2C67457109D49aretanaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    On 1/21/16, 10:13 AM, "Chris Bowers" <cbowers@juniper.net> wrote:

    Chris:

    Hi!

    Pierre and Stewart,

     

    Thanks for the feedback.  I wi= ll remove the comparison table and text from the next revision. 

     

    Alvaro, 

     

    Would you like a new revision witho= ut the comparison table sometime before the IESG telechat on 2/4, or should= I wait to incorporate this change with other potential changes requested by the IESG?

    Yes, please post a new revision.  We need it by the end of next w= eek (Jan/29).  I haven't seen other IETF LC comments yet, but you may = want to wait just in case (and still publish an update by the 29th).

    I will remove the unused reference = to I-D.ietf-rtgwg-lfa-manageability.

     

    With respect to the use of “w= e”, “we” generally refers to the authors.  In genera= l, we use “we” to explain why we (the authors) are explaining t= hings in a particular order.    I did a quick search for the usag= e of “we note” and ”we consider” in RFCs, and it se= ems fairly common to use we in this way.    The usages of &#= 8220;we” could be changed to passive or imperative form, but in many = cases I think it would make the text more awkward.

    Yeah, as I said, it is a style nit.  Given that this is a Standar= ds Track document (ie. A rough consensus document), it is a little awkward = that "we" refers to the authors and not the WG, or the IETF.. &nb= sp;Again, just a style nit..

    Thanks!

    Alvaro.
    --_000_D2C67457109D49aretanaciscocom_-- From nobody Thu Jan 21 10:56:45 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A461A8A6C; Thu, 21 Jan 2016 10:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ3n2fYDGJRg; Thu, 21 Jan 2016 10:56:40 -0800 (PST) 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 A72B41A8A68; Thu, 21 Jan 2016 10:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8375; q=dns/txt; s=iport; t=1453402600; x=1454612200; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z6eg6J2pxk5OYdWjI0tJyOf1evLN8ddWGF8XExQq7/M=; b=L2CMVmoJ8GUUiFR1tW6p8RrPh71dCWveaEazgYBLdsdSPIQNQcaSH+ID 6uscltO6pwwZZy8HlKnV5bMAVCgP8pvZivyn2df31zFu3QfFQy/TKJe8I Ut6ATLfDOKQMv3zW9I8KkrSyEEGk7XJPdxMzmJODuwfZj7vojyVwQdX6A c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgAKKaFW/5xdJa1egm5MgT8GiFGyH?= =?us-ascii?q?wENgWKGDwKBPzgUAQEBAQEBAYEKhDQBAQEEdwIQAgEIDgMDAQIoBzIUCQgCBAE?= =?us-ascii?q?NBYgbvhsBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjiEdIQUWYQbBY1hhRGEAwGNV?= =?us-ascii?q?o55jjsBHgEBQoNmaoYnfAEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,326,1449532800"; d="scan'208,217"; a="63864337" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 18:56:39 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u0LIudxf001716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 18:56:39 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Jan 2016 12:56:38 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Thu, 21 Jan 2016 12:56:38 -0600 From: "Reshad Rahman (rrahman)" To: Jeff Haas , "Nitish Gupta (nitisgup)" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgIOSG4CAAPKPAIAAwjmAgAGG3wCAAKFngIABfbcA Date: Thu, 21 Jan 2016 18:56:38 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.242.102] Content-Type: multipart/alternative; boundary="_000_D2C511E71132E6rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: Mahesh Jethanandani , "rtg-bfd@ietf.org" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:56:44 -0000 --_000_D2C511E71132E6rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BFD YANG spec doesn't currently support multipoint, what I recall is that t= he DT had agreed to wait for the multipoint draft to become RFC. I assume the YANG model in draft-liu-rtgwg-yang-vrrp would need to be modif= ied/augmented to support this capability? Regards, Reshad. From: Rtg-bfd > o= n behalf of Jeff Haas > Date: Wednesday, January 20, 2016 at 10:10 AM To: "Nitish Gupta (nitisgup)" > Cc: "Aditya Dogra (addogra)" >,= "colin@doch.org.uk" >, "rtg-bfd@ietf.org" >, "rtgwg@ietf.org" > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) > wrote: The other thing I want to make sure if there is any particular configuratio= n requirement from a BFD YANG model perspective. I understand that you are = using the fast timer in BFD to detect next-hop IP address liveliness check.= We address that configuration in the BFD YANG model today. However, we hav= e not addressed the issue of p2mp BFD configuration as yet. Depending on ho= w that discussion proceeds we might want to look at that also. [nitish] There is no particular requirement that we can see from BFD YANG m= odel perspective. As VRRP should interface with BFD as another protocol usi= ng BFD as a means of fast failure detection of its peer. The desired behavior we're looking for in yang is ideally making use of the= groupings exported by the BFD yang module. This permits a simple maintain= able place to put BFD session parameters. There are two issues Mahesh is alluding to: 1. Multipoint is currently not in the BFD yang spec. Thus, the BFD yang te= am has homework to provide support for that option to allow modules such as= a vrrp module supporting this feature to import it. 2. VRRP would only utilize this in *some* circumstances; namely the master/= backup scenario rather than each backup. Configuration state would likely = be consistent, but ti does make the operational state a bit trickier. The = session is provisioned, but may not be started - and it may not even be *in= stantiated* depending on the implementation and whether the priority of the= VRRP router is lower than the first available backup. -- Jeff --_000_D2C511E71132E6rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0EC4112B08DD5E4CAA12C12D7E55B01E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    <Speaking as individual contributor>

    BFD YANG spec doesn’t currently support multipoint, what I recal= l is that the DT had agreed to wait for the multipoint draft to become RFC.=  

    I assume the YANG model in draft-liu-rtgwg-yang-vrrp would need to be = modified/augmented to support this capability?

    Regards,
    Reshad.

    From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Je= ff Haas <jhaas@juniper.net><= br> Date: Wednesday, January 20, 2016 a= t 10:10 AM
    To: "Nitish Gupta (nitisgup)&q= uot; <nitisgup@cisco.com> Cc: "Aditya Dogra (addogra)&qu= ot; <addogra@cisco.com>, &qu= ot;colin@doch.org.uk" <colin@doch.org.uk>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
    Subject: Re: New Version Notificati= on for draft-nitish-vrrp-bfd-02.txt


    On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <<= a href=3D"mailto:nitisgup@cisco.com" class=3D"">nitisgup@cisco.com> = wrote:

    The other thing I want to make sure if there is any particu= lar configuration requirement from a BFD YANG model perspective. I understa= nd that you are using the fast timer in BFD to detect next-hop IP address l= iveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue of p= 2mp BFD configuration as yet. Depending on how that discussion proceeds we = might want to look at that also.

    [nitish] There is no particular requirement that we can see= from BFD YANG model perspective. As VRRP should interface with BFD as anot= her protocol using BFD as a means of fast failure detection of its peer.

    The desired behavior we're looking for in yang is ideally making use of the= groupings exported by the BFD yang module.  This permits a simple mai= ntainable place to put BFD session parameters.

    There are two issues Mahesh is alluding to:
    1. Multipoint is currently not in the BFD yang spec.  Thus, the B= FD yang team has homework to provide support for that option to allow modul= es such as a vrrp module supporting this feature to import it.
    2. VRRP would only utilize this in *some* circumstances; namely the ma= ster/backup scenario rather than each backup.  Configuration state wou= ld likely be consistent, but ti does make the operational state a bit trick= ier.  The session is provisioned, but may not be started - and it may not even be *instantiated* depending on th= e implementation and whether the priority of the VRRP router is lower than = the first available backup.

    -- Jeff

     --_000_D2C511E71132E6rrahmanciscocom_-- From nobody Tue Jan 26 10:36:12 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8C1B2A44 for ; Tue, 26 Jan 2016 10:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd8RB4OVrb7r for ; Tue, 26 Jan 2016 10:36:08 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.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 251B31B29ED for ; Tue, 26 Jan 2016 10:36:07 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by DM2PR05MB622.namprd05.prod.outlook.com (10.141.157.20) with Microsoft SMTP Server (TLS) id 15.1.390.13; Tue, 26 Jan 2016 18:36:05 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0390.013; Tue, 26 Jan 2016 18:36:05 +0000 From: Chris Bowers To: "rtgwg@ietf.org" Subject: guidelines for drafts in RTGWG on wiki Thread-Topic: guidelines for drafts in RTGWG on wiki Thread-Index: AdFYZy69SQY+gvI0Q0K4O/4LNaPezQ== Date: Tue, 26 Jan 2016 18:36:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; DM2PR05MB622; 5:p/TUiCvyduqtnrmRU77jd7KhKcjcvVHkxeI0QYHX042Ed8Xm8bVD+ZnqKJaM7xCvMa+r6BwbtFJ5NCzoRUzGTSkFxDP2MiRWh51VSjfL1Ux5O0iakm6vDBwOsPZHGBeYq7NntekMVBLWz0v1ZMHbeA==; 24:q5pV2LfzKsT9bLtj8LpHCxQMoenXEHUf6lKvaiA/igwFEGbZBYU0kPmH/Qi3eM9j5YU5lbOVvH33NBe8Ge/EZ+jzTYquzvfo68ZkkVu7pQ0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB622; x-ms-office365-filtering-correlation-id: bef6bdff-62a4-4291-2db0-08d3267f8cda x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(123027)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:DM2PR05MB622; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB622; x-forefront-prvs: 08331F819E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(54356999)(561944003)(15975445007)(74316001)(5001960100002)(1220700001)(3846002)(102836003)(76576001)(110136002)(1096002)(77096005)(107886002)(11100500001)(229853001)(2900100001)(2351001)(97736004)(106356001)(50986999)(5008740100001)(101416001)(586003)(105586002)(5003600100002)(19580395003)(81156007)(6116002)(99286002)(189998001)(5002640100001)(3280700002)(66066001)(87936001)(1730700002)(33656002)(2906002)(10400500002)(122556002)(450100001)(5004730100002)(92566002)(40100003)(86362001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB622; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR05MB623996C2C38E8BED3BA8CD4A9D80DM2PR05MB623namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2016 18:36:05.3620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB622 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 18:36:10 -0000 --_000_DM2PR05MB623996C2C38E8BED3BA8CD4A9D80DM2PR05MB623namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear RTGWG, Jeff and I put together the following guidelines for working on topics in t= he RTGWG charter. This might be useful for new participants. Others mays = still find it useful because it documents some aspects that are not common = to all working groups, such as requiring responses from authors regarding r= elevant IPR as part of the WG adoption poll. The guidelines can be found directly at this link: https://trac.tools.ietf.org/wg/rtgwg/trac/wiki/InCharterWork Or at a link off of the main wiki page: https://trac.tools.ietf.org/wg/rtgwg/trac/wiki There is also existing info about submitting proposals for New Work in the = Routing Area as a whole. The link above also has info about how RTGWG participants can use the Wiki = to support work in RTGWG. Thanks, Chris and Jeff --_000_DM2PR05MB623996C2C38E8BED3BA8CD4A9D80DM2PR05MB623namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Dear RTGWG,
     
    Jeff and I put together the following guidelines for working on topics= in the RTGWG charter.  This might be useful for new participants.&nbs= p; Others mays still find it useful because it documents some aspects that = are not common to all working groups, such as requiring responses from authors regarding relevant IPR as part of the W= G adoption poll.
     
    The guidelines can be found directly at this link:
     
    Or at a link off of the main wiki page:
     
    There is also existing info about submitting proposals for New Work in= the Routing Area as a whole. 
     
    The link above also has info about how RTGWG participants can use the = Wiki to support work in RTGWG.
     
    Thanks,
    Chris and Jeff
     
     --_000_DM2PR05MB623996C2C38E8BED3BA8CD4A9D80DM2PR05MB623namprd_-- From nobody Wed Jan 27 06:59:10 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABB01B3253; Tue, 26 Jan 2016 14:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYUxn2OG8lY9; Tue, 26 Jan 2016 14:22:40 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 513901B324F; Tue, 26 Jan 2016 14:22:33 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id l65so19821315wmf.3; Tue, 26 Jan 2016 14:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ck0ZAbcGJrZVAvwHk/CkhARuzk1N2mPheA0lVt6fxbk=; b=w3MRYe6W0rLx6J5in9+EzG5A+JTjYA6T6B0gqU7uh7itRzSCl3cGo8FVTbuTYniTWL ekEk3Rg194Pck3asKDyTDKFX1NRIuKjx05RidY6J5QcCEeLRfN++kD+CcBjNqMDE/bpi +EYBsPe9aI5ClMSFrBHfhCuGP87IH/XgsfhrWorH9XAv/5k3e+FAW/bIGYk2/X4+I1zw eo4FLUhaAbqSj7tCXpoZ6vIiH90tGNqF2EFx+TP8LMDqNM7Yn60SjRV2OFXPwuOIQKxu HMr9dtFwlia3heB0d5mrn3RKbmvGjeh08y8xF8pLEvPLgIEgMhl5QdHrZ4m//RRVnSrm pr8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ck0ZAbcGJrZVAvwHk/CkhARuzk1N2mPheA0lVt6fxbk=; b=i8+W8u3nnl5O0ACdTh/+uDycwf5iwidhYj9NA6U0is+vjjA/1Y3yKErRI/bf2s60wc HmJAZNh+qy9xRaUIxf989vD3WxYAwIWkmlLxPbkK/dsYdl9px5huVTlD3vOVJr4fCIHA fuPg5UgXyVBDKHntgR1V/C5rGYGgOHqxWVWAJUFdBQzEHFx5f0IhtSQHK1zbqCFtoiwY dd0RDPmgpQQpXgTjXpcwBodDv3LTwdrHOq30Au+R77kxXmKNn4MUxVS7v3Ws3H61dVN9 QX7e8hgMrzSA0AKEvJsdlURgfEEsaEB93FLItEvfX7/dYofiVOVAQKoiduy8y+QNBiPu ahSQ== X-Gm-Message-State: AG10YOTkuKrcHIrfAp9Mg+V4QffxZggtd632FyoV8r0ugzKeuqBqdXWcXvvZsvOWpe7s9q5OQiqMoiVsrzDxRw== MIME-Version: 1.0 X-Received: by 10.28.107.152 with SMTP id a24mr28570633wmi.101.1453846951923; Tue, 26 Jan 2016 14:22:31 -0800 (PST) Received: by 10.194.30.65 with HTTP; Tue, 26 Jan 2016 14:22:31 -0800 (PST) Date: Tue, 26 Jan 2016 17:22:31 -0500 Message-ID: Subject: Subscribe From: George Swallow To: idr@ietf.org, ccamp@ietf.org, teas@ietf.org, spring@ietf.org, bfd@ietf.org, bier@ietf.org, i2rs@ietf.org, isis@ietf.org, rtgwg@ietf.org Content-Type: multipart/alternative; boundary=001a114768da2095d3052a441fd9 Archived-At: X-Mailman-Approved-At: Wed, 27 Jan 2016 06:59:09 -0800 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 22:22:41 -0000 --001a114768da2095d3052a441fd9 Content-Type: text/plain; charset=UTF-8 subscribe --001a114768da2095d3052a441fd9 Content-Type: text/html; charset=UTF-8
    subscribe
    --001a114768da2095d3052a441fd9-- From nobody Wed Jan 27 17:42:54 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96361A01EC; Wed, 27 Jan 2016 17:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.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, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEIgGEbGTcQd; Wed, 27 Jan 2016 17:42:42 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96181A0262; Wed, 27 Jan 2016 17:42:41 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-64-56a971fe66ee Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C5.6C.32102.EF179A65; Thu, 28 Jan 2016 02:42:22 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Wed, 27 Jan 2016 20:42:40 -0500 From: Gregory Mirsky To: Chris Bowers , "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYpHSG9NZLZk0mhGks73w62U559pVgAgHxsaYCAChvegIAMmnag Date: Thu, 28 Jan 2016 01:42:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyuXSPn+6/wpVhBo8+Slqcv7+Z0eLHeleL fVNfM1psm25hceLhRSaLz3+2MVpcePOb2YHdY8rvjawer3+sZfZYsuQnk8f1pqvsASxRXDYp qTmZZalF+nYJXBl9fa8ZC778ZKzY0jiXuYFx0zXGLkZODgkBE4nPv7vZIGwxiQv31gPZXBxC AkcYJaYtO8wM4SxnlLj06TZYB5uAkcSLjT3sILaIwBJGiePXE0FsZoEqiZPf21lBbGEBN4nb D48xQtS4S0y5uxzI5gCy3SRmbwQLswioSix/PAHM5hXwleiff5wdYtcdRolzX/ewgCQ4BaIl Wp5sACtiBLru+6k1TBC7xCVuPZnPBHG1gMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Woz5e439vO DLFMUOLkzCcsExhFZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dp cUFObrqR4SZGYHQek2Bz3MG4t9fzEKMAB6MSD6/BoeVhQqyJZcWVuYcYJTiYlUR4ZyWvDBPi TUmsrEotyo8vKs1JLT7EKM3BoiTOu4V/UZiQQHpiSWp2ampBahFMlomDU6qBsUtX8K3h23rX q+L3ZPL5zmRsemledqR2SlD+h3XzunobGOZ9s4w+OXu1IZuU8OKAOPvPbiu5w648st3etyvs us7q331PdNeIn7yxvkjlc5Js4MyohAlLXGeWzxE7I/D1k+3uxYILoxczus5M2+Y2w/mjU83/ XW5HVz0OlLsvd1M7Pb5n/8ZzqkosxRmJhlrMRcWJAG8+DBTKAgAA Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 01:42:50 -0000 --_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, greatly appreciate your thorough review and the most detailed comments. As = we've contributed p2mp BFD applicability to VRRP part of the draft I'll add= ress your comments, that I've copied below, to Section 4. Please find my no= tes tagged GIM>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Secti= on 4 below. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. GIM>> Very good catch. Indeed, the idea is to use IPvX address associated w= ith the particular VRID. Would the following change clarify selection of so= urce IP address: The Master router starts transmitting BFD control packets with IPvX address= associated with the VRID as source IP address. Backup router demultiplexes= p2mp BFD test sessions based on IP source address associated with the virt= ual router that it been configured with. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. GIM>> I think that VRRP multicast address MAY be used as destination IP add= ress for p2mp BFD which has VRRP as its client. I think that subnet broadca= st address SHOULD be used as destination IP address. I'll add the text to t= he Section 4. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. GIM>> p2mp BFD, as I think, does not change VRRP state machine. I'll add st= atement to that to the text for the next version. -----Original Message----- From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach. So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= . 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky >; Jeff Haas >; colin@d= och.org.uk; Aditya Dogra (addogra) > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" > wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>successfully submitted by Nitish Gupta and posted to the IETF >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> >> >> >> >>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 >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Chris,

    greatly appreciate your thorough review and the m= ost detailed comments. As we've contributed p2mp BFD applicability to VRRP = part of the draft I'll address your comments, that I've copied below, to Se= ction 4. Please find my notes tagged GIM>>

     

    4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

    GIM>>  Hope that will be clearer once = I address your questions to the Section 4 below.

     

    A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

    GIM>> Very good catch. Indeed, the idea is = to use IPvX address associated with the particular VRID. Would the followin= g change clarify selection of source IP address:

    The Master router star= ts transmitting BFD control packets with IPvX address associated with the V= RID as source IP address. Backup router demultiplexes p2mp BFD test session= s based on IP source address associated with the virtual router that it been configured with.

     

    B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

    GIM>> I think that VRRP multicast address M= AY be used as destination IP address for p2mp BFD which has VRRP as its cli= ent. I think that subnet broadcast address SHOULD be used as destination IP= address. I’ll add the text to the Section 4.

     

    C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

    GIM>> p2mp BFD, as I think, does not change= VRRP state machine. I’ll add statement to that to the text for the n= ext version.

     

    -----Original Message-----
    From: Chris Bowers [mailto:cbowers@juniper.net]
    Sent: Tuesday, January 19, 2016 11:54 AM
    To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd@ietf.org
    Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

     

    Nitish and co-authors,

     

    I have read this draft and have several comments = below.  In general, I prefer that authors address outstanding comments= in a new revision before we conduct a poll for adoption in RTGWG.  Si= nce an adoption poll usually triggers quite a few people read a draft in detail, it makes better use of the working gr= oups time to have them reading the most up-to-date version.  However, = an argument could also be made for filling in some of the additional detail= that I am asking for below after WG adoption (assuming it is adopted), when the WG has more direct control of = the document.   So I am open to either approach.

     

    So please respond to the feedback below and tell = me if you would like to address some of it in a new revision before I condu= ct a poll for WG adoption, or if you would prefer to do the WG adoption pol= l using the current revision.  There has also been feedback from others on this draft in response to your email= , so you should respond to that as well.

     

    In general, I think the draft would benefit from = specifying the VRRP state machine for this BFD mode of operation at the sam= e level of detail that RFC5798 specifies the existing VRRP state machine.&n= bsp;  There are several places where it is probably possible to infer the correct behavior, but making it very exp= licit will make for a better document.

     

    1) Section 3.5 of this draft defines the Critical= BFD session which is the BFD session between the VRRP Master and the next = best VRRP backup.  In the existing VRRP state machine, a VRRP router i= n the backup state is not able to determine if it is the next best VRRP backup.  Presumably, in the VRRP state ma= chine for the BFD mode of operation, a VRRP router in the backup state will= look at the peer table populated by the Backup Advertisements and figure o= ut which router is the next best VRRP router based on highest priority value with highest IPvX address as tie br= eaker.  However, it would be better to be as explicit as RFC5798 about= how this new state machine operates.

     

    2) Section 5 says that "To reduce the number= of packets generated at a regular interval, Backup Advert packets may be s= ent at a reduced rate as compared to Advert packets sent by the VRRP Master= ."  It seems that the state machine for VRRP BFD mode will have to be enhanced in some way to support this.  = One  way to do this would be for each router to have a Backup_Advertis= ement_Interval which it uses to populate the Maximum Advertisement Interval= in the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and = remove a peer entry when a BACKUP ADVERTISEMENT is not received from P for = 3* Peer_Advert_Interval(P).  But this is just one possible approach.&n= bsp; In any case,  it would be good to choose a mechanism and describe the corresponding state machine.

     

    3) The text should clarify how the VRRP state mac= hine interacts with the BFD state machine.   One can imagine scen= arios where a BFD session stays up but the VRRP advertisements stop being r= eceived, or vice versa.  This scenario is not very far-fetched because BFD may use unicast and VRRP uses multicast. = ; Behavior can probably be inferred from existing text, but I think more pr= ecision is better here.

     

    4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

     

    A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

     

    B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

     

    C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

     

    Thanks,

    Chris

     

    -----Original Message-----

    From: rtgwg [mailto:rtgwg-bo= unces@ietf.org] On Behalf Of Nitish Gupta (nitisgup)<= /p>

    Sent: Wednesday, January 13, 2016 3:31 AM

    To: rtgwg@ietf.org; rtg-bfd@ietf.org

    Cc: Gregory Mirsky <= gregory.mirsky@ericsson.com>; Jeff Haas <j= haas@juniper.net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>

    Subject: Re: New Version Notification for draft-n= itish-vrrp-bfd-02.txt

     

    Hi,

     

    We had presented the Draft for VRRP BFD integrati= on in IETF 93 and we had taken care of all the comments that came as part o= f the WG meeting.

    We had also merged the two drafts as per the comm= ents in IETF 93:

    http:/= /tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00=

     

    We had presented the merged draft in IETF 94 and = there were no specific comments on the draft.

    We would like to ask the RTGWG to adopt the Draft= as a WG document.

     

    Thanks,

    Nitish

     

     

    On 26/10/15 11:57 am, "Nitish Gupta (nitisgu= p)" <nitisgup@cisco.com> wrote:=

     

    >Hi,

    > 

    >We have submitted a new version of the draft.= As discussed in IETF 93

    >at prague.

    > 

    >We have merged the following drafts:

    >ht= tp://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    > 

    >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-cas= e-00

    > 

    > 

    > 

    >We have also taken care of all the comments t= hat were discussed in the

    >RTGWG meeting.

    >We welcome any comments and suggestions on th= e draft.

    > 

    >Thanks,

    >Nitish

    > 

    >On 13/10/15 9:09 pm, "internet-drafts@ietf.org"

    ><internet-drafts@ie= tf.org>

    >wrote:

    > 

    >> 

    >>A new version of I-D, draft-nitish-vrrp-b= fd-02.txt has been

    >>successfully submitted by Nitish Gupta an= d posted to the IETF

    >>repository.

    >> 

    >>Name:      =             &nb= sp;          draft-nitish-vrrp= -bfd

    >>Revision:     &n= bsp;  02

    >>Title:      = ;           Fast failure = detection in VRRP with BFD

    >>Document date:    &nb= sp;     2015-10-13

    >>Group:      = ;            &n= bsp;         Individual Submission<= o:p>

    >>Pages:      = ;            &n= bsp;          10

    >>URL:      &= nbsp;    

    >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-= 02.txt

    >>Status:     &nbs= p;   https://datatracker.i= etf.org/doc/draft-nitish-vrrp-bfd/

    >>Htmlized:     &n= bsp; https://tools.ietf.or= g/html/draft-nitish-vrrp-bfd-02

    >>Diff:      =     

    >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

    >> 

    >>Abstract:

    >>   This document describes how = Bidirectional Forwarding Detection (BFD)

    >>   can be used to support sub-s= econd detection of a Master Router

    >>   failure in the Virtual Route= r Redundancy Protocol (VRRP).

    >> 

    >>       = ;         

    >>       = ;

    >> 

    >> 

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

    >> 

    > 

     

    _______________________________________________

    rtgwg mailing list

    rtgwg@ietf.org=

    https://www.ie= tf.org/mailman/listinfo/rtgwg

    --_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_-- From nobody Thu Jan 28 07:40:35 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9DB1A8A3D; Thu, 28 Jan 2016 07:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVhVZ-PP1DR6; Thu, 28 Jan 2016 07:40:22 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4FC1A8A42; Thu, 28 Jan 2016 07:40:21 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by BY2PR0501MB1813.namprd05.prod.outlook.com (10.163.155.143) with Microsoft SMTP Server (TLS) id 15.1.390.13; Thu, 28 Jan 2016 15:40:18 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0390.016; Thu, 28 Jan 2016 15:40:18 +0000 From: Chris Bowers To: Gregory Mirsky , "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACACWswAIAM9MqAgADbUEA= Date: Thu, 28 Jan 2016 15:40:17 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1813; 5:i24hHtIn0bc0YJrUDxFIixTrDeiHstaY6THt5AJ3L4dABkQXvvVCWpYkbNhqiIyE58RLTD1kHczuRZDTCGEzr5x6DTLVTdu8tC2KL9mj0apgbzaDtqyLMWUkO+Zo9yO1JZ0KPBZTDIyzJzhOVYeQMg==; 24:fHIiqzyJvy5u0AFwqoLAka8hZ6PnCjoMHzNOCRtchO/V2xyNk/y7P7+FZnYjUl/TAiEw8zKwjhSlCn3ft32pFTPz8fIMOQz8AQnqk9b240s= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1813; x-ms-office365-filtering-correlation-id: d3791911-58d4-49a0-11f9-08d327f952e5 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0501MB1813; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1813; x-forefront-prvs: 083526BF8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(13464003)(189002)(164054003)(51444003)(377454003)(24454002)(199003)(479174004)(11100500001)(33656002)(2501003)(5008740100001)(101416001)(5003600100002)(3660700001)(1220700001)(3470700001)(3846002)(790700001)(102836003)(6116002)(40100003)(19300405004)(1096002)(92566002)(3280700002)(586003)(4326007)(122556002)(74316001)(2906002)(10710500007)(76576001)(54356999)(76176999)(19609705001)(230783001)(50986999)(93886004)(19580395003)(19580405001)(5001770100001)(97736004)(16236675004)(81156007)(87936001)(4001150100001)(5002640100001)(19625215002)(2420400006)(15975445007)(10400500002)(2201001)(5001960100002)(2900100001)(86362001)(99286002)(106356001)(106116001)(2950100001)(189998001)(105586002)(66066001)(19617315012)(77096005)(5004730100002)(7110500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1813; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2016 15:40:17.7174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1813 Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:40:31 -0000 --_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Thanks. Those clarifications seem reasonable. Draft authors, I do have another general comment about the current text of the draft. Th= e current text discusses two different approaches to doing fast failure det= ection in VRRP with BFD, using p2p BFD or p2mp BFD. The first uses existin= g BFD p2p sessions and enhances VRRP to use the p2p BFD sessions. The seco= nd requires less enhancement of VRRP, but relies on enhanced functionality = in BFD. If this is correct, it would be good for the text to explicitly s= tate that these are two distinct approaches, to help the readers during the= poll for WG adoption. If this work is adopted by RTGWG, one could imagine a scenario where the wo= rking group decides to document both approaches in the final version. Howe= ver, it is usually more desirable for the working group to evaluate the dif= ferent approaches and choose one. It would also be useful for the text to = explicitly state the authors' thoughts and intentions with respect to how t= he document should evolve. Should it ultimately document one solution, sho= uld it document multiple solutions, or should more work be done to determin= e if there are compelling reasons to document multiple solutions? If adop= ted, it will ultimately be up to the WG to decide how to move forward, rega= rdless of the stated intentions of the current authors. However, it would = be useful for the readers during the poll for WG adoption to understand the= authors' current intentions and their thinking on this topic. Thanks, Chris From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, January 27, 2016 7:43 PM To: Chris Bowers ; Nitish Gupta (nitisgup) ; rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Jeff Haas ; colin@doch.org.uk; Aditya Dogra (addogra= ) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi Chris, greatly appreciate your thorough review and the most detailed comments. As = we've contributed p2mp BFD applicability to VRRP part of the draft I'll add= ress your comments, that I've copied below, to Section 4. Please find my no= tes tagged GIM>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Secti= on 4 below. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. GIM>> Very good catch. Indeed, the idea is to use IPvX address associated w= ith the particular VRID. Would the following change clarify selection of so= urce IP address: The Master router starts transmitting BFD control packets with IPvX address= associated with the VRID as source IP address. Backup router demultiplexes= p2mp BFD test sessions based on IP source address associated with the virt= ual router that it been configured with. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. GIM>> I think that VRRP multicast address MAY be used as destination IP add= ress for p2mp BFD which has VRRP as its client. I think that subnet broadca= st address SHOULD be used as destination IP address. I'll add the text to t= he Section 4. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. GIM>> p2mp BFD, as I think, does not change VRRP state machine. I'll add st= atement to that to the text for the next version. -----Original Message----- From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd= @ietf.org Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk;= Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach. So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= . 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky >; Jeff Haas >; colin@d= och.org.uk; Aditya Dogra (addogra) > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" > wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>successfully submitted by Nitish Gupta and posted to the IETF >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> >> >> >> >>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 >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Greg,

     

    Thanks.  Those cl= arifications seem reasonable. 

     

    Draft authors,

     

    I do have another gene= ral comment about the current text of the draft.   The current te= xt discusses two different approaches to doing fast failure detection in VR= RP with BFD, using p2p BFD or p2mp BFD.  The first uses existing BFD p2p sessions and enhances VRRP to use the p2p BFD sessio= ns.  The second requires less enhancement of VRRP, but relies on enhan= ced functionality in BFD.   If this is correct, it would be good = for the text to explicitly state that these are two distinct approaches, to help the readers during the poll for WG adopti= on.

     

    If this work is adopte= d by RTGWG, one could imagine a scenario where the working group decides to= document both approaches in the final version.  However, it is usuall= y more desirable for the working group to evaluate the different approaches and choose one.  It would also be u= seful for the text to explicitly state the authors’ thoughts and inte= ntions with respect to how the document should evolve.  Should it ulti= mately document one solution, should it document multiple solutions, or should more work be done to determine if there are = compelling reasons to document multiple solutions?   If adopted, = it will ultimately be up to the WG to decide how to move forward, regardles= s of the stated intentions of the current authors.  However, it would be useful for the readers during the poll= for WG adoption to understand the authors’ current intentions and th= eir thinking on this topic.

     

    Thanks,

    Chris

     

     

     

    From: Gregory Mirsky [mailto:gregory.mirsky@e= ricsson.com]
    Sent: Wednesday, January 27, 2016 7:43 PM
    To: Chris Bowers <cbowers@juniper.net>; Nitish Gupta (nitisgup= ) <nitisgup@cisco.com>; rtgwg@ietf.org; rtg-bfd@ietf.org
    Cc: Jeff Haas <jhaas@juniper.net>; colin@doch.org.uk; Aditya D= ogra (addogra) <addogra@cisco.com>
    Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.t= xt

     

    Hi Chris,

    greatly appreciate your thorough review and the m= ost detailed comments. As we've contributed p2mp BFD applicability to VRRP = part of the draft I'll address your comments, that I've copied below, to Se= ction 4. Please find my notes tagged GIM>>

     

    4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

    GIM>>  Hope that will be clearer once = I address your questions to the Section 4 below.

     

    A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

    GIM>> Very good catch. Indeed, the idea is = to use IPvX address associated with the particular VRID. Would the followin= g change clarify selection of source IP address:

    The Master router star= ts transmitting BFD control packets with IPvX address associated with the V= RID as source IP address. Backup router demultiplexes p2mp BFD test session= s based on IP source address associated with the virtual router that it been configured with.

     

    B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

    GIM>> I think that VRRP multicast address M= AY be used as destination IP address for p2mp BFD which has VRRP as its cli= ent. I think that subnet broadcast address SHOULD be used as destination IP= address. I’ll add the text to the Section 4.

     

    C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

    GIM>> p2mp BFD, as I think, does not change= VRRP state machine. I’ll add statement to that to the text for the n= ext version.

     

    -----Original Message-----
    From: Chris Bowers [mailto:cbowers@j= uniper.net]
    Sent: Tuesday, January 19, 2016 11:54 AM
    To: Nitish Gupta (nitisgup); rtgwg@ietf.o= rg; rtg-bfd@ietf.org
    Cc: Gregory Mirsky; Jeff Haas; colin@d= och.org.uk; Aditya Dogra (addogra)
    Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt=

     

    Nitish and co-authors,

     

    I have read this draft and have several comments = below.  In general, I prefer that authors address outstanding comments= in a new revision before we conduct a poll for adoption in RTGWG.  Si= nce an adoption poll usually triggers quite a few people read a draft in detail, it makes better use of the working gr= oups time to have them reading the most up-to-date version.  However, = an argument could also be made for filling in some of the additional detail= that I am asking for below after WG adoption (assuming it is adopted), when the WG has more direct control of = the document.   So I am open to either approach.

     

    So please respond to the feedback below and tell = me if you would like to address some of it in a new revision before I condu= ct a poll for WG adoption, or if you would prefer to do the WG adoption pol= l using the current revision.  There has also been feedback from others on this draft in response to your email= , so you should respond to that as well.

     

    In general, I think the draft would benefit from = specifying the VRRP state machine for this BFD mode of operation at the sam= e level of detail that RFC5798 specifies the existing VRRP state machine.&n= bsp;  There are several places where it is probably possible to infer the correct behavior, but making it very exp= licit will make for a better document.

     

    1) Section 3.5 of this draft defines the Critical= BFD session which is the BFD session between the VRRP Master and the next = best VRRP backup.  In the existing VRRP state machine, a VRRP router i= n the backup state is not able to determine if it is the next best VRRP backup.  Presumably, in the VRRP state ma= chine for the BFD mode of operation, a VRRP router in the backup state will= look at the peer table populated by the Backup Advertisements and figure o= ut which router is the next best VRRP router based on highest priority value with highest IPvX address as tie br= eaker.  However, it would be better to be as explicit as RFC5798 about= how this new state machine operates.

     

    2) Section 5 says that "To reduce the number= of packets generated at a regular interval, Backup Advert packets may be s= ent at a reduced rate as compared to Advert packets sent by the VRRP Master= ."  It seems that the state machine for VRRP BFD mode will have to be enhanced in some way to support this.  = One  way to do this would be for each router to have a Backup_Advertis= ement_Interval which it uses to populate the Maximum Advertisement Interval= in the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and = remove a peer entry when a BACKUP ADVERTISEMENT is not received from P for = 3* Peer_Advert_Interval(P).  But this is just one possible approach.&n= bsp; In any case,  it would be good to choose a mechanism and describe the corresponding state machine.

     

    3) The text should clarify how the VRRP state mac= hine interacts with the BFD state machine.   One can imagine scen= arios where a BFD session stays up but the VRRP advertisements stop being r= eceived, or vice versa.  This scenario is not very far-fetched because BFD may use unicast and VRRP uses multicast. = ; Behavior can probably be inferred from existing text, but I think more pr= ecision is better here.

     

    4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

     

    A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

     

    B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

     

    C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

     

    Thanks,

    Chris

     

    -----Original Message-----

    From: rtgwg [mailto:rtgwg-bo= unces@ietf.org] On Behalf Of Nitish Gupta (nitisgup)<= /p>

    Sent: Wednesday, January 13, 2016 3:31 AM

    To: rtgwg@ietf.org; rtg-bfd@ietf.org

    Cc: Gregory Mirsky <= gregory.mirsky@ericsson.com>; Jeff Haas <j= haas@juniper.net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>

    Subject: Re: New Version Notification for draft-n= itish-vrrp-bfd-02.txt

     

    Hi,

     

    We had presented the Draft for VRRP BFD integrati= on in IETF 93 and we had taken care of all the comments that came as part o= f the WG meeting.

    We had also merged the two drafts as per the comm= ents in IETF 93:

    http:/= /tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00=

     

    We had presented the merged draft in IETF 94 and = there were no specific comments on the draft.

    We would like to ask the RTGWG to adopt the Draft= as a WG document.

     

    Thanks,

    Nitish

     

     

    On 26/10/15 11:57 am, "Nitish Gupta (nitisgu= p)" <nitisgup@cisco.com> wrote:=

     

    >Hi,

    > 

    >We have submitted a new version of the draft.= As discussed in IETF 93

    >at prague.

    > 

    >We have merged the following drafts:

    >ht= tp://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    > 

    >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-cas= e-00

    > 

    > 

    > 

    >We have also taken care of all the comments t= hat were discussed in the

    >RTGWG meeting.

    >We welcome any comments and suggestions on th= e draft.

    > 

    >Thanks,

    >Nitish

    > 

    >On 13/10/15 9:09 pm, "internet-drafts@ietf.org"

    ><internet-drafts@ie= tf.org>

    >wrote:

    > 

    >> 

    >>A new version of I-D, draft-nitish-vrrp-b= fd-02.txt has been

    >>successfully submitted by Nitish Gupta an= d posted to the IETF

    >>repository.

    >> 

    >>Name:      =             &nb= sp;          draft-nitish-vrrp= -bfd

    >>Revision:     &n= bsp;  02

    >>Title:      = ;           Fast failure = detection in VRRP with BFD

    >>Document date:    &nb= sp;     2015-10-13

    >>Group:      = ;            &n= bsp;         Individual Submission<= o:p>

    >>Pages:      = ;            &n= bsp;          10

    >>URL:      &= nbsp;    

    >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-= 02.txt

    >>Status:     &nbs= p;   https://datatracker.i= etf.org/doc/draft-nitish-vrrp-bfd/

    >>Htmlized:     &n= bsp; https://tools.ietf.or= g/html/draft-nitish-vrrp-bfd-02

    >>Diff:      =     

    >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

    >> 

    >>Abstract:

    >>   This document describes how = Bidirectional Forwarding Detection (BFD)

    >>   can be used to support sub-s= econd detection of a Master Router

    >>   failure in the Virtual Route= r Redundancy Protocol (VRRP).

    >> 

    >>       = ;         

    >>       = ;

    >> 

    >> 

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

    >> 

    > 

     

    _______________________________________________

    rtgwg mailing list

    rtgwg@ietf.org=

    https://www.ie= tf.org/mailman/listinfo/rtgwg

    --_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_-- From nobody Thu Jan 28 12:14:01 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3810B1ACDB7; Thu, 28 Jan 2016 12:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rbW_lDerFVb; Thu, 28 Jan 2016 12:13:51 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C561ACDB2; Thu, 28 Jan 2016 12:13:51 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-e9-56aa739da789 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.E5.06940.E937AA65; Thu, 28 Jan 2016 21:01:34 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Thu, 28 Jan 2016 15:13:50 -0500 From: Gregory Mirsky To: Chris Bowers , "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYpHSG9NZLZk0mhGks73w62U559pVgAgHxsaYCAChvegIAMmnaggAFDr4D///ZdUA== Date: Thu, 28 Jan 2016 20:13:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221996D4C@eusaamb103.ericsson.se> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> 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.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyuXRPoO684lVhBodWSlqcv7+Z0eLHeleL fVNfM1psm25hceLhRSaLz3+2MVpcePOb2YHdY8rvjawer3+sZfZYsuQnk8f1pqvsASxRXDYp qTmZZalF+nYJXBm925eyFHw5zlRxccNHtgbGizOZuhg5OSQETCQ2r97BCGGLSVy4t56ti5GL Q0jgCKPEie4ZUM5yRol13T9ZQarYBIwkXmzsYQexRQSWMEocv54IYjMLVEmc/N4OViMs4CZx ++ExRogad4kpd5dD2WESN7evAathEVCVmP35CQuIzSvgKzF7WiMzxLKPTBKzek+xgSQ4BaIl 5r2cB3YqI9B530+tYYJYJi5x68l8qBcEJJbsOc8MYYtKvHz8jxXCVpTY1z+dHaI+X+Lo3Vvs EMsEJU7OfMIygVF0FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQW F+TkphsZbGIExucxCTbdHYz3p3seYhTgYFTi4TVIXRUmxJpYVlyZe4hRgoNZSYQ3PAsoxJuS WFmVWpQfX1Sak1p8iFGag0VJnNeGd1GYkEB6YklqdmpqQWoRTJaJg1OqgTFKPV62XftlrbLe tkOxPbfmW8kYp+c7zJglNNmr5QVDk5TJQo8VOzMCF5qz18+T+qw216o+6I/ElXgpDS+xD5M0 XnVd+jj79JcvvPJqM/QEuj7d/bpO8dGiZbNzN4tW9l2vYzkz/5Jmxod5wUYTP/vM52a3lJt9 kc02qpQvzZn/4ul5Xj1zc5VYijMSDbWYi4oTARvNMAfLAgAA Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 20:14:00 -0000 --_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, thank you for your review. Will include the proposed update in the next ver= sion of the draft. On two approaches being presented in the draft. We'll work on the text to m= ake the situation more clear. And I can refer to RFC 4090 where two approac= hes to RSVP FRR defined. And, as in the case with VRRP-BFD, it was result o= f merging two drafts that presented technically viable though different sol= utions. And that how I see two solutions presented in this draft - both are= technically sound, with their own pros and cons. But, of course, it would = be for the RTGWG and community of experts from other WGs, e.g. BFD, to deci= de. Regards, Greg From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Thursday, January 28, 2016 7:40 AM To: Gregory Mirsky; Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd@ietf.o= rg Cc: Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Greg, Thanks. Those clarifications seem reasonable. Draft authors, I do have another general comment about the current text of the draft. Th= e current text discusses two different approaches to doing fast failure det= ection in VRRP with BFD, using p2p BFD or p2mp BFD. The first uses existin= g BFD p2p sessions and enhances VRRP to use the p2p BFD sessions. The seco= nd requires less enhancement of VRRP, but relies on enhanced functionality = in BFD. If this is correct, it would be good for the text to explicitly s= tate that these are two distinct approaches, to help the readers during the= poll for WG adoption. If this work is adopted by RTGWG, one could imagine a scenario where the wo= rking group decides to document both approaches in the final version. Howe= ver, it is usually more desirable for the working group to evaluate the dif= ferent approaches and choose one. It would also be useful for the text to = explicitly state the authors' thoughts and intentions with respect to how t= he document should evolve. Should it ultimately document one solution, sho= uld it document multiple solutions, or should more work be done to determin= e if there are compelling reasons to document multiple solutions? If adop= ted, it will ultimately be up to the WG to decide how to move forward, rega= rdless of the stated intentions of the current authors. However, it would = be useful for the readers during the poll for WG adoption to understand the= authors' current intentions and their thinking on this topic. Thanks, Chris From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, January 27, 2016 7:43 PM To: Chris Bowers >; Nitish = Gupta (nitisgup) >; rtgwg@iet= f.org; rtg-bfd@ietf.org Cc: Jeff Haas >; colin@doch.org= .uk; Aditya Dogra (addogra) > Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi Chris, greatly appreciate your thorough review and the most detailed comments. As = we've contributed p2mp BFD applicability to VRRP part of the draft I'll add= ress your comments, that I've copied below, to Section 4. Please find my no= tes tagged GIM>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Secti= on 4 below. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. GIM>> Very good catch. Indeed, the idea is to use IPvX address associated w= ith the particular VRID. Would the following change clarify selection of so= urce IP address: The Master router starts transmitting BFD control packets with IPvX address= associated with the VRID as source IP address. Backup router demultiplexes= p2mp BFD test sessions based on IP source address associated with the virt= ual router that it been configured with. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. GIM>> I think that VRRP multicast address MAY be used as destination IP add= ress for p2mp BFD which has VRRP as its client. I think that subnet broadca= st address SHOULD be used as destination IP address. I'll add the text to t= he Section 4. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. GIM>> p2mp BFD, as I think, does not change VRRP state machine. I'll add st= atement to that to the text for the next version. -----Original Message----- From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd= @ietf.org Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk;= Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach. So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= . 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky >; Jeff Haas >; colin@d= och.org.uk; Aditya Dogra (addogra) > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" > wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>successfully submitted by Nitish Gupta and posted to the IETF >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> >> >> >> >>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 >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Chris,

    thank you for your rev= iew. Will include the proposed update in the next version of the draft.

     

    On two approaches bein= g presented in the draft. We’ll work on the text to make the situatio= n more clear. And I can refer to RFC 4090 where two approaches to RSVP FRR = defined. And, as in the case with VRRP-BFD, it was result of merging two drafts that presented technically viable thou= gh different solutions. And that how I see two solutions presented in this = draft – both are technically sound, with their own pros and cons. But= , of course, it would be for the RTGWG and community of experts from other WGs, e.g. BFD, to decide.

     

       &nbs= p;            Regard= s,

       &nbs= p;            &= nbsp;           &nbs= p;   Greg

     

    From: Chris Bo= wers [mailto:cbowers@juniper.net]
    Sent: Thursday, January 28, 2016 7:40 AM
    To: Gregory Mirsky; Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd= @ietf.org
    Cc: Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra)
    Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.t= xt

     

    Greg,

     

    Thanks.  Those cl= arifications seem reasonable. 

     

    Draft authors,

     

    I do have another gene= ral comment about the current text of the draft.   The current te= xt discusses two different approaches to doing fast failure detection in VR= RP with BFD, using p2p BFD or p2mp BFD.  The first uses existing BFD p2p sessions and enhances VRRP to use the p2p BFD sessio= ns.  The second requires less enhancement of VRRP, but relies on enhan= ced functionality in BFD.   If this is correct, it would be good = for the text to explicitly state that these are two distinct approaches, to help the readers during the poll for WG adopti= on.

     

    If this work is adopte= d by RTGWG, one could imagine a scenario where the working group decides to= document both approaches in the final version.  However, it is usuall= y more desirable for the working group to evaluate the different approaches and choose one.  It would also be u= seful for the text to explicitly state the authors’ thoughts and inte= ntions with respect to how the document should evolve.  Should it ulti= mately document one solution, should it document multiple solutions, or should more work be done to determine if there are = compelling reasons to document multiple solutions?   If adopted, = it will ultimately be up to the WG to decide how to move forward, regardles= s of the stated intentions of the current authors.  However, it would be useful for the readers during the poll= for WG adoption to understand the authors’ current intentions and th= eir thinking on this topic.

     

    Thanks,

    Chris

     

     

     

    From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
    Sent: Wednesday, January 27, 2016 7:43 PM
    To: Chris Bowers <cbowers@= juniper.net>; Nitish Gupta (nitisgup) <nitisgup@cisco.com>; rtgwg@ietf.org; rtg-bfd@ietf.org
    Cc: Jeff Haas <jhaas@juniper= .net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>
    Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.t= xt

     

    Hi Chris,

    greatly appreciate your thorough review and the m= ost detailed comments. As we've contributed p2mp BFD applicability to VRRP = part of the draft I'll address your comments, that I've copied below, to Se= ction 4. Please find my notes tagged GIM>>

     

    4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

    GIM>>  Hope that will be clearer once = I address your questions to the Section 4 below.

     

    A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

    GIM>> Very good catch. Indeed, the idea is = to use IPvX address associated with the particular VRID. Would the followin= g change clarify selection of source IP address:

    The Master router star= ts transmitting BFD control packets with IPvX address associated with the V= RID as source IP address. Backup router demultiplexes p2mp BFD test session= s based on IP source address associated with the virtual router that it been configured with.

     

    B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

    GIM>> I think that VRRP multicast address M= AY be used as destination IP address for p2mp BFD which has VRRP as its cli= ent. I think that subnet broadcast address SHOULD be used as destination IP= address. I’ll add the text to the Section 4.

     

    C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

    GIM>> p2mp BFD, as I think, does not change= VRRP state machine. I’ll add statement to that to the text for the n= ext version.

     

    -----Original Message-----
    From: Chris Bowers [mailto:cbowers@j= uniper.net]
    Sent: Tuesday, January 19, 2016 11:54 AM
    To: Nitish Gupta (nitisgup); rtgwg@ietf.o= rg; rtg-bfd@ietf.org
    Cc: Gregory Mirsky; Jeff Haas; colin@d= och.org.uk; Aditya Dogra (addogra)
    Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt=

     

    Nitish and co-authors,

     

    I have read this draft and have several comments = below.  In general, I prefer that authors address outstanding comments= in a new revision before we conduct a poll for adoption in RTGWG.  Si= nce an adoption poll usually triggers quite a few people read a draft in detail, it makes better use of the working gr= oups time to have them reading the most up-to-date version.  However, = an argument could also be made for filling in some of the additional detail= that I am asking for below after WG adoption (assuming it is adopted), when the WG has more direct control of = the document.   So I am open to either approach.

     

    So please respond to the feedback below and tell = me if you would like to address some of it in a new revision before I condu= ct a poll for WG adoption, or if you would prefer to do the WG adoption pol= l using the current revision.  There has also been feedback from others on this draft in response to your email= , so you should respond to that as well.

     

    In general, I think the draft would benefit from = specifying the VRRP state machine for this BFD mode of operation at the sam= e level of detail that RFC5798 specifies the existing VRRP state machine.&n= bsp;  There are several places where it is probably possible to infer the correct behavior, but making it very exp= licit will make for a better document.

     

    1) Section 3.5 of this draft defines the Critical= BFD session which is the BFD session between the VRRP Master and the next = best VRRP backup.  In the existing VRRP state machine, a VRRP router i= n the backup state is not able to determine if it is the next best VRRP backup.  Presumably, in the VRRP state ma= chine for the BFD mode of operation, a VRRP router in the backup state will= look at the peer table populated by the Backup Advertisements and figure o= ut which router is the next best VRRP router based on highest priority value with highest IPvX address as tie br= eaker.  However, it would be better to be as explicit as RFC5798 about= how this new state machine operates.

     

    2) Section 5 says that "To reduce the number= of packets generated at a regular interval, Backup Advert packets may be s= ent at a reduced rate as compared to Advert packets sent by the VRRP Master= ."  It seems that the state machine for VRRP BFD mode will have to be enhanced in some way to support this.  = One  way to do this would be for each router to have a Backup_Advertis= ement_Interval which it uses to populate the Maximum Advertisement Interval= in the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and = remove a peer entry when a BACKUP ADVERTISEMENT is not received from P for = 3* Peer_Advert_Interval(P).  But this is just one possible approach.&n= bsp; In any case,  it would be good to choose a mechanism and describe the corresponding state machine.

     

    3) The text should clarify how the VRRP state mac= hine interacts with the BFD state machine.   One can imagine scen= arios where a BFD session stays up but the VRRP advertisements stop being r= eceived, or vice versa.  This scenario is not very far-fetched because BFD may use unicast and VRRP uses multicast. = ; Behavior can probably be inferred from existing text, but I think more pr= ecision is better here.

     

    4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

     

    A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

     

    B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

     

    C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

     

    Thanks,

    Chris

     

    -----Original Message-----

    From: rtgwg [mailto:rtgwg-bo= unces@ietf.org] On Behalf Of Nitish Gupta (nitisgup)<= /p>

    Sent: Wednesday, January 13, 2016 3:31 AM

    To: rtgwg@ietf.org; rtg-bfd@ietf.org

    Cc: Gregory Mirsky <= gregory.mirsky@ericsson.com>; Jeff Haas <j= haas@juniper.net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>

    Subject: Re: New Version Notification for draft-n= itish-vrrp-bfd-02.txt

     

    Hi,

     

    We had presented the Draft for VRRP BFD integrati= on in IETF 93 and we had taken care of all the comments that came as part o= f the WG meeting.

    We had also merged the two drafts as per the comm= ents in IETF 93:

    http:/= /tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00=

     

    We had presented the merged draft in IETF 94 and = there were no specific comments on the draft.

    We would like to ask the RTGWG to adopt the Draft= as a WG document.

     

    Thanks,

    Nitish

     

     

    On 26/10/15 11:57 am, "Nitish Gupta (nitisgu= p)" <nitisgup@cisco.com> wrote:=

     

    >Hi,

    > 

    >We have submitted a new version of the draft.= As discussed in IETF 93

    >at prague.

    > 

    >We have merged the following drafts:

    >ht= tp://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

    > 

    >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-cas= e-00

    > 

    > 

    > 

    >We have also taken care of all the comments t= hat were discussed in the

    >RTGWG meeting.

    >We welcome any comments and suggestions on th= e draft.

    > 

    >Thanks,

    >Nitish

    > 

    >On 13/10/15 9:09 pm, "internet-drafts@ietf.org"

    ><internet-drafts@ie= tf.org>

    >wrote:

    > 

    >> 

    >>A new version of I-D, draft-nitish-vrrp-b= fd-02.txt has been

    >>successfully submitted by Nitish Gupta an= d posted to the IETF

    >>repository.

    >> 

    >>Name:      =             &nb= sp;          draft-nitish-vrrp= -bfd

    >>Revision:     &n= bsp;  02

    >>Title:      = ;           Fast failure = detection in VRRP with BFD

    >>Document date:    &nb= sp;     2015-10-13

    >>Group:      = ;            &n= bsp;         Individual Submission<= o:p>

    >>Pages:      = ;            &n= bsp;          10

    >>URL:      &= nbsp;    

    >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-= 02.txt

    >>Status:     &nbs= p;   https://datatracker.i= etf.org/doc/draft-nitish-vrrp-bfd/

    >>Htmlized:     &n= bsp; https://tools.ietf.or= g/html/draft-nitish-vrrp-bfd-02

    >>Diff:      =     

    >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

    >> 

    >>Abstract:

    >>   This document describes how = Bidirectional Forwarding Detection (BFD)

    >>   can be used to support sub-s= econd detection of a Master Router

    >>   failure in the Virtual Route= r Redundancy Protocol (VRRP).

    >> 

    >>       = ;         

    >>       = ;

    >> 

    >> 

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

    >> 

    > 

     

    _______________________________________________

    rtgwg mailing list

    rtgwg@ietf.org=

    https://www.ie= tf.org/mailman/listinfo/rtgwg

    --_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_-- From nobody Fri Jan 29 07:06:07 2016 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5871A7002; Fri, 29 Jan 2016 07:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MANGLED_LOAN=2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 0TYuKVh_czXr; Fri, 29 Jan 2016 07:06:01 -0800 (PST) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83981A7003; Fri, 29 Jan 2016 07:06:00 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 2AD914036E; Fri, 29 Jan 2016 16:05:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id E76CC1A0056; Fri, 29 Jan 2016 16:05:58 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Fri, 29 Jan 2016 16:05:58 +0100 From: To: "rtg-ads@ietf.org" Subject: RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09 Thread-Topic: RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09 Thread-Index: AdFapJJOEIRxVEGZTDqri7ekVvJZbA== Date: Fri, 29 Jan 2016 15:05:58 +0000 Message-ID: <23108_1454079959_56AB7FD7_23108_16575_1_53C29892C857584299CBF5D05346208A0F7A569A@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:06:03 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1 cmUtMDkudHh0DQpSZXZpZXdlcjogQnJ1bm8gRGVjcmFlbmUNClJldmlldyBEYXRlOiAyMDE2LTAx LTI5DQpJRVRGIExDIEVuZCBEYXRlOiAyMDE2LTAxLTI5DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5k YXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KICAgIEkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFi b3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUg cHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KICAgRG9jdW1lbnQgaXMgY2xlYXIgYW5kIHZlcnkg d2VsbCB3cml0dGVuLiBUaGFuayB5b3UuIFZlcnkgbXVjaCBhcHByZWNpYXRlZCBnaXZlbiB0aGUg c2l6ZSBvZiB0aGUgZG9jdW1lbnQgYW5kIHRoZSBzdWJqZWN0Lg0KDQpNYWpvcnMgSXNzdWVzOg0K ICAgTm9uZQ0KDQpNaW5vciBJc3N1ZXM6DQoNCi0tLS0NCi0gc2VjdGlvbiA2OiBVbmljYXN0IGZv cndhcmRpbmcgd2l0aCBNUlQgYW5kIEZhc3QtUmVyb3V0ZQ0KVGhpcyBzZWN0aW9uIGxpc3QgbWFu eSBwb3NzaWJpbGl0aWVzIG9mIHdoYXQgY291bGQgaGF2ZSBiZSBkb25lIG9yIHdoYXQgY291bGQg YmUgdXNlZC4gVGhpcyBpcyB2ZXJ5IGludGVyZXN0aW5nIGFuZCBvcGVuIGxhcmdlciBwb3NzaWJp bGl0aWVzLCBidXQgZm9yIGEgU1REIHRyYWNrIGRvY3VtZW50LCBpdCBtYXkgaGF2ZSBiZWVuIG1v cmUgcHJlc2NyaXB0aXZlLiAgKGFuZCB0aGUgbGFzdCBwYXJhZ3JhcGggb2Ygwqc2LjMuMS4yIHN0 YXJ0aW5nIHdpdGggIkZvciBjb21wbGV0ZW5lc3MiIGZ1cnRoZXIgcHVzaCB0aGUgY3Vyc29yIG9u IHRoZSBzaWRlIG9mIGNhdGFsb2cgb2YgcG9zc2libGUgc29sdXRpb25zIHJhdGhlciB0aGFuIHRo ZSBzcGVjaWZpY2F0aW9uIG9mIGEgb25lIFNURCB0cmFjayBzb2x1dGlvbi4pIEJ1dCBJIGFncmVl IHRoYXQgdGhlICJNUlQgYXJjaGl0ZWN0dXJlIiBjb3VsZCBiZSBzZWVuIGFzIGJyb2FkZXIgdGhh biBhIHNpbmdsZSBzb2x1dGlvbi4gQW5kIHRoZSBkb2N1bWVudCBwcm9wb3NlIHRoZSBkZWZpbml0 aW9uIG9mICJNUlQgcHJvZmlsZXMiIHdoaWNoIHNlZW0gYXBwcm9wcmlhdGUgdG8gYWxsb3cgZm9y IGludGVyb3BlcmFibGUgZGVwbG95bWVudHMgKGJ1dCBhcyBhIHNpbmdsZSBwcm9maWxlIGlzIGRl ZmluZWQsIGl0IHdvdWxkIGhhdmUgYmVlbiBwb3NzaWJsZSB0byB3cml0ZSBhIHNpbmdsZSBzb2x1 dGlvbiwgd2hpbGUgc3RpbGwgYmVpbmcgZXh0ZW5kYWJsZSBpbiB0aGUgZnV0dXJlKS4gDQoNCkV2 ZW50dWFsbHkgSSB3b3VsZCBwcm9wb3NlIGEgc2xpZ2h0IGNoYW5nZSBpbiB0aGUgVG9DIGZvciB0 aGUgcmVhZGVyIHRvIG1vcmUgZWFzaWx5IHVuZGVyc3RhbmQgd2hhdCBpcyBvcHRpb25hbCB2cyBy ZXF1aXJlZDoNCjpzLzYuMSBNUlQgRm9yd2FyZGluZyBNZWNoYW5pc21zLzYuMSBJbnRyb2R1Y3Rp b24gdG8gTVJUIEZvcndhcmRpbmcgb3B0aW9ucw0KQWRkaW5nICI2LjIuNCBSZXF1aXJlZCBzdXBw cG9ydCIsIHVzaW5nICI2LjMuMyBSZXF1aXJlZCBzdXBwb3J0IiBhcyBtb2RlbCAocGx1cyBtb3Zp bmcgdGhlIGxhc3Qgc2VudGVuY2Ugb2YgNi4yLjMgaW4gdGhpcyBzZWN0aW9uKQ0KDQotLS0tDQpD b21wYXJpc29uOg0KW05vdGU6IFllcywgSSByZWFkIHRoYXQgYXV0aG9ycyB3aWxsIHJlbW92ZSB0 aGUgY29tcGFyaXNvbiB0YWJsZSBpbiB0aGUgbmV4dCB2ZXJzaW9uLiA6LSkgQnV0IEkgaGFkIHN0 YXJ0ZWQgdGhlIHJldmlldyBiZWZvcmUsIGFuZCBJJ20gc3RpbGwgcmV2aWV3aW5nIHRoZSBsYXRl c3QgdmVyc2lvbi5dDQoNCkknbSBub3Qgc3VyZSB0aGF0IHRoZSBjb21wYXJpc29uIGlzIGJlc3Qg cGxhY2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbi4gSSdkIHJhdGhlciBtb3ZlIGl0IGxh dGVyIGluIHRoZSBkb2MsIG9yIGluIGFwcGVuZGl4IGFuZCBoYXZlIHRoZSBpbnRyb2R1Y3Rpb24g b25seSByZWZlcmVuY2UgaXQuIE9yIGluIGEgZGlmZmVyZW50IGRyYWZ0Lg0KDQotIDNyZCBjb2x1 bW4NCiIgICBUaGUgdGhpcmQgY29sdW1uIGdpdmVzIGFuIGVzdGltYXRlIG9mIHRoZSBhbW91bnQg b2YgY29tcHV0YXRpb24NCiAgIHJlcXVpcmVkIGF0IGVhY2ggbm9kZSB0byBzdXBwb3J0IHRoZSBG UlIgbWV0aG9kLCBpbiBhZGRpdGlvbiB0byB0aGUNCiAgIHVzdWFsIFNQRiBjb21wdXRhdGlvbiBy b290ZWQgYXQgdGhlIGNvbXB1dGluZyBub2RlIGl0c2VsZi4gIFRoaXMNCiAgIG1ldHJpYyBvZiBj b21wYXJpc29uIGlzIGltcG9ydGFudCBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgc2VlayB0bw0K ICAgcXVpY2tseSByZWNvbXB1dGUgcmVwYWlyIHBhdGhzIg0KDQpvay4gQnV0IGZvciByZWd1bGFy IHJvdXRpbmcsIHRoaXMgdGltZSBpcyB0eXBpY2FsbHkgZHJpdmVuIGJ5IEZJQiB1cGRhdGUgcmF0 aGVyIHRoYW4gY29udHJvbCBwbGFuZSBjb21wdXRhdGlvbi4gR2l2ZW4gdGhhdCAidGhlIE1SVCBM b3dwb2ludCBhbGdvcml0aG0gaXMgY29tcHV0YXRpb25hbGx5IGVmZmljaWVudCIsIGl0J3Mgbm90 IGNsZWFyIHRvIG1lIHRoYXQgY29udHJvbCBwbGFuZSBjb21wdXRhdGlvbiBpcyB0aGUgcmlnaHQg bWV0cmljIHRvIGV2YWx1YXRlIHRoZSB0aW1lIHRvIGJlIHJlYWR5IGZvciB0aGUgbmV4dCBmYWls dXJlLiBFc3BlY2lhbGx5IHNpbmNlIE1SVCByZXF1aXJlcyBhIGxhcmdlciBGSUIgKCozKSBhbmQg aGVuY2Ugd2lsbCBiZSBzbG93ZXIgb24gdGhlIG1haW4gZmFjdG9yLg0KDQotIE1SVCB1c2UgYSBk ZWRpY2F0ZWQgaW5mcmFzdHJ1Y3R1cmUgKHByb3RvY29scyBleHRlbnNpb24sIGFsZ29yaXRobSwg UklCL0ZJQiBlbnRyaWVzKSBmb3IgdGhlIEZSUiB0cmFmZmljLiDCpzE0LjEgcmVjb21tZW5kcyB0 byBjaGVjayB0aGF0IHRoaXMgaW5mcmFzdHJ1Y3R1cmUgaXMgcnVubmluZyBjb3JyZWN0bHkgd2hp Y2ggcmVwcmVzZW50IGFuIGFkZGl0aW9uYWwgb3BlcmF0aW9uYWwgd29yayBhbmQgdG9vbGluZy4g T3RoZXIgc29sdXRpb25zIGUuZy4gTEZBLCBUSS1MRkEsIFJMRkEgcmUtdXNlcyB0aGUgbm9taW5h bCByb3V0aW5nIGluZnJhc3RydWN0dXJlIHdoaWNoIGlzIGFscmVhZHkgbW9uaXRvcmVkLg0KLSBU cmFmZmljIGNhcGFjaXR5IG1heSBiZSBhbiBpbnRlcmVzdGluZyBtZXRyaWMgdG8gY29tcGFyZSAo YXMgZGlzY3Vzc2VkIGluIMKnMTQuMikNCg0KDQoNCi0tLS0NCsKnMTQuMiBUcmFmZmljIENhcGFj aXR5IG9uIEJhY2t1cCBQYXRocw0KSGF2aW5nIG5vdCByZWFkIE1SVCBMb3cgUG9pbnQgQWxnbywN CiJBZHZlcnRpc2luZyBsaW5rcyBhcyBNUlQtSW5lbGlnaWJsZSBpcyB0aGUgbWFpbiB0b29sIHBy b3ZpZGVkIGJ5IE1SVC1GUlIgZm9yIGtlZXBpbmcgYmFja3VwIHRyYWZmaWMgb2ZmIG9mIGxvd2Vy IGJhbmR3aWR0aCBsaW5rcyBkdXJpbmcgZmFzdC1yZXJvdXRlIGV2ZW50cy4iDQoiTWFpbiIgb3Ig Ik9ubHkiPyBJZiBvdGhlcnMgdG9vbHMgYXJlIGVmZmVjdGl2ZSwgaXQgbWF5IGJlIHVzZWZ1bCB0 byBpbmRpY2F0ZSB0aGVtLg0KSW4gcGFydGljdWxhciwgaXQncyBub3Qgb2J2aW91cyB3aGV0aGVy IElHUCBjb3N0IGlzIHRha2VuIGludG8gYWNjb3VudCBhbmQgbWF5IGJlIHVzZWZ1bCB0byBnaXZl IHByZWZlcmVuY2UgdG8gc29tZSBiYWNrdXAgcGF0aC4gSWYgbm90LCBpdCBtYXkgYmUgdXNlZnVs IHRvIGluZGljYXRlIHRoYXQgdGhlIGJhY2t1cCBwYXRoIHdpbGwgbm90IChzaWduaWZpY2FudGx5 KSB0YWtlIGludG8gYWNjb3VudCB0aGUgSUdQIG1ldHJpY3MgKGUuZy4gZGVsYXksIGJhbmR3aWR0 aCwgZGlzdGFuY2UsIGNvc3QsIG9wZXJhdG9yIHByZWZlcmVuY2VzLi4uKQ0KLS0tDQoiVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbiBmb3IgSVAvTERQIGZhc3QtcmVyb3V0ZSBbUkZD NTcxNF0uIE1SVC1GUlIgY3JlYXRlcyB0d28gYWx0ZXJuYXRlIHRyZWVzIHNlcGFyYXRlIGZyb20g dGhlIHByaW1hcnkgbmV4dC1ob3AgZm9yd2FyZGluZyB1c2VkIGR1cmluZyBzdGFibGUgb3BlcmF0 aW9uLiINCk9uZSBvZiB0aGUgdHJlZSBtYXkgdXNlIHRoZSBwcmltYXJ5IG5leHQtaG9wIGFuZCBo ZW5jZSBpcyBub3QgdGhhdCBzZXBhcmF0ZS4NCi0tLQ0KIltUSS1MRkFdIGFpbXMgdG8gcHJvdmlk ZSINCkFsbCBGUlIgc29sdXRpb25zICJwcm92aWRlcyIgd2lsbCBUSS1MRkEgImFpbXMgdG8gcHJv dmlkZSIgOy0pIEFsdGhvdWdoIFRJLUxGQSBpcyBub3QgYSBXRyBkb2N1bWVudCwgSU1ITyB0aGUg ZG9jdW1lbnQgY291bGQgdXNlIHRoZSBzYW1lIGZvcm11bGF0aW9uIGZvciBhbGwgRlJSIHNvbHV0 aW9ucy4NCi0tLQ0KwqcxLjENCiJBc3ltbWV0cmljIGxpbmsgY29zdHMgYXJlIGFsc28gYSBjb21t b24gYXNwZWN0IG9mIG5ldHdvcmtzLiAgVGhlcmUNCiAgIGFyZSBhdCBsZWFzdCB0aHJlZSBjb21t b24gY2F1c2VzIGZvciB0aGVtLiAgRmlyc3QsIGFueSBicm9hZGNhc3QNCiAgIGludGVyZmFjZSBp cyByZXByZXNlbnRlZCBieSBhIHBzZXVkby1ub2RlIGFuZCBoYXMgYXN5bW1ldHJpYyBsaW5rDQog ICBjb3N0cyB0byBhbmQgZnJvbSB0aGF0IHBzZXVkby1ub2RlLiAgU2Vjb25kLCB3aGVuIHJvdXRl cnMgY29tZSB1cCBvcg0KICAgYSBsaW5rIHdpdGggTERQIGNvbWVzIHVwLCBpdCBpcyByZWNvbW1l bmRlZCBpbiBbUkZDNTQ0M10gYW5kDQogICBbUkZDNjk4N10gdGhhdCB0aGUgbGluayBtZXRyaWMg YmUgcmFpc2VkIHRvIHRoZSBtYXhpbXVtIGNvc3Q7IHRoaXMNCiAgIG1heSBub3QgYmUgc3ltbWV0 cmljIGFuZCBmb3IgW1JGQzY5ODddIGlzIG5vdCBleHBlY3RlZCB0byBiZS4gIg0KICAgDQpHaXZl biB0aGUgcHJldmlvdXMgRmlndXJlIDEsIEkgYXNzdW1lIHRoYXQgdGhlIHRhcmdldCBvZiB0aGUg Y29tbWVudCBpcyBUSS1MRkEgbGluayBwcm90ZWN0aW9uIHdpdGggMiBsYWJlbHMuIEluIHRoaXMg Y2FzZSwgMiBjb21tZW50czoNCi0gSUlOTSwgd2hhdCBpcyBuZWVkZWQgKGZvciB0aGUgcHJvb2Yp IGlzIHN5bW1ldHJpYyBjb3N0IGJldHdlZW4gX2ZvcndhcmRpbmdfIG5vZGVzLiBQc2V1ZG8tbm9k ZSB3b3VsZCBub3QgY291bnQvYmUgYW4gaXNzdWUuDQotIFRJLUxGQSBuZWVkcyBTZWdtZW50IFJv dXRpbmcgaW4gd2hpY2ggY2FzZSBMRFAgd291bGQgbm90IGJlIHVzZWQuIEhlbmNlIGl0IGRvZXMg bm90IHNlZW0gZmFpciB0byBhc3N1bWUgdGhhdCBMRFAtSUdQIHN5bmMgd291bGQgYmUgcHJlc2Vu dC4NCi0tLQ0KIldoZW4gYSBuZXR3b3JrIG5lZWRzIHRvIHVzZSBhIG1pY3JvLWxvb3AgcHJldmVu dGlvbiBtZWNoYW5pc20NCiAgIFtSRkM1NzE1XSBzdWNoIGFzIE9yZGVyZWQgRklCW1JGQzY5NzZd IG9yIE5lYXJzaWRlDQogICBUdW5uZWxpbmdbUkZDNTcxNV0sIHRoZW4gdGhlIHdob2xlIElHUCBh cmVhIG5lZWRzIHRvIGhhdmUgYWx0ZXJuYXRlcw0KICAgYXZhaWxhYmxlIg0KDQpJIHdvdWxkIHBy b3Bvc2UNCg0KIldoZW4gYSBuZXR3b3JrIHRvIHVzZSBPcmRlcmVkIEZJQltSRkM2OTc2XSBvciBO ZWFyc2lkZQ0KICAgVHVubmVsaW5nW1JGQzU3MTVdIGFzIGEgbWljcm8tbG9vcCBwcmV2ZW50aW9u IG1lY2hhbmlzbQ0KICAgW1JGQzU3MTVdLCB0aGVuIHRoZSB3aG9sZSBJR1AgYXJlYSBuZWVkcyB0 byBoYXZlIGFsdGVybmF0ZXMNCiAgIGF2YWlsYWJsZSINCiAgIA0KTW90aXZhdGlvbjogdGhlIHJl cXVpcmVtZW50IGZvciBGUlIgY29tZXMgZnJvbSB0aGVzZSAyIHNwZWNpZmljIHNvbHV0aW9ucywg bm90IGZyb20gImEgbWljcm8tbG9vcCBwcmV2ZW50aW9uIG1lY2hhbmlzbSIuIEkgd29uJ3QgYXJn dWUgd2hldGhlciB0aGUgb3JpZ2luYWwgdGV4dCBpcyBmaW5lIGZyb20gYW4gZW5nbGlzaCBzdGFu ZHBvaW50IChhcyBpdCB3ZWxsIGJleW9uZCBteSBza2lsbHMpLCBidXQgb25lIHJlYWRlciBjb3Vs ZCBtaXNpbnRlcnByZXQgaXQuDQotLS0NCiJBREFHOiAgIEFsbW9zdCBEaXJlY3RlZCBBY3ljbGlj IEdyYXBoIC0gYSBncmFwaCB0aGF0LCBpZiBhbGwgbGlua3MgaW5jb21pbmcgdG8gdGhlIHJvb3Qg d2VyZSByZW1vdmVkLCB3b3VsZCBiZSBhIERBRy4iDQpJdCdzIG5vdCBjbGVhciB0byBtZSB3aGF0 ICJ0aGUgcm9vdCIgaXMuIEl0IHNlZW1zIHRvIHJlZmVyIHRvICJhIGdyYXBoIiBhbmQgSSBjYW4n dCBmaW5kIGhvdyB0aGlzIHJvb3QgaXMgZGV0ZXJtaW5lZC4gTWF5IGJlIHlvdSBtZWFuIDpzL2dy YXBoL0RBRyAgYnV0IGV2ZW4gaW4gdGhpcyBjYXNlLCBpdCdzIG5vdCBvYnZpb3VzIHRvIG1lIHRo YXQgdGhlcmUgaXMgYSBzaW5nbGUgInJvb3QiLiAoc29ycnkgaWYgdGhpcyBpcyBvYnZpb3VzIGZv ciBldmVyeW9uZSBlbHNlLiBObyBuZWVkIHRvIGV4cGxhaW4gaXQgdG8gbWUuIEknbSBqdXN0IGNo ZWNraW5nIHRoYXQgdGhpcyBpcyB3ZWxsIGRlZmluZWQpDQotLS0NCsKnNi4xLjEuMQ0KIkhvd2V2 ZXIsIGl0DQogICByZWR1Y2VzIHRoZSBsYWJlbCBzcGFjZSBmb3Igb3RoZXIgdXNlcywgYW5kIGl0 IGluY3JlYXNlcyB0aGUgbWVtb3J5DQogICBuZWVkZWQgdG8gc3RvcmUgdGhlIGxhYmVscyBhbmQg dGhlIGNvbW11bmljYXRpb24gcmVxdWlyZWQgYnkgTERQIHRvDQogICBkaXN0cmlidXRlIEZFQy1s YWJlbCBiaW5kaW5ncy4iDQoNCkl0IGFsc28gaW5jcmVhc2UgdGhlIHRpbWUgbmVlZGVkIHRvIGlu c3RhbGwgdGhlIEZSUiBlbnRyaWVzIGluIHRoZSBGSUIgaGVuY2UgdGhlIHRpbWUgbmVlZGVkIGJl Zm9yZSB0aGUgbmV4dCBmYWlsdXJlIG1heSBiZSBwcm90ZWN0ZWQuDQotLS0NCltSRkM3MzA3XSAo TERQIE1UKSBpcyBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvciBib3RoIExEUCBhbmQgSVAgdHJh ZmZpYy4gSXQgbWF5IGV2ZW50dWFsbHkgYmUgc2VlbiBhcyBhIF9ub3JtYXRpdmVfIHJlZmVyZW5j ZS4gDQotLS0NCiJBbGwgcm91dGVycyBpbiBhbiBNUlQgSXNsYW5kIE1VU1Qgc3VwcG9ydCB0aGUg c2FtZSBNUlQgcHJvZmlsZS4iDQoNCm9rLCBidXQgSU1ITyB0aGlzIGlzIG1vcmUgYSBtYXR0ZXIg b2YgZGVmaW5pdGlvbiB0aGFuIGEgbWF0dGVyIG9mIGJlaGF2aW9yIHRoYXQgTVVTVCBiZSBlbmZv cmNlZC4gU28gSSB3b3VsZCByYXRoZXIgaGF2ZSBhIGRlZmluaXRpb24gb2YgYW4gTVJUIElzbGFu ZC4gKGUuZy4gQW4gTVJUIElzbGFuZCBpcyBkZWZpbmVkIGFzIHRoZSBzZXQgb2Ygcm91dGVycyBz dXBwb3J0aW5nIHRoZSBzYW1lIE1SVCBwcm9maWxlLCBpbiB0aGUgc2FtZSBJR1AgYXJlYS9sZXZl bCBhbmQgdGhlIGJpLWRpcmVjdGlvbmFscyBsaW5rcyBpbnRlcmNvbm5lY3RpbmcgdGhvc2Ugcm91 dGVycywiLg0KLS0tDQrCpyA3LjIgIkEgZ2l2ZW4gcm91dGVyIGNhbiBzdXBwb3J0IG11bHRpcGxl IE1SVCBwcm9maWxlcyBhbmQgcGFydGljaXBhdGUgaW4gbXVsdGlwbGUgTVJUIElzbGFuZHMuIiBb Li4uXSAiTm90ZSB0aGF0IGEgcm91dGVyIG1heSBhZHZlcnRpc2Ugc3VwcG9ydCBmb3IgbXVsdGlw bGUgZGlmZmVyZW50IE1SVCBwcm9maWxlcy4iDQoNCklNSE8gdGhlIHNlY29uZCBzZW50ZW5jZSBp cyByZWR1bmRhbnQgYW5kIGNvdWxkIGJlIHJlbW92ZWQuDQotLS0NCsKnOC4zICJ0aGUgbW9zdCBw cmVmZXJyZWQgR0FEQUcgUm9vdCBTZWxlY3Rpb24gUHJpb3JpdHkNCiAgICAgIGFkdmVydGlzZWQg KGNvcnJlc3BvbmRpbmcgdG8gdGhlIGxvd2VzdCBudW1lcmljYWwgdmFsdWUgb2YgR0FEQUcNCiAg ICAgIFJvb3QgU2VsZWN0aW9uIFByaW9yaXR5KSINCg0KRG8geW91IG1lYW4gdGhhdCB0aGUgX21v c3QgcHJlZmVycmVkXyBpcyB0aGUgbm9kZSBhZHZlcnRpc2luZyB0aGUgX2xvd2VzdCBwcmlvcml0 eV8/IFRoaXMgZG9lcyBub3Qgc2VlbSBpbnR1aXRpdmUgdG8gbWUuIElmIHNvLCBJTUhPIHRoaXMg c2hvdWxkIGJlIHNwZWNpZmllZCBjbGVhcmx5IHNvbWV3aGVyZSwgbm90IGp1c3QgYmV0d2VlbiBi cmFja2V0cy4JQnV0IEkgd291bGQgcmF0aGVyIGZhdm9yaW5nIGEgaW50dWl0aXZlIGJlaGF2aW9y IChlLmcuIGlmIGxvd2VzdCBudW1lcmljYWwgdmFsdWUgaXMgcHJlZmVyZWQsIHVzZSB0aGUgd29y ZCAiQ29zdCIgb3IgIk1ldHJpYyIgcmF0aGVyIHRoYW4gIlByaW9yaXR5Ii4gSWYgIlByaW9yaXR5 IiBpcyBrZXB0LCBwcmVmZXIgdGhlIGhpZ2hlc3QgdmFsdWUuICANCi0tDQrCpzYuMS4xLjQgDQoi SWYgYSByb3V0ZXIgc3VwcG9ydHMgYSBwcm9maWxlIHRoYXQgaW5jbHVkZXMgdGhlIE1SVCBMRFAg TGFiZWwgb3B0aW9uDQogICBmb3IgTVJUIHRyYW5zaXQgZm9yd2FyZGluZyBtZWNoYW5pc20sIHRo ZW4gaXQgTVVTVCBzdXBwb3J0IG9wdGlvbiAxQSwNCiAgIHdoaWNoIGVuY29kZXMgdG9wb2xvZ3kt c2NvcGVkIEZFQ3MgdXNpbmcgYSBzaW5nbGUgbGFiZWwuIg0KDQpvay4gQnV0IGluIHRoaXMgY29u ZGl0aW9uLCBJJ20gbm90IHN1cmUgdG8gc2VlIGEgcmVhc29uIHdoeSBhbnlvbmUgd291bGQgaW1w bGVtZW50IG9wdGlvbiAxQiBpbiBhZGRpdGlvbi4gSW4gd2hpY2ggY2FzZSwgaXQgbWF5IGhhdmUg c2ltcGxpZmllZCB0aGUgc3BlYyB0byBqdXN0IG1vdmUgb3B0aW9uIDFCIGluIGFwcGVuZGl4IGFu ZCBoZW5jZSByZW1vdmUgTVJUIExEUCBsYWJlbCBvcHRpb25zLg0KLS0NCsKnMTANCiAiU2Vjb25k LCB0aGlzIGFsbG93cyBmYWlsdXJlcyB0aGF0IG1pZ2h0IGFwcGVhciBpbiBtdWx0aXBsZSBhcmVh cw0KICAgKGUuZy4gIEFCUi9MQlIgZmFpbHVyZXMpIHRvIGJlIHNlcGFyYXRlbHkgaWRlbnRpZmll ZCBhbmQgcmVwYWlyZWQNCiAgIGFyb3VuZC4gIFRoaXJkLCB0aGUgcGFja2V0IGNhbiBiZSBmYXN0 LXJlcm91dGVkIGFnYWluLCBpZiBuZWNlc3NhcnksDQogICBkdWUgdG8gYSBmYWlsdXJlIGluIGEg ZGlmZmVyZW50IGFyZWEuIg0KDQpJdCdzIG5vdCBvYnZpb3VzIHRvIG1lIHdoeSB0aGUgc2Vjb25k IGFuZCB0aGlyZCByZWFzb25zIGFyZSByZWFsbHkgZGlmZmVyZW50Lg0KLS0tDQrCpzEwDQoiICAg QW4gQUJSL0xCUiB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IG9uIE1SVC1SZWQgb3IgTVJULUJsdWUg dG93YXJkcw0KICAgZGVzdGluYXRpb24gWiBzaG91bGQgY29udGludWUgdG8gZm9yd2FyZCB0aGUg cGFja2V0IGFsb25nIE1SVC1SZWQgb3INCiAgIE1SVC1CbHVlIG9ubHkgaWYgdGhlIGJlc3Qgcm91 dGUgdG8gWiBpcyBpbiB0aGUgc2FtZSBhcmVhIGFzIHRoZQ0KICAgaW50ZXJmYWNlIHRoYXQgdGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQgb24uICAgDQoNClRoaXMgc2VlbXMgYSBiaXQgT1NQRiBzcGVj aWZpYy4gV2hhdCBhYm91dCBJUy1JUz8gSW4gcGFydGljdWxhciB3aGVuIHNvbWUgcm91dGVycyBt YXkgYmUgaW4gYm90aCBsZXZlbHMuDQogICANCklkZW0gaW4gwqcxMC4xOg0KIiBUbyB0aG9zZSBy b3V0ZXJzIGluIHRoZSBzYW1lIGFyZWEgYXMgdGhlIGJlc3Qgcm91dGUgdG8gdGhlDQogICBkZXN0 aW5hdGlvbiwgdGhlIEFCUi9MQlIgYWR2ZXJ0aXNlcyB0aGUgZm9sbG93aW5nIEZFQy1sYWJlbCBi aW5kaW5nczoiDQoNCkhvdyBkbyB0aGlzIGFwcGx5IHRvIElTLUlTIExCUj8gDQotLS0NCiAiVGhl IHVzZSBvZiB0aGUgUmFpbmJvdy1GRUMgYnkgdGhlIEFCUiBmb3Igbm9uLWJlc3QtYXJlYSBhZHZl cnRpc2VtZW50cyBpcyBSRUNPTU1FTkRFRC4iDQoNCiBJIGRvbid0IHNlZSB0aGUgYmFzaXMgZm9y IHRoaXMgcmVjb21tZW5kYXRpb24uIFRoaXMgY2hvaWNlIHNlZW1zIGRyaXZlbiBieSBzcGVjaWZp YyBpbXBsZW1lbnRhdGlvbnMuIE90aGVyIGltcGxlbWVudGF0aW9ucyBtYXkgaGF2ZSBubyByZWFz b24gdG8gc2VuZCB0aGUgUmFpbmJvdy1GRUMuDQogSU1PLCBpdCB3b3VsZCBiZSBlbm91Z2ggdG8g c2F5ICJhIHJvdXRlciB0aGF0IHN1cHBvcnRzIHRoZSBMRFAgTGFiZWwgTVJUIEZvcndhcmRpbmcg TWVjaGFuaXNtIE1VU1QgYmUgYWJsZSB0byByZWNlaXZlIGFuZCBjb3JyZWN0bHkgaW50ZXJwcmV0 IHRoZSBSYWluYm93LUZFQy4iIHdoaWNoIGlzIGFscmVhZHkgc2FpZC4gSGVuY2UgSSB3b3VsZCBw cm9wb3NlOg0KDQogT0xEOg0KICAgIFRoZSB1c2Ugb2YgdGhlIFJhaW5ib3ctRkVDIGJ5IHRoZSBB QlIgZm9yIG5vbi1iZXN0LWFyZWENCiAgIGFkdmVydGlzZW1lbnRzIGlzIFJFQ09NTUVOREVELiAg QW4gQUJSIE1BWSBhZHZlcnRpc2UgdGhlIGxhYmVsIGZvcg0KICAgdGhlIGRlZmF1bHQgdG9wb2xv Z3kgaW4gc2VwYXJhdGUgTVJULUJsdWUgYW5kIE1SVC1SZWQgYWR2ZXJ0aXNlbWVudHMuDQogICBI b3dldmVyLCBhIHJvdXRlcg0KIA0KIE5FVzoNCiAgIEFuIEFCUiBtYXkgY2hvb3NlIHRvIGVpdGhl ciBhZHZlcnRpc2UgdGhlIFJhaW5ib3ctRkVDIG9yIGFkdmVydGlzZSBzZXBhcmF0ZSBNUlQtQmx1 ZSBhbmQgTVJULVJlZCBhZHZlcnRpc2VtZW50cy4gVGhpcyBpcyBhIGxvY2FsIGNob2ljZS4NCiAg IEEgcm91dGVyDQoNCkluIHdoaWNoIGNhc2UsIHNlY3Rpb24gMTAuMSB3b3VsZCBuZWVkIHRvIGJl IHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGlzLiAgIA0KLS0tDQrCpzE2IElBTkENCkluIGRyYWZ0LWhh YXMtY29kZS1wb2ludC1yZXNlcnZhdGlvbi1iY3AsIEplZmYgcHJvcG9zZWQgdG8gcmVzZXJ2ZSB0 aGUgbGFzdCBjb2RlIHBvaW50ICgyNTUpIHRvIGFsbG93IGZvciBmdXR1cmUgZXh0ZW5zaW9uLiBX aGlsZSBJJ20gbm90IHN1cmUgdGhpcyB3b3VsZCBiZSBuZWVkZWQgZm9yIE1SVCBwcm9maWxlcywg dGhpcyB3b3VsZCBhbHNvIGNhdXNlIG5vIGhhcm0uDQoNCg0KTml0czoNCi0gTEZBIGltcG9zZXMg bm8gYWRkaXRpb25hbCBsYWJlbHMgaW1wb3NlZA0KdG9vIG1hbnkgImltcG9zZSI/DQotIDpzL0lT SVMvSVMtSVMNCi0gOnMvaW1wbG1lbnRhdGlvbnMvaW1wbGVtZW50YXRpb25zDQoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoK Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpU aGFuayB5b3UuCgo=