idnits 2.17.1 draft-ietf-ospf-ospfv2-hbit-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2019) is 1589 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) ** Downref: Normative reference to an Informational RFC: RFC 6987 == Outdated reference: A later version (-28) exists of draft-ietf-idr-bgp-optimal-route-reflection-19 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF K. Patel 3 Internet-Draft Arrcus 4 Updates: 6987 (if approved) P. Pillay-Esnault 5 Intended status: Standards Track PPE Consulting 6 Expires: June 20, 2020 M. Bhardwaj 7 S. Bayraktar 8 Cisco Systems 9 December 18, 2019 11 Host Router Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-12 14 Abstract 16 The Open Shortest Path First Version 2 (OSPFv2) protocol does not 17 have a mechanism for a node to repel transit traffic if it is on the 18 shortest path. This document defines a bit (Host-bit) that enables a 19 router to advertise that it is a non-transit router. It also 20 describes the changes needed to support the H-bit in the domain. In 21 addition, this document updates RFC 6987 to advertise type-2 External 22 and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a 23 high cost in order to repel traffic effectively. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 20, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Host-bit Support . . . . . . . . . . . . . . . . . . . . . . 3 62 4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Auto Discovery and Backward Compatibility . . . . . . . . . . 6 64 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The OSPFv2 protocol specifies a Shortest Path First (SPF) algorithm 76 that identifies transit vertices based on their adjacencies. 77 Therefore, OSPFv2 does not have a mechanism to prevent traffic 78 transiting a participating node if it is a transit vertex in the only 79 existing or shortest path to the destination. The use of metrics to 80 make the node undesirable can help to repel traffic only if an 81 alternative better route exists. 83 A mechanism to move traffic away from the shortest path is 84 particularly useful for a number of use cases: 86 1. To gracefully isolate a router to avoid blackhole scenarios when 87 there is a reload and possible long reconvergence times. 89 2. Closet Switches are usually not used for transit traffic but need 90 to participate in the topology. 92 3. Overloaded routers could use such a capability to temporarily 93 repel traffic until they stabilize. 95 4. BGP Route reflectors known as virtual Route Reflectors (vRRs), 96 that are not in the forwarding path but are in central locations 97 such as data centers. Such Route Reflectors typically are used 98 for route distribution and are not capable of forwarding transit 99 traffic. However, they need to learn the OSPF topology to 100 perform SPF computation for optimal routes and reachability 101 resolution for its clients 102 [I-D.ietf-idr-bgp-optimal-route-reflection]. 104 This document describes the Host-bit (H-bit) functionality that 105 prevents other OSPFv2 routers from using the host router by excluding 106 it in path calculations for transit traffic in OSPFv2 routing 107 domains. If the H-bit is set then the calculation of the shortest- 108 path tree for an area, as described in section 16.1 of [RFC2328], is 109 modified by including a check to verify that transit vertices DO NOT 110 have the H-bit set (see Section 4). Furthermore, in order to repel 111 traffic effectively, [RFC6987] is updated so that type-2 External and 112 NSSA LSAs are advertised with a high cost (see Section 6). Open 113 Shortest Path First Version 3 defines an option bit for router-LSAs 114 known as the R-bit in [RFC5340] to support a similar functionality. 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 3. Host-bit Support 126 This document defines a new router-LSA bit known as the Host Bit or 127 the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit 128 set indicates that it MUST NOT be used as a transit router (see 129 Section 4) by other OSPFv2 routers in the area supporting the 130 functionality. 132 If the H-bit is not set then backwards compatibility is achieved as 133 the behavior will be the same as in [RFC2328]. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | LS age | Options | 1 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Link State ID | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Advertising Router | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | LS sequence number | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | LS checksum | length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |H|0|0|N|W|V|E|B| 0 | # links | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Link ID | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Link Data | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type | # TOS | metric | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | ... | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | TOS | 0 | TOS metric | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Link ID | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Link Data | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | ... | 166 Figure 1: OSPF Router-LSA 168 Bit H is the high-order bit of the OSPF flags as shown below. 170 0 1 2 3 4 5 6 7 171 +-+-+-+-+-+-+-+-+ 172 |H|0|0|N|W|V|E|B| 173 +-+-+-+-+-+-+-+-+ 175 Figure 2: OSPF Router-LSA Option bits 177 When the H-bit is set, the OSPFv2 router is a Host (non-transit) 178 router and is incapable of forwarding transit traffic. In this mode, 179 the other OSPFv2 routers in the area MUST NOT use the host router for 180 transit traffic, but may send traffic to its local destinations. 182 An OSPFv2 router originating a router-LSA with the H-bit set MUST 183 advertise all its non-stub links with a link cost of MaxLinkMetric 184 [RFC6987]. 186 When the H-bit is set, an Area Border Router (ABR) MUST advertise the 187 same H-bit setting in its self-originated router-LSAs for all 188 attached areas. The consistency of the setting will prevent inter- 189 area traffic transiting through the router by suppressing 190 advertisement of prefixes from other routers in the area in its 191 summary LSAs. Only IPv4 prefixes associated with its local 192 interfaces MUST be advertised in summary-LSAs to provide reachability 193 to end hosts attached to a router with the H-bit set. 195 When the H-bit is set the host router cannot act as an AS Boundary 196 Router (ASBR). Indeed, ASBR are transit routers to prefixes that are 197 typically imported through redistribution of prefixes from other 198 routing protocols. Therefore, non-local IPv4 prefixes, e.g., those 199 imported from other routing protocols, SHOULD NOT be advertised in 200 AS-external-LSAs if the H-bit is set. Some use cases, such as an 201 overloaded router or a router being gracefully isolated, may benefit 202 from continued advertisement of non-local prefixes. In these cases, 203 the type 2-metric in AS-external-LSAs MUST be set to LSInfinity to 204 repel traffic.(see Section 6 of this document). 206 4. SPF Modifications 208 The SPF calculation described in section 16.1 [RFC2328] will be 209 modified to ensure that the routers originating router-LSAs with the 210 H-bit set will not be used for transit traffic. The Step 2 is 211 modified to include a check on H-bit as shown below. (Please note 212 all the sub-procedures of Step 2 remain unchanged and not included in 213 the excerpt below.) 214 2) Call the vertex just added to the 215 tree vertex V. Examine the LSA 216 associated with vertex V. This is 217 a lookup in the Area A's link state 218 database based on the Vertex ID. If 219 this is a router-LSA, and the H-bit 220 of the router-LSA is set, and 221 vertex V is not the root, then the 222 router should not be used for transit 223 and step (3) should be executed 224 immediately. If this is a router-LSA, 225 and bit V of the router-LSA (see 226 Section A.4.2) is set, set Area A's 227 TransitCapability to TRUE. In any case, 228 each link described by the LSA gives 229 the cost to an adjacent vertex. For 230 each described link, (say it joins 231 vertex V to vertex W): 233 5. Auto Discovery and Backward Compatibility 235 To reduce the possibility of any routing loops due to partial 236 deployment, this document defines an OSPF Router Information (RI) LSA 237 [RFC7770] capability. The RI LSA MUST be area-scoped. Bit: 239 Bit Capabilities 241 7 Host Router Support capability 243 Table 1: OSPF Router Information LSA Capabilities 245 Auto Discovery via announcement of the Host Router Support Capability 246 ensures that the H-bit functionality and its associated SPF changes 247 MUST only take effect if all the routers in a given OSPF area support 248 this functionality. 250 In normal operation, it is possible that the RI LSA will fail to 251 reach all routers in an area in a timely manner. For example, if a 252 new router without H-bit support joins an area that previously had 253 only H-bit capable routers with H-bit set then it may take some time 254 for the RI to propagate to all routers. While it is propagating, the 255 routers in the area will gradually detect the presence of a router 256 not supporting the capability and revert back to normal SPF 257 calculation. During the propagation time, the area as a whole is 258 unsure of the status of the new router, and that can cause temporary 259 transient loops. 261 The following recommendations will mitigate transient routing loops: 263 o Implementations are RECOMMENDED to provide a configuration 264 parameter to manually override enforcement of the H-bit 265 functionality in partial deployments where the topology guarantees 266 that OSPFv2 routers not supporting the H-bit do not compute routes 267 resulting in routing loops. 269 o All routers with the H-bit set MUST advertise all of the router's 270 non-stub links with a metric equal to MaxLinkMetric [RFC6987] in 271 its LSAs in order to avoid OSPFv2 (unless last resort) routers not 272 supporting the H-bit from attempting to use it for transit 273 traffic. 275 o All routers supporting the H-Bit MUST check the RI LSAs of all 276 nodes in the area to verify that all nodes support the H-Bit 277 before actively using the H-Bit feature. If any router does not 278 advertise the Host Router Support capability then the SPF 279 Modifications (Section 4) MUST NOT be used in the area. 281 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 283 When calculating the path to a prefix in an OSPF AS-External-LSA or 284 NSSA-LSA [RFC3101] with a Type-2 metric, the advertised Type-2 metric 285 is taken as more significant than the OSPF intra-area or inter-area 286 path. Hence, advertising the links with MaxLinkMetric as specified 287 in [RFC6987] does not discourage transit traffic when calculating AS 288 external or NSSA routes with Type-2 metrics. 290 Consequently, [RFC6987] is updated so that the Type-2 metric in any 291 self-originated AS-External-LSAs or NSSA-LSAs is advertised as 292 LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type-2 metric 293 MUST be set to LSInfinity. 295 7. IANA Considerations 297 This document requests the IANA to assign the 0x80 value to the Host- 298 Bit (H-bit)in the OSPFv2 Router Properties Registry 300 Value Description Reference 302 0x80 Host (H-bit) This Document 304 This document requests the IANA to assign the Bit Number value of 7 305 to the Host Router Support Capability in the OSPF Router 306 Informational Capability Bits Registry. 308 Bit Number Capability Name Reference 310 7 OSPF Host Router This Document 312 8. Security Considerations 314 This document introduces the H-bit which is a capability that 315 restricts the use of a router for transit, while only its local 316 destinations are reachable. This is a subset of the operations of a 317 normal router and therefore should not introduce new security 318 considerations beyond those already known in OSPFv2 [RFC2328]. The 319 feature introduces the advertising of a host router capability 320 information to all OSPFv2 routers in an area. This information can 321 be leveraged for discovery and verification that all routers in the 322 area support the capability before the feature is turned on. In the 323 event that a rogue or buggy router advertises incorrectly its 324 capability the possible cases are: 326 o The router does not have the capability but sends the H-Bit set in 327 its LSAs: In this case, there is a possibility of a routing loop. 328 However this is mitigated by the fact that this router should be 329 avoided anyway. Moreover, the link metrics cost (MaxLinkMetric) 330 of this router will mitigate this situation. In any case, a 331 router advertising the H-bit capability without its links cost 332 equal to MaxLinkMetric may be an indicator that this is a rogue 333 router and should be avoided. 335 o The router has the capability but sends the H-Bit clear in its 336 LSAs: In this case, the router merely prevents support of other 337 H-bit routers in the area and all the routers to run the modified 338 SPF. The impact is also mitigated as other H-Bit routers in the 339 area also advertise MaxLinkMetric cost so they will still be 340 avoided unless they are the last resort path. 342 o The rogue router is on the only transit path for some destinations 343 and sends the H-Bit set (for no good/valid reason) in its LSAs and 344 effectively partition the network. This case is indistinguishable 345 from the normal case where the operator may consciously decide to 346 set the H-bit to perform maintenance on a router that is on the 347 only transit path. The OSPF protocol will continue to function 348 within the partitioned domains. 350 9. Acknowledgements 352 The authors would like to acknowledge Hasmit Grover for discovery of 353 the limitation in [RFC6987], Acee Lindem, Abhay Roy, David Ward, 354 Burjiz Pithawala, and Michael Barnes for their comments. 356 10. References 358 10.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 366 DOI 10.17487/RFC2328, April 1998, 367 . 369 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 370 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 371 DOI 10.17487/RFC6987, September 2013, 372 . 374 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 375 S. Shaffer, "Extensions to OSPF for Advertising Optional 376 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 377 February 2016, . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 10.2. Informative References 385 [I-D.ietf-idr-bgp-optimal-route-reflection] 386 Raszuk, R., Cassar, C., Aman, E., Decraene, B., and K. 387 Wang, "BGP Optimal Route Reflection (BGP-ORR)", draft- 388 ietf-idr-bgp-optimal-route-reflection-19 (work in 389 progress), July 2019. 391 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 392 RFC 3101, DOI 10.17487/RFC3101, January 2003, 393 . 395 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 396 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 397 . 399 Authors' Addresses 400 Keyur Patel 401 Arrcus 403 Email: keyur@arrcus.com 405 Padma Pillay-Esnault 406 PPE Consulting 408 Email: padma.ietf@gmail.com 410 Manish Bhardwaj 411 Cisco Systems 412 170 W. Tasman Drive 413 San Jose, CA 95134 414 USA 416 Email: manbhard@cisco.com 418 Serpil Bayraktar 419 Cisco Systems 420 170 W. Tasman Drive 421 San Jose, CA 95134 422 USA 424 Email: serpil@cisco.com