| Internet-Draft | SR Policy for BFD Configuration | February 2026 |
| Li & Liu | Expires 17 August 2026 | [Page] |
Segment Routing (SR) Policies require fast failure detection for Candidate Paths (CPs) to enable rapid rerouting and high availability. Currently, the provisioning of SR Policies and the configuration of associated Bidirectional Forwarding Detection (BFD) or Seamless BFD (S-BFD) sessions are performed independently. This often necessitates separate mechanisms (e.g., manual configuration, NETCONF, or additional signaling) to associate BFD/S-BFD sessions with the SR Policies, resulting in complex and error-prone operations¶
This document defines extensions to BGP SR Policy for the simultaneous provisioning of SR Policy CPs and their BFD/S-BFD configuration parameters during policy advertisement. The extensions include optional sub-TLVs within the Tunnel Encapsulation Attribute to carry BFD/S-BFD configuration parameters (e.g., discriminators, intervals, multipliers).¶
These extensions simplify deployment in distributed or controller-based environments, reduce configuration overhead, and enhance operational efficiency for SR-based traffic engineering.¶
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/.¶
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 17 August 2026.¶
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.¶
Segment Routing (SR) [RFC8402] enables source routing by allowing a headend node to steer packet flows along specific paths using an ordered list of segments, eliminating intermediate per-path states. An SR Policy [RFC9256] defines such paths as one or more Candidate Paths (CPs), each comprising one or more segment lists.¶
To ensure high availability and fast failure detection in SR networks, Bidirectional Forwarding Detection (BFD) [RFC5880] or Seamless BFD (S-BFD) [RFC7880] is commonly used to monitor SR Policy path liveliness. However, current deployments configure SR Policies and BFD/S-BFD sessions independently. Typically, an SR Policy Controller [RFC9256] defines the set of policies and advertises them to SR Policy headend routers (typically ingress routers) via BGP SR Policy [RFC9830], or PCEP [RFC8664][RFC9603]. After SR Policies are advertised and installed, separate mechanisms (e.g., manual configuration, NETCONF/YANG, or additional signaling) are required to associate BFD/S-BFD parameters with the paths. This leads to increased operational complexity, longer provisioning times, and potential inconsistencies.¶
[I-D.ietf-pce-pcep-bfd-parameters] extends PCEP [RFC5440] to carry S-BFD parameters, which can be used together with [RFC8664] or [RFC9603] to complete S-BFD configuration while distributing SR Policies.¶
This document extends BGP SR Policy [RFC9830] to carry BFD/S-BFD parameters. These extensions enable simultaneous provisioning of SR Policies and their monitoring sessions, reducing separate configuration steps.¶
BGP itself does not install SR Policy CPs or BFD/S-BFD sessions into the data plane; these actions remain the responsibility of the SR Policy Module (SRPM) on the headend node.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section defines extensions to BGP SR Policy that allow an SR Policy Candidate Path (CP) to be advertised together with the configuration parameters required to establish BFD [RFC5880] or S‑BFD [RFC7880] sessions for monitoring the liveness of the path. The extensions are designed to be carried within the existing BGP SR Policy SAFI (73) and the Tunnel Encapsulation Attribute as specified in [RFC9830].¶
The BFD and S‑BFD configuration parameters are carried in new optional sub‑TLVs of the Tunnel Encapsulation Attribute [RFC9012]. These sub‑TLVs are applicable only for the SR Policy SAFI (AFI/SAFI 1/73 or 2/73). They MAY appear at most once in a given Tunnel Encapsulation Attribute; if multiple instances of the same sub‑TLV are present, only the first instance is processed and subsequent instances MUST be ignored. The Extended BGP SR Policy Encoding structure is as follows.¶
SR Policy SAFI NLRl: <Distinguisher, Color, Endpoint>
Attributes:
Tunnel Encapsulation Attribute (23)
Tunnel Type: SR Policy (15)
Binding SID
Preference
Priority
BFD Parameters (This Document)
S‑BFD Parameters (This Document)
SR Policy Name
SR Policy Candidate Path Name
Explicit NULL Label Policy (ENLP)
Segment List
Weight
Segment
Segment
...
...
The introduced sub‑TLVs in this document are not used by the BGP path selection process. They are passed unchanged to the SRPM on the headend node, which is responsible for validating the parameters and instantiating the corresponding BFD/S‑BFD sessions.¶
The BFD Parameters sub‑TLV carries the configuration parameters needed to establish a BFD session for monitoring the SR Policy CP. The format of this BFD Parameters Sub-TLV is as follows.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD1) | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: To be assigned by IANA from the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry (suggested value 21).¶
Length: Length of the value field in octets. MUST be 24.¶
Flags: 1 octet. Bits 0‑7 are reserved and MUST be set to zero on transmission and ignored on receipt.¶
Reserved: 1 octet. MUST be set to zero on transmission and ignored on receipt.¶
Other parameters have the same meaning as defined in [RFC5880].¶
The S‑BFD Parameters sub‑TLV carries the configuration parameters needed to establish a S‑BFD session for monitoring the SR Policy CP. The format of this S-BFD Parameters Sub-TLV is as follows.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD2) | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: To be assigned by IANA from the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry (suggested value 22).¶
Length: Length of the value field in octets. MUST be 24.¶
Flags: 1 octet. Bits 0‑7 are reserved and MUST be set to zero on transmission and ignored on receipt.¶
Reserved: 1 octet. MUST be set to zero on transmission and ignored on receipt.¶
Other parameters have the same meaning as defined in [RFC7880].¶
When establishing an S‑BFD session, the headend typically acts as an initiator and the endpoint as a reflector, as described in Section 3 of [RFC7880]. My Discriminator field contains the discriminator that will be used by the initiator, while Your Discriminator field specifies the reflector's discriminator.¶
A BGP SR Policy speaker that receives an SR Policy UPDATE containing BFD/S‑BFD sub‑TLVs MUST perform the following steps:¶
The SRPM on the headend node is responsible for interpreting the BFD/S‑BFD parameters and instantiating the corresponding monitoring sessions in the data plane. If the SRPM cannot support a requested parameter (e.g., an interval value below its hardware capability), it SHOULD log an error and MAY fall back to locally configured defaults or disable BFD/S‑BFD for that CP.¶
This document defines new Sub‑TLVs for the BGP Tunnel Encapsulation Attribute that enable BFD/S‑BFD configuration to be advertised along with SR Policy Candidate Paths.¶
IANA is requested to allocate two new code points in the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry:¶
| Code Point | Description | Reference |
|---|---|---|
| TBD1 | BFD Parameters Sub‑TLV | This document |
| TBD2 | S‑BFD Parameters Sub‑TLV | This document |
The suggested values are 21 for BFD Parameters Sub‑TLV, 22 for S‑BFD Parameters Sub‑TLV.¶
The security considerations of BGP [RFC4271], BGP SR Policy [RFC9830], BFD [RFC5880], and S‑BFD [RFC7880] apply to this document.¶
Advertisements of BFD/S‑BFD parameters via BGP SR Policy may expose sensitive network information, such as failure detection capabilities, session intervals, and discriminator values. These advertisements should be confined within trusted administrative domains to prevent information disclosure.¶
Malicious modification of BFD/S‑BFD parameters in BGP SR Policy advertisements could lead to denial of service or reduced monitoring effectiveness. For example, setting extremely short intervals might overwhelm network resources, while setting inappropriate discriminators could prevent session establishment. Implementations should validate received parameters against acceptable ranges before applying them.¶
Unauthorized configuration of BFD/S‑BFD sessions could be used to create false failure indications or hide actual failures. Network operators should ensure that BGP SR Policy sessions carrying BFD/S‑BFD configuration parameters are properly authenticated and authorized.¶
For BFD/S‑BFD sessions established based on the parameters advertised via BGP SR Policy, the security mechanisms defined in [RFC5880] and [RFC7880] should be used to protect against session spoofing and unauthorized access. This includes using authentication where appropriate.¶