idnits 2.17.1 draft-ietf-lsr-ospf-prefix-originator-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 1, 2019) is 1855 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) == Unused Reference: 'RFC2328' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-idr-bgpls-inter-as-topology-ext' is defined on line 301, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-11 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-mpls-elc-07 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 7 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: September 2, 2019 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 K. Talaulikar 9 P. Psenak 10 Cisco Systems 11 March 1, 2019 13 OSPF Extension for Prefix Originator 14 draft-ietf-lsr-ospf-prefix-originator-00 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 several multi- 21 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 September 2, 2019. 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 . . . . . . . . . . . . . . . . . . . . . 5 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 +---------------------------------------------------------------+ 197 o Source Router-ID Sub-TLV Type: TBD1[RFC7684] or TBD2 [RFC8362] 199 o Length: 4 201 o Value: Router-ID of OSPFv2/OSPFv3 source router 203 This sub-TLV can be included in the "OSPFv2 Extended Prefix Opaque 204 LSA" [RFC7684] or the "E-Inter-Area-Prefix-LSA" [RFC8362]. 206 5. Extended LSA Elements of Procedure 208 When an ABR, for example R2 in Fig.1, receives the Router-LSA 209 announcement in area 2, it should originate the corresponding "OSPFv2 210 Extended Prefix Opaque LSA" for OSPFv2 or "E-Inter-Area-Prefix-LSA" 211 for OSPFv3 that includes the Source Router-ID sub-TLV for the network 212 prefixes, e.g., for prefix Lt1, N2. etc., which identifies the source 213 router that advertised the prefix. 215 When S1 in another area receives such LSA, it then can learn that 216 prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD 217 value according to its necessity, and construct the right label stack 218 at the ingress node S1 for the traffic destined to Lt1. 220 When R0 receives such LSA, it learns the Prefix Source Router-id and 221 includes it in the prefix information advertised to an SDN controller 222 as described in[I-D.ietf-idr-bgp-ls-segment-routing-ext]. The SDN 223 controller can then use such information to build the inter-area 224 topology according to the process described in the Appendix A. The 225 topology retrieval process may not suitable for some environments as 226 stated in Appendix B. 228 6. Security Considerations 230 TBD. 232 7. IANA Considerations 234 TBD. 236 8. Acknowledgement 238 Many thanks to Les Ginsberg for his valuable suggestions on this 239 draft. And also thanks Jeff Tantsura,Rob Shakir, Van De Velde 240 Gunter, Goethals Dirk, Shaofu Peng, John E Drake for their valuable 241 comments on this draft. 243 9. References 245 9.1. Normative References 247 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 248 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 249 and M. Chen, "BGP Link-State extensions for Segment 250 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-11 251 (work in progress), October 2018. 253 [I-D.ietf-ospf-mpls-elc] 254 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 255 Litkowski, "Signaling Entropy Label Capability and Entropy 256 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 257 mpls-elc-07 (work in progress), September 2018. 259 [I-D.ietf-ospf-segment-routing-msd] 260 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 261 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 262 ietf-ospf-segment-routing-msd-25 (work in progress), 263 October 2018. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 271 DOI 10.17487/RFC2328, April 1998, 272 . 274 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 275 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 276 . 278 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 279 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 280 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 281 2015, . 283 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 284 S. Ray, "North-Bound Distribution of Link-State and 285 Traffic Engineering (TE) Information Using BGP", RFC 7752, 286 DOI 10.17487/RFC7752, March 2016, 287 . 289 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 290 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 291 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 292 March 2016, . 294 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 295 F. Baker, "OSPFv3 Link State Advertisement (LSA) 296 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 297 2018, . 299 9.2. Informative References 301 [I-D.wang-idr-bgpls-inter-as-topology-ext] 302 Wang, A. and H. Chen, "BGP-LS Extension for Inter-AS 303 Topology Retrieval", draft-wang-idr-bgpls-inter-as- 304 topology-ext-02 (work in progress), August 2018. 306 Appendix A. Inter-Area Topology Retrieval Process 308 When an IP SDN Controller receives this information, it should 309 compare the prefix NLRI that included in the BGP-LS packet. When it 310 encounters the same prefix but with different source router ID, it 311 should extract the corresponding area-ID, rebuild the link between 312 these two different source routers in non-backbone area. Belows is 313 one example that based on the Fig.1: 315 Assuming we want to rebuild the connection between router S1 and 316 router S2 that locates in area 1: 318 a. Normally, router S1 will advertise prefix N1 within its router- 319 LSA. 321 b. When this router-LSA reaches the ABR router R1, it will convert 322 it into summary-LSA, add the Prefix Source Router-ID sub-TLV, 323 which is router id of S1 in this example. 325 c. R1 then floods this extension summary-LSA to R0, which is running 326 BGP-LS protocol with IP SDN Controller. The controller then 327 knows the prefixes of N1 is from S1. 329 d. Router S2 will do the similar process, and the controller will 330 also learn that prefixes N1 is also from S2. 332 e. Then it can reconstruct the link between S1 and S2, using the 333 prefix N1. The topology within Area 1 can then be reconstructed 334 accordingly. 336 Iterating the above process continuously, an IP SDN controller can 337 retrieve a detailed topology that spans multiple areas. 339 Appendix B. Special Considerations on Inter-Area Topology Retrieval 341 The above topology retrieval process can be applied in the case where 342 each link between routers is assigned a unique prefix. However, 343 there are some situations where this heuristic cannot be applied. 344 Specifically, the cases where the link is unnumbered or the prefix 345 corresponding to the link is an anycast prefix and is not unique. 347 The Appendix A heuristic to rebuild the topology can normally be used 348 if all links are numbered and the anycast prefixes correspond to 349 loopbacks and have a host prefix length, i.e., 32 for IPv4 prefixes 350 and 128 for IPv6 prefixes. 352 Authors' Addresses 354 Aijun Wang 355 China Telecom 356 Beiqijia Town, Changping District 357 Beijing 102209 358 China 360 Email: wangaj.bri@chinatelecom.cn 362 Acee Lindem 363 Cisco Systems 364 301 Midenhall Way 365 Cary, NC 27513 366 USA 368 Email: acee@cisco.com 370 Jie Dong 371 Huawei Technologies 372 Beijing 373 China 375 Email: jie.dong@huawei.com 376 Ketan Talaulikar 377 Cisco Systems 378 S.No. 154/6, Phase I, Hinjawadi 379 Pune 411 057 380 India 382 Email: ketant@cisco.com 384 Peter Psenak 385 Cisco Systems 386 Pribinova Street 10 387 Bratislava, Eurovea Centre, Central 3 81109 388 Slovakia 390 Email: ppsenak@cisco.com