idnits 2.17.00 (12 Aug 2021) /tmp/idnits56259/draft-smith-mpls-ldp-restart-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 423 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 170: '...s not set (see below), this field MUST...' RFC 2119 keyword, line 182: '...eckpoint Bit set MUST acknowledge the ...' RFC 2119 keyword, line 185: '...eckpoint Bit set MUST contain a non-ze...' RFC 2119 keyword, line 191: '...ed Message ID field MUST be set to the...' RFC 2119 keyword, line 200: '... These 13 bits MUST be filled with z...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the received Cork message's Final bit is set, the receiving peer immediately sends any pending Label Mapping, Label Withdraw, Address, and Address Withdraw messages to the sending peer, followed by a Cork message with the Final bit set in response. This Cork message may also serve to acknowledge receipt of the sending peer's Final Cork message. After sending the Cork message, the receiving peer MUST not send any more Label Mapping, Label Withdraw, Address, or Address Withdraw messages to the sending peer. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) == Outdated reference: draft-martini-l2circuit-trans-mpls has been published as RFC 4906 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. '2') -- Possible downref: Normative reference to a draft: ref. '3' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Toby Smith (Laurel Networks) 2 Internet Draft Andrew G. Malis (Vivace Networks) 3 Expiration Date: April 2002 Jack Shaio (Vivace Networks) 5 Graceful Restart Mechanism for LDP 7 draft-smith-mpls-ldp-restart-00.txt 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working 17 documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed 29 at http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document proposes a lightweight mechanism that the LDP 34 protocol may use to help minimize the impact introduced by 35 transient interruptions to an LDP session's TCP connection, 36 with a focus on connection preservation for signaled Layer 2 37 circuits. A new LDP Cork message request/response mechanism is 38 specified. New message types are defined for the delivery of 39 graceful restart events. Finally, procedures for utilizing this 40 mechanism are detailed. 42 3. Introduction 44 The LDP protocol [1] provides label mapping information to its 45 peer LSRs. In addition to providing label mappings for IP 46 prefixes, LDP has recently been adopted as a signaling 47 mechanism for the establishment of Layer 2 circuits between two 48 provider edge LSRs [2, 3]. Customers expect these circuits, 49 like the physical circuits they emulate, to be highly available 50 connections. 52 Under some circumstances (planned outages, software upgrades), 53 LDP may temporarily lose connectivity to its peer(s). In these 54 circumstances, it is beneficial to the customer to maintain the 55 LDP-established LSPs even in the (temporary) absence of an LDP 56 session. 58 This draft describes a proposal for a lightweight mechanism 59 which allows LDP LSRs to retain their forwarding state, even 60 when the connection to the peer LSR is temporarily lost. 62 The procedure described in this draft has excellent scaling 63 properties: the LDP state is preserved incrementally, such that 64 after an unexpected restart of an LDP session, only the LDP 65 activity not already acknowledged during the previous session 66 needs to be resignaled. In the case of provisioned Layer 2 67 circuits, it is probable that no resignaling will be necessary. 69 The procedure described in this draft is minimally invasive to 70 the LDP state machine and requires no changes to the LDP 71 message processing procedures. 73 This mechanism may be used in conjunction with a mechanism for 74 the preservation of IP forwarding state; when LDP is being used 75 solely as a signaling mechanism for the establishment of Layer 76 2 transports, however, such coordination is not required. 78 The remainder of this document is organized as follows: A new 79 LDP Cork message request/response mechanism is specified. New 80 message types are defined for the delivery of graceful restart 81 events. Finally, procedures for utilizing this mechanism are 82 detailed. 84 4. Overview of Graceful Restart Mechanism 86 LDP LSRs which support this graceful restart mechanism signal 87 this capability with an additional Graceful Restart TLV sent as 88 part of the session's Initialization messages. 90 During normal session operation, each peer periodically issues 91 a Cork message, defined below, which checkpoints the current 92 label advertisement state between the peers. Each cork message 93 is acknowledged by the far end. 95 If an LDP peer is able to recognize that it needs to 96 temporarily drop its connection to its peer, this LSR (termed 97 the Originating Peer) will send a special, final Cork message 98 to each of its peer LSRs (termed the Receiving Peer(s)). 100 When the Receiving Peer receives a final Cork message, it 101 responds with a corresponding final Cork message to the 102 Originating Peer. Upon receiving the final Cork message 103 response from each Receiving Peer, the Originating Peer may 104 sever its TCP connection(s). All forwarding state 105 corresponding to the cached state of the LDP protocol is 106 preserved over the loss of connectivity with the LDP peer. 108 Once the Originating Peer's LDP state is able to be 109 re-established, it reconnects to each of its Receiving Peers, 110 following the standard procedures for establishing TCP 111 connections as specified in [1]. 113 When the TCP session to the Receiving Peer(s) has been 114 re-established, the LSRs exchange Graceful Restart TLVs as part 115 of their Initialization messages. This TLV contains that 116 checkpoint information corresponding to the last exchanged Cork 117 messages, which allows the LSRs to resume operation without 118 readvertising any checkpointed label mapping information. 120 The details of the steps outlined in this section may be found 121 in the Procedures section, below. 123 5. Message Formats 125 This section describes the new LDP message and TLV formats used 126 by this document. 128 5.1 Cork Message 130 The LDP Cork message is sent periodically by each participating 131 LSR. The Cork message may be used to checkpoint currently sent 132 information, to acknowledge the reception of a previously 133 received Cork message, or both. 135 The rate at which periodic Cork messages are sent is locally 136 determined by each participating LSR, and is implementation 137 dependent. For example, cork messages may be sent at regular 138 intervals, or after a threshold of sent LDP messages has been 139 exceeded. Cork updates are not necessary if the state of the 140 LSR has not changed since the time the last Cork message was 141 sent. 143 Cork messages with the Final Bit set are used to flush all 144 currently pending label mapping and nexthop messages to the 145 peer LSR, in anticipation of dropping the connection to the 146 peer. 148 The encoding for the Cork Message is: 150 0 1 2 3 151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |0| Cork (0x3F00) | Message Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Message ID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Acknowledged Message ID | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 |F|C|A| Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Message ID 163 32-bit value used to identify this message. 165 Acknowledged Message ID 166 A 32-bit value used to acknowledge the reception of a prior 167 Cork message from the sender. The receiver replies with a 168 Cork message of its own, with this field set to the Message 169 ID of the Cork message it is acknowledging. If the 170 Acknowledgement Bit is not set (see below), this field MUST 171 be ignored. 173 Final Bit 174 A single bit denoting whether this message is the final 175 checkpointing Cork message that the receiver should expect to 176 receive from the sender. 178 Checkpoint Bit 179 A single bit denoting that this Cork message is being used 180 by the sender to checkpoint its currently sent label and 181 address information. An LSR which receives a Cork message 182 with the Checkpoint Bit set MUST acknowledge the reception 183 of this message with a corresponding Cork message with the 184 Acknowledgement Bit set (see below). Cork messages with 185 the Checkpoint Bit set MUST contain a non-zero Message ID. 187 Acknowledgement Bit 188 A single bit denoting that this Cork message is being used 189 by the sender to acknowledge the reception of a previously 190 received Cork message. When the Acknowledgement Bit is 191 set, the Acknowledged Message ID field MUST be set to the 192 Message ID of the Cork message being acknowledged. 194 A single Cork message may have both the Checkpoint and 195 Acknowledgement Bits set, allowing a single message to 196 both checkpoint recently sent information, as well as 197 acknowledge recently received Cork messages. 199 Reserved 200 These 13 bits MUST be filled with zeroes. 202 5.2 Graceful Restart TLV 204 The Graceful Restart TLV is contained within both the 205 Originating and Receiving Peers' Initialization messages to 206 denote their participation in the graceful restart protocol. 208 The encoding for the Graceful Restart TLV is: 210 0 1 2 3 211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |0|0| Graceful Restart (0x3F00) | Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Acknowledged Message ID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Restart Timeout | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Acknowledged Message ID 221 If the LSR is establishing a connection to a peer for the 222 first time, this field MUST be set to zero. 224 If an LSR is re-establishing a session with a remote peer 225 with which it had previously exchanged Cork messages, and if 226 the local LSR's Restart Timeout time has not expired, this 227 value MUST contain the Message ID of the last successfully 228 acknowledged Cork message received from the remote peer. If 229 the Restart Timeout time has expired, this value MUST be 230 reset to zero. 232 Restart Timeout 233 32-bit unsigned non-zero integer that indicates the number of 234 seconds that the sending LSR is willing to wait for 235 re-establishment of the TCP connection between the peers 236 after a restart has begun. This timer is started when the 237 current TCP connection is terminated. The Restart Timeout 238 MUST be calculated by using the smaller of the values sent in 239 the Graceful Restart TLV to the peer LSR and the Restart 240 Timeout value in the Graceful Restart TLV received from the 241 peer LSR. 243 6. Procedures 245 This section describes in detail the procedures which must be 246 implemented by participating LSRs. 248 An LSR which is capable of participating in this mechanism 249 includes a Graceful Restart TLV in the Initialization message 250 it sends to its remote peer. 252 If the Initialization message received from the remote peer 253 does not contain a Graceful Restart TLV, or if the value 254 contained in the Acknowledged Message ID field is not 255 the value expected from that peer, then the graceful restart 256 mechanism MUST NOT be employed, and no Cork messages may be 257 sent to the remote peer. In this case, if the local LSR has 258 cached any state from a prior session to this peer, that cached 259 state MUST be immediately discarded. 261 For two LSRs which have successfully exchanged Graceful Restart 262 TLVs, the Restart Timeout value used by both LSRs is calculated 263 to be the lesser of the values exchanged by the peers. 265 If this is the first time that the two LSRs have peered, or if 266 the Restart Timeout time from a previous session has expired, 267 the peering LSRs MUST include a value of zero in the 268 Acknowledged Message ID field. 270 When the exchanged Acknowledged Message ID values are 271 non-zero, and neither LSR's Restart Timeout time has expired, 272 both peers MUST resume operation of the LDP session as if all 273 checkpointed sent and received information is still active. 274 Upon returning to such a state, the first message sent by each 275 LSR to its peer MUST be a Cork message with the Acknowledgement 276 Bit set, and the Acknowledged Message ID set to the value 277 contained in the LSR's Graceful Restart TLV Acknowledged 278 Message ID field. If the LSR is unable to restore 279 its state for any reason, it MUST immediately send a Cork 280 message with the Acknowledgement Bit set and containing an 281 Acknowledged Message ID value of zero. In either case, after 282 exchanging Initialization messages with non-zero Acknowledged 283 Message ID values, the first messages exchanged between the 284 peers MUST be Cork messages. 286 If an LSR which is re-establishing cached state after a restart 287 receives an initial Cork message which does not match the value 288 contained in the peer's Graceful Restart TLV, the receiving LSR 289 MUST immediately discard any cached state, as the graceful 290 restart has failed on the peer LSR. 292 After successfully negotiating the use of the graceful restart 293 mechanism, and restoring cached state (if recovering from a 294 prior restart), the peering LSRs resume normal LDP operation. 295 Each LSR periodically checkpoints the label mapping and nexthop 296 information that it has sent to its peer and issues an 297 unsolicited Cork message with the Checkpoint Bit set to its 298 peer. The sending LSR MUST NOT cache the current state of the 299 sent session information until the remote peer acknowledges the 300 receipt of the current Cork message. 302 If the local LSR knows a priori that it is about to restart, it 303 may issue a Cork message with the Final Bit set. After sending 304 a Cork message with the Final bit set, the sending LSR MUST NOT 305 send any further Label Mapping, Label Withdraw, Address, or 306 Address Withdraw messages to the receiving peer. 308 An LSR which receives a Cork message from its peer with the 309 Checkpoint Bit set MUST acknowledge the receipt of this message 310 by responding to the sending peer with a Cork message with the 311 Acknowledgement Bit set. The receiving LSR MUST cache all 312 received session information from the remote peer before 313 acknowledging the reception of a Checkpoint Cork message. 315 If the received Cork message's Final bit is set, the receiving 316 peer immediately sends any pending Label Mapping, Label 317 Withdraw, Address, and Address Withdraw messages to the sending 318 peer, followed by a Cork message with the Final bit set in 319 response. This Cork message may also serve to acknowledge 320 receipt of the sending peer's Final Cork message. After 321 sending the Cork message, the receiving peer MUST not send any 322 more Label Mapping, Label Withdraw, Address, or Address 323 Withdraw messages to the sending peer. 325 An LSR which is expecting to be restarted initiates the 326 graceful restart by sending a Cork message with the Final bit 327 set to its peer. This LSR may restart upon receiving both a 328 corresponding Final Cork message from its peer, and upon 329 receiving a Acknowledgement Cork message from its peer. These 330 two messages may be consolidated into a single message with the 331 Final, Checkpoint and Acknowledgement Bits set. 333 LSRs participating in this graceful restart mechanism do not 334 expect to see a fatal Notification message from their remote 335 peer before restarting. If an LSR sends a fatal Notification 336 message to its remote peer, or receives a fatal Notification 337 from its remote peer, the LSR MUST discard any cached LDP state 338 immediately. 340 7. Operational Considerations 342 This document describes a mechanism for the graceful 343 re-establishment of LDP sessions, with a focus on providing a 344 simple signaling recovery mechanism for Layer 2 transport 345 LSPs. Given that the establishment of IP LSPs via LDP relies 346 upon the existence of an underlying IGP to determine the 347 network topology, a complete graceful restart mechanism 348 requires a degree of coordination between LDP and its 349 underlying IGP when restarting. This document does not address 350 ways in which the IGP state may be preserved during a graceful 351 restart. 353 8. Security Considerations 355 Given that this document describes a mechanism for preserving 356 LDP session state during periods of lost connectivity, there 357 may be concern that this proposal introduces new security 358 risks. However, since the re-establishment of the LDP session 359 is based upon the same mechanisms described in [1], and since 360 the cached LDP session state is only eligible for use if an LDP 361 session is re-established to a peer which had previously been 362 peering with the LSR, the authors believe that this proposal 363 does not impact the underlying security model of LDP. 365 9. References 367 [1] "LDP Specification", L. Andersson, P. Doolan, N. Feldman, 368 A. Fredette, B. Thomas. RFC3036 370 [2] "Transport of Layer 2 Frames Over MPLS", draft-martini- 371 l2circuit-trans-mpls-08.txt. ( work in progress ) 373 [3] "MPLS-based Layer 2 VPNs", Kompella, et. al., draft- 374 kompella-mpls-l2vpn-02.txt. ( work in progress ) 376 10. Author Information 378 Toby Smith 379 Laurel Networks, Inc. 380 1300 Omega Drive 381 Pittsburgh, PA 15205 382 Email: tob@laurelnetworks.com 384 Andrew G. Malis 385 Vivace Networks, Inc. 386 2730 Orchard Parkway 387 San Jose, CA 95134 388 Phone: +1 408 383 7223 389 Email: Andy.Malis@vivacenetworks.com 391 Jack Shaio 392 Vivace Networks, Inc. 393 2730 Orchard Parkway 394 San Jose, CA 95134 395 Phone: +1 408 432 7623 396 Email: Jack.Shaio@vivacenetworks.com