idnits 2.17.1 draft-wang-lsr-ospf-prefix-originator-ext-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 : ---------------------------------------------------------------------------- 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 (January 4, 2019) is 1938 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 269, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-idr-bgpls-inter-as-topology-ext' is defined on line 300, 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: July 8, 2019 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 K. Talaulikar 9 P. Psenak 10 Cisco Systems 11 January 4, 2019 13 OSPF Extension for Prefix Originator 14 draft-wang-lsr-ospf-prefix-originator-ext-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 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 July 8, 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 and Rob Shakir for their 240 valuable comments on this draft. 242 9. References 244 9.1. Normative References 246 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 247 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 248 and M. Chen, "BGP Link-State extensions for Segment 249 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-11 250 (work in progress), October 2018. 252 [I-D.ietf-ospf-mpls-elc] 253 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 254 Litkowski, "Signaling Entropy Label Capability and Entropy 255 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 256 mpls-elc-07 (work in progress), September 2018. 258 [I-D.ietf-ospf-segment-routing-msd] 259 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 260 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 261 ietf-ospf-segment-routing-msd-25 (work in progress), 262 October 2018. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 270 DOI 10.17487/RFC2328, April 1998, 271 . 273 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 274 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 275 . 277 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 278 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 279 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 280 2015, . 282 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 283 S. Ray, "North-Bound Distribution of Link-State and 284 Traffic Engineering (TE) Information Using BGP", RFC 7752, 285 DOI 10.17487/RFC7752, March 2016, 286 . 288 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 289 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 290 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 291 March 2016, . 293 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 294 F. Baker, "OSPFv3 Link State Advertisement (LSA) 295 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 296 2018, . 298 9.2. Informative References 300 [I-D.wang-idr-bgpls-inter-as-topology-ext] 301 Wang, A. and H. Chen, "BGP-LS Extension for Inter-AS 302 Topology Retrieval", draft-wang-idr-bgpls-inter-as- 303 topology-ext-02 (work in progress), August 2018. 305 Appendix A. Inter-Area Topology Retrieval Process 307 When an IP SDN Controller receives this information, it should 308 compare the prefix NLRI that included in the BGP-LS packet. When it 309 encounters the same prefix but with different source router ID, it 310 should extract the corresponding area-ID, rebuild the link between 311 these two different source routers in non-backbone area. Belows is 312 one example that based on the Fig.1: 314 Assuming we want to rebuild the connection between router S1 and 315 router S2 that locates in area 1: 317 a. Normally, router S1 will advertise prefix N1 within its router- 318 LSA. 320 b. When this router-LSA reaches the ABR router R1, it will convert 321 it into summary-LSA, add the Prefix Source Router-ID sub-TLV, 322 which is router id of S1 in this example. 324 c. R1 then floods this extension summary-LSA to R0, which is running 325 BGP-LS protocol with IP SDN Controller. The controller then 326 knows the prefixes of N1 is from S1. 328 d. Router S2 will do the similar process, and the controller will 329 also learn that prefixes N1 is also from S2. 331 e. Then it can reconstruct the link between S1 and S2, using the 332 prefix N1. The topology within Area 1 can then be reconstructed 333 accordingly. 335 Iterating the above process continuously, an IP SDN controller can 336 retrieve a detailed topology that spans multiple areas. 338 Appendix B. Special Considerations on Inter-Area Topology Retrieval 340 The above topology retrieval process can be applied in the case where 341 each link between routers is assigned a unique prefix. However, 342 there are some situations where this heuristic cannot be applied. 343 Specifically, the cases where the link is unnumbered or the prefix 344 corresponding to the link is an anycast prefix and is not unique. 346 The Appendix A heuristic to rebuild the topology can normally be used 347 if all links are numbered and the anycast prefixes correspond to 348 loopbacks and have a host prefix length, i.e., 32 for IPv4 prefixes 349 and 128 for IPv6 prefixes. 351 Authors' Addresses 353 Aijun Wang 354 China Telecom 355 Beiqijia Town, Changping District 356 Beijing 102209 357 China 359 Email: wangaj.bri@chinatelecom.cn 361 Acee Lindem 362 Cisco Systems 363 301 Midenhall Way 364 Cary, NC 27513 365 USA 367 Email: acee@cisco.com 369 Jie Dong 370 Huawei Technologies 371 Beijing 372 China 374 Email: jie.dong@huawei.com 375 Ketan Talaulikar 376 Cisco Systems 377 S.No. 154/6, Phase I, Hinjawadi 378 Pune 411 057 379 India 381 Email: ketant@cisco.com 383 Peter Psenak 384 Cisco Systems 385 Pribinova Street 10 386 Bratislava, Eurovea Centre, Central 3 81109 387 Slovakia 389 Email: ppsenak@cisco.com