idnits 2.17.1 draft-ietf-lsr-ospf-prefix-originator-09.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 (March 19, 2021) is 1135 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: September 20, 2021 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar 10 Cisco Systems 11 March 19, 2021 13 OSPF Prefix Originator Extensions 14 draft-ietf-lsr-ospf-prefix-originator-09 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 September 20, 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Prefix attributes are advertised in OSPFv2 [RFC2328] using the 73 Extended Prefix Opaque Link State Advertisement (LSA) [RFC7684] and 74 in OSPFv3 [RFC5340] using the various Extended Prefix LSA types 75 [RFC8362]. 77 The identification of the originating router for a prefix in OSPF 78 varies by the type of the prefix and is currently not always 79 possible. For intra-area prefixes, the originating router is 80 identified by the Advertising Router field of the area-scoped LSA 81 used for those prefix advertisements. However, for the inter-area 82 prefixes advertised by the Area Border Router (ABR), the Advertising 83 Router field of their area-scoped LSAs is set to the ABR itself and 84 the information about the router originating the prefix advertisement 85 is lost in this process of prefix propagation across areas. For 86 Autonomous System (AS) external prefixes, the originating router may 87 be considered as the Autonomous System Border Router (ASBR) and is 88 identified by the Advertising Router field of the AS-scoped LSA used. 89 However, the actual originating router for the prefix may be a remote 90 router outside the OSPF domain. Similarly, when an ABR performs 91 translation of Not-So-Stubby Area (NSSA) [RFC3101] LSAs to AS- 92 external LSAs, the information associated with the NSSA ASBR (or the 93 router outside the OSPF domain) is not conveyed across the OSPF 94 domain. 96 While typically the originator of information in OSPF is identified 97 by its OSPF Router ID, it does not necessarily represent a reachable 98 address for the router. The IPv4/IPv6 Router Address as defined in 99 [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 respectively provide an 100 address to reach that router. 102 The primary use case for the extensions proposed in this document is 103 to be able to identify the originator of a prefix in the network. In 104 cases where multiple prefixes are advertised by a given router, it is 105 also useful to be able to associate all these prefixes with a single 106 router even when prefixes are advertised outside of the area in which 107 they originated. It also helps to determine when the same prefix is 108 being originated by multiple routers across areas. 110 This document proposes extensions to the OSPF protocol for inclusion 111 of information associated with the router originating the prefix 112 along with the prefix advertisement. These extensions do not change 113 the core OSPF route computation functionality. They provide useful 114 information for topology analysis and traffic engineering, especially 115 on a controller when this information is advertised as an attribute 116 of the prefixes via mechanisms such as Border Gateway Protocol Link- 117 State (BGP-LS) [RFC7752] [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 119 1.1. 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 2. Protocol Extensions 129 This document defines the Prefix Source OSPF Router-ID and the Prefix 130 Source Router Address Sub-TLVs for inclusion of the Router ID and a 131 reachable address information for the router originating the prefix 132 as a prefix attribute. 134 2.1. Prefix Source OSPF Router-ID Sub-TLV 136 For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional 137 Sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 138 Prefix Source OSPF Router-ID Sub-TLV is an optional Sub-TLV of the 139 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV 140 [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix 141 advertisement. 143 The Prefix Source OSPF Router-ID Sub-TLV has the following format: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Type | Length | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | OSPF Router ID | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1: Prefix Source OSPF Router-ID Sub-TLV Format 155 Where: 157 o Type: 4 for OSPFv2 and 27 for OSPFv3 159 o Length: 4 161 o OSPF Router ID : the OSPF Router ID of the OSPF router that 162 originated the prefix advertisement in the OSPF domain. 164 The parent TLV of a prefix advertisement MAY include more than one 165 Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of 166 the Equal-Cost Multi-Path (ECMP) nodes that originated the given 167 prefix. 169 For intra-area prefix advertisements, the Prefix Source OSPF Router- 170 ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router 171 ID field is not the same as Advertising Router field in the 172 containing LSA. Similar validation cannot be reliably performed for 173 inter-area and external prefix advertisements. 175 A received Prefix Source OSPF Router-ID Sub-TLV with OSPF Router ID 176 set to 0 MUST be considered invalid and ignored. Additionally, 177 reception of such Sub-TLV SHOULD be logged as an error (subject to 178 rate-limiting). 180 2.2. Prefix Source Router Address Sub-TLV 182 For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional 183 Sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 184 Prefix Source Router Address Sub-TLV is an optional Sub-TLV of the 185 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV 186 [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix 187 advertisement. 189 The Prefix Source Router Address Sub-TLV has the following format: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Type | Length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Router Address (4 or 16 octets) | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: Prefix Source Router Address Sub-TLV Format 201 Where: 203 o Type: TBD1 for OSPFv2 and TBD2 for OSPFv3 205 o Length: 4 or 16 207 o Router Address: A reachable IPv4 or IPv6 router address for the 208 router that originated the IPv4 or IPv6 prefix advertisement 209 respectively. Such an address would be semantically equivalent to 210 what may be advertised in the OSPFv2 Router Address TLV [RFC3630] 211 or in the OSPFv3 Router IPv6 Address TLV [RFC5329]. 213 The parent TLV of a prefix advertisement MAY include more than one 214 Prefix Source Router Address Sub-TLV, one corresponding to each of 215 the Equal-Cost Multi-Path (ECMP) nodes that originated the given 216 prefix. 218 A received Prefix Source Router Address Sub-TLV that has an invalid 219 length (i.e. not consistent with the prefix's address family) or a 220 Router Address containing an invalid IPv4 or IPv6 address (dependent 221 on address family of the associated prefix) MUST be considered 222 invalid and ignored. Additionally, reception of such Sub-TLV SHOULD 223 be logged as an error (subject to rate-limiting). 225 3. Elements of Procedure 227 This section describes the procedure for advertisement of the Prefix 228 Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs along 229 with the prefix advertisement. 231 The OSPF Router ID of the Prefix Source OSPF Router-ID is set to the 232 OSPF Router ID of the node originating the prefix in the OSPF domain. 234 If the originating node is advertising an OSPFv2 Router Address TLV 235 [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the 236 same address MUST be used in the Router Address field of the Prefix 237 Source Router Address Sub-TLV. When the originating node is not 238 advertising such an address, implementations can determine a unique 239 and reachable address (i.e., advertised with the N-flag set [RFC7684] 240 or N-bit set [RFC8362]) belonging to the originating node to set in 241 the Router Address field. 243 Implementations MAY support the selection of specific prefixes for 244 which the originating node information needs to be included with 245 their prefix advertisements. 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 node. 260 Implementations MAY provide control on ABRs to selectively disable 261 the propagation of the originating node information across area 262 boundaries. 264 Implementations may support the propagation of the originating node 265 information along with a redistributed prefix into the OSPF domain 266 from another routing domain. The details of such mechanisms are 267 outside the scope of this document. Such implementations may also 268 provide control on whether the Router Address in the Prefix Source 269 Router Address Sub-TLV is set as the ABSR node address or as the 270 address of the actual node outside the OSPF domain that owns the 271 prefix. 273 When translating the NSSA prefix advertisements [RFC3101] to the AS 274 external prefix advertisements, the NSSA ABR, follows the same 275 procedures as an ABR generating inter-area prefix advertisements for 276 the propagation of the originating node information. 278 4. Security Considerations 280 Since this document extends the OSPFv2 Extended Prefix LSA, the 281 security considerations for [RFC7684] are applicable. Similarly, 282 since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E- 283 Inter-Area-Prefix-LSA, E-AS-External LSA and E-NSSA-LSA, the security 284 considerations for [RFC8362] are applicable. The new sub-TLVs 285 introduced in this document are optional and do not affect the OSPF 286 route computation and therefore do not affect the security aspects of 287 OSPF protocol operations. A rogue node that can inject prefix 288 advertisements may use the new extensions introduced in this document 289 to indicate incorrect prefix source information. 291 5. IANA Considerations 293 This document requests IANA for the allocation of the codepoints from 294 the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open 295 Shortest Path First v2 (OSPFv2) Parameters" registry. 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |Code | Description | IANA Allocation | 299 |Point| | Status | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | 4 | Prefix Source OSPF Router-ID Sub-TLV| early allocation done | 302 | TBD1| Prefix Source Router Address Sub-TLV| pending | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3: Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs 307 This document requests IANA for the allocation of the codepoints from 308 the "OSPFv3 Extended Prefix TLV Sub-TLVs" registry under the "Open 309 Shortest Path First v3 (OSPFv3) Parameters" registry. 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |Code | Description | IANA Allocation | 313 |Point| | Status | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | 27 | Prefix Source OSPF Router-ID Sub-TLV| early allocation done | 316 |TBD2 | Prefix Source Router Address Sub-TLV| pending | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 4: Codepoints in OSPFv3 Extended-LSA Sub-TLVs 321 6. Acknowledgement 323 Many thanks to Les Ginsberg for his suggestions on this draft. Also 324 thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals 325 Dirk, Smita Selot, Shaofu Peng, John E Drake and Baalajee S for their 326 review and valuable comments. The authors would also like to thank 327 Alvaro Retana for his detailed review and suggestions for the 328 improvement of this document. 330 7. References 332 7.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 340 DOI 10.17487/RFC2328, April 1998, 341 . 343 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 344 (TE) Extensions to OSPF Version 2", RFC 3630, 345 DOI 10.17487/RFC3630, September 2003, 346 . 348 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 349 "Traffic Engineering Extensions to OSPF Version 3", 350 RFC 5329, DOI 10.17487/RFC5329, September 2008, 351 . 353 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 354 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 355 . 357 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 358 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 359 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 360 2015, . 362 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 363 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 364 May 2017, . 366 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 367 F. Baker, "OSPFv3 Link State Advertisement (LSA) 368 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 369 2018, . 371 7.2. Informative References 373 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 374 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 375 and M. Chen, "BGP Link-State extensions for Segment 376 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 377 (work in progress), June 2019. 379 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 380 RFC 3101, DOI 10.17487/RFC3101, January 2003, 381 . 383 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 384 R. Aggarwal, "Support of Address Families in OSPFv3", 385 RFC 5838, DOI 10.17487/RFC5838, April 2010, 386 . 388 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 389 S. Ray, "North-Bound Distribution of Link-State and 390 Traffic Engineering (TE) Information Using BGP", RFC 7752, 391 DOI 10.17487/RFC7752, March 2016, 392 . 394 Authors' Addresses 396 Aijun Wang 397 China Telecom 398 Beiqijia Town, Changping District 399 Beijing 102209 400 China 402 Email: wangaj3@chinatelecom.cn 404 Acee Lindem 405 Cisco Systems 406 301 Midenhall Way 407 Cary, NC 27513 408 USA 410 Email: acee@cisco.com 412 Jie Dong 413 Huawei Technologies 414 Beijing 415 China 417 Email: jie.dong@huawei.com 418 Peter Psenak 419 Cisco Systems 420 Pribinova Street 10 421 Bratislava, Eurovea Centre, Central 3 81109 422 Slovakia 424 Email: ppsenak@cisco.com 426 Ketan Talaulikar 427 Cisco Systems 428 India 430 Email: ketant@cisco.com