idnits 2.17.1 draft-ietf-ccamp-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 == Line 380 has weird spacing: '...ocation colle...' -- The document date (August 26, 2014) is 3525 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 F. Zhang, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires: February 27, 2015 Telefonica Global CTO 6 D. Li 7 Huawei 8 C. Margaria 10 M. Hartley 11 Z. Ali 12 Cisco 13 August 26, 2014 15 RSVP-TE Extensions for Collecting SRLG Information 16 draft-ietf-ccamp-rsvp-te-srlg-collect-07 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 27, 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 . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 8 78 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 9 79 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 9 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 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, early allocation requested, 143 see Section 8.1 for more details): SRLG 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. The value is to be assigned by IANA. An 174 early allocation is requested (see Section 8.2 for more details). 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 RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub- 199 object) in the RRO so as to facilitate confidentiality in the 200 signaling of inter-domain TE LSPs, and allows the path segment that 201 needs to be hidden (that is, a Confidential Path Segment (CPS)) to be 202 replaced in the RRO with a PKS. If the CPS contains SRLG Sub- 203 objects, these MAY be retained in the RRO by adding them again after 204 the PKS Sub-object in the RRO. 206 A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without 207 also pushing either a IPv4 sub-object, a IPv6 sub-object, a 208 Unnumbered Interface ID sub-object or a Path Key sub-object. 210 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 211 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 213 5. Signaling Procedures 215 5.1. SRLG Collection 217 Per RFC 3209 [RFC3209], an ingress node initiates the recording of 218 the route information of an LSP by adding a RRO to a Path message. 219 If an ingress node also desires SRLG recording, it MUST set the SRLG 220 Collection Flag in the Attribute Flags TLV which MAY be carried 221 either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 222 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 223 desired, but not mandatory 225 When a node receives a Path message which carries an 226 LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag set, if 227 local policy determines that the SRLG information is not to be 228 provided to the endpoints, it MUST return a PathErr message with 229 Error Code 2 (policy) and Error subcode "SRLG Recording Rejected" 230 (value to be assigned by IANA, early allocation of the value 231 requested, see Section 8.3 for more details) to reject the Path 232 message. 234 When a node receives a Path message which carries an LSP_ATTRIBUTES 235 Object and the SRLG Collection Flag set, if local policy determines 236 that the SRLG information is not to be provided to the endpoints, the 237 Path message SHOULD NOT be rejected due to SRLG recording restriction 238 and the Path message SHOULD be forwarded without any SRLG sub- 239 object(s) in the RRO of the corresponding outgoing Path message. 241 If local policy permits the recording of the SRLG information, the 242 processing node SHOULD add local SRLG information, as defined below, 243 to the RRO of the corresponding outgoing Path message. It then 244 forwards the Path message to the next node in the downstream 245 direction. 247 Following the steps described above, the intermediate nodes of the 248 LSP can collect the SRLG information in the RRO during the processing 249 of the Path message hop by hop. When the Path message arrives at the 250 egress node, the egress node receives SRLG information in the RRO. 252 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 253 message which contains an RRO, an egress node initiates the RRO 254 process by adding an RRO to the outgoing Resv message. The 255 processing for RROs contained in Resv messages then mirrors that of 256 the Path messages. 258 When a node receives a Resv message for an LSP for which SRLG 259 Collection is specified, if local policy determines that the SRLG 260 information is not to be provided to the endpoints, if the SRLG- 261 recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a 262 ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording 263 Rejected" (value to be assigned by IANA, early allocation of the 264 value requested, see Section 8.3 for more details) MUST be sent. If 265 the request was in a LSP_ATTRIBUTES object, then a ResvErr SHOULD NOT 266 be generated, but SRLG information MUST NOT be added in the RRO. 267 When local policy allows recording SRLG information, the node SHOULD 268 add SRLG information, as defined below, to the RRO of the 269 corresponding outgoing Resv message. When the Resv message arrives 270 at the ingress node, the ingress node can get the SRLG information 271 from the RRO in the same way as the egress node. 273 Note that a link's SRLG information for the upstream direction cannot 274 be assumed to be the same as that in the downstream. 276 o For Path and Resv messages for a unidirectional LSP, a node SHOULD 277 include SRLG sub-objects in the RRO for the downstream data link 278 only. 280 o For Path and Resv messages for a bidirectional LSP, a node SHOULD 281 include SRLG sub-objects in the RRO for both the upstream data 282 link and the downstream data link from the local node. In this 283 case, the node MUST include the information in the same order for 284 both Path messages and Resv messages. That is, the SRLG sub- 285 object for the upstream link is added to the RRO before the SRLG 286 sub-object for the downstream link. 288 Based on the above procedure, the endpoints can get the SRLG 289 information automatically. Then the endpoints can for instance 290 advertise it as a TE link to the routing instance based on the 291 procedure described in [RFC6107] and configure the SRLG information 292 of the FA automatically. 294 5.2. SRLG Update 296 When the SRLG information of a link is changed, the LSPs using that 297 link should be aware of the changes. The procedures defined in 298 Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG 299 information if the SRLG change is to be communicated to other nodes 300 according to the local node's policy. If local policy is that the 301 SRLG change should be suppressed or would result in no change to the 302 previously signaled SRLG-list, the node SHOULD NOT send an update. 304 5.3. Compatibility 306 A node that does not recognize the SRLG Collection Flag in the 307 Attribute Flags TLV is expected to proceed as specified in RFC 5420 308 [RFC5420]. It is expected to pass the TLV on unaltered if it appears 309 in a LSP_ATTRIBUTES object, or reject the Path message with the 310 appropriate Error Code and Value if it appears in a 311 LSP_REQUIRED_ATTRIBUTES object. 313 A node that does not recognize the SRLG RRO sub-object is expected to 314 behave as specified in RFC 3209 [RFC3209]: unrecognized subobjects 315 are to be ignored and passed on unchanged. 317 6. Manageability Considerations 319 6.1. Policy Configuration 321 In a border node of inter-domain or inter-layer network, the 322 following SRLG processing policy should be capable of being 323 configured: 325 o Whether the SRLG IDs of the domain or specific layer network can 326 be exposed to the nodes outside the domain or layer network, or 327 whether they should be summarized, mapped to values that are 328 comprehensible to nodes outside the domain or layer network, or 329 removed entirely. 331 A node using RFC 5553 [RFC5553] and PKS may apply the same policy. 333 6.2. Coherent SRLG IDs 335 In a multi-layer multi-domain scenario, SRLG ids may be configured by 336 different management entities in each layer/domain. In such 337 scenarios, maintaining a coherent set of SRLG IDs is a key 338 requirement in order to be able to use the SRLG information properly. 339 Thus, SRLG IDs must be unique. Note that current procedure is 340 targeted towards a scenario where the different layers and domains 341 belong to the same operator, or to several coordinated administrative 342 groups. Ensuring the aforementioned coherence of SRLG IDs is beyond 343 the scope of this document. 345 Further scenarios, where coherence in the SRLG IDs cannot be 346 guaranteed are out of the scope of the present document and are left 347 for further study. 349 7. Security Considerations 351 This document builds on the mechanisms defined in [RFC3473], which 352 also discusses related security measures. In addition, [RFC5920] 353 provides an overview of security vulnerabilities and protection 354 mechanisms for the GMPLS control plane. The procedures defined in 355 this document permit the transfer of SRLG data between layers or 356 domains during the signaling of LSPs, subject to policy at the layer 357 or domain boundary. It is recommended that domain/layer boundary 358 policies take the implications of releasing SRLG information into 359 consideration and behave accordingly during LSP signaling. 361 8. IANA Considerations 363 8.1. RSVP Attribute Bit Flags 365 IANA has created a registry and manages the space of the Attribute 366 bit flags of the Attribute Flags TLV, as described in section 11.3 of 367 RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource 368 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" 369 registry located in https://www.iana.org/assignments/rsvp-te- 370 parameters/rsvp-te-parameters.xhtml. It is requested that IANA makes 371 an early allocation in the "Attribute Flags" section of the mentioned 372 registry. 374 This document introduces a new Attribute Bit Flag: 376 Bit No Name Attribute Attribute RRO Reference 377 Flags Path Flags Resv 378 ----------- ---------- ---------- ----------- --- --------- 379 TBD(early SRLG Yes Yes Yes This I-D 380 allocation collection 381 requested) Flag 383 8.2. ROUTE_RECORD Object 385 IANA manages the "RSVP PARAMETERS" registry located at 386 http://www.iana.org/assignments/rsvp-parameters. We request IANA to 387 make an early allocation in the Sub-object type 21 ROUTE_RECORD - 388 Type 1 Route Record registry 390 This document introduces a new RRO sub-object: 392 Value Description Reference 393 --------------------- ------------------- --------- 394 TBD (early allocation SRLG sub-object This I-D 395 requested, suggested 396 value 34) 398 8.3. Policy Control Failure Error subcodes 400 IANA manages the assignments in the "Error Codes and Globally-Defined 401 Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry 402 located at http://www.iana.org/assignments/rsvp-parameters. We 403 request IANA to make an early allocation in the "Sub-Codes - 2 Policy 404 Control Failure" subsection of the the "Error Codes and Globally- 405 Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" 406 registry. 408 This document introduces a new Policy Control Failure Error sub-code: 410 Value Description Reference 411 --------------------- ----------------------- --------- 412 TBD (early allocation SRLG Recording Rejected This I-D 413 requested) 415 9. Acknowledgements 417 The authors would like to thank Igor Bryskin, Ramon Casellas, Lou 418 Berger, Alan Davey and Dhruv Dhody for their useful comments and 419 improvements to the document. 421 10. References 423 10.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 429 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 430 Tunnels", RFC 3209, December 2001. 432 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 433 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 434 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 436 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 437 Ayyangarps, "Encoding of Attributes for MPLS LSP 438 Establishment Using Resource Reservation Protocol Traffic 439 Engineering (RSVP-TE)", RFC 5420, February 2009. 441 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 442 Reservation Protocol (RSVP) Extensions for Path Key 443 Support", RFC 5553, May 2009. 445 10.2. Informative References 447 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 448 Support of Generalized Multi-Protocol Label Switching 449 (GMPLS)", RFC 4202, October 2005. 451 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 452 Hierarchy with Generalized Multi-Protocol Label Switching 453 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 455 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 456 Networks", RFC 5920, July 2010. 458 [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically 459 Signaled Hierarchical Label Switched Paths", RFC 6107, 460 February 2011. 462 Authors' Addresses 463 Fatai Zhang (editor) 464 Huawei 465 F3-5-B RD Center 466 Bantian, Longgang District, Shenzhen 518129 467 P.R.China 469 Email: zhangfatai@huawei.com 471 Oscar Gonzalez de Dios (editor) 472 Telefonica Global CTO 473 Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 474 Madrid 28050 475 Spain 477 Phone: +34 913129647 478 Email: oscar.gonzalezdedios@telefonica.com 480 Dan Li 481 Huawei 482 F3-5-B RD Center 483 Bantian, Longgang District, Shenzhen 518129 484 P.R.China 486 Email: danli@huawei.com 488 Cyril Margaria 489 Suite 4001, 200 Somerset Corporate Blvd. 490 Bridgewater, NJ 08807 491 US 493 Email: cyril.margaria@gmail.com 495 Matt Hartley 496 Cisco 498 Email: mhartley@cisco.com 500 Zafar Ali 501 Cisco 503 Email: zali@cisco.com