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