BGP Extensions for Inter-Domain Flexible Algorithm with Segment Routing over IPv6 (SRv6)

IGP Flexible Algorithm (Flex-Algo) provides a mechanism for IGP nodes to compute the best paths according to a set of constraints in the topology and computation metrics. Segment Routing over IPv6 (SRv6) can be used as one data plane of IGP Flex-Algo. In SRv6 networks, services may be carried across multiple network domains which are under the same administration. For some services, it is expected that the an end-to-end inter-domain path can be computed according to the same constraints (such as low latency) defined by Flex-Algo. This document defines the BGP extensions to advertise SRv6 locators as IPv6 prefixes, together with the associated algorithm across the AS boundary.

This section shows a typical scenario of the inter-domain algorithm-specific IPv6 route distribution in Figure 1. AS1 and AS2 belong to the same network operator, the service from CE1 to CE2 requires an inter-domain path from PE1 to PE2 based on specific constraints (such as low latency). In each domain, the intra-domain low latency path can be computed based on flexible algorithm. In both AS1 and AS2, Flex-Algo 128 is defined to compute the best path using the latency metrics. In AS2, the SRv6 locator of PE2 which is associated with Flex-Algo 128 is advertised in IGP. To make the SRv6 locator of PE2 reachable in AS1, the SRv6 locator of PE2 is advertised as an IPv6 prefix by ASBR2 to ASBR1 in BGP IPv6 Unicast . However, the associated algorithm is not carried in the Update message. When the BGP route is redestributed into IGP in AS1, the SRv6 locator of PE2 will be treated as a IPv6 prefix without algorithm information. As a result, the IGP nodes in AS1 will only compute the shortest path to the SRv6 locator of PE2 using the default IGP metric, then inter-domain path computed based on Flex-Algo 128 is not possible.

One possible approach to achieve inter-domain algorithm-specific path computation is to configure route-policy on ASBR1 to apply Flex-Algo 128 to specific prefixes received from ASBR2. This requires manual configuration of route-policy for each prefix which is algorithm-specific SRv6 locators, hus it is complex and error-prone. A preferable approach is to add the associated algorithm information in the BGP routes advertised across the AS boundary, so that when the BGP route is redistributed into IGP, the associated algorithm could be obtained automatically.

A new extended community is defined to carry the algorithm information associated with the prefix carried in the IPv6 Unicast NLRI. The Flex-Algo extended community is a transitive Opaque Extended Community which is used to carry the Algorithm ID associated with the IPv6 prefixes advertised in BGP Update message. The encoding of the Flex-Algo Extended Community is shown as below:

The value of the extended Type field is 0x03, which indicates it is a transitive opaque extended community. The value of the low-order octet of the extended Type field is TBA. Flags: 1 octet, carries the flags related to an Algorithm. No flag is defined in this document. Algorithm: 1 octet, it can be the algorithm as defined in the "IGP Algorithm Types" registry , or Flexible Algorithms as defined in . Reserved: 4-octet reserved for future use.

IANA is requested to assign a code point for Flex-Algo Extended Community from the "Transitive Opaque Extended Community Sub-Types" subregistry of the "Border Gateway Protocol (BGP) Extended Communities" registry:

This document does not introduce any additional security considerations than those described in and .

The authors would like to thank XXX for the review and valuable discussion.