idnits 2.17.1 draft-cls-ppr-te-attributes-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 (May 16, 2019) is 1808 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) == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-03 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-03 == Outdated reference: A later version (-09) exists of draft-clt-dmm-tn-aware-mobility-03 -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group U. Chunduri, Ed. 3 Internet-Draft R. Li 4 Intended status: Standards Track Huawei USA 5 Expires: November 17, 2019 K. Smith 6 Vodafone 7 May 16, 2019 9 Resources for Preferred Path Routes in IGPs 10 draft-cls-ppr-te-attributes-01 12 Abstract 14 Preferred Path Routing (PPR) is concerned with setting up the route 15 for a given prefix as specified in the path description along with a 16 corresponding data plane/forwarding identifier PPR-ID. This document 17 specifies an extension to PPR, a mechanism to perform resource 18 reservations nodes on Preferred Path Routes (PPR) for IGPs (IS-IS, 19 OSPFv2, OSPFv3). This is done by specifying the resources that need 20 to be reserved along the path using PPR path attributes. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC2119 [RFC2119], 27 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 28 shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 17, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 67 3. PPR Resource Reservation Related Parameters . . . . . . . . . 4 68 3.1. IS-IS Parameters . . . . . . . . . . . . . . . . . . . . 4 69 3.1.1. Bandwidth Sub-TLV . . . . . . . . . . . . . . . . . . 4 70 3.1.2. Burst Size Sub-TLV . . . . . . . . . . . . . . . . . 5 71 3.1.3. Per-hop Queuing Latency Sub-TLV . . . . . . . . . . . 5 72 3.1.4. Lifetime Sub-TLV . . . . . . . . . . . . . . . . . . 6 73 3.1.5. Node Resource Capability Sub-TLV . . . . . . . . . . 7 74 3.1.6. Node Status TLV . . . . . . . . . . . . . . . . . . . 8 75 3.1.7. IS-IS TE Metric Extensions . . . . . . . . . . . . . 9 76 3.1.7.1. Per PPR queuing delay on the node . . . . . . . . 10 77 3.1.7.2. Unidirectional Utilized PPR Bandwidth . . . . . . 10 78 3.2. OSPFv2/OSPFv3 Parameters . . . . . . . . . . . . . . . . 11 79 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 11 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. IGP Common Parameters . . . . . . . . . . . . . . . . . . 12 83 6.2. IS-IS Registries . . . . . . . . . . . . . . . . . . . . 12 84 6.3. OSPFv2 Registries . . . . . . . . . . . . . . . . . . . . 13 85 6.4. OSPFv3 Registries . . . . . . . . . . . . . . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 8.2. Informative References . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 RSVP [RFC2205] allows out of band signaling along a specified path 95 for resource reservations. This is done by sending PATH/RESV message 96 with flow-spec/filter-spec. RSVP-TE [RFC3209], builds on RSVP 97 protocol and defines new objects, modifies existing objects for MPLS 98 LSP establishment with resources (reserved bandwidth). This is less 99 widely deployed perhaps due to soft-state maintenance, scaling and 100 management overhead considerations. [RFC8370] addresses some of the 101 concerns by specifying refresh independence and per-peer flow control 102 which would reduce processing cycles required to maintain LSP state. 104 Segment Routing [RFC8402] enables packet steering with a specified 105 path in the packet itself designed for MPLS and IPv6 data plane SRH. 106 Routing with Preferred Paths with an optimized data plane (regardless 107 of the type of data plane) is described in 108 [I-D.chunduri-lsr-isis-preferred-path-routing]. With PPR nodes in 109 IGP compute the nexthops based on the path description of the prefix 110 for increasing dataplane performance and reducing the packet 111 overhead. While both these allow packet steering on a specified path 112 (either encoded in the packet itself or through a data plane 113 identifier), they do not have any notion of QoS or resources reserved 114 along the path. 116 This document extends PPR to indicate the resources to be reserved 117 along the preferred path. These resources are required in some 118 deployments [I-D.clt-dmm-tn-aware-mobility], for not only providing 119 committed bandwidth or deterministic latency, but also for assuring 120 overall service level guarantee in the network. This approach does 121 not require per-hop provisioning and also reduces the OPEX by 122 minimizing the number of protocols needed and allows dynamism with 123 FRR capabilities. Unlike [RFC3209], this does not rely on periodic 124 refreshes between neighbors for state synchronization. 126 1.1. Acronyms 128 IS-IS LSP- IS-IS Link State PDU 130 LSP - Label Switched Path 132 MPLS - Multi Protocol Label Switching 134 MTU - Maximum Transferrable Unit 136 PPR - Preferred Path Routing/Route 138 PPR-ID - Preferred Path Route Identifier, a data plane identifier 139 SID - Segment Identifier 141 SR-MPLS - Segment Routing with MPLS data plane 143 SRH - Segment Routing Header - IPv6 routing Extension header 145 SRv6 - Segment Routing with Ipv6 data plane with SRH 147 TE - Traffic Engineering 149 2. Solution Overview 151 Key aspect of the solution concerns with specifying the resources to 152 be reserved along the preferred path 153 [I-D.chunduri-lsr-isis-preferred-path-routing], 154 [I-D.chunduri-lsr-ospf-preferred-path-routing].Reservations are 155 expressed in terms of required resources (bandwidth), traffic 156 characteristics (burst size), and service level parameters (expected 157 maximum latency at each hop) based on the capabilities of each node 158 and link along the path. The second part of the solution is 159 providing mechanism to indicate the status of the reservations 160 requested i.e., if these have been honored by individual node/links 161 in the path. This is done by defining a new TLV/Sub-TLV in 162 respective IGPS. Another aspect is additional node level TLVs and 163 extensions to [RFC7810] and [RFC7471] to provide accounting/usage 164 statistics that have to be maintained at each node per preferred 165 path. All the above is specified for IS-IS/OSPFv2/OSPFv3 protocols. 167 3. PPR Resource Reservation Related Parameters 169 This section describes the encoding of additional TLVs and Sub-TLVs 170 needed for resource reservations, associated accounting statistics 171 for Preferred Path Routes in IS-IS/OSPFv2/OSPFv3 protocols. 173 3.1. IS-IS Parameters 175 [I-D.chunduri-lsr-isis-preferred-path-routing] defines few PPR- 176 Attribute Sub-TLVs and this document extends the same for resources 177 to be reserved through various Sub-TLVs. The following additional 178 IS-IS PPR-Attribute Sub-TLVs (Type - IANA TBD) are defined: 180 3.1.1. Bandwidth Sub-TLV 182 This is the required bandwidth for the PPR at each node/link in the 183 path description. It has minimum (CIR) and maximum bandwidth (PIR). 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |Type | Length | Reserved | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Minimum bandwidth | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Maximum bandwidth | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1: Bandwidth Sub-TLV Format 197 o Type: 5 (IANA) 199 o Length: 10 Octets 201 o Minimum bandwidth: The minimum bandwidth required, or CIR, unit 202 Mbps 204 o Maximum bandwidth: The maximum bandwidth required, or PIR, unit 205 Mbps 207 3.1.2. Burst Size Sub-TLV 209 This is the required burst for the PPR and is the maximum burst size. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |Type | Length | Reserved | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Burst Size | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 2: Burst Size Sub-TLV Format 221 o Type: 6 (IANA) 223 o Length: 6 Octets 225 o Burst size: The burst size, unit K bytes 227 3.1.3. Per-hop Queuing Latency Sub-TLV 229 This is the bounded latency for each hop on the PPR. This is not the 230 end to end latency. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |Type | Length | Reserved |T| Flags | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Latency | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 3: Per-hop Queuing Latency Sub-TLV Format 242 o Type: 7 (IANA) 244 o Length: 6 Octets 246 o Flags: 1 Octet 248 T Bit - Set to 0, if Queuing Latency in milliseconds and Set to 1, If 249 Queuing Latency in microseconds 251 Latency: Expected maximum queuing latency for each hop 253 When an expected hop-by-hop latency is given, the bandwidth 254 expectation (CIR) MUST be present. 256 3.1.4. Lifetime Sub-TLV 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |Type | Length | Reserved| Flags | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Lifetime | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 4: Lifetime Sub-TLV Format 268 o Type: 8 (IANA) 270 o Length: 6 Octets 272 o Flags: 1 Octet 274 o Life Time: Life time of reservations done at each node in Seconds 276 See the usage of this TLV and procedures after Lifetime expiration 277 and related details in Section 4. 279 3.1.5. Node Resource Capability Sub-TLV 281 The node Resource Capability Sub-TLV is defined within the body of 282 the IS-IS Router Capability TLV [RFC7981]. This would allow what all 283 TE parameters than can be supported by a node. This sub-TLV lists 284 all supported TE capabilities. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |Type | Length | RC Flags | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 5: IS-IS Reservation Capability Sub-TLV Format 294 o Type: TBD (IANA) from IS-IS Router Capability TLV Registry 296 o Length: Total length of the value field in bytes 298 o RC Flags: 2 Octets 300 Reservation Capability Sub-TLV bit-field Format 302 Reservation Capability bit-field Format 304 0 1 2 3 4 5 6 7 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |B|S|L|T| Reserved |E| 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 o Bit-0: B Bit: If this bit is set, Min/Max bandwidth reservation is 310 supported by the node 312 o Bit-1: S Bit: If this bit is set burst size handling is supported 313 by the node 315 o Bit-2: L Bit: If this bit is set per hop maximum queuing latency 316 is supported by the node 318 o Bit-3: T Bit: If this bit is set an expiration timer for PPR-ID is 319 supported by the node 321 o Bit-15: E Bit: If this bit is set one more 16-bit status bit-field 322 is followed to this bit-field. 324 Rest of the bits undefined and transmitted as unset/0. 326 3.1.6. Node Status TLV 328 A new top level IS-IS TLV is defined to indicate the status of per 329 preferred path TE resource reservation by each node, where it is part 330 of one ore more PPRs. This TLV should be generated by a node which 331 is along the preferred path and which does the reservation of 332 resources as indicated in the above TE parameters. 334 Structure of this TLV: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |Type | Length | Reserved | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 // Sub-TLVs // 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 6: Node Status TLV Format 346 o Type: TBD (IANA) - From IS-IS top level TLV registry 348 o Length: Total length of the value field in bytes 350 o Sub-TLVs : One or more Sub-TLVs 352 This document defines one of the Sub-TLVs in the above TLV. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |Type | Length | PPR-ID Type | PPR-ID Len | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 // PPR-ID Value (Size variable) // 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |16-bit status bit-field | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 7: Reservation Status Sub-TLV Format 366 Reservation Status Sub-TLV bit-field Format 368 Reservation Status bit-field Format 370 0 1 2 3 4 5 6 7 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |B|S|L|T| Reserved |E| 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 o Bit-0: B Bit: If this bit is set, Min/Max bandwidth reservation 376 for the PPR-ID is present 378 o Bit-1: S Bit: If this bit is set burst size handling for the PPR- 379 ID is present 381 o Bit-2: L Bit: If this bit is set per hop maximum queuing latency 382 enforcement is present 384 o Bit-3: T Bit: If this bit is set an expiration timer is present 386 o Bit-15: E Bit: If this bit is set one more 16-bit status bit-field 387 is followed to this bit-field. 389 Rest of the bits undefined and transmitted as unset/0. 391 Once preferred path is received through IGP as defined in 392 [I-D.chunduri-lsr-isis-preferred-path-routing] and with the 393 extensions as specified in this document for resources reservation, a 394 node on the path allocate the resources requested in the hardware. 395 However after resources are allocated in the hardware, status of the 396 same is given to the respective IGP in the control plane, which would 397 enable IGP to indicate the status in the structure described above. 398 If record is missing in the above structure, for that preferred path 399 reservations could have been withdrawn. 401 3.1.7. IS-IS TE Metric Extensions 403 Once resource reservations are done, usage statistics need to be 404 maintained and further transported to a central entity. Each node on 405 PPR path, the following stat(s) need to be maintained. More 406 parameters TBD. 408 3.1.7.1. Per PPR queuing delay on the node 410 This Sub-TLV advertises the average PPR queue delay variation in the 411 node. This is a 24-bit field carries the average PPR queue delay 412 over a configurable interval in microseconds The delay variation 413 advertised. The format of this Sub-TLV is shown in the following 414 diagram: 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Type | Length | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | RESERVED | Avg. queue Delay Variation | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |PPR-ID Type | PPR-ID Len | PPR-ID Value (Size variable) // 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 8: QUEUE Delay Sub-TLV Format 428 o where: 430 Type: TBD IANA - from the node capabilities TLV. 432 Length: Variable 434 RESERVED: This field is reserved for future use. It MUST be set to 0 435 when sent and MUST be ignored when received. 437 Delay Variation: This 24-bit field carries the average PPR queue 438 delay variation over a configurable interval in microseconds, encoded 439 as an integer value. When set to 0, it has not been measured. When 440 set to the maximum value 16,777,215 (16.777215 sec), then the delay 441 is at least that value and may be larger. 443 3.1.7.2. Unidirectional Utilized PPR Bandwidth 445 This Sub-TLV advertises the PPR bandwidth utilization per PPR-ID in 446 the node. The bandwidth utilization advertised by this Sub-TLV MUST 447 be the bandwidth from the system originating this Sub-TLV. The 448 format of this Sub-TLV is shown in the following diagram: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type | Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Utilized Bandwidth | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |PPR-ID Type | PPR-ID Len | PPR-ID Value (Size variable) // 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 9: TLV Format 462 where: 464 o Type: IANA (TBD) - from the "Sub-TLVs for TLVs 22, 23, 141, 222, 465 and 223" registry: 467 o Length: Total length of the value field in bytes 469 o Utilized Bandwidth: This field carries the bandwidth utilization 470 per PPR-ID on a link , forwarding adjacency, or bundled link in 471 IEEE floating-point format with units of bytes per second. 472 Considerations for a link or forwarding adjacency or for a bundled 473 link is similar to Section 4.7 of RFC 7810. 475 3.2. OSPFv2/OSPFv3 Parameters 477 Similar extensions are needed for OSPFv2 and OSPFv3 PPR TLV's PPR 478 attributes except the Type (respective suggested values in 479 Section 6.3 and Section 6.4) and Length fields are 2 octets each. 480 New Sub-TLVs are also needed for Node status similar to Figure 6 and 481 TE parameter extensions similar to Section 3.1.7 for OSPFv2 and 482 OSPFv3 protocols. 484 4. Elements of Procedure 486 If a PPR has attributes as specified in Section 3 for reserving 487 resources along the path, individual nodes in the path description 488 acts on the path attributes. Section 3 defines few PPR-Attributes 489 for allocating/reserving resources in each node of the PPR path 490 description. Presence of these Sub-TLVs instruct to provision the 491 hardware with appropriate parameters as specified. Traffic 492 accounting should happen concerning to the resource in question, when 493 the actual data traffic hits for the PPR-ID in the forwarding plane. 494 New attribute values can be updated for an existing PPR-ID and when 495 the PPR-ID is withdrawn corresponding resources along the path MUST 496 be removed along with the Status TLV Figure 7 update. 498 After the data plane is programmed for a TE, a TE state is created. 499 The TE state life is determined by the "Life Time" in the PPR 500 attribute Sub-TLV. Whenever there is a packet processed by a TE 501 state for the respective PPR-ID, the associated timer for the TE 502 state is reset. If the timer of a TE state is expired, the TE state 503 will be erased and the associated resource can be released and 504 accordingly and Node Status TLV Figure 7 would be updated. In order 505 to keep the TE state active, IGP LSP/LSA refresh has to happen and it 506 should be less than the time of "Life time" attribute 507 (Section 3.1.4). 509 5. Acknowledgements 511 TBD. 513 6. IANA Considerations 515 6.1. IGP Common Parameters 517 This document requests additional IANA registries in an IANA managed 518 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 519 TLV parameters. The registration procedure is based on the "Expert 520 Review" as defined in [RFC8126]. The suggested registry names are: 522 6.2. IS-IS Registries 524 This document requests IANA to create a new Sub-TLV registry for IS- 525 IS PPR TLV Section 3 with the following initial entries (suggested 526 values): 528 Sub-TLV # Sub-TLV Name 529 --------- --------------------------------------------------------- 531 5 Bandwidth (Section 3.1.1) 533 6 Burst Size (Section 3.1.2) 535 7 Per-hop Queuing Latency (Section 3.1.3) 537 8 Lifetime (Section 3.1.4) 539 This document also requests a new Sub-TLV code point from IS-IS 540 Router Capability TLV Registry as defined by [RFC8126] and an IS-IS 541 top level Status TLV code point from IANA IS-IS TLV code- point 542 registry. 544 6.3. OSPFv2 Registries 546 This document requests IANA to create a new Sub-TLV registry for 547 OSPFv2 PPR TLV Section 3 with the following initial entries 548 (suggested values): 550 Sub-TLV # Sub-TLV Name 551 --------- --------------------------------------------------------- 553 4 Bandwidth (Section 3.2) 555 5 Burst Size (Section 3.2) 557 6 Per-hop Queuing Latency (Section 3.2) 559 7 Lifetime (Section 3.2) 561 6.4. OSPFv3 Registries 563 This document requests IANA to create a new Sub-TLV registry for 564 OSPV3 PPR TLV Section 3 with the following initial entries (suggested 565 values): 567 Sub-TLV # Sub-TLV Name 568 --------- --------------------------------------------------------- 570 4 Bandwidth (Section 3.2) 572 5 Burst Size (Section 3.2) 574 6 Per-hop Queuing Latency (Section 3.2) 576 7 Lifetime (Section 3.2) 578 7. Security Considerations 580 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 581 Further security analysis for IS-IS protocol is done in [RFC7645] 582 with detailed analysis of various security threats and why [RFC5304] 583 should not be used in the deployments. 585 OSPF security extensions are described in [RFC2328] and [RFC7684] and 586 these apply to the extensions specified in this document. While OSPF 587 is under a single administrative domain, there can be deployments 588 where potential attackers have access to one or more networks in the 589 OSPF routing domain. In these deployments, stronger authentication 590 mechanisms such as those specified in [RFC7474] SHOULD be used. 592 Advertisement of the additional information defined in this document 593 introduces no new security concerns in IS-IS or OSPF protocols. 595 8. References 597 8.1. Normative References 599 [I-D.chunduri-lsr-isis-preferred-path-routing] 600 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 601 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 602 draft-chunduri-lsr-isis-preferred-path-routing-03 (work in 603 progress), May 2019. 605 [I-D.chunduri-lsr-ospf-preferred-path-routing] 606 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 607 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 608 chunduri-lsr-ospf-preferred-path-routing-03 (work in 609 progress), May 2019. 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, 613 DOI 10.17487/RFC2119, March 1997, 614 . 616 8.2. Informative References 618 [I-D.clt-dmm-tn-aware-mobility] 619 Chunduri, U., Li, R., Bhaskaran, S., Tantsura, J., 620 Contreras, L., and P. Muley, "Transport Network aware 621 Mobility for 5G", draft-clt-dmm-tn-aware-mobility-03 (work 622 in progress), February 2019. 624 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 625 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 626 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 627 September 1997, . 629 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 630 DOI 10.17487/RFC2328, April 1998, 631 . 633 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 634 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 635 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 636 . 638 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 639 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 640 2008, . 642 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 643 and M. Fanto, "IS-IS Generic Cryptographic 644 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 645 2009, . 647 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 648 Previdi, "OSPF Traffic Engineering (TE) Metric 649 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 650 . 652 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 653 "Security Extension for OSPFv2 When Using Manual Key 654 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 655 . 657 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 658 Authentication for Routing Protocol (KARP) IS-IS Security 659 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 660 . 662 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 663 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 664 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 665 2015, . 667 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 668 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 669 RFC 7810, DOI 10.17487/RFC7810, May 2016, 670 . 672 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 673 for Advertising Router Information", RFC 7981, 674 DOI 10.17487/RFC7981, October 2016, 675 . 677 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 678 Writing an IANA Considerations Section in RFCs", BCP 26, 679 RFC 8126, DOI 10.17487/RFC8126, June 2017, 680 . 682 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 683 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 684 May 2017, . 686 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 687 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 688 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 689 . 691 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 692 Decraene, B., Litkowski, S., and R. Shakir, "Segment 693 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 694 July 2018, . 696 Authors' Addresses 698 Uma Chunduri (editor) 699 Huawei USA 700 2330 Central Expressway 701 Santa Clara, CA 95050 702 USA 704 Email: uma.chunduri@huawei.com 706 Richard Li 707 Huawei USA 708 2330 Central Expressway 709 Santa Clara, CA 95050 710 USA 712 Email: renwei.li@huawei.com 714 Kevin Smith 715 Vodafone 716 UK 718 Email: kevin.smith@vodafone.com