INTERNET-DRAFT Madhukar Anand Hasmit Grover Abhay Roy Intended Status: Proposed Standard Cisco Systems Expires: Nov 16, 2013 Jun 16, 2013 Asymmetric OSPF Hold Timer draft-madhukar-ospf-agr-asymmetric-01 Abstract Current OSPF standard requires that the HELLO/Dead interval be symmetric on either side of the link in order to maintain adjacency. There are many scenarios in which this may not be desirable. This memo describes a technique to allow OSPF adjacency to be maintained with asymmetric values of the OSPF Dead interval. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 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 Anand et al. Expires Jul 25, 2013 [Page 1] INTERNET DRAFT Asymmetric OSPF Hold Timer 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Sending HELLOs with Asymmetric Hold Timers. . . . . . . . . 4 2.2 Receiving HELLOs with Asymmetric Hold Timer Values. . . . . 5 4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Anand et al. Expires Jul 25, 2013 [Page 2] INTERNET DRAFT Asymmetric OSPF Hold Timer 1 Introduction With networking infrastructure becoming critical for businesses, many networking vendors now design their routing software implementations to deliver high availability and built-in redundancy. To meet these requirements, routing processes support features such as crash recovery and in-service software upgrades. For control plane protocols such as OSPF, this typically translates to recovering and restoring state across process restarts. Crash recovery and upgrades via state restoration has advantages over graceful restart in that, there is no control traffic between neighbors, and there is no requirement of the topology being intact during this window. One of the implications of such busy periods of state restoration in a process is that, the process may not be able to sustain the rate of sending HELLOs across all its interfaces. In a controlled restart scenario (such as OSPF Graceful restart), the router is able to ask for a grace period by flooding out opaque LSAs indicating that it is restarting. In case of upgrades and restarts with state restoration, (i.e., not involving a graceful restart), this is not possible. An alternative, in these situations, is for the router to be able to send HELLOs at a reduced frequency during this window, and resume the normal (configured) functionality after its recovery or upgrade. If this alternative is to be supported, OSPF routers in the network would have to relax the requirement that HELLO and dead intervals be the same on either side of the network. Yet another scenario where such asymmetric HELLO intervals may be desirable would be the case where routers of disparate load and configuration form an adjacency. For example, the number of adjacencies in a stub area router, and an adjacent ABR can potentially differ by an order of magnitude. Another example is in the case of a hub and spoke topology. The hub router is definitely more loaded than the spoke router. Further, in such topologies it may be desirable that the failure of a non-central (leaf node) router is to be detected faster, so that the routers in the center of the topology can possibly reroute traffic. This could be supported, for instance, by having the non-central routers send HELLOs at a much faster rate than the central routers. Finally, OSPFv3 Auto-configuration [OSPFV3-AUTOCONFIG] calls for flexibility in OSPFv3 HELLO and Dead intervals (See Sec 3 of [OSPFV3- AUTOCONFIG]). These requirements can be easily met by implementing the proposal here. 1.1 Terminology Anand et al. Expires Jul 25, 2013 [Page 3] INTERNET DRAFT Asymmetric OSPF Hold Timer 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 RFC 2119 [RFC2119]. 2 Proposed Solution We expect that OSPF interface on which an asymmetric hold timer is to be supported have appropriate CLI configuration to accept the normal (symmetric), and alternate (potentially asymmetric) values of Dead interval. Alternatively, the asymmetric value of Dead interval could also be derived through other means. Henceforth, we refer to the (potentially) asymmetric dead interval advertised by a router as the OSPF hold interval for that router on the receiving link. Another requirement is that, all routers in the network that form an OSPF adjacency have this capability, i.e., understand and support the changes proposed in this document. The latter requirement would prevent OSPF routers not supporting this feature from forming adjacencies with routers that are already running with asymmetric DEAD intervals, and adjacency down would be detected. 2.1 Sending HELLOs with Asymmetric Hold Timers. Routers that wish to set asymmetric hold timer in OSPF would make use of the LLS block (RFC 4813) attached to the HELLO packet, with the following changes. 1. The router will set the L-bit indicating the presence of the LLS block. The router will also set the LLS type to 0 (reserved), and use the following extended options bit (0x00000003) in the EO-TLV, introduced for this purpose. Extended Options Bit Name Reference 0x00000003 Asymmetric Hello capability draft-madhukar- ospf-asymmetric-01 2. The value of the hold timer would be specified in a LLS TLV. Note that the LLS TLV types are maintained by the IANA, and this document proposes the introduction of a new TLV. The type field of the new TLV is proposed to be 18, the length of the value is 4 bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 4 | Anand et al. Expires Jul 25, 2013 [Page 4] INTERNET DRAFT Asymmetric OSPF Hold Timer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Hold Timer Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Routers must set the HELLO and Dead interval values carried in the OSPF HELLO packet to zero. 4. To stop advertising the asymmetric hold timer value, routers will simply revert back to advertising configured (non-zero) values of HELLO and dead interval in the OSPF Hello packet. The mechanism of sending HELLOs would remain as specified in Sec 9.5 of RFC 2328. 2.2 Receiving HELLOs with Asymmetric Hold Timer Values. The processing of an incoming HELLO packet with the L-bit set, and containing the extended options set for alternate HELLOs would follow the specification in Sec 10.5 of RFC 2328 with one modification. 1. Routers that recognize this new extended options will set the value of the neighbor dead interval to the value specified in the LLS block TLV, but only if BOTH the HELLO and dead interval are set to zero in the OSPF HELLO packet. 2. Routers that do not recognize the extended options would drop adjacency as it will not match with the configured (or default) HELLO or dead interval as specified in Sec 10.5 of RFC 2328. Note that, routers can stop appending the LLS block in their HELLO, and the neighbors will simply (re)start using the value specified in the HELLO packet. Anand et al. Expires Jul 25, 2013 [Page 5] INTERNET DRAFT Asymmetric OSPF Hold Timer 4 Discussion It is possible to use Bidirectional Forwarding Detection (BFD) [RFC 5880] to alleviate some of the concerns in the use-cases identified above. Relying entirely on BFD without OSPF HELLOs is not a possibility given that OSPF HELLOs are still used for discovery of neighbors. The BFD approach has its own shortcomings such as limited cross-vendor and cross-platform support and also performance implications, especially with increasing scale requirements. In any case, BFD can be made to work in conjunction with the proposal in this document to achieve the best possible network performance. It is intended that the proposal for asymmetric hold timer would work independent of BFD deployment considerations, and could also help in new applications where it may be desirable to support asymmetric and possibly dynamic dead interval values (e.g., OSPFv3 Auto- Configuration, [OSPFV3-AUTOCONFIG]). Anand et al. Expires Jul 25, 2013 [Page 6] INTERNET DRAFT Asymmetric OSPF Hold Timer 5 Acknowledgements The authors would like to thank Paul Wells for careful review of this document. We would also like to thank Anton Smirnov for reviewing this document and bringing the BFD alternative to our attention. Anand et al. Expires Jul 25, 2013 [Page 7] INTERNET DRAFT Asymmetric OSPF Hold Timer 6 Backward Compatibility No modifications to OSPF packet formats are proposed here. The new EO-TLV introduced here is standard OSPF because LLS-incapable routers will not consider the extra data after the packet; i.e., the LLS data block will be ignored by routers that do not support the LLS extension. Anand et al. Expires Jul 25, 2013 [Page 8] INTERNET DRAFT Asymmetric OSPF Hold Timer 7 Security Considerations The function described in this document does not create any new security issues for the OSPF protocol. 8 IANA Considerations Please refer to the "IANA Considerations" section of [RFC4813] for more information on the Extended Options bit definitions. 9 References 9.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. 9.2 Informative References [OSPFV3-AUTOCONFIG] Lindem, A., and Arkko, J., "OSPFv3 Auto- Configuration", draft-ietf-ospf-ospfv3-autoconfig-02.txt, Apr 15, 2013 (work in progress). [RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010. Authors' Addresses Madhukar Anand Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Anand et al. Expires Jul 25, 2013 [Page 9] INTERNET DRAFT Asymmetric OSPF Hold Timer Email: anandmkr@cisco.com Hasmit Grover Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: hasmit@cisco.com Abhay Roy Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: akr@cisco.com Anand et al. Expires Jul 25, 2013 [Page 10]