idnits 2.17.1 draft-ietf-lsr-ospf-prefix-originator-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 (April 9, 2021) is 660 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: draft-ietf-idr-bgp-ls-segment-routing-ext has been published as RFC 9085 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track A. Lindem 5 Expires: October 11, 2021 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar, Ed. 10 Cisco Systems 11 April 9, 2021 13 OSPF Prefix Originator Extensions 14 draft-ietf-lsr-ospf-prefix-originator-12 16 Abstract 18 This document defines OSPF extensions to include information 19 associated with the node originating a prefix along with the prefix 20 advertisement. These extensions do not change the core OSPF route 21 computation functionality but provide useful information for network 22 analysis, troubleshooting, and use-cases like traffic engineering. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 11, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Prefix Source OSPF Router-ID Sub-TLV . . . . . . . . . . 4 62 2.2. Prefix Source Router Address Sub-TLV . . . . . . . . . . 5 63 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. Operational Considerations . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Prefix attributes are advertised in OSPFv2 [RFC2328] using the 76 Extended Prefix Opaque Link State Advertisement (LSA) [RFC7684] and 77 in OSPFv3 [RFC5340] using the various Extended Prefix LSA types 78 [RFC8362]. 80 The procedures for identification of the originating router for a 81 prefix in OSPF vary by the type of the prefix and, currently, it is 82 not always possible to produce an accurate result. For intra-area 83 prefixes, the originating router is identified by the Advertising 84 Router field of the area-scoped LSA used for those prefix 85 advertisements. However, for the inter-area prefixes advertised by 86 the Area Border Router (ABR), the Advertising Router field of their 87 area-scoped LSAs is set to the ABR itself and the information about 88 the router originating the prefix advertisement is lost in this 89 process of prefix propagation across areas. For Autonomous System 90 (AS) external prefixes, the originating router may be considered as 91 the Autonomous System Border Router (ASBR) and is identified by the 92 Advertising Router field of the AS-scoped LSA used. However, the 93 actual originating router for the prefix may be a remote router 94 outside the OSPF domain. Similarly, when an ABR performs translation 95 of Not-So-Stubby Area (NSSA) [RFC3101] LSAs to AS-external LSAs, the 96 information associated with the NSSA ASBR (or the router outside the 97 OSPF domain) is not conveyed across the OSPF domain. 99 While typically the originator of information in OSPF is identified 100 by its OSPF Router ID, it does not necessarily represent a reachable 101 address for the router since the OSPF Router ID is a 32-bit number. 102 There exists a prevalent practice to use one of the IPv4 address of 103 the node (e.g. a loopback interface) as an OSPF Router ID in the case 104 of OSPFv2. However, this cannot be always assumed and this approach 105 does not extend to IPv6 addresses with OSPFv3. The IPv4/IPv6 Router 106 Address as defined in [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 107 respectively provide an address to reach that router. 109 The primary use case for the extensions proposed in this document is 110 to be able to identify the originator of a prefix in the network. In 111 cases where multiple prefixes are advertised by a given router, it is 112 also useful to be able to associate all these prefixes with a single 113 router even when prefixes are advertised outside of the area in which 114 they originated. It also helps to determine when the same prefix is 115 being originated by multiple routers across areas. 117 This document proposes extensions to the OSPF protocol for the 118 inclusion of information associated with the router originating the 119 prefix along with the prefix advertisement. These extensions do not 120 change the core OSPF route computation functionality. They provide 121 useful information for topology analysis and traffic engineering, 122 especially on a controller when this information is advertised as an 123 attribute of the prefixes via mechanisms such as Border Gateway 124 Protocol Link-State (BGP-LS) [RFC7752] 125 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. Protocol Extensions 137 This document defines the Prefix Source OSPF Router-ID and the Prefix 138 Source Router Address Sub-TLVs. They are used, respectively, to 139 include the Router ID of, and a reachable address of, the router that 140 originates the prefix as a prefix attribute. 142 2.1. Prefix Source OSPF Router-ID Sub-TLV 144 For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional 145 Sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 146 Prefix Source OSPF Router-ID Sub-TLV is an optional Sub-TLV of the 147 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV 148 [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix 149 advertisement. 151 The Prefix Source OSPF Router-ID Sub-TLV has the following format: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | OSPF Router ID | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Prefix Source OSPF Router-ID Sub-TLV Format 163 Where: 165 o Type: 4 for OSPFv2 and 27 for OSPFv3 167 o Length: 4 169 o OSPF Router ID : the OSPF Router ID of the OSPF router that 170 originated the prefix advertisement in the OSPF domain. 172 The parent TLV of a prefix advertisement MAY include more than one 173 Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of 174 the Equal-Cost Multi-Path (ECMP) nodes that originated the given 175 prefix. 177 For intra-area prefix advertisements, the Prefix Source OSPF Router- 178 ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router 179 ID field is not the same as the Advertising Router field in the 180 containing LSA. Similar validation cannot be reliably performed for 181 inter-area and external prefix advertisements. 183 A received Prefix Source OSPF Router-ID Sub-TLV with OSPF Router ID 184 set to 0 MUST be considered invalid and ignored. Additionally, 185 reception of such Sub-TLV SHOULD be logged as an error (subject to 186 rate-limiting). 188 2.2. Prefix Source Router Address Sub-TLV 190 For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional 191 Sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 192 Prefix Source Router Address Sub-TLV is an optional Sub-TLV of the 193 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV 194 [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix 195 advertisement. 197 The Prefix Source Router Address Sub-TLV has the following format: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Router Address (4 or 16 octets) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2: Prefix Source Router Address Sub-TLV Format 209 Where: 211 o Type: 5 (suggested) for OSPFv2 and 28 (suggested) for OSPFv3 213 o Length: 4 or 16 215 o Router Address: A reachable IPv4 or IPv6 router address for the 216 router that originated the IPv4 or IPv6 prefix advertisement 217 respectively. Such an address would be semantically equivalent to 218 what may be advertised in the OSPFv2 Router Address TLV [RFC3630] 219 or in the OSPFv3 Router IPv6 Address TLV [RFC5329]. 221 The parent TLV of a prefix advertisement MAY include more than one 222 Prefix Source Router Address Sub-TLV, one corresponding to each of 223 the Equal-Cost Multi-Path (ECMP) nodes that originated the given 224 prefix. 226 A received Prefix Source Router Address Sub-TLV that has an invalid 227 length (i.e. not consistent with the prefix's address family) MUST be 228 considered invalid and ignored. Additionally, reception of such Sub- 229 TLV SHOULD be logged as an error (subject to rate-limiting). 231 3. Elements of Procedure 233 This section describes the procedure for the advertisement of the 234 Prefix Source OSPF Router-ID and Prefix Source Router Address Sub- 235 TLVs along with the prefix advertisement. 237 The OSPF Router ID of the Prefix Source OSPF Router-ID is set to the 238 OSPF Router ID of the node originating the prefix in the OSPF domain. 240 If the originating node is advertising an OSPFv2 Router Address TLV 241 [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the 242 same address MUST be used in the Router Address field of the Prefix 243 Source Router Address Sub-TLV. When the originating node is not 244 advertising such an address, implementations can determine a unique 245 and reachable address (for example, advertised with the N-flag set 246 [RFC7684] or N-bit set [RFC8362]) belonging to the originating node 247 to set in the Router Address field. 249 When an ABR generates inter-area prefix advertisements into its non- 250 backbone areas corresponding to an inter-area prefix advertisement 251 from the backbone area, the only way to determine the originating 252 node information is based on the Prefix Source OSPF Router-ID and 253 Prefix Source Router Address Sub-TLVs present in the inter-area 254 prefix advertisement originated into the backbone area by an ABR from 255 another non-backbone area. The ABR performs its prefix calculation 256 to determine the set of nodes that contribute to the best prefix 257 reachability. It MUST use the prefix originator information only 258 from this set of nodes. The ABR MUST NOT include the Prefix Source 259 OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it 260 is unable to determine the information of the best originating nodes. 262 Implementations may support the propagation of the originating node 263 information along with a redistributed prefix into the OSPF domain 264 from another routing domain. The details of such mechanisms are 265 outside the scope of this document. Such implementations may also 266 provide control on whether the Router Address in the Prefix Source 267 Router Address Sub-TLV is set as the ABSR node address or as the 268 address of the actual node outside the OSPF domain that owns the 269 prefix. 271 When translating the NSSA prefix advertisements [RFC3101] to the AS 272 external prefix advertisements, the NSSA ABR, follows the same 273 procedures as an ABR generating inter-area prefix advertisements for 274 the propagation of the originating node information. 276 4. Security Considerations 278 Since this document extends the OSPFv2 Extended Prefix LSA, the 279 security considerations for [RFC7684] are applicable. Similarly, 280 since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E- 281 Inter-Area-Prefix-LSA, E-AS-External LSA, and E-NSSA-LSA, the 282 security considerations for [RFC8362] are applicable. The new sub- 283 TLVs introduced in this document are optional and do not affect the 284 OSPF route computation and therefore do not affect the security 285 aspects of OSPF protocol operations. 287 A rogue node that can inject prefix advertisements may use the new 288 extensions introduced in this document to indicate an incorrect 289 prefix source information. 291 5. Operational Considerations 293 Consideration should be given to the operational impact of the 294 increase in the size of the OSPF Link-State Database as a result of 295 the protocol extensions in this document. Based on deployment design 296 and requirements, a subset of prefixes may be identified for which 297 the originating node information needs to be included with their 298 prefix advertisements. 300 The propagation of the prefix source node information when doing 301 prefix advertisements across OSPF area or domain boundaries results 302 in the exposure of node information outside of an area or domain 303 within which it is normally hidden or abstracted by the base OSPF 304 protocol. Based on deployment design and requirements, a subset of 305 prefixes may be identified for which the propagation of the 306 originating node information across area or domain boundaries is 307 disabled at the ABRs or ASBRs respectively. 309 The identification of the node that is originating a specific prefix 310 in the network may aid in debugging of issues related to prefix 311 reachability within an OSPF network. 313 6. IANA Considerations 315 This document requests IANA for the allocation of the codepoints from 316 the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open 317 Shortest Path First v2 (OSPFv2) Parameters" registry. 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Code | Description | IANA Allocation | 321 | Point | | Status | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | 4 | Prefix Source OSPF Router-ID | early allocation done | 324 | 5 | Prefix Source Router Address | suggested | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 3: Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs 329 This document requests IANA for the allocation of the codepoints from 330 the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "Open Shortest 331 Path First v3 (OSPFv3) Parameters" registry. 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Code | Description | IANA Allocation | 335 | Point | | Status | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | 27 | Prefix Source OSPF Router-ID | early allocation done | 338 | 28 | Prefix Source Router Address | suggested | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 4: Codepoints in OSPFv3 Extended-LSA Sub-TLVs 343 7. Acknowledgement 345 Many thanks to Les Ginsberg for his suggestions on this draft. Also 346 thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals 347 Dirk, Smita Selot, Shaofu Peng, John E Drake and Baalajee S for their 348 review and valuable comments. The authors would also like to thank 349 Alvaro Retana for his detailed review and suggestions for the 350 improvement of this document. 352 8. References 354 8.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 362 DOI 10.17487/RFC2328, April 1998, 363 . 365 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 366 (TE) Extensions to OSPF Version 2", RFC 3630, 367 DOI 10.17487/RFC3630, September 2003, 368 . 370 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 371 "Traffic Engineering Extensions to OSPF Version 3", 372 RFC 5329, DOI 10.17487/RFC5329, September 2008, 373 . 375 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 376 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 377 . 379 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 380 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 381 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 382 2015, . 384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 386 May 2017, . 388 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 389 F. Baker, "OSPFv3 Link State Advertisement (LSA) 390 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 391 2018, . 393 8.2. Informative References 395 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 396 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 397 and M. Chen, "BGP Link-State extensions for Segment 398 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 399 (work in progress), June 2019. 401 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 402 RFC 3101, DOI 10.17487/RFC3101, January 2003, 403 . 405 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 406 R. Aggarwal, "Support of Address Families in OSPFv3", 407 RFC 5838, DOI 10.17487/RFC5838, April 2010, 408 . 410 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 411 S. Ray, "North-Bound Distribution of Link-State and 412 Traffic Engineering (TE) Information Using BGP", RFC 7752, 413 DOI 10.17487/RFC7752, March 2016, 414 . 416 Authors' Addresses 417 Aijun Wang 418 China Telecom 419 Beiqijia Town, Changping District 420 Beijing 102209 421 China 423 Email: wangaj3@chinatelecom.cn 425 Acee Lindem 426 Cisco Systems 427 301 Midenhall Way 428 Cary, NC 27513 429 USA 431 Email: acee@cisco.com 433 Jie Dong 434 Huawei Technologies 435 Beijing 436 China 438 Email: jie.dong@huawei.com 440 Peter Psenak 441 Cisco Systems 442 Pribinova Street 10 443 Bratislava, Eurovea Centre, Central 3 81109 444 Slovakia 446 Email: ppsenak@cisco.com 448 Ketan Talaulikar (editor) 449 Cisco Systems 450 India 452 Email: ketant@cisco.com