idnits 2.17.1 draft-mirsky-bfd-mpls-demand-06.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 (December 22, 2019) is 1577 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 December 22, 2019 5 Expires: June 24, 2020 7 BFD in Demand Mode over Point-to-Point MPLS LSP 8 draft-mirsky-bfd-mpls-demand-06 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 June 24, 2020. 34 Copyright Notice 36 Copyright (c) 2019 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. Once the BFD session is in Up state the ingress LER 107 that supports this specification MUST switch to the Demand mode by 108 setting Demand (D) bit in its Control packet and initiating a Poll 109 Sequence. If the egress LER supports this specification it MUST 110 respond with the Final (F) bit set in its BFD Control packet sent to 111 the ingress LER and ceases further transmission of periodic BFD 112 control packets to the ingress LER. 114 In this state BFD peers MAY remain as long as the egress LER is in Up 115 state. The ingress LER MAY check liveness of the egress LER by 116 setting the Poll flag. The egress LER will respond by transmitting 117 BFD control packet with the Final flag set. If the ingress LER 118 doesn't receive BFD packet with the Final flag from its peer after 119 the predetermined period of time, default wait time recommended 1 120 second, the ingress MAY transmit another packet with the Poll flag 121 set. If ingress doesn't receive BFD control packet with the Final 122 flag set in response to three consecutive packets with Poll flag, it 123 MAY declare the BFD peer non-responsive and change state of the BFD 124 session to Down state. 126 If the Detection timer at the egress LER expires it MUST send BFD 127 Control packet to the ingress LER with the Poll (P) bit set, Status 128 (Sta) field set to Down value, and the Diagnostic (Diag) field set to 129 Control Detection Time Expired value. The egress LER sends these 130 Control packets to the ingress LER at the rate of one per second 131 until either it receives the valid for this BFD session control 132 packet with the Final (F) bit set from the ingress LER or the defect 133 condition clears and the BFD session state reaches Up state at the 134 egress LER. 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 o destination IP address MUST be set to the destination IP address 148 of the LSP Ping Echo request message [RFC8029]; 150 o destination UDP port set to 4784 [RFC5883]; 152 o Final (F) flag in BFD control packet MUST be set; 154 o 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 4. IANA Considerations 164 TBD 166 5. Security Considerations 168 This document does not introduce new security aspects but inherits 169 all security considerations from [RFC5880], [RFC5884], [RFC7726], 170 [RFC8029], and [RFC6425]. 172 6. Normative References 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, 176 DOI 10.17487/RFC2119, March 1997, 177 . 179 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 180 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 181 . 183 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 184 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 185 June 2010, . 187 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 188 "Bidirectional Forwarding Detection (BFD) for MPLS Label 189 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 190 June 2010, . 192 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 193 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 194 Failures in Point-to-Multipoint MPLS - Extensions to LSP 195 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 196 . 198 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 199 Aldrin, "Clarifying Procedures for Establishing BFD 200 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 201 DOI 10.17487/RFC7726, January 2016, 202 . 204 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 205 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 206 Switched (MPLS) Data-Plane Failures", RFC 8029, 207 DOI 10.17487/RFC8029, March 2017, 208 . 210 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 211 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 212 May 2017, . 214 Appendix A. Acknowledgements 216 TBD 218 Author's Address 220 Greg Mirsky 221 ZTE Corp. 223 Email: gregimirsky@gmail.com