idnits 2.17.00 (12 Aug 2021) /tmp/idnits42827/draft-rahman-ccamp-rsvp-restart-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Missing revision: the document name given in the document, 'draft-rahman-ccamp-rsvp-restart-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-rahman-ccamp-rsvp-restart-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-rahman-ccamp-rsvp-restart-', but the file name used is 'draft-rahman-ccamp-rsvp-restart-extensions-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' security considerations pertaining to the original RSVP' ) ** 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.) ** There are 105 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], R5,, [R2,R3,, [R2,R6], [RFC3471], [RFC2119], [RFC3473], [RFC3477], [R3,R4,, [RFC3209], R6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 158 has weird spacing: '... one of the E...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 2004) is 6663 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) -- Missing reference section? 'RFC3473' on line 362 looks like a reference -- Missing reference section? 'RFC2119' on line 369 looks like a reference -- Missing reference section? 'RFC3209' on line 357 looks like a reference -- Missing reference section? 'R3' on line 252 looks like a reference -- Missing reference section? 'R4' on line 252 looks like a reference -- Missing reference section? 'R5' on line 252 looks like a reference -- Missing reference section? 'R6' on line 252 looks like a reference -- Missing reference section? 'R2' on line 241 looks like a reference -- Missing reference section? 'RFC2205' on line 354 looks like a reference -- Missing reference section? 'RFC3471' on line 359 looks like a reference -- Missing reference section? 'RFC3477' on line 366 looks like a reference Summary: 12 errors (**), 1 flaw (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group 3 Internet Draft Reshad Rahman, 4 Anca Zamfir, 5 Junaid Israr 6 Cisco Systems 7 Document: draft-rahman-ccamp-rsvp-restart- 8 extensions.txt 9 Expires: August 2004 February 2004 11 RSVP Graceful Restart Extensions 13 draft-rahman-ccamp-rsvp-restart-extensions-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance 18 with all provisions of Section 10 of RFC2026. Internet-Drafts 19 are working documents of the Internet Engineering Task Force 20 (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet- 22 Drafts. 23 Internet-Drafts are working documents of the Internet 24 Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as 31 "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed 35 at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes the extensions needed by certain 41 features for the purpose of RSVP Graceful Restart (defined 42 in[RFC3473]). One of these extensions refers to the ability of 43 a node to recover the ERO in the case it has performed an ERO 44 expansion before control plane restart. Also a small 45 modification is proposed in the basic procedure to support 46 simultaneous multiple node restarts in a network. 47 Specifically, a node should use a non-zero Recovery Time while 48 in the recovery phase. This allows a node to determine at 49 restart time if any of its neighbors has previously restarted 50 and it is currently in the recovery phase. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 55 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 56 "OPTIONAL" in this document are to be interpreted as described 57 in RFC 2119 [RFC2119]. 59 Routing ID Summary 61 (This section to be removed before publication.) 63 SUMMARY 65 This document specifies extensions and mechanisms to RSVP 66 Graceful Restart to provide support for ERO Recovery and 67 multiple node restart. 69 WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING WORK? 71 This work fits in the context of [RFC3473]. 73 WHY IS IT TARGETED AT THIS WG? 75 This draft is targeted at this WG, because it specifies 76 extensions to RSVP graceful restart which is defined in 77 [RFC3473]. 79 RELATED REFERENCES 81 Please refer to the reference section. 83 Table of Contents 85 1. 86 Terminology 88 GR - Graceful Restart procedure for RSVP as specified in 89 [RFC3473]. 91 2. 92 RSVP Graceful Restart 94 The procedure for RSVP Graceful Restart (GR) is described 95 in [RFC3473]. The purpose of this procedure is to allow a node 96 that has experienced a failure in the control plane but that 97 has preserved its forwarding plane to recreate its states 98 based on replayed RSVP messages received from its neighbors 99 and also based on information retrieved from the forwarding 100 plane. Typically, the data that can be obtained from the 101 forwarding plane for each LSP endpoint is (port, label). At 102 mid, control plane obtains also the cross-connect information: 103 (ingress-port, ingress-label) X (egress-port, egress-label) 105 While most of the objects can be recovered based on these two 106 sources of information, the route information that is 107 contained in the ERO object cannot be recovered if the 108 restarting node has modified the ERO content prior to restart. 109 Section 3 proposes a solution for this problem. 111 The GR procedure described in [RFC3473] handles some cases of 112 multiple node restart. In the example below, assume that one 113 LSP was signaled by R1 to span L1, R2, L2, R3. 115 L1 L2 116 R1 ----- R2 ----- R3 118 If R2 restarts and then R3 restarts after the Hellos have come 119 up, then as described in [RFC3473], R2 is able to detect that 120 R3 has restarted and if R2 is in the recovery mode when R3 has 121 restarted, when R2 receives a recovery message from R1 it 122 sends a recovery message to R3. For the LSP described before, 123 R1 sends the Path message including a Recovery Label and R2 124 also includes a Recovery Label in the Path message sent to R3. 126 If R2 restarts and then R3 restarts before the Hellos have 127 come up, then there is no specified way for R2 to detect that 128 R3 has restarted and is currently in Recovery Mode. Therefore, 129 when R2 receives the Path message with the Recovery Label from 130 R1, after processing it, R2 sends the corresponding outgoing 131 Path message to R3 with Suggested Label instead of the 132 Recovery Label. This is incorrect since this message must 133 include the Recovery Label in order to help R3 recover its 134 state. 136 A solution for this problem is described in Section 4. 138 3. 139 ERO Recovery 141 If a node experiences a control plane failure and restarts, 142 the existing GR procedures do not ensure that ERO expansion 143 before and after the failure yield the same results. A change 144 in ERO expansion should be avoided as it may lead to 145 undesirable results. 147 This section describes how such a change can be prevented. To 148 support this solution, a new RSVP object, called Recovery ERO 149 is introduced. 151 3.1 152 Recovery ERO Object 154 The Recovery ERO object is used during nodal fault recovery 155 process. The format of Recovery ERO object is identical to 156 that of the ERO object described in [RFC3209]. A Recovery ERO 157 object uses Class-Number ?? (of form 10bbbbbb) and the same C- 158 Type as the one of the ERO object it is trying to recover. 159 Only C-Type = 1 is currently supported. 161 3.2 162 Procedures at the Restarting Node and its Neighbors 164 When a node experiences control plane restart and receives a 165 Path message with Recovery Label from the upstream node, it 166 searches for a matching forwarding state as per [RFC3473]. If 167 no matching state is found and if ERO expansion is required, 168 then the node considers the Path message as a new LSP. It 169 processes the incoming Path message and performs ERO expansion 170 as specified in [RFC3473], [RFC3209]. If the forwarding state 171 is found and if ERO expansion is required, then the node 172 processes the incoming Path message as specified in [RFC3473], 173 [RFC3209] with following modifications: 175 1. It performs partial ERO expansion at this point to include: 176 - the strict next hop that is contained in the forwarding 177 state. 178 - the loose hop as in the ERO of the received Path message. 179 2. It includes the result of the previous step in the Recovery 180 ERO object to be sent as part of the outgoing Path message. 181 3. The restarting node sends the outgoing Path message out. 183 When the Path message is received by the neighbor downstream 184 of the restarting node, the following processing occurs: 186 4. If this message has associated incoming Path and forwarding 187 states, the neighbor node retrieves the ERO object as it was 188 previously created by the restarting node and formats a new 189 Recovery ERO object with this content to be sent upstream. 191 5. If this message has neither an associated incoming Path 192 state nor a forwarding state, then this should be treated as a 193 normal setup. 195 6. If this message has no associated Path state but forwarding 196 state is present, then this node is restarting as well and the 197 procedure of the restarting node applies. Once the outgoing 198 Path state is recovered, this node retrieves the outgoing ERO 199 and creates the Recovery ERO object by prepending one or more 200 strict elements as identified by forwarding entry associated 201 with this LSP on this abstract node. 203 If a new upstream Recovery ERO object is available after 204 executing the steps 4, 5 and 6, then the neighbor node 205 includes the upstream ERO content in a Recovery ERO object to 206 be sent upstream in the Resv message. 208 When the restarting node receives the Resv message (after step 209 3), it removes the Recovery ERO object before creating the 210 Reservation State and uses its content to update the ERO in 211 the associated Path State. 213 In the case where restarting node determines that the 214 downstream node has not been able to include the expanded ERO 215 (e.g. downstream node is also a restarting node and forwarding 216 has not been preserved), the restarting node performs the 217 expansion as described in [RFC3473], [RFC3209]. In this case 218 the recovery of the LSP is not guaranteed. 220 Below is an example that covers the steps above: 222 Assume a simple topology as follows: 224 R1 ----- R2 ----- R3 ----- R5 ----- R6 225 | | 226 ----R4---- 228 1. R1 sends a Path message to R2 with an ERO containing [R2, 229 R6(loose)]. R2 performs ERO expansion [R3, R4, R5, R6] and 230 forwards the Path message to R3. R3 stores this ERO and LSP 231 gets established using normal LSP setup procedures. 233 2. The control plane on R2 restarts. 235 3. R2 receives a Path message with Recovery Label and ERO = 236 [R2, R6(loose)]. R2 finds the forwarding state and creates 237 the incoming Path state with ERO = [R2, R6]. 239 4. Based on the forwarding state, R2 determines that the next 240 hop is R3. R2 creates an outgoing Path State with a Recovery 241 ERO = [R2, R3, R6] and forwards the Path message to R3. 243 5. R3 finds the associated incoming Path State with ERO = [R3, 244 R4, R5, R6] and creates a Recovery ERO with this content. R3 245 sends the Resv message upstream including the Recovery ERO 246 object that contains: [R3, R4, R5, R6] 248 6. R2 receives the Resv message, removes the Recovery ERO 249 object and creates the Reservation state. 251 7. R2 uses the Recovery ERO from the Resv message to create 252 the ERO of the outgoing Path State as [R3, R4, R5, R6] and 253 removes the Recovery ERO. 255 4. 256 Handling Multiple Restarts 258 If a node (R2 below) experiences a control plane failure 259 and if this node implements Graceful Restart procedure 260 described in [RFC3473], then it can correctly recover all RSVP 261 states it had prior to restart. 263 During recovery, new LSPs may be established as long as 264 they do not collide with the LSPs that are in progress of 265 being recovered. If a Path message that includes a Suggested 266 Label is received and if the restarting node checks its 267 forwarding and determines that a previous LSP was using the 268 (ingress-port, ingress-label), the new request may get 269 rejected. It may also get accepted with an upstream label 270 different than the one suggested in the Suggested Label. 272 R0 ----- R1 ----- R2 ----- R3 274 With the current specification, if a node R1 upstream of 275 the restarting node R2 is also in the recovery phase, then the 276 only case where the LSP is recovered is when R1 has restarted 277 prior to R2. In this case R1 determines based on the Hello 278 session that R2 has restarted and therefore it sends Path 279 Messages with Recovery Label for the LSPs that need to be 280 recovered. 282 In the case R1 restarted after R2, R1 cannot determine 283 based on the Hello Instance that R2 is a restarting node. When 284 R1 receives recovery Path messages from its upstream node, it 285 sends Path messages with Suggested Label to R2 as indicated in 287 [RFC3473]. R2 does not use the Suggested Label in this case. 288 This is because its forwarding indicates that a Recovery Path 289 message may be received from R1. In fact, it may setup a new 290 LSP using a different label. 292 In the case of GMPLS, messages from different upstream 293 neighbors may be received on the same interface which may be 294 different from the interface hosting the LSP to be recovered. 296 This draft proposes the use of Recovery Time value received 297 by a restarting node as an indication that its downstream 298 neighbor is in recovery mode. 300 A node that complies with this specification sends non-zero 301 Recovery Time while in recovery mode and MUST set it to 0 once 302 its recovery has completed. 304 The alternative solution is to require restarting nodes 305 that receive a Path with Recovery Label to forward, after 306 processing, a Path with Recovery Label and not Suggested 307 Label. 309 To allow for recovery to complete, a restarting node may 310 wish to adjust its advertised Recovery Time when an upstream 311 node restarts, in an attempt to prevent the downstream nodes 312 to expire states that may be recovered later than expected. 314 5. 315 Forward Compatibility Note 317 A node that does not support the Recovery ERO object and 318 the procedure described in this draft, will ignore the 319 Recovery ERO object and responds with a Resv. A restarting 320 node may choose to continue the recovery by performing a new 321 ERO expansion. In the case where the new ERO matches the ERO 322 before restart the LSP is recovered. Otherwise, depending on 323 the downstream node implementations, the LSP may be torn down. 325 The extensions specified in this draft do not affect the 326 processing of the Restart Cap object at nodes that do not 327 support them. 329 A node that does not comply with this specification and has no 330 proprietary way to detect at restart time the downstream 331 neighbors that have previously restarted and that are in the 332 recovery mode, may ignore the Recovery Time in the Restart_Cap 333 object and may forward only Path messages with Suggested 334 Label. 336 A node that does comply with this specification and that 337 receives a Restart_Cap object with a non-zero Recovery Time 338 from a downstream node that does not comply with this 339 specification, forwards Path messages with Recovery Label 340 included for all recovered LSPs while in the recovery period. 341 If in fact the downstream node is not in Recovery mode and 342 receives a Path message with a Recovery Label, it should 343 generate a Resv message and normal state processing continues. 345 6. 346 Security Considerations 348 This document does not introduce new security issues. The 349 security considerations pertaining to the original RSVP 350 protocol [RFC2205] remain relevant. 352 References 354 [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, 355 Functional Specification", RFC 2205, Braden, et al, 356 September 1997. 357 [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et 358 al, RFC 3209, December 2001. 359 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 360 Signaling Functional Description", RFC 3471, L. Berger, et 361 al, January 2003. 362 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 363 Signaling Resource ReserVation Protocol-Traffic Engineering 364 (RSVP-TE) Extensions", RFC 3471, L. Berger, et al, January 365 2003. 366 [RFC3477] "Signaling Unnumbered Links in Resource ReSerVation 367 Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. 368 Kompella, Y. Rekhter, January 2003. 369 [RFC2119] "Key words for use in RFCs to Indicate Requirement 370 Levels", RFC 2119, S. Bradner, March 1997. 372 Author's Addresses 374 Reshad Rahman 375 Cisco Systems Inc. 376 2000 Innovation Dr., 377 Kanata, Ontario, K2K 3E8 378 Canada. 379 Phone: (613)-254-3519 380 Email: rrahman@cisco.com 381 Anca Zamfir 382 Cisco Systems Inc. 383 2000 Innovation Dr., 384 Kanata, Ontario, K2K 3E8 385 Canada. 386 Phone: (613)-254-3484 387 Email: ancaz@cisco.com 389 Junaid Israr 390 Cisco Systems Inc. 391 2000 Innovation Dr., 392 Kanata, Ontario, K2K 3E8 393 Canada. 394 Phone: (613)-254-3693 395 Email: jisrar@cisco.com