idnits 2.17.1 draft-vasseur-mpls-3209-patherr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 371. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2006) is 6400 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3476' is mentioned on line 242, but not defined == Missing Reference: 'RFC3474' is mentioned on line 246, but not defined == Missing Reference: 'RFC3175' is mentioned on line 255, but not defined == Missing Reference: 'RFC3270' is mentioned on line 256, but not defined == Missing Reference: 'RFC4124' is mentioned on line 257, but not defined == Missing Reference: 'RFC4420' is mentioned on line 259, but not defined ** Obsolete undefined reference: RFC 4420 (Obsoleted by RFC 5420) == Missing Reference: 'IANA-URL' is mentioned on line 277, but not defined == Unused Reference: 'I-D.ietf-ccamp-loose-path-reopt' is defined on line 281, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-loose-path-reopt (ref. 'I-D.ietf-ccamp-loose-path-reopt') Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur 2 Internet-Draft George. Swallow 3 Intended status: Best Current Cisco Systems, Inc 4 Practice Adrian. Farrel 5 Expires: April 21, 2007 Old Dog Consulting 6 October 18, 2006 8 Node behavior upon originating and receiving Resource ReserVation 9 Protocol (RSVP) Path Error message 10 draft-vasseur-mpls-3209-patherr-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 21, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The aim of this document is to describe a common practice with regard 44 to the behavior of a node sending a Resource ReserVation Protocol 45 (RSVP) Path Error message and to the behavior of a node receiving an 46 RSVP Path Error message for a particular Multi-Protocol Label 47 Switching - Traffic Engineering (MPLS-TE) Label Switched Path (LSP). 49 This document does not define any new protocol extensions. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4 61 1.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 4 62 1.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5 63 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Intellectual Property and Copyright Statements . . . . . . . . . . 9 71 1. Protocol behavior 73 [RFC2205] defines two RSVP error message types: PathErr and ResvErr 74 that are generated when an error occurs. Path Error Messages 75 (PathErr) are used to report errors and travel upstream toward the 76 head-end of the flow. Resv Error messages (ResvErr) travel 77 downstream toward the tail-end of the flow. 79 This document describes only PathErr message processing. PathErr 80 messages are routed hop-by-hop using the path state established when 81 a Path message is routed through the network from the head-end to its 82 tail-end. 84 As stated in [RFC2205], PathErr messages do not modify the state of 85 any node through which they pass; they are only reported to the head- 86 end of the TE LSP (Traffic Engineering Label Switched Path). 88 The format of the PathErr message as defined in [RFC2205] is as 89 follows: 91 ::= [ ] 92 93 [ ...] 94 [ ] 96 ::= 97 [ ] 99 The ERROR_SPEC object includes the IP address of the node that 100 detected the error (Error Node Address), and specifies the error 101 through two fields. The Error Code field encodes the category of the 102 error, for example, Policy Control Failure or Unknown object class. 103 The Error Value field qualifies the error code to indicate the error 104 with more precision. [RFC3209] extends RSVP as defined in [RFC2205] 105 for the management of Multi-Protocol Label Switching (MPLS) Traffic 106 Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies 107 several additional conditions that trigger the sending of an RSVP 108 PathErr message for which new error codes and error values have been 109 defined that extend the list defined in [RFC2205]. The exact 110 circumstances under which such PathErr messages are sent are defined 111 in [RFC3209] and will not be repeated here. 113 Values for the Error Code and Error Value fields defined in 114 [RFC2205], [RFC3209], and other documents are maintained in a 115 registry by the IANA. A full list can be seen at Section 5. The 116 error conditions fall into two categories: - fatal errors represent 117 disruptive conditions for a TE LSP, - non-fatal errors are non- 118 disruptive conditions which have occurred for this TE LSP. 119 Additionally, PathErr messages may be used in two circumstances: - 120 during TE LSP establishment, - after a TE LSP has been successfully 121 established. Nodal behavior is dependent on which combination of the 122 four cases listed above applies. The following sections describe the 123 expected behavior at nodes that detect (and therefore report using 124 PathErr messages) errors, and at nodes that receive PathErr messages. 125 This text is a clarification and re-statement of the procedures set 126 out in [RFC3209] and does not define any new behavior. Section 2 127 provides a list of the currently defined PathErr Error Codes and 128 Error Values and indicates for each whether it is fatal or non-fatal. 130 1.1. Behavior at Detecting Nodes 132 In the case of fatal errors, the detecting node must send a PathErr 133 message reporting the error condition, and must clear the 134 corresponding Path and Resv (control plane) states. A direct 135 implication is that the data plane resources of such a TE LSP are 136 also released, thus resulting in traffic disruption. It should be 137 noted, however, that in fatal error cases, the LSP has usually 138 already failed in the data plane, and traffic has already been 139 disrupted. When the error arises during LSP establishment, the 140 implications are different to when it arises on an active LSP since 141 no traffic flows until the LSP has been fully established. In the 142 case of non-fatal errors, the detecting node should send a PathErr 143 message, and must not clear control plane or data plane state. 145 1.2. Behavior at Receiving Nodes 147 Nodes that receive PathErr messages are all of the nodes along the 148 path of the TE LSP upstream of the node that detected the error. 149 This includes the head-end node. In accordance with [RFC2205] a node 150 receiving a PathErr message takes no action upon it and consequently 151 it must not clear Path or Resv control plane or data plane state. 152 This is true regardless of whether the error condition reported by 153 the PathErr is fatal or non-fatal. RSVP states should only be 154 affected upon receiving a PathTear or ResvTear message, or in the 155 event of a Path or Resv state timeout. Further discussion of the 156 processing of these events is outside the scope of this document. 157 Note that [RFC3473] defines a Path_State_Removed flag in the 158 ERROR_SPEC object carried on a PathErr message. This field may be 159 set to change the behavior of upstream nodes that receive the PathErr 160 message. When set, the flag indicates that the message sender has 161 removed Path state (and any associated Resv and data plane state) for 162 the TE LSP. The message receiver should do likewise before 163 forwarding the message, but may retain state and clear the flag 164 before forwarding the message. 166 1.3. Data Plane Behavior 168 Any node clearing either or both the Path or the Resv state of a TE 169 LSP MUST also free up the data plane resources allocated to the 170 corresponding TE LSP. 172 2. IANA Considerations 174 IANA maintains a registry of RSVP Error Codes and Error Values at 175 Section 5. The registry is labeled "Resource ReSerVation Protocol 176 (RSVP) Parameters" / "Error Codes and Values" IANA is requested to 177 add a column to this registry to indicate for each Error Code / Error 178 Value combination whether the error reported constitutes a fatal or 179 non-fatal error condition if the error is seen in an MPLS-TE system. 180 It is suggested that the column in headed "MPLS-TE Fatal" and contain 181 one of three values: Yes - The error condition represents a fatal 182 condition as described in this document when applied to an MPLS TE 183 LSP. No - The error condition represents a non-fatal condition as 184 described in this document when applied to an MPLS TE LSP. N/A - The 185 error condition cannot be applied to an MPLS TE LSP. IANA should 186 require that all new assignments from this registry provide 187 information in this column. In order to update this registry for the 188 creation of this column, the table below supplies the setting of the 189 column for each existing entry in the registry. IANA is requested to 190 transfer this information into the registry. Note that only the 191 Error Code and Error Value numbers are supplied here. No change to 192 any of the other registry fields is implied. 194 Error code Error Value Reference MPLS-TE Fatal 195 ------------+--------------+--------------+-------------- 196 0 Any [RFC2205] N/A 197 1 Any [RFC2205] N/A 198 2 5 [RFC2750] Yes 199 100 [RFC3476] N/A 200 101 [RFC3476] N/A 201 102 [RFC4495] N/A 202 Any other [RFC2205] N/A 203 3 Any [RFC2205] N/A 204 4 Any [RFC2205] N/A 205 5 Any [RFC2205] Yes 206 6 Any [RFC2205] N/A 207 7 Any [RFC2205] N/A 208 8 Any [RFC2205] N/A 209 9 Any [RFC2205] N/A 210 10 Any [RFC2205] N/A 211 11 Any [RFC2205] N/A 212 12 Any [RFC2205] N/A 213 13 Any [RFC2205] 214 14 Any [RFC2205] 215 15 Any [RFC2205] N/A 216 16 Any [RFC2205] N/A 217 17 Any [RFC2205] N/A 218 18 Any [RFC2205] N/A 219 19 Any [RFC2205] N/A 220 20 Any [RFC2205] N/A 221 21 Any [RFC2205] 222 22 Any [RFC2205] 223 23 Any [RFC2205] 224 24 1 [RFC3209] Yes 225 2 [RFC3209] Yes 226 3 [RFC3209] Yes 227 4 [RFC3209] Yes 228 5 [RFC3209] Yes 229 6 [RFC3209] Yes 230 7 [RFC3209] Yes 231 8 [RFC3209] Yes 232 9 [RFC3209] Yes 233 10 [RFC3209] Yes 234 11 [RFC3473] Yes 235 12 [RFC3473] Yes 236 13 [RFC3473] Yes 237 14 [RFC3473] Yes 238 15 [RFC3473] Yes 239 16 [RFC3473] Yes 240 100 [RFC3476] N/A 241 101 [RFC3476] N/A 242 102 [RFC3476] N/A 243 103 [RFC3474] N/A 244 104 [RFC3474] N/A 245 105 [RFC3474] N/A 246 106 [RFC3474] N/A 247 25 1 [RFC3209] No 248 2 [RFC3209] No 249 3 [RFC3209] No 250 4 [RFC3473] No 251 5 [RFC3473] No 252 6 [draft-ietf-ccamp-loose-path-reopt] No 253 7 [draft-ietf-ccamp-loose-path-reopt] No 254 8 [draft-ietf-ccamp-loose-path-reopt] No 255 26 Any [RFC3175] N/A 256 27 Any [RFC3270] N/A 257 28 Any [RFC4124] Yes 258 29 Any [RFC4420] 259 30 Any [RFC4420] 261 3. Security Considerations 263 This document does not define any new procedures, but clarifies those 264 defined in other documents where security considerations are already 265 specified. This document does not raise specific security issues 266 beyond those of existing MPLS-TE. By clarifying the procedures, this 267 document reduces the security risk introduced by non-conformant 268 implementations. 270 4. Acknowledgements 272 The author would like to thank Carol Iturralde, Ashok Narayanan, Rom 273 Reuther and Reshad Rahman. 275 5. URLs 277 [IANA-URL] http://www.iana.org/numbers.html 279 6. Normative References 281 [I-D.ietf-ccamp-loose-path-reopt] 282 Vasseur, J., "Reoptimization of Multiprotocol Label 283 Switching (MPLS) Traffic Engineering (TE) loosely routed 284 Label Switch Path (LSP)", 285 draft-ietf-ccamp-loose-path-reopt-02 (work in progress), 286 February 2006. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 292 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 293 Functional Specification", RFC 2205, September 1997. 295 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 296 RFC 2750, January 2000. 298 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 299 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 300 Tunnels", RFC 3209, December 2001. 302 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 303 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 304 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 306 [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol 307 (RSVP) Extension for the Reduction of Bandwidth of a 308 Reservation Flow", RFC 4495, May 2006. 310 Authors' Addresses 312 JP Vasseur 313 Cisco Systems, Inc 314 1414 Massachusetts Avenue 315 Boxborough, MA 01719 316 USA 318 Email: jpv@cisco.com 320 George Swallow 321 Cisco Systems, Inc 322 1414 Massachusetts Avenue 323 Boxborough, MA 01719 324 USA 326 Email: swallow@cisco.com 328 Adrian Farrel 329 Old Dog Consulting 331 Email: adrian@olddog.co.uk 333 Full Copyright Statement 335 Copyright (C) The Internet Society (2006). 337 This document is subject to the rights, licenses and restrictions 338 contained in BCP 78, and except as set forth therein, the authors 339 retain all their rights. 341 This document and the information contained herein are provided on an 342 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 343 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 344 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 345 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 346 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 347 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 349 Intellectual Property 351 The IETF takes no position regarding the validity or scope of any 352 Intellectual Property Rights or other rights that might be claimed to 353 pertain to the implementation or use of the technology described in 354 this document or the extent to which any license under such rights 355 might or might not be available; nor does it represent that it has 356 made any independent effort to identify any such rights. Information 357 on the procedures with respect to rights in RFC documents can be 358 found in BCP 78 and BCP 79. 360 Copies of IPR disclosures made to the IETF Secretariat and any 361 assurances of licenses to be made available, or the result of an 362 attempt made to obtain a general license or permission for the use of 363 such proprietary rights by implementers or users of this 364 specification can be obtained from the IETF on-line IPR repository at 365 http://www.ietf.org/ipr. 367 The IETF invites any interested party to bring to its attention any 368 copyrights, patents or patent applications, or other proprietary 369 rights that may cover technology that may be required to implement 370 this standard. Please address the information to the IETF at 371 ietf-ipr@ietf.org. 373 Acknowledgment 375 Funding for the RFC Editor function is provided by the IETF 376 Administrative Support Activity (IASA).