idnits 2.17.1 draft-ietf-mpls-3209-patherr-02.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, updated by RFC 4748 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 306. 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 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 (February 18, 2008) is 5905 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft George. Swallow 3 Intended status: Best Current Cisco Systems, Inc 4 Practice Ina. Minei 5 Expires: August 21, 2008 Juniper Networks 6 February 18, 2008 8 Node behavior upon originating and receiving Resource ReserVation 9 Protocol (RSVP) Path Error message 10 draft-ietf-mpls-3209-patherr-02.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 August 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 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) Traffic Engineering (TE) Path Error message and to the 46 behavior of a node receiving an RSVP Path Error message for a 47 preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering 48 Label Switched Path (TE LSP). This document does not define any new 49 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4 62 2.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 5 63 2.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5 64 3. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 Intellectual Property and Copyright Statements . . . . . . . . . . 8 72 1. Introduction 74 The aim of this document is to describe a common practice with regard 75 to the behavior of a node sending a Resource ReserVation Protocol 76 (RSVP) Traffic Engineering (TE) Path Error message and to the 77 behavior of a node receiving an RSVP Path Error message for a 78 preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering 79 Label Switched Path (TE LSP). 81 [RFC2205] defines two RSVP error message types: PathErr and ResvErr 82 that are generated when an error occurs. Path Error Messages 83 (PathErr) are used to report errors and travel upstream toward the 84 head-end of the flow. Resv Error messages (ResvErr) travel 85 downstream toward the tail-end of the flow. 87 This document describes only PathErr message processing for the 88 specific case of a preempted Traffic Engineering Label Switched Path 89 (TE LSP) where the term preemption is defined in [RFC3209]. 91 2. Protocol behavior 93 PathErr messages are routed hop-by-hop using the path state 94 established when a Path message is routed through the network from 95 the head-end to its tail-end. 97 As stated in [RFC2205], PathErr messages do not modify the state of 98 any node through which they pass; they are only reported to the head- 99 end of the TE LSP (Traffic Engineering Label Switched Path). 101 The format of the PathErr message as defined in [RFC2205] is as 102 follows: 104 ::= [ ] 105 106 [ ...] 107 [ ] 109 ::= 110 [ ] 112 The ERROR_SPEC object includes the IP address of the node that 113 detected the error (Error Node Address), and specifies the error 114 through two fields. The Error Code field encodes the category of the 115 error, for example, Policy Control Failure or Unknown object class. 116 The Error Value field qualifies the error code to indicate the error 117 with more precision. [RFC3209] extends RSVP as defined in [RFC2205] 118 for the management of Multi-Protocol Label Switching (MPLS) Traffic 119 Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies 120 several additional conditions that trigger the sending of a RSVP 121 PathErr message for which new error codes and error values have been 122 defined that extend the list defined in [RFC2205]. The exact 123 circumstances under which a TE LSP is preempted and such PathErr 124 messages are sent are defined in [RFC3209] and will not be repeated 125 here. 127 Values for the Error Code and Error Value fields defined in 128 [RFC2205], [RFC3209], and other documents are maintained in a 129 registry by the IANA. 131 The error conditions fall into two categories: 133 o Fatal errors represent disruptive conditions for a TE LSP, 135 o Non-fatal errors are non-disruptive conditions which have occurred 136 for this TE LSP 138 Additionally, PathErr messages may be used in two circumstances: 140 o During TE LSP establishment, 142 o After a TE LSP has been successfully established. 144 Nodal behavior is dependent on which combination of the four cases 145 listed above applies. The following sections describe the expected 146 behavior at nodes that perform a preemption action for a TE LSP (and 147 therefore report using error PathErr messages), and at nodes that 148 receive PathErr messages. This text is a clarification and re- 149 statement of the procedures set out in [RFC3209] and does not define 150 any new behavior. 152 2.1. Behavior at Detecting Nodes 154 In the case of fatal errors, the detecting node must send a PathErr 155 message reporting the error condition, and must clear the 156 corresponding Path and Resv (control plane) states. A direct 157 implication is that the data plane resources of such a TE LSP are 158 also released, thus resulting in traffic disruption. It should be 159 noted, however, that in fatal error cases, the LSP has usually 160 already failed in the data plane, and traffic has already been 161 disrupted. When the error arises during LSP establishment, the 162 implications are different to when it arises on an active LSP since 163 no traffic flows until the LSP has been fully established. In the 164 case of non-fatal errors, the detecting node should send a PathErr 165 message, and must not clear control plane or data plane state. 167 2.2. Behavior at Receiving Nodes 169 Nodes that receive PathErr messages are all of the nodes along the 170 path of the TE LSP upstream of the node that detected the error. 171 This includes the head-end node. In accordance with [RFC2205] a node 172 receiving a PathErr message takes no action upon it and consequently 173 it must not clear Path or Resv control plane or data plane state. 174 This is true regardless of whether the error condition reported by 175 the PathErr is fatal or non-fatal. RSVP states should only be 176 affected upon receiving a PathTear or ResvTear message, or in the 177 event of a Path or Resv state timeout. Further discussion of the 178 processing of these events is outside the scope of this document. 179 Note that [RFC3473] defines a Path_State_Removed flag in the 180 ERROR_SPEC object carried on a PathErr message. This field may be 181 set to change the behavior of upstream nodes that receive the PathErr 182 message. When set, the flag indicates that the message sender has 183 removed Path state (and any associated Resv and data plane state) for 184 the TE LSP. The message receiver should do likewise before 185 forwarding the message, but may retain state and clear the flag 186 before forwarding the message. 188 2.3. Data Plane Behavior 190 Any node clearing either or both the Path or the Resv state of a TE 191 LSP MUST also free up the data plane resources allocated to the 192 corresponding TE LSP. 194 3. RSVP PathErr Messages For a Preempted TE LSP 196 Two Error-code can be used to report a preempted TE LSPs: 198 o As defined in [RFC2750]:Error Code=2: "Policy Control Failure", 199 Error Value=5 "Flow was preempted" 201 o As defined in [RFC2205], Error Code=12: "Service preempted" 203 In both cases, these are fatal errors. 205 4. IANA Considerations 207 This document does not define any new protocol extensions and thus no 208 action is requested to IANA. 210 5. Security Considerations 212 This document does not define any new procedures, but clarifies those 213 defined in other documents where security considerations are already 214 specified. This document does not raise specific security issues 215 beyond those of existing MPLS-TE. By clarifying the procedures, this 216 document reduces the security risk introduced by non-conformant 217 implementations. 219 6. Acknowledgements 221 The author would like to thank Carol Iturralde, Ashok Narayanan, Rom 222 Reuther and Reshad Rahman. 224 7. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, March 1997. 229 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 230 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 231 Functional Specification", RFC 2205, September 1997. 233 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 234 RFC 2750, January 2000. 236 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 237 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 238 Tunnels", RFC 3209, December 2001. 240 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 241 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 242 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 244 Authors' Addresses 246 JP Vasseur (editor) 247 Cisco Systems, Inc 248 1414 Massachusetts Avenue 249 Boxborough, MA 01719 250 USA 252 Email: jpv@cisco.com 253 George Swallow 254 Cisco Systems, Inc 255 1414 Massachusetts Avenue 256 Boxborough, MA 01719 257 USA 259 Email: swallow@cisco.com 261 Ina Minei 262 Juniper Networks 263 1194 North Mathilda Ave. 264 Sunnyvale, 94089 266 Email: ina@juniper.net 268 Full Copyright Statement 270 Copyright (C) The IETF Trust (2008). 272 This document is subject to the rights, licenses and restrictions 273 contained in BCP 78, and except as set forth therein, the authors 274 retain all their rights. 276 This document and the information contained herein are provided on an 277 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 278 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 279 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 280 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 Intellectual Property 286 The IETF takes no position regarding the validity or scope of any 287 Intellectual Property Rights or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; nor does it represent that it has 291 made any independent effort to identify any such rights. Information 292 on the procedures with respect to rights in RFC documents can be 293 found in BCP 78 and BCP 79. 295 Copies of IPR disclosures made to the IETF Secretariat and any 296 assurances of licenses to be made available, or the result of an 297 attempt made to obtain a general license or permission for the use of 298 such proprietary rights by implementers or users of this 299 specification can be obtained from the IETF on-line IPR repository at 300 http://www.ietf.org/ipr. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights that may cover technology that may be required to implement 305 this standard. Please address the information to the IETF at 306 ietf-ipr@ietf.org. 308 Acknowledgment 310 Funding for the RFC Editor function is provided by the IETF 311 Administrative Support Activity (IASA).