idnits 2.17.1 draft-mirsky-bfd-mpls-demand-01.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 (June 28, 2017) is 2494 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 June 28, 2017 5 Expires: December 30, 2017 7 BFD in Demand Mode over Point-to-Point MPLS LSP 8 draft-mirsky-bfd-mpls-demand-01 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 http://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 December 30, 2017. 34 Copyright Notice 36 Copyright (c) 2017 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 (http://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 data path 66 of a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP). 67 Use of the Demand mode, also specified in [RFC5880], has not been 68 defined so far. This document describes procedures for using the 69 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) is usually acts as Active BFD peer and egress LER acts 105 as 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 111 over IP network to the egress LER and ceases transmission of periodic 112 BFD 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 Poll flag. The egress LER will respond by transmitting BFD 117 control packet with the Final flag set. If the ingress LER doesn't 118 receive BFD packet with the Final flag from its peer after 119 predetermined period of time, default wait time recommended 1 second, 120 the ingress MAY transmit another packet with the Poll flag set. If 121 ingress doesn't receive BFD control packet with the Final flag set in 122 response to three consecutive packets with Poll flag, it MAY declare 123 the BFD peer non-responsive and change state of the BFD session to 124 Down state. 126 If the Detection timer at the egress LER expires it MUST send BFD 127 Control packet to the ingress LER over the IP network with the Poll 128 (P) bit set, Status (Sta) field set to Down value, and the Diagnostic 129 (Diag) field set to Control Detection Time Expired value. The egress 130 LER sends these Control packets to the ingress LER at the rate of one 131 per second until either it receives the valid for this BFD session 132 control packet with the Final (F) bit set from the ingress LER or the 133 defect condition clears and the BFD session state reaches Up. 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. Once the ingress LER receives such BFD Control packet 141 the ingress LER transmits the BFD Control packet to the egress LER 142 over the IP network with: 144 o Final (F) flag set; 146 o Demand (D) flag cleared. 148 The ingress LER changes the state of the BFD session to Down and 149 changes rate of BFD Control packets transmission to one packet per 150 second. The ingress LER in Down mode changes to Asynchronous mode 151 until the BFD session comes to Up state once again. Then the ingress 152 LER switches to the Demand mode. 154 4. IANA Considerations 156 TBD 158 5. Security Considerations 160 This document does not introduce new security aspects but inherits 161 all security considerations from [RFC5880], [RFC5884], [RFC7726], 162 [RFC8029], and [RFC6425]. 164 6. Normative References 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, 168 DOI 10.17487/RFC2119, March 1997, 169 . 171 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 172 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 173 . 175 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 176 "Bidirectional Forwarding Detection (BFD) for MPLS Label 177 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 178 June 2010, . 180 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 181 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 182 Failures in Point-to-Multipoint MPLS - Extensions to LSP 183 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 184 . 186 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 187 Aldrin, "Clarifying Procedures for Establishing BFD 188 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 189 DOI 10.17487/RFC7726, January 2016, 190 . 192 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 193 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 194 Switched (MPLS) Data-Plane Failures", RFC 8029, 195 DOI 10.17487/RFC8029, March 2017, 196 . 198 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 199 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 200 May 2017, . 202 Appendix A. Acknowledgements 204 Author's Address 206 Greg Mirsky 207 ZTE Corp. 209 Email: gregimirsky@gmail.com