BGP SR Policy Extensions for BFD Configuration

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 liveliness. 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 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.

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 BFD/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 BFD or 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 BFD and S‑BFD configuration parameters are carried in new optional sub‑TLVs of the Tunnel Encapsulation Attribute . 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.

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

BFD Parameters Sub‑TLV 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.

BFD Parameters Sub‑TLV Format 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 .

S‑BFD Parameters Sub‑TLV 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.

S‑BFD Parameters Sub‑TLV Format 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 . 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 . My Discriminator field contains the discriminator that will be used by the initiator, while Your Discriminator field specifies the reflector's discriminator.

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

If the BFD/S‑BFD sub‑TLVs are malformed (e.g., length inconsistent, reserved fields non‑zero), the UPDATE MUST be handled according to the "treat‑as‑withdraw" strategy .
If multiple BFD‑related sub‑TLVs (BFD Parameters, S‑BFD Parameters) are present in the same UPDATE, only the first one is processed and subsequent ones MUST be ignored.
If the sub‑TLVs are syntactically valid, the speaker MUST pass them 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 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.

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

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.

Security Considerations The security considerations of BGP , BGP SR Policy , BFD , and S‑BFD 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 and should be used to protect against session spoofing and unauthorized access. This includes using authentication where appropriate.