idnits 2.17.1 draft-dong-mpls-frr-resource-class-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If node disjoint protection if required, as indicated by the "protection desired" bit set and the "Node protection desired" bit set, then protection path SHOULD not be established for nodes or links which are included as a result of applying the corresponding Resource Attribute Bit Masks for the LSP to the Node Classification Bit Map of the node or Link Classification Bit Map of the link. Then for nodes and links which need local protection, the protection paths must be disjoint with respect to all SRLG, SRNG and ESRLG included, except SRNG and SRLG excluded as a result of applying the corresponding Resource Attribute Bit Masks for the LSP to the SRNG Classification Bit Map and the SRLG Classification Bit Map respectively. -- The document date (October 31, 2011) is 4555 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 3, 2012 C. Villamizar 6 OCCNC, LLC 7 October 31, 2011 9 MPLS-TE Fast Reroute Resource Classification 10 draft-dong-mpls-frr-resource-class-01 12 Abstract 14 This document describes simple and backward compatible extensions to 15 Fast-Reroute (FRR) MPLS Traffic Engineering (TE). The purpose of 16 these extensions include the following. These extensions provide a 17 classification of SRLG to support LSP with differing protection 18 requirements. These extensions allow highly reliable nodes or links, 19 typically resources with redundancy at a lower layer, to be 20 identified to allow LSP to optionally not consider these resources as 21 potential points of failure. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 65 3. TE FRR Resource Class Overview . . . . . . . . . . . . . . . . 4 66 3.1. Setting Default Behavior . . . . . . . . . . . . . . . . . 4 67 3.2. Backwards Compatibility with Legacy PLR . . . . . . . . . 4 68 3.3. Backwards Compatibility with Legacy Ingress . . . . . . . 5 69 4. TE FRR Resource Class Protocol Extensions . . . . . . . . . . 5 70 5. IGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5.1. OSPF Node Reliability sub-TLV . . . . . . . . . . . . . . 5 72 5.2. OSPF Link Reliability sub-TLV . . . . . . . . . . . . . . 6 73 5.3. IS-IS Node Reliability TLV . . . . . . . . . . . . . . . . 6 74 5.4. IS-IS Link Reliability TLV . . . . . . . . . . . . . . . . 7 75 5.5. Shared Risk Node Group . . . . . . . . . . . . . . . . . . 7 76 5.6. Extended Shared Risk Link Group . . . . . . . . . . . . . 8 77 6. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Resource Attribute Bit Mask . . . . . . . . . . . . . . . 9 79 7. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. To Be Completed . . . . . . . . . . . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.3. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 12. Normative References . . . . . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 MPLS Traffic Engineering (TE) Fast Reroute (FRR) [RFC4090] is widely 93 used for protecting MPLS-TE LSPs from local failures. TE FRR 94 implementations today can consistently achieve redirection of traffic 95 from a single resource failure to other local resources in 10s of 96 milliseconds. TE FRR can therefore provide high availability for 97 service carried on the TE LSP. 99 The existing TE FRR defines several protection and switching modes 100 which are designed to apply to all protected LSPs regardless of what 101 kind of availability is required by the service. Protection must 102 accomodate the most strict protection requirements of any service 103 carried, even though protection of low probability failures are not 104 appropriate for other services. Where this occurs, the result can be 105 greater requirements for network resources and higher network costs. 107 This document first describes the flexibility limitations in existing 108 TE FRR that are addressed and then proposes a flexible TE FRR 109 mechanism to address them. 111 2. Problem Statement 113 MPLS-TE LSPs may be used to carry services which require different 114 levels of availability. MPLS-TE FRR mechanism defined in [RFC4090] 115 can only provide the same local protection level for LSPs regardless 116 of the availability requirement of the services. 118 In some cases network nodes with sufficient internal redundancy 119 mechanisms could be considered sufficiently immune to node failures 120 for most services. Similarly, some links could also be considered 121 sufficiently redundant for most services. Examples of reliable links 122 are link bundle and multipath links that do not use common media, 123 such as parallel physical links deployed within a provider facility. 124 Thus for most services such nodes and links could be considered 125 sufficiently reliable that they do not need be protected at LSP 126 level. 128 A subset of LSP may require extremely high availability. Commonly 129 cited examples include communications among emergency first 130 responders (police, fire, etc) and application for which loss of 131 connectivity may result in large financial losses (financial 132 services, e-commerce, trading). These services may require 133 protection against Shared Risk Link Group (SRLG) which would be 134 expected to cause failure in extremely rare circumstances. This same 135 high level of protection is unnecessary for most services. 137 In order to provide different levels of local protection for 138 different kinds of services, a more flexible TE FRR mechanism is 139 required. Resource classes and resource class affinity are proposed 140 to address this. 142 3. TE FRR Resource Class Overview 144 To support different levels of local protection, a classification of 145 node and link reliability is defined. This information is carried in 146 the TE link state database (TED). A classification may be associated 147 with a node, a link, or an SRLG. Extensions are defined for OSPF-TE 148 and ISIS-TE. 150 To support a decision at the point of local repair (PLR), an 151 extension is defined for RSVP-TE. The requirements of a specific LSP 152 is defined in the RSVP-TE PATH message. The requirements are 153 expressed as changes from a default behavior. 155 3.1. Setting Default Behavior 157 Signaling can be reduced by configuring a default behavior at 158 potential PLR. If the majority of services do not require protection 159 from relatively reliable nodes and/or links, setting configured 160 defaults to this behavior allows a small reduction in the size of 161 RSVP-TE PATH messages. 163 Using a new TLV to define SRLG which are disabled by default can 164 improve backward compatibility with respect to legacy PLR in cases 165 where it is preferred that these legacy PLR ignore these low 166 probability SRLG for all LSP. Using the SRLG extensions understood 167 by the legacy PLR allows these PLR to consider low probability SRLG 168 for all LSP, with extension affecting only the PLR implementing this 169 specification. 171 3.2. Backwards Compatibility with Legacy PLR 173 Legacy PLR will ignore distinctions between relatively reliable nodes 174 or links and low probability SRLG and those which are relatively 175 unreliable. These PLRs may choose protection paths which error on 176 the side of providing more protection for some services than is 177 required. At worst, this has an impact on network cost, but still 178 would represent a lower cost than if the extensions were unavailable 179 at all nodes. 181 SRLG can be defined such that legacy PLR either always consider the 182 SRLG or always ignore the SRLG. Only the PLR implementing this 183 specification will be able to selectively apply classes of SRLG on a 184 per LSP basis. 186 3.3. Backwards Compatibility with Legacy Ingress 188 Legacy Ingress will not provide any extensions which allow LSP to be 189 treated differently from the default. In a brownfield installation 190 the defaults can be set to provide the level of protection that had 191 been available. Extensions can then be used by LSR implementing this 192 specification to indicate LSP which require some protection, but less 193 than this default, or more protection than this default. 195 4. TE FRR Resource Class Protocol Extensions 197 This document defines the following extensions. 199 1. new TLVs in OSPF and IS-IS to provide a means of host or link 200 reliability classification. 202 2. new TLVs in OSPF and IS-IS to provide SRLG classification. 204 3. a new alternate SRLG TLV for OSPF and IS-IS to allow definition 205 of SRLG that will be ignored by legacy PLR. 207 4. an extension to RSVP-TE to allow per LSP deviations from default 208 protection to be specified. 210 5. IGP Extensions 212 5.1. OSPF Node Reliability sub-TLV 214 The reliability of a node is specified using a Node Reliability sub- 215 TLV of the Node Attribute TLV [RFC5786]. Length of this sub-TLV is 216 variable. The format is as follows: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | TBD | Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Flags | Node Classification Bit Map | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Zero or more SRNG | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 The type code is TBA for Node Reliability sub-TLV. 230 The length field is set to four plus the number of SRNG included time 231 the size of an SRNG. 233 The Flags field is reserved for future use. 235 The 3-octet Node Classification Bit Map is a bit map which may be 236 used by operator to specify inclusion of the node in a set of 237 operator defined classifications. 239 The format of SRNG is common to OSPF and ISIS and is defined in 240 Section 5.5 242 5.2. OSPF Link Reliability sub-TLV 244 The reliability of link is specified using a Link Reliability sub-TLV 245 of the Link TLV [RFC3630]. Length of this sub-TLV is variable. The 246 format is as follow: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Flags | Link Classification Bit Map | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Zero or more Extended SRLG | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 The Flags field is reserved for future use. 258 The 3 octet Link Classification Bit Map is a bit map which may be 259 used by operator to specify inclusion of the link in a set of 260 operator defined classifications. 262 The format of Extended SRLG is common to OSPF and ISIS and is defined 263 in Section 5.5 265 5.3. IS-IS Node Reliability TLV 267 The reliability of node is specified using a Node Reliability TLV 268 with TLV Type TBA. Length of this TLV is variable. The format is as 269 follows: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | TBD | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Flags | Node Classification Bit Map | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Zero or more SRNG | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 The Flags field is reserved for future use. 283 The 3 octet Node Classification Bit Map is a bit map which may be 284 used by operator to specify inclusion of the node in a set of 285 operator defined classifications. 287 The format of SRNG is common to OSPF and ISIS and is defined in 288 Section 5.5 290 5.4. IS-IS Link Reliability TLV 292 The reliability of link is specified using a Link Reliability sub-TLV 293 of the TLV 22 [RFC5305]. Length of this sub-TLV is variable. The 294 format is as follow: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Flags | Link Classification Bit Map | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Zero or more Extended SRLG | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 The Flags field is reserved for future use. 306 The 3 octet Link Classification Bit Map is a bit map which may be 307 used by operator to specify inclusion of the link in a set of 308 operator defined classifications. 310 The format of Extended SRLG is common to OSPF and ISIS and is defined 311 in Section 5.5 313 5.5. Shared Risk Node Group 315 The Shared Risk Node Group (SRNG) is carried within either the OSPF 316 Node Reliability sub-TLV (see Section 5.1) or the IS-IS Node 317 Reliability TLV (see Section 5.3). The SRNG is 8 bytes. The format 318 is as follow: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Shared Risk Node Group Number | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Flags | SRNG Classification Bit Map | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 The Shared Risk Node Group Number (SRLG) is a 32 bit number used to 329 specify the inclusion of the node within a set of nodes which share a 330 common resource that therefore can be expected to fail simultaneously 331 if that resource becomes unavailable. The SRLG is a operator 332 assigned number which identified the resource. 334 The Flags field is reserved for future use. 336 The 3-octet SRNG Classification Bit Map is a bit map which may be 337 used by operator to specify inclusion of the SRNG in a set of 338 operator defined classifications. 340 5.6. Extended Shared Risk Link Group 342 The Extended Shared Risk Link Group (ESRLG) is carried within either 343 the OSPF Link Reliability sub-TLV (see Section 5.2) or the IS-IS Link 344 Reliability TLV (see Section 5.4). The ESRLG is 8 bytes. The format 345 is as follow: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Extended Shared Risk Link Group Number | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Flags | SRLG Classification Bit Map | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 The Extended Shared Risk Link Group Number (ESRLG) is a 32 bit number 356 used to specify the inclusion of the link within a set of links which 357 share a common resource that therefore can be expected to fail 358 simultaneously if that resource becomes unavailable. The SRLG is a 359 operator assigned number which identified the resource. 361 The Flags field is reserved for future use. 363 The 3-octet SRLG Classification Bit Map is a bit map which may be 364 used by operator to specify inclusion of the SRLG in a set of 365 operator defined classifications. 367 The Extended Shared Risk Link Group Number (ESRLG) may be given the 368 same number as an advertised SRLG when the desired behavior for 369 legacy PLR is to have the legacy PLR always protect against failure 370 of the ESRLG. If the desired behavior for legacy PLR is to have the 371 legacy PLR never protect against failure of the ESRLG, then the ESRLG 372 number must not conflict with an SRLG number. 374 6. RSVP-TE Extensions 376 6.1. Resource Attribute Bit Mask 378 The Resource Attribute Bit Mask is defined in LSP_ATRTRIBUTE Object. 379 The LSP_ATRTRIBUTE is defined in [RFC5420]. The format of the 380 Resource Attribute Bit Mask is as follows: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | TBD | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | OP| Ap| Resv | Resource Attribute Bit Mask | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 The 2 bit Operation field (OP) specifies one of the following 391 operations. The following values are defined for the Operation 392 field. 394 00 Include if any set 396 01 Include if all set 398 10 Exclude if any set 400 11 Exclude if all set 402 The 2 bit Apply field (Ap) is a bit map which indicates which context 403 the bit mask is applied to. The following values are defined for the 404 Apply field. 406 00 Apply the mask to Node Reliability values 407 01 Apply the mask to Link Reliability values 409 10 Apply the mask to SRNG Reliability values 411 11 Apply the mask to ESRLG Reliability values 413 The 3-octet Resource Attribute Bit Mask is a bit mask applied to the 414 3-octet resource classifications specified for nodes, links, SRNG, or 415 ESRLG. The Apply field indicates which type of resource 416 classification to apply the mask to. The Operation field indicates 417 what action to take as a result of the mask operation. 419 7. Protocol Actions 421 The Node Reliability and Link Reliability are assigned to nodes and 422 links according to configuration on the LSR advertising the 423 containing TLV. The Resource Attribute Bit Mask is assigned 424 according to configuration on the ingress LSR for a given LSP. 426 The action taken at a PLR for a given LSP are as follows. 428 If no protection is required, as indicated by the "protection 429 desired" bit in the RSVP-TE Flags SESSION_ATTRIBUTE [RFC3209] not 430 being set, then no protection path is created at a potential PLR. 431 This behavior is unchanged. 433 If link disjoint protection if required, as indicated by the 434 "protection desired" bit set and the "Node protection desired" bit 435 not set [RFC4090], then protection path SHOULD NOT be established for 436 links which are included as a result of applying the Resource 437 Attribute Bit Masks for the LSP to the Link Classification Bit Map of 438 the link, then for links which need local protection, the protection 439 paths must be disjoint with respect to all SRLGs and ESRLGs included, 440 except SRLGs excluded as a result of applying the Resource Attribute 441 Bit Masks for the LSP to the SRLG Classification Bit Map. 443 If node disjoint protection if required, as indicated by the 444 "protection desired" bit set and the "Node protection desired" bit 445 set, then protection path SHOULD not be established for nodes or 446 links which are included as a result of applying the corresponding 447 Resource Attribute Bit Masks for the LSP to the Node Classification 448 Bit Map of the node or Link Classification Bit Map of the link. Then 449 for nodes and links which need local protection, the protection paths 450 must be disjoint with respect to all SRLG, SRNG and ESRLG included, 451 except SRNG and SRLG excluded as a result of applying the 452 corresponding Resource Attribute Bit Masks for the LSP to the SRNG 453 Classification Bit Map and the SRLG Classification Bit Map 454 respectively. 456 The action taken in the absence of any Resource Attribute Bit Masks 457 in all cases is identical to the action that would be taken by a 458 legacy PLR. Inclusion of one or more Resource Attribute Bit Mask 459 modifies this behavior. 461 8. To Be Completed 463 An LSP may have many Resource Attribute Bit Masks. It may be more 464 efficient to define a container for the Resource Attribute Bit Masks 465 and include that container in the LSP_ATTRIBUTES. Whether to use 466 such a container rather than include multiple Resource Attribute Bit 467 Masks directly in the LSP_ATTRIBUTES is up for discussion. 469 9. IANA Considerations 471 9.1. OSPF 473 The registry for the Node Attribute TLV is defined in [RFC5786]. 474 IANA is requested to assign a new sub-TLV codepoint for the Node 475 Reliability sub-TLV carried in the Node Attribute TLV. 477 Value Sub-TLV Reference 478 ----- ------- --------- 479 TBA Node Reliability sub-TLV this document 481 The registry for the Link TLV is defined in [RFC3630]. IANA is 482 requested to assign a new sub-TLV codepoint for the Link Reliability 483 sub-TLV carried in the Link TLV. 485 Value Sub-TLV Reference 486 ----- ------- --------- 487 TBA Link Reliability sub-TLV this document 489 9.2. IS-IS 491 IANA is requested to assign a new TLV codepoint for Node Reliability 492 TLV. 494 Type TLV Reference 495 ----- ------- --------- 496 TBA Node Reliability sub-TLV this document 498 The registry for TLV 22 is defined in [RFC5305]. IANA is requested 499 to assign a new sub-TLV codepoint for the Link Reliability sub-TLV 500 which is carried in TLV 22. 502 Value Sub-TLV Reference 503 ----- ------- --------- 504 TBA Link Reliability sub-TLV this document 506 9.3. RSVP-TE 508 IANA is requested to assign a new type codepoint for the "Resource 509 Attribute Bit Mask" TLV in the Attribute TLV Space. It is carried in 510 the LSP_ATTRIBUTES object (class = 197, C-Type = 1). 512 Type: TBA 513 Name: Resource Attribute Bit Mask 514 Allowed on LSP_ATTRIBUTES: Yes 515 Allowed on LSP_REQUIRED_ATTRIBUTES: No 517 10. Security Considerations 519 The function described in this document does not create any new 520 security issues for the OSPF and IS-IS protocols and does not 521 introduce any new security issues above those identified in [RFC3209] 522 and [RFC4090]. 524 11. Acknowledgements 526 TBD 528 12. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 534 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 535 Tunnels", RFC 3209, December 2001. 537 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 538 (TE) Extensions to OSPF Version 2", RFC 3630, 539 September 2003. 541 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 542 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 543 May 2005. 545 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 546 Engineering", RFC 5305, October 2008. 548 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 549 Ayyangarps, "Encoding of Attributes for MPLS LSP 550 Establishment Using Resource Reservation Protocol Traffic 551 Engineering (RSVP-TE)", RFC 5420, February 2009. 553 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 554 Local Addresses in OSPF Traffic Engineering (TE) 555 Extensions", RFC 5786, March 2010. 557 Authors' Addresses 559 Jie Dong 560 Huawei Technologies 561 Huawei Building, No.156 Beiqing Rd 562 Beijing 100095 563 China 565 Email: jie.dong@huawei.com 567 Mach Chen 568 Huawei Technologies 569 Huawei Building, No.156 Beiqing Rd 570 Beijing 100095 571 China 573 Email: mach.chen@huawei.com 575 Curtis Villamizar 576 OCCNC, LLC 578 Email: curtis@occnc.com