idnits 2.17.1 draft-ietf-ccamp-rsvp-te-srlg-collect-06.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 (July 31, 2014) is 3557 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 Network Working Group F. Zhang, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires: February 1, 2015 Telefonica Global CTO 6 D. Li 7 Huawei 8 C. Margaria 10 M. Hartley 11 Z. Ali 12 Cisco 13 July 31, 2014 15 RSVP-TE Extensions for Collecting SRLG Information 16 draft-ietf-ccamp-rsvp-te-srlg-collect-06 18 Abstract 20 This document provides extensions for the Resource ReserVation 21 Protocol-Traffic Engineering (RSVP-TE) to support automatic 22 collection of Shared Risk Link Group (SRLG) Information for the TE 23 link formed by a LSP. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 1, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 3 62 3.1. SRLG Collection Indication . . . . . . . . . . . . . . . 3 63 3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 3 64 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 3 67 4.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 4 68 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 5 69 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5 70 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Manageability Considerations . . . . . . . . . . . . . . . . 7 73 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 7 74 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 7 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 8 78 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 8 79 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 9 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 10.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 It is important to understand which TE links in the network might be 89 at risk from the same failures. In this sense, a set of links may 90 constitute a 'shared risk link group' (SRLG) if they share a resource 91 whose failure may affect all links in the set [RFC4202]. 93 On the other hand, as described in [RFC4206] and [RFC6107], H-LSP 94 (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying 95 one or more other LSPs. Both of the H-LSP and S-LSP can be formed as 96 a TE link. In such cases, it is important to know the SRLG 97 information of the LSPs that will be used to carry further LSPs. 99 This document provides an automatic mechanism to collect the SRLG for 100 the TE link formed by a LSP. Note that how to use the collected SRLG 101 information is out of scope of this document 103 2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. RSVP-TE Requirements 111 3.1. SRLG Collection Indication 113 The ingress nodes of the LSP must be capable of indicating whether 114 the SRLG information of the LSP should be collected during the 115 signaling procedure of setting up an LSP. SRLG information SHOULD 116 NOT be collected without an explicit request for it being made by the 117 ingress node. 119 3.2. SRLG Collection 121 If requested, the SRLG information should be collected during the 122 setup of an LSP. The endpoints of the LSP may use the collected SRLG 123 information and use it for routing, sharing and TE link configuration 124 purposes. 126 3.3. SRLG Update 128 When the SRLG information of an existing LSP for which SRLG 129 information was collected during signaling changes, the relevant 130 nodes of the LSP must be capable of updating the SRLG information of 131 the LSP. This means that that the signaling procedure must be 132 capable of updating the new SRLG information. 134 4. Encodings 136 4.1. SRLG Collection Flag 138 In order to indicate nodes that SRLG collection is desired, this 139 document defines a new flag in the Attribute Flags TLV, which is 140 carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTE Object: 142 o Bit Number (to be assigned by IANA, recommended bit 12): SRLG 143 Collection flag 145 The SRLG Collection flag is meaningful on a Path message. If the 146 SRLG Collection flag is set to 1, it means that the SRLG information 147 should be reported to the ingress and egress node along the setup of 148 the LSP. 150 The rules of the processing of the Attribute Flags TLV are not 151 changed. 153 4.2. SRLG sub-object 155 This document defines a new RRO sub-object (ROUTE_RECORD sub-object) 156 to record the SRLG information of the LSP. Its format is modeled on 157 the RRO sub-objects defined in RFC 3209 [RFC3209]. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Length | Reserved | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | SRLG ID 1 (4 bytes) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ~ ...... ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | SRLG ID n (4 bytes) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type 173 The type of the sub-object, to be assigned by IANA, which is 174 recommended 34. 176 Length 178 The Length field contains the total length of the sub-object in 179 bytes, including the Type and Length fields. The Length depends on 180 the number of SRLG IDs. 182 Reserved 184 This 2 byte field is reserved. It SHOULD be set to zero on 185 transmission and MUST be ignored on receipt. 187 SRLG ID 189 This 4 byte field contains one SRLG ID. There is one SRLG ID field 190 per SRLG collected. 192 As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is 193 managed as a stack. The SRLG sub-object SHOULD be pushed by the node 194 before the node IP address or link identifier. The SRLG-sub-object 195 SHOULD be pushed after the Attribute subobject, if present, and after 196 the LABEL subobject, if requested. 198 A node MUST NOT push a SRLG subobject in the RECORD_ROUTE without 199 also pushing a IPv4, IPv6 or Unnumbered Interface ID sub-object. 201 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 202 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 204 5. Signaling Procedures 206 5.1. SRLG Collection 208 Per RFC 3209 [RFC3209], an ingress node initiates the recording of 209 the route information of an LSP by adding a RRO to a Path message. 210 If an ingress node also desires SRLG recording, it MUST set the SRLG 211 Collection Flag in the Attribute Flags TLV which MAY be carried 212 either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 213 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 214 desired, but not mandatory 216 When a node receives a Path message which carries an 217 LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag set, if 218 local policy determines that the SRLG information is not to be 219 provided to the endpoints, it MUST return a PathErr message with 220 Error Code 2 (policy) and Error subcode "SRLG Recording Rejected" 221 (value to be assigned by IANA, suggest value 108) to reject the Path 222 message. 224 When a node receives a Path message which carries an LSP_ATTRIBUTES 225 Object and the SRLG Collection Flag set, if local policy determines 226 that the SRLG information is not to be provided to the endpoints, the 227 Path message SHOULD NOT be rejected due to SRLG recording restriction 228 and the Path message SHOULD be forwarded without any SRLG sub- 229 object(s) in the RRO of the corresponding outgoing Path message. 231 If local policy permits the recording of the SRLG information, the 232 processing node SHOULD add local SRLG information, as defined below, 233 to the RRO of the corresponding outgoing Path message. It then 234 forwards the Path message to the next node in the downstream 235 direction. 237 Following the steps described above, the intermediate nodes of the 238 LSP can collect the SRLG information in the RRO during the processing 239 of the Path message hop by hop. When the Path message arrives at the 240 egress node, the egress node receives SRLG information in the RRO. 242 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 243 message which contains an RRO, an egress node initiates the RRO 244 process by adding an RRO to the outgoing Resv message. The 245 processing for RROs contained in Resv messages then mirrors that of 246 the Path messages. 248 When a node receives a Resv message for an LSP for which SRLG 249 Collection is specified, if local policy determines that the SRLG 250 information is not to be provided to the endpoints, if the SRLG- 251 recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a 252 ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording 253 Rejected" (value to be assigned by IANA, suggest value 108) MUST be 254 sent. If the request was in a LSP_ATTRIBUTES object, then a ResvErr 255 SHOULD NOT be generated, but SRLG information MUST NOT be added in 256 the RRO. When local policy allows recording SRLG information, the 257 node SHOULD add SRLG information, as defined below, to the RRO of the 258 corresponding outgoing Resv message. When the Resv message arrives 259 at the ingress node, the ingress node can get the SRLG information 260 from the RRO in the same way as the egress node. 262 Note that a link's SRLG information for the upstream direction cannot 263 be assumed to be the same as that in the downstream. 265 o For Path and Resv messages for a unidirectional LSP, a node SHOULD 266 include SRLG sub-objects in the RRO for the downstream data link 267 only. 269 o For Path and Resv messages for a bidirectional LSP, a node SHOULD 270 include SRLG sub-objects in the RRO for both the upstream data 271 link and the downstream data link from the local node. In this 272 case, the node MUST include the information in the same order for 273 both Path messages and Resv messages. That is, the SRLG sub- 274 object for the upstream link is added to the RRO before the SRLG 275 sub-object for the downstream link. 277 Based on the above procedure, the endpoints can get the SRLG 278 information automatically. Then the endpoints can for instance 279 advertise it as a TE link to the routing instance based on the 280 procedure described in [RFC6107] and configure the SRLG information 281 of the FA automatically. 283 5.2. SRLG Update 285 When the SRLG information of a link is changed, the LSPs using that 286 link should be aware of the changes. The procedures defined in 287 Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG 288 information if the SRLG change is to be communicated to other nodes 289 according to the local node's policy. If local policy is that the 290 SRLG change should be suppressed or would result in no change to the 291 previously signaled SRLG-list, the node SHOULD NOT send an update. 293 5.3. Compatibility 295 A node that does not recognize the SRLG Collection Flag in the 296 Attribute Flags TLV is expected to proceed as specified in RFC 5420 297 [RFC5420]. It is expected to pass the TLV on unaltered if it appears 298 in a LSP_ATTRIBUTES object, or reject the Path message with the 299 appropriate Error Code and Value if it appears in a 300 LSP_REQUIRED_ATTRIBUTES object. 302 A node that does not recognize the SRLG RRO sub-object is expected to 303 behave as specified in RFC 3209 [RFC3209]: unrecognized subobjects 304 are to be ignored and passed on unchanged. 306 6. Manageability Considerations 308 6.1. Policy Configuration 310 In a border node of inter-domain or inter-layer network, the 311 following SRLG processing policy should be capable of being 312 configured: 314 o Whether the SRLG IDs of the domain or specific layer network can 315 be exposed to the nodes outside the domain or layer network, or 316 whether they should be summarized, mapped to values that are 317 comprehensible to nodes outside the domain or layer network, or 318 removed entirely. 320 6.2. Coherent SRLG IDs 322 In a multi-layer multi-domain scenario, SRLG ids may be configured by 323 different management entities in each layer/domain. In such 324 scenarios, maintaining a coherent set of SRLG IDs is a key 325 requirement in order to be able to use the SRLG information properly. 326 Thus, SRLG IDs must be unique. Note that current procedure is 327 targeted towards a scenario where the different layers and domains 328 belong to the same operator, or to several coordinated administrative 329 groups. Ensuring the aforementioned coherence of SRLG IDs is beyond 330 the scope of this document. 332 Further scenarios, where coherence in the SRLG IDs cannot be 333 guaranteed are out of the scope of the present document and are left 334 for further study. 336 7. Security Considerations 338 This document builds on the mechanisms defined in [RFC3473], which 339 also discusses related security measures. In addition, [RFC5920] 340 provides an overview of security vulnerabilities and protection 341 mechanisms for the GMPLS control plane. The procedures defined in 342 this document permit the transfer of SRLG data between layers or 343 domains during the signaling of LSPs, subject to policy at the layer 344 or domain boundary. It is recommended that domain/layer boundary 345 policies take the implications of releasing SRLG information into 346 consideration and behave accordingly during LSP signaling. 348 8. IANA Considerations 350 8.1. RSVP Attribute Bit Flags 352 IANA has created a registry and manages the space of attributes bit 353 flags of Attribute Flags TLV, as described in section 11.3 of 354 [RFC5420], in the "Attributes TLV Space" section of the "Resource 355 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" 356 registry located in https://www.iana.org/assignments/rsvp-te- 357 parameters/rsvp-te-parameters.xhtml. It is requested that IANA makes 358 assignments from the Attribute Bit Flags. 360 This document introduces a new Attribute Bit Flag: 362 o Bit number: TBD (early allocation requested) 364 o Defining RFC: this I-D 366 o Name of bit: SRLG Collection Flag 368 o The meaning of the SRLG Collection Flag is defined in this I-D. 370 8.2. ROUTE_RECORD Object 372 IANA has made the following assignments in the "Class Names, Class 373 Numbers, and Class Types" section of the "RSVP PARAMETERS" registry 374 located at http://www.iana.org/assignments/rsvp-parameters. We 375 request that IANA make assignments from the ROUTE_RECORD RFC 3209 376 [RFC3209] portions of this registry. 378 This document introduces a new RRO sub-object: 380 Type Name Reference 381 --------- ---------------------- --------- 382 TBD (early SRLG sub-object This I-D 383 allocation 384 requested) 386 8.3. Policy Control Failure Error subcodes 388 IANA has made the following assignments in the "Error Codes and 389 Globally-Defined Error Value Sub-Codes" section of the "RSVP 390 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 391 parameters. We request that IANA make assignments from the Policy 392 Control Failure Sub-Codes registry. 394 This document introduces a new Policy Control Failure Error sub-code: 396 o Error sub-code: TBD (early allocation requested) 398 o Defining RFC: this I-D 400 o Name of error sub-code: SRLG Recording Rejected 402 o The meaning of the SRLG Recording Rejected error sub-code is 403 defined in this I-D 405 9. Acknowledgements 407 The authors would like to thank Igor Bryskin, Ramon Casellas, Lou 408 Berger and Alan Davey for their useful comments and improvements to 409 the document. 411 10. References 413 10.1. Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 419 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 420 Tunnels", RFC 3209, December 2001. 422 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 423 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 424 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 426 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 427 Ayyangarps, "Encoding of Attributes for MPLS LSP 428 Establishment Using Resource Reservation Protocol Traffic 429 Engineering (RSVP-TE)", RFC 5420, February 2009. 431 10.2. Informative References 433 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 434 Support of Generalized Multi-Protocol Label Switching 435 (GMPLS)", RFC 4202, October 2005. 437 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 438 Hierarchy with Generalized Multi-Protocol Label Switching 439 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 441 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 442 Networks", RFC 5920, July 2010. 444 [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically 445 Signaled Hierarchical Label Switched Paths", RFC 6107, 446 February 2011. 448 Authors' Addresses 450 Fatai Zhang (editor) 451 Huawei 452 F3-5-B RD Center 453 Bantian, Longgang District, Shenzhen 518129 454 P.R.China 456 Email: zhangfatai@huawei.com 458 Oscar Gonzalez de Dios (editor) 459 Telefonica Global CTO 460 Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 461 Madrid 28050 462 Spain 464 Phone: +34 913129647 465 Email: oscar.gonzalezdedios@telefonica.com 466 Dan Li 467 Huawei 468 F3-5-B RD Center 469 Bantian, Longgang District, Shenzhen 518129 470 P.R.China 472 Email: danli@huawei.com 474 Cyril Margaria 475 Suite 4001, 200 Somerset Corporate Blvd. 476 Bridgewater, NJ 08807 477 US 479 Email: cyril.margaria@gmail.com 481 Matt Hartley 482 Cisco 484 Email: mhartley@cisco.com 486 Zafar Ali 487 Cisco 489 Email: zali@cisco.com