Skip to main content

Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)
draft-ietf-bfd-rfc5884-bis-01

Document Type Active Internet-Draft (bfd WG)
Authors Rahul Aggarwal , Kireeti Kompella , Thomas Nadeau , George Swallow , Vengada Prasad Govindan , Kalyani Rajaraman , Greg Mirsky , Sam Aldrin
Last updated 2026-08-15
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
Mailing list discussion
Stream WG state WG Document
Associated WG milestone
Dec 2026
RFC 5884 "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)" to Internet Standard
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-bfd-rfc5884-bis-01
Network Working Group                                        R. Aggarwal
Internet-Draft                                               K. Kompella
Obsoletes: 5884, 7726 (if approved)                     Juniper Networks
Intended status: Standards Track                               T. Nadeau
Expires: 16 February 2027                                             BT
                                                              G. Swallow
                                                                 Retired
                                                        V. Govindan, Ed.
                                                            K. Rajaraman
                                                     Cisco Systems, Inc.
                                                               G. Mirsky
                                                                   Ciena
                                                               S. Aldrin
                                                                  NVIDIA
                                                          15 August 2026

 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths
                                 (LSPs)
                     draft-ietf-bfd-rfc5884-bis-01

Abstract

   One desirable application of Bidirectional Forwarding Detection (BFD)
   is to detect a Multiprotocol Label Switching (MPLS) Label Switched
   Path (LSP) data plane failure.  LSP Ping is an existing mechanism for
   detecting MPLS data plane failures and for verifying the MPLS LSP
   data plane against the control plane.  BFD can be used for the
   former, but not for the latter.  However, the control plane
   processing required for BFD Control packets is relatively smaller
   than the processing required for LSP Ping messages.  A combination of
   LSP Ping and BFD can be used to provide faster data plane failure
   detection and/or make it possible to provide such detection on a
   greater number of LSPs.  This document describes the applicability of
   BFD in relation to LSP Ping for this application.  It also describes
   procedures for using BFD in this environment.  This document
   obsoletes RFC5884 and RFC7726.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

Aggarwal, et al.        Expires 16 February 2027                [Page 1]
Internet-Draft              BFD for MPLS LSPs                August 2026

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 February 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  BFD for MPLS LSPs: Motivation . . . . . . . . . . . . . .   3
     3.2.  Using BFD in Conjunction with LSP Ping  . . . . . . . . .   5
   4.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   6
   5.  Initialization and Demultiplexing . . . . . . . . . . . . . .   7
   6.  Session Establishment . . . . . . . . . . . . . . . . . . . .   7
     6.1.  BFD Discriminator TLV in LSP Ping . . . . . . . . . . . .   8
   7.  Encapsulation . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Procedures for multiple BFD over MPLS sessions  . . . . . . .  10
     8.1.  Procedures for establishment of multiple BFD sessions . .  10
     8.2.  Procedures for maintenance of multiple BFD sessions . . .  11
     8.3.  Procedures for removing BFD sessions at the egress LSR  .  11
     8.4.  Changing discriminators for a BFD session . . . . . . . .  12
     8.5.  Backwards Compatibility . . . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     12.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Discussions about the loopback address to be used in
           the BFD packet  . . . . . . . . . . . . . . . . . . . . .  15
   Appendix B.  Implementation Status  . . . . . . . . . . . . . . .  15

Aggarwal, et al.        Expires 16 February 2027                [Page 2]
Internet-Draft              BFD for MPLS LSPs                August 2026

     B.1.  TBF . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   One desirable application of Bidirectional Forwarding Detection (BFD)
   is to track the liveness of a Multiprotocol Label Switching (MPLS)
   Label Switched Path (LSP).  In particular, BFD can be used to detect
   a data plane failure in the forwarding path of an MPLS LSP.  LSP Ping
   [RFC4379] is an existing mechanism for detecting MPLS LSP data plane
   failures and for verifying the MPLS LSP data plane against the
   control plane.  This document describes the applicability of BFD in
   relation to LSP Ping for detecting MPLS LSP data plane failures.  It
   also describes procedures for using BFD for detecting MPLS LSP data
   plane failures.

2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Applicability

   In the event of an MPLS LSP failing to deliver data traffic, it may
   not always be possible to detect the failure using the MPLS control
   plane.  For instance, the control plane of the MPLS LSP may be
   functional while the data plane may be mis-forwarding or dropping
   data.  Hence, there is a need for a mechanism to detect a data plane
   failure in the MPLS LSP path [RFC4377].

3.1.  BFD for MPLS LSPs: Motivation

   LSP Ping described in [RFC4379] is an existing mechanism for
   detecting an MPLS LSP data plane failure.  In addition, LSP Ping also
   provides a mechanism for verifying the MPLS control plane against the
   data plane.  This is done by ensuring that the LSP is mapped to the
   same Forwarding Equivalence Class (FEC), at the egress, as the
   ingress.

   BFD cannot be used for verifying the MPLS control plane against the
   data plane.  However, BFD can be used to detect a data plane failure
   in the forwarding path of an MPLS LSP.  The LSP may be associated
   with any of the following FECs:

      a) Resource Reservation Protocol (RSVP) LSP_Tunnel IPv4/IPv6
         Session [RFC3209]

Aggarwal, et al.        Expires 16 February 2027                [Page 3]
Internet-Draft              BFD for MPLS LSPs                August 2026

      b) Label Distribution Protocol (LDP) IPv4/IPv6 prefix [RFC5036]

      c) Virtual Private Network (VPN) IPv4/IPv6 prefix [RFC4364] d)
      Layer 2 VPN [L2-VPN]

      e) Pseudowires based on PWid FEC and Generalized PWid FEC
         [RFC4447]

      f) Border Gateway Protocol (BGP) labeled prefixes [RFC3107]

   LSP Ping includes extensive control plane verification.  BFD, on the
   other hand, was designed as a lightweight means of testing only the
   data plane.  As a result, LSP Ping is computationally more expensive
   than BFD for detecting MPLS LSP data plane faults.  BFD is also more
   suitable for being implemented in hardware or firmware due to its
   fixed packet format.  Thus, the use of BFD for detecting MPLS LSP
   data plane faults has the following advantages:

      a) Support for fault detection for greater number of LSPs.

      b) Fast detection.  Detection with sub-second granularity is
         considered as fast detection.  LSP Ping is intended to be used
         in an environment where fault detection messages are exchanged,
         either for diagnostic purposes or for infrequent periodic fault
         detection, in the order of tens of seconds or minutes.  Hence,
         it is not appropriate for fast detection.  BFD, on the other
         hand, is designed for sub-second fault detection intervals.
         Following are some potential cases when fast detection may be
         desirable for MPLS LSPs:

         1.  In the case of a bypass LSP used for a facility-based link
             or node protection [RFC4090].  In this case, the bypass LSP
             is essentially being used as an alternate link to protect
             one or more LSPs.  It represents an aggregate and is used
             to carry data traffic belonging to one or more LSPs, when
             the link or the node being protected fails.  Hence, fast
             failure detection of the bypass LSP may be desirable
             particularly in the event of link or node failure when the
             data traffic is moved to the bypass LSP.

         2.  MPLS Pseudowires (PWs).  Fast detection may be desired for
             MPLS PWs depending on i) the model used to layer the MPLS
             network with the Layer 2 network, and ii) the service that
             the PW is emulating.  For a non-overlay model between the
             Layer 2 network and the MPLS network, the provider may rely
             on PW fault detection to provide service status to the end-
             systems.  Also, in that case, interworking scenarios such
             as ATM/Frame Relay interworking may force periodic PW fault

Aggarwal, et al.        Expires 16 February 2027                [Page 4]
Internet-Draft              BFD for MPLS LSPs                August 2026

             detection messages.  Depending on the requirements of the
             service that the MPLS PW is emulating, fast failure
             detection may be desirable.

   There may be other potential cases where fast failure detection is
   desired for MPLS LSPs.

3.2.  Using BFD in Conjunction with LSP Ping

   BFD can be used for MPLS LSP data plane fault detection.  However, it
   does not have all the functionality of LSP Ping.  In particular, it
   cannot be used for verifying the control plane against the data
   plane.  LSP Ping performs the following functions that are outside
   the scope of BFD:

      a) Association of an LSP Ping Echo request message with a FEC.
      In
         the case of Penultimate Hop Popping (PHP) or when the egress
         Label Switching Router (LSR) distributes an explicit null label
         to the penultimate hop router, for a single label stack LSP,
         the only way to associate a fault detection message with a FEC
         is by carrying the FEC in the message.  LSP Ping provides this
         functionality.  Next-hop label allocation also makes it
         necessary to carry the FEC in the fault detection message as
         the label alone is not sufficient to identify the LSP being
         verified.  In addition, presence of the FEC in the Echo request
         message makes it possible to verify the control plane against
         the data plane at the egress LSR.

      b) Equal Cost Multi-Path (ECMP) considerations.  LSP Ping
         traceroute makes it possible to probe multiple alternate paths
         for LDP IP FECs.

      c) Traceroute.  LSP Ping supports traceroute for a FEC and it
      can
         be used for fault isolation.

   Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
   detection:

      i) LSP Ping is used for bootstrapping the BFD session as
         described later in this document.

             ii) BFD is used to exchange fault detection (i.e., BFD
             session) packets at the required detection interval.

Aggarwal, et al.        Expires 16 February 2027                [Page 5]
Internet-Draft              BFD for MPLS LSPs                August 2026

             iii) LSP Ping is used to periodically verify the control
             plane
                  against the data plane by ensuring that the LSP is
                  mapped to the same FEC, at the egress, as the ingress.

4.  Theory of Operation

   To use BFD for fault detection on an MPLS LSP, a BFD session MUST be
   established for that particular MPLS LSP.  BFD Control packets MUST
   be sent along the same data path as the LSP being verified and are
   processed by the BFD processing module of the egress LSR.  If the LSP
   is associated with multiple FECs, a BFD session SHOULD be established
   for each FEC.  For instance, this may happen in the case of next-hop
   label allocation.  Hence, the operation is conceptually similar to
   the data plane fault detection procedures of LSP Ping.

   If MPLS fast-reroute is being used for the MPLS LSP, the use of BFD
   for fault detection can result in false fault detections if the BFD
   fault detection interval is less than the MPLS fast-reroute
   switchover time.  When MPLS fast-reroute is triggered because of a
   link or node failure, BFD Control packets will be dropped until
   traffic is switched on to the backup LSP.  If the time taken to
   perform the switchover exceeds the BFD fault detection interval, a
   fault will be declared even though the MPLS LSP is being locally
   repaired.  To avoid this, the BFD fault detection interval should be
   greater than the fast-reroute switchover time.  An implementation
   SHOULD provide configuration options to control the BFD fault
   detection interval.

   If there are multiple alternate paths from an ingress LSR to an
   egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to
   determine each of these alternate paths.  A BFD session SHOULD be
   established for each alternate path that is discovered.

   Periodic LSP Ping Echo request messages SHOULD be sent by the ingress
   LSR to the egress LSR along the same data path as the LSP.  This is
   to periodically verify the control plane against the data plane by
   ensuring that the LSP is mapped to the same FEC, at the egress, as
   the ingress.  The rate of generation of these LSP Ping Echo request
   messages SHOULD be significantly less than the rate of generation of
   the BFD Control packets.  An implementation MAY provide configuration
   options to control the rate of generation of the periodic LSP Ping
   Echo request messages.

   To enable fault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes

Aggarwal, et al.        Expires 16 February 2027                [Page 6]
Internet-Draft              BFD for MPLS LSPs                August 2026

   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress
   LSR to identify the OAM packet.  For fault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5885] is
   configured and the support of LSP Ping is also configured.

5.  Initialization and Demultiplexing

   A BFD session may be established for a FEC associated with an MPLS
   LSP.  As described above, in the case of PHP or when the egress LSR
   distributes an explicit null label to the penultimate hop router, or
   next-hop label allocation, the BFD Control packet received by the
   egress LSR does not contain sufficient information to associate it
   with a BFD session.  Hence, the demultiplexing MUST be done using the
   remote discriminator field in the received BFD Control packet.  The
   exchange of BFD discriminators for this purpose is described in the
   next section.

6.  Session Establishment

   A BFD session is bootstrapped using LSP Ping.  This specification
   describes procedures only for BFD asynchronous mode.  BFD demand mode
   is outside the scope of this specification.  Further, the use of the
   BFD Echo function is outside the scope of this specification.  The
   initiation of fault detection for a particular <MPLS LSP, FEC>
   combination results in the exchange of LSP Ping Echo request and Echo
   reply packets, in the ping mode, between the ingress and egress LSRs
   for that <MPLS LSP, FEC>.  To establish a BFD session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.

   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.  This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.  The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.

   The ingress LSR follows the procedures in [RFC5880] to send BFD
   Control packets to the egress LSR in response to the BFD Control
   packets received from the egress LSR.  The BFD Control packets from
   the ingress to the egress LSR MUST set the local discriminator of the

Aggarwal, et al.        Expires 16 February 2027                [Page 7]
Internet-Draft              BFD for MPLS LSPs                August 2026

   egress LSR in the Your Discriminator field.  The egress LSR
   demultiplexes the BFD session based on the received Your
   Discriminator field.  As mentioned above, the egress LSR MUST send
   Control packets to the ingress LSR with the Your Discriminator field
   set to the local discriminator of the ingress LSR.The ingress LSR
   uses this to demultiplex the BFD session.

   The egress LSR processes the LSP Ping Echo request message in
   accordance with the procedures defined in [RFC 8029].  The LSP Ping
   Echo reply message generated by the egress LSR MAY carry the local
   discriminator assigned by it for the BFD session, as specified in
   section 6.1.

6.1.  BFD Discriminator TLV in LSP Ping

   LSP Ping Echo request and Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TLV.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is not in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.

7.  Encapsulation

   BFD Control packets sent by the ingress LSR MUST be encapsulated in
   the MPLS label stack that corresponds to the FEC for which fault
   detection is being performed.  If the label stack has a depth greater
   than one, the TTL of the inner MPLS label MAY be set to 1.  This may
   be necessary for certain FECs to enable the egress LSR's control
   plane to receive the packet [RFC4379].  For MPLS PWs, alternatively,
   the presence of a fault detection message may be indicated by setting
   a bit in the control word [RFC5885].

Aggarwal, et al.        Expires 16 February 2027                [Page 8]
Internet-Draft              BFD for MPLS LSPs                August 2026

   The BFD Control packet sent by the ingress LSR MUST be a UDP packet
   with a well-known destination port 3784 [RFC5881] and a source port
   assigned by the sender as per the procedures in [RFC5881].  The
   source IP address is a routable address of the sender.  The
   destination IP address MUST be randomly chosen from the 127/8 range
   for IPv4 and from the 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6 with
   the following exception.  If the FEC is an LDP IP FEC, the ingress
   LSR may discover multiple alternate paths to the egress LSR for this
   FEC using LSP Ping traceroute.  In this case, the destination IP
   address, used in a BFD session established for one such alternate
   path, is the address in the 127/8 range for IPv4 or
   0:0:0:0:0:FFFF:7F00:0/104 range for IPv6 discovered by LSP Ping
   traceroute [RFC4379] to exercise that particular alternate path.

   The motivation for using the address range 127/8 is the same as
   specified in Section 2.1 of [RFC4379].  This is an exception to the
   behavior defined in [RFC1122].

   The IP TTL or hop limit MUST be set to 1 [RFC4379].

   BFD Control packets sent by the egress LSR are UDP packets.  The
   source IP address is a routable address of the replier.

   The BFD Control packet sent by the egress LSR to the ingress LSR MAY
   be routed based on the destination IP address as per the procedures
   in [RFC5883].  If this is the case, the destination IP address MUST
   be set to the source IP address of the LSP Ping Echo request message,
   received by the egress LSR from the ingress LSR.

   Or the BFD Control packet sent by the egress LSR to the ingress LSR
   MAY be encapsulated in an MPLS label stack.  In this case, the
   presence of the fault detection message is indicated as described
   above.  This may be the case if the FEC for which the fault detection
   is being performed corresponds to a bidirectional LSP or an MPLS PW.
   This may also be the case when there is a return LSP from the egress
   LSR to the ingress LSR.  In this case, the destination IP address
   MUST be randomly chosen from the 127/8 range for IPv4 and from the
   0:0:0:0:0:FFFF:7F00:0/104 range for IPv6.

   The BFD Control packet sent by the egress LSR MUST have a well-known
   destination port 4784, if it is routed [RFC5883], or it MUST have a
   well-known destination port 3784 [RFC5881] if it is encapsulated in a
   MPLS label stack.  The source port MUST be assigned by the egress LSR
   as per the procedures in [BFD-IP].

   Note that once the BFD session for the MPLS LSP is UP, either end of
   the BFD session MUST NOT change the source IP address and the local
   discriminator values of the BFD Control packets it generates, unless

Aggarwal, et al.        Expires 16 February 2027                [Page 9]
Internet-Draft              BFD for MPLS LSPs                August 2026

   it first brings down the session.  This implies that an LSR MUST
   ignore BFD packets for a given session, demultiplexed using the
   received Your Discriminator field, if the session is in UP state and
   if the My Discriminator or the Source IP address fields of the
   received packet do not match the values associated with the session.

8.  Procedures for multiple BFD over MPLS sessions

8.1.  Procedures for establishment of multiple BFD sessions

   To support the requirement that a BFD session SHOULD be established
   for each alternate path that is discovered and to disallow either end
   to change local discriminator values in BFD control packets after the
   session reaches the UP state, the following procedures are to be
   implemented:

   At the ingress LSR:

   *  MPLS LSP ping can be used to bootstrap multiple BFD sessions for a
      given <MPLS FEC, LSP>.  Each LSP ping MUST carry a different
      discriminator value in the BFD discriminator TLV [RFC4379].

   The egress LSR needs to perform the following:

   *  If the validation of the FEC in the MPLS Echo request message
      succeeds, check the discriminator specified in the BFD
      discriminator TLV of the MPLS Echo request.  If there is no local
      session that corresponds to the (remote) discriminator received in
      the MPLS Echo request, a new session is bootstrapped and a local
      discriminator is allocated.  The validation of a FEC is a
      necessary condition to be satisfied to create a new BFD session at
      the egress LSR.  However, the policy or procedure if any, to be
      applied by the egress LSR before allowing a new BFD session to be
      created is outside the scope of this document.  Such policies or
      procedures could consider availability of system resources before
      allowing a session to be created.  When the egress LSR disallows
      the creation of a BFD session due to policy, it MUST drop the MPLS
      Echo request message.

   *  Ensure the uniqueness of the <MPLS FEC, LSP, Remote
      Discriminiator> tuple.

   *  Except for the clarification mentioned above, the remaining
      procedures of BFD session establishment are as specified in
      Sections 4-6 of [RFC5884].

Aggarwal, et al.        Expires 16 February 2027               [Page 10]
Internet-Draft              BFD for MPLS LSPs                August 2026

8.2.  Procedures for maintenance of multiple BFD sessions

   Both the ingress LSR and egress LSR use the YourDiscriminator of the
   received BFD packet to demultiplex BFD sessions.

8.3.  Procedures for removing BFD sessions at the egress LSR

   [RFC5884] does not specify an explicit procedure for deleting BFD
   sessions.  The procedure for removing a BFD session established by an
   out-of-band discriminator exchange using the MPLS LSP ping can
   improve resource management (like memory etc.) especially in
   scenarios involving thousands or more of such sessions.  A few
   observations are made here:

   *  The BFD session MAY be removed in the egress LSR if the BFD
      session transitions from UP to DOWN.  This can either be done
      immediately after the BFD session transitions from UP to DOWN or
      after the expiry of a configurable timer started after the BFD
      session state transitions from UP to DOWN at the egress LSR to
      reduce flapping by adding hysteresis.

   *  The BFD session on the egress LSR MAY be removed by the ingress
      LSR by using the BFD diagnostic code AdminDown(7) as specified in
      [RFC5880].  When the ingress LSR wants to remove a session without
      triggering any state change at the egress, it MAY transmit BFD
      packets indicating the State as Down(1), diagnostic code
      AdminDown(7) detectMultiplier number of times.  Upon receiving
      such a packet, the egress LSR MAY remove the BFD session, without
      triggering a change of state.

   *  The procedures to be followed at the egress LSR when BFD
      session(s) remain in the DOWN state for a significant amount of
      time is a local matter.  Such procedures are outside the scope of
      this document.

   *  All BFD sessions established with the FEC MUST be removed
      automatically if the FEC is removed.

   *  The egress MUST use the discriminators exchanged when the session
      was brought UP, to indicate any session state change to the
      ingress.  The egress SHOULD reset this to zero after transmitting
      bfd.detectMult number of packets if the BFD session transitions to
      DOWN state.

Aggarwal, et al.        Expires 16 February 2027               [Page 11]
Internet-Draft              BFD for MPLS LSPs                August 2026

8.4.  Changing discriminators for a BFD session

   The discriminators of a BFD session established over an MPLS LSP
   cannot be changed when it is in UP state.  The BFD session could be
   removed after a graceful transition to AdminDown state using the BFD
   diagnostic code AdminDown.  A new session could be established with a
   different discriminator.  The initiation of the transition from the
   Up to Down state can be done either by the ingress LSR or the egress
   LSR.

8.5.  Backwards Compatibility

   The procedures clarified by this document are fully backward
   compatible with an existing implementation of [RFC5884].  While the
   capability to bootstrap and maintain multiple BFD sessions may not be
   present in current implementations, the procedures outlined by this
   document can be implemented as a software upgrade without affecting
   existing sessions.  In particular, the egress LSR needs to support
   multiple BFD sessions per <MPLS FEC, LSP> before the ingress LSR is
   upgraded.

9.  Security Considerations

   Security considerations discussed in [RFC5880], [RFC5883], and
   [RFC4379] apply to this document.  For BFD Control packets sent by
   the ingress LSR or when the BFD Control packet sent by the egress LSR
   are encapsulated in an MPLS label stack, MPLS security considerations
   apply.  These are discussed in [RFC5920].  When BFD Control packets
   sent by the egress LSR are routed, the authentication considerations
   discussed in [RFC5883] should be followed.

   It is highly important to ensure only minimum number of BFD sessions
   are provisioned per FEC, and bootstrapped BFD sessions are properly
   deleted when no longer required.  Additionally security measures
   described in [RFC4379] and [RFC5884] are to be followed.

10.  IANA Considerations

   This document introduces a BFD discriminator TLV in LSP Ping.  The
   BFD Discriminator has been assigned a value of 15 from the LSP Ping
   TLVs and sub-TLVs registry maintained by IANA.

11.  Acknowledgments

   Thanks to Jeffrey Haas, Reshad Rehman, Mathew Bocci, John Scudder,
   Eric Vyncke, Ketan Talaulikar for their comments and feedback.

12.  References

Aggarwal, et al.        Expires 16 February 2027               [Page 12]
Internet-Draft              BFD for MPLS LSPs                August 2026

12.1.  Normative References

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              DOI 10.17487/RFC5881, June 2010,
              <https://www.rfc-editor.org/info/rfc5881>.

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
              June 2010, <https://www.rfc-editor.org/info/rfc5884>.

12.2.  Informative References

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
              <https://www.rfc-editor.org/info/rfc3107>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <https://www.rfc-editor.org/info/rfc4090>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

Aggarwal, et al.        Expires 16 February 2027               [Page 13]
Internet-Draft              BFD for MPLS LSPs                August 2026

   [RFC4377]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
              Matsushima, "Operations and Management (OAM) Requirements
              for Multi-Protocol Label Switched (MPLS) Networks",
              RFC 4377, DOI 10.17487/RFC4377, February 2006,
              <https://www.rfc-editor.org/info/rfc4377>.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <https://www.rfc-editor.org/info/rfc4379>.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447,
              DOI 10.17487/RFC4447, April 2006,
              <https://www.rfc-editor.org/info/rfc4447>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <https://www.rfc-editor.org/info/rfc5036>.

   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
              June 2010, <https://www.rfc-editor.org/info/rfc5883>.

   [RFC5885]  Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
              Forwarding Detection (BFD) for the Pseudowire Virtual
              Circuit Connectivity Verification (VCCV)", RFC 5885,
              DOI 10.17487/RFC5885, June 2010,
              <https://www.rfc-editor.org/info/rfc5885>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <https://www.rfc-editor.org/info/rfc5920>.

   [RFC9780]  Mirsky, G., Mishra, G., and D. Eastlake 3rd,
              "Bidirectional Forwarding Detection (BFD) for Multipoint
              Networks over Point-to-Multipoint MPLS Label Switched
              Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025,
              <https://www.rfc-editor.org/info/rfc9780>.

   [L2-VPN]   Kompella, K., Leelanivas, M., Vohra, Q., Achirica, J.,
              Bonica, R., Cooper, D., Liljenstolpe, C., Metz, E., Ould-
              Brahim, H., Sargor, C., Shah, H., Srinivasan, and Z.
              Zhang, "Layer 2 VPNs Over Tunnels", Work in Progress,
              February 2003.

Aggarwal, et al.        Expires 16 February 2027               [Page 14]
Internet-Draft              BFD for MPLS LSPs                August 2026

Appendix A.  Discussions about the loopback address to be used in the
             BFD packet

   For IPv4, BFD over MPLS Control packets use destination addresses
   from the 127.0.0.0/8 loopback prefix to prevent off-link forwarding,
   which complies with standard IPv4 addressing architecture.  In IPv6,
   however, the use of IPv4-mapped IPv6 loopback addresses is not
   natively supported by the IPv6 addressing architecture.

   During the original development of [RFC5884], architectural
   compliance aspects regarding IPv4-mapped loopback addresses were
   discussed, but these considerations were not fully incorporated into
   the published specification.  Because commercial implementations
   based on [RFC5884] have been widely deployed using IPv4-mapped
   addresses, interoperability and backward compatibility remain crucial
   requirements.  Consequently, the addressing recommendations in this
   document account for existing deployed behavior and may not strictly
   align with the loopback prefix defined in [RFC9780].

Appendix B.  Implementation Status

   Note to the RFC Editor: This section may be removed upon publication
   as an RFC.

   This section documents the [RFC5880] [RFC5884] implementation status
   of this document.  [RFC5884] is built as an application of the BFD
   protocol in [RFC5880], hence the coverage discusses applicable
   sections of the BFD protocol to the MPLS transport.  For e.g.
   sections related to BFD Echo functionality and Demand mode are
   skipped.

   *  The organization responsible for the implementation, if any.

   *  The implementation's name and/or a link to a web page where the
      implementation or a description of it can be found.

   *  A brief general description.

   *  The implementation's level of maturity: research, prototype,
      alpha, beta, production, widely used, etc.

   *  Coverage: which parts of the protocol specification are
      implemented.

   *  Version compatibility: what version/versions of the Internet-Draft
      are known to be implemented.

Aggarwal, et al.        Expires 16 February 2027               [Page 15]
Internet-Draft              BFD for MPLS LSPs                August 2026

   *  Licensing: the terms under which the implementation can be used.
      For example: proprietary, royalty licensing, freely distributable
      with acknowledgement (BSD style), freely distributable with
      requirement to redistribute source (General Public License (GPL)
      style), and other (specify).

   *  Implementation experience: any useful information the implementers
      want to share with the community.

   *  Contact information: ideally a person's name and email address,
      but possibly just a URL or mailing list.

   *  The date when information about this particular implementation was
      last updated.

B.1.  TBF

   Organization:
      TBF

   Implementation Name:
      TBF

   Description:
      BFD over MPLS feature

   Maturity:
      TBF

   Coverage:
      *  Section x.

      *  RFC5884 - 3.2: Bootstrapping BFD over LSP using LSP ping

      *  RFC5884 - 3.2: Setting BFD fault detection parameters for the
         LSP

      *  RFC5884 - 4.0: Periodic LSP Ping echo request messages

      *  RFC5884 - 4.0: Configuration knobs for enablement and operation
         of BFD and LSP ping

      *  RFC5884 - 5.0: Demultiplexing logic for BFD sessions based on
         remote Discriminator

      *  RFC5884 - 6.0: LSP Ping Echo request message with local
         discriminator for session establishment using BFD Discriminator
         TLV (Sec 6.1)

Aggarwal, et al.        Expires 16 February 2027               [Page 16]
Internet-Draft              BFD for MPLS LSPs                August 2026

      *  RFC5884 - 6.0: Egress LSR validates FEC and follows procedures
         for discriminators

      *  RFC5883 - 6.0: How does the ingress LER handle the case when
         the Mydiscriminator returned in the BFD packet differs from the
         discriminator value returned in the LSP Ping Echo reply?

      *  RFC5884 - 7.0: Dataplane formats for BFD over MPLS using TTL=1.

      *  RFC5880 - 6.3: unique discriminator per session

      *  RFC5880 6.5: Poll Sequence

      *  RFC5880 6.7: Authentication

      *  RFC5880 6.7.2: Simple Password Authentication

      *  RFC5880 6.7.3: Keyed MD5 and Meticulous Keyed MD5
         Authentication

      *  RFC5880 6.7.4: Keyed SHA1 and Meticulous Keyed SHA1
         Authentication

      *  RFC5880 6.8.1: State Variables

      *  RFC5880 6.8.2: Timer Negotiation

      *  RFC5880 6.8.3: Timer Manipulation

      *  RFC5880 6.8.4: Detection Time Calculation

      *  RFC5880 6.8.6: Reception of BFD Control Packets

      *  RFC5880 6.8.7: Transmitting BFD Control Packets

      *  RFC5880 6.8.7: What source/destination IPv6 loopback addresses
         are used for BFD control packets over IPv6 LSPs?

      *  RFC5880 6.8.10: Min Rx Interval Change

      *  RFC5880 6.8.11: Min Tx Interval Change

      *  RFC5880 6.8.12: Detect Multiplier Change

      *  RFC5880 6.8.15: Forwarding Plane Reset

      *  RFC5880 6.8.16: Administrative Control

Aggarwal, et al.        Expires 16 February 2027               [Page 17]
Internet-Draft              BFD for MPLS LSPs                August 2026

      *  RFC5880 6.8.17: Concatenated Paths

      *  RFC5880 6.8.18: Session Hold Down

      *  RFC5880 9: Generalized TTL Security Mechanism

   Version Compatibility:
      TBF

   Licensing:
      TBF

   Implementation Experience:

   Contact Information:
      TBF

   Last Updated:
      TBF

Authors' Addresses

   Rahul Aggarwal
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089
   USA
   Email: rahul@juniper.net

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089
   USA
   Email: kireeti@juniper.net

   Thomas D. Nadeau
   BT
   BT Centre
   81 Newgate Street
   London EC1A 7AJ
   UK
   Email: tom.nadeau@bt.com

Aggarwal, et al.        Expires 16 February 2027               [Page 18]
Internet-Draft              BFD for MPLS LSPs                August 2026

   George Swallow
   Retired
   Email: swallow@tbd.com

   Vengada Prasad Govindan (editor)
   Cisco Systems, Inc.
   Email: venggovi@cisco.com

   Kalyani Rajaraman
   Cisco Systems, Inc.
   Email: kalyanir@cisco.com

   Gregory Mirsky
   Ciena
   Email: gregimirsky@gmail.com

   Sam Aldrin
   NVIDIA
   Email: aldrin.ietf@gmail.com

Aggarwal, et al.        Expires 16 February 2027               [Page 19]