idnits 2.17.00 (12 Aug 2021) /tmp/idnits44040/draft-ietf-lsr-ospf-prefix-originator-06.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 (June 30, 2020) is 690 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: January 1, 2021 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar 10 Cisco Systems 11 June 30, 2020 13 OSPF Prefix Originator Extensions 14 draft-ietf-lsr-ospf-prefix-originator-06 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 January 1, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 . . . . . . . . . . . . . 4 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 Appendix A. Inter-Area Topology Retrieval Process . . . . . . . 9 69 Appendix B. Special Considerations on Inter-Area Topology 70 Retrieval . . . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 identification of the originating router for a prefix in OSPF 81 varies by the type of the prefix and is currently not always 82 possible. For intra-area prefixes, the originating router is 83 identified by the advertising Router ID field of the area-scoped LSA 84 used for those prefix advertisements. However, for the inter-area 85 prefixes advertised by the Area Border Router (ABR), the advertising 86 Router ID field of their area-scoped LSAs is set to the ABR itself 87 and the information about the router originating the prefix 88 advertisement is lost in this process of prefix propagation across 89 areas. For Autonomous System (AS) external prefixes, the originating 90 router may be considered as the Autonomous System Border Router 91 (ASBR) and is identified by the advertising Router ID field of the 92 AS-scoped LSA used. However, the actual originating router for the 93 prefix may be a remote router outside the OSPF domain. Similarly, 94 when an ABR performs translation of Not-So-Stubby Area (NSSA) 95 [RFC3101] LSAs to AS-external LSAs, the information associated with 96 the NSSA ASBR (or the router outside the OSPF domain) is not conveyed 97 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. The IPv4/IPv6 Router Address as defined in 102 [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 respectively provide an 103 address to reach that router. 105 The primary use case for the extensions proposed in this document is 106 to be able to identify the originator of the prefix in the network. 107 In cases where multiple prefixes are advertised by a given router, it 108 is also useful to be able to associate all these prefixes with a 109 single router even when prefixes are advertised outside of the area 110 in which they originated. It also helps to determine when the same 111 prefix is being originated by multiple routers across areas. 113 This document proposes extensions to the OSPF protocol for inclusion 114 of information associated with the router originating the prefix 115 along with the prefix advertisement. These extensions do not change 116 the core OSPF route computation functionality. They provide useful 117 information for topology analysis and traffic engineering, especially 118 on a controller when this information is advertised as an attribute 119 of the prefixes via mechanisms such as Border Gateway Protocol Link- 120 State (BGP-LS) [RFC7752]. 122 Applications related to use of the prefix originating node 123 information for topology reconstruction process on a controller and 124 the associated limitations are described in Appendix A and 125 Appendix B. 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 Router-ID and the Prefix 138 Originator Sub-TLVs for inclusion of the Router ID and a reachable 139 address information for the router originating the prefix as a prefix 140 attribute. 142 2.1. Prefix Source Router-ID Sub-TLV 144 For OSPFv2, the Prefix Source Router-ID Sub-TLV is an optional Sub- 145 TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the 146 Prefix Source Router-ID Sub-TLV is an optional Sub-TLV of the Intra- 147 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 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 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 A prefix advertisement MAY include more than one Prefix Source 173 Router-ID sub-TLV, one corresponding to each of the Equal-Cost Multi- 174 Path (ECMP) nodes that originated the given prefix. 176 A received Prefix Source Router-ID Sub-TLV with OSPF Router ID set to 177 0 MUST be considered invalid and ignored. Additionally, reception of 178 such Sub-TLV SHOULD be logged as an error (subject to rate-limiting). 180 2.2. Prefix Originator Sub-TLV 182 For OSPFv2, the Prefix Originator Sub-TLV is an optional Sub-TLV of 183 the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the Prefix 184 Originator Sub-TLV is an optional Sub-TLV of the Intra-Area-Prefix 185 TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362] when 186 originating either an IPv4 [RFC5838] or an IPv6 prefix advertisement. 188 The Prefix Originator Sub-TLV has the following format: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Router Address (4 or 16 octects) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 2: Prefix Originator Sub-TLV Format 200 Where: 202 o Type: TBD1 for OSPFv2 and TBD2 for OSPFv3 204 o Length: 4 or 16 206 o Router Address: A reachable IPv4 or IPv6 router address for the 207 router that originated the IPv4 or IPv6 prefix advertisement. 208 Such an address would be semantically equivalent to what may be 209 advertised in the OSPFv2 Router Address TLV [RFC3630] or in the 210 OSPFv3 Router IPv6 Address TLV [RFC5329]. 212 A prefix advertisement MAY include more than one Prefix Originator 213 sub-TLV, one corresponding to each of the Equal-Cost Multi-Path 214 (ECMP) nodes that originated the given prefix. 216 A received Prefix Originator Sub-TLV that has an invalid length (not 217 4 or 16) or a Reachable Address containing an invalid IPv4 or IPv6 218 address (dependent on address family of the associated prefix) MUST 219 be considered invalid and ignored. Additionally, reception of such 220 Sub-TLV SHOULD be logged as an error (subject to rate-limiting). 222 [RFC7794] provides similar functionality for the Intermediate System 223 to Intermediate System (IS-IS) protocol. 225 3. Elements of Procedure 227 This section describes the procedure for advertisement of the Prefix 228 Source Router-ID and Prefix Originator Sub-TLVs along with the prefix 229 advertisement. 231 The OSPF Router ID of the Prefix Source Router-ID is set to the OSPF 232 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 that 236 value is set in the Router Address field of the Prefix Originator 237 Sub-TLV. When the orignating node is not advertising such an 238 address, implementations MAY support mechanisms to determine a 239 reachable address belonging to the originating node to set in the 240 Router Address field. Such mechanisms are outside the scope of this 241 document. 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 Router-ID and Prefix 251 Originator Sub-TLVs present in the inter-area prefix advertisement 252 originated into the backbone area by an ABR for another non-backbone 253 area. The ABR performs its prefix calculation to determine the set 254 of nodes that contribute to the best prefix reachability. It MUST 255 use the prefix originator information only from this set of nodes. 256 The ABR MUST NOT include the Prefix Source Router-ID or the Prefix 257 Originator Sub-TLVs when it is unable to determine the information of 258 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 269 Originator Sub-TLV is set as the ABSR node address or as the address 270 of the actual node outside the OSPF domain that owns the prefix. 272 When translating the NSSA prefix advertisements [RFC3101] to the AS 273 external prefix advertisements, the NSSA ABR, follows the same 274 procedures as an ABR generating inter-area prefix advertisements for 275 the propagation of the originating node information. 277 4. Security Considerations 279 Since this document extends the OSPFv2 Extended Prefix LSA, the 280 security considerations for [RFC7684] are applicable. Similarly, 281 since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E- 282 Inter-Area-Prefix-LSA, E-AS-External LSA and E-NSSA-LSA, the security 283 considerations for [RFC8362] are applicable. 285 5. IANA Considerations 287 This document requests IANA for the allocation of the codepoint from 288 the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open 289 Shortest Path First v2 (OSPFv2) Parameters" registry. 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Code | Description | IANA Allocation | 293 | Point | | Status | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | 4 | Prefix Source Router-ID Sub-TLV | early allocation done | 296 | TBD1 | Prefix Originator Sub-TLV | pending | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 3: Code Points in OSPFv2 Extended Prefix TLV Sub-TLVs 301 This document requests IANA for the allocation of the codepoint from 302 the "OSPFv3 Extended Prefix TLV Sub-TLVs" registry under the "Open 303 Shortest Path First v3 (OSPFv3) Parameters" registry. 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Code | Description | IANA Allocation | 307 | Point | | Status | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | 27 | Prefix Source Router-ID Sub-TLV | early allocation done | 310 | TBD2 | Prefix Originator Sub-TLV | pending | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 4: Code Points in OSPFv3 Extended-LSA Sub-TLVs 315 6. Acknowledgement 317 Many thanks to Les Ginsberg for his suggestions on this draft. Also 318 thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals 319 Dirk, Smita Selot, Shaofu Peng, and John E Drake for their valuable 320 comments. 322 7. References 324 7.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 332 DOI 10.17487/RFC2328, April 1998, 333 . 335 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 336 RFC 3101, DOI 10.17487/RFC3101, January 2003, 337 . 339 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 340 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 341 . 343 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 344 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 345 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 346 2015, . 348 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 349 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 350 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 351 March 2016, . 353 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 354 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 355 May 2017, . 357 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 358 F. Baker, "OSPFv3 Link State Advertisement (LSA) 359 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 360 2018, . 362 7.2. Informative References 364 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 365 (TE) Extensions to OSPF Version 2", RFC 3630, 366 DOI 10.17487/RFC3630, September 2003, 367 . 369 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 370 "Traffic Engineering Extensions to OSPF Version 3", 371 RFC 5329, DOI 10.17487/RFC5329, September 2008, 372 . 374 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 375 R. Aggarwal, "Support of Address Families in OSPFv3", 376 RFC 5838, DOI 10.17487/RFC5838, April 2010, 377 . 379 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 380 S. Ray, "North-Bound Distribution of Link-State and 381 Traffic Engineering (TE) Information Using BGP", RFC 7752, 382 DOI 10.17487/RFC7752, March 2016, 383 . 385 Appendix A. Inter-Area Topology Retrieval Process 387 When an IP SDN Controller receives BGP-LS [RFC7752] information, it 388 should compare the prefix Network Layer Reachability Information 389 (NLRI) that is included in the BGP-LS NLRI. When it encounters the 390 same prefix but with different source router ID, it should extract 391 the corresponding area-ID, rebuild the link between these two source 392 routers in the non-backbone area. Below is one example that based on 393 the Figure 5 which illustrates a topology where OSPF is running in 394 multiple areas. 396 +-----------------+ 397 |IP SDN Controller| 398 +--------+--------+ 399 | 400 | BGP-LS 401 | 402 +---------------------+------+--------+-----+--------------+ 403 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 404 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 405 | +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++| 406 | | | | | || | | 407 | | | | | || | | 408 | +-++ +-++ ++-+ +-++ ++++ +-++| 409 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 410 | +--+ +--+ ++-+ +-++ ++-+ +--+| 411 | | | | 412 | | | | 413 | Area 1 | Area 0 | Area 2 | 414 +---------------------+---------------+--------------------+ 416 Figure 5: OSPF Inter-Area Prefix Originator Scenario 418 R0-R4 are routers in the backbone area, S1-S4 are internal routers in 419 area 1, and T1-T4 are internal routers in area 2. R1 and R3 are ABRs 420 between area 0 and area 1. R2 and R4 are ABRs between area 0 and 421 area 2. N1 is the network between router S1 and S2 and N2 is the 422 network between router T1 and T2. Ls1 is the loopback address of 423 Node S1 and Lt1 is the loopback address of Node T1. 425 Assuming we want to rebuild the connection between router S1 and 426 router S2 located in area 1: 428 a. Normally, router S1 will advertise prefix N1 within its router- 429 LSA. 431 b. When this router-LSA reaches the ABR router R1, it will convert 432 it into summary-LSA, add the Source Router-ID Sub-TLV and the 433 Prefix Originator Sub-TLV, as described in Section 3. 435 c. R1 then floods this extension summary-LSA to R0, which is using 436 the BGP-LS protocol with IP SDN Controller. The controller then 437 knows the prefix for N1 is from S1. 439 d. Router S2 will perform a similar process, and the controller will 440 also learn that prefix N1 is also from S2. 442 e. Then it can reconstruct the link between S1 and S2, using the 443 prefix N1. The topology within Area 1 can then be reconstructed 444 accordingly. 446 Iterating the above process continuously, the IP SDN controller can 447 retrieve a detailed topology that spans multiple areas. 449 Appendix B. Special Considerations on Inter-Area Topology Retrieval 451 The above topology retrieval process can be applied in the case where 452 each point-to-point or multi-access link connecting routers is 453 assigned a unique prefix. However, there are some situations where 454 this heuristic cannot be applied. Specifically, the cases where the 455 link is unnumbered or the prefix corresponding to the link is an 456 anycast prefix. 458 The Appendix A heuristic to rebuild the topology can normally be used 459 if all links are numbered. For anycast prefixes, if it corresponds 460 to the loopback interface and has a host prefix length, i.e., 32 for 461 IPv4 prefixes and 128 for IPv6 prefixes, Appendix A can also applied 462 since these anycast prefixes are not required to reconstruct the 463 topology. 465 Authors' Addresses 466 Aijun Wang 467 China Telecom 468 Beiqijia Town, Changping District 469 Beijing 102209 470 China 472 Email: wangaj3@chinatelecom.cn 474 Acee Lindem 475 Cisco Systems 476 301 Midenhall Way 477 Cary, NC 27513 478 USA 480 Email: acee@cisco.com 482 Jie Dong 483 Huawei Technologies 484 Beijing 485 China 487 Email: jie.dong@huawei.com 489 Peter Psenak 490 Cisco Systems 491 Pribinova Street 10 492 Bratislava, Eurovea Centre, Central 3 81109 493 Slovakia 495 Email: ppsenak@cisco.com 497 Ketan Talaulikar 498 Cisco Systems 499 India 501 Email: ketant@cisco.com