idnits 2.17.1 draft-aa-mpls-ldp-link-shut-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document updates RFC5036, but the abstract doesn't seem to directly say this. It does mention RFC5036 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5036, updated by this document, for RFC5378 checks: 2004-10-12) -- 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 3, 2019) is 1697 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network M. Anush 3 Internet-Draft T. Anupkumar 4 Updates: 5036 (if approved) Ericsson 5 Intended status: Standards Track September 3, 2019 6 Expires: March 6, 2020 8 LDP behaviour on link-shut scenarios 9 draft-aa-mpls-ldp-link-shut-00 11 Abstract 13 This document is intended as clarification of LDP behaviour in link- 14 down scenarios. Base LDP RFC5036 lacks sufficient clarity on what an 15 LDP enabled node should be doing when a link down event is received, 16 and the only LDP adjacency for an LDP peer is over this link. 17 Different vendors have handled this scenario differently, with some 18 immediately resetting tcp session with neighbor and some waiting for 19 igp recovergence instead of reacting directly to link events. With 20 this document we intend to clarify the expected behaviour explicitly 21 so that any interop issues can be avoided. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 6, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 2 60 4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerationss . . . . . . . . . . . . . . . . . . . . 4 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 67 1. Introduction 69 [RFC5036] details LDP specification and procedures to be followed by 70 LDP implementations. However, for some scenarios like link down, the 71 rfc isn't particularly clear as to what an implementation is supposed 72 to do. This could lead to interop issues when routers from different 73 vendors are part of the network. More details are given in the 74 problem description section below. A possible solution is also 75 suggested in the subsequent sections. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 o LDP: Label distribution protocol. 87 o GR: Graceful-restart. 89 3. Problem Description 91 Consider the following topology: 93 E 94 | 95 | 96 A --- B 97 | | 98 | | 99 C --- D 101 Figure 1: Example topology for LDP 103 All the nodes here are LDP enabled and also support GR. We have an 104 lsp from C-E via C-A-E path(this is igp bestpath). IGP has also 105 computed LFA backup for this primary-lsp via C-D-B-A-E path and we 106 have LDP lfa backup as well (taking this path). 108 Now, lets bring down A-C link. Node A has detected link-shut event 109 and since this link is the only adjacency to LDP-neighbor C, it 110 resets the LDP session and sends shutdown to neighbour C. 112 At C, the link-down event is detected bit late and subsequently the 113 IGP update is also delayed. Meanwhile, C has received shutdown from 114 peer A, and it results in C flushing all labels received from A. 115 Since the primary-label for C-E lsp is no longer available (from A), 116 the lsp itself is deleted by LDP, as LDP can't be congruent with IGP. 117 This LDP-lsp flap can in turn impact l3vpn/l2vpn traffic which are 118 dependent on this LSP. 120 We can definitely reduce traffic-loss by running BFD and switching 121 traffic to lfa backup in forwarding, but the intention above is to 122 highlight that IGP updates and subsequently LDP updates would be 123 asynchronous at nodes A and C, which may be more prominent if there 124 are routers with different capabilities (and maybe from different 125 vendors) in the network. So even if traffic has moved to lfa-backup 126 lsp in forwarding, the primary-lsp itself could be deleted by the 127 shutdown message (which is a fatal error). 129 4. Solutions 131 When a node has LDP adjacency to its neighbor (With GR [RFC3478] 132 enabled on both the node and its neighbor) over a 'single' directly 133 connected link and that link goes down, the node MAY reset the tcp 134 session with neighbor. However, it MUST NOT send shutdown message, 135 which flushes advertised labels at neighbor immediately. 137 The neighbor itself could have different backup mechanisms (ldp-lfa, 138 rsvp-bypass etc) to ensure minimal traffic loss in forwarding for 139 lsps having this node as active(primary)-path. Transmitting shutdown 140 message immediately could result in neighbor prematurely deleting 141 LSPs instead of letting IGP recoverge. 143 Another approach could be to avoid reacting immediately to link down 144 events. Instead, let hello timeout bringdown the session and update 145 LSP-paths as soon as IGP reconverges. 147 Both approaches can help to avoid traffic loss by accounting for 148 asynchronous ordering of events in LDP-peering routers. 150 5. Security Considerations 152 The security considerations described in RFC5036 apply to this 153 document. 155 6. IANA Considerationss 157 7. Acknowledgments 159 . 161 8. Normative References 163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 164 Requirement Levels", BCP 14, RFC 2119, 165 DOI 10.17487/RFC2119, March 1997, 166 . 168 [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful 169 Restart Mechanism for Label Distribution Protocol", 170 RFC 3478, DOI 10.17487/RFC3478, February 2003, 171 . 173 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 174 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 175 October 2007, . 177 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 178 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 179 May 2017, . 181 Authors' Addresses 182 Anush Mohan 183 Ericsson 184 Bangalore 185 India 187 Email: anush.mohan@ericsson.com 189 Anupkumar T 190 Ericsson 191 Bangalore 192 India 194 Email: anupkumar.t@ericsson.com