Network Working Group S. Bryant Internet-Draft Huawei Technologies Intended status: Standards Track A. Atlas Expires: April 15, 2017 C. Bowers Juniper Networks October 12, 2016 Synchronisation of Network Parameters draft-bryant-rtgwg-param-sync-00 Abstract This document describes a mechanism for a link state routing protocol to coordinate the value of a network-wide parameter. The document also defines the solution to one specific case: the agreement of a common convergence timer value for use in network convergence. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 15, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bryant, et al. Expires April 15, 2017 [Page 1] Internet-Draft Parameter Sync October 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 4.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Convergence Time . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Required Properties . . . . . . . . . . . . . . . . . . . 5 5.2. Definition of the Convergence Timer . . . . . . . . . . . 5 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. Network Wide Parameter . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction There exist use cases where it desirable for a network to use a common value for a parameter across all nodes. In the past, these use cases have been addressed by setting the parameter to a constant value in the protocol definition itself, or by requiring that the same value of the parameter be configured at every node. Setting the parameter to a constant value in the protocol definition makes it very difficult to change the parameter, since a change would require formal modification to the protocol. In practice, such a change is impractical, so the constant value needs to be chosen conservatively. This may impose a fundamental restriction on the eventual use of the protocol. Manual or "static" configuration of the parameter is fraught for two reasons. First, it is always difficult to ensure that the correct value is installed in all of the routers. Second, if any change is introduced into the network that results in a need to change the value (for example due to a change in hardware or software version) then all of the routers need to be reconfigured to use the new parameter value. Bryant, et al. Expires April 15, 2017 [Page 2] Internet-Draft Parameter Sync October 2016 This document describes a protocol extension that propagates a parameter throughout the flooding domain. The method of choosing between one or more different advertised values, the flooding scope, and the action to be taken when the parameter changes MUST be provided in the definition of the parameter type. This document also creates one parameter type: Convergence Timer intended for use in IP Fast-reroute applications [RFC5714] [RFC5715]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 3. Mechanism The following mechanism is specified. A new information element is introduced into the routing protocol that specifies the parameter. Each router is expected to advertise a specific value of the parameter, which that router determines based mainly on considerations local to that router. In general, different routers in the flooding domain will advertise different values of the parameter. A router receiving the parameter values advertised by all routers in the flooding domain will use a well-defined method to select the operational value of the parameter that it uses in the running of the protocol. All routers MUST use the same method applied to the same set of advertised parameter values. All routers SHALL therefore choose the same operational value for the parameter. Note the operational value for the parameter selected SHOULD NOT directly affect the value for the parameter advertised a router. The method of selecting from a range of advertised parameter values MUST be provided in the parameter definition. The definition of the parameter MUST specify the action to be taken when a new parameter value is advertised that would cause a change in the selected value. The definition of the parameter MUST specify the action to be taken in the legacy/migration case, where not all routers advertise the parameter. Bryant, et al. Expires April 15, 2017 [Page 3] Internet-Draft Parameter Sync October 2016 4. Protocol Details This section describes the protocol extensions needed to implement this functionality. 4.1. ISIS A new Network Wide Parameter (NWP) sub-TLV is introduced into the IS- IS Router CAPABILITY TLV (TLV #242 defined in [RFC4971]). The setting of the S-bit in TLV #242 (indicating whether the parameter should be leaked between levels) MUST be included in the specific NWP definition. Network Wide Parameter Sub-TLV TYPE: Length: As defined by parameter definition. Sub-sub-TLV NWP Type: (16 bits) as defined in NWP Registry NWP Value: As defined by parameter definition 4.2. OSPF THIS NEEDS CHECKING OVER BY AN OSPF EXPERT A new OSPF Router Information LSA TLV is defined. This may be carried in a type 10 or type 11 OSPF Opaque LSA depending on the required flooding scope. Network Wide Parameter TLV TYPE: Length: As defined by parameter definition. Sub-TLV NWP Type: (16 bits) as defined in NWP Registry NWP Value: As defined by parameter definition 5. Convergence Time Routers running a fast-reroute mechanism such as Maximally Redundant Tree (MRT) [RFC7812] fast re-route require a network wide convergence time value so that know how long they need continue using the repair path before it is safe to use the base path. This time is set to be the worst case time that any router will take to calculate the new topology, and to make the necessary changes to the FIB. The time taken by a router to complete each phase of the transition will be dependent on the size of the network and the design and Bryant, et al. Expires April 15, 2017 [Page 4] Internet-Draft Parameter Sync October 2016 implementation of the router. It can therefore be expected that the optimum delay will need to be tuned from time to time as the network evolves. 5.1. Required Properties The Convergence Time mechanism MUST have the following properties: o The operational convergence delay time MUST be consistent among all routers that are converging on the new topology. o The operational convergence delay time MUST be the highest delay time advertised by any router in the new topology. o The mechanism MUST increase the delay when a new router in introduced to the network that requires a higher delay than is currently in use. o When the router that had the longest delay requirements is removed from the topology, the convergence delay timer value MUST, within some reasonable time, be reduced to the longest delay required by the remaining routers. o It MUST be possible for a router to change the convergence delay timer value that it requires. o A router which is in multiple routing areas, or is running multiple routing protocols MAY signal a different loop-free convergence delay for each area. How a router determines the time that it needs to execute each convergence phase is an implementation issue, and outside the scope of this specification. However a router that dynamically determines its proposed delay value must do so in such a way that it does not cause the synchronized value to continually fluctuate. 5.2. Definition of the Convergence Timer The NWP value is 16 bits and is specified in milliseconds; this gives a maximum value of about 65s. The NWP value selected is the largest value advertised. If a routing protocol message is issued that changes the Convergence Timer value, but does not change the topology, the new timer value MUST be taken into consideration during the next network transition, but MUST NOT instigate a new transition. Bryant, et al. Expires April 15, 2017 [Page 5] Internet-Draft Parameter Sync October 2016 If a routing protocol message is issued that changes both the Convergence Timer value and the topology, a transition is instigated and the new timer value MUST be taken into consideration. The convergence mechanism MUST specify the action to be taken if a timer change (only) message and a topology change message are independently generated during the hold-off time. All routers that support controlled convergence MUST advertise an NWP specifying their required Convergence Time. If the parameter is carried in ISIS the S-bit is set to zero indicating that the Convergence Timer NWP MUST NOT be leaked between levels. If the parameter is carried in OSPF it is only carried in a type 10 Opaque LSA which prevents propagation outside the OSPF area. 6. IANA considerations 6.1. ISIS IANA is requested to allocate a new Sub-TLVs for TLV 242 from the IS- IS TLV Codepoints name space. Value Description Reference ---------------------------------------------- TBD Network Wide Parameter This Document 6.2. OSPF IANA is requested to allocate a new OSPF Router Information (RI) TLV from the Open Shortest Path First (OSPF) Parameters name space Value TLV Name Reference -------------------------------------------------- TBD Network Wide Parameter This document A value in the range 12 to 32767 is requested. 6.3. Network Wide Parameter IANA is requested to create a new Network Wide Parameter Registry within its own name space, and to allocate one value from it. Bryant, et al. Expires April 15, 2017 [Page 6] Internet-Draft Parameter Sync October 2016 Value Name Reference ------------------------------------------------ 0 Reserved This document 1 Convergence Timer This document 2..65535 Reserved This document Allocations within this registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG. 7. Security Considerations The introduction of this parameter advertizing mechanism does not introduce a significant vulnerability into the base routing protocol and is secured in exactly the same way as the other TLVs that are carried. A rouge router deliberately introducing an anomalous parameter value is just as capable of introducing many other anomalies into the routing domain. As far as possible, care should be taken to validate that the parameter is reasonable. In the specific case of the Convergence Time NWP, the following considerations apply. If an abnormally large timer value is proposed by a router, the there is a danger that the convergence process will take an excessive time. If during that time the routing protocol signals the need for another transition, the transition will be abandoned and the default best case (traditional) convergence mechanism used. The maximum value that can be specified in the LSP/LSA is limited through the use of a 16 bit field to about 65 seconds. 8. Contributing Authors Mike Shand Independent mike@mshand.org.uk 9. References Bryant, et al. Expires April 15, 2017 [Page 7] Internet-Draft Parameter Sync October 2016 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, DOI 10.17487/RFC4971, July 2007, . 9.2. Informative References [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, . [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2010, . [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, . Authors' Addresses Stewart Bryant Huawei Technologies Email: stewart.bryant@gmail.com Alia Atlas Juniper Networks Email: akatlas@gmail.com Chris Bowers Juniper Networks Email: cbowers@juniper.net Bryant, et al. Expires April 15, 2017 [Page 8]