idnits 2.17.1 draft-ietf-ospf-ospfv2-hbit-07.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 abstract seems to contain references ([RFC2328]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2019) is 1805 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 (if approved) P. Pillay-Esnault 5 Intended status: Standards Track Huawei Technologies 6 Expires: November 20, 2019 M. Bhardwaj 7 S. Bayraktar 8 Cisco Systems 9 May 19, 2019 11 Host Router Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-07 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 [RFC2328] by assigning a 25 new bit (Host-bit) in the OSPF Router-LSA bit registry. If the Host- 26 bit is set, the calculation of the shortest-path tree for an area, as 27 described in [RFC2328], is modified by including a new check to 28 verify that transit vertices have the Host-bit clear. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 20, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 77 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 78 3. Host-bit Support . . . . . . . . . . . . . . . . . . . . . . 3 79 4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5 80 5. Auto Discovery and Backward Compatibility . . . . . . . . . . 6 81 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics . . . . . 6 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 87 10.2. Informative References . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 The OSPFv2 specifies an SPF algorithm that identifies transit 93 vertices based on their adjacencies. Therefore, OSPFv2 does not have 94 a mechanism to prevent traffic transiting a participating node if it 95 is a transit vertex in the only existing or shortest path to the 96 destination. The use of metrics to make the node undesirable can 97 only help to repel traffic if an alternative better route exists. 99 This functionality is particularly useful for a number of use cases: 101 1. To isolate a router to avoid blackhole scenarios when there is a 102 reload and possible long reconvergence times. 104 2. Closet Switches are usually not used for transit traffic but need 105 to participate in the topology. 107 3. Overloaded routers could use such a capability to repel traffic 108 until they stabilize. 110 4. BGP Route reflectors known as virtual Route Reflectors (vRRs), 111 that are not in the forwarding path but are in central locations 112 such as data centers. Such Route Reflectors typically are used 113 for route distribution and are not capable of forwarding transit 114 traffic. However, they need to learn the OSPF topology to 115 perform spf computation for optimal routes and reachbility 116 resolution for its clients 117 [I-D.ietf-idr-bgp-optimal-route-reflection]. 119 This document defines the Host-bit (H-Bit)functionality to prevent 120 other OSPFv2 routers from using the router for transit traffic in 121 OSPFv2 routing domains. This document updates the [RFC2328] by - 122 assigning the Host-bit in the OSPF Router-LSA bit registry - if the 123 host-bit is set then the calculation of the shortest-path tree for an 124 area, as described in section 16.1 of [RFC2328], is modified by 125 including a new check to verify that transit vertices DO NOT have the 126 host-bit set. 128 2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Host-bit Support 138 This document defines a new router-LSA bit known as the Host Bit or 139 the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit 140 set indicates to other OSPFv2 routers in the area supporting the 141 functionality that it MUST NOT be used as a transit router (see 142 section 4). 144 If the host-bit is NOT set routers MUST act transit routers as 145 described in [RFC2328] ensuring backward compatibility. 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | LS age | Options | 1 | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Link State ID | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Advertising Router | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | LS sequence number | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | LS checksum | length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |H|0|0|N|W|V|E|B| 0 | # links | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Link ID | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Link Data | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | # TOS | metric | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | ... | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | TOS | 0 | TOS metric | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Link ID | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Link Data | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | ... | 178 Host Bit in router-LSA 180 0 1 2 3 4 5 6 7 181 +-+-+-+-+-+-+-+-+ 182 |H|0|0|N|W|V|E|B| 183 +-+-+-+-+-+-+-+-+ 185 Host Bit 187 Bit H is the high-order bit of the OSPF as shown above. When set, an 188 OSPFv2 router is a non-transit router and is incapable of forwarding 189 transit traffic. 191 An OSPFv2 router originating a router-LSA with the H-bit set MUST 192 advertise all its router links with a link cost of MaxLinkMetric 193 [RFC6987]. This is to increase the applicability of the H-bit to 194 partial deployments where it is the responsibility of the operator to 195 ensure that OSPFv2 routers not supporting the H-bit do not install 196 routes causing routing loops. 198 When the H-bit is set, an Area Border Router (ABR) MUST advertise a 199 consistent H-bit setting in its self-originated router-LSAs for all 200 attached areas. ONLY IPv4 prefixes associated with its local 201 interfaces MAY be advertised in summary LSAs. 203 When the H-bit is set cannot act as an AS Boundary Router (ASBR), as 204 non-local IPv4 prefixes, e.g., those exported from other routing 205 protocols, MUST NOT be advertised in AS-external-LSAs. 207 4. SPF Modifications 209 The SPF calculation described in section 16.1 [RFC2328] will be 210 modified to ensure that the routers originating router-LSAs with the 211 H-bit set will not be used for transit traffic. Step 2 is modified 212 as follows: 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 avoid the possibility of any routing loops due to partial 236 deployment, this document defines a OSPF Router Information (RI) LSA 237 with a Router Functional Capability TLV that includes the following 238 Router Functional Capability Bit: 240 Bit Capabilities 242 7 Host Router Support capability 244 Auto Discovery via announcement of the Host Support Functional 245 Capability ensures that the H-bit functionality and its associated 246 SPF changes SHOULD only take effect if all the routers in a given 247 OSPF area support this functionality. 249 Implementations are encouraged to provide a configuration parameter 250 to manually override enforcement of the H-bit functionality in 251 partial deployments where the topology guarantees that OSPFv2 routers 252 not supporting the H-bit do not compute routes resulting in routing 253 loops. More precisely, the advertisement of MaxLinkMetric for the 254 router's non-local links will prevent OSPFv2 routers not supporting 255 the H-bit from attempting to use it for transit traffic. 257 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 259 When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with 260 a Type-2 metric, the advertised Type-2 metric is taken as more 261 significant than the OSPF intra-area or inter-area path. Hence, 262 advertising the links with MaxLinkMetric as specified in [RFC6987] 263 does not discourage transit traffic when calculating AS external or 264 NSSA routes. Consequently, OSPF routers implementing [RFC6987] or 265 this specification should advertise a Type-2 metric of LSInfinity for 266 any self-originated AS-External-LSAs or NSSA-LSAs in situations when 267 the OSPF router is acting as a stub router [RFC6987] or implementing 268 this specification. 270 7. IANA Considerations 272 IANA is requested to create the OSPF Router-LSA bit registry with the 273 following assignments: 275 Value Description Reference 276 0x01 Area Border Router (B-bit) [RFC2328] 277 0x02 AS Boundary Router (E-bit) [RFC2328] 278 0x04 Virtual Link Endpoint (V-bit) [RFC2328] 279 0x08 Historic (W-bit) [RFC1584] 280 0x10 Unconditional NSSA Translator (Nt-bit) [RFC3101] 281 0x20 Unassigned 282 0x40 Unassigned 283 0x80 Host (H-bit) This Document 285 This document also defines a new Router Functional Capability 286 [RFC7770] known as the Host Router Support Functional Capability. 287 This document requests IANA to allocate the value of this capability 288 from the Router Functional Capability Bits TLV. 290 8. Security Considerations 292 This document introduces no new security considerations beyond those 293 already specified in [RFC6987], [RFC2328], and [RFC5340]. 295 9. Acknowledgements 297 The authors would like to acknowledge Hasmit Grover for discovery of 298 the limitation in [RFC6987], Acee Lindem, Abhay Roy, David Ward, 299 Burjiz Pithawala and Michael Barnes for their comments. 301 10. References 303 10.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 311 DOI 10.17487/RFC2328, April 1998, 312 . 314 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 315 RFC 3101, DOI 10.17487/RFC3101, January 2003, 316 . 318 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 319 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 320 . 322 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 323 S. Shaffer, "Extensions to OSPF for Advertising Optional 324 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 325 February 2016, . 327 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 328 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 329 May 2017, . 331 10.2. Informative References 333 [I-D.ietf-idr-bgp-optimal-route-reflection] 334 Raszuk, R., Cassar, C., Aman, E., Decraene, B., and K. 335 Wang, "BGP Optimal Route Reflection (BGP-ORR)", draft- 336 ietf-idr-bgp-optimal-route-reflection-18 (work in 337 progress), April 2019. 339 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 340 DOI 10.17487/RFC1584, March 1994, 341 . 343 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 344 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 345 DOI 10.17487/RFC6987, September 2013, 346 . 348 Authors' Addresses 350 Keyur Patel 351 Arrcus 353 Email: keyur@arrcus.com 355 Padma Pillay-Esnault 356 Huawei Technologies 357 2330 Central Expressway 358 Santa Clara, CA 95050 359 USA 361 Email: padma@huawei.com 362 Manish Bhardwaj 363 Cisco Systems 364 170 W. Tasman Drive 365 San Jose, CA 95134 366 USA 368 Email: manbhard@cisco.com 370 Serpil Bayraktar 371 Cisco Systems 372 170 W. Tasman Drive 373 San Jose, CA 95134 374 USA 376 Email: serpil@cisco.com