idnits 2.17.00 (12 Aug 2021) /tmp/idnits41832/draft-ietf-lsr-ospf-prefix-originator-08.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 8, 2021) is 439 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: September 9, 2021 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar 10 Cisco Systems 11 March 8, 2021 13 OSPF Prefix Originator Extensions 14 draft-ietf-lsr-ospf-prefix-originator-08 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 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 Router-ID Sub-TLV . . . . . . . . . . . . . 3 60 2.2. Prefix Originator 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 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 Router-ID and the Prefix 130 Originator Sub-TLVs for inclusion of the Router ID and a reachable 131 address information for the router originating the prefix as a prefix 132 attribute. 134 2.1. Prefix Source Router-ID Sub-TLV 136 For OSPFv2, the Prefix Source Router-ID Sub-TLV is an optional Sub- 137 TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 138 Prefix Source Router-ID Sub-TLV is an optional Sub-TLV of the Intra- 139 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 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 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 Router-ID sub-TLV, one corresponding to each of the 166 Equal-Cost Multi-Path (ECMP) nodes that originated the given prefix. 168 For intra-area prefix advertisements, the Prefix Source Router-ID 169 Sub-TLV MUST be considered invalid and ignored if it is not the same 170 as Advertising Router ID for the prefix advertisement. 172 A received Prefix Source Router-ID Sub-TLV with OSPF Router ID set to 173 0 MUST be considered invalid and ignored. Additionally, reception of 174 such Sub-TLV SHOULD be logged as an error (subject to rate-limiting). 176 2.2. Prefix Originator Sub-TLV 178 For OSPFv2, the Prefix Originator Sub-TLV is an optional Sub-TLV of 179 the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the Prefix 180 Originator Sub-TLV is an optional Sub-TLV of the Intra-Area-Prefix 181 TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362] when 182 originating either an IPv4 [RFC5838] or an IPv6 prefix advertisement. 184 The Prefix Originator Sub-TLV has the following format: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Router Address (4 or 16 octets) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 2: Prefix Originator Sub-TLV Format 196 Where: 198 o Type: TBD1 for OSPFv2 and TBD2 for OSPFv3 200 o Length: 4 or 16 202 o Router Address: A reachable IPv4 or IPv6 router address for the 203 router that originated the IPv4 or IPv6 prefix advertisement 204 respectively. Such an address would be semantically equivalent to 205 what may be advertised in the OSPFv2 Router Address TLV [RFC3630] 206 or in the OSPFv3 Router IPv6 Address TLV [RFC5329]. 208 A prefix advertisement MAY include more than one Prefix Originator 209 sub-TLV, one corresponding to each of the Equal-Cost Multi-Path 210 (ECMP) nodes that originated the given prefix. 212 A received Prefix Originator Sub-TLV that has an invalid length (i.e. 213 not consistent with the prefix's address family) or a Router Address 214 containing an invalid IPv4 or IPv6 address (dependent on address 215 family of the associated prefix) MUST be considered invalid and 216 ignored. Additionally, reception of such Sub-TLV SHOULD be logged as 217 an error (subject to rate-limiting). 219 3. Elements of Procedure 221 This section describes the procedure for advertisement of the Prefix 222 Source Router-ID and Prefix Originator Sub-TLVs along with the prefix 223 advertisement. 225 The OSPF Router ID of the Prefix Source Router-ID is set to the OSPF 226 Router ID of the node originating the prefix in the OSPF domain. 228 If the originating node is advertising an OSPFv2 Router Address TLV 229 [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the 230 same address SHOULD be used in the Router Address field of the Prefix 231 Originator Sub-TLV. When the originating node is not advertising 232 such an address, implementations MAY support mechanisms to determine 233 a reachable address (e.g., advertised with the N-flag set [RFC7684] 234 or N-bit set [RFC8362] and either matching the OSPF Router ID or the 235 highest IP address) belonging to the originating node to set in the 236 Router Address field. 238 Implementations MAY support the selection of specific prefixes for 239 which the originating node information needs to be included with 240 their prefix advertisements. 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 Router-ID and Prefix 246 Originator Sub-TLVs present in the inter-area prefix advertisement 247 originated into the backbone area by an ABR from another non-backbone 248 area. The ABR performs its prefix calculation to determine the set 249 of nodes that contribute to the best prefix reachability. It MUST 250 use the prefix originator information only from this set of nodes. 251 The ABR MUST NOT include the Prefix Source Router-ID or the Prefix 252 Originator Sub-TLVs when it is unable to determine the information of 253 the best originating node. 255 Implementations MAY provide control on ABRs to selectively disable 256 the propagation of the originating node information across area 257 boundaries. 259 Implementations may support the propagation of the originating node 260 information along with a redistributed prefix into the OSPF domain 261 from another routing domain. The details of such mechanisms are 262 outside the scope of this document. Such implementations may also 263 provide control on whether the Router Address in the Prefix 264 Originator Sub-TLV is set as the ABSR node address or as the address 265 of the actual node outside the OSPF domain that owns the prefix. 267 When translating the NSSA prefix advertisements [RFC3101] to the AS 268 external prefix advertisements, the NSSA ABR, follows the same 269 procedures as an ABR generating inter-area prefix advertisements for 270 the propagation of the originating node information. 272 4. Security Considerations 274 Since this document extends the OSPFv2 Extended Prefix LSA, the 275 security considerations for [RFC7684] are applicable. Similarly, 276 since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E- 277 Inter-Area-Prefix-LSA, E-AS-External LSA and E-NSSA-LSA, the security 278 considerations for [RFC8362] are applicable. The new sub-TLVs 279 introduced in this document are optional and do not affect the OSPF 280 route computation and therefore do not affect the security aspects of 281 OSPF protocol operations. 283 5. IANA Considerations 285 This document requests IANA for the allocation of the codepoints from 286 the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open 287 Shortest Path First v2 (OSPFv2) Parameters" registry. 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Code | Description | IANA Allocation | 291 | Point | | Status | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | 4 | Prefix Source Router-ID Sub-TLV | early allocation done | 294 | TBD1 | Prefix Originator Sub-TLV | pending | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 3: Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs 299 This document requests IANA for the allocation of the codepoints from 300 the "OSPFv3 Extended Prefix TLV Sub-TLVs" registry under the "Open 301 Shortest Path First v3 (OSPFv3) Parameters" registry. 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Code | Description | IANA Allocation | 305 | Point | | Status | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | 27 | Prefix Source Router-ID Sub-TLV | early allocation done | 308 | TBD2 | Prefix Originator Sub-TLV | pending | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 4: Codepoints in OSPFv3 Extended-LSA Sub-TLVs 313 6. Acknowledgement 315 Many thanks to Les Ginsberg for his suggestions on this draft. Also 316 thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals 317 Dirk, Smita Selot, Shaofu Peng, John E Drake and Baalajee S for their 318 review and valuable comments. 320 7. References 322 7.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 330 DOI 10.17487/RFC2328, April 1998, 331 . 333 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 334 (TE) Extensions to OSPF Version 2", RFC 3630, 335 DOI 10.17487/RFC3630, September 2003, 336 . 338 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 339 "Traffic Engineering Extensions to OSPF Version 3", 340 RFC 5329, DOI 10.17487/RFC5329, September 2008, 341 . 343 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 344 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 345 . 347 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 348 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 349 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 350 2015, . 352 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 353 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 354 May 2017, . 356 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 357 F. Baker, "OSPFv3 Link State Advertisement (LSA) 358 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 359 2018, . 361 7.2. Informative References 363 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 364 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 365 and M. Chen, "BGP Link-State extensions for Segment 366 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 367 (work in progress), June 2019. 369 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 370 RFC 3101, DOI 10.17487/RFC3101, January 2003, 371 . 373 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 374 R. Aggarwal, "Support of Address Families in OSPFv3", 375 RFC 5838, DOI 10.17487/RFC5838, April 2010, 376 . 378 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 379 S. Ray, "North-Bound Distribution of Link-State and 380 Traffic Engineering (TE) Information Using BGP", RFC 7752, 381 DOI 10.17487/RFC7752, March 2016, 382 . 384 Authors' Addresses 386 Aijun Wang 387 China Telecom 388 Beiqijia Town, Changping District 389 Beijing 102209 390 China 392 Email: wangaj3@chinatelecom.cn 394 Acee Lindem 395 Cisco Systems 396 301 Midenhall Way 397 Cary, NC 27513 398 USA 400 Email: acee@cisco.com 402 Jie Dong 403 Huawei Technologies 404 Beijing 405 China 407 Email: jie.dong@huawei.com 409 Peter Psenak 410 Cisco Systems 411 Pribinova Street 10 412 Bratislava, Eurovea Centre, Central 3 81109 413 Slovakia 415 Email: ppsenak@cisco.com 417 Ketan Talaulikar 418 Cisco Systems 419 India 421 Email: ketant@cisco.com