idnits 2.17.1 draft-ietf-mpls-3209-patherr-06.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (September 28, 2009) is 5321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: Standards Track Cisco Systems, Inc 4 Expires: April 1, 2010 Ina. Minei 5 Juniper Networks 6 September 28, 2009 8 Node behavior upon originating and receiving Resource ReserVation 9 Protocol (RSVP) Path Error message 10 draft-ietf-mpls-3209-patherr-06.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 April 1, 2010. 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The aim of this document is to describe a common practice with regard 49 to the behavior of a node sending a Resource ReserVation Protocol 50 (RSVP) Traffic Engineering (TE) Path Error message and to the 51 behavior of a node receiving an RSVP Path Error message for a 52 preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS 53 (GMPLS) Traffic Engineering Label Switched Path (TE LSP). This 54 document does not define any new protocol extensions. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4 67 2.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 4 68 2.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5 69 3. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 The aim of this document is to describe a common practice with regard 81 to the behavior of a node sending a Resource ReserVation Protocol 82 (RSVP) Traffic Engineering (TE) Path Error message and to the 83 behavior of a node receiving an RSVP Path Error message for a 84 preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS 85 (GMPLS) Traffic Engineering Label Switched Path (TE LSP) (for 86 reference to the notion of TE LSP preemption see [RFC3209]). 88 [RFC2205] defines two RSVP error message types: PathErr and ResvErr 89 that are generated when an error occurs. Path Error Messages 90 (PathErr) are used to report errors and travel upstream toward the 91 head-end of the flow. Resv Error messages (ResvErr) travel 92 downstream toward the tail-end of the flow. 94 This document describes only PathErr message processing for the 95 specific case of a preempted Traffic Engineering Label Switched Path 96 (TE LSP) where the term preemption is defined in [RFC3209]. 98 2. Protocol behavior 100 PathErr messages are routed hop-by-hop using the path state 101 established when a Path message is routed through the network from 102 the head-end to its tail-end. 104 As stated in [RFC2205], PathErr messages do not modify the state of 105 any node through which they pass; they are only reported to the head- 106 end of the TE LSP (Traffic Engineering Label Switched Path). 108 The format of the PathErr message is defined in Section 3. of 109 [RFC2205]. 111 The ERROR_SPEC object includes the IP address of the node that 112 detected the error (Error Node Address), and specifies the error 113 through two fields. The Error Code field encodes the category of the 114 error, for example, Policy Control Failure or Unknown object class. 115 The Error Value field qualifies the error code to indicate the error 116 with more precision. [RFC3209] extends RSVP as defined in [RFC2205] 117 for the management of Multi-Protocol Label Switching (MPLS) Traffic 118 Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies 119 several additional conditions that trigger the sending of a RSVP 120 PathErr message for which new error codes and error values have been 121 defined that extend the list defined in [RFC2205]. The exact 122 circumstances under which a TE LSP is preempted and such PathErr 123 messages are sent are defined in Section 2.2 of [RFC3209] and will 124 not be repeated here. 126 Values for the Error Code and Error Value fields defined in 127 [RFC2205], [RFC3209], and other documents are maintained in a 128 registry by the IANA. 130 The error conditions fall into two categories: 132 o Fatal errors represent disruptive conditions for a TE LSP, 134 o Non-fatal errors are non-disruptive conditions which have occurred 135 for this TE LSP 137 PathErr messages may be used in two circumstances: 139 o During TE LSP establishment, 141 o After a TE LSP has been successfully established. 143 Nodal behavior is dependent on which combination of the four cases 144 listed above applies. The following sections describe the expected 145 behavior at nodes that perform a preemption action for a TE LSP (and 146 therefore report using error PathErr messages), and at nodes that 147 receive PathErr messages. This text is a clarification and re- 148 statement of the procedures set out in [RFC3209] and does not define 149 any new behavior. 151 2.1. Behavior at Detecting Nodes 153 In the case of fatal errors ("Hard Preemption" see section 4.7.3 of 154 [RFC3209]), the detecting node SHOULD send a PathErr message 155 reporting the error condition, and clears the corresponding Path and 156 Resv (control plane) states. A direct implication is that the data 157 plane resources of such a TE LSP are also released, thus resulting in 158 traffic disruption. It should be noted, however, that in fatal error 159 cases, the LSP has usually already failed in the data plane, and 160 traffic has already been disrupted. When the error arises during LSP 161 establishment, the implications are different to when it arises on an 162 active LSP since no traffic flows until the LSP has been fully 163 established. In the case of non-fatal errors, the detecting node 164 should send a PathErr message, and must not clear control plane or 165 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] 172 Section 3.7.1, a node receiving a PathErr message takes no action 173 upon it and consequently it must not clear Path or Resv control plane 174 or data plane state. This is true regardless of whether the error 175 condition reported by the PathErr is fatal or non-fatal. RSVP states 176 should only be affected upon receiving a PathTear or ResvTear 177 message, or in the event of a Path or Resv state timeout. Further 178 discussion of the processing of these events is outside the scope of 179 this document. 181 Note that [RFC3473] defines a Path_State_Removed flag in the 182 ERROR_SPEC object carried on a PathErr message. This field may be 183 set to change the behavior of upstream nodes that receive the PathErr 184 message. When set, the flag indicates that the message sender has 185 removed Path state (and any associated Resv and data plane state) for 186 the TE LSP. The message receiver should do likewise before 187 forwarding the message, but may retain state and clear the flag 188 before forwarding the message. 190 2.3. Data Plane Behavior 192 Any node clearing either or both the Path or the Resv state of a TE 193 LSP MUST also free up the data plane resources allocated to the 194 corresponding TE LSP. 196 3. RSVP PathErr Messages For a Preempted TE LSP 198 Two Error-code have been defined to report a preempted TE LSP: 200 o As defined in [RFC2750]:Error Code=2: "Policy Control Failure", 201 Error Value=5 "Flow was preempted" 203 o As defined in [RFC2205], Error Code=12: "Service preempted" 205 In both cases, these are fatal errors. 207 4. IANA Considerations 209 This document does not define any new protocol extensions and thus no 210 action is requested to IANA. 212 5. Security Considerations 214 This document does not define any new procedures, but clarifies those 215 defined in other documents where security considerations are already 216 specified in [RFC3209] and [RFC3473]. This document does not raise 217 specific security issues beyond those of existing MPLS-TE. By 218 clarifying the procedures, this document reduces the security risk 219 introduced by non-conformant implementations. See 220 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] for further 221 discussion of MPLS security issues. 223 6. Acknowledgements 225 The author would like to thank Carol Iturralde, Ashok Narayanan, Rom 226 Reuther and Reshad Rahman. 228 7. References 230 7.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 236 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 237 Functional Specification", RFC 2205, September 1997. 239 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 240 RFC 2750, January 2000. 242 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 243 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 244 Tunnels", RFC 3209, December 2001. 246 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 247 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 248 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 250 7.2. Informative References 252 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] 253 Fang, L. and M. Behringer, "Security Framework for MPLS 254 and GMPLS Networks", 255 draft-ietf-mpls-mpls-and-gmpls-security-framework-06 (work 256 in progress), July 2009. 258 Authors' Addresses 260 JP Vasseur (editor) 261 Cisco Systems, Inc 262 1414 Massachusetts Avenue 263 Boxborough, MA 01719 264 USA 266 Email: jpv@cisco.com 268 George Swallow 269 Cisco Systems, Inc 270 1414 Massachusetts Avenue 271 Boxborough, MA 01719 272 USA 274 Email: swallow@cisco.com 276 Ina Minei 277 Juniper Networks 278 1194 North Mathilda Ave. 279 Sunnyvale, 94089 281 Email: ina@juniper.net