idnits 2.17.1 draft-ietf-lsr-ospf-transport-instance-02.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 (21 May 2022) is 706 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: 22 November 2022 Futurewei 6 A. Roy 7 Arrcus, Inc. 8 S. Mirtorabi 9 Cisco Systems 10 21 May 2022 12 OSPF Transport Instance Extensions 13 draft-ietf-lsr-ospf-transport-instance-02 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 22 November 2022. 45 Copyright Notice 47 Copyright (c) 2022 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. Possible Use Cases . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. MEC Service Discovery . . . . . . . . . . . . . . . . . . 3 65 3.2. Application Data Dissemination . . . . . . . . . . . . . 4 66 3.3. Intra-Area Topology for BGP-LS Distribution . . . . . . . 4 67 4. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4 68 4.1. OSPFv2 Transport Instance Packet Differentiation . . . . 5 69 4.2. OSPFv3 Transport Instance Packet Differentiation . . . . 5 70 4.3. Instance Relationship to Normal OSPF Instances . . . . . 5 71 4.4. Network Prioritization . . . . . . . . . . . . . . . . . 5 72 4.5. OSPF Transport Instance Omission of Routing 73 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 . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 11 83 6. Manageability Considerations . . . . . . . . . . . . . . . . 11 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 8.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 12 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 * 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 * 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 * 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 Figure 1: 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 * 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 * The instance boundary offers much better separation for allocation 287 of finite resources such as buffers, memory, processor cores, 288 sockets, and bandwidth. 290 * 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 * 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 configuring 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 * All OSPF packets have the remote neighbor's configured IP address 335 as the IP destination address. This address has be to reachable 336 usig the unicast topology. 338 * The adjacency is represented in the router Router-LSA as a router 339 (type-1) link with the link data set to the remote neighbor's 340 configured IP address. 342 * Similar to NBMA networks, a poll-interval is configured to 343 determine if the remote neighbor is reachable. This value is 344 normally much higher than the hello interval with 40 seconds 345 RECOMMENDED as the default. 347 4.8. Multiple Topologies 349 For some applications, the information need to be flooded only to a 350 topology which is a subset of routers of the transport instance. 351 This allows the application specific information only to be flooded 352 to routers that support the application. A transport instance may 353 support multiple topologies as defined in [RFC4915]. But as pointed 354 out in Section 4.5, a transport instance or topology SHOULD NOT 355 install any IP or IPv6 routes. 357 Each topology associated with the transport instance MUST be fully 358 connected in order for the LSAs to be successfully flooded to all 359 routers in the topology. 361 5. OSPF Transport Instance Information (TII) Encoding 363 5.1. OSPFv2 Transport Instance Information Encoding 365 Application specific information will be flooded in opaque LSAs as 366 specified in [RFC5250]. An Opaque LSA option code will be reserved 367 for Transport Instance Information (TII) as described in Section 8. 368 The TII LSA can be advertised at any of the defined flooding scopes 369 (link, area, or autonomous system (AS)). 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | LS age | Options | 9, 10, or 11 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | TBD1 | Opaque ID (Instance ID) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Advertising Router | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | LS sequence number | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | LS checksum | length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 +- TLVs -+ 386 | ... | 388 g 390 Figure 2: OSPFv2 Transport Instance Information Opaque LSA 392 The format of the TLVs within the body of an TII LSA is as defined in 393 Section 5.3. 395 5.2. OSPFv3 Transport Instance Information Encoding 397 Application specific information will be flooded in separate LSAs 398 with a separate function code. Refer to section A.4.2.1 of 399 [RFC5340]. for information on the LS Type encoding in OSPFv3, and 400 section 2 of [RFC8362] for OSPFv3 extended LSA types. An OSPFv3 401 function code will be reserved for Transport Instance Information 402 (TII) as described in Section 8. Same as OSPFv2, the TII LSA can be 403 advertised at any of the defined flooding scopes (link, area, or 404 autonomous system (AS)). The U bit will be set indicating that 405 OSPFv3 TTI LSAs should be flooded even if it is not understood. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | LS age |1|S12| TBD2 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Link State ID (Instance ID) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Advertising Router | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | LS sequence number | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | LS checksum | Length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 +- TLVs -+ 422 | ... | 424 Figure 3: OSPFv3 Transport Instance Information LSA 426 The format of the TLVs within the body of an TII LSA is as defined in 427 Section 5.3. 429 5.3. Transport Instance Information (TII) TLV Encoding 431 The format of the TLVs within the body of the LSAs containing non- 432 routing information is the same as the format used by the Traffic 433 Engineering Extensions to OSPF [RFC3630]. The LSA payload consists 434 of one or more nested Type/Length/Value (TLV) triplets. The format 435 of each TLV is: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type | Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Value... | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 4: TLV Format 447 5.3.1. Top-Level TII Application TLV 449 An Application top-level TLV will be used to encapsulate application 450 data advertised within TII LSAs. This top-level TLV may be used to 451 handle the local publication/subscription for application specific 452 data. The details of such a publication/subscription mechanism are 453 beyond the scope of this document. An Application ID is used in the 454 top-level application TLV and shares the same code point with IS-IS 455 as defined in [RFC6823]. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type (1) | Length - Variable | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Application ID | Reserved | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 . . 465 . Sub-TLVs . 466 . . 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Application ID: 470 An identifier assigned to this application via the IANA registry, 471 as defined in RFC 6823. Each unique application will have a 472 unique ID. 474 Additional Application-Specific Sub-TLVs: 475 Additional information defined by applications can be encoded as 476 Sub-TLVs. Definition of such information is beyond the scope of 477 this document. 479 Figure 5: Top-Level TLV 481 The specific TLVs and sub-TLVs relating to a given application and 482 the corresponding IANA considerations MUST be specified in the 483 document corresponding to that application. 485 6. Manageability Considerations 487 7. Security Considerations 489 The security considerations for the Transport Instance will not be 490 different for those for OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 492 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 Figure 6: 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", Work in Progress, Internet- 594 Draft, draft-wang-lsr-igp-extensions-ifit-01, 28 July 595 2020, . 598 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the 599 Tunnel Setup Protocol (TSP)", RFC 5572, 600 DOI 10.17487/RFC5572, February 2010, 601 . 603 Authors' Addresses 605 Acee Lindem 606 Cisco Systems 607 301 Midenhall Way 608 CARY, NC 27513 609 United States 610 Email: acee@cisco.com 612 Yingzhen Qu 613 Futurewei 614 2330 Central Expressway 615 Santa Clara, CA 95050 616 United States of America 617 Email: yingzhen.qu@futurewei.com 619 Abhay Roy 620 Arrcus, Inc. 621 Email: abhay@arrcus.com 623 Sina Mirtorabi 624 Cisco Systems 625 170 West Tasman Drive 626 San Jose, CA 95134 627 United States of America 628 Email: smirtora@cisco.com