BGP SR Policy Extensions for BFD Configuration

BGP SR Policy Extensions for BFD Configuration China Mobile

29 Finance Avenue, Xicheng District Beijing CN lizhenqiang@chinamobile.com

China Mobile

10 Manbai Road, Changping District Beijing CN liusongwl@chinamobile.com

Routing Inter-Domain Routing BGP SR Policy BFD S-BFD 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 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.

Introduction Segment Routing (SR) 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 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) or Seamless BFD (S-BFD) is commonly used to monitor SR Policy path liveness. However, current deployments configure SR Policies and BFD/S-BFD sessions independently. Typically, an SR Policy Controller defines the set of policies and advertises them to SR Policy headend routers (typically ingress routers) via BGP SR Policy , or PCEP . 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. extends PCEP to carry S-BFD parameters, which can be used together with or to complete S-BFD configuration while distributing SR Policies. This document extends BGP SR Policy 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 relationship between this document and existing BFD signaling mechanisms in BGP is discussed in .

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

BGP SR Policy Extensions for S‑BFD Configuration 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 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 . The S‑BFD configuration parameters are carried in a new optional sub‑TLV of the Tunnel Encapsulation Attribute . 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.

Extended BGP SR Policy Encoding 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.

S‑BFD Sub‑TLV The S‑BFD sub‑TLV carries the configuration parameters needed to establish a Seamless BFD (S‑BFD) session 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.

S‑BFD Sub‑TLV Format Type: 1 octet. To be assigned by IANA from the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry (suggested value 22). Length: 1 octet. Length of the Optional TLVs field in octets. If no Optional TLVs are present, this field MUST be set to 0. 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 . Optional TLVs: variable-length. It is optional and MAY be used to carry additional parameters. Details are defined in .

S‑BFD Optional TLVs Optional TLVs MAY be carried in S‑BFD Sub‑TLV in a sequential manner. The format of each Optional TLV is as follows:

Optional TLV Format Where:

Type:: 2 octets. The type of the Optional TLV. The following types are defined in this document (see the table below for the complete list).
Length:: 2 octets. The length of the Value field in octets.
Value:: A variable-length field that carries the TLV-specific data.

The following Optional TLV types are defined by this document: S‑BFD Parameters Optional TLV Types

TLV Type	Description	Length	Reference
0	Reserved		This document
1	S‑BFD Desired Min TX Interval	4	This document
2	S‑BFD Detection Multiplier	1	This document
3–249	Unassigned
250–254	Experimental Use		This document
255	Reserved		This document

Desired Min TX Interval TLV 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:

S‑BFD Desired Min TX Interval TLV Format (Type=1) The fields of the S‑BFD Desired Min TX Interval TLV are as follows:

Type:: 2 octets. Set to 1.
Length:: 2 octets. Set to 4.
Desired Min TX Interval:: 4 octets. Specifies the minimum transmit interval for the S‑BFD session, in microseconds. This field has the same semantics as the "Desired Min TX Interval" defined in .

Detection Multiplier TLV The S‑BFD Detection Multiplier TLV (Type=2) carries the detection multiplier for the S‑BFD session. Its format is as follows:

S‑BFD Detection Multiplier TLV Format (Type=2) The fields of the S‑BFD Detection Multiplier TLV are as follows:

Type:: 2 octets. Set to 2.
Length:: 2 octets. Set to 1.
Multiplier:: 1 octet. Specifies the detection multiplier for the S‑BFD session. This field has the same semantics as the "Detect Mult" defined in . The value MUST be in the range 1 through 255.

Error Handling If present, Optional TLVs MUST appear in the order specified in the table above. A Sub‑TLV is considered malformed if any of the following conditions are true:

The Length field of an Optional TLV is inconsistent with the expected length for that Type.
An Optional TLV appears more than once.
Optional TLVs do not appear in ascending order of Type.

An Optional TLV with an unrecognized Type MUST be ignored and skipped during processing; it does not make the Sub‑TLV malformed. If the Sub‑TLV is malformed, the speaker MUST ignore the Sub‑TLV and continue processing the rest of the Tunnel Encapsulation Attribute. The SR Policy Candidate Path is installed without the S‑BFD parameters carried in this sub‑TLV; S‑BFD monitoring may still be configured for that CP through existing local mechanisms (e.g., manual configuration). The error SHOULD be logged for the operator. If the Sub‑TLV is syntactically valid, the speaker MUST pass it unchanged to the SRPM together with the rest of the SR Policy CP information. 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 . The Your Discriminator field in the fixed header identifies the S‑BFD reflector instance associated with the monitored Candidate Path. 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 S‑BFD for that CP.

BGP SR Policy Speaker Behavior A BGP SR Policy speaker that receives an SR Policy UPDATE containing the S‑BFD sub‑TLV MUST perform the following steps:

If the S‑BFD sub‑TLV is malformed (e.g., length inconsistent), the speaker MUST ignore the sub‑TLV and continue processing the UPDATE. The CP is installed without the sub‑TLV's S‑BFD parameters; S‑BFD monitoring for that CP falls back to existing local mechanisms. The error SHOULD be logged.
If multiple instances of the S‑BFD sub‑TLV are present in the same UPDATE, only the first one is processed and subsequent ones MUST be ignored.
If the sub‑TLV is syntactically valid, the speaker MUST pass it unchanged to the SRPM together with the rest of the SR Policy CP information.

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 .

IANA Considerations 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: BGP Tunnel Encapsulation Attribute Sub-TLV Values

Code Point	Description	Reference
TBD1	S‑BFD Sub‑TLV	This document

The suggested value is 22. A new registry called "S-BFD Optional TLVs" is solicited to be created in the "BGP Tunnel Encapsulation Attribute Sub‑TLVs" registry. S‑BFD Optional TLVs

TLV Type	Description	Reference
0	Reserved	This document
1	S‑BFD Desired Min TX Interval	This document
2	S‑BFD Detection Multiplier	This document
3–249	Unassigned
250–254	Experimental Use	This document
255	Reserved	This document

Operational Considerations Specifying aggressive detection timers on many Candidate Paths simultaneously may stress the BFD packet processing capacity of the involved nodes. BFD session scaling varies across implementations and hardware platforms, and the achievable scale may be significantly lower than the theoretical maximum when per‑path timer overrides are deployed. In many deployments, S‑BFD timer parameters are best determined on a per‑device basis. When per‑path customization is used, it is RECOMMENDED to apply overrides selectively, monitor the total number of S‑BFD sessions per headend, and log fallback events when the SRPM cannot support a requested parameter. The S‑BFD parameters defined in this document participate in a two‑level configuration model:

Device‑level: locally configured or factory‑default timer values that serve as the global baseline for all S‑BFD sessions on the node.
Candidate Path (CP) level: parameters advertised by the controller via the S‑BFD sub‑TLV, which apply only to the S‑BFD session associated with that specific Candidate Path.

The interaction between these two levels is as follows:

If the S‑BFD sub‑TLV is present but contains no Optional TLVs (Length = 0), the SRPM uses the device‑level default timer values to establish the S‑BFD session. This is an intentional design point: the controller mandates monitoring but defers the timer configuration to the local device.
If the S‑BFD sub‑TLV carries Optional TLVs (e.g., the S‑BFD Desired Min TX Interval TLV or the S‑BFD Detection Multiplier TLV), the CP‑level values take precedence. If the SRPM cannot support a requested CP‑level parameter, it SHOULD log an error and fall back to the device‑level defaults for that parameter.
The CP‑level parameters do not alter or override the device‑level defaults for any other sessions; their scope is strictly limited to the Candidate Path with which they were advertised.

Security Considerations The security considerations of BGP , BGP SR Policy , BFD , and S‑BFD 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 should 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 should validate received parameters against acceptable ranges before applying them. Unauthorized configuration of 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 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 and should be used to protect against session spoofing and unauthorized access. This includes using authentication where appropriate.

References Normative References Informative References

Acknowledgements The authors would also like to thank Changwang Lin from New H3C Technologies, as well as Xuhui Cai and Yunyang Lu from China Unitechs, and Zhibo Hu from Huawei, for their valuable comments and constructive suggestions that helped improve and refine this document.

Contributors The following people contributed substantially to the content of this document: Jeffrey Haas