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