idnits 2.17.1 draft-ietf-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 18, 2021) is 888 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 22, 2022 Futurewei 6 A. Roy 7 Arrcus, Inc. 8 S. Mirtorabi 9 Cisco Systems 10 November 18, 2021 12 OSPF Transport Instance Extensions 13 draft-ietf-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 22, 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 (TII) Encoding . . . . . 8 79 5.1. OSPFv2 Transport Instance Information Encoding . . . . . 8 80 5.2. OSPFv3 Transport Instance Information Encoding . . . . . 9 81 5.3. Transport Instance Information (TII) TLV Encoding . . . . 10 82 5.3.1. Top-Level TII Application TLV . . . . . . . . . . . . 10 83 6. Manageability Considerations . . . . . . . . . . . . . . . . 11 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 8.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 11 87 8.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 12 88 8.3. OSPF Transport Instance Information Top-Level TLV 89 Registry . . . . . . . . . . . . . . . . . . . . . . . . 12 90 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 10.2. Informative References . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 OSPFv2 [RFC2328] and OSPFv3 [RFC5340] include a reliable flooding 99 mechanism to disseminate routing topology and Traffic Engineering 100 (TE) information within a routing domain. Given the effectiveness of 101 these mechanisms, it is convenient to envision using the same 102 mechanism for dissemination of other types of information within the 103 domain. However, burdening OSPF with this additional information 104 will impact intra-domain routing convergence and possibly jeopardize 105 the stability of the OSPF routing domain. This document presents 106 mechanism to relegate this ancillary information to a separate OSPF 107 instance and minimize the impact. 109 This OSPF protocol extension provides functionality similar to 110 "Advertising Generic Information in IS-IS" [RFC6823]. Additionally, 111 OSPF is extended to support sparse non-routing overlay topologies 112 Section 4.7. 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. Possible Use Cases 124 3.1. MEC Service Discovery 126 Multi-Access Edge Computing (MEC) plays an important role in 5G 127 architecture. MEC optimizes the performance for ultra-low latency 128 and high bandwidth services by providing networking and computing at 129 the edge of the network [ETSI-WP28-MEC]. To achieve this goal, it's 130 important to expose the network capabilities and services of a MEC 131 device to 5G User Equipment UE, i.e. UEs. 133 The followings are an incomplete list of the kind of information that 134 OSPF transport instance can help to disseminate: 136 o A network service is realized using one or more physical or 137 virtualized hosts in MEC, and the locations of these service 138 points might change. The auto-discovery of these service 139 locations can be achieved using an OSPF transport instance. 141 o UEs might be mobile, and MEC should support service continuity and 142 application mobility. This may require service state transferring 143 and synchronization. OSPF transport instance can be used to 144 synchronize these states. 146 o Network resources are limited, such as computing power, storage. 147 The availability of such resources is dynamic, and OSPF transport 148 instance can be used to populate such information, so applications 149 can pick the right location of such resources, hence improve user 150 experience and resource utilization. 152 3.2. Application Data Dissemination 154 Typically a network consists of routers from different vendors with 155 different capabilities, and some applications may want to know 156 whether a router supports certain functionality or where to find a 157 router supports a functionality, so it will be ideal if such kind of 158 information is known to all routers or a group of routers in the 159 network. For example, an ingress router needs to find an egress 160 router that supports In-situ Flow Information Telemetry (IFIT) 161 [I-D.wang-lsr-igp-extensions-ifit] and obtain IFIT parameters. 163 OSPF transport instance can be used to populate such router 164 capabilities/functionalities without impacting the performance or 165 convergence of the base OSPF protocol. 167 3.3. Intra-Area Topology for BGP-LS Distribution 169 In some cases, it is desirable to limit the number of BGP-LS 170 [RFC5572] sessions with a controller to the a one or two routers in 171 an OSPF domain. However, many times those router(s) do not have full 172 visibility to the complete topology of all the areas. To solve this 173 problem without extended the BGP-LS domain, the OSPF LSAs for non- 174 local area could be flooded over the OSPF transport instance topology 175 using remote neighbors Section 4.7.1. 177 4. OSPF Transport Instance 179 In order to isolate the effects of flooding and processing of non- 180 routing information, it will be relegated to a separate protocol 181 instance. This instance should be given lower priority when 182 contending for router resources including processing, backplane 183 bandwidth, and line card bandwidth. How that is realized is an 184 implementation issue and is outside the scope of this document. 186 Throughout the document, non-routing refers to routing information 187 that is not used for IP or IPv6 routing calculations. The OSPF 188 transport instance is ideally suited for dissemination of routing 189 information for other protocols and layers. 191 4.1. OSPFv2 Transport Instance Packet Differentiation 193 OSPFv2 currently does not offer a mechanism to differentiate 194 Transport instance packets from normal instance packets sent and 195 received on the same interface. However, the [RFC6549] provides the 196 necessary packet encoding to support multiple OSPF protocol 197 instances. 199 4.2. OSPFv3 Transport Instance Packet Differentiation 201 Fortunately, OSPFv3 already supports separate instances within the 202 packet encodings. The existing OSPFv3 packet header instance ID 203 field will be used to differentiate packets received on the same link 204 (refer to section 2.4 in [RFC5340]). 206 4.3. Instance Relationship to Normal OSPF Instances 208 In OSPF transport instance, we must guarantee that any information 209 we've received is treated as valid if and only if the router sending 210 it is reachable. We'll refer to this as the "condition of 211 reachability" in this document. 213 The OSPF transport instance is not dependent on any other OSPF 214 instance. It does, however, have much of the same as topology 215 information must be advertised to satisfy the "condition of 216 reachability". 218 Further optimizations and coupling between an OSPF transport instance 219 and a normal OSPF instance are beyond the scope of this document. 220 This is an area for future study. 222 4.4. Network Prioritization 224 While OSPFv2 (section 4.3 in [RFC2328]) are normally sent with IP 225 precedence Internetwork Control, any packets sent by an OSPF 226 transport instance will be sent with IP precedence Flash (B'011'). 227 This is only appropriate given that this is a pretty flashy 228 mechanism. 230 Similarly, OSPFv3 transport instance packets will be sent with the 231 traffic class mapped to flash (B'011') as specified in ([RFC5340]). 233 By setting the IP/IPv6 precedence differently for OSPF transport 234 instance packets, normal OSPF routing instances can be given priority 235 during both packet transmission and reception. In fact, some router 236 implementations map the IP precedence directly to their internal 237 packet priority. However, internal router implementation decisions 238 are beyond the scope of this document. 240 4.5. OSPF Transport Instance Omission of Routing Calculation 242 Since the whole point of the transport instance is to separate the 243 routing and non-routing processing and fate sharing, a transport 244 instance SHOULD NOT install any IP or IPv6 routes. OSPF routers 245 SHOULD NOT advertise any transport instance LSAs containing IP or 246 IPv6 prefixes and OSPF routers receiving LSAs advertising IP or IPv6 247 prefixes SHOULD ignore them. This implies that an OSPF transport 248 instance Link State Database should not include any of the LSAs as 249 shown in Table 1. 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | OSPFv2 | summary-LSAs (type 3) | 253 | | AS-external-LSAs (type 5) | 254 | | NSSA-LSAs (type 7) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | OSPFv3 | inter-area-prefix-LSAs (type 2003) | 257 | | AS-external-LSAs (type 0x4005) | 258 | | NSSA-LSAs (type 0x2007) | 259 | | intra-area-prefix-LSAs (type 0x2009) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | OSPFv3 Extended LSA | E-inter-area-prefix-LSAs (type 0xA023) | 262 | | E-as-external-LSAs (type 0xC025) | 263 | | E-Type-7-NSSA (type 0xA027) | 264 | | E-intra-area-prefix-LSA (type 0xA029) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 LSAs not included in OSPF transport instance 269 If these LSAs are erroneously advertised, they will be flooded as per 270 standard OSPF but MUST be ignored by OSPF routers supporting this 271 specification. 273 4.6. Non-routing Instance Separation 275 It has been suggested that an implementation could obtain the same 276 level of separation between IP routing information and non-routing 277 information in a single instance with slight modifications to the 278 OSPF protocol. The authors refute this contention for the following 279 reasons: 281 o Adding internal and external mechanisms to prioritize routing 282 information over non-routing information are much more complex 283 than simply relegating the non-routing information to a separate 284 instance as proposed in this specification. 286 o The instance boundary offers much better separation for allocation 287 of finite resources such as buffers, memory, processor cores, 288 sockets, and bandwidth. 290 o The instance boundary decreases the level of fate sharing for 291 failures. Each instance may be implemented as a separate process 292 or task. 294 o With non-routing information, many times not every router in the 295 OSPF routing domain requires knowledge of every piece of non- 296 routing information. In these cases, groups of routers which need 297 to share information can be segregated into sparse topologies 298 greatly reducing the amount of non-routing information any single 299 router needs to maintain. 301 4.7. Non-Routing Sparse Topologies 303 With non-routing information, many times not every router in the OSPF 304 routing domain requires knowledge of every piece of non-routing 305 information. In these cases, groups of routers which need to share 306 information can be segregated into sparse topologies. This will 307 greatly reduce the amount of information any single router needs to 308 maintain with the core routers possibly not requiring any non-routing 309 information at all. 311 With normal OSPF, every router in an OSPF area must have every piece 312 of topological information and every intra-area IP or IPv6 prefix. 313 With non-routing information, only the routers needing to share a set 314 of information need be part of the corresponding sparse topology. 315 For directly attached routers, one only needs to configure the 316 desired topologies on the interfaces with routers requiring the non- 317 routing information. When the routers making up the sparse topology 318 are not part of a uniconnected graph, two alternatives exist. The 319 first alternative is configure tunnels to form a fully connected 320 graph including only those routers in the sparse topology. The 321 second alternative is use remote neighbors as described in 322 Section 4.7.1. 324 4.7.1. Remote OSPF Neighbor 326 With sparse topologies, OSPF routers sharing non-routing information 327 may not be directly connected. OSPF adjacencies with remote 328 neighbors are formed exactly as they are with regular OSPF neighbors. 329 The main difference is that a remote OSPF neighbor's address is 330 configured and IP routing is used to deliver OSPF protocol packets to 331 the remote neighbor. Other salient feature of the remote neighbor 332 include: 334 o All OSPF packets have the remote neighbor's configured IP address 335 as the IP destination address. 337 o The adjacency is represented in the router Router-LSA as a router 338 (type-1) link with the link data set to the remote neighbor's 339 configured IP address. 341 o Similar to NBMA networks, a poll-interval is configured to 342 determine if the remote neighbor is reachable. This value is 343 normally much higher than the hello interval with 40 seconds 344 RECOMMENDED as the default. 346 4.8. Multiple Topologies 348 For some applications, the information need to be flooded only to a 349 topology which is a subset of routers of the transport instance. 350 This allows the application specific information only to be flooded 351 to routers that support the application. A transport instance may 352 support multiple topologies as defined in [RFC4915]. But as pointed 353 out in Section 4.5, a transport instance or topology SHOULD NOT 354 install any IP or IPv6 routes. 356 Each topology associated with the transport instance MUST be fully 357 connected in order for the LSAs to be successfully flooded to all 358 routers in the topology. 360 5. OSPF Transport Instance Information (TII) Encoding 362 5.1. OSPFv2 Transport Instance Information Encoding 364 Application specific information will be flooded in opaque LSAs as 365 specified in [RFC5250]. An Opaque LSA option code will be reserved 366 for Transport Instance Information (TII) as described in Section 8. 367 The TII LSA can be advertised at any of the defined flooding scopes 368 (link, area, or autonomous system (AS)). 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | LS age | Options | 9, 10, or 11 | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | TBD1 | Opaque ID (Instance ID) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Advertising Router | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | LS sequence number | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | LS checksum | length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 +- TLVs -+ 385 | ... | 387 g 389 OSPFv2 Transport Instance Information Opaque LSA 391 The format of the TLVs within the body of an TII LSA is as defined in 392 Section 5.3. 394 5.2. OSPFv3 Transport Instance Information Encoding 396 Application specific information will be flooded in separate LSAs 397 with a separate function code. Refer to section A.4.2.1 of 398 [RFC5340]. for information on the LS Type encoding in OSPFv3, and 399 section 2 of [RFC8362] for OSPFv3 extended LSA types. An OSPFv3 400 function code will be reserved for Transport Instance Information 401 (TII) as described in Section 8. Same as OSPFv2, the TII LSA can be 402 advertised at any of the defined flooding scopes (link, area, or 403 autonomous system (AS)). The U bit will be set indicating that 404 OSPFv3 TTI LSAs should be flooded even if it is not understood. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | LS age |1|S12| TBD2 | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Link State ID (Instance ID) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Advertising Router | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | LS sequence number | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | LS checksum | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | 420 +- TLVs -+ 421 | ... | 423 OSPFv3 Transport Instance Information LSA 425 The format of the TLVs within the body of an TII LSA is as defined in 426 Section 5.3. 428 5.3. Transport Instance Information (TII) TLV Encoding 430 The format of the TLVs within the body of the LSAs containing non- 431 routing information is the same as the format used by the Traffic 432 Engineering Extensions to OSPF [RFC3630]. The LSA payload consists 433 of one or more nested Type/Length/Value (TLV) triplets. The format 434 of each TLV is: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Value... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 TLV Format 446 5.3.1. Top-Level TII Application TLV 448 An Application top-level TLV will be used to encapsulate application 449 data advertised within TII LSAs. This top-level TLV may be used to 450 handle the local publication/subscription for application specific 451 data. The details of such a publication/subscription mechanism are 452 beyond the scope of this document. An Application ID is used in the 453 top-level application TLV and shares the same code point with IS-IS 454 as defined in [RFC6823]. 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type (1) | Length - Variable | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Application ID | Reserved | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 . . 464 . Sub-TLVs . 465 . . 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Application ID: 469 An identifier assigned to this application via the IANA registry, 470 as defined in RFC 6823. Each unique application will have a 471 unique ID. 473 Additional Application-Specific Sub-TLVs: 474 Additional information defined by applications can be encoded as 475 Sub-TLVs. Definition of such information is beyond the scope of 476 this document. 478 Top-Level TLV 480 The specific TLVs and sub-TLVs relating to a given application and 481 the corresponding IANA considerations MUST be specified in the 482 document corresponding to that application. 484 6. Manageability Considerations 486 7. Security Considerations 488 The security considerations for the Transport Instance will not be 489 different for those for OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 491 8. IANA Considerations 493 8.1. OSPFv2 Opaque LSA Type Assignment 495 IANA is requested to assign an option type, TBD1, for Transport 496 Instance Information (TII) LSA from the "Opaque Link-State 497 Advertisements (LSA) Option Types" registry. 499 8.2. OSPFv3 LSA Function Code Assignment 501 IANA is requested to assign a function code, TBD2, for Transport 502 Instance Information (TII) LSAs from the "OSPFv3 LSA Function Codes" 503 registry. 505 8.3. OSPF Transport Instance Information Top-Level TLV Registry 507 IANA is requested to create a registry for OSPF Transport Instance 508 Information (TII) Top-Level TLVs. The first available TLV (1) is 509 assigned to the Application TLV Section 5.3.1. The allocation of the 510 unsigned 16-bit TLV type are defined in the table below. 512 +-------------+-----------------------------------+ 513 | Range | Assignment Policy | 514 +-------------+-----------------------------------+ 515 | 0 | Reserved (Not to be assigned) | 516 | | | 517 | 1 | Application TLV | 518 | | | 519 | 2-16383 | Unassigned (IETF Review) | 520 | | | 521 | 16383-32767 | Unassigned (FCFS) | 522 | | | 523 | 32768-32777 | Experimentation (No assignements) | 524 | | | 525 | 32778-65535 | Reserved (Not to be assigned) | 526 +-----------+-------------------------------------+ 528 TII Top-Level TLV Registry Assignments 530 9. Acknowledgement 532 The authors would like to thank Les Ginsberg for review and comments. 534 10. References 536 10.1. Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, 540 DOI 10.17487/RFC2119, March 1997, 541 . 543 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 544 DOI 10.17487/RFC2328, April 1998, 545 . 547 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 548 (TE) Extensions to OSPF Version 2", RFC 3630, 549 DOI 10.17487/RFC3630, September 2003, 550 . 552 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 553 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 554 RFC 4915, DOI 10.17487/RFC4915, June 2007, 555 . 557 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 558 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 559 July 2008, . 561 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 562 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 563 . 565 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 566 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 567 March 2012, . 569 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 570 Generic Information in IS-IS", RFC 6823, 571 DOI 10.17487/RFC6823, December 2012, 572 . 574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 575 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 576 May 2017, . 578 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 579 F. Baker, "OSPFv3 Link State Advertisement (LSA) 580 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 581 2018, . 583 10.2. Informative References 585 [ETSI-WP28-MEC] 586 Sami Kekki, etc., "MEC in 5G Networks", 2018, 587 . 590 [I-D.wang-lsr-igp-extensions-ifit] 591 Wang, Y., Zhou, T., Qin, F., Chen, H., and R. Pang, "IGP 592 Extensions for In-situ Flow Information Telemetry (IFIT) 593 Capability Advertisement", draft-wang-lsr-igp-extensions- 594 ifit-01 (work in progress), July 2020. 596 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the 597 Tunnel Setup Protocol (TSP)", RFC 5572, 598 DOI 10.17487/RFC5572, February 2010, 599 . 601 Authors' Addresses 603 Acee Lindem 604 Cisco Systems 605 301 Midenhall Way 606 CARY, NC 27513 607 UNITED STATES 609 Email: acee@cisco.com 611 Yingzhen Qu 612 Futurewei 613 2330 Central Expressway 614 Santa Clara, CA 95050 615 USA 617 Email: yingzhen.qu@futurewei.com 619 Abhay Roy 620 Arrcus, Inc. 622 Email: abhay@arrcus.com 624 Sina Mirtorabi 625 Cisco Systems 626 170 West Tasman Drive 627 San Jose, CA 95134 628 USA 630 Email: smirtora@cisco.com