idnits 2.17.1 draft-ietf-lsr-ospf-prefix-originator-01.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 8 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 (July 1, 2019) is 1733 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 (-15) exists of draft-ietf-ospf-mpls-elc-08 ** 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-15 Summary: 2 errors (**), 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: January 2, 2020 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 K. Talaulikar 9 P. Psenak 10 Cisco Systems 11 July 1, 2019 13 OSPF Extension for Prefix Originator 14 draft-ietf-lsr-ospf-prefix-originator-01 16 Abstract 18 This document describes OSPFv2 and OSPFv3 encodings to advertise the 19 router-id of the originator of inter-area prefixes for OSPFv2 and 20 OSPFv3 LSAs, which are needed in several use cases in multi-area OSPF 21 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 January 2, 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. Scenario Description . . . . . . . . . . . . . . . . . . . . 3 60 4. Prefix Source Router-ID sub-TLV . . . . . . . . . . . . . . . 4 61 5. Extended LSA Elements of Procedure . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 9.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Appendix A. Inter-Area Topology Retrieval Process . . . . . . . 7 69 Appendix B. Special Considerations on Inter-Area Topology 70 Retrieval . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 [I-D.ietf-ospf-mpls-elc] defines mechanisms to signal Entropy Label 76 Capability (ELC) and Entropy Readable Label Depth (ERLD) for ingress 77 LSR to discover each LSR's capability of reading the maximum label 78 stack depth and performing EL-based load-balancing in MPLS networks. 79 The ingress LSR can use this information to push the appropriate 80 label stack for specific FEC trafffic, especially in segment routing 81 environments and other stacked LSPs scenarios. 83 However, in inter-area scenarios, the Area Border Router (ABR) does 84 not advertise the originating OSPF router-id for inter-area prefixes. 85 An OSPF router in one area doesn't know where the prefixes really 86 came from and can't determine the router that originated inter-area 87 prefixes and then can't judge the ELC and ERLD capabilities of the 88 destination. It is necessary to transfer the originator information 89 of these inter-area prefixes to ensure the ingress LSR constructs the 90 right Label stack. 92 More generally, draft [I-D.ietf-ospf-segment-routing-msd] defines a 93 mechanism to advertise multiple types of supported Maximum SID Depths 94 (MSD) at node and/or link granularity. This information will be 95 referred when the head-end router starts to send traffic to 96 destination prefixes. In inter-area scenario, it is also necessary 97 for the sender to learn the capabilities of the receivers associated 98 with the inter-area prefixes. 100 There is also another scenario where knowing the originator of inter- 101 area prefixes is useful. For example, BGP-LS [RFC7752] describes 102 mechanisms using the BGP protocol to advertise Link-State 103 information. This can enable an SDN controller to collect the 104 underlay network topology automatically. 106 But if the underlay network is divided into multiple areas and 107 running the OSPF protocol, it is not easy for the SDN controller to 108 rebuild the multi-area topology, because normally an Area Border 109 Router (ABR) that connects multiple areas will hide the detailed 110 topology information for these non-backbone areas, and the router in 111 backbone area that runs the BGP-LS protocol can only learn and report 112 the summary network information from the non-backbone areas. If the 113 SDN controller can learn the originator of the inter-area prefixes, 114 it is possible for them to rebuild the inter-area topology 115 automatically. 117 [RFC7794] introduces the IS-IS "IPv4/IPv6 Source Router IDs" TLV to 118 advertise the source of the prefixes redistributed from a different 119 IS-IS level. This TLV can be used in the above scenarios. Such 120 solution can also be applied in networks that run the OSPF protocol, 121 but the related Link state Advertisements (LSAs) must be extended. 123 This draft provides such solution for the OSPFv2 and OSPFv3 124 protocols. 126 2. Conventions used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119] . 132 3. Scenario Description 134 Fig.1 illustrates the topology scenario when OSPF is running in 135 multi-area. R0-R4 are routers in backbone area, S1-S4,T1-T4 are 136 internal routers in area 1 and area 2 respectively. R1 and R3 are 137 area border routers between area 0 and area 1. R2 and R4 are area 138 border routers between area 0 and area 2. N1 is the network between 139 router S1 and S2 and N2 is the network between router T1 and T2. Ls1 140 is the loopback address of Node S1 and Lt1 is the loopback address of 141 Node T1. 143 +-----------------+ 144 |IP SDN Controller| 145 +--------+--------+ 146 | 147 | BGP-LS 148 | 149 +---------------------+------+--------+-----+--------------+ 150 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 151 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 152 | +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++| 153 | | | | | || | | 154 | | | | | || | | 155 | +-++ +-++ ++-+ +-++ ++++ +-++| 156 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 157 | +--+ +--+ ++-+ +-++ ++-+ +--+| 158 | | | | 159 | | | | 160 | Area 1 | Area 0 | Area 2 | 161 +---------------------+---------------+--------------------+ 163 Fig.1 OSPF Inter-Area Prefix Originator Scenario 165 If S1 wants to send traffic to prefix Lt1 that is connected T1 in 166 another area, it should know the ELC, ERLD, and MSD values that are 167 associated with the node T1, and then construct the right label stack 168 at the ingress node for the target traffic. 170 In another scenario, If R0 has some method to learn the originator of 171 network N1 and reports such information to IP SDN controller, then it 172 is possible for the controller to retrieval the topology in non- 173 backbone area. The topology retrieval process and its usage 174 limitation are described in the Appendix A and Appendix B. 176 From the above scenarios, we can conclude it is useful to introduce 177 and define the prefix originator sub TLV within OSPF. 179 4. Prefix Source Router-ID sub-TLV 181 [RFC7684] and [RFC8362] define the TLV extensions for OSPFv2 and 182 OSPFv3 respectively. These documents facilitate addition of new 183 attributes for prefixes and links. Based on these formats, we can 184 define new sub-TLV to advertise the "Prefix Source Router ID", as 185 that defined in [RFC7794]. 187 The "Prefix Source Router-ID" sub-TLV has the following format: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Prefix Source Router-ID | 195 +---------------------------------------------------------------+ 196 Fig. 2 Prefix Source Router-ID sub-TLV Format 198 o Source Router-ID Sub-TLV Type: TBD1[RFC7684] or TBD2 [RFC8362] 200 o Length: 4 202 o Value: Router-ID of OSPFv2/OSPFv3 source router 204 This sub-TLV can be included in the "OSPFv2 Extended Prefix Opaque 205 LSA" [RFC7684] or the "E-Inter-Area-Prefix-LSA" [RFC8362]. 207 5. Extended LSA Elements of Procedure 209 When an ABR, for example R2 in Fig.1, receives the Router-LSA 210 announcement in area 2, it should originate the corresponding "OSPFv2 211 Extended Prefix Opaque LSA" for OSPFv2 or "E-Inter-Area-Prefix-LSA" 212 for OSPFv3 that includes the Source Router-ID sub-TLV for the network 213 prefixes, e.g., for prefix Lt1, N2. etc., which identifies the source 214 router that advertised the prefix. 216 When S1 in another area receives such LSA, it then can learn that 217 prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD 218 value according to its necessity, and construct the right label stack 219 at the ingress node S1 for the traffic destined to Lt1. 221 When R0 receives such LSA, it learns the Prefix Source Router-id and 222 includes it in the prefix information advertised to an SDN controller 223 as described in[I-D.ietf-idr-bgp-ls-segment-routing-ext]. The SDN 224 controller can then use such information to build the inter-area 225 topology according to the process described in the Appendix A. The 226 topology retrieval process may not suitable for some environments as 227 stated in Appendix B. 229 6. Security Considerations 231 Security concerns for OSPF are addressed in [RFC5709] 233 Advertisement of the additional information defined in this document 234 introduces no new security concerns 236 7. IANA Considerations 238 This document adds the following new sub-TLV to the registry of 239 "OSPFv2 Extended Prefix TLV Sub-TLVs". The allocation policy is IETF 240 Review that defined in [RFC7684] 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 243 | Code Point | Description | Status | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 245 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 247 Fig.3: Prefix Source sub-TLV CodePoint from OSPFv2 Extended Prefix TLV Sub-TLVs 249 This document adds the following sub-TLV to the registry of "OSPFv3 250 Extended-LSA Sub-TLVs". The allocation is IETF Review that defined 251 in [RFC8362] 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 254 | Code Point | Description | Status | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 256 | TBD | Prefix Source Sub-TLV | Allocation from IANA | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 258 Fig.4: Prefix Source sub-TLV CodePoint from OSPFv3 Extended-LSA Sub-TLVs 260 8. Acknowledgement 262 Many thanks to Les Ginsberg for his valuable suggestions on this 263 draft. And also thanks Jeff Tantsura,Rob Shakir, Van De Velde 264 Gunter, Goethals Dirk, Shaofu Peng, John E Drake for their valuable 265 comments on this draft. 267 9. References 269 9.1. Normative References 271 [I-D.ietf-ospf-mpls-elc] 272 Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. 273 Litkowski, "Signaling Entropy Label Capability and Entropy 274 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 275 mpls-elc-08 (work in progress), May 2019. 277 [I-D.ietf-ospf-segment-routing-msd] 278 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 279 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 280 ietf-ospf-segment-routing-msd-25 (work in progress), 281 October 2018. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 289 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 290 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 291 2009, . 293 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 294 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 295 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 296 2015, . 298 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 299 S. Ray, "North-Bound Distribution of Link-State and 300 Traffic Engineering (TE) Information Using BGP", RFC 7752, 301 DOI 10.17487/RFC7752, March 2016, 302 . 304 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 305 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 306 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 307 March 2016, . 309 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 310 F. Baker, "OSPFv3 Link State Advertisement (LSA) 311 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 312 2018, . 314 9.2. Informative References 316 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 317 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 318 and M. Chen, "BGP Link-State extensions for Segment 319 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-15 320 (work in progress), May 2019. 322 Appendix A. Inter-Area Topology Retrieval Process 324 When an IP SDN Controller receives this information, it should 325 compare the prefix NLRI that included in the BGP-LS packet. When it 326 encounters the same prefix but with different source router ID, it 327 should extract the corresponding area-ID, rebuild the link between 328 these two different source routers in non-backbone area. Belows is 329 one example that based on the Fig.1: 331 Assuming we want to rebuild the connection between router S1 and 332 router S2 that locates in area 1: 334 a. Normally, router S1 will advertise prefix N1 within its router- 335 LSA. 337 b. When this router-LSA reaches the ABR router R1, it will convert 338 it into summary-LSA, add the Prefix Source Router-ID sub-TLV, 339 which is router id of S1 in this example. 341 c. R1 then floods this extension summary-LSA to R0, which is running 342 BGP-LS protocol with IP SDN Controller. The controller then 343 knows the prefixes of N1 is from S1. 345 d. Router S2 will do the similar process, and the controller will 346 also learn that prefixes N1 is also from S2. 348 e. Then it can reconstruct the link between S1 and S2, using the 349 prefix N1. The topology within Area 1 can then be reconstructed 350 accordingly. 352 Iterating the above process continuously, an IP SDN controller can 353 retrieve a detailed topology that spans multiple areas. 355 Appendix B. Special Considerations on Inter-Area Topology Retrieval 357 The above topology retrieval process can be applied in the case where 358 each link between routers is assigned a unique prefix. However, 359 there are some situations where this heuristic cannot be applied. 360 Specifically, the cases where the link is unnumbered or the prefix 361 corresponding to the link is an anycast prefix and is not unique. 363 The Appendix A heuristic to rebuild the topology can normally be used 364 if all links are numbered and the anycast prefixes correspond to 365 loopbacks and have a host prefix length, i.e., 32 for IPv4 prefixes 366 and 128 for IPv6 prefixes. 368 Authors' Addresses 370 Aijun Wang 371 China Telecom 372 Beiqijia Town, Changping District 373 Beijing 102209 374 China 376 Email: wangaj.bri@chinatelecom.cn 377 Acee Lindem 378 Cisco Systems 379 301 Midenhall Way 380 Cary, NC 27513 381 USA 383 Email: acee@cisco.com 385 Jie Dong 386 Huawei Technologies 387 Beijing 388 China 390 Email: jie.dong@huawei.com 392 Ketan Talaulikar 393 Cisco Systems 394 S.No. 154/6, Phase I, Hinjawadi 395 Pune 411 057 396 India 398 Email: ketant@cisco.com 400 Peter Psenak 401 Cisco Systems 402 Pribinova Street 10 403 Bratislava, Eurovea Centre, Central 3 81109 404 Slovakia 406 Email: ppsenak@cisco.com