| Internet-Draft | BGP SR Policy Extensions for CATS | October 2025 |
| Xiong, et al. | Expires 18 April 2026 | [Page] |
An SR (Segment Routing) Policy is a set of candidate paths, each consisting of one or more segment lists. The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. This document proposes the BGP SR policy extensions for distributing CATS services.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 18 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in [RFC9256]. In order to distribute SR policies to the headend, [RFC9830] specifies a mechanism by using BGP.¶
The CATS (Computing-Aware Traffic Steering) as per [I-D.ietf-cats-framework] can steer traffic between clients of a service and sites offering the service. Segment Routing (SR) can be used as an encapsulation solution for CATS data plane from an Ingress CATS-Router to an Egress CATS-Router while using an anycast IP address as the Computing-aware Service ID (CS-ID) associated with a service. And the CATS Service Contact Instance ID (CSCI-ID) is representing a specific service contact instance which serves the service request. This document proposes the BGP SR policy extensions for distributing CATS services.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
As per [I-D.ietf-cats-framework], a standalone C-PS can be a functional component of a centralized controller. And C-PS will collect the metric information from C-SMA and C-NMA and also determine the best paths to forward traffic. When the SR is used as the data plane encapsulation for CATS from an Ingress CATS-Router to an Egress CATS-Router, the C-PS or the controller may distribute SR policies to the CATS Ingress CATS-Router.¶
The Figure 1 shows an example of BGP SR Policy for CATS service from CATS-Forwarder 1 as ingress node to CATS-Forwarder 2 as egress node. The SR policy is configured with policy color 100 and NLRI is mapping to the CATS service which is refereed as CS-ID 1. Two service sites with service contact instances represented with CSCI-ID 1 and CSCI-ID 2 are connected to the CATS-Forwarder 2 from the interfaces with Endpoint SID End.DX-1 and End.DX-2. The SR policy may be distributed to carry the identifiers of CATS services.¶
+------+
:<------| C-PS |
: | |<------+ Service Site 1
BGP SR Policy: : +------+ | End.DX-1 +---------+
NLRI: CS-ID 1 : ^ | +---|CS-ID 1 |
Policy Color: 100 : | | | |CSCI-ID 1|
Endpoint SID: : | +----------------+ | +---------+
End.DX-1/End.DX-2 : | | C-SMA |---| Service Site 2
: | +----------------+ | +---------+
: | |CATS-Forwarder 2| +---|CS-ID 1 |
: | +----------------+ |CSCI-ID 2|
+--------+ : | | End.DX-2 +---------+
| Client | : Network | +----------------------+
+--------+ : metrics | | +-------+ |
| : +----| C-NMA | |
| : | +-------+ |
+----------------+ | | |
|CATS-Forwarder 1|<-----------+ |
| |-------| |
+----------------+ | Underlay |
| Infrastructure |
| |
+----------------------+
Figure 1: Example of BGP SR Policy for CATS
¶
As per [I-D.ietf-cats-framework], CS-ID is representing a service in CATS, which the clients use to access it. CSCI-ID is representing a specific service contact instance. As defined in [RFC9830], the SR policy with CS-ID and CSCI-ID encoding structure is shown in Figure 2 as follows:¶
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encapsulation Attribute (23)
Tunnel Type: SR Policy (15)
Binding SID
SRv6 Binding SID
Preference
Priority
Policy Name
Policy Candidate Path Name
Explicit NULL Label Policy (ENLP)
CS-ID
CSCI-ID
CSCI-ID
...
Segment List
Weight
Segment
Segment
...
...
Figure 2: SR policy with CS-ID and CSCI-ID Encoding
¶
The format of CS-ID Sub-TLV is shown in Figure 3 as follows:¶
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 | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CS-ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: CS-ID sub-TLV
¶
where:¶
Type: TBD.¶
Length: variable.¶
Flags: 1 octet of flags. None are defined at this stage. Flags SHOULD be set to zero on transmission and MUST be ignored on receipt.¶
RESERVED: 1 octet of reserved bits. SHOULD be set to zero on transmission and MUST be ignored on receipt.¶
CS-ID: indicates the identifier associated with the CATS service. It is 4 octets which carry a 32-bit unsigned non-zero number in SR networks and 16 octets which carry a 128-bit unsigned non-zero number in SRv6 networks.¶
The format of CSCI-ID Sub-sub-TLV is shown in Figure 4 as follows:¶
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 | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CSCI-ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: CSCI-ID sub-sub-TLV
¶
where:¶
Type: TBD.¶
Length: variable.¶
Flags: 1 octet of flags. None are defined at this stage. Flags SHOULD be set to zero on transmission and MUST be ignored on receipt.¶
RESERVED: 1 octet of reserved bits. SHOULD be set to zero on transmission and MUST be ignored on receipt.¶
CSCI-ID: indicates the identifier for a specific service contact instance. It is 4 octets which carry a 32-bit unsigned non-zero number in SR networks and 16 octets which carry a 128-bit unsigned non-zero number in SRv6 networks.¶
To be discussed in future versions of this document.¶
TBD.¶