New H3C Technologies

linchangwang.04414@h3c.com

China Mobile

liuyisong@chinamobile.com

China Telecom

Guangzhou zhuyq8@chinatelecom.cn

ZTE Corporation

China chen.ran@zte.com.cn

Cisco Systems

India aramahen@cisco.com

Routing IDR Working Group BGP-LS Segment Routing SR Policy Performance Metric Traffic Engineering This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS).

Introduction BGP Link State (BGP-LS) can be used to distribute link-state and traffic engineering (TE) information to external components . describes the mechanism for BGP-LS to distribute the information of TE policies. In some network scenarios, the controller needs to obtain the performance information of TE Policies, which can be used in service placement to meet better customer requirements and utilize network resources more efficiently. and describe the procedures for Performance Measurement in SR networks, using STAMP as defined in . The described procedure is used for SR paths (including SR Policies ). This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS).

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.

Advertisement of SR Policy Performance Metric defines several Link Attribute TLVs for BGP-LS to carry the IGP Traffic Engineering Performance Metric Extensions: Link Attribute TLVs for Performance Metric Extensions

TLV Code Point	Description
1114	Unidirectional Link Delay
1115	Min/Max Unidirectional Link Delay
1116	Unidirectional Delay Variation
1117	Unidirectional Link Loss

The above TLVs can be reused to report performance metrics for TE Policies. The scope of measurement and advertisement is described in . When used to describe the performance metric of the SR Policy NLRI, they are carried in the optional non-transitive BGP Path Attribute "BGP-LS Attribute" defined in . The semantics of the above TLVs comply with , except for that they are extended to describe TE Policies besides IGP links. The performance metric of SR Policy may be measured at the headend, for example, by using STAMP for SR Policy and . But the measurement methods are out of the scope of this document. The existing performance metrics above are all unidirectional. However, there are also requirements to advertise round-trip performance metrics for TE Policies. The BGP-LS extensions for round-trip TE performance metrics are defined in the .

Scope of Measurement The TLVs defined in this document and the reused TLVs from can be used to report performance metrics at two levels:

• SID-List level: When a metric is associated with a specific SID list, the TLV is carried as a sub-TLV of the corresponding SR Segment List TLV of the SR Policy Candidate Path NLRI.
• Candidate Path level: When a metric is associated with a particular SR candidate path, the TLV is carried as a top-level TLV in the BGP-LS Attribute associated with the SR Policy Candidate Path NLRI .

When multiple SID lists are active and load balanced for a candidate path, a candidate-path-level metric represents the performance measured across all active SID lists, which may be a weighted aggregate (weighted by the weight associated with each SID list, as defined in ). A value measured for a single SID list MUST NOT be advertised as representing the entire candidate path. In such cases, the metric MUST be reported at the SID-List level. When a candidate path or SID list becomes inactive, or when a SID list or its weight changes, the metrics associated with the affected SID list or candidate path SHOULD be re-advertised with updated information. When a candidate path or SID list is no longer active, the associated metrics that are no longer valid SHOULD be withdrawn and the latest measurement for the newly active SID list or candidate path SHOULD be advertised. A PCE MAY advertise these measurements on behalf of the headend, as permitted by . In this case, the measurements remain associated with the exact headend, candidate path, and SID list through the corresponding SR Policy Candidate Path NLRI as defined in . The measurement information MUST remain associated with the exact headend, candidate path, and SID list for which the measurement was performed. A value measured for one SID list MUST NOT be advertised as representing the entire candidate path. BGP-LS distributes state information; it does not by itself indicate when a measurement was taken or whether the measurement session remains operational. A stale value may therefore remain associated with a live SR Policy Candidate Path NLRI after the measurement session fails or becomes idle. The absence of a performance metric TLV in a BGP-LS update MUST be interpreted as "no current value is advertised" -- it MUST NOT be interpreted as a zero value and it does not imply withdrawal of the SR Policy Candidate Path NLRI. A BGP-LS consumer MUST NOT retain a previously received value for a given metric after an updated BGP-LS Attribute omits that TLV; the value MUST be considered invalid until a new measurement is advertised. For each TLV defined in this document and reused from , only one instance of a given metric type is permitted per container (i.e., per SR Segment List TLV for SID-List level metrics, or per BGP-LS Attribute for Candidate Path level metrics). If multiple instances of the same metric type appear in a container, the first syntactically valid instance MUST be used, and subsequent instances MUST be ignored. This rule is consistent with .

Relationship to RFC 9857 defines a mechanism for advertising SR Policy information using BGP-LS, including the SR Policy Candidate Path NLRI and associated state TLVs. In particular, defines:

• The SR Metric Constraint sub-TLV (Type 1215) for reporting optimization metrics and constraints at the candidate path level (Section 5.6.6 of )
• The SR Segment List Metric sub-TLV (Type 1207) for reporting computed metrics at the segment list level (Section 5.7.2 of )

The metrics defined in are computed path metrics, which are derived by the computation entity (i.e., the headend or the controller when the path is delegated). These include the optimization metric with its margin and bound used for path computation, as well as the computed metric values of the resulting path. They represent the computed or planned characteristics of an SR Policy based on the underlying IGP link-state TE metrics. In contrast, this document reuses the IGP Traffic Engineering Performance Metric Extensions TLVs defined in (Types 1114-1117) and extends their applicability to SR Policies. These TLVs are used to advertise measured operational performance metrics, which are obtained through active or passive measurement of the actual traffic forwarding behavior. The round-trip extensions defined in follow the same approach for bidirectional performance characteristics. The key distinctions between the two documents are:

• Source of metrics: reports computed or planned metrics from the path computation entity, while this document reports measured operational performance from actual traffic forwarding.
• TLV namespace: uses the SR Policy Metric Types (e.g., Types 1207 and 1215) within the SR Policy Attribute, while this document reuses the Link Attribute TLVs (Types 1114-1117) from .
• Directionality: The SR Policy Metric Types in are unidirectional, while this document also defines round-trip (bidirectional) performance metrics.
• Use case: provides SR Policy state information for path computation, reoptimization, service placement, and network visualization, while this document additionally enables operational monitoring and reoptimization based on measured performance metrics.

When both types of metrics are present, a consumer SHOULD treat them as complementary information:

• The computed metrics from indicate the computed path metric values from the computation entity (i.e., the headend or the controller when the path is delegated), which can be used for path validation and network visualization.
• The measured metrics from this document indicate the actual operational performance, which may vary due to network conditions, congestion, or anomalies. These provide additional information for service placement and reoptimization decisions based on measured performance.

Extensions for Round-trip TE Performance Metric The round-trip performance metrics defined in this section describe the measured performance of a packet traveling from the headend to the endpoint and back. An SR Policy identifies the forward path from the headend to the endpoint. The reverse path of a round-trip measurement is not explicitly identified by the SR Policy and may be an IGP path, another SR Policy, or a path selected by the measurement procedure. The reverse path may change independently of the advertised candidate path. The reverse path is not identified by any TLV defined in this document or in . Therefore, a receiver MUST NOT assume that the reverse path is congruent with the forward path, nor that the reverse path is represented by the advertised SR Policy Candidate Path NLRI. The round-trip metric value applies only to the combination of the advertised forward path and an unspecified reverse path.

Round-trip Delay TLV This TLV advertises the average round-trip delay for SR Policy. As described in , this TLV can be used at either the SID-List level or the Candidate Path level.

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

• Type: TBD
• Length: 4 octets
• Reserved: Reserved for future use. MUST be set to 0 when sent and MUST be ignored when received.
• A: Anomalous (A) Bit. Same semantics as the A Bit in Unidirectional Link Delay TLV .
• Delay: A 24-bit unsigned integer in microseconds. Same semantics as the Delay field in Unidirectional Link Delay TLV , except that the delay is round-trip.

Min/Max Round-trip Delay TLV This TLV advertises the minimum and maximum round-trip delay for SR Policy. As described in , this TLV can be used at either the SID-List level or the Candidate Path level.

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Min Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Max Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

• Type: TBD
• Length: 8 octets
• Reserved: Reserved for future use. MUST be set to 0 when sent and MUST be ignored when received.
• A: Anomalous (A) Bit. Same semantics as the A Bit in Min/Max Unidirectional Link Delay TLV .
• Min Delay: A 24-bit unsigned integer in microseconds. Same semantics as the Min Delay field in Min/Max Unidirectional Link Delay TLV , except that the delay is round-trip.
• Max Delay: A 24-bit unsigned integer in microseconds. Same semantics as the Max Delay field in Min/Max Unidirectional Link Delay TLV , except that the delay is round-trip.

Round-trip Delay Variation TLV This TLV advertises the average round-trip delay variation for SR Policy. As described in , this TLV can be used at either the SID-List level or the Candidate Path level.

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Delay Variation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

• Type: TBD
• Length: 4 octets
• Reserved: Reserved for future use. MUST be set to 0 when sent and MUST be ignored when received.
• Delay Variation: A 24-bit unsigned integer in microseconds. Same semantics as the Delay Variation field in Unidirectional Delay Variation TLV , except that the delay variation is round-trip.

Round-trip Loss TLV This TLV advertises the round-trip loss for SR Policy. As described in , this TLV can be used at either the SID-List level or the Candidate Path level.

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

• Type: TBD
• Length: 4 octets
• Reserved: Reserved for future use. MUST be set to 0 when sent and MUST be ignored when received.
• A: Anomalous (A) Bit. Same semantics as the A Bit in Unidirectional Link Loss TLV .
• Loss: A 24-bit unsigned integer representing packet loss as a percentage. Same semantics as the Link Loss field in Unidirectional Link Loss TLV , except that the loss is round-trip.

Security Considerations The procedures and protocol extensions defined in this document do not affect the BGP security model. The sub-TLVs introduced in this document allow an operator to advertise state information of SR Policy (e.g., bandwidth, delay), which may be sensitive and dynamic in nature. In very large networks, instability could occur if measurement intervals are configured at a frequency that overwhelms the processing capacity for announcement intervals. Therefore, care must be taken when configuring these values. Implementations SHOULD NOT allow the inter-update timer to be set lower than the measurement interval. Additionally, implementations SHOULD enforce configurable constraints to mitigate the risk of instability. For a discussion of BGP security, refer to the "Security Considerations" section of . Analyses of BGP security issues are also provided in and . Security considerations related to the acquisition and distribution of BGP-LS information are discussed in , , and . The mechanism proposed in this document is subject to the same vulnerabilities as any other protocol that relies on BGP-LS.

Management Considerations An implementation SHOULD allow the operator to specify neighbors to which Link-State NLRIs will be advertised and from which Link-State NLRIs will be accepted. An implementation SHOULD allow the operator to control the content of advertisements, such as whether or not to advertise latency, packet loss rate, bidirectional latency, and bidirectional packet loss rate. An implementation SHOULD allow the operator to control advertisement thresholds to avoid frequent announcements.

IANA Considerations IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs" under the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group. This document defines the following new TLV code points for round-trip performance metrics of SR Policies: New BGP-LS TLVs for Round-trip Performance Metrics

TLV Code Point	Description	Reference
TBD	Round-trip Delay	Section 4.1 of this document
TBD	Min/Max Round-trip Delay	Section 4.2 of this document
TBD	Round-trip Delay Variation	Section 4.3 of this document
TBD	Round-trip Loss	Section 4.4 of this document

This document also extends the applicability of the Link Attribute TLVs (Types 1114-1117) defined in to SR Policies. IANA is requested to update the corresponding entries in the "BGP-LS NLRI and Attribute TLVs" registry to include a reference to this document in addition to for the following TLVs: BGP-LS Link Attribute TLVs Extended for SR Policy

TLV Code Point	Description	Reference
1114	Unidirectional Link Delay	, Section 2 of this document
1115	Min/Max Unidirectional Link Delay	, Section 2 of this document
1116	Unidirectional Delay Variation	, Section 2 of this document
1117	Unidirectional Link Loss	, Section 2 of this document

References Normative References Informative References

Cross WG Information This section describes cross-working group information for use during the IETF review process. This section will be removed by the RFC editor prior to publication.

Link to Spring WG and describe the procedures for Performance Measurement in SR networks, using STAMP as defined in . The described procedure is used for SR paths (including SR Policies ). These SPRING features require the implementation of this document. This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS).

Interaction with PCE WG Stateful Path Computation Element Communication Protocol (PCEP) extensions have been defined for TE LSPs for Segment Routing (SR) and RSVP. describes the PCEP extensions for enabling and notifying end-to-end performance measurement including liveness detection for both PCE-Initiated and PCC- Initiated LSPs for SR-TE over MPLS and IPv6 data planes, and MPLS-TE using RSVP to an Active Stateful PCE. BGP-LS and PCEP are two distinct methods for reporting SR Policy performance metrics. Implementers can choose between BGP-LS and PCEP based on actual deployment requirements.

Interaction with SRV6ops Recommendations This optimization feature could be distributed to external components using BGP-LS extension defined in this document.