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

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, Seamless Bidirectional Forwarding Detection (S-BFD) 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 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 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.

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

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 The S‑BFD sub‑TLV is considered malformed if any of the following conditions are true:

The Length field of the S‑BFD sub‑TLV is less than 6 octets, or is inconsistent with the total length of the Optional TLVs it contains.
The Length field of an Optional TLV is inconsistent with the length expected for that Type, as specified in the table in .
More than one instance of the same Optional TLV type is present, as specified in .

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.

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, the speaker MUST follow the procedure specified in .
If more than one S‑BFD sub‑TLV is present in the same Tunnel Encapsulation Attribute, the speaker MUST process only the first instance and MUST ignore the subsequent ones.
If the S‑BFD sub‑TLV is syntactically valid, the speaker MUST pass it unchanged to the SRPM together with the rest of the SR Policy Candidate Path 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. 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 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: S‑BFD Optional TLVs

TLV Type	Description	Reference
1	S‑BFD Desired Min TX Interval	This document
2	S‑BFD Detection Multiplier	This document

Operational Considerations 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 . 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 MUST be as follows:

If the S‑BFD sub‑TLV is present but contains no Optional TLVs (Length = 6), the SRPM MUST establish the S‑BFD session using the device‑level default timer values.
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 MUST take precedence over the device‑level values for the S‑BFD session of that Candidate Path.
If the SRPM cannot support a requested CP‑level parameter, it MUST log an error and MUST fall back to the device‑level default value for that parameter, as specified in .
The CP‑level parameters MUST NOT alter or override the device‑level defaults for any other session. Their scope MUST be strictly limited to the Candidate Path with which they were advertised, and an implementation MUST NOT apply parameters received for one Candidate Path to any other Candidate Path or session.

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

References Normative References Informative References

Acknowledgements 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

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