idnits 2.17.1 draft-ietf-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 296. 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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 8, 2008) is 5921 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: 3 errors (**), 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 Adrian. Farrel 5 Expires: August 11, 2008 Old Dog Consulting 6 Ina. Minei 7 Juniper Networks 8 February 8, 2008 10 Node behavior upon originating and receiving Resource ReserVation 11 Protocol (RSVP) Path Error message 12 draft-ietf-mpls-3209-patherr-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 11, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 The aim of this document is to describe a common practice with regard 46 to the behavior of a node sending a Resource ReserVation Protocol 47 (RSVP) Traffic Engineering (TE) Path Error message and to the 48 behavior of a node receiving an RSVP Path Error message for a 49 preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering 50 Label Switched Path (TE LSP). This document does not define any new 51 protocol extensions. 53 Requirements Language 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119]. 59 Table of Contents 61 1. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4 63 1.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 4 64 1.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5 65 2. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 Intellectual Property and Copyright Statements . . . . . . . . . . 8 72 1. Protocol behavior 74 [RFC2205] defines two RSVP error message types: PathErr and ResvErr 75 that are generated when an error occurs. Path Error Messages 76 (PathErr) are used to report errors and travel upstream toward the 77 head-end of the flow. Resv Error messages (ResvErr) travel 78 downstream toward the tail-end of the flow. 80 This document describes only PathErr message processing for the 81 specific case of a preempted Traffic Engineering Label Switched Path 82 (TE LSP) where the term preemption is defined in [RFC3209]. PathErr 83 messages are routed hop-by-hop using the path state established when 84 a Path message is routed through the network from the head-end to its 85 tail-end. 87 As stated in [RFC2205], PathErr messages do not modify the state of 88 any node through which they pass; they are only reported to the head- 89 end of the TE LSP (Traffic Engineering Label Switched Path). 91 The format of the PathErr message as defined in [RFC2205] is as 92 follows: 94 ::= [ ] 95 96 [ ...] 97 [ ] 99 ::= 100 [ ] 102 The ERROR_SPEC object includes the IP address of the node that 103 detected the error (Error Node Address), and specifies the error 104 through two fields. The Error Code field encodes the category of the 105 error, for example, Policy Control Failure or Unknown object class. 106 The Error Value field qualifies the error code to indicate the error 107 with more precision. [RFC3209] extends RSVP as defined in [RFC2205] 108 for the management of Multi-Protocol Label Switching (MPLS) Traffic 109 Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies 110 several additional conditions that trigger the sending of a RSVP 111 PathErr message for which new error codes and error values have been 112 defined that extend the list defined in [RFC2205]. The exact 113 circumstances under which a TE LSP is preempted and such PathErr 114 messages are sent are defined in [RFC3209] and will not be repeated 115 here. 117 Values for the Error Code and Error Value fields defined in 118 [RFC2205], [RFC3209], and other documents are maintained in a 119 registry by the IANA. 121 The error conditions fall into two categories: 123 o Fatal errors represent disruptive conditions for a TE LSP, 125 o Non-fatal errors are non-disruptive conditions which have occurred 126 for this TE LSP 128 Additionally, PathErr messages may be used in two circumstances: 130 o During TE LSP establishment, 132 o After a TE LSP has been successfully established. 134 Nodal behavior is dependent on which combination of the four cases 135 listed above applies. The following sections describe the expected 136 behavior at nodes that perform a preemption action for a TE LSP (and 137 therefore report using error PathErr messages), and at nodes that 138 receive PathErr messages. This text is a clarification and re- 139 statement of the procedures set out in [RFC3209] and does not define 140 any new behavior. 142 1.1. Behavior at Detecting Nodes 144 In the case of fatal errors, the detecting node must send a PathErr 145 message reporting the error condition, and must clear the 146 corresponding Path and Resv (control plane) states. A direct 147 implication is that the data plane resources of such a TE LSP are 148 also released, thus resulting in traffic disruption. It should be 149 noted, however, that in fatal error cases, the LSP has usually 150 already failed in the data plane, and traffic has already been 151 disrupted. When the error arises during LSP establishment, the 152 implications are different to when it arises on an active LSP since 153 no traffic flows until the LSP has been fully established. In the 154 case of non-fatal errors, the detecting node should send a PathErr 155 message, and must not clear control plane or data plane state. 157 1.2. Behavior at Receiving Nodes 159 Nodes that receive PathErr messages are all of the nodes along the 160 path of the TE LSP upstream of the node that detected the error. 161 This includes the head-end node. In accordance with [RFC2205] a node 162 receiving a PathErr message takes no action upon it and consequently 163 it must not clear Path or Resv control plane or data plane state. 164 This is true regardless of whether the error condition reported by 165 the PathErr is fatal or non-fatal. RSVP states should only be 166 affected upon receiving a PathTear or ResvTear message, or in the 167 event of a Path or Resv state timeout. Further discussion of the 168 processing of these events is outside the scope of this document. 169 Note that [RFC3473] defines a Path_State_Removed flag in the 170 ERROR_SPEC object carried on a PathErr message. This field may be 171 set to change the behavior of upstream nodes that receive the PathErr 172 message. When set, the flag indicates that the message sender has 173 removed Path state (and any associated Resv and data plane state) for 174 the TE LSP. The message receiver should do likewise before 175 forwarding the message, but may retain state and clear the flag 176 before forwarding the message. 178 1.3. Data Plane Behavior 180 Any node clearing either or both the Path or the Resv state of a TE 181 LSP MUST also free up the data plane resources allocated to the 182 corresponding TE LSP. 184 2. RSVP PathErr Messages For a Preempted TE LSP 186 Two Error-code can be used to report a preempted TE LSPs: 188 o As defined in [RFC2750]:Error Code=2: "Policy Control Failure", 189 Error Value=5 "Flow was preempted" 191 o As defined in [RFC2205], Error Code=12: "Service preempted" 193 In both cases, these are fatal errors. 195 3. Security Considerations 197 This document does not define any new procedures, but clarifies those 198 defined in other documents where security considerations are already 199 specified. This document does not raise specific security issues 200 beyond those of existing MPLS-TE. By clarifying the procedures, this 201 document reduces the security risk introduced by non-conformant 202 implementations. 204 4. Acknowledgements 206 The author would like to thank Carol Iturralde, Ashok Narayanan, Rom 207 Reuther and Reshad Rahman. 209 5. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 215 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 216 Functional Specification", RFC 2205, September 1997. 218 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 219 RFC 2750, January 2000. 221 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 222 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 223 Tunnels", RFC 3209, December 2001. 225 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 226 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 227 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 229 Authors' Addresses 231 JP Vasseur (editor) 232 Cisco Systems, Inc 233 1414 Massachusetts Avenue 234 Boxborough, MA 01719 235 USA 237 Email: jpv@cisco.com 239 George Swallow 240 Cisco Systems, Inc 241 1414 Massachusetts Avenue 242 Boxborough, MA 01719 243 USA 245 Email: swallow@cisco.com 247 Adrian Farrel 248 Old Dog Consulting 250 Email: adrian@olddog.co.uk 251 Ina Minei 252 Juniper Networks 253 1194 North Mathilda Ave. 254 Sunnyvale, 94089 256 Email: ina@juniper.net 258 Full Copyright Statement 260 Copyright (C) The IETF Trust (2008). 262 This document is subject to the rights, licenses and restrictions 263 contained in BCP 78, and except as set forth therein, the authors 264 retain all their rights. 266 This document and the information contained herein are provided on an 267 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 268 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 269 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 270 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 271 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 272 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 274 Intellectual Property 276 The IETF takes no position regarding the validity or scope of any 277 Intellectual Property Rights or other rights that might be claimed to 278 pertain to the implementation or use of the technology described in 279 this document or the extent to which any license under such rights 280 might or might not be available; nor does it represent that it has 281 made any independent effort to identify any such rights. Information 282 on the procedures with respect to rights in RFC documents can be 283 found in BCP 78 and BCP 79. 285 Copies of IPR disclosures made to the IETF Secretariat and any 286 assurances of licenses to be made available, or the result of an 287 attempt made to obtain a general license or permission for the use of 288 such proprietary rights by implementers or users of this 289 specification can be obtained from the IETF on-line IPR repository at 290 http://www.ietf.org/ipr. 292 The IETF invites any interested party to bring to its attention any 293 copyrights, patents or patent applications, or other proprietary 294 rights that may cover technology that may be required to implement 295 this standard. Please address the information to the IETF at 296 ietf-ipr@ietf.org. 298 Acknowledgment 300 Funding for the RFC Editor function is provided by the IETF 301 Administrative Support Activity (IASA).