idnits 2.17.1 draft-ietf-lsr-ospf-prefix-originator-04.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 (September 12, 2019) is 1682 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 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-mpls-elc-09 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 3 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: March 15, 2020 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar 10 Cisco Systems 11 September 12, 2019 13 OSPF Prefix Originator Extension 14 draft-ietf-lsr-ospf-prefix-originator-04 16 Abstract 18 This document defines Open Shortest Path First (OSPF) encodings to 19 advertise the router-id of the originator of inter-area prefixes for 20 OSPFv2 and OSPFv3 Link-State Advertisements (LSAs). The source 21 originator is needed in several multi-area OSPF use cases. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 15, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Inter-Area Prefix Source Advertisement Use Cases . . . . . . 4 61 5. Prefix Source Router-ID sub-TLV . . . . . . . . . . . . . . . 5 62 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 10.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Appendix A. Inter-Area Topology Retrieval Process . . . . . . . 9 70 Appendix B. Special Considerations on Inter-Area Topology 71 Retrieval . . . . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 [I-D.ietf-ospf-mpls-elc] defines mechanisms to advertise Entropy 77 Readable Label Depth (ERLD) for ingress Label Switching Routers (LSR) 78 to discover other LSR's capability of performing Entropy Label based 79 load-balancing in MPLS networks. The ingress LSR can use this 80 information to construct the appropriate label stack for specific 81 traffic requirements, especially in segment routed networks and other 82 deployments requiring stacked LSPs. 84 However, in inter-area scenarios, the Area Border Router (ABR) does 85 not advertise the originating OSPF router-id for inter-area prefixes. 86 An OSPF router in one area doesn't know the origin area of inter-area 87 prefixes and can't determine the router that originated these 88 prefixes or the ERLD capabilities of the destination. Therefore, it 89 is necessary to advertise the originator of these inter-area prefixes 90 to ensure the ingress LSR can construct the appropriate label stack. 92 More generally, [RFC8476] defines a mechanism to advertise multiple 93 types of supported Maximum SID Depths (MSD) at node and/or link 94 granularity. This information will be referred when the head-end 95 router starts to send traffic to destination prefixes. In inter-area 96 scenario, it is also necessary for the sender to learn the 97 capabilities of the receivers associated with the inter-area 98 prefixes. 100 There is another scenario where knowing the originator of inter-area 101 prefixes is useful. For example, Border Gateway Protocol Link-State 102 (BGP-LS) [RFC7752] describes mechanisms using the BGP protocol to 103 advertise Link-State information. This information can enable a 104 Software Definition Network (SDN) controller to automatically 105 determine the underlay network topology. 107 However, if the underlay network is partitioned into multiple areas 108 and running the OSPF protocol, it is not easy for the SDN controller 109 to rebuild the multi-area topology since ABR that connects multiple 110 areas will normally hide the detailed topology for these non-backbone 111 areas. If only the internal routers within backbone area run the 112 BGP-LS protocol, they just learn and report the summary network 113 information from the non-backbone areas. If the SDN controller can 114 learn the originator of the inter-area prefixes, it is possible to 115 rebuild the inter-area topology. 117 [RFC7794] introduces the Intermediate System to Intermediate System 118 (IS-IS) "IPv4/IPv6 Source Router IDs" Type-Length-Value (TLV) to 119 advertise the source of prefixes leaked from a different IS-IS level. 120 This TLV can be used in the above scenarios. Such solution can also 121 be applied in networks that run the OSPF protocol, but existing OSPF 122 LSAs TLVs must be extended to include the router originating the 123 prefix. 125 This draft provides such solution for the OSPFv2 and OSPFv3 126 protocols. 128 2. Conventions used in this document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Terminology 138 The following terms are used in this document: 140 o ABR: Area Border Router 142 o ERLD: Entropy Readable Label Depth 144 o EL: Entropy Label 145 o IS-IS: Intermediate System to Intermediate System 147 o LSA: Link-State Advertisement 149 o MSD: Maximum SID Depths 151 o NLRI: Network Layer Reachability Information 153 o OSPF: Open Shortest Path First 155 o SID: Segment IDentifier 157 o SDN: Software Definition Network 159 4. Inter-Area Prefix Source Advertisement Use Cases 161 Figure 1 illustrates a topology where OSPF is running in multiple 162 areas. R0-R4 are routers in the backbone area, S1-S4 are internal 163 routers in area 1, and T1-T4 are internal routers in area 2. R1 and 164 R3 are ABRs between area 0 and area 1. R2 and R4 are ABRs between 165 area 0 and area 2. N1 is the network between router S1 and S2 and N2 166 is the network between router T1 and T2. Ls1 is the loopback address 167 of Node S1 and Lt1 is the loopback address of Node T1. 169 +-----------------+ 170 |IP SDN Controller| 171 +--------+--------+ 172 | 173 | BGP-LS 174 | 175 +---------------------+------+--------+-----+--------------+ 176 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 177 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 178 | +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++| 179 | | | | | || | | 180 | | | | | || | | 181 | +-++ +-++ ++-+ +-++ ++++ +-++| 182 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 183 | +--+ +--+ ++-+ +-++ ++-+ +--+| 184 | | | | 185 | | | | 186 | Area 1 | Area 0 | Area 2 | 187 +---------------------+---------------+--------------------+ 189 Figure 1: OSPF Inter-Area Prefix Originator Scenario 191 If S1 wants to send traffic to prefix Lt1 that is connected to T1 in 192 another area, it should know the ERLD and MSD values associated with 193 the node T1, and then construct the right label stack at the ingress 194 node for traffic destined to prefix Lt1. 196 In another scenario, If R0 has some method to learn the originator of 197 network N1 and reports such information to IP SDN controller, then it 198 is possible for the controller to reconstruct the topology in the 199 non-backbone areas. The topology reconstruction process and its 200 limitations are described in the Appendix A and Appendix B. 202 From the above scenarios, we can conclude it is useful to define the 203 OSPF prefix originator sub TLV . 205 5. Prefix Source Router-ID sub-TLV 207 [RFC7684] and [RFC8362] respectively define TLV-based LSAs for OSPFv2 208 and OSPFv3. These documents facilitate addition of new attributes 209 for prefixes and provide the basis for a sub-TLV to advertise the 210 "Prefix Source Router ID". For OSPFv2, this sub-TLV is a sub-TLV of 211 OSPFv2 Extended Prefix TLV which SHOULD be included in the "OSPFv2 212 Extended Prefix Opaque LSA" [RFC7684] for inter-area prefixes. For 213 OSPFv3, this sub-TLV is a sub-TLV of "Inter-Area-Prefix TLV", which 214 SHOULD be included in the "E-Inter-Area-Prefix-LSA" [RFC8362]. 216 The "Prefix Source Router-ID" sub-TLV has the following format: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type | Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Prefix Source Router-ID | 224 +---------------------------------------------------------------+ 225 Figure 2: Prefix Source Router-ID sub-TLV Format 227 o Source Router-ID Sub-TLV Type: TBD1 [RFC7684] or TBD2 [RFC8362] 229 o Length: 4 231 o Value: Router-ID of OSPFv2/OSPFv3 router that is the source of the 232 prefix. 234 This sub-TLV provides the same functionality as the IS-IS "IPv4/IPv6 235 Source Router" TLV defined in [RFC7794]. 237 6. Elements of Procedure 239 When an ABR, for example R2 in Figure 1, receives a Router-LSA 240 advertisement in area 2, it SHOULD originate the corresponding 241 "OSPFv2 Extended Prefix Opaque LSA" for OSPFv2 or "E-Inter-Area- 242 Prefix-LSA" for OSPFv3 that includes the Source Router-ID sub-TLV for 243 the network prefixes. For example, to identify the source router 244 prefix Lt1 and other inter-area prefixes in Figure 1. 246 When a router in another area, e.g., S1, receives such LSA, it then 247 can ascertain that prefix Lt1 is associated with node T1 and obtain 248 the ERLD or MSD value from T1's Router-Information LSA [RFC7770] and 249 construct the right label stack at the ingress node S1 for traffic 250 destined to prefix Lt1. 252 When a router in another area, e.g., R0, receives such LSA, it learns 253 the Prefix Source Router-id and includes it in the prefix information 254 advertised to an SDN controller as described in 255 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The SDN controller can 256 then use such information to build the inter-area topology according 257 to the process described in the Appendix A. The topology retrieval 258 process may not suitable for some environments as stated in 259 Appendix B. 261 7. Security Considerations 263 Since this document extends the "OSPFv2 Extended Prefix LSA" and 264 "OSPFv3 E-Inter-Area-Prefix LSA", the security considerations for 265 [RFC7684] and [RFC8362] are applicable. 267 Modification of the "Prefix Source Sub-TLV" could be used for a 268 Denial-of-Service attack and could inhibit the use cases described in 269 Section 4. If the OSPF domain is vulnerable to such attacks, OSPF 270 authentication should be used as defined for OSPFv2 in [RFC5709] and 271 [RFC7474] and for OSPFv3 in [RFC7166]. 273 Additionally, advertisement of the prefix source for inter-area 274 prefixes facilitates reconstruction of the OSPF topology for other 275 areas. Network operators may consider their topologies to be 276 sensitive confidential data. For OSPFv3, IPsec can be used to 277 provide confidentiality [RFC4552]. Since there is no standard 278 defined for native OSPFv2 IPsec, some form of secure tunnel is 279 required to provide confidentiality. 281 8. IANA Considerations 283 This specification defines the Prefix Source Router-ID sub-TLV as 284 described in Section 5. This value should be added to the both 285 existing "OSPFv2 Extended Prefix TLV Sub-TLVs" and "OSPFv3 Extended- 286 LSA Sub-TLVs" registries. 288 The following sub-TLV is added to the "OSPFv2 Extended Prefix TLV 289 Sub-TLVs" registry. The allocation policy is IETF Review as defined 290 in [RFC7684] 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Code Point | Description | Status | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 3: Code Point in "OSPFv2 Extended Prefix TLV Sub-TLVs" 299 The following sub-TLV is added to the "OSPFv3 Extended-LSA Sub-TLVs" 300 registry. The allocation policy is IETF Review as defined in 301 [RFC8362] 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Code Point | Description | Status | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 4: Code Point in "OSPFv3 Extended-LSA Sub-TLVs" 310 9. Acknowledgement 312 Many thanks to Les Ginsberg for his suggestions on this draft. Also 313 thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals 314 Dirk, Shaofu Peng, and John E Drake for their valuable comments. 316 10. References 318 10.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 326 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 327 . 329 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 330 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 331 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 332 2009, . 334 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 335 Authentication Trailer for OSPFv3", RFC 7166, 336 DOI 10.17487/RFC7166, March 2014, 337 . 339 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 340 "Security Extension for OSPFv2 When Using Manual Key 341 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 342 . 344 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 345 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 346 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 347 2015, . 349 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 350 S. Shaffer, "Extensions to OSPF for Advertising Optional 351 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 352 February 2016, . 354 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 355 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 356 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 357 March 2016, . 359 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 360 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 361 May 2017, . 363 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 364 F. Baker, "OSPFv3 Link State Advertisement (LSA) 365 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 366 2018, . 368 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 369 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 370 DOI 10.17487/RFC8476, December 2018, 371 . 373 10.2. Informative References 375 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 376 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 377 and M. Chen, "BGP Link-State extensions for Segment 378 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 379 (work in progress), June 2019. 381 [I-D.ietf-ospf-mpls-elc] 382 Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. 383 Litkowski, "Signaling Entropy Label Capability and Entropy 384 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 385 mpls-elc-09 (work in progress), September 2019. 387 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 388 S. Ray, "North-Bound Distribution of Link-State and 389 Traffic Engineering (TE) Information Using BGP", RFC 7752, 390 DOI 10.17487/RFC7752, March 2016, 391 . 393 Appendix A. Inter-Area Topology Retrieval Process 395 When an IP SDN Controller receives BGP-LS [RFC7752] information, it 396 should compare the prefix Network Layer Reachability Information 397 (NLRI) that is included in the BGP-LS NLRI. When it encounters the 398 same prefix but with different source router ID, it should extract 399 the corresponding area-ID, rebuild the link between these two source 400 routers in the non-backbone area. Below is one example that based on 401 the Figure 1: 403 Assuming we want to rebuild the connection between router S1 and 404 router S2 located in area 1: 406 a. Normally, router S1 will advertise prefix N1 within its router- 407 LSA. 409 b. When this router-LSA reaches the ABR router R1, it will convert 410 it into summary-LSA, add the Prefix Source Router-ID sub-TLV, 411 which is router id of S1 in this example. 413 c. R1 then floods this extension summary-LSA to R0, which is using 414 the BGP-LS protocol with IP SDN Controller. The controller then 415 knows the prefix for N1 is from S1. 417 d. Router S2 will perform a similar process, and the controller will 418 also learn that prefix N1 is also from S2. 420 e. Then it can reconstruct the link between S1 and S2, using the 421 prefix N1. The topology within Area 1 can then be reconstructed 422 accordingly. 424 Iterating the above process continuously, the IP SDN controller can 425 retrieve a detailed topology that spans multiple areas. 427 Appendix B. Special Considerations on Inter-Area Topology Retrieval 429 The above topology retrieval process can be applied in the case where 430 each point-to-point or multi-access link connecting routers is 431 assigned a unique prefix. However, there are some situations where 432 this heuristic cannot be applied. Specifically, the cases where the 433 link is unnumbered or the prefix corresponding to the link is an 434 anycast prefix. 436 The Appendix A heuristic to rebuild the topology can normally be used 437 if all links are numbered. For anycast prefixes, if it corresponds 438 to the loopback interface and has a host prefix length, i.e., 32 for 439 IPv4 prefixes and 128 for IPv6 prefixes, Appendix A can also applied 440 since these anycast prefixes are not required to reconstruct the 441 topology. 443 Authors' Addresses 445 Aijun Wang 446 China Telecom 447 Beiqijia Town, Changping District 448 Beijing 102209 449 China 451 Email: wangaj3@chinatelecom.cn 453 Acee Lindem 454 Cisco Systems 455 301 Midenhall Way 456 Cary, NC 27513 457 USA 459 Email: acee@cisco.com 460 Jie Dong 461 Huawei Technologies 462 Beijing 463 China 465 Email: jie.dong@huawei.com 467 Peter Psenak 468 Cisco Systems 469 Pribinova Street 10 470 Bratislava, Eurovea Centre, Central 3 81109 471 Slovakia 473 Email: ppsenak@cisco.com 475 Ketan Talaulikar 476 Cisco Systems 477 S.No. 154/6, Phase I, Hinjawadi 478 Pune 411 057 479 India 481 Email: ketant@cisco.com