idnits 2.17.00 (12 Aug 2021) /tmp/idnits42636/draft-ietf-lsr-ospf-prefix-originator-02.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 25, 2019) is 1000 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 == Outdated reference: draft-ietf-ospf-mpls-elc has been published as RFC 9089 Summary: 1 error (**), 0 flaws (~~), 4 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: February 26, 2020 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 K. Talaulikar 9 P. Psenak 10 Cisco Systems 11 August 25, 2019 13 OSPF Extension for Prefix Originator 14 draft-ietf-lsr-ospf-prefix-originator-02 16 Abstract 18 This document describes Open Shortest Path First (OSPF) v2 and OSPFv3 19 encodings to advertise the router-id of the originator of inter-area 20 prefixes for OSPFv2 and OSPFv3 Link-State Advertisement (LSA), which 21 are needed in several use cases in 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 February 26, 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. Conventions used in this document . . . . . . . . . . . . . . 4 61 5. Scenario Description . . . . . . . . . . . . . . . . . . . . 4 62 6. Prefix Source Router-ID sub-TLV . . . . . . . . . . . . . . . 5 63 7. Extended LSA Elements of Procedure . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 11.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. Inter-Area Topology Retrieval Process . . . . . . . 8 71 Appendix B. Special Considerations on Inter-Area Topology 72 Retrieval . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 [I-D.ietf-ospf-mpls-elc] defines mechanisms to Entropy Readable Label 78 Depth (ERLD) for ingress Label Switching Router (LSR) to discover 79 each LSR's capability of performing Entropy Label (EL) -based load- 80 balancing in Multi Protocol Label Switch (MPLS) networks. The 81 ingress LSR can use this information to push the appropriate label 82 stack for specific traffic, especially in segment routing 83 environments and other stacked LSPs scenarios. 85 However, in inter-area scenarios, the Area Border Router (ABR) does 86 not advertise the originating OSPF router-id for inter-area prefixes. 87 An OSPF router in one area doesn't know where the prefixes really 88 came from and can't determine the router that originated inter-area 89 prefixes and then can't judge the ERLD capabilities of the 90 destination. It is necessary to transfer the originator information 91 of these inter-area prefixes to ensure the ingress LSR constructs the 92 right Label stack. 94 More generally, draft [RFC8476] defines a mechanism to advertise 95 multiple types of supported Maximum SID Depths (MSD) at node and/or 96 link granularity. This information will be referred when the head- 97 end router starts to send traffic to destination prefixes. In inter- 98 area scenario, it is also necessary for the sender to learn the 99 capabilities of the receivers associated with the inter-area 100 prefixes. 102 There is also another scenario where knowing the originator of inter- 103 area prefixes is useful. For example, Border Gateway Protocol Link- 104 State (BGP-LS) [RFC7752] describes mechanisms using the BGP protocol 105 to advertise Link-State information. This can enable an Soft 106 Definition Network (SDN) controller to collect the underlay network 107 topology automatically. 109 But if the underlay network is divided into multiple areas and 110 running the OSPF protocol, it is not easy for the SDN controller to 111 rebuild the multi-area topology, because normally an ABR that 112 connects multiple areas will hide the detailed topology information 113 for these non-backbone areas. If only the router in backbone area 114 runs the BGP-LS protocol, it just learn and report the summary 115 network information from the non-backbone areas. If the SDN 116 controller can learn the originator of the inter-area prefixes, it is 117 possible for them to rebuild the inter-area topology automatically. 119 [RFC7794] introduces the Intermediate System to Intermediate System 120 (IS-IS) "IPv4/IPv6 Source Router IDs" Type-Length-Value (TLV) to 121 advertise the source of the prefixes redistributed from a different 122 IS-IS level. This TLV can be used in the above scenarios. Such 123 solution can also be applied in networks that run the OSPF protocol, 124 but the related LSAs TLV must be extended. 126 This draft provides such solution for the OSPFv2 and OSPFv3 127 protocols. 129 2. Conventions used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] . 135 3. Terminology 137 The following terms are used in this document: 139 o ABR: Area Border Router 141 o ERLD: Entropy Readable Label Depth 143 o EL: Entropy Label 144 o IS-IS: Intermediate System to Intermediate System 146 o LSA: Link-State Advertisement 148 o MSD: Maximum SID Depths 150 o OSPF: Open Shortest Path First 152 o SID: Segment IDentifier 154 4. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119] . 160 5. Scenario Description 162 Figure 1 illustrates the topology scenario when OSPF is running in 163 multi-area. R0-R4 are routers in backbone area, S1-S4,T1-T4 are 164 internal routers in area 1 and area 2 respectively. R1 and R3 are 165 area border routers between area 0 and area 1. R2 and R4 are area 166 border routers between area 0 and area 2. N1 is the network between 167 router S1 and S2 and N2 is the network between router T1 and T2. Ls1 168 is the loopback address of Node S1 and Lt1 is the loopback address of 169 Node T1. 171 +-----------------+ 172 |IP SDN Controller| 173 +--------+--------+ 174 | 175 | BGP-LS 176 | 177 +---------------------+------+--------+-----+--------------+ 178 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 179 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 180 | +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++| 181 | | | | | || | | 182 | | | | | || | | 183 | +-++ +-++ ++-+ +-++ ++++ +-++| 184 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 185 | +--+ +--+ ++-+ +-++ ++-+ +--+| 186 | | | | 187 | | | | 188 | Area 1 | Area 0 | Area 2 | 189 +---------------------+---------------+--------------------+ 191 Figure 1: OSPF Inter-Area Prefix Originator Scenario 193 If S1 wants to send traffic to prefix Lt1 that is connected T1 in 194 another area, it should know the ERLD, and MSD values that are 195 associated with the node T1, and then construct the right label stack 196 at the ingress node for the target traffic. 198 In another scenario, If R0 has some method to learn the originator of 199 network N1 and reports such information to IP SDN controller, then it 200 is possible for the controller to retrieval the topology in non- 201 backbone area. The topology retrieval process and its usage 202 limitation are described in the Appendix A and Appendix B. 204 From the above scenarios, we can conclude it is useful to introduce 205 and define the prefix originator sub TLV within OSPF. 207 6. Prefix Source Router-ID sub-TLV 209 [RFC7684] and [RFC8362] define the TLV extensions for OSPFv2 and 210 OSPFv3 respectively. These documents facilitate addition of new 211 attributes for prefixes. Based on these formats, we can define new 212 sub-TLV to advertise the "Prefix Source Router ID", as that defined 213 in [RFC7794]. 215 The "Prefix Source Router-ID" sub-TLV has the following format: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type | Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Prefix Source Router-ID | 223 +---------------------------------------------------------------+ 224 Figure 2: Prefix Source Router-ID sub-TLV Format 226 o Source Router-ID Sub-TLV Type: TBD1[RFC7684] or TBD2 [RFC8362] 228 o Length: 4 230 o Value: Router-ID of OSPFv2/OSPFv3 source router 232 For OSPFv2, this sub-TLV is a sub-TLV of OSPFv2 Extended Prefix TLV, 233 which is included in the "OSPFv2 Extended Prefix Opaque LSA" 234 [RFC7684]. 236 For OSPFv3, this sub-TLV is a sub-TLV of "Inter-Area-Prefix TLV", 237 which is included in the "E-Inter-Area-Prefix-LSA". 239 7. Extended LSA Elements of Procedure 241 When an ABR, for example R2 in Fig.1, receives the Router-LSA 242 announcement in area 2, it should originate the corresponding "OSPFv2 243 Extended Prefix Opaque LSA" for OSPFv2 or "E-Inter-Area-Prefix-LSA" 244 for OSPFv3 that includes the Source Router-ID sub-TLV for the network 245 prefixes, e.g., for prefix Lt1, N2. etc., which identifies the source 246 router that advertised the prefix. 248 When S1 in another area receives such LSA, it then can learn that 249 prefix Lt1 is associated with node T1, check the ERLD, or MSD value 250 according to its necessity, and construct the right label stack at 251 the ingress node S1 for the traffic destined to Lt1. 253 When R0 receives such LSA, it learns the Prefix Source Router-id and 254 includes it in the prefix information advertised to an SDN controller 255 as described in[I-D.ietf-idr-bgp-ls-segment-routing-ext]. The SDN 256 controller can then use such information to build the inter-area 257 topology according to the process described in the Appendix A. The 258 topology retrieval process may not suitable for some environments as 259 stated in Appendix B. 261 8. Security Considerations 263 Security concerns for OSPF are addressed in [RFC5709] 265 Advertisement of the additional information defined in this document 266 introduces no new security concerns 268 9. IANA Considerations 270 This specification defines one Prefix Source Router-ID sub-TLV as 271 described in Section 6. This value should be added to the existing 272 OSPFv2 Extended Prefix TLV Sub-TLVs registry and OSPFv3 Extended-LSA 273 Sub-TLVs registry respectively. 275 Th following new sub-TLV is added to the registry of "OSPFv2 Extended 276 Prefix TLV Sub-TLVs". The allocation policy is IETF Review that 277 defined in [RFC7684] 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 280 | Code Point | Description | Status | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 282 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 284 Figure 3: Prefix Source sub-TLV CodePoint from OSPFv2 Extended Prefix TLV Sub-TLVs 285 The following sub-TLV is added to the registry of "OSPFv3 Extended- 286 LSA Sub-TLVs". The allocation is IETF Review that defined in 287 [RFC8362] 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 290 | Code Point | Description | Status | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 292 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 294 Figure 4: Prefix Source sub-TLV CodePoint from OSPFv3 Extended-LSA Sub-TLVs 296 10. Acknowledgement 298 Many thanks to Les Ginsberg for his valuable suggestions on this 299 draft. And also thanks Jeff Tantsura,Rob Shakir, Van De Velde 300 Gunter, Goethals Dirk, Shaofu Peng, John E Drake for their valuable 301 comments on this draft. 303 11. References 305 11.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 313 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 314 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 315 2009, . 317 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 318 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 319 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 320 2015, . 322 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 323 S. Ray, "North-Bound Distribution of Link-State and 324 Traffic Engineering (TE) Information Using BGP", RFC 7752, 325 DOI 10.17487/RFC7752, March 2016, 326 . 328 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 329 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 330 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 331 March 2016, . 333 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 334 F. Baker, "OSPFv3 Link State Advertisement (LSA) 335 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 336 2018, . 338 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 339 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 340 DOI 10.17487/RFC8476, December 2018, 341 . 343 11.2. Informative References 345 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 346 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 347 and M. Chen, "BGP Link-State extensions for Segment 348 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 349 (work in progress), June 2019. 351 [I-D.ietf-ospf-mpls-elc] 352 Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. 353 Litkowski, "Signaling Entropy Label Capability and Entropy 354 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 355 mpls-elc-08 (work in progress), May 2019. 357 Appendix A. Inter-Area Topology Retrieval Process 359 When an IP SDN Controller receives this information, it should 360 compare the prefix NLRI that included in the BGP-LS packet. When it 361 encounters the same prefix but with different source router ID, it 362 should extract the corresponding area-ID, rebuild the link between 363 these two different source routers in non-backbone area. Belows is 364 one example that based on the Fig.1: 366 Assuming we want to rebuild the connection between router S1 and 367 router S2 that locates in area 1: 369 a. Normally, router S1 will advertise prefix N1 within its router- 370 LSA. 372 b. When this router-LSA reaches the ABR router R1, it will convert 373 it into summary-LSA, add the Prefix Source Router-ID sub-TLV, 374 which is router id of S1 in this example. 376 c. R1 then floods this extension summary-LSA to R0, which is running 377 BGP-LS protocol with IP SDN Controller. The controller then 378 knows the prefixes of N1 is from S1. 380 d. Router S2 will do the similar process, and the controller will 381 also learn that prefixes N1 is also from S2. 383 e. Then it can reconstruct the link between S1 and S2, using the 384 prefix N1. The topology within Area 1 can then be reconstructed 385 accordingly. 387 Iterating the above process continuously, an IP SDN controller can 388 retrieve a detailed topology that spans multiple areas. 390 Appendix B. Special Considerations on Inter-Area Topology Retrieval 392 The above topology retrieval process can be applied in the case where 393 each link between routers is assigned a unique prefix. However, 394 there are some situations where this heuristic cannot be applied. 395 Specifically, the cases where the link is unnumbered or the prefix 396 corresponding to the link is an anycast prefix and is not unique. 398 The Appendix A heuristic to rebuild the topology can normally be used 399 if all links are numbered and the anycast prefixes correspond to 400 loopbacks and have a host prefix length, i.e., 32 for IPv4 prefixes 401 and 128 for IPv6 prefixes. 403 Authors' Addresses 405 Aijun Wang 406 China Telecom 407 Beiqijia Town, Changping District 408 Beijing 102209 409 China 411 Email: wangaj3@chinatelecom.cn 413 Acee Lindem 414 Cisco Systems 415 301 Midenhall Way 416 Cary, NC 27513 417 USA 419 Email: acee@cisco.com 420 Jie Dong 421 Huawei Technologies 422 Beijing 423 China 425 Email: jie.dong@huawei.com 427 Ketan Talaulikar 428 Cisco Systems 429 S.No. 154/6, Phase I, Hinjawadi 430 Pune 411 057 431 India 433 Email: ketant@cisco.com 435 Peter Psenak 436 Cisco Systems 437 Pribinova Street 10 438 Bratislava, Eurovea Centre, Central 3 81109 439 Slovakia 441 Email: ppsenak@cisco.com