idnits 2.17.1 draft-mirsky-bfd-mpls-demand-10.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 : ---------------------------------------------------------------------------- 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 date (1 October 2021) is 931 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track 1 October 2021 5 Expires: 4 April 2022 7 BFD in Demand Mode over Point-to-Point MPLS LSP 8 draft-mirsky-bfd-mpls-demand-10 10 Abstract 12 This document describes procedures for using Bidirectional Forwarding 13 Detection (BFD) in Demand mode to detect data plane failures in 14 Multiprotocol Label Switching (MPLS) point-to-point Label Switched 15 Paths. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 4 April 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions used in this document . . . . . . . . . . . . . . 2 52 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 3. Use of the BFD Demand Mode . . . . . . . . . . . . . . . . . 3 55 3.1. The Applicability of BFD for Multipoint Networks . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 59 7. Informative References . . . . . . . . . . . . . . . . . . . 6 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 [RFC5884] defined use of the Asynchronous method of Bidirectional 66 Detection (BFD) [RFC5880] to monitor and detect failures in the data 67 path of a Multiprotocol Label Switching (MPLS) Label Switched Path 68 (LSP). Use of the Demand mode, also specified in [RFC5880], has not 69 been defined so far. This document describes procedures for using 70 the Demand mode of BFD protocol to detect data plane failures in MPLS 71 point-to-point (p2p) LSPs. 73 2. Conventions used in this document 75 2.1. Terminology 77 MPLS: Multiprotocol Label Switching 79 LSP: Label Switched Path 81 LER: Label switching Edge Router 83 BFD: Bidirectional Forwarding Detection 85 p2p: Point-to-Point 87 2.2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 3. Use of the BFD Demand Mode 97 [RFC5880] defines that the Demand mode MAY be: 99 * asymmetric, i.e. used in one direction of a BFD session; 101 * switched to and from without bringing BFD session to Down state 102 through using a Poll Sequence. 104 For the case of BFD over MPLS LSP, ingress Label switching Edge 105 Router (LER) usually acts as Active BFD peer and egress LER acts as 106 Passive BFD peer. The Active peer bootstraps the BFD session by 107 using LSP ping. If the BFD session is configured to use the Demand 108 mode, once the BFD session is in Up state the ingress LER MUST switch 109 to the Demand mode as defined in Section 6.6 [RFC5880]. The egress 110 LER also follows procedures defined in Section 6.6 [RFC5880] and 111 ceases further transmission of periodic BFD control packets to the 112 ingress LER. 114 In this state BFD peers MAY remain as long as the egress LER is in Up 115 state. The ingress LER SHOULD periodically check continuity of a 116 bidirectional path between the ingress and egress LERs by using the 117 Poll Sequence, as described in Section 6.6 [RFC5880]. An 118 implementation that supports using the Poll Sequence as the mechanism 119 for bidirectional path continuity check MUST be able to control the 120 interval between consecutive Poll Sequences. The RECOMMENDED default 121 value is 1 second. 123 If the Detection timer at the egress LER expires it MUST send BFD 124 Control packet to the ingress LER with the Poll (P) bit set, Status 125 (Sta) field set to the Down value, and the Diagnostic (Diag) field 126 set to Control Detection Time Expired value. The egress LER 127 periodically transmits these Control packets to the ingress LER until 128 either it receives the valid for this BFD session control packet with 129 the Final (F) bit set from the ingress LER or the defect condition 130 clears and the BFD session state reaches Up state at the egress LER. 131 An implementation that supports this specification MUST provide 132 control of the interval between consecutive Poll messages signaling 133 the expiration of the Detection timer. The RECOMMENDED default value 134 of the interval is 1 second. 136 The ingress LER transmits BFD Control packets over the MPLS LSP with 137 the Demand (D) flag set at negotiated interval per [RFC5880], the 138 greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, 139 until it receives the valid BFD packet from the egress LER with the 140 Poll (P) bit and the Diagnostic (Diag) field value Control Detection 141 Time Expired. Reception of such BFD control packet by the ingress 142 LER indicates that the monitored LSP has a failure and sending BFD 143 control packet with the Final flag set to acknowledge failure 144 indication is likely to fail. Instead, the ingress LER transmits the 145 BFD Control packet to the egress LER over the IP network with: 147 * destination IP address MUST be set to the destination IP address 148 of the LSP Ping Echo request message [RFC8029]; 150 * destination UDP port set to 4784 [RFC5883]; 152 * Final (F) flag in BFD control packet MUST be set; 154 * Demand (D) flag in BFD control packet MUST be cleared. 156 The ingress LER changes the state of the BFD session to Down and 157 changes rate of BFD Control packets transmission to one packet per 158 second. The ingress LER in Down mode changes to Asynchronous mode 159 until the BFD session comes to Up state once again. Then the ingress 160 LER switches to the Demand mode. 162 3.1. The Applicability of BFD for Multipoint Networks 164 [RFC8562] defines the use of BFD in multipoint networks. This 165 specification analyzes the case of p2p LSP. In that scenario, the 166 ingress of the LSP acts as the MultipointHead, and the egress - as 167 MultipointTail. The BFD state machines for MultipointHead, 168 MultipointClient, and MultipointTail don't use the three-way 169 handshakes for session establishment and teardown. As a result, the 170 Init state is absent, and the session transitions to the Up state 171 once the BFD session is administratively enabled. Hence, a BFD 172 session over a p2p LSP, using principles of [RFC8562] or [RFC8563], 173 can be established faster if the MultipointTail has been provisioned 174 with the value of My Discriminator used by the MultipointHead for 175 that BFD session. That value can be provided to the MultipointTail 176 using different mechanisms, e.g., an extension to IGP. Description 177 of mechanism to provide the value of My Discriminator used by the 178 MultipointHead for the particular BFD session is outside the scope of 179 this specification. 181 Unsolicited notification of the detected failure by the 182 MultipointTail to the MultipointClient performs as described above 183 for the case when the ingress BFD system switches the remote peer 184 into the Demand mode. 186 4. IANA Considerations 188 TBD 190 5. Security Considerations 192 This document does not introduce new security aspects but inherits 193 all security considerations from [RFC5880], [RFC5884], [RFC7726], 194 [RFC8029], and [RFC6425]. 196 6. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 204 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 205 . 207 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 208 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 209 June 2010, . 211 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 212 "Bidirectional Forwarding Detection (BFD) for MPLS Label 213 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 214 June 2010, . 216 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 217 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 218 Failures in Point-to-Multipoint MPLS - Extensions to LSP 219 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 220 . 222 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 223 Aldrin, "Clarifying Procedures for Establishing BFD 224 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 225 DOI 10.17487/RFC7726, January 2016, 226 . 228 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 229 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 230 Switched (MPLS) Data-Plane Failures", RFC 8029, 231 DOI 10.17487/RFC8029, March 2017, 232 . 234 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 235 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 236 May 2017, . 238 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 239 Ed., "Bidirectional Forwarding Detection (BFD) for 240 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 241 April 2019, . 243 7. Informative References 245 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 246 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 247 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 248 . 250 Appendix A. Acknowledgements 252 TBD 254 Author's Address 256 Greg Mirsky 257 Ericsson 259 Email: gregimirsky@gmail.com