idnits 2.17.1 draft-madhukar-ospf-agr-asymmetric-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 109 has weird spacing: '...ould be suppo...' == Line 152 has weird spacing: '...ability draf...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Jun 16, 2013) is 3967 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Unused Reference: 'KEYWORDS' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 266, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-02 -- Obsolete informational reference (is this intentional?): RFC 4813 (Obsoleted by RFC 5613) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Madhukar Anand 3 Hasmit Grover 4 Abhay Roy 5 Intended Status: Proposed Standard Cisco Systems 6 Expires: Nov 16, 2013 Jun 16, 2013 8 Asymmetric OSPF Hold Timer 9 draft-madhukar-ospf-agr-asymmetric-01 11 Abstract 13 Current OSPF standard requires that the HELLO/Dead interval be 14 symmetric on either side of the link in order to maintain adjacency. 15 There are many scenarios in which this may not be desirable. This 16 memo describes a technique to allow OSPF adjacency to be maintained 17 with asymmetric values of the OSPF Dead interval. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1 Sending HELLOs with Asymmetric Hold Timers. . . . . . . . . 4 61 2.2 Receiving HELLOs with Asymmetric Hold Timer Values. . . . . 5 62 4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 6 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 65 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 66 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 67 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 69 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1 Introduction 74 With networking infrastructure becoming critical for businesses, many 75 networking vendors now design their routing software implementations 76 to deliver high availability and built-in redundancy. To meet these 77 requirements, routing processes support features such as crash 78 recovery and in-service software upgrades. For control plane 79 protocols such as OSPF, this typically translates to recovering and 80 restoring state across process restarts. Crash recovery and upgrades 81 via state restoration has advantages over graceful restart in that, 82 there is no control traffic between neighbors, and there is no 83 requirement of the topology being intact during this window. 85 One of the implications of such busy periods of state restoration in 86 a process is that, the process may not be able to sustain the rate of 87 sending HELLOs across all its interfaces. In a controlled restart 88 scenario (such as OSPF Graceful restart), the router is able to ask 89 for a grace period by flooding out opaque LSAs indicating that it is 90 restarting. In case of upgrades and restarts with state restoration, 91 (i.e., not involving a graceful restart), this is not possible. 93 An alternative, in these situations, is for the router to be able to 94 send HELLOs at a reduced frequency during this window, and resume the 95 normal (configured) functionality after its recovery or upgrade. If 96 this alternative is to be supported, OSPF routers in the network 97 would have to relax the requirement that HELLO and dead intervals be 98 the same on either side of the network. 100 Yet another scenario where such asymmetric HELLO intervals may be 101 desirable would be the case where routers of disparate load and 102 configuration form an adjacency. For example, the number of 103 adjacencies in a stub area router, and an adjacent ABR can 104 potentially differ by an order of magnitude. Another example is in 105 the case of a hub and spoke topology. The hub router is definitely 106 more loaded than the spoke router. Further, in such topologies it may 107 be desirable that the failure of a non-central (leaf node) router is 108 to be detected faster, so that the routers in the center of the 109 topology can possibly reroute traffic. This could be supported, for 110 instance, by having the non-central routers send HELLOs at a much 111 faster rate than the central routers. 113 Finally, OSPFv3 Auto-configuration [OSPFV3-AUTOCONFIG] calls for 114 flexibility in OSPFv3 HELLO and Dead intervals (See Sec 3 of [OSPFV3- 115 AUTOCONFIG]). These requirements can be easily met by implementing 116 the proposal here. 118 1.1 Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2 Proposed Solution 125 We expect that OSPF interface on which an asymmetric hold timer is to 126 be supported have appropriate CLI configuration to accept the normal 127 (symmetric), and alternate (potentially asymmetric) values of Dead 128 interval. Alternatively, the asymmetric value of Dead interval could 129 also be derived through other means. Henceforth, we refer to the 130 (potentially) asymmetric dead interval advertised by a router as the 131 OSPF hold interval for that router on the receiving link. 133 Another requirement is that, all routers in the network that form an 134 OSPF adjacency have this capability, i.e., understand and support the 135 changes proposed in this document. The latter requirement would 136 prevent OSPF routers not supporting this feature from forming 137 adjacencies with routers that are already running with asymmetric 138 DEAD intervals, and adjacency down would be detected. 140 2.1 Sending HELLOs with Asymmetric Hold Timers. 142 Routers that wish to set asymmetric hold timer in OSPF would make 143 use of the LLS block (RFC 4813) attached to the HELLO packet, with 144 the following changes. 146 1. The router will set the L-bit indicating the presence of the LLS 147 block. The router will also set the LLS type to 0 (reserved), and use 148 the following extended options bit (0x00000003) in the EO-TLV, 149 introduced for this purpose. 151 Extended Options Bit Name Reference 152 0x00000003 Asymmetric Hello capability draft-madhukar- 153 ospf-asymmetric-01 155 2. The value of the hold timer would be specified in a LLS TLV. Note 156 that the LLS TLV types are maintained by the IANA, and this document 157 proposes the introduction of a new TLV. The type field of the new TLV 158 is proposed to be 18, the length of the value is 4 bytes. 160 0 1 2 3 162 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | 18 | 4 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | OSPF Hold Timer Value | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 3. Routers must set the HELLO and Dead interval values carried in the 174 OSPF HELLO packet to zero. 176 4. To stop advertising the asymmetric hold timer value, routers will 177 simply revert back to advertising configured (non-zero) values of 178 HELLO and dead interval in the OSPF Hello packet. 180 The mechanism of sending HELLOs would remain as specified in Sec 9.5 181 of RFC 2328. 183 2.2 Receiving HELLOs with Asymmetric Hold Timer Values. 185 The processing of an incoming HELLO packet with the L-bit set, and 186 containing the extended options set for alternate HELLOs would follow 187 the specification in Sec 10.5 of RFC 2328 with one modification. 189 1. Routers that recognize this new extended options will set the 190 value of the neighbor dead interval to the value specified in the LLS 191 block TLV, but only if BOTH the HELLO and dead interval are set to 192 zero in the OSPF HELLO packet. 194 2. Routers that do not recognize the extended options would drop 195 adjacency as it will not match with the configured (or default) HELLO 196 or dead interval as specified in Sec 10.5 of RFC 2328. 198 Note that, routers can stop appending the LLS block in their HELLO, 199 and the neighbors will simply (re)start using the value specified in 200 the HELLO packet. 202 4 Discussion 204 It is possible to use Bidirectional Forwarding Detection (BFD) [RFC 205 5880] to alleviate some of the concerns in the use-cases identified 206 above. Relying entirely on BFD without OSPF HELLOs is not a 207 possibility given that OSPF HELLOs are still used for discovery of 208 neighbors. The BFD approach has its own shortcomings such as limited 209 cross-vendor and cross-platform support and also performance 210 implications, especially with increasing scale requirements. In any 211 case, BFD can be made to work in conjunction with the proposal in 212 this document to achieve the best possible network performance. It is 213 intended that the proposal for asymmetric hold timer would work 214 independent of BFD deployment considerations, and could also help in 215 new applications where it may be desirable to support asymmetric and 216 possibly dynamic dead interval values (e.g., OSPFv3 Auto- 217 Configuration, [OSPFV3-AUTOCONFIG]). 219 5 Acknowledgements 221 The authors would like to thank Paul Wells for careful review of 222 this document. We would also like to thank Anton Smirnov for 223 reviewing this document and bringing the BFD alternative to our 224 attention. 226 6 Backward Compatibility 228 No modifications to OSPF packet formats are proposed here. The new 229 EO-TLV introduced here is standard OSPF because LLS-incapable routers 230 will not consider the extra data after the packet; i.e., the LLS data 231 block will be ignored by routers that do not support the LLS 232 extension. 234 7 Security Considerations 236 The function described in this document does not create any new 237 security issues for the OSPF protocol. 239 8 IANA Considerations 241 Please refer to the "IANA Considerations" section of [RFC4813] for 242 more information on the Extended Options bit definitions. 244 9 References 246 9.1 Normative References 248 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 253 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 254 IANA Considerations Section in RFCs", RFC 2434, October 255 1998. 257 9.2 Informative References 259 [OSPFV3-AUTOCONFIG] Lindem, A., and Arkko, J., "OSPFv3 Auto- 260 Configuration", draft-ietf-ospf-ospfv3-autoconfig-02.txt, 261 Apr 15, 2013 (work in progress). 263 [RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. 264 Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007. 266 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding 267 Detection", RFC 5880, June 2010. 269 Authors' Addresses 271 Madhukar Anand 272 Cisco Systems 273 170 W Tasman Drive 274 San Jose, CA 95138 275 US 276 Email: anandmkr@cisco.com 278 Hasmit Grover 279 Cisco Systems 280 170 W Tasman Drive 281 San Jose, CA 95138 282 US 284 Email: hasmit@cisco.com 286 Abhay Roy 287 Cisco Systems 288 170 W Tasman Drive 289 San Jose, CA 95138 290 US 292 Email: akr@cisco.com