idnits 2.17.1 draft-mirsky-bfd-mpls-demand-08.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 (September 9, 2020) is 1319 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 September 9, 2020 5 Expires: March 13, 2021 7 BFD in Demand Mode over Point-to-Point MPLS LSP 8 draft-mirsky-bfd-mpls-demand-08 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 March 13, 2021. 34 Copyright Notice 36 Copyright (c) 2020 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 2 53 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 2 55 3. Use of the BFD Demand Mode . . . . . . . . . . . . . . . . . 3 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 59 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 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 2.2. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 3. Use of the BFD Demand Mode 96 [RFC5880] defines that the Demand mode MAY be: 98 o asymmetric, i.e. used in one direction of a BFD session; 100 o switched to and from without bringing BFD session to Down state 101 through using a Poll Sequence. 103 For the case of BFD over MPLS LSP, ingress Label switching Edge 104 Router (LER) usually acts as Active BFD peer and egress LER acts as 105 Passive BFD peer. The Active peer bootstraps the BFD session by 106 using LSP ping. If the BFD session is configured to use the Demand 107 mode, once the BFD session is in Up state the ingress LER MUST switch 108 to the Demand mode as defined in Section 6.6 [RFC5880]. The egress 109 LER also follows procedures defined in Section 6.6 [RFC5880] and 110 ceases further transmission of periodic BFD control packets to the 111 ingress LER. 113 In this state BFD peers MAY remain as long as the egress LER is in Up 114 state. The ingress LER SHOULD periodically check continuity of a 115 bidirectional path between the ingress and egress LERs by using the 116 Poll Sequence, as described in Section 6.6 [RFC5880]. An 117 implementation that supports using the Poll Sequence as the mechanism 118 for bidirectional path continuity check MUST be able to control the 119 interval between consecutive Poll Sequences. The RECOMMENDED default 120 value is 1 second. 122 If the Detection timer at the egress LER expires it MUST send BFD 123 Control packet to the ingress LER with the Poll (P) bit set, Status 124 (Sta) field set to the Down value, and the Diagnostic (Diag) field 125 set to Control Detection Time Expired value. The egress LER 126 periodically transmits these Control packets to the ingress LER until 127 either it receives the valid for this BFD session control packet with 128 the Final (F) bit set from the ingress LER or the defect condition 129 clears and the BFD session state reaches Up state at the egress LER. 130 An implementation that supports this specification MUST provide 131 control of the interval between consecutive Poll messages signaling 132 the expiration of the Detection timer. The RECOMMENDED default value 133 of the interval is 1 second. 135 The ingress LER transmits BFD Control packets over the MPLS LSP with 136 the Demand (D) flag set at negotiated interval per [RFC5880], the 137 greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, 138 until it receives the valid BFD packet from the egress LER with the 139 Poll (P) bit and the Diagnostic (Diag) field value Control Detection 140 Time Expired. Reception of such BFD control packet by the ingress 141 LER indicates that the monitored LSP has a failure and sending BFD 142 control packet with the Final flag set to acknowledge failure 143 indication is likely to fail. Instead, the ingress LER transmits the 144 BFD Control packet to the egress LER over the IP network with: 146 o destination IP address MUST be set to the destination IP address 147 of the LSP Ping Echo request message [RFC8029]; 149 o destination UDP port set to 4784 [RFC5883]; 151 o Final (F) flag in BFD control packet MUST be set; 153 o Demand (D) flag in BFD control packet MUST be cleared. 155 The ingress LER changes the state of the BFD session to Down and 156 changes rate of BFD Control packets transmission to one packet per 157 second. The ingress LER in Down mode changes to Asynchronous mode 158 until the BFD session comes to Up state once again. Then the ingress 159 LER switches to the Demand mode. 161 4. IANA Considerations 163 TBD 165 5. Security Considerations 167 This document does not introduce new security aspects but inherits 168 all security considerations from [RFC5880], [RFC5884], [RFC7726], 169 [RFC8029], and [RFC6425]. 171 6. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, 175 DOI 10.17487/RFC2119, March 1997, 176 . 178 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 179 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 180 . 182 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 183 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 184 June 2010, . 186 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 187 "Bidirectional Forwarding Detection (BFD) for MPLS Label 188 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 189 June 2010, . 191 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 192 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 193 Failures in Point-to-Multipoint MPLS - Extensions to LSP 194 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 195 . 197 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 198 Aldrin, "Clarifying Procedures for Establishing BFD 199 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 200 DOI 10.17487/RFC7726, January 2016, 201 . 203 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 204 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 205 Switched (MPLS) Data-Plane Failures", RFC 8029, 206 DOI 10.17487/RFC8029, March 2017, 207 . 209 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 210 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 211 May 2017, . 213 Appendix A. Acknowledgements 215 TBD 217 Author's Address 219 Greg Mirsky 220 ZTE Corp. 222 Email: gregimirsky@gmail.com