idnits 2.17.1 draft-ietf-mpls-3209-patherr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 2, 2009) is 5534 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 (==), 3 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: August 6, 2009 Ina. Minei 5 Juniper Networks 6 February 2, 2009 8 Node behavior upon originating and receiving Resource ReserVation 9 Protocol (RSVP) Path Error message 10 draft-ietf-mpls-3209-patherr-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 6, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 The aim of this document is to describe a common practice with regard 50 to the behavior of a node sending a Resource ReserVation Protocol 51 (RSVP) Traffic Engineering (TE) Path Error message and to the 52 behavior of a node receiving an RSVP Path Error message for a 53 preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering 54 Label Switched Path (TE LSP). This document does not define any new 55 protocol extensions. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4 68 2.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 5 69 2.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5 70 3. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 The aim of this document is to describe a common practice with regard 80 to the behavior of a node sending a Resource ReserVation Protocol 81 (RSVP) Traffic Engineering (TE) Path Error message and to the 82 behavior of a node receiving an RSVP Path Error message for a 83 preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering 84 Label Switched Path (TE LSP). 86 [RFC2205] defines two RSVP error message types: PathErr and ResvErr 87 that are generated when an error occurs. Path Error Messages 88 (PathErr) are used to report errors and travel upstream toward the 89 head-end of the flow. Resv Error messages (ResvErr) travel 90 downstream toward the tail-end of the flow. 92 This document describes only PathErr message processing for the 93 specific case of a preempted Traffic Engineering Label Switched Path 94 (TE LSP) where the term preemption is defined in [RFC3209]. 96 2. Protocol behavior 98 PathErr messages are routed hop-by-hop using the path state 99 established when a Path message is routed through the network from 100 the head-end to its tail-end. 102 As stated in [RFC2205], PathErr messages do not modify the state of 103 any node through which they pass; they are only reported to the head- 104 end of the TE LSP (Traffic Engineering Label Switched Path). 106 The format of the PathErr message as defined in [RFC2205] is as 107 follows: 109 ::= [ ] 110 111 [ ...] 112 [ ] 114 ::= 115 [ ] 117 The ERROR_SPEC object includes the IP address of the node that 118 detected the error (Error Node Address), and specifies the error 119 through two fields. The Error Code field encodes the category of the 120 error, for example, Policy Control Failure or Unknown object class. 121 The Error Value field qualifies the error code to indicate the error 122 with more precision. [RFC3209] extends RSVP as defined in [RFC2205] 123 for the management of Multi-Protocol Label Switching (MPLS) Traffic 124 Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies 125 several additional conditions that trigger the sending of a RSVP 126 PathErr message for which new error codes and error values have been 127 defined that extend the list defined in [RFC2205]. The exact 128 circumstances under which a TE LSP is preempted and such PathErr 129 messages are sent are defined in [RFC3209] and will not be repeated 130 here. 132 Values for the Error Code and Error Value fields defined in 133 [RFC2205], [RFC3209], and other documents are maintained in a 134 registry by the IANA. 136 The error conditions fall into two categories: 138 o Fatal errors represent disruptive conditions for a TE LSP, 140 o Non-fatal errors are non-disruptive conditions which have occurred 141 for this TE LSP 143 Additionally, PathErr messages may be used in two circumstances: 145 o During TE LSP establishment, 147 o After a TE LSP has been successfully established. 149 Nodal behavior is dependent on which combination of the four cases 150 listed above applies. The following sections describe the expected 151 behavior at nodes that perform a preemption action for a TE LSP (and 152 therefore report using error PathErr messages), and at nodes that 153 receive PathErr messages. This text is a clarification and re- 154 statement of the procedures set out in [RFC3209] and does not define 155 any new behavior. 157 2.1. Behavior at Detecting Nodes 159 In the case of fatal errors, the detecting node must send a PathErr 160 message reporting the error condition, and must clear the 161 corresponding Path and Resv (control plane) states. A direct 162 implication is that the data plane resources of such a TE LSP are 163 also released, thus resulting in traffic disruption. It should be 164 noted, however, that in fatal error cases, the LSP has usually 165 already failed in the data plane, and traffic has already been 166 disrupted. When the error arises during LSP establishment, the 167 implications are different to when it arises on an active LSP since 168 no traffic flows until the LSP has been fully established. In the 169 case of non-fatal errors, the detecting node should send a PathErr 170 message, and must not clear control plane or data plane state. 172 2.2. Behavior at Receiving Nodes 174 Nodes that receive PathErr messages are all of the nodes along the 175 path of the TE LSP upstream of the node that detected the error. 176 This includes the head-end node. In accordance with [RFC2205] a node 177 receiving a PathErr message takes no action upon it and consequently 178 it must not clear Path or Resv control plane or data plane state. 179 This is true regardless of whether the error condition reported by 180 the PathErr is fatal or non-fatal. RSVP states should only be 181 affected upon receiving a PathTear or ResvTear message, or in the 182 event of a Path or Resv state timeout. Further discussion of the 183 processing of these events is outside the scope of this document. 184 Note that [RFC3473] defines a Path_State_Removed flag in the 185 ERROR_SPEC object carried on a PathErr message. This field may be 186 set to change the behavior of upstream nodes that receive the PathErr 187 message. When set, the flag indicates that the message sender has 188 removed Path state (and any associated Resv and data plane state) for 189 the TE LSP. The message receiver should do likewise before 190 forwarding the message, but may retain state and clear the flag 191 before forwarding the message. 193 2.3. Data Plane Behavior 195 Any node clearing either or both the Path or the Resv state of a TE 196 LSP MUST also free up the data plane resources allocated to the 197 corresponding TE LSP. 199 3. RSVP PathErr Messages For a Preempted TE LSP 201 Two Error-code can be used to report a preempted TE LSPs: 203 o As defined in [RFC2750]:Error Code=2: "Policy Control Failure", 204 Error Value=5 "Flow was preempted" 206 o As defined in [RFC2205], Error Code=12: "Service preempted" 208 In both cases, these are fatal errors. 210 4. IANA Considerations 212 This document does not define any new protocol extensions and thus no 213 action is requested to IANA. 215 5. Security Considerations 217 This document does not define any new procedures, but clarifies those 218 defined in other documents where security considerations are already 219 specified. This document does not raise specific security issues 220 beyond those of existing MPLS-TE. By clarifying the procedures, this 221 document reduces the security risk introduced by non-conformant 222 implementations. 224 6. Acknowledgements 226 The author would like to thank Carol Iturralde, Ashok Narayanan, Rom 227 Reuther and Reshad Rahman. 229 7. Normative References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997. 234 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 235 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 236 Functional Specification", RFC 2205, September 1997. 238 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 239 RFC 2750, January 2000. 241 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 242 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 243 Tunnels", RFC 3209, December 2001. 245 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 246 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 247 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 249 Authors' Addresses 251 JP Vasseur (editor) 252 Cisco Systems, Inc 253 1414 Massachusetts Avenue 254 Boxborough, MA 01719 255 USA 257 Email: jpv@cisco.com 258 George Swallow 259 Cisco Systems, Inc 260 1414 Massachusetts Avenue 261 Boxborough, MA 01719 262 USA 264 Email: swallow@cisco.com 266 Ina Minei 267 Juniper Networks 268 1194 North Mathilda Ave. 269 Sunnyvale, 94089 271 Email: ina@juniper.net