idnits 2.17.1 draft-mirsky-bfd-mpls-demand-09.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 (30 March 2021) is 1123 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 ZTE Corp. 4 Intended status: Standards Track 30 March 2021 5 Expires: 1 October 2021 7 BFD in Demand Mode over Point-to-Point MPLS LSP 8 draft-mirsky-bfd-mpls-demand-09 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 1 October 2021. 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 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 58 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 [RFC5884] defined use of the Asynchronous method of Bidirectional 64 Detection (BFD) [RFC5880] to monitor and detect failures in the data 65 path of a Multiprotocol Label Switching (MPLS) Label Switched Path 66 (LSP). Use of the Demand mode, also specified in [RFC5880], has not 67 been defined so far. This document describes procedures for using 68 the Demand mode of BFD protocol to detect data plane failures in MPLS 69 point-to-point (p2p) LSPs. 71 2. Conventions used in this document 73 2.1. Terminology 75 MPLS: Multiprotocol Label Switching 77 LSP: Label Switched Path 79 LER: Label switching Edge Router 81 BFD: Bidirectional Forwarding Detection 83 p2p: Point-to-Point 85 2.2. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 3. Use of the BFD Demand Mode 95 [RFC5880] defines that the Demand mode MAY be: 97 * asymmetric, i.e. used in one direction of a BFD session; 99 * switched to and from without bringing BFD session to Down state 100 through using a Poll Sequence. 102 For the case of BFD over MPLS LSP, ingress Label switching Edge 103 Router (LER) usually acts as Active BFD peer and egress LER acts as 104 Passive BFD peer. The Active peer bootstraps the BFD session by 105 using LSP ping. If the BFD session is configured to use the Demand 106 mode, once the BFD session is in Up state the ingress LER MUST switch 107 to the Demand mode as defined in Section 6.6 [RFC5880]. The egress 108 LER also follows procedures defined in Section 6.6 [RFC5880] and 109 ceases further transmission of periodic BFD control packets to the 110 ingress LER. 112 In this state BFD peers MAY remain as long as the egress LER is in Up 113 state. The ingress LER SHOULD periodically check continuity of a 114 bidirectional path between the ingress and egress LERs by using the 115 Poll Sequence, as described in Section 6.6 [RFC5880]. An 116 implementation that supports using the Poll Sequence as the mechanism 117 for bidirectional path continuity check MUST be able to control the 118 interval between consecutive Poll Sequences. The RECOMMENDED default 119 value is 1 second. 121 If the Detection timer at the egress LER expires it MUST send BFD 122 Control packet to the ingress LER with the Poll (P) bit set, Status 123 (Sta) field set to the Down value, and the Diagnostic (Diag) field 124 set to Control Detection Time Expired value. The egress LER 125 periodically transmits these Control packets to the ingress LER until 126 either it receives the valid for this BFD session control packet with 127 the Final (F) bit set from the ingress LER or the defect condition 128 clears and the BFD session state reaches Up state at the egress LER. 129 An implementation that supports this specification MUST provide 130 control of the interval between consecutive Poll messages signaling 131 the expiration of the Detection timer. The RECOMMENDED default value 132 of the interval is 1 second. 134 The ingress LER transmits BFD Control packets over the MPLS LSP with 135 the Demand (D) flag set at negotiated interval per [RFC5880], the 136 greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, 137 until it receives the valid BFD packet from the egress LER with the 138 Poll (P) bit and the Diagnostic (Diag) field value Control Detection 139 Time Expired. Reception of such BFD control packet by the ingress 140 LER indicates that the monitored LSP has a failure and sending BFD 141 control packet with the Final flag set to acknowledge failure 142 indication is likely to fail. Instead, the ingress LER transmits the 143 BFD Control packet to the egress LER over the IP network with: 145 * destination IP address MUST be set to the destination IP address 146 of the LSP Ping Echo request message [RFC8029]; 148 * destination UDP port set to 4784 [RFC5883]; 150 * Final (F) flag in BFD control packet MUST be set; 152 * Demand (D) flag in BFD control packet MUST be cleared. 154 The ingress LER changes the state of the BFD session to Down and 155 changes rate of BFD Control packets transmission to one packet per 156 second. The ingress LER in Down mode changes to Asynchronous mode 157 until the BFD session comes to Up state once again. Then the ingress 158 LER switches to the Demand mode. 160 4. IANA Considerations 162 TBD 164 5. Security Considerations 166 This document does not introduce new security aspects but inherits 167 all security considerations from [RFC5880], [RFC5884], [RFC7726], 168 [RFC8029], and [RFC6425]. 170 6. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, 174 DOI 10.17487/RFC2119, March 1997, 175 . 177 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 178 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 179 . 181 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 182 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 183 June 2010, . 185 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 186 "Bidirectional Forwarding Detection (BFD) for MPLS Label 187 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 188 June 2010, . 190 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 191 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 192 Failures in Point-to-Multipoint MPLS - Extensions to LSP 193 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 194 . 196 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 197 Aldrin, "Clarifying Procedures for Establishing BFD 198 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 199 DOI 10.17487/RFC7726, January 2016, 200 . 202 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 203 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 204 Switched (MPLS) Data-Plane Failures", RFC 8029, 205 DOI 10.17487/RFC8029, March 2017, 206 . 208 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 209 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 210 May 2017, . 212 Appendix A. Acknowledgements 214 TBD 216 Author's Address 218 Greg Mirsky 219 ZTE Corp. 221 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com