idnits 2.17.00 (12 Aug 2021) /tmp/idnits39231/draft-ietf-lsr-ospf-prefix-originator-10.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 2, 2021) is 414 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 4, 2021 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar, Ed. 10 Cisco Systems 11 April 2, 2021 13 OSPF Prefix Originator Extensions 14 draft-ietf-lsr-ospf-prefix-originator-10 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 4, 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 . . . . . . . . . . . . . . . . . 6 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. The IPv4/IPv6 Router Address as defined in 100 [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 respectively provide an 101 address to reach that router. 103 The primary use case for the extensions proposed in this document is 104 to be able to identify the originator of a prefix in the network. In 105 cases where multiple prefixes are advertised by a given router, it is 106 also useful to be able to associate all these prefixes with a single 107 router even when prefixes are advertised outside of the area in which 108 they originated. It also helps to determine when the same prefix is 109 being originated by multiple routers across areas. 111 This document proposes extensions to the OSPF protocol for inclusion 112 of information associated with the router originating the prefix 113 along with the prefix advertisement. These extensions do not change 114 the core OSPF route computation functionality. They provide useful 115 information for topology analysis and traffic engineering, especially 116 on a controller when this information is advertised as an attribute 117 of the prefixes via mechanisms such as Border Gateway Protocol Link- 118 State (BGP-LS) [RFC7752] [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. Protocol Extensions 130 This document defines the Prefix Source OSPF Router-ID and the Prefix 131 Source Router Address Sub-TLVs for inclusion of the Router ID and a 132 reachable address information for the router originating the prefix 133 as a prefix attribute. 135 2.1. Prefix Source OSPF Router-ID Sub-TLV 137 For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional 138 Sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 139 Prefix Source OSPF Router-ID Sub-TLV is an optional Sub-TLV of the 140 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV 141 [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix 142 advertisement. 144 The Prefix Source OSPF Router-ID Sub-TLV has the following format: 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | OSPF Router ID | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: Prefix Source OSPF Router-ID Sub-TLV Format 156 Where: 158 o Type: 4 for OSPFv2 and 27 for OSPFv3 160 o Length: 4 162 o OSPF Router ID : the OSPF Router ID of the OSPF router that 163 originated the prefix advertisement in the OSPF domain. 165 The parent TLV of a prefix advertisement MAY include more than one 166 Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of 167 the Equal-Cost Multi-Path (ECMP) nodes that originated the given 168 prefix. 170 For intra-area prefix advertisements, the Prefix Source OSPF Router- 171 ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router 172 ID field is not the same as Advertising Router field in the 173 containing LSA. Similar validation cannot be reliably performed for 174 inter-area and external prefix advertisements. 176 A received Prefix Source OSPF Router-ID Sub-TLV with OSPF Router ID 177 set to 0 MUST be considered invalid and ignored. Additionally, 178 reception of such Sub-TLV SHOULD be logged as an error (subject to 179 rate-limiting). 181 2.2. Prefix Source Router Address Sub-TLV 183 For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional 184 Sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 185 Prefix Source Router Address Sub-TLV is an optional Sub-TLV of the 186 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV 187 [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix 188 advertisement. 190 The Prefix Source Router Address Sub-TLV has the following format: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type | Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Router Address (4 or 16 octets) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 2: Prefix Source Router Address Sub-TLV Format 202 Where: 204 o Type: 5 (suggested) for OSPFv2 and 28 (suggested) for OSPFv3 206 o Length: 4 or 16 208 o Router Address: A reachable IPv4 or IPv6 router address for the 209 router that originated the IPv4 or IPv6 prefix advertisement 210 respectively. Such an address would be semantically equivalent to 211 what may be advertised in the OSPFv2 Router Address TLV [RFC3630] 212 or in the OSPFv3 Router IPv6 Address TLV [RFC5329]. 214 The parent TLV of a prefix advertisement MAY include more than one 215 Prefix Source Router Address Sub-TLV, one corresponding to each of 216 the Equal-Cost Multi-Path (ECMP) nodes that originated the given 217 prefix. 219 A received Prefix Source Router Address Sub-TLV that has an invalid 220 length (i.e. not consistent with the prefix's address family) MUST be 221 considered invalid and ignored. Additionally, reception of such Sub- 222 TLV SHOULD be logged as an error (subject to rate-limiting). 224 3. Elements of Procedure 226 This section describes the procedure for advertisement of the Prefix 227 Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs along 228 with the prefix advertisement. 230 The OSPF Router ID of the Prefix Source OSPF Router-ID is set to the 231 OSPF Router ID of the node originating the prefix in the OSPF domain. 233 If the originating node is advertising an OSPFv2 Router Address TLV 234 [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the 235 same address MUST be used in the Router Address field of the Prefix 236 Source Router Address Sub-TLV. When the originating node is not 237 advertising such an address, implementations can determine a unique 238 and reachable address (i.e., advertised with the N-flag set [RFC7684] 239 or N-bit set [RFC8362]) belonging to the originating node to set in 240 the Router Address field. 242 When an ABR generates inter-area prefix advertisements into its non- 243 backbone areas corresponding to an inter-area prefix advertisement 244 from the backbone area, the only way to determine the originating 245 node information is based on the Prefix Source OSPF Router-ID and 246 Prefix Source Router Address Sub-TLVs present in the inter-area 247 prefix advertisement originated into the backbone area by an ABR from 248 another non-backbone area. The ABR performs its prefix calculation 249 to determine the set of nodes that contribute to the best prefix 250 reachability. It MUST use the prefix originator information only 251 from this set of nodes. The ABR MUST NOT include the Prefix Source 252 OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it 253 is unable to determine the information of the best originating node. 255 Implementations may support the propagation of the originating node 256 information along with a redistributed prefix into the OSPF domain 257 from another routing domain. The details of such mechanisms are 258 outside the scope of this document. Such implementations may also 259 provide control on whether the Router Address in the Prefix Source 260 Router Address Sub-TLV is set as the ABSR node address or as the 261 address of the actual node outside the OSPF domain that owns the 262 prefix. 264 When translating the NSSA prefix advertisements [RFC3101] to the AS 265 external prefix advertisements, the NSSA ABR, follows the same 266 procedures as an ABR generating inter-area prefix advertisements for 267 the propagation of the originating node information. 269 4. Security Considerations 271 Since this document extends the OSPFv2 Extended Prefix LSA, the 272 security considerations for [RFC7684] are applicable. Similarly, 273 since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E- 274 Inter-Area-Prefix-LSA, E-AS-External LSA and E-NSSA-LSA, the security 275 considerations for [RFC8362] are applicable. The new sub-TLVs 276 introduced in this document are optional and do not affect the OSPF 277 route computation and therefore do not affect the security aspects of 278 OSPF protocol operations. A rogue node that can inject prefix 279 advertisements may use the new extensions introduced in this document 280 to indicate incorrect prefix source information. 282 5. Operational Considerations 284 Consideration should be given to the operation impact of the increase 285 in the size of the OSPF Link-State Database as a result of the 286 protocol extensions in this document. Based on deployment design and 287 requirements, a subset of prefixes may be identified for which the 288 originating node information needs to be included with their prefix 289 advertisements. 291 The propagation of the prefix source node information when doing 292 prefix advertisements across OSPF area or domain boundaries results 293 in the exposure of node information outside of an area or domain 294 within which it is normally hidden or abstracted by the base OSPF 295 protocol. Based on deployment design and requirements, a subset of 296 prefixes may be identified for which the propagation of the 297 originating node information across area boundaries is disabled at 298 the ABRs. 300 The identification of the node that is originating a specific prefix 301 in the network may aid in debugging of issues related to prefix 302 reachability within an OSPF network. 304 6. IANA Considerations 306 This document requests IANA for the allocation of the codepoints from 307 the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open 308 Shortest Path First v2 (OSPFv2) Parameters" registry. 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Code | Description | IANA Allocation | 312 | Point | | Status | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | 4 | Prefix Source OSPF Router-ID | early allocation done | 315 | 5 | Prefix Source Router Address | suggested | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 3: Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs 320 This document requests IANA for the allocation of the codepoints from 321 the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "Open Shortest 322 Path First v3 (OSPFv3) Parameters" registry. 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Code | Description | IANA Allocation | 326 | Point | | Status | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | 27 | Prefix Source OSPF Router-ID | early allocation done | 329 | 28 | Prefix Source Router Address | suggested | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 4: Codepoints in OSPFv3 Extended-LSA Sub-TLVs 334 7. Acknowledgement 336 Many thanks to Les Ginsberg for his suggestions on this draft. Also 337 thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals 338 Dirk, Smita Selot, Shaofu Peng, John E Drake and Baalajee S for their 339 review and valuable comments. The authors would also like to thank 340 Alvaro Retana for his detailed review and suggestions for the 341 improvement of this document. 343 8. References 345 8.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 353 DOI 10.17487/RFC2328, April 1998, 354 . 356 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 357 (TE) Extensions to OSPF Version 2", RFC 3630, 358 DOI 10.17487/RFC3630, September 2003, 359 . 361 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 362 "Traffic Engineering Extensions to OSPF Version 3", 363 RFC 5329, DOI 10.17487/RFC5329, September 2008, 364 . 366 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 367 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 368 . 370 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 371 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 372 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 373 2015, . 375 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 376 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 377 May 2017, . 379 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 380 F. Baker, "OSPFv3 Link State Advertisement (LSA) 381 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 382 2018, . 384 8.2. Informative References 386 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 387 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 388 and M. Chen, "BGP Link-State extensions for Segment 389 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 390 (work in progress), June 2019. 392 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 393 RFC 3101, DOI 10.17487/RFC3101, January 2003, 394 . 396 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 397 R. Aggarwal, "Support of Address Families in OSPFv3", 398 RFC 5838, DOI 10.17487/RFC5838, April 2010, 399 . 401 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 402 S. Ray, "North-Bound Distribution of Link-State and 403 Traffic Engineering (TE) Information Using BGP", RFC 7752, 404 DOI 10.17487/RFC7752, March 2016, 405 . 407 Authors' Addresses 409 Aijun Wang 410 China Telecom 411 Beiqijia Town, Changping District 412 Beijing 102209 413 China 415 Email: wangaj3@chinatelecom.cn 417 Acee Lindem 418 Cisco Systems 419 301 Midenhall Way 420 Cary, NC 27513 421 USA 423 Email: acee@cisco.com 424 Jie Dong 425 Huawei Technologies 426 Beijing 427 China 429 Email: jie.dong@huawei.com 431 Peter Psenak 432 Cisco Systems 433 Pribinova Street 10 434 Bratislava, Eurovea Centre, Central 3 81109 435 Slovakia 437 Email: ppsenak@cisco.com 439 Ketan Talaulikar (editor) 440 Cisco Systems 441 India 443 Email: ketant@cisco.com