BGP SR Policy Extensions for Metric

An SR Policy is associated with one or more Candidate Paths (CPs), each of which is expressed as a segment list or a set of segment lists.. BGP SR Policy can be used to propogate SR Policy CPs to the SR Policy headend nodes in the network. After an SR Policy CP is installed on the headend node, packets can be steered into the SR Policy. For a particular BGP destination, if there are multiple BGP routes with different next-hops, BGP best path selection is performed and the IGP metric to the next-hop node may be used for tie-breaking to select the best path. When the path to the next-hop is resolved over an SR Policy, the IGP metric of the SR policy is needed for BGP path selection. This document defines the BGP extensions to carry the IGP metric of segment lists when BGP is used to propagate SR Policy CPs.

In network scenarios where there are multiple BGP routes to a particular destination prefix with different next-hops, and some of which are resolved via SR Policy, the metric of the SR Policy may be needed for BGP best path selection. The specific scenarios are as follows:

On PE1, the BGP route to the prefix advertised by CE1 has two candidate next-hops: PE2 and PE3. The BGP best path selection to the prefix of CE1 may be based on the IGP metric of the paths from PE1 to PE2 and from PE1 to PE3 respectively. The path toward PE2 is resolved via SR Policy-1, whose endpoint is PE2; similarly, the path toward PE3 is resolved via SR Policy-2. PE1 needs to know the the IGP metrics of the SR Policies to select the SR Policy which best meet the requirement. Thus the IGP metric of the Segment Lists which constitute the SR Policy CP needs to be conveyed to the headend node of SR Policy.

In order to carry the metric of an SR Policy CP, the tunnel encapsulation attribute of the BGP SR Policy is extended. The BGP SR Policy Encoding structure is as follows: SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>

Where the metric indicates the metric for the segment list.

A new sub-TLV called Metric Sub-TLV is defined. Metric sub-TLV specifies the metric of an SR policy Segment List. Each sub-TLV is encoded as shown in Figure 1. More than one metric Sub-TLVs may be present in one Segment List to refer to the metric values of different metric types.

* Type: Metric, 1 octet, TBD. * Length: 6 octets. * Metric Type: 1-octet field which identifies the type of the metric being used. The metric-type code points are listed in Section 7.2. * Flags: None are defined at this stage. Flags MUST be set to zero on transmission and MUST be ignored on receipt. * Metric Value: 4-octet value which indicates the metric of the computed path.

When an SR Policy headend node receives the SR Policy segment list with the metric field, the metric may be of any of the defined types: (IGP metric, Min Unidirection Link delay, TE metric, Hop Count, or SID List length).

Taking the scenario in Figure 1 as an example, according to the rules above, the metric of SR Policy 1 is 30, and the metric of SR Policy 2 is 40, then according to the BGP path selection tie-breaking rule, the BGP route with next-hop PE2 is selected as the metric of SR Policy 1 is smaller than that of SR Policy 2.

The authors would like to thank Liyan Song for the review and discussion.

IANA is requested to assign a new code point for Metric Sub-TLV in the "SR Policy Segment List Sub-TLVs" registry of the "BGP Tunnel Encapsulation" registry group.

The semantics of the Metric Type field in the Metric sub-TLV defined in this document is identifical to the metric types in the "BGP-LS SR Policy Metric Types" registry in the "BGP-LS Parameters" registry group. IANA is requested to rename the existing registry to "BGP/BGP-LS SR Policy Metric Types" registry. This is to allow the sharing of this registry for metric types in both BGP SR Policy and BGP-LS SR Policy. There is no change to the code points in this registry.

The BGP extensions defined in this document do not affect the base BGP security model. The BGP SR policy extension specified in this document is based on . The security requirements and mechanisms described in also apply to this document. SR operates within a trusted SR domain and its security considerations also apply to BGP sessions which are used for distributing SR Policy information. The distribution of SR Policy with metric information may pose additional mission-critical or commercially sensitive information about the network. The BGP sessions used for SR Policy distribution not automatic established and require configuration, network operator needs to ensure that only trusted nodes (that include both routers and controller applications) within the SR domain are configured to receive such information.