| Internet-Draft | SR Policy BFD Extensions | October 2026 |
| Li & Liu | Expires 2 May 2027 | [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 the associated Seamless Bidirectional Forwarding Detection (S-BFD) sessions are performed independently. This often necessitates separate mechanisms (e.g., manual configuration, NETCONF, or additional signaling) to associate 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 S-BFD configuration parameters during policy advertisement. The extensions include optional sub-TLVs within the Tunnel Encapsulation Attribute to carry 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 2 May 2027.¶
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, Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] is commonly used to monitor SR Policy path liveness. However, current deployments configure SR Policies and 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 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 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 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 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 S‑BFD configuration parameters are carried in a new optional sub‑TLV of the Tunnel Encapsulation Attribute [RFC9012]. This sub‑TLV is applicable only for the SR Policy SAFI (AFI/SAFI 1/73 or 2/73). It MAY appear at most once in a given Tunnel Encapsulation Attribute; if multiple instances of this 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 NLRI: <Distinguisher, Color, Endpoint>
Attributes:
Tunnel Encapsulation Attribute (23)
Tunnel Type: SR Policy (15)
Binding SID
Preference
Priority
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‑TLV in this document is not used by the BGP path selection process. It is passed unchanged to the SRPM on the headend node, which is responsible for validating the parameters and instantiating the corresponding S‑BFD sessions.¶
The S‑BFD sub‑TLV carries the configuration parameters needed to establish a S-BFD session [RFC7880] for monitoring an SR Policy Candidate Path. The presence of this Sub‑TLV in the Tunnel Encapsulation Attribute indicates that S‑BFD SHALL be enabled for the Candidate Path. The format of this Sub‑TLV is as follows.¶
The S‑BFD parameters carried in this sub‑TLV apply at the Candidate Path level. All Segment Lists within a given Candidate Path share the same S‑BFD configuration. Per-Segment-List differentiation of S‑BFD parameters is not supported, as the S‑BFD session monitors the reachability of the SR Policy endpoint (the tailend reflector), which is common to all Segment Lists of the same Candidate Path.¶
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 | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Optional TLVs (variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1 octet. To be assigned by IANA from the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry (suggested value 21).¶
Length: 1 octet. The total length, in octets, of the RESERVED, Your Discriminator, and Optional TLVs fields. That is, it is the length of the sub‑TLV Value field, not including the Type and Length fields, and it is consistent with the definition of the other sub‑TLVs of the Tunnel Encapsulation Attribute [RFC9012]. When no Optional TLVs are present, this field MUST be set to 6. An S‑BFD sub‑TLV whose Length field is less than 6 MUST be considered malformed.¶
RESERVED: 2 octets. Reserved for future use. RESERVED field SHOULD be set to zero on transmission and MUST be ignored on receipt.¶
Your Discriminator: 4 octets. This field identifies the S‑BFD reflector instance on the tailend node. It MUST match the local discriminator configured on the tailend reflector. This field is REQUIRED, as S‑BFD sessions rely on the Your Discriminator to demultiplex incoming S‑BFD packets as specified in [RFC7880].¶
Optional TLVs: variable-length. It is optional and MAY be used to carry additional parameters. Details are defined in Section 2.2.¶
Optional TLVs MAY be carried in S‑BFD Sub‑TLV in a sequential manner. The format of each Optional 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value (variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The following Optional TLV types are defined by this document:¶
| TLV Type | Description | Length | Reference |
|---|---|---|---|
| 1 | S‑BFD Desired Min TX Interval | 4 | This document |
| 2 | S‑BFD Detection Multiplier | 1 | This document |
Each Optional TLV type MUST NOT appear more than once within a given S‑BFD sub‑TLV. If more than one instance of the same Optional TLV type is present, the S‑BFD sub‑TLV MUST be considered malformed and MUST be handled as specified in Section 2.3.¶
The S‑BFD Desired Min TX Interval TLV (Type=1) carries the desired minimum transmit interval for the S‑BFD session. Its format 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=1 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the S‑BFD Desired Min TX Interval TLV are as follows:¶
The S‑BFD Detection Multiplier TLV (Type=2) carries the detection multiplier for the S‑BFD session. Its format 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=2 | Length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multiplier | +-+-+-+-+-+-+-+-+
The fields of the S‑BFD Detection Multiplier TLV are as follows:¶
The S‑BFD sub‑TLV is considered malformed if any of the following conditions are true:¶
An Optional TLV with an unrecognized Type MUST be ignored and skipped during processing; it does not make the S‑BFD sub‑TLV malformed.¶
If the S‑BFD sub‑TLV is malformed, the speaker MUST ignore it and MUST continue processing the rest of the Tunnel Encapsulation Attribute. The SR Policy Candidate Path is then installed without the S‑BFD parameters carried in this sub‑TLV. S‑BFD monitoring for that Candidate Path MAY still be configured through existing local mechanisms (e.g., manual configuration). The error SHOULD be logged for the operator.¶
If the SRPM cannot support a requested parameter (e.g., an interval value below its hardware capability), it MUST log an error and MUST fall back to the device-level default value for that parameter.¶
A BGP SR Policy speaker that receives an SR Policy UPDATE containing the S‑BFD sub‑TLV MUST perform the following steps:¶
When establishing an S‑BFD session, the headend of the SR Policy acts as the S‑BFD initiator and the endpoint of the SR Policy acts as the S‑BFD reflector, as described in Section 4 of [RFC7880]. The Your Discriminator field in the fixed header identifies the S‑BFD reflector instance associated with the monitored Candidate Path.¶
The SRPM on the headend node is responsible for interpreting the S‑BFD parameters and instantiating the corresponding monitoring sessions in the data plane, as described in Section 2.¶
This document defines a new Sub‑TLV for the BGP Tunnel Encapsulation Attribute that enables S‑BFD configuration to be advertised along with SR Policy Candidate Paths.¶
IANA is requested to allocate a new code point in the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry:¶
| Code Point | Description | Reference |
|---|---|---|
| TBD1 | S‑BFD Sub‑TLV | This document |
The suggested value is 21.¶
IANA is also requested to create a new registry named "S-BFD Optional TLVs" as a subregistry of the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry. The code points of this registry are scoped to the S‑BFD Sub‑TLV (code point TBD1) and identify the Optional TLVs carried within that sub‑TLV. The initial contents of this registry are as follows:¶
| TLV Type | Description | Reference |
|---|---|---|
| 1 | S‑BFD Desired Min TX Interval | This document |
| 2 | S‑BFD Detection Multiplier | This document |
Specifying aggressive detection timers on many Candidate Paths simultaneously can stress the S‑BFD packet processing capacity of the involved nodes. S‑BFD session scaling varies across implementations and hardware platforms, and the scale achievable when per‑path timer overrides are deployed can be significantly lower than the theoretical maximum. Operators SHOULD verify the S‑BFD session scale that each headend can sustain before such timers are distributed to a large number of Candidate Paths, and SHOULD NOT assume that the theoretical maximum is achievable.¶
In many deployments, S‑BFD timer parameters are better determined on a per‑device basis. When per‑path customization is used, the SRPM SHOULD apply overrides selectively, the operator SHOULD monitor the total number of S‑BFD sessions per headend, and fallback events SHOULD be logged as specified in Section 2.3.¶
The S‑BFD parameters defined in this document participate in a two‑level configuration model:¶
The interaction between these two levels MUST be as follows:¶
The security considerations of BGP [RFC4271], BGP SR Policy [RFC9830], and S‑BFD [RFC7880] apply to this document.¶
Advertisements of S‑BFD parameters via BGP SR Policy may expose sensitive network information, such as failure detection capabilities, session intervals, and discriminator values. These advertisements MUST be confined within trusted administrative domains to prevent information disclosure.¶
Malicious modification of 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 MUST validate received parameters against acceptable ranges before applying them, and MUST discard parameters that fall outside those ranges.¶
Unauthorized configuration of S‑BFD sessions could be used to create false failure indications or hide actual failures. Network operators MUST ensure that BGP SR Policy sessions carrying S‑BFD configuration parameters are properly authenticated and authorized.¶
For S‑BFD sessions established based on the parameters advertised via BGP SR Policy, the security mechanisms defined in [RFC7880] MUST be used to protect against session spoofing and unauthorized access. This includes using authentication where appropriate.¶
The authors thank Susan Hares for her detailed review and constructive suggestions. They also thank Changwang Lin (New H3C Technologies), Xuhui Cai and Yunyang Lu (China Unitechs), and Zhibo Hu (Huawei) for their valuable comments and suggestions¶
The following people contributed substantially to the content of this document:¶
Jeffrey Haas¶