idnits 2.17.1 draft-ietf-teas-rsvp-te-srlg-collect-07.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 (August 16, 2016) is 2808 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 TEAS Working Group F. Zhang, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires February 16, 2017 Telefonica Global CTO 6 M. Hartley 7 Z. Ali 8 Cisco 9 C. Margaria 11 August 16, 2016 13 RSVP-TE Extensions for Collecting SRLG Information 14 draft-ietf-teas-rsvp-te-srlg-collect-07 16 Abstract 18 This document provides extensions for the Resource ReserVation 19 Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support 20 automatic collection of Shared Risk Link Group (SRLG) information for 21 the TE link formed by a Label Switched Path (LSP). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 26, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Applicability Example: Dual Homing . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 60 3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. SRLG Collection Indication . . . . . . . . . . . . . . . . 5 62 3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.4. SRLG ID definition . . . . . . . . . . . . . . . . . . . . 6 65 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6 67 4.2. RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . 6 68 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10 72 5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Manageability Considerations . . . . . . . . . . . . . . . . . 10 74 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11 75 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 11 79 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12 80 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 12 81 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 It is important to understand which Traffic Engineering (TE) links in 91 the network might be at risk from the same failures. In this sense, 92 a set of links can constitute a 'shared risk link group' (SRLG) if 93 they share a resource whose failure can affect all links in the set 94 [RFC4202]. 96 On the other hand, as described in [RFC4206] and [RFC6107], H-LSP 97 (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying 98 one or more other LSPs. Both of the H-LSP and S-LSP can be formed as 99 a TE link. In such cases, it is important to know the SRLG 100 information of the LSPs that will be used to carry further LSPs. 102 This document provides a signaling mechanism to collect the SRLGs 103 used by a LSP, which can then be advertized as properties of the TE- 104 link formed by that LSP. 106 1.1. Applicability Example: Dual Homing 108 An interesting use case for the SRLG collection procedures defined in 109 this document is achieving LSP diversity in a dual homing scenario. 110 The use case is illustrated in Figure 1, when the overlay model is 111 applied as defined in RFC 4208 [RFC4208] . In this example, the 112 exchange of routing information over the User-Network Interface (UNI) 113 is prohibited by operator policy. 115 +---+ +---+ 116 | P |....| P | 117 +---+ +---+ 118 / \ 119 +-----+ +-----+ 120 +---+ | PE1 | | PE3 | +---+ 121 |CE1|----| | | |----|CE2| 122 +---+\ +-----+ +-----+ /+---+ 123 \ | | / 124 \ +-----+ +-----+ / 125 \| PE2 | | PE4 |/ 126 | | | | 127 +-----+ +-----+ 128 \ / 129 +---+ +---+ 130 | P |....| P | 131 +---+ +---+ 133 Figure 1: Dual Homing Configuration 135 Single-homed customer edge (CE) devices are connected to a single 136 provider edge (PE) device via a single UNI link (which could be a 137 bundle of parallel links, typically using the same fiber cable). This 138 single UNI link can constitute a single point of failure. Such a 139 single point of failure can be avoided if the CE device is connected 140 to two PE devices via two UNI interfaces as depicted in Figure 1 141 above for CE1 and CE2, respectively. 143 For the dual-homing case, it is possible to establish two connections 144 (LSPs) from the source CE device to the same destination CE device 145 where one connection is using one UNI link to PE1, for example, and 146 the other connection is using the UNI link to PE2. In order to avoid 147 single points of failure within the provider network, it is necessary 148 to also ensure path (LSP) diversity within the provider network in 149 order to achieve end-to-end diversity for the two LSPs between the 150 two CE devices CE1 and CE2. This use case describes how it is 151 possible to achieve path diversity within the provider network based 152 on collected SRLG information. As the two connections (LSPs) enter 153 the provider network at different PE devices, the PE device that 154 receives the connection request for the second connection needs to 155 know the additional path computation constraints such that the path 156 of the second LSP is disjoint with respect to the already established 157 first connection. 159 As SRLG information is normally not shared between the provider 160 network and the client network, i.e., between PE and CE devices, the 161 challenge is how to solve the diversity problem when a CE is dual- 162 homed. The RSVP extensions for collecting SRLG information defined 163 in this document make it possible to retrieve SRLG information for an 164 LSP and hence solve the dual-homing LSP diversity problem. For 165 example, CE1 in Figure 1 may have requested an LSP1 to CE2 via PE1 166 that is routed via PE3 to CE2. CE1 can then subsequently request an 167 LSP2 to CE2 via PE2 with the constraint that it needs to be maximally 168 SRLG disjoint with respect to LSP1. PE2, however, does not have any 169 SRLG information associated with LSP1, which is needed as input for 170 its constraint-based path computation function. If CE1 is capable of 171 retrieving the SRLG information associated with LSP1 from PE1, it can 172 pass this discovered information to PE2 as part of the LSP2 setup 173 request (RSVP PATH message) in an EXCLUDE_ROUTE Object (XRO) or 174 Explicit Exclusion Route Subobject (EXRS) as described in [RFC4874], 175 and PE2 can now calculate a path for LSP2 that is SRLG disjoint with 176 respect to LSP1. The SRLG information associated with LSP1 can be 177 retrieved when LSP1 is established or at any time before LSP2 is 178 setup. 180 When CE1 sends the setup request for LSP2 to PE2, it can also request 181 the collection of SRLG information for LSP2 and send that information 182 to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's 183 discovered SRLGs. This will ensure that the two paths for the two 184 LSPs remain mutually diverse, which is important when the provider 185 network is capable of restoring connections that failed due to a 186 network failure (fiber cut) in the provider network. 188 Note that the knowledge of SRLG information even for multiple LSPs 189 does not allow a CE device to derive the provider network topology 190 based on the collected SRLG information. It would, however, be 191 possible for an entity controlling multiple CE devices to derive some 192 information related to the topology. This document therefore allows 193 PE devices to control the communication of SRLGs outside the provider 194 network if desired. 196 2. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC 2119 [RFC2119]. 202 3. RSVP-TE Requirements 204 The SRLG-collection process takes place in three stages: 206 o The LSP's ingress node requests that SRLG collection take place; 208 o SRLG data is added to the Path and Resv ROUTE_RECORD Objects 209 (RROs) by all nodes during signaling; 211 o Changes to previously-signaled SRLG data are made by sending 212 updated Path and Resv messages as required. 214 3.1. SRLG Collection Indication 216 The ingress node of the LSP needs be capable of indicating whether 217 the SRLG information of the LSP is to be collected during the 218 signaling procedure of setting up an LSP. There is no need for SRLG 219 information to be collected without an explicit request for it being 220 made by the ingress node. 222 It may be preferable for the SRLG collection request to be understood 223 by all nodes along the LSP's path, or it may be more important for 224 the LSP to be established successfully even if it traverses nodes 225 that cannot supply SRLG information or have not implemented the 226 procedures specified in this document. It is desirable for the 227 ingress node to make the SRLG collection request in a manner that 228 best suits its own policy. 230 3.2. SRLG Collection 232 If requested, the SRLG information is collected during the setup of 233 an LSP. SRLG information is added by each hop to the Path RRO during 234 Path message processing. The same information is also added to the 235 Resv RRO during Resv processing at each hop. 237 3.3. SRLG Update 238 When the SRLG information of an existing LSP for which SRLG 239 information was collected during signaling changes, the relevant 240 nodes of the LSP need to be capable of updating the SRLG information 241 of the LSP. This means that the signaling procedure needs to be 242 capable of updating the new SRLG information. 244 3.4. SRLG ID definition 246 The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity 247 in [RFC4202]. This definition is used in this document. 249 4. Encodings 251 4.1. SRLG Collection Flag 253 In order to indicate to nodes that SRLG collection is desired, this 254 document defines a new flag in the Attribute Flags TLV (see RFC 5420 255 [RFC5420]). This document defines a new SRLG collection flag in the 256 Attribute Flags TLV (see RFC 5420 [RFC5420]). A node that wishes to 257 indicate that SRLG collection is desired MUST set this flag in an 258 Attribute Flags TLV in an LSP_REQUIRED_ATTRIBUTES Object if 259 collection is to be mandatory, or an LSP_ATTRIBUTES Object if 260 collection is desired but not mandatory. 262 o Bit Number (specified in Section 8.1): SRLG Collection flag 264 The SRLG Collection flag is meaningful on a Path message. If the 265 SRLG Collection flag is set to 1, it means that the SRLG information 266 SHOULD be reported to the ingress and egress node along the setup of 267 the LSP. 269 The rules for the processing of the Attribute Flags TLV are not 270 changed. 272 4.2. RRO SRLG sub-object 274 This document defines a new RRO sub-object (ROUTE_RECORD sub-object) 275 to record the SRLG information of the LSP. Its format is modeled on 276 the RRO sub-objects defined in RFC 3209 [RFC3209]. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Length |D| Reserved | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | SRLG ID 1 (4 octets) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 ~ ...... ~ 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | SRLG ID n (4 octets) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Type (8 bits) 292 The type of the sub-object. The value is specified in Section 8.2. 294 Length (8 bits) 296 The Length field contains the total length of the sub-object in 297 octets, including the Type and Length fields. The Length depends on 298 the number of SRLG IDs. 300 Direction bit (D-bit) (1 bit) 302 If not set, the SRLGs contained in this sub-object apply to the 303 downstream direction. If set, they apply to the upstream direction. 305 Reserved (15 bits) 307 This 15-bit field is reserved. It SHOULD be set to zero on 308 transmission and MUST be ignored on receipt. 310 SRLG ID (4 octets) 312 This field contains one SRLG ID. There is one SRLG ID field per SRLG 313 collected. There MAY be multiple SRLG ID fields in an SRLG sub- 314 object. 316 A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without 317 also pushing either a IPv4 sub-object, a IPv6 sub-object, a 318 Unnumbered Interface ID sub-object or a Path Key sub-object. 320 As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is 321 managed as a stack. The SRLG sub-object MUST be pushed by the node 322 before the node IP address or link identifier. The SRLG-sub-object 323 SHOULD be pushed after the Attribute sub-object, if present, and 324 after the LABEL sub-object, if requested. It MUST be pushed within 325 the hop to which it applies. 327 RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub- 328 object) in the RRO so as to facilitate confidentiality in the 329 signaling of inter-domain TE LSPs, and allows the path segment that 330 needs to be hidden (that is, a Confidential Path Segment (CPS)) to be 331 replaced in the RRO with a PKS. If the CPS contains SRLG Sub- 332 objects, these MAY be retained in the RRO by adding them again after 333 the PKS Sub-object in the RRO. The CPS is defined in RFC 5520 334 [RFC5520]. 336 The rules for the processing of the LSP_REQUIRED_ATTRIBUTES, 337 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 339 5. Signaling Procedures 341 The ingress node of the LSP MUST be capable of indicating whether the 342 SRLG information of the LSP is to be collected during the signaling 343 procedure of setting up an LSP. 345 5.1. SRLG Collection 347 Per RFC 3209 [RFC3209], an ingress node initiates the recording of 348 the route information of an LSP by adding a RRO to a Path message. If 349 an ingress node also desires SRLG recording, it MUST set the SRLG 350 Collection Flag in the Attribute Flags TLV which MAY be carried 351 either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 352 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 353 desired, but not mandatory. 355 A node MUST NOT add SRLG information without an explicit request for 356 it being made by the ingress node in the Path message. 358 When a node receives a Path message which carries an 359 LSP_REQUIRED_ATTRIBUTES Object with the SRLG Collection Flag set, if 360 local policy determines that the SRLG information is not to be 361 provided to the endpoints, it MUST return a PathErr message with: 362 o Error Code 2 (policy) and 363 o Error subcode "SRLG Recording Rejected" (see Section 8.3 for 364 value) 365 to reject the Path message. 367 When a node receives a Path message which carries an LSP_ATTRIBUTES 368 Object with the SRLG Collection Flag set, if local policy determines 369 that the SRLG information is not to be provided to the endpoints, the 370 Path message MUST NOT be rejected due to the SRLG recording 371 restriction and the Path message MUST be forwarded without any SRLG 372 sub-object(s) added to the RRO of the corresponding outgoing Path 373 message. 375 If local policy permits the recording of the SRLG information, the 376 processing node SHOULD add local SRLG information, as defined below, 377 to the RRO of the corresponding outgoing Path message. The 378 processing node MAY add multiple SRLG sub-objects to the RRO if 379 necessary. It then forwards the Path message to the next node in the 380 downstream direction. The processing node MUST retain a record of the 381 SRLG recording request for reference during Resv processing described 382 below. 384 If the addition of SRLG information to the RRO would result in the 385 RRO exceeding its maximum possible size or becoming too large for the 386 Path message to contain it, the requested SRLGs MUST NOT be added. If 387 the SRLG collection request was contained in an 388 LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as 389 specified by RFC 3209 [RFC3209] and drop the RRO from the Path 390 message entirely. If the SRLG collection request was contained in an 391 LSP_ATTRIBUTES Object, the processing node MAY omit some or all of 392 the requested SRLGs from the RRO; otherwise it MUST behave as 393 specified by [RFC3209] and drop the RRO from the Path message 394 entirely. Subsequent processing of the LSP proceeds as further 395 specified in RFC 3209 [RFC3209]. 397 Following the steps described above, the intermediate nodes of the 398 LSP can collect the SRLG information in the RRO during the processing 399 of the Path message hop by hop. When the Path message arrives at the 400 egress node, the egress node receives SRLG information in the RRO. 402 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 403 message which contains an RRO, an egress node initiates the RRO 404 process by adding an RRO to the outgoing Resv message. The 405 processing for RROs contained in Resv messages then mirrors that of 406 the Path messages. 408 When a node receives a Resv message for an LSP for which SRLG 409 Collection was specified in the corresponding Path message, then when 410 local policy allows recording SRLG information, the node MUST add 411 SRLG information to the RRO of the corresponding outgoing Resv 412 message as specified below. When the Resv message arrives at the 413 ingress node, the ingress node can extract the SRLG information from 414 the RRO in the same way as the egress node. 416 Note that a link's SRLG information for the upstream direction cannot 417 be assumed to be the same as that in the downstream. 419 o For Path and Resv messages for a unidirectional LSP, a node SHOULD 420 include SRLG sub-objects in the RRO for the downstream data link 421 only. 423 o For Path and Resv messages for a bidirectional LSP, a node SHOULD 424 include SRLG sub-objects in the RRO for both the upstream data 425 link and the downstream data link from the local node. In this 426 case, the node MUST include the information in the same order for 427 both Path messages and Resv messages. That is, the SRLG sub- 428 object for the upstream link is added to the RRO before the SRLG 429 sub-object for the downstream link. 431 If SRLG data is added for both the upstream and downstream links, 432 the two sets of SRLG data MUST be added in separate SRLG sub- 433 objects. A single SRLG sub-object MUST NOT contain a mixture of 434 upstream and downstream SRLGs. When adding a SRLG sub-object to an 435 RRO, the D-bit MUST be set appropriately to indicate the direction 436 of the SRLGs. If an SRLG ID applies in both directions, it SHOULD 437 be added to both the upstream and downstream SRLG sub-objects. 439 Based on the above procedure, the endpoints can get the SRLG 440 information automatically. Then the endpoints can for instance 441 advertise it as a TE link to the routing instance based on the 442 procedure described in [RFC6107] and configure the SRLG information 443 of the Forwarding Adjacency (FA) automatically. 445 5.2. SRLG Update 447 When the SRLG information of a link is changed, the endpoints of LSPs 448 using that link need to be made aware of the changes. When a change 449 to the set of SRLGs associated with a link occurs, the procedures 450 defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to 451 refresh the SRLG information for each affected LSP if the SRLG change 452 is to be communicated to other nodes according to the local node's 453 policy. 455 5.3 Domain Boundaries 457 If mandated by local policy as specified by the network operator, a 458 node MAY remove SRLG information from any RRO in a Path or Resv 459 message being processed. It MAY add a summary of the removed SRLGs or 460 map them to other SRLG values. However, this SHOULD NOT be done 461 unless explicitly mandated by local policy. 463 5.4. Compatibility 465 A node that does not recognize the SRLG Collection Flag in the 466 Attribute Flags TLV is expected to proceed as specified in RFC 5420 467 [RFC5420]. It is expected to pass the TLV on unaltered if it appears 468 in a LSP_ATTRIBUTES object, or reject the Path message with the 469 appropriate Error Code and Value if it appears in a 470 LSP_REQUIRED_ATTRIBUTES object. 472 A node that does not recognize the SRLG RRO sub-object is expected to 473 behave as specified in RFC 3209 [RFC3209]: unrecognized sub-objects 474 are to be ignored and passed on unchanged. 476 6. Manageability Considerations 477 6.1. Policy Configuration 479 In a border node of inter-domain or inter-layer network, the 480 following SRLG processing policy MUST be capable of being configured: 482 o Whether the node is allowed to participate in SRLG collection and 483 notify changes to collected SRLG information to endpoint nodes as 484 described in section 5.2. 486 o Whether the SRLG IDs of the domain or specific layer network can 487 be exposed to the nodes outside the domain or layer network, or 488 whether they SHOULD be summarized, mapped to values that are 489 comprehensible to nodes outside the domain or layer network, or 490 removed entirely as described in section 5.3. 492 A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy. 494 6.2. Coherent SRLG IDs 496 In a multi-layer multi-domain scenario, SRLG IDs can be configured by 497 different management entities in each layer/domain. In such 498 scenarios, maintaining a coherent set of SRLG IDs is a key 499 requirement in order to be able to use the SRLG information properly. 500 Thus, SRLG IDs SHOULD be unique. Note that current procedure is 501 targeted towards a scenario where the different layers and domains 502 belong to the same operator, or to several coordinated administrative 503 groups. Ensuring the aforementioned coherence of SRLG IDs is beyond 504 the scope of this document. 506 Further scenarios, where coherence in the SRLG IDs cannot be 507 guaranteed are out of the scope of the present document and are left 508 for further study. 510 7. Security Considerations 512 This document builds on the mechanisms defined in [RFC3473], which 513 also discusses related security measures. In addition, [RFC5920] 514 provides an overview of security vulnerabilities and protection 515 mechanisms for the GMPLS control plane. The procedures defined in 516 this document permit the transfer of SRLG data between layers or 517 domains during the signaling of LSPs, subject to policy at the layer 518 or domain boundary. It is recommended that domain/layer boundary 519 policies take the implications of releasing SRLG information into 520 consideration and behave accordingly during LSP signaling. 522 8. IANA Considerations 524 8.1. RSVP Attribute Bit Flags 525 IANA has created a registry and manages the space of the Attribute 526 bit flags of the Attribute Flags TLV, as described in section 11.3 of 527 RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource 528 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" 529 registry located in http://www.iana.org/assignments/rsvp-te- 530 parameters". 532 This document introduces a new Attribute Bit Flag: 534 Bit No Name Attribute Attribute ERO RRO Reference 535 Flags Path Flags Resv 536 --------- ---------- ---------- ----------- --- --- --------- 537 TBD; SRLG Yes No No Yes This I-D 538 suggested Collection 539 value: 12 Flag 541 8.2. ROUTE_RECORD Object 543 IANA manages the "RSVP PARAMETERS" registry located at 544 http://www.iana.org/assignments/rsvp-parameters. This document 545 introduces a new RRO sub-object: 547 Value Description Reference 548 --------------------- ------------------- --------- 549 TBD; suggested SRLG sub-object This I-D 550 value: 34 552 8.3. Policy Control Failure Error subcodes 554 IANA manages the assignments in the "Error Codes and Globally-Defined 555 Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry 556 located at http://www.iana.org/assignments/rsvp-parameters. 558 This document introduces a new Policy Control Failure Error sub-code: 560 Value Description Reference 561 --------------------- ----------------------- --------- 562 TBD; suggested SRLG Recording Rejected This I-D 563 value: 21 565 9. Contributors 567 Dan Li 568 Huawei 569 F3-5-B RD Center 570 Bantian, Longgang District, Shenzhen 518129 571 P.R.China 572 Email: danli@huawei.com 574 10. Acknowledgements 576 The authors would like to thank Dieter Beller, Vishnu Pavan Beeram, 577 Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas 578 Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah and 579 Xian Zhang for their useful comments and improvements to this 580 document. 582 11. References 584 11.1. Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 590 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 591 Tunnels", RFC 3209, December 2001. 593 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 594 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 595 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 597 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 598 Support of Generalized Multi-Protocol Label Switching 599 (GMPLS)", RFC 4202, October 2005. 601 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 602 Ayyangarps, "Encoding of Attributes for MPLS LSP 603 Establishment Using Resource Reservation Protocol Traffic 604 Engineering (RSVP-TE)", RFC 5420, February 2009. 606 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 607 Topology Confidentiality in Inter-Domain Path Computation 608 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 610 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 611 Reservation Protocol (RSVP) Extensions for Path Key 612 Support", RFC 5553, May 2009. 614 11.2. Informative References 616 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 617 Hierarchy with Generalized Multi-Protocol Label Switching 618 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 620 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 621 "Generalized Multiprotocol Label Switching (GMPLS) User- 622 Network Interface (UNI): Resource ReserVation Protocol- 623 Traffic Engineering (RSVP-TE) Support for the Overlay 624 Model", RFC 4208, October 2005. 626 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 627 Extension to Resource ReserVation Protocol-Traffic 628 Engineering (RSVP-TE)", RFC 4874, April 2007. 630 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 631 Networks", RFC 5920, July 2010. 633 [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically 634 Signaled Hierarchical Label Switched Paths", RFC 6107, 635 February 2011. 637 Authors' Addresses 639 Fatai Zhang (editor) 640 Huawei 641 F3-5-B RD Center 642 Bantian, Longgang District, Shenzhen 518129 643 P.R.China 644 Email: zhangfatai@huawei.com 646 Oscar Gonzalez de Dios (editor) 647 Telefonica Global CTO 648 Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 649 Madrid 28050 650 Spain 651 Phone: +34 913129647 652 Email: oscar.gonzalezdedios@telefonica.com 654 Cyril Margaria 655 Suite 4001, 200 Somerset Corporate Blvd. 656 Bridgewater, NJ 08807 657 US 658 Email: cyril.margaria@gmail.com 660 Matt Hartley 661 Cisco 662 Email: mhartley@cisco.com 663 Zafar Ali 664 Cisco 665 Email: zali@cisco.com