idnits 2.17.1 draft-ietf-lsr-ospf-prefix-originator-03.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 (August 27, 2019) is 1698 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == 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-08 Summary: 1 error (**), 0 flaws (~~), 3 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 28, 2020 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar 10 Cisco Systems 11 August 27, 2019 13 OSPF Extension for Prefix Originator 14 draft-ietf-lsr-ospf-prefix-originator-03 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 28, 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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . 9 71 Appendix B. Special Considerations on Inter-Area Topology 72 Retrieval . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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, [RFC8476] defines a mechanism to advertise multiple 95 types of supported Maximum SID Depths (MSD) at node and/or link 96 granularity. This information will be referred when the head-end 97 router starts to send traffic to destination prefixes. In inter-area 98 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 Software 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 internal routers within 114 backbone area run the BGP-LS protocol, they just learn and report the 115 summary 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 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 NLRI: Network Layer Reachability Information 152 o OSPF: Open Shortest Path First 154 o SID: Segment IDentifier 156 o SDN: Software Definition Network 158 4. Conventions used in this document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119] . 164 5. Scenario Description 166 Figure 1 illustrates the topology scenario when OSPF is running in 167 multi-area. R0-R4 are routers in backbone area, S1-S4,T1-T4 are 168 internal routers in area 1 and area 2 respectively. R1 and R3 are 169 area border routers between area 0 and area 1. R2 and R4 are area 170 border routers between area 0 and area 2. N1 is the network between 171 router S1 and S2 and N2 is the network between router T1 and T2. Ls1 172 is the loopback address of Node S1 and Lt1 is the loopback address of 173 Node T1. 175 +-----------------+ 176 |IP SDN Controller| 177 +--------+--------+ 178 | 179 | BGP-LS 180 | 181 +---------------------+------+--------+-----+--------------+ 182 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 183 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 184 | +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++| 185 | | | | | || | | 186 | | | | | || | | 187 | +-++ +-++ ++-+ +-++ ++++ +-++| 188 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 189 | +--+ +--+ ++-+ +-++ ++-+ +--+| 190 | | | | 191 | | | | 192 | Area 1 | Area 0 | Area 2 | 193 +---------------------+---------------+--------------------+ 195 Figure 1: OSPF Inter-Area Prefix Originator Scenario 197 If S1 wants to send traffic to prefix Lt1 that is connected T1 in 198 another area, it should know the ERLD, and MSD values that are 199 associated with the node T1, and then construct the right label stack 200 at the ingress node for the target traffic. 202 In another scenario, If R0 has some method to learn the originator of 203 network N1 and reports such information to IP SDN controller, then it 204 is possible for the controller to retrieval the topology in non- 205 backbone area. The topology retrieval process and its usage 206 limitation are described in the Appendix A and Appendix B . 208 From the above scenarios, we can conclude it is useful to introduce 209 and define the prefix originator sub TLV within OSPF. 211 6. Prefix Source Router-ID sub-TLV 213 [RFC7684] and [RFC8362] define the TLV extensions for OSPFv2 and 214 OSPFv3 respectively. These documents facilitate addition of new 215 attributes for prefixes. Based on these formats, we can define new 216 sub-TLV to advertise the "Prefix Source Router ID", as that defined 217 in [RFC7794]. 219 The "Prefix Source Router-ID" sub-TLV has the following format: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Prefix Source Router-ID | 227 +---------------------------------------------------------------+ 228 Figure 2: Prefix Source Router-ID sub-TLV Format 230 o Source Router-ID Sub-TLV Type: TBD1[RFC7684] or TBD2 [RFC8362] 232 o Length: 4 234 o Value: Router-ID of OSPFv2/OSPFv3 source router 236 For OSPFv2, this sub-TLV is a sub-TLV of OSPFv2 Extended Prefix TLV, 237 which SHOULD be included in the "OSPFv2 Extended Prefix Opaque LSA" . 239 For OSPFv3, this sub-TLV is a sub-TLV of "Inter-Area-Prefix TLV", 240 which SHOULD be included in the "E-Inter-Area-Prefix-LSA". 242 7. Extended LSA Elements of Procedure 244 When an ABR, for example R2 in Figure 1, receives the Router-LSA 245 announcement in area 2, it should originate the corresponding "OSPFv2 246 Extended Prefix Opaque LSA" for OSPFv2 or "E-Inter-Area-Prefix-LSA" 247 for OSPFv3 that includes the Source Router-ID sub-TLV for the network 248 prefixes, e.g., for prefix Lt1, N2. etc., which identifies the source 249 router that advertised the prefix. 251 When S1 in another area receives such LSA, it then can learn that 252 prefix Lt1 is associated with node T1, check the ERLD, or MSD value 253 according to its necessity, and construct the right label stack at 254 the ingress node S1 for the traffic destined to Lt1. 256 When R0 receives such LSA, it learns the Prefix Source Router-id and 257 includes it in the prefix information advertised to an SDN controller 258 as described in[I-D.ietf-idr-bgp-ls-segment-routing-ext]. The SDN 259 controller can then use such information to build the inter-area 260 topology according to the process described in the Appendix A. The 261 topology retrieval process may not suitable for some environments as 262 stated in Appendix B. 264 8. Security Considerations 266 Security concerns for OSPF are addressed in [RFC5709] 267 Advertisement of the additional information defined in this document 268 introduces no new security concerns 270 9. IANA Considerations 272 This specification defines one Prefix Source Router-ID sub-TLV as 273 described in Section 6. This value should be added to the existing 274 "OSPFv2 Extended Prefix TLV Sub-TLVs" registry and "OSPFv3 Extended- 275 LSA Sub-TLVs registry" respectively. 277 The following new sub-TLV is added to the registry of "OSPFv2 278 Extended Prefix TLV Sub-TLVs". The allocation policy is IETF Review 279 that defined in [RFC7684] 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 282 | Code Point | Description | Status | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 284 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 286 Figure 3: CodePoint in "OSPFv2 Extended Prefix TLV Sub-TLVs" 288 The following new sub-TLV is added to the registry of "OSPFv3 289 Extended-LSA Sub-TLVs". The allocation policy is IETF Review that 290 defined in [RFC8362] 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 293 | Code Point | Description | Status | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 295 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 297 Figure 4: CodePoint in "OSPFv3 Extended-LSA Sub-TLVs" 299 10. Acknowledgement 301 Many thanks to Les Ginsberg for his valuable suggestions on this 302 draft. And also thanks Jeff Tantsura,Rob Shakir, Van De Velde 303 Gunter, Goethals Dirk, Shaofu Peng, John E Drake for their valuable 304 comments on this draft. 306 11. References 308 11.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 316 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 317 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 318 2009, . 320 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 321 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 322 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 323 2015, . 325 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 326 S. Ray, "North-Bound Distribution of Link-State and 327 Traffic Engineering (TE) Information Using BGP", RFC 7752, 328 DOI 10.17487/RFC7752, March 2016, 329 . 331 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 332 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 333 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 334 March 2016, . 336 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 337 F. Baker, "OSPFv3 Link State Advertisement (LSA) 338 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 339 2018, . 341 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 342 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 343 DOI 10.17487/RFC8476, December 2018, 344 . 346 11.2. Informative References 348 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 349 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 350 and M. Chen, "BGP Link-State extensions for Segment 351 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 352 (work in progress), June 2019. 354 [I-D.ietf-ospf-mpls-elc] 355 Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. 356 Litkowski, "Signaling Entropy Label Capability and Entropy 357 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 358 mpls-elc-08 (work in progress), May 2019. 360 Appendix A. Inter-Area Topology Retrieval Process 362 When an IP SDN Controller receives this information, it should 363 compare the prefix Network Layer Reachability Information (NLRI) that 364 included in the BGP-LS packet. When it encounters the same prefix 365 but with different source router ID, it should extract the 366 corresponding area-ID, rebuild the link between these two different 367 source routers in non-backbone area. Belows is one example that 368 based on the Figure 1: 370 Assuming we want to rebuild the connection between router S1 and 371 router S2 that locates in area 1: 373 a. Normally, router S1 will advertise prefix N1 within its router- 374 LSA. 376 b. When this router-LSA reaches the ABR router R1, it will convert 377 it into summary-LSA, add the Prefix Source Router-ID sub-TLV, 378 which is router id of S1 in this example. 380 c. R1 then floods this extension summary-LSA to R0, which is running 381 BGP-LS protocol with IP SDN Controller. The controller then 382 knows the prefixes of N1 is from S1. 384 d. Router S2 will do the similar process, and the controller will 385 also learn that prefixes N1 is also from S2. 387 e. Then it can reconstruct the link between S1 and S2, using the 388 prefix N1. The topology within Area 1 can then be reconstructed 389 accordingly. 391 Iterating the above process continuously, the IP SDN controller can 392 retrieve a detailed topology that spans multiple areas. 394 Appendix B. Special Considerations on Inter-Area Topology Retrieval 396 The above topology retrieval process can be applied in the case where 397 each link between routers is assigned a unique prefix. However, 398 there are some situations where this heuristic cannot be applied. 399 Specifically, the cases where the link is unnumbered or the prefix 400 corresponding to the link is an anycast prefix. 402 The Appendix A heuristic to rebuild the topology can normally be used 403 if all links are numbered. For anycast prefixes, if it corresponds 404 to the loopback interface and has a host prefix length, i.e., 32 for 405 IPv4 prefixes and 128 for IPv6 prefixes, Appendix A can also apply. 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 425 Jie Dong 426 Huawei Technologies 427 Beijing 428 China 430 Email: jie.dong@huawei.com 432 Peter Psenak 433 Cisco Systems 434 Pribinova Street 10 435 Bratislava, Eurovea Centre, Central 3 81109 436 Slovakia 438 Email: ppsenak@cisco.com 440 Ketan Talaulikar 441 Cisco Systems 442 S.No. 154/6, Phase I, Hinjawadi 443 Pune 411 057 444 India 446 Email: ketant@cisco.com