idnits 2.17.1 draft-ietf-ospf-ospfv2-hbit-08.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2328, but the abstract doesn't seem to directly say this. It does mention RFC2328 though, so this could be OK. -- The draft header indicates that this document updates RFC6987, but the abstract doesn't seem to directly say this. It does mention RFC6987 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2019) is 1751 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) == Outdated reference: A later version (-28) exists of draft-ietf-idr-bgp-optimal-route-reflection-18 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF K. Patel 3 Internet-Draft Arrcus 4 Updates: 2328,6987 (if approved) P. Pillay-Esnault 5 Intended status: Standards Track Futurewei 6 Expires: January 9, 2020 M. Bhardwaj 7 S. Bayraktar 8 Cisco Systems 9 July 8, 2019 11 Host Router Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-08 14 Abstract 16 The OSPFv2 specifies an SPF algorithm that identifies transit 17 vertices based on their adjacencies. Therefore, OSPFv2 does not have 18 a mechanism to prevent traffic transiting a participating node if it 19 is a transit vertex in the only existing or shortest path to the 20 destination. The use of metrics to make the node undesirable can 21 only help to repel traffic if an alternative better route exists. 22 This document defines the Host-bit functionality to prevent other 23 OSPFv2 routers from using the router for transit traffic in OSPFv2 24 routing domains. This document updates the Open Shortest Path First 25 v2 specification (OSPFv2 rfc2328) by assigning a new bit (Host-bit) 26 in the OSPF Router-LSA bit registry. In addition, if the Host-bit is 27 set, the calculation of the shortest-path tree for an area, as 28 described in OSPFv2, is modified by including a new check to verify 29 that transit vertices have the Host-bit clear. In addition, this 30 document updates OSPF Stub Router Advertisement (rfc6987) to 31 advertise for type-2 External and NSSA LSAs with a high cost in order 32 to repel traffic effectively. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 69 3. Host-bit Support . . . . . . . . . . . . . . . . . . . . . . 3 70 4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Auto Discovery and Backward Compatibility . . . . . . . . . . 6 72 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 10.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 The OSPFv2 specifies an SPF algorithm that identifies transit 84 vertices based on their adjacencies. Therefore, OSPFv2 does not have 85 a mechanism to prevent traffic transiting a participating node if it 86 is a transit vertex in the only existing or shortest path to the 87 destination. The use of metrics to make the node undesirable can 88 only help to repel traffic if an alternative better route exists. 90 This functionality is particularly useful for a number of use cases: 92 1. To isolate a router to avoid blackhole scenarios when there is a 93 reload and possible long reconvergence times. 95 2. Closet Switches are usually not used for transit traffic but need 96 to participate in the topology. 98 3. Overloaded routers could use such a capability to temporarily 99 repel traffic until they stabilize. 101 4. BGP Route reflectors known as virtual Route Reflectors (vRRs), 102 that are not in the forwarding path but are in central locations 103 such as data centers. Such Route Reflectors typically are used 104 for route distribution and are not capable of forwarding transit 105 traffic. However, they need to learn the OSPF topology to 106 perform spf computation for optimal routes and reachbility 107 resolution for its clients 108 [I-D.ietf-idr-bgp-optimal-route-reflection]. 110 This document defines the Host-bit (H-Bit)functionality to prevent 111 other OSPFv2 routers from using the router for transit traffic in 112 OSPFv2 routing domains. This document updates the [RFC2328] by - 113 assigning the Host-bit in the OSPFv2 Router Properties Registry - if 114 the host-bit is set then the calculation of the shortest-path tree 115 for an area, as described in section 16.1 of [RFC2328], is modified 116 by including a new check to verify that transit vertices DO NOT have 117 the host-bit set. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 3. Host-bit Support 129 This document defines a new router-LSA bit known as the Host Bit or 130 the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit 131 set indicates to other OSPFv2 routers in the area supporting the 132 functionality that it MUST NOT be used as a transit router (see 133 section 4). 135 If the host-bit is NOT set routers MUST act transit routers as 136 described in [RFC2328] ensuring backward compatibility. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | LS age | Options | 1 | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Link State ID | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Advertising Router | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | LS sequence number | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | LS checksum | length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |H|0|0|N|W|V|E|B| 0 | # links | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Link ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Link Data | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Type | # TOS | metric | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | ... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | TOS | 0 | TOS metric | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Link ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Link Data | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | ... | 169 Host Bit in router-LSA 171 0 1 2 3 4 5 6 7 172 +-+-+-+-+-+-+-+-+ 173 |H|0|0|N|W|V|E|B| 174 +-+-+-+-+-+-+-+-+ 176 Host Bit 178 Bit H is the high-order bit of the OSPF as shown above. When set, an 179 OSPFv2 router is a Host (non-transit) router and is incapable of 180 forwarding transit traffic. 182 An OSPFv2 router originating a router-LSA with the H-bit set MUST 183 advertise all its router links with a link cost of MaxLinkMetric 184 [RFC6987]. This is to increase the applicability of the H-bit to 185 partial deployments where it is the responsibility of the operator to 186 ensure that OSPFv2 routers not supporting the H-bit do not install 187 routes causing routing loops. 189 When the H-bit is set, an Area Border Router (ABR) MUST advertise the 190 same H-bit setting in its self-originated router-LSAs for all 191 attached areas. The consistency of the setting will prevent inter- 192 area traffic transiting through the router by suppressing the 193 suppressing advertisement of prefixes from other routers in the area 194 in its summary LSAs. ONLY IPv4 prefixes associated with its local 195 interfaces MAY be advertised in summary LSAs to provide reachability 196 to end hosts attached behind a router with the H-bit set. 198 When the H-bit is set cannot act as an AS Boundary Router (ASBR), as 199 ASBR are transit routers to prefixes that are typically imported 200 through redistribution of prefixes of other routing protocols. 201 Therefore, non-local IPv4 prefixes, e.g., those exported from other 202 routing protocols, MUST NOT be advertised in AS-external-LSAs for 203 routers acting permanly as a host. However, in use cases such as an 204 overloaded router or a router being gracefully isolated, these 205 routers are only temporarily acting as host routers and therefore 206 should continue to advertise their External LSAs but ensure they do 207 not attract traffic. In addition to the procedure described above, 208 temporary host routers advertising type 2-metric External LSAs MUST 209 set the metrics to LSInfinity to repel traffic.(see Section 6 of this 210 document). 212 4. SPF Modifications 214 The SPF calculation described in section 16.1 [RFC2328] will be 215 modified to ensure that the routers originating router-LSAs with the 216 H-bit set will not be used for transit traffic. Step 2 is modified 217 as follows: 219 2) Call the vertex just added to the 220 tree vertex V. Examine the LSA 221 associated with vertex V. This is 222 a lookup in the Area A's link state 223 database based on the Vertex ID. If 224 this is a router-LSA, and the H-bit 225 of the router-LSA is set, and 226 vertex V is not the root, then the 227 router should not be used for transit 228 and step (3) should be executed 229 immediately. If this is a router-LSA, 230 and bit V of the router-LSA (see 231 Section A.4.2) is set, set Area A's 232 TransitCapability to TRUE. In any case, 233 each link described by the LSA gives 234 the cost to an adjacent vertex. For 235 each described link, (say it joins 236 vertex V to vertex W): 238 5. Auto Discovery and Backward Compatibility 240 To avoid the possibility of any routing loops due to partial 241 deployment, this document defines a OSPF Router Information (RI) LSA 242 [RFC7770] with and area flooding scope and a new bit assigned in the 243 OSPF Router Informational Capability Bits Registry. Bit: 245 Bit Capabilities 247 7 Host Router Support capability 249 Auto Discovery via announcement of the Host Support Functional 250 Capability ensures that the H-bit functionality and its associated 251 SPF changes MUST only take effect if all the routers in a given OSPF 252 area support this functionality. 254 In normal operations, there is no guarantee that the RI LSA will 255 reach all routers in an area in a timely manner which may result in 256 rooting loops in partial deployments. For example, in a new router 257 joins an area which previous had only H-bit capable routers with 258 H-bit set then it may take some time for the RI to propagate to all 259 routers. 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 270 router's non-local links with a metric equal to MaxLinkMetric 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 H-Bit MUST check all the RI LSAs of nodes 276 in the area before actively running the modified SPF to account 277 for the H-bit in order to verify that all routers are in routing 278 capability. If any router does not have the H-Bit support then 279 all routers in the areas MUST run the normal SPF. 281 o Any router not supporting the H-bit capability is detected (by 282 examination of RI- LSA or RTR LSA in the area database) then all 283 routers in the area MUST revert back to normal operations. 285 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 287 When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with 288 a Type-2 metric, the advertised Type-2 metric is taken as more 289 significant than the OSPF intra-area or inter-area path. Hence, 290 advertising the links with MaxLinkMetric as specified in [RFC6987] 291 does not discourage transit traffic when calculating AS external or 292 NSSA routes with Type-2 metrics. 294 Consequently, OSPF routers implementing [RFC6987] and required to be 295 the last resort transit then they MUST advertise a Type-2 metric of 296 LSInfinity-1 for any self-originated type 2 AS-External-LSAs or NSSA- 297 LSAs. However, in situations, the router needs to repel traffic and 298 acts as a host router then, in addition of the host bit procedure 299 described in this document they MUST advertise a Type-2 metric of 300 LSInfinity for any self-originated type 2 AS-External-LSAs or NSSA- 301 LSAs. 303 7. IANA Considerations 305 This document requests the IANA to assign the 0x80 value to the Host- 306 Bit (H-bit)in the OSPFv2 Router Properties Registry 308 Value Description Reference 310 0x80 Host (H-bit) This Document 312 This document requests the IANA to assign the Bit Number value of 7 313 to the Host Router Support Capability in the OSPF Router 314 Informational Capability Bits Registry. [RFC7770] 316 Bit Number Capability Name Reference 318 7 OSPF Host Router This Document 320 8. Security Considerations 322 This document introduces the H-bit which is a capability that 323 restricts the use of a router for transit except for its local 324 destinations. This is a subset of the operations of a normal router 325 and therefore should not introduce new security considerations beyond 326 those already known in OSPF. The feature however does introduce the 327 flooding of a capability information that allows discovery and 328 verification that all routers in an area are capable before turning 329 on the feature. In case. a rogue or buggy router advertise 330 incorrectly its capability there are two possible cases: 332 o The router does not have the capability but send H-Bit set in its 333 LSAs: In this case, there is a possibility of a routing loop. 334 However this is mitigated by the fact that this router should be 335 avoided anyway. Moreover, the link metrics cost of this router 336 should be MaxLinkMetric and will mitigate this situation. In any 337 case a router advertising the H-bit capability without its links 338 cost equal to MaxLinkMetric may be an indicator that this is a 339 rogue router. 341 o The router has the capability but sends the H-Bit clear in its 342 LSAs: In this case, the router merely prevents support of other 343 H-bit routers in the area and all the routers to run the modified 344 SPF. The impact is also mitigated as other H-Bit routers in the 345 area also advertise MaxLinkMetric cost so they will still be 346 avoided unless they are the last resort path. 348 9. Acknowledgements 350 The authors would like to acknowledge Hasmit Grover for discovery of 351 the limitation in [RFC6987], Acee Lindem, Abhay Roy, David Ward, 352 Burjiz Pithawala and Michael Barnes for their comments. 354 10. References 355 10.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 363 DOI 10.17487/RFC2328, April 1998, 364 . 366 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 367 S. Shaffer, "Extensions to OSPF for Advertising Optional 368 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 369 February 2016, . 371 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 372 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 373 May 2017, . 375 10.2. Informative References 377 [I-D.ietf-idr-bgp-optimal-route-reflection] 378 Raszuk, R., Cassar, C., Aman, E., Decraene, B., and K. 379 Wang, "BGP Optimal Route Reflection (BGP-ORR)", draft- 380 ietf-idr-bgp-optimal-route-reflection-18 (work in 381 progress), April 2019. 383 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 384 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 385 DOI 10.17487/RFC6987, September 2013, 386 . 388 Authors' Addresses 390 Keyur Patel 391 Arrcus 393 Email: keyur@arrcus.com 395 Padma Pillay-Esnault 396 Futurewei 397 2330 Central Expressway 398 Santa Clara, CA 95050 399 USA 401 Email: padma.ietf@gmail.com 402 Manish Bhardwaj 403 Cisco Systems 404 170 W. Tasman Drive 405 San Jose, CA 95134 406 USA 408 Email: manbhard@cisco.com 410 Serpil Bayraktar 411 Cisco Systems 412 170 W. Tasman Drive 413 San Jose, CA 95134 414 USA 416 Email: serpil@cisco.com