idnits 2.17.1 draft-acee-lsr-ospf-transport-instance-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 date (November 2, 2020) is 1264 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Workgroup A. Lindem 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Y. Qu 5 Expires: May 6, 2021 Futurewei 6 A. Roy 7 Arrcus, Inc. 8 S. Mirtorabi 9 Cisco Systems 10 November 2, 2020 12 OSPF Transport Instance Extensions 13 draft-acee-lsr-ospf-transport-instance-01 15 Abstract 17 OSPFv2 and OSPFv3 include a reliable flooding mechanism to 18 disseminate routing topology and Traffic Engineering (TE) information 19 within a routing domain. Given the effectiveness of these 20 mechanisms, it is convenient to envision using the same mechanism for 21 dissemination of other types of information within the domain. 22 However, burdening OSPF with this additional information will impact 23 intra-domain routing convergence and possibly jeopardize the 24 stability of the OSPF routing domain. This document presents 25 mechanism to relegate this ancillary information to a separate OSPF 26 instance and minimize the impact. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 6, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Possible Use Cases . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. MEC Service Discovery . . . . . . . . . . . . . . . . . . 3 66 3.2. Application Data Dissemination . . . . . . . . . . . . . 4 67 3.3. Intra-Area Topology for BGP-LS Distribution . . . . . . . 4 68 4. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4 69 4.1. OSPFv2 Transport Instance Packet Differentiation . . . . 5 70 4.2. OSPFv3 Transport Instance Packet Differentiation . . . . 5 71 4.3. Instance Relationship to Normal OSPF Instances . . . . . 5 72 4.4. Network Prioritization . . . . . . . . . . . . . . . . . 5 73 4.5. OSPF Transport Instance Omission of Routing Calculation . 6 74 4.6. Non-routing Instance Separation . . . . . . . . . . . . . 6 75 4.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 7 76 4.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . 7 77 4.8. Multiple Topologies . . . . . . . . . . . . . . . . . . . 8 78 5. OSPF Transport Instance Information Encoding . . . . . . . . 8 79 5.1. OSPFv2 Transport Instance Information Encoding . . . . . 9 80 5.2. OSPFv3 Transport Instance Information Encoding . . . . . 9 81 6. Manageability Considerations . . . . . . . . . . . . . . . . 9 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 10.2. Informative References . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 OSPFv2 [RFC2328] and OSPFv3 [RFC5340] include a reliable flooding 93 mechanism to disseminate routing topology and Traffic Engineering 94 (TE) information within a routing domain. Given the effectiveness of 95 these mechanisms, it is convenient to envision using the same 96 mechanism for dissemination of other types of information within the 97 domain. However, burdening OSPF with this additional information 98 will impact intra-domain routing convergence and possibly jeopardize 99 the stability of the OSPF routing domain. This document presents 100 mechanism to relegate this ancillary information to a separate OSPF 101 instance and minimize the impact. 103 This OSPF protocol extension provides functionality similar to 104 "Advertising Generic Information in IS-IS" [RFC6823]. Additionally, 105 OSPF is extended to support sparse non-routing overlay topologies 106 Section 4.7. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Possible Use Cases 118 3.1. MEC Service Discovery 120 Multi-Access Edge Computing (MEC) plays an important role in 5G 121 architecture. MEC optimizes the performance for ultra-low latency 122 and high bandwidth services by providing networking and computing at 123 the edge of the network [ETSI-WP28-MEC]. To achieve this goal, it's 124 important to expose the network capabilities and services of a MEC 125 device to 5G User Equipment UE, i.e. UEs. 127 The followings are an incomplete list of the kind of information that 128 OSPF transport instance can help to disseminate: 130 o A network service is realized using one or more physical or 131 virtualized hosts in MEC, and the locations of these service 132 points might change. The auto-discovery of these service 133 locations can be achieved using an OSPF transport instance. 135 o UEs might be mobile, and MEC should support service continuity and 136 application mobility. This may require service state transferring 137 and synchronization. OSPF transport instance can be used to 138 synchronize these states. 140 o Network resources are limited, such as computing power, storage. 141 The availability of such resources is dynamic, and OSPF transport 142 instance can be used to populate such information, so applications 143 can pick the right location of such resources, hence improve user 144 experience and resource utilization. 146 3.2. Application Data Dissemination 148 Typically a network consists of routers from different vendors with 149 different capabilities, and some applications may want to know 150 whether a router supports certain functionality or where to find a 151 router supports a functionality, so it will be ideal if such kind of 152 information is known to all routers or a group of routers in the 153 network. For example, an ingress router needs to find an egress 154 router that supports In-situ Flow Information Telemetry (IFIT) 155 [I-D.wang-lsr-igp-extensions-ifit] and obtain IFIT parameters. 157 OSPF transport instance can be used to populate such router 158 capabilities/functionalities without impacting the performance or 159 convergence of the base OSPF protocol. 161 3.3. Intra-Area Topology for BGP-LS Distribution 163 In some cases, it is desirable to limit the number of BGP-LS 164 [RFC5572] sessions with a controller to the a one or two routers in 165 an OSPF domain. However, many times those router(s) do not have full 166 visibility to the complete topology of all the areas. To solve this 167 problem without extended the BGP-LS domain, the OSPF LSAs for non- 168 local area could be flooded over the OSPF transport instance topology 169 using remote neighbors Section 4.7.1. 171 4. OSPF Transport Instance 173 In order to isolate the effects of flooding and processing of non- 174 routing information, it will be relegated to a separate protocol 175 instance. This instance should be given lower priority when 176 contending for router resources including processing, backplane 177 bandwidth, and line card bandwidth. How that is realized is an 178 implementation issue and is outside the scope of this document. 180 Throughout the document, non-routing refers to routing information 181 that is not used for IP or IPv6 routing calculations. The OSPF 182 transport instance is ideally suited for dissemination of routing 183 information for other protocols and layers. 185 4.1. OSPFv2 Transport Instance Packet Differentiation 187 OSPFv2 currently does not offer a mechanism to differentiate 188 Transport instance packets from normal instance packets sent and 189 received on the same interface. However, the [RFC6549] provides the 190 necessary packet encoding to support multiple OSPF protocol 191 instances. 193 4.2. OSPFv3 Transport Instance Packet Differentiation 195 Fortunately, OSPFv3 already supports separate instances within the 196 packet encodings. The existing OSPFv3 packet header instance ID 197 field will be used to differentiate packets received on the same link 198 (refer to section 2.4 in [RFC5340]). 200 4.3. Instance Relationship to Normal OSPF Instances 202 In OSPF transport instance, we must guarantee that any information 203 we've received is treated as valid if and only if the router sending 204 it is reachable. We'll refer to this as the "condition of 205 reachability" in this document. 207 The OSPF transport instance is not dependent on any other OSPF 208 instance. It does, however, have much of the same as topology 209 information must be advertised to satisfy the "condition of 210 reachability". 212 Further optimizations and coupling between an OSPF transport instance 213 and a normal OSPF instance are beyond the scope of this document. 214 This is an area for future study. 216 4.4. Network Prioritization 218 While OSPFv2 (section 4.3 in [RFC2328]) are normally sent with IP 219 precedence Internetwork Control, any packets sent by an OSPF 220 transport instance will be sent with IP precedence Flash (B'011'). 221 This is only appropriate given that this is a pretty flashy 222 mechanism. 224 Similarly, OSPFv3 transport instance packets will be sent with the 225 traffic class mapped to flash (B'011') as specified in ([RFC5340]). 227 By setting the IP/IPv6 precedence differently for OSPF transport 228 instance packets, normal OSPF routing instances can be given priority 229 during both packet transmission and reception. In fact, some router 230 implementations map the IP precedence directly to their internal 231 packet priority. However, internal router implementation decisions 232 are beyond the scope of this document. 234 4.5. OSPF Transport Instance Omission of Routing Calculation 236 Since the whole point of the transport instance is to separate the 237 routing and non-routing processing and fate sharing, a transport 238 instance SHOULD NOT install any IP or IPv6 routes. OSPF routers 239 SHOULD NOT advertise any transport instance LSAs containing IP or 240 IPv6 prefixes and OSPF routers receiving LSAs advertising IP or IPv6 241 prefixes SHOULD ignore them. This implies that an OSPF transport 242 instance Link State Database should not include any of the LSAs as 243 shown in Table 1. 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | OSPFv2 | summary-LSAs (type 3) | 247 | | AS-external-LSAs (type 5) | 248 | | NSSA-LSAs (type 7) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | OSPFv3 | inter-area-prefix-LSAs (type 2003) | 251 | | AS-external-LSAs (type 0x4005) | 252 | | NSSA-LSAs (type 0x2007) | 253 | | intra-area-prefix-LSAs (type 0x2009) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | OSPFv3 Extended LSA | E-inter-area-prefix-LSAs (type 0xA023) | 256 | | E-as-external-LSAs (type 0xC025) | 257 | | E-Type-7-NSSA (type 0xA027) | 258 | | E-intra-area-prefix-LSA (type 0xA029) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 LSAs not included in OSPF transport instance 263 If these LSAs are erroneously advertised, they will be flooded as per 264 standard OSPF but MUST be ignored by OSPF routers supporting this 265 specification. 267 4.6. Non-routing Instance Separation 269 It has been suggested that an implementation could obtain the same 270 level of separation between IP routing information and non-routing 271 information in a single instance with slight modifications to the 272 OSPF protocol. The authors refute this contention for the following 273 reasons: 275 o Adding internal and external mechanisms to prioritize routing 276 information over non-routing information are much more complex 277 than simply relegating the non-routing information to a separate 278 instance as proposed in this specification. 280 o The instance boundary offers much better separation for allocation 281 of finite resources such as buffers, memory, processor cores, 282 sockets, and bandwidth. 284 o The instance boundary decreases the level of fate sharing for 285 failures. Each instance may be implemented as a separate process 286 or task. 288 o With non-routing information, many times not every router in the 289 OSPF routing domain requires knowledge of every piece of non- 290 routing information. In these cases, groups of routers which need 291 to share information can be segregated into sparse topologies 292 greatly reducing the amount of non-routing information any single 293 router needs to maintain. 295 4.7. Non-Routing Sparse Topologies 297 With non-routing information, many times not every router in the OSPF 298 routing domain requires knowledge of every piece of non-routing 299 information. In these cases, groups of routers which need to share 300 information can be segregated into sparse topologies. This will 301 greatly reduce the amount of information any single router needs to 302 maintain with the core routers possibly not requiring any non-routing 303 information at all. 305 With normal OSPF, every router in an OSPF area must have every piece 306 of topological information and every intra-area IP or IPv6 prefix. 307 With non-routing information, only the routers needing to share a set 308 of information need be part of the corresponding sparse topology. 309 For directly attached routers, one only needs to configure the 310 desired topologies on the interfaces with routers requiring the non- 311 routing information. When the routers making up the sparse topology 312 are not part of a uniconnected graph, two alternatives exist. The 313 first alternative is configure tunnels to form a fully connected 314 graph including only those routers in the sparse topology. The 315 second alternative is use remote neighbors as described in 316 Section 4.7.1. 318 4.7.1. Remote OSPF Neighbor 320 With sparse topologies, OSPF routers sharing non-routing information 321 may not be directly connected. OSPF adjacencies with remote 322 neighbors are formed exactly as they are with regular OSPF neighbors. 323 The main difference is that a remote OSPF neighbor's address is 324 configured and IP routing is used to deliver OSPF protocol packets to 325 the remote neighbor. Other salient feature of the remote neighbor 326 include: 328 o All OSPF packets have the remote neighbor's configured IP address 329 as the IP destination address. 331 o The adjacency is represented in the router Router-LSA as a router 332 (type-1) link with the link data set to the remote neighbor's 333 configured IP address. 335 o Similar to NBMA networks, a poll-interval is configured to 336 determine if the remote neighbor is reachable. This value is 337 normally much higher than the hello interval with 40 seconds 338 RECOMMENDED as the default. 340 4.8. Multiple Topologies 342 For some applications, the information need to be flooded only to a 343 topology which is a subset of routers of the transport instance. 344 This allows the application specific information only to be flooded 345 to routers that support the application. A transport instance may 346 support multiple topologies as defined in [RFC4915]. But as pointed 347 out in Section 4.5, a transport instance or topology SHOULD NOT 348 install any IP or IPv6 routes. 350 Each topology associated with the transport instance MUST be fully 351 connected in order for the LSAs to be successfully flooded to all 352 routers in the topology. 354 5. OSPF Transport Instance Information Encoding 356 The format of the TLVs within the body of an LSA containing non- 357 routing information is the same as the format used by the Traffic 358 Engineering Extensions to OSPF [RFC3630]. The LSA payload consists 359 of one or more nested Type/Length/Value (TLV) triplets. The format 360 of each TLV is: 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Length | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Value... | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 TLV Format 372 However, each unique application using the mechanisms defined in this 373 document will have it's own unique ID. Whether to encode this ID as 374 the top-level TLV or make it part of the OSPF LSA ID is open for 375 debate. 377 The specific TLVs and sub-TLVs relating to a given application and 378 the corresponding IANA considerations MUST for standard applications 379 MUST be specified in the document corresponding to that application. 381 5.1. OSPFv2 Transport Instance Information Encoding 383 Application specific information will be flooded in opaque LSAs as 384 specified in [RFC5250]. 386 5.2. OSPFv3 Transport Instance Information Encoding 388 Application specific information will be flooded in separate LSAs 389 with separate function codes. Refer to section A.4.2.1 of [RFC5340]. 390 for information on the LS Type encoding in OSPFv3, and section 2 of 391 [RFC8362] for OSPFv3 extended LSA types. 393 6. Manageability Considerations 395 7. Security Considerations 397 The security considerations for the Transport Instance will not be 398 different for those for OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 400 8. IANA Considerations 402 No IANA actions are required. 404 9. Acknowledgement 406 10. References 408 10.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 416 DOI 10.17487/RFC2328, April 1998, 417 . 419 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 420 (TE) Extensions to OSPF Version 2", RFC 3630, 421 DOI 10.17487/RFC3630, September 2003, 422 . 424 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 425 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 426 RFC 4915, DOI 10.17487/RFC4915, June 2007, 427 . 429 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 430 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 431 July 2008, . 433 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 434 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 435 . 437 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 438 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 439 March 2012, . 441 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 442 Generic Information in IS-IS", RFC 6823, 443 DOI 10.17487/RFC6823, December 2012, 444 . 446 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 447 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 448 May 2017, . 450 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 451 F. Baker, "OSPFv3 Link State Advertisement (LSA) 452 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 453 2018, . 455 10.2. Informative References 457 [ETSI-WP28-MEC] 458 Sami Kekki, etc., "MEC in 5G Networks", 2018, 459 . 462 [I-D.wang-lsr-igp-extensions-ifit] 463 Wang, Y., Zhou, T., Qin, F., Chen, H., and R. Pang, "IGP 464 Extensions for In-situ Flow Information Telemetry (IFIT) 465 Capability Advertisement", draft-wang-lsr-igp-extensions- 466 ifit-01 (work in progress), July 2020. 468 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the 469 Tunnel Setup Protocol (TSP)", RFC 5572, 470 DOI 10.17487/RFC5572, February 2010, 471 . 473 Authors' Addresses 475 Acee Lindem 476 Cisco Systems 477 301 Midenhall Way 478 CARY, NC 27513 479 UNITED STATES 481 Email: acee@cisco.com 483 Yingzhen Qu 484 Futurewei 485 2330 Central Expressway 486 Santa Clara, CA 95050 487 USA 489 Email: yingzhen.qu@futurewei.com 491 Abhay Roy 492 Arrcus, Inc. 494 Email: abhay@arrcus.com 496 Sina Mirtorabi 497 Cisco Systems 498 170 West Tasman Drive 499 San Jose, CA 95134 500 USA 502 Email: smirtora@cisco.com