idnits 2.17.1 draft-ietf-ccamp-rsvp-te-srlg-collect-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '...he endpoints, it MUST return a PathErr...' RFC 2119 keyword, line 198: '...the Path message SHOULD NOT be rejecte...' RFC 2119 keyword, line 199: '...d the Path message SHOULD be forwarded...' RFC 2119 keyword, line 203: '... processing node SHOULD add an SRLG su...' RFC 2119 keyword, line 222: '...ed by IANA, suggest value 108) MUST be...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3717 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) == Missing Reference: 'RFC5420' is mentioned on line 301, but not defined == Unused Reference: 'RFC5150' is defined on line 374, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5920 Summary: 2 errors (**), 0 flaws (~~), 3 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: August 18, 2014 Telefonica Global CTO 6 D. Li 7 Huawei 8 C. Margaria 10 M. Hartley 11 Z. Ali 12 Cisco 13 February 14, 2014 15 RSVP-TE Extensions for Collecting SRLG Information 16 draft-ietf-ccamp-rsvp-te-srlg-collect-04 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 August 18, 2014. 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. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 3 61 2.1. SRLG Collection Indication . . . . . . . . . . . . . . . 3 62 2.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. RSVP-TE Extensions (Encoding) . . . . . . . . . . . . . . . . 3 65 3.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 3 66 3.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 4 67 4. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 4 68 4.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 4 69 4.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Manageability Considerations . . . . . . . . . . . . . . . . 6 71 5.1. Policy Configuration . . . . . . . . . . . . . . . . . . 6 72 5.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 6 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 7 76 7.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 7 77 7.3. Policy Control Failure Error subcodes . . . . . . . . . . 8 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 It is important to understand which TE links in the network might be 85 at risk from the same failures. In this sense, a set of links may 86 constitute a 'shared risk link group' (SRLG) if they share a resource 87 whose failure may affect all links in the set [RFC4202]. 89 On the other hand, as described in [RFC4206] and [RFC6107], H-LSP 90 (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying 91 one or more other LSPs. Both of the H-LSP and S-LSP can be formed as 92 a TE link. In such cases, it is important to know the SRLG 93 information of the LSPs that will be used to carry further LSPs. 95 This document provides an automatic mechanism to collect the SRLG for 96 the TE link formed by a LSP. Note that how to use the collected SRLG 97 information is out of scope of this document 99 2. RSVP-TE Requirements 101 2.1. SRLG Collection Indication 103 The head nodes of the LSP must be capable of indicating whether the 104 SRLG information of the LSP should be collected during the signaling 105 procedure of setting up an LSP. SRLG information should not be 106 collected without an explicit request for it being made by the head 107 node. 109 2.2. SRLG Collection 111 If requested, the SRLG information should be collected during the 112 setup of an LSP. The endpoints of the LSP may use the collected SRLG 113 information and use it for routing, sharing and TE link configuration 114 purposes. 116 2.3. SRLG Update 118 When the SRLG information of an existing LSP for which SRLG 119 information was collected during signaling changes, the relevant 120 nodes of the LSP must be capable of updating the SRLG information of 121 the LSP. This means that that the signaling procedure must be 122 capable of updating the new SRLG information. 124 3. RSVP-TE Extensions (Encoding) 126 3.1. SRLG Collection Flag 128 In order to indicate nodes that SRLG collection is desired, this 129 document defines a new flag in the Attribute Flags TLV, which is 130 carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTE Object: 132 o Bit Number (to be assigned by IANA, recommended bit 12): SRLG 133 Collection flag 135 The SRLG Collection flag is meaningful on a Path message. If the 136 SRLG Collection flag is set to 1, it means that the SRLG information 137 should be reported to the head and tail node along the setup of the 138 LSP. 140 The rules of the processing of the Attribute Flags TLV are not 141 changed. 143 3.2. SRLG sub-object 145 This document defines a new RRO sub-object (ROUTE_RECORD sub-object) 146 to record the SRLG information of the LSP. Its format is modeled on 147 the RRO sub-objects defined in RFC 3209 [RFC3209]. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | Reserved | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | SRLG ID 1 (4 bytes) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 ~ ...... ~ 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | SRLG ID n (4 bytes) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Type 163 The type of the sub-object, to be assigned by IANA, which is 164 recommended 34. 166 Length 168 The Length contains the total length of the sub-object in bytes, 169 including the Type and Length fields. The Length depends on the 170 number of SRLG IDs. 172 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 173 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 175 4. Signaling Procedures 177 4.1. SRLG Collection 179 Typically, the head node gets the route information of an LSP by 180 adding a RRO which contains the sender's IP addresses in the Path 181 message. If a head node also desires SRLG recording, it sets the 182 SRLG Collection Flag in the Attribute Flags TLV which can be carried 183 either in an LSP_REQUIRED_ATTRIBUTES Object if the collection is 184 mandatory, or in an LSP_ATTRIBUTES Object if the collection is 185 desired, but not mandatory 187 When a node receives a Path message which carries an 188 LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag is set, 189 if local policy determines that the SRLG information should not be 190 provided to the endpoints, it MUST return a PathErr message with 191 Error Code 2 (policy) and Error subcode "SRLG Recording Rejected" 192 (value to be assigned by IANA, suggest value 108) to reject the Path 193 message. 195 When a node receives a Path message which carries an LSP_ATTRIBUTES 196 Object and the SRLG Collection Flag is set, if local policy 197 determines that the SRLG information should not be provided to the 198 endpoints, the Path message SHOULD NOT be rejected due to SRLG 199 recording restriction and the Path message SHOULD be forwarded 200 without the SRLG sub-object(s) in the Path RRO. 202 If local policy permits the recording of the SRLG information, the 203 processing node SHOULD add an SRLG sub-object to the RRO to carry the 204 local SRLG information. It then forwards the Path message to the 205 next node in the downstream direction. 207 Following the steps described above, the intermediate nodes of the 208 LSP can collect the SRLG information in the RRO during the forwarding 209 of the Path message hop by hop. When the Path message arrives at the 210 tail node, the tail node can get the SRLG information from the RRO. 212 Before the Resv message is sent to the upstream node, the tail node 213 adds the SRLG subobject with the SRLG value(s) associated with the 214 local hop to the Resv RRO in a similar manner to that specified above 215 for the addition of Path RRO sub-objects by midpoint nodes. 217 When a node receives a Resv message for an LSP for which SRLG 218 Collection is specified, if local policy determines that the SRLG 219 information should not be provided to the endpoints, if the SRLG- 220 recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a 221 ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording 222 Rejected" (value to be assigned by IANA, suggest value 108) MUST be 223 sent. If the request was in a LSP_ATTRIBUTES object, then a ResvErr 224 SHOULD NOT be generated, but SRLG information must not be added in 225 the RRO. Otherwise, if local policy allows to provide the SRLG 226 information, it MUST add an SRLG sub-object to the RRO to carry the 227 SRLG information in the upstream direction. When the Resv message 228 arrives at the head node, the head node can get the SRLG information 229 from the RRO in the same way as the tail node. 231 Note that a link's SRLG information for the upstream direction cannot 232 be assumed to be the same as that in the downstream. 234 o For Path and Resv messages for a unidirectional LSP, a node SHOULD 235 include SRLG sub-objects in the RRO for the downstream data link 236 only. 238 o For Path and Resv messages for a bidirectional LSP, a node SHOULD 239 include SRLG sub-objects in the RRO for both the upstream data 240 link and the downstream data link from the local node. In this 241 case, the node MUST include the information in the same order for 242 both Path messages and Resv messages. That is, the SRLG sub- 243 object for the upstream link is added to the RRO before the SRLG 244 sub-object for the downstream link. 246 Based on the above procedure, the endpoints can get the SRLG 247 information automatically. Then the endpoints can for instance 248 advertise it as a TE link to the routing instance based on the 249 procedure described in [RFC6107] and configure the SRLG information 250 of the FA automatically. 252 4.2. SRLG Update 254 When the SRLG information of a link is changed, the LSPs using that 255 link should be aware of the changes. The procedures defined in 256 Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG 257 information if the SRLG change is to be communicated to other nodes 258 according to the local node's policy. If local policy is that the 259 SRLG change should be suppressed or would result in no change to the 260 previously signaled SRLG-list, the node need not send an update. 262 5. Manageability Considerations 264 5.1. Policy Configuration 266 In a border node of inter-domain or inter-layer network, the 267 following SRLG processing policy should be capable of being 268 configured: 270 o Whether the SRLG IDs of the domain or specific layer network can 271 be exposed to the nodes outside the domain or layer network, or 272 whether they should be summarized or removed entirely. 274 5.2. Coherent SRLG IDs 276 In a multi-layer multi-domain scenario, SRLG ids may be configured by 277 different management entities in each layer/domain. In such 278 scenarios, maintaining a coherent set of SRLG IDs is a key 279 requirement in order to be able to use the SRLG information properly. 280 Thus, SRLG IDs must be unique. Note that current procedure is 281 targeted towards a scenario where the different layers and domains 282 belong to the same operator, or to several coordinated administrative 283 groups. Ensuring the aforementioned coherence of SRLG IDs is beyond 284 the scope of this document. 286 Further scenarios, where coherence in the SRLG IDs cannot be 287 guaranteed are out of the scope of the present document and are left 288 for further study. 290 6. Security Considerations 292 This document does not introduce any additional security issues above 293 those identified in [RFC5920][RFC3209][RFC3473] 295 7. IANA Considerations 297 7.1. RSVP Attribute Bit Flags 299 IANA has created a registry and manages the space of attributes bit 300 flags of Attribute Flags TLV, as described in section 11.3 of 301 [RFC5420], in the "Attributes TLV Space" section of the "Resource 302 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" 303 registry located in https://www.iana.org/assignments/rsvp-te- 304 parameters/rsvp-te-parameters.xhtml. It is requested that IANA makes 305 assignments from the Attribute Bit Flags. 307 This document introduces a new Attribute Bit Flag: 309 o Bit number: TBD (10) 311 o Defining RFC: this I-D 313 o Name of bit: SRLG Collection Flag 315 o The meaning of the SRLG Collection Flag is defined in this I-D. 317 7.2. ROUTE_RECORD Object 319 IANA has made the following assignments in the "Class Names, Class 320 Numbers, and Class Types" section of the "RSVP PARAMETERS" registry 321 located at http://www.iana.org/assignments/rsvp-parameters. We 322 request that IANA make assignments from the ROUTE_RECORD RFC 3209 323 [RFC3209] portions of this registry. 325 This document introduces a new RRO sub-object: 327 Type Name Reference 328 --------- ---------------------- --------- 329 TBD (34) SRLG sub-object This I-D 331 7.3. Policy Control Failure Error subcodes 333 IANA has made the following assignments in the "Error Codes and 334 Globally-Defined Error Value Sub-Codes" section of the "RSVP 335 PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- 336 parameters. We request that IANA make assignments from the Policy 337 Control Failure Sub-Codes registry. 339 This document introduces a new Policy Control Failure Error sub-code: 341 o Error sub-code: TBD (108) 343 o Defining RFC: this I-D 345 o Name of error sub-code: SRLG Recording Rejected 347 o The meaning of the SRLG Recording Rejected error sub-code is 348 defined in this I-D 350 8. Acknowledgements 352 The authors would like to thank Igor Bryskin, Ramon Casellas, Lou 353 Berger and Alan Davey for their useful comments and improvements to 354 the document. 356 9. Normative References 358 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 359 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 360 Tunnels", RFC 3209, December 2001. 362 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 363 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 364 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 366 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 367 Support of Generalized Multi-Protocol Label Switching 368 (GMPLS)", RFC 4202, October 2005. 370 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 371 Hierarchy with Generalized Multi-Protocol Label Switching 372 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 374 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 375 "Label Switched Path Stitching with Generalized 376 Multiprotocol Label Switching Traffic Engineering (GMPLS 377 TE)", RFC 5150, February 2008. 379 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 380 Networks", RFC 5920, July 2010. 382 [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically 383 Signaled Hierarchical Label Switched Paths", RFC 6107, 384 February 2011. 386 Authors' Addresses 388 Fatai Zhang (editor) 389 Huawei 390 F3-5-B RD Center 391 Bantian, Longgang District, Shenzhen 518129 392 P.R.China 394 Email: zhangfatai@huawei.com 396 Oscar Gonzalez de Dios (editor) 397 Telefonica Global CTO 398 Don Ramon de la Cruz 399 Madrid 28006 400 Spain 402 Phone: +34 913328832 403 Email: ogondio@tid.es 405 Dan Li 406 Huawei 407 F3-5-B RD Center 408 Bantian, Longgang District, Shenzhen 518129 409 P.R.China 411 Email: danli@huawei.com 413 Cyril Margaria 414 SabenerStr. 44 415 Munich 81547 416 Germany 418 Phone: +49 89 5159 16934 419 Email: cyril.margaria@gmail.com 420 Matt Hartley 421 Cisco 423 Email: mhartley@cisco.com 425 Zafar Ali 426 Cisco 428 Email: zali@cisco.com