idnits 2.17.1 draft-ietf-ospf-ospfv2-hbit-11.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 (November 16, 2019) is 1620 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: May 19, 2020 M. Bhardwaj 7 S. Bayraktar 8 Cisco Systems 9 November 16, 2019 11 Host Router Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-11 14 Abstract 16 The Open Shortest Path First Version 2 (OSPFv2) does not have a 17 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 May 19, 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 specifies a Shortest Path First (SPF) algorithm that 76 identifies transit vertices based on their adjacencies. Therefore, 77 OSPFv2 does not have a mechanism to prevent traffic transiting a 78 participating node if it is a transit vertex in the only existing or 79 shortest path to the destination. The use of metrics to make the 80 node undesirable can help to repel traffic only if an alternative 81 better route exists. 83 This functionality is particularly useful for a number of use cases: 85 1. To gracefully isolate a router to avoid blackhole scenarios when 86 there is a reload and possible long reconvergence times. 88 2. Closet Switches are usually not used for transit traffic but need 89 to participate in the topology. 91 3. Overloaded routers could use such a capability to temporarily 92 repel traffic until they stabilize. 94 4. BGP Route reflectors known as virtual Route Reflectors (vRRs), 95 that are not in the forwarding path but are in central locations 96 such as data centers. Such Route Reflectors typically are used 97 for route distribution and are not capable of forwarding transit 98 traffic. However, they need to learn the OSPF topology to 99 perform SPF computation for optimal routes and reachability 100 resolution for its clients 101 [I-D.ietf-idr-bgp-optimal-route-reflection]. 103 This document describes the Host-bit (H-bit) functionality that 104 prevents other OSPFv2 routers from using the host router by excluding 105 it in path calculations for transit traffic in OSPFv2 routing 106 domains. If the H-bit is set then the calculation of the shortest- 107 path tree for an area, as described in section 16.1 of [RFC2328], is 108 modified by including a check to verify that transit vertices DO NOT 109 have the H-bit set (see Section 4). Furthermore, in order to repel 110 traffic effectively, [RFC6987] is updated so that type-2 External and 111 NSSA LSAs are advertised with a high cost (see Section 6). Open 112 Shortest Path First Version 3 defines an option bit for router-LSAs 113 known as the R-bit in [RFC5340] to support a similar functionality. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. Host-bit Support 125 This document defines a new router-LSA bit known as the Host Bit or 126 the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit 127 set indicates that it MUST NOT be used as a transit router (see 128 Section 4) by other OSPFv2 routers in the area supporting the 129 functionality. 131 If the H-bit is not set then backwards compatibility is achieved as 132 the behavior will be the same as in [RFC2328]. 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | LS age | Options | 1 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Link State ID | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Advertising Router | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | LS sequence number | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | LS checksum | length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |H|0|0|N|W|V|E|B| 0 | # links | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Link ID | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Link Data | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type | # TOS | metric | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | ... | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | TOS | 0 | TOS metric | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Link ID | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Link Data | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | ... | 165 Figure 1: OSPF Router-LSA 167 Bit H is the high-order bit of the OSPF flags as shown below. 169 0 1 2 3 4 5 6 7 170 +-+-+-+-+-+-+-+-+ 171 |H|0|0|N|W|V|E|B| 172 +-+-+-+-+-+-+-+-+ 174 Figure 2: OSPF Router-LSA Option bits 176 When the H-bit is set, the OSPFv2 router is a Host (non-transit) 177 router and is incapable of forwarding transit traffic. In this mode, 178 the other OSPFv2 routers in the area MUST NOT use the host router for 179 transit traffic, but may send traffic to its local destinations. 181 An OSPFv2 router originating a router-LSA with the H-bit set MUST 182 advertise all its non-stub links with a link cost of MaxLinkMetric 183 [RFC6987]. 185 When the H-bit is set, an Area Border Router (ABR) MUST advertise the 186 same H-bit setting in its self-originated router-LSAs for all 187 attached areas. The consistency of the setting will prevent inter- 188 area traffic transiting through the router by suppressing 189 advertisement of prefixes from other routers in the area in its 190 summary LSAs. Only IPv4 prefixes associated with its local 191 interfaces MUST be advertised in summary-LSAs to provide reachability 192 to end hosts attached to a router with the H-bit set. 194 When the H-bit is set the host router cannot act as an AS Boundary 195 Router (ASBR). Indeed, ASBR are transit routers to prefixes that are 196 typically imported through redistribution of prefixes from other 197 routing protocols. Therefore, non-local IPv4 prefixes, e.g., those 198 imported from other routing protocols, SHOULD NOT be advertised in 199 AS-external-LSAs if the H-bit is set. Some use cases, such as an 200 overloaded router or a router being gracefully isolated, may benefit 201 from continued advertisement of non-local prefixes. In these cases, 202 the type 2-metric in AS-external-LSAs MUST be set to LSInfinity to 203 repel traffic.(see Section 6 of this document). 205 4. SPF Modifications 207 The SPF calculation described in section 16.1 [RFC2328] will be 208 modified to ensure that the routers originating router-LSAs with the 209 H-bit set will not be used for transit traffic. Step 2 is modified 210 as follows: 212 2) Call the vertex just added to the 213 tree vertex V. Examine the LSA 214 associated with vertex V. This is 215 a lookup in the Area A's link state 216 database based on the Vertex ID. If 217 this is a router-LSA, and the H-bit 218 of the router-LSA is set, and 219 vertex V is not the root, then the 220 router should not be used for transit 221 and step (3) should be executed 222 immediately. If this is a router-LSA, 223 and bit V of the router-LSA (see 224 Section A.4.2) is set, set Area A's 225 TransitCapability to TRUE. In any case, 226 each link described by the LSA gives 227 the cost to an adjacent vertex. For 228 each described link, (say it joins 229 vertex V to vertex W): 231 5. Auto Discovery and Backward Compatibility 233 To reduce the possibility of any routing loops due to partial 234 deployment, this document defines an OSPF Router Information (RI) LSA 235 [RFC7770] capability. The RI LSA MUST be area-scoped. Bit: 237 Bit Capabilities 239 7 Host Router Support capability 241 Table 1: OSPF Router Information LSA Capabilities 243 Auto Discovery via announcement of the Host Router Support Capability 244 ensures that the H-bit functionality and its associated SPF changes 245 MUST only take effect if all the routers in a given OSPF area support 246 this functionality. 248 In normal operation, there is no guarantee that the RI LSA will reach 249 all routers in an area in a timely manner, which may result in 250 forwarding loops in partial deployments. For example, if a new 251 router joins an area, which previously had only H-bit capable routers 252 with H-bit set then it may take some time for the RI to propagate to 253 all routers. 255 The following recommendations will mitigate transient routing loops: 257 o Implementations are RECOMMENDED to provide a configuration 258 parameter to manually override enforcement of the H-bit 259 functionality in partial deployments where the topology guarantees 260 that OSPFv2 routers not supporting the H-bit do not compute routes 261 resulting in routing loops. 263 o All routers, with the H-bit set, MUST advertise all of the 264 router's non-stub links with a metric equal to MaxLinkMetric 265 [RFC6987] in its LSAs in order to avoid OSPFv2 (unless last 266 resort) routers not supporting the H-bit from attempting to use it 267 for transit traffic. 269 o All routers supporting H-Bit MUST check all the RI LSAs of nodes 270 in the area before actively running the modified SPF to account 271 for the H-bit in order to verify that all routers are in routing 272 capability. If any router does not advertise the Host Router 273 Support capability then the SPF Modifications (Section 4) MUST NOT 274 be used in the area. 276 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 278 When calculating the path to an OSPF AS-External-LSA or NSSA-LSA 279 [RFC3101] with a Type-2 metric, the advertised Type-2 metric is taken 280 as more significant than the OSPF intra-area or inter-area path. 281 Hence, advertising the links with MaxLinkMetric as specified in 282 [RFC6987] does not discourage transit traffic when calculating AS 283 external or NSSA routes with Type-2 metrics. 285 Consequently, [RFC6987] is updated so that the Type-2 metric in any 286 self-originated AS-External-LSAs or NSSA-LSAs is advertised as 287 LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type-2 metric 288 MUST be set to LSInfinity. 290 7. IANA Considerations 292 This document requests the IANA to assign the 0x80 value to the Host- 293 Bit (H-bit)in the OSPFv2 Router Properties Registry 295 Value Description Reference 297 0x80 Host (H-bit) This Document 299 This document requests the IANA to assign the Bit Number value of 7 300 to the Host Router Support Capability in the OSPF Router 301 Informational Capability Bits Registry. 303 Bit Number Capability Name Reference 305 7 OSPF Host Router This Document 307 8. Security Considerations 309 This document introduces the H-bit which is a capability that 310 restricts the use of a router for transit, while only its local 311 destinations are reachable. This is a subset of the operations of a 312 normal router and therefore should not introduce new security 313 considerations beyond those already known in OSPFv2 [RFC2328]. The 314 feature introduces the advertising of a host router capability 315 information to all OSPFv2 routers in an area. This information can 316 be leveraged for discovery and verification that all routers in the 317 area support the capability before the feature is turned on. In the 318 event that a rogue or buggy router advertises incorrectly its 319 capability the possible cases are: 321 o The router does not have the capability but sends the H-Bit set in 322 its LSAs: In this case, there is a possibility of a routing loop. 323 However this is mitigated by the fact that this router should be 324 avoided anyway. Moreover, the link metrics cost (MaxLinkMetric) 325 of this router will mitigate this situation. In any case, a 326 router advertising the H-bit capability without its links cost 327 equal to MaxLinkMetric may be an indicator that this is a rogue 328 router and should be avoided. 330 o The router has the capability but sends the H-Bit clear in its 331 LSAs: In this case, the router merely prevents support of other 332 H-bit routers in the area and all the routers to run the modified 333 SPF. The impact is also mitigated as other H-Bit routers in the 334 area also advertise MaxLinkMetric cost so they will still be 335 avoided unless they are the last resort path. 337 o The rogue router is on the only transit path for some destinations 338 and sends the H-Bit set (for no good/valid reason) in its LSAs and 339 effectively partition the network. This case is indistinguishable 340 from the normal case where the operator may consciously decide to 341 set the H-bit to perform maintenance on a router that is on the 342 only transit path. The OSPF protocol will continue to function 343 within the partitioned domains. 345 9. Acknowledgements 347 The authors would like to acknowledge Hasmit Grover for discovery of 348 the limitation in [RFC6987], Acee Lindem, Abhay Roy, David Ward, 349 Burjiz Pithawala, and Michael Barnes for their comments. 351 10. References 353 10.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 361 DOI 10.17487/RFC2328, April 1998, 362 . 364 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 365 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 366 DOI 10.17487/RFC6987, September 2013, 367 . 369 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 370 S. Shaffer, "Extensions to OSPF for Advertising Optional 371 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 372 February 2016, . 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 376 May 2017, . 378 10.2. Informative References 380 [I-D.ietf-idr-bgp-optimal-route-reflection] 381 Raszuk, R., Cassar, C., Aman, E., Decraene, B., and K. 382 Wang, "BGP Optimal Route Reflection (BGP-ORR)", draft- 383 ietf-idr-bgp-optimal-route-reflection-19 (work in 384 progress), July 2019. 386 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 387 RFC 3101, DOI 10.17487/RFC3101, January 2003, 388 . 390 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 391 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 392 . 394 Authors' Addresses 395 Keyur Patel 396 Arrcus 398 Email: keyur@arrcus.com 400 Padma Pillay-Esnault 401 PPE Consulting 403 Email: padma.ietf@gmail.com 405 Manish Bhardwaj 406 Cisco Systems 407 170 W. Tasman Drive 408 San Jose, CA 95134 409 USA 411 Email: manbhard@cisco.com 413 Serpil Bayraktar 414 Cisco Systems 415 170 W. Tasman Drive 416 San Jose, CA 95134 417 USA 419 Email: serpil@cisco.com