idnits 2.17.1 draft-mirsky-bfd-mpls-demand-11.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 (7 March 2022) is 752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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: Informational 7 March 2022 5 Expires: 8 September 2022 7 BFD in Demand Mode over Point-to-Point MPLS LSP 8 draft-mirsky-bfd-mpls-demand-11 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 8 September 2022. 34 Copyright Notice 36 Copyright (c) 2022 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 Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions used in this document . . . . . . . . . . . . . . 2 52 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Use of the BFD Demand Mode . . . . . . . . . . . . . . . . . 2 54 3.1. The Applicability of BFD for Multipoint Networks . . . . 4 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 58 7. Informative References . . . . . . . . . . . . . . . . . . . 5 59 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 [RFC5884] defined use of the Asynchronous method of Bidirectional 65 Detection (BFD) [RFC5880] to monitor and detect failures in the data 66 path of a Multiprotocol Label Switching (MPLS) Label Switched Path 67 (LSP). Use of the Demand mode, also specified in [RFC5880], has not 68 been defined so far. This document describes procedures for using 69 the Demand mode of BFD protocol to detect data plane failures in MPLS 70 point-to-point (p2p) LSPs. 72 2. Conventions used in this document 74 2.1. Terminology 76 MPLS: Multiprotocol Label Switching 78 LSP: Label Switched Path 80 LER: Label switching Edge Router 82 BFD: Bidirectional Forwarding Detection 84 p2p: Point-to-Point 86 3. Use of the BFD Demand Mode 88 [RFC5880] defines that the Demand mode may be: 90 * asymmetric, i.e. used in one direction of a BFD session; 92 * switched to and from without bringing BFD session to Down state 93 through using a Poll Sequence. 95 For the case of BFD over MPLS LSP, ingress Label switching Edge 96 Router (LER) usually acts as Active BFD peer and egress LER acts as 97 Passive BFD peer. The Active peer bootstraps the BFD session by 98 using LSP ping. If the BFD session is configured to use the Demand 99 mode, once the BFD session is in Up state the ingress LER switches to 100 the Demand mode as defined in Section 6.6 [RFC5880]. The egress LER 101 also follows procedures defined in Section 6.6 [RFC5880] and ceases 102 further transmission of periodic BFD control packets to the ingress 103 LER. 105 In this state BFD peers remains as long as the egress LER is in Up 106 state. The ingress LER can periodically check continuity of a 107 bidirectional path between the ingress and egress LERs by using the 108 Poll Sequence, as described in Section 6.6 [RFC5880]. An 109 implementation that supports using the Poll Sequence as the mechanism 110 for bidirectional path continuity check must control the interval 111 between consecutive Poll Sequences. The Rdefault value could be 112 selected as 1 second. 114 If the Detection timer at the egress LER expires, the BFD system on 115 LER sends BFD Control packet to the ingress LER with the Poll (P) bit 116 set, Status (Sta) field set to the Down value, and the Diagnostic 117 (Diag) field set to Control Detection Time Expired value. The egress 118 LER periodically transmits these Control packets to the ingress LER 119 until either it receives the valid for this BFD session control 120 packet with the Final (F) bit set from the ingress LER or the defect 121 condition clears and the BFD session state reaches Up state at the 122 egress LER. An implementation that supports this specification 123 provides control of the interval between consecutive Poll messages 124 signaling the expiration of the Detection timer. The default value 125 of the interval can be selected as 1 second. 127 The ingress LER transmits BFD Control packets over the MPLS LSP with 128 the Demand (D) flag set at negotiated interval per [RFC5880], the 129 greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, 130 until it receives the valid BFD packet from the egress LER with the 131 Poll (P) bit and the Diagnostic (Diag) field value Control Detection 132 Time Expired. Reception of such BFD control packet by the ingress 133 LER indicates that the monitored LSP has a failure and sending BFD 134 control packet with the Final flag set to acknowledge failure 135 indication is likely to fail. Instead, the ingress LER transmits the 136 BFD Control packet to the egress LER over the IP network with: 138 * destination IP address is set to the destination IP address of the 139 LSP Ping Echo request message [RFC8029]; 141 * destination UDP port set to 4784 [RFC5883]; 142 * Final (F) flag in BFD control packet is set; 144 * Demand (D) flag in BFD control packet is cleared. 146 The ingress LER changes the state of the BFD session to Down and 147 changes rate of BFD Control packets transmission to one packet per 148 second. The ingress LER in Down mode changes to Asynchronous mode 149 until the BFD session comes to Up state once again. Then the ingress 150 LER switches to the Demand mode. 152 3.1. The Applicability of BFD for Multipoint Networks 154 [RFC8562] defines the use of BFD in multipoint networks. This 155 specification analyzes the case of p2p LSP. In that scenario, the 156 ingress of the LSP acts as the MultipointHead, and the egress - as 157 MultipointTail. The BFD state machines for MultipointHead, 158 MultipointClient, and MultipointTail don't use the three-way 159 handshakes for session establishment and teardown. As a result, the 160 Init state is absent, and the session transitions to the Up state 161 once the BFD session is administratively enabled. Hence, a BFD 162 session over a p2p LSP, using principles of [RFC8562] or [RFC8563], 163 can be established faster if the MultipointTail has been provisioned 164 with the value of My Discriminator used by the MultipointHead for 165 that BFD session. That value can be provided to the MultipointTail 166 using different mechanisms, e.g., an extension to IGP. Description 167 of mechanism to provide the value of My Discriminator used by the 168 MultipointHead for the particular BFD session is outside the scope of 169 this specification. 171 Unsolicited notification of the detected failure by the 172 MultipointTail to the MultipointClient performs as described above 173 for the case when the ingress BFD system switches the remote peer 174 into the Demand mode. 176 4. IANA Considerations 178 TBD 180 5. Security Considerations 182 This document does not introduce new security aspects but inherits 183 all security considerations from [RFC5880], [RFC5884], [RFC7726], 184 [RFC8029], and [RFC6425]. 186 6. Normative References 188 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 189 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 190 . 192 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 193 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 194 June 2010, . 196 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 197 "Bidirectional Forwarding Detection (BFD) for MPLS Label 198 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 199 June 2010, . 201 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 202 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 203 Failures in Point-to-Multipoint MPLS - Extensions to LSP 204 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 205 . 207 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 208 Aldrin, "Clarifying Procedures for Establishing BFD 209 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 210 DOI 10.17487/RFC7726, January 2016, 211 . 213 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 214 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 215 Switched (MPLS) Data-Plane Failures", RFC 8029, 216 DOI 10.17487/RFC8029, March 2017, 217 . 219 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 220 Ed., "Bidirectional Forwarding Detection (BFD) for 221 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 222 April 2019, . 224 7. Informative References 226 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 227 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 228 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 229 . 231 Appendix A. Acknowledgements 233 TBD 235 Author's Address 237 Greg Mirsky 238 Ericsson 239 Email: gregimirsky@gmail.com