SR Policy seg types: Segment Type Extensions for BGP Segment Routing (SR) Policy
Encoding every Segment Routing segment type inside a BGP SR Policy.
Talaulikar, K., Ed., Filsfils, C., Previdi, S., Mattes, P., and D. Jain, "Segment Type Extensions for BGP Segment Routing (SR) Policy", RFC 9831, DOI 10.17487/RFC9831, September 2025, <https://www.rfc-editor.org/info/rfc9831>.
@misc{rfc9831,
series = {Request for Comments},
number = 9831,
howpublished = {RFC 9831},
publisher = {RFC Editor},
doi = {10.17487/RFC9831},
url = {https://www.rfc-editor.org/info/rfc9831},
author = {K. Talaulikar and C. Filsfils and S. Previdi and P. Mattes and D. Jain},
title = {{Segment Type Extensions for BGP Segment Routing (SR) Policy}},
pagetotal = 16,
year = 2025,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) K. Talaulikar, Ed.
Request for Comments: 9831 C. Filsfils
Category: Experimental Cisco Systems
ISSN: 2070-1721 S. Previdi
Huawei Technologies
P. Mattes
Microsoft
D. Jain
Google
September 2025
Segment Type Extensions for BGP Segment Routing (SR) Policy
Abstract
This document specifies the signaling of additional Segment Routing
(SR) Segment Types for SR Policies in BGP using the SR Policy
Subsequent Address Family Identifier (SAFI).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9831.
Copyright Notice
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.
Table of Contents
1. Introduction
1.1. Requirements Language
2. Segment Type Sub-TLVs
2.1. Segment Type C
2.2. Segment Type D
2.3. Segment Type E
2.4. Segment Type F
2.5. Segment Type G
2.6. Segment Type H
2.7. Segment Type I
2.8. Segment Type J
2.9. Segment Type K
2.10. SR Policy Segment Flags
3. IANA Considerations
3.1. SR Policy Segment List Sub-TLVs
3.2. SR Policy Segment Flags
4. Security Considerations
5. Manageability Considerations
6. Normative References
Acknowledgments
Authors' Addresses
1. Introduction
The BGP Segment Routing (SR) Policy Subsequent Address Family
Identifier (SAFI) was introduced by [RFC9830] for the advertisement
of SR Policies [RFC8402]. [RFC9830] introduced the base SR Segment
Types A and B as specified by the SR Policy Architecture [RFC9256].
This document specifies the extensions for the advertisement of the
remaining SR Segment Types defined in [RFC9256] in the SR Policy SAFI
for both SR-MPLS (see [RFC8660]) and Segment Routing over IPv6 (SRv6)
(see [RFC8754] and [RFC8986]).
The extensions in this document do not impact the SR Policy
operations or fault management as specified in [RFC9830].
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Segment Type Sub-TLVs
The Segment List sub-TLV [RFC9830] encodes a single explicit path
towards the endpoint as described in Section 5.1 of [RFC9256]. The
Segment List sub-TLV includes the elements of the paths (i.e.,
segments).
A Segment sub-TLV describes a single segment in a segment list (i.e.,
a single element of the explicit path).
Section 4 of [RFC9256] defines several Segment Types for SR-MPLS and
SRv6 that are listed below as a reminder:
Type A: SR-MPLS Label
Type B: SRv6 SID
Type C: IPv4 Prefix with optional SR Algorithm
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS
Type E: IPv4 Prefix with Local Interface ID
Type F: IPv4 Addresses for link endpoints as Local, Remote pair
Type G: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SR-MPLS
Type H: IPv6 Addresses for link endpoints as Local, Remote pair for
SR-MPLS
Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6
Type J: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SRv6
Type K: IPv6 Addresses for link endpoints as Local, Remote pair for
SRv6
[RFC9830] specifies Segment Type Sub-TLVs for the Segment Types A and
B. The following subsections specify the sub-TLVs used for encoding
each of the other Segment Types above.
As specified in Sections 2.4.4 and 2.4.4.2 of [RFC9830], validation
of an explicit path encoded by the Segment List sub-TLV is beyond the
scope of BGP and performed by the Segment Routing Policy Module
(SRPM) as described in Section 5 of [RFC9830]. As specified in
Section 5.1 of [RFC9256], a mix of SR-MPLS and SRv6 segments make the
segment-list invalid.
2.1. Segment Type C
The Type C Segment sub-TLV encodes an IPv4 node address, SR
Algorithm, and an optional SR-MPLS Segment Identifier (SID). The
format is 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 | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Type C Segment Sub-TLV
Where:
Type: 3
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be 10
when the SR-MPLS SID is present; else, it MUST be 6.
Flags: 1 octet of flags as defined in Section 2.10.
SR Algorithm: 1 octet specifying the SR Algorithm as described in
Section 3.1.1 of [RFC8402] when the A-Flag as defined in
Section 2.10 is set. The SR Algorithm is used by the SRPM
[RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag
is not set, this field MUST be set to zero on transmission and
MUST be ignored on receipt.
IPv4 Node Address: A 4-octet IPv4 address representing a node.
SR-MPLS SID: Optional. A 4-octet field containing a label, Traffic
Class (TC), bottom-of-stack (S), and TTL as defined for Segment
Type A [RFC9830].
2.2. Segment Type D
The Type D Segment sub-TLV encodes an IPv6 node address, SR
Algorithm, and an optional SR-MPLS SID. The format is 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 | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Type D Segment Sub-TLV
Where:
Type: 4
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be 22
when the SR-MPLS SID is present; else, it MUST be 18.
Flags: 1 octet of flags as defined in Section 2.10.
SR Algorithm: 1 octet specifying the SR Algorithm as described in
Section 3.1.1 of [RFC8402] when the A-Flag as defined in
Section 2.10 is set. The SR Algorithm is used by the SRPM
[RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag
is not set, this field MUST be set to zero on transmission and
MUST be ignored on receipt.
IPv6 Node Address: A 16-octet IPv6 address representing a node.
SR-MPLS SID: Optional. A 4-octet field containing a label, TC, S,
and TTL as defined for Segment Type A [RFC9830].
2.3. Segment Type E
The Type E Segment sub-TLV encodes an IPv4 node address, a local
interface Identifier (Local Interface ID), and an optional SR-MPLS
SID. The format is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Type E Segment Sub-TLV
Where:
Type: 5
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be 14
when the SR-MPLS SID is present; else, it MUST be 10.
Flags: 1 octet of flags as defined in Section 2.10.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero
on transmission and MUST be ignored on receipt.
Local Interface ID: 4 octets carrying the interface index of the
local interface (refer to TLV 258 of [RFC9552]).
IPv4 Node Address: A 4-octet IPv4 address representing a node.
SR-MPLS SID: Optional. A 4-octet field containing a label, TC, S,
and TTL as defined for Segment Type A [RFC9830].
2.4. Segment Type F
The Type F Segment sub-TLV encodes an adjacency local address, an
adjacency remote address, and an optional SR-MPLS SID. The format is
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Type F Segment Sub-TLV
Where:
Type: 6
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be 14
when the SR-MPLS SID is present; else, it MUST be 10.
Flags: 1 octet of flags as defined in Section 2.10.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero
on transmission and MUST be ignored on receipt.
Local IPv4 Address: A 4-octet IPv4 address representing the local
link address of the node.
Remote IPv4 Address: A 4-octet IPv4 address representing the link
address of the neighbor node.
SR-MPLS SID: Optional. A 4-octet field containing a label, TC, S,
and TTL as defined for Segment Type A [RFC9830].
2.5. Segment Type G
The Type G Segment sub-TLV encodes an IPv6 link-local adjacency with
an IPv6 local node address, a local interface identifier (Local
Interface ID), an IPv6 remote node address, a remote interface
identifier (Remote Interface ID), and an optional SR-MPLS SID. The
format is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Type G Segment Sub-TLV
Where:
Type: 7
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be 46
when the SR-MPLS SID is present; else, it MUST be 42.
Flags: 1 octet of flags as defined in Section 2.10.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero
on transmission and MUST be ignored on receipt.
Local Interface ID: 4 octets of interface index of local interface
(refer to TLV 258 of [RFC9552]).
IPv6 Local Node Address: A 16-octet IPv6 address representing the
node.
Remote Interface ID: 4 octets of interface index of remote interface
(refer to TLV 258 of [RFC9552]). The value MAY be set to zero
when the local node address and interface identifiers are
sufficient to describe the link.
IPv6 Remote Node Address: A 16-octet IPv6 address. The value MAY be
set to zero when the local node address and interface identifiers
are sufficient to describe the link.
SR-MPLS SID: Optional. A 4-octet field containing a label, TC, S,
and TTL as defined for Segment Type A [RFC9830].
2.6. Segment Type H
The Type H Segment sub-TLV encodes an adjacency local address, an
adjacency remote address, and an optional SR-MPLS SID. The format is
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Type H Segment Sub-TLV
Where:
Type: 8
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be 38
when the SR-MPLS SID is present; else, it MUST be 34.
Flags: 1 octet of flags as defined in Section 2.10.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero
on transmission and MUST be ignored on receipt.
Local IPv6 Address: A 16-octet IPv6 address representing the local
link address of the node.
Remote IPv6 Address: A 16-octet IPv6 address representing the link
address of the neighbor node.
SR-MPLS SID: Optional. A 4-octet field containing a label, TC, S,
and TTL as defined for Segment Type A [RFC9830].
2.7. Segment Type I
The Type I Segment sub-TLV encodes an IPv6 node address, an SR
Algorithm, and an optional SRv6 SID. The format is 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 | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Type I Segment Sub-TLV
Where:
Type: 14
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be one
of the following:
* 42 when both SRv6 SID and SRv6 Endpoint Behavior and SID
Structure are present,
* 34 when only SRv6 SID is present, or
* 18 when the SRv6 SID is not present.
Flags: 1 octet of flags as defined in Section 2.10.
SR Algorithm: 1 octet specifying the SR Algorithm as described in
Section 3.1.1 of [RFC8402] when the A-Flag as defined in
Section 2.10 is set. The SR Algorithm is used by the SRPM
[RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag
is not set, this field MUST be set to zero on transmission and
MUST be ignored on receipt.
IPv6 Node Address: A 16-octet IPv6 address representing the node.
SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY be
used when the controller wants to indicate the desired SRv6
Endpoint Behavior or SID Structure without specifying the SID.
SRv6 Endpoint Behavior and SID Structure: Optional, as defined in
Section 2.4.4.2.4 of [RFC9830]. The SRv6 Endpoint Behavior or SID
Structure MUST NOT be included when the SRv6 SID has not been
included.
TLV 10 defined for the advertisement of Segment Type I in the early
draft versions of [RFC9830] has been deprecated to avoid backward-
compatibility issues.
2.8. Segment Type J
The Type J Segment sub-TLV encodes an IPv6 link-local adjacency with
a local node address, a local interface identifier (Local Interface
ID), a remote IPv6 node address, a remote interface identifier
(Remote Interface ID), and an optional SRv6 SID. The format is 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 | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Type J Segment Sub-TLV
Where:
Type: 15
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be one
of the following:
* 66 when both SRv6 SID and SRv6 Endpoint Behavior and SID
Structure are present,
* 58 when only SRv6 SID is present, or
* 42 when the SRv6 SID is not present.
Flags: 1 octet of flags as defined in Section 2.10.
SR Algorithm: 1 octet specifying the SR Algorithm as described in
Section 3.1.1 of [RFC8402] when the A-Flag as defined in
Section 2.10 is set. The SR Algorithm is used by the SRPM
[RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag
is not set, this field MUST be set to zero on transmission and
MUST be ignored on receipt.
Local Interface ID: 4 octets of interface index of local interface
(refer to TLV 258 of [RFC9552]).
IPv6 Local Node Address: A 16-octet IPv6 address representing the
node.
Remote Interface ID: 4 octets of interface index of remote interface
(refer to TLV 258 of [RFC9552]). The value MAY be set to zero
when the local node address and interface identifiers are
sufficient to describe the link.
IPv6 Remote Node Address: A 16-octet IPv6 address. The value MAY be
set to zero when the local node address and interface identifiers
are sufficient to describe the link.
SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY be
used when the controller wants to indicate the desired SRv6
Endpoint Behavior or SID Structure without specifying the SID.
SRv6 Endpoint Behavior and SID Structure: Optional, as defined in
Section 2.4.4.2.4 of [RFC9830]. The SRv6 Endpoint Behavior and
SID Structure MUST NOT be included when the SRv6 SID has not been
included.
TLV 11 defined for the advertisement of Segment Type J in the early
draft versions of [RFC9830] has been deprecated to avoid backward-
compatibility issues.
2.9. Segment Type K
The Type K Segment sub-TLV encodes an adjacency local address, an
adjacency remote address, and an optional SRv6 SID. The format is 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 | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Type K Segment Sub-TLV
Where:
Type: 16
Length: Specifies the length of the value field (i.e., not including
Type and Length fields) in terms of octets. The value MUST be one
of the following:
* 58 when both SRv6 SID and SRv6 Endpoint Behavior and SID
Structure are present,
* 50 when only SRv6 SID is present, or
* 34 when the SRv6 SID is not present.
Flags: 1 octet of flags as defined in Section 2.10.
SR Algorithm: 1 octet specifying the SR Algorithm as described in
Section 3.1.1 of [RFC8402] when the A-Flag as defined in
Section 2.10 is set. The SR Algorithm is used by the SRPM
[RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag
is not set, this field MUST be set to zero on transmission and
MUST be ignored on receipt.
Local IPv6 Address: A 16-octet IPv6 address representing the local
link address of the node.
Remote IPv6 Address: A 16-octet IPv6 address representing the link
address of the neighbor node.
SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY be
used when the controller wants to indicate the desired SRv6
Endpoint Behavior or SID Structure without specifying the SID.
SRv6 Endpoint Behavior and SID Structure: Optional, as defined in
Section 2.4.4.2.4 of [RFC9830]. The SRv6 Endpoint Behavior and
SID Structure MUST NOT be included when the SRv6 SID has not been
included.
TLV 12 defined for the advertisement of Segment Type K in the early
draft versions of [RFC9830] has been deprecated to avoid backward-
compatibility issues.
2.10. SR Policy Segment Flags
The Segment Type sub-TLVs described above may contain the following
SR Policy Segment Flags [RFC9830] in their Flags field (see also
Section 3.2). This document introduces additional flags below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|A|S|B| |
+-+-+-+-+-+-+-+-+
Figure 10: SR Policy Segment Flags
Where:
V-Flag: This is an existing flag as defined in [RFC9830].
A-Flag: When set, this flag indicates the presence of the SR
Algorithm id in the SR Algorithm field applicable to various
Segment Types. The SR Algorithm is used by the SRPM [RFC9830] as
described in Section 4 of [RFC9256].
S-Flag: When set, this flag indicates the presence of the SR-MPLS or
SRv6 SID depending on the segment type.
B-Flag: This is an existing flag as defined in [RFC9830].
The following applies to the Segment Flags:
* The V-Flag applies to all Segment Types including those introduced
by this document.
* The A-Flag applies to Segment Types C, D, I, J, and K. The value
of the A-Flag MUST be ignored for Segment Types A, B, E, F, G, and
H.
* The S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K.
The value of the S-Flag MUST be ignored for Segment Types A and B.
* The B-Flag applies to Segment Types B, I, J, and K. The value of
the B-Flag MUST be ignored for Segment Types A, C, D, E, F, G, and
H.
3. IANA Considerations
3.1. SR Policy Segment List Sub-TLVs
IANA has allocated the following code points from the "SR Policy
Segment List Sub-TLVs" registry [RFC9830] under the "Border Gateway
Protocol (BGP) Tunnel Encapsulation" registry group.
+=======+========================+===========+
| Value | Description | Reference |
+=======+========================+===========+
| 3 | Type C Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 4 | Type D Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 5 | Type E Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 6 | Type F Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 7 | Type G Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 8 | Type H Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 14 | Type I Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 15 | Type J Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
| 16 | Type K Segment sub-TLV | RFC 9831 |
+-------+------------------------+-----------+
Table 1: SR Policy Segment List Code Points
3.2. SR Policy Segment Flags
IANA has allocated code points from the "SR Policy Segment Flags"
registry [RFC9830] under the "Border Gateway Protocol (BGP) Tunnel
Encapsulation" registry group.
+=====+=============================+===========+
| Bit | Description | Reference |
+=====+=============================+===========+
| 1 | SR Algorithm Flag (A-Flag) | RFC 9831 |
+-----+-----------------------------+-----------+
| 2 | SID Specified Flag (S-Flag) | RFC 9831 |
+-----+-----------------------------+-----------+
Table 2: SR Policy Segment Flags
4. Security Considerations
The security considerations in [RFC9830] apply to the Segment Types
defined in this document. No additional security considerations are
introduced.
5. Manageability Considerations
The operations and manageability considerations in [RFC9830] apply to
the Segment Types defined in this document. No additional operations
and manageability considerations are introduced.
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., and D. Jain, "Advertising Segment Routing Policies in
BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
<https://www.rfc-editor.org/info/rfc9830>.
Acknowledgments
The authors would like to Dan Romascanu, Stig Venaas, and Russ
Housley for their comments and review. The authors would like to
thank Susan Hares for her detailed shepherd review that helped in
improving the document.
Authors' Addresses
Ketan Talaulikar (editor)
Cisco Systems
India
Email: ketant.ietf@gmail.com
Clarence Filsfils
Cisco Systems
Brussels
Belgium
Email: cfilsfil@cisco.com
Stefano Previdi
Huawei Technologies
Italy
Email: stefano@previdi.net
Paul Mattes
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Email: pamattes@microsoft.com
Dhanendra Jain
Google
Email: dhanendra.ietf@gmail.com
ISO Plain Language
On this page
§1Introduction
The BGP Segment Routing Policy Subsequent Address Family Identifier was introduced by RFC 9830 for the advertisement of SR Policies (RFC 8402). RFC 9830 introduced the base SR Segment Types A and B, as specified by the SR Policy Architecture (RFC 9256).
This document specifies the extensions for the advertisement of the remaining SR Segment Types defined in RFC 9256 in the SR Policy SAFI, for both SR-MPLS (see RFC 8660) and Segment Routing over IPv6 (SRv6) (see RFC 8754 and RFC 8986).
The extensions do not impact the SR Policy operations or fault management as specified in RFC 9830. Validation of an explicit path encoded by the Segment List sub-TLV is beyond the scope of BGP and is performed by the Segment Routing Policy Module as described in RFC 9830. As specified in the architecture, a mix of SR-MPLS and SRv6 segments makes the segment list invalid.
Segment Routing lets a controller list the exact steps a packet should take through the network. This RFC finishes the job of letting BGP carry that list, by defining how to encode the remaining kinds of step, such as a node address, a specific interface, or a particular link between two routers.
§2The Segment Types
The Segment List sub-TLV of RFC 9830 encodes a single explicit path towards the endpoint. It includes the elements of the path, that is, the segments. A Segment sub-TLV describes a single segment in a segment list, that is, a single element of the explicit path.
Section 4 of RFC 9256 defines several Segment Types for SR-MPLS and SRv6:
- Type A: SR-MPLS Label
- Type B: SRv6 SID
- Type C: IPv4 Prefix with optional SR Algorithm
- Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS
- Type E: IPv4 Prefix with Local Interface ID
- Type F: IPv4 Addresses for link endpoints as Local, Remote pair
- Type G: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS
- Type H: IPv6 Addresses for link endpoints as Local, Remote pair for SR-MPLS
- Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6
- Type J: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6
- Type K: IPv6 Addresses for link endpoints as Local, Remote pair for SRv6
RFC 9830 specifies the Segment Type Sub-TLVs for Types A and B. This document specifies the sub-TLVs for each of the others. The nine new types fall into three groups. Types C, D and I name a node by its address, optionally with an SR Algorithm and a segment identifier. Types E, G and J name a node by its address together with a local interface identifier, which pins the step to one of the node's interfaces. Types F, H and K name a link by giving the local and remote addresses at its two ends.
There are eleven kinds of step. Two were already defined: a plain MPLS label and an SRv6 identifier. The other nine are added here, in three families: steps that name a router, steps that name a router and one of its interfaces, and steps that name the link between two routers.
§2.1Encoding a Segment That Names a Node
Every Segment Type sub-TLV starts the same way. The first octet is the Type, and the second is the Length, which specifies the length of the value field, not including the Type and Length fields, in octets. The third octet is a Flags field, and the fourth is either an SR Algorithm or a reserved octet.
The Type C sub-TLV has Type 3 and encodes an IPv4 node address, an SR Algorithm and an optional SR-MPLS Segment Identifier. The Length MUST be 10 when the SR-MPLS SID is present and 6 otherwise. The IPv4 Node Address is a 4-octet address representing a node. The optional SR-MPLS SID is a 4-octet field containing a label, Traffic Class, bottom-of-stack and TTL, as defined for Segment Type A.
The Type D sub-TLV has Type 4 and does the same for IPv6. The Length MUST be 22 when the SR-MPLS SID is present and 18 otherwise, and the IPv6 Node Address is 16 octets.
The Type I sub-TLV has Type 14 and encodes an IPv6 node address, an SR Algorithm and an optional SRv6 SID. The Length MUST be 42 when both the SRv6 SID and the SRv6 Endpoint Behavior and SID Structure are present, 34 when only the SRv6 SID is present, or 18 when the SRv6 SID is not present. The SRv6 SID is a 16-octet address, and the value 0 MAY be used when the controller wants to indicate the desired SRv6 Endpoint Behavior or SID Structure without specifying the SID. The SRv6 Endpoint Behavior or SID Structure MUST NOT be included when the SRv6 SID has not been included.
The SR Algorithm field is 1 octet and carries the SR Algorithm as described in the Segment Routing Architecture when the A-Flag is set. When the A-Flag is not set, the field MUST be set to zero on transmission and MUST be ignored on receipt.
Each sub-TLV starts with a type number and a length, then a flags byte and either an algorithm number or a reserved byte. After that come the addresses that identify the step, and optionally a label or an SRv6 identifier that says how the traffic should be carried there.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 1 byte | 3 | 3 for a Type C segment, which names an IPv4 node. |
LENGTH | Length | 1 byte | 10 | Length of the value field in octets, not counting the Type and Length fields. It is 10 with the SR-MPLS SID and 6 without. |
FLAGS | Flags | 1 byte | One octet of segment flags: V, A, S and B in the top four bits. | |
SR-ALGORITHM | SR Algorithm | 1 byte | The algorithm to use, meaningful only when the A-Flag is set. | |
IPV4-NODE | IPv4 Node Address | 4 bytes | A 4-octet address representing a node. | |
SR-MPLS-SID | SR-MPLS SID | 4 bytes | Optional: a label, Traffic Class, bottom-of-stack and TTL, as for Segment Type A. |
§2.3Segments That Name an Interface or a Link
The Type E sub-TLV has Type 5 and encodes an IPv4 node address, a local interface identifier and an optional SR-MPLS SID. The Length MUST be 14 when the SR-MPLS SID is present and 10 otherwise. The fourth octet is RESERVED, which MUST be set to zero on transmission and MUST be ignored on receipt. The Local Interface ID is 4 octets carrying the interface index of the local interface, referring to TLV 258 of RFC 9552.
The Type F sub-TLV has Type 6 and encodes an adjacency local address, an adjacency remote address and an optional SR-MPLS SID. The Length MUST be 14 when the SID is present and 10 otherwise. The Local IPv4 Address is the local link address of the node, and the Remote IPv4 Address is the link address of the neighbour node.
The Type G sub-TLV has Type 7 and encodes an IPv6 link-local adjacency for SR-MPLS, with an IPv6 local node address, a local interface identifier, an IPv6 remote node address, a remote interface identifier and an optional SR-MPLS SID. The Length MUST be 46 when the SID is present and 42 otherwise. The Remote Interface ID MAY be set to zero, and the IPv6 Remote Node Address MAY be set to zero, when the local node address and the interface identifiers are sufficient to describe the link.
The Type H sub-TLV has Type 8 and encodes an adjacency local address, an adjacency remote address and an optional SR-MPLS SID, this time with 16-octet IPv6 addresses. The Length MUST be 38 when the SID is present and 34 otherwise.
The Type J sub-TLV has Type 15 and encodes an IPv6 link-local adjacency for SRv6, with a local node address, a local interface identifier, a remote IPv6 node address, a remote interface identifier, an optional SRv6 SID and optionally the SRv6 Endpoint Behavior and SID Structure. The Length MUST be 66 when both the SID and the endpoint behavior are present, 58 when only the SID is present, or 42 when the SID is not present.
The Type K sub-TLV has Type 16 and encodes an adjacency local address, an adjacency remote address, an optional SRv6 SID and optionally the SRv6 Endpoint Behavior and SID Structure. The Length MUST be 58 when both are present, 50 when only the SID is present, or 34 when the SID is not present.
Three earlier TLV numbers, 10, 11 and 12, had been defined for the advertisement of Segment Types I, J and K in the early drafts of RFC 9830, and have been deprecated to avoid backward compatibility issues.
Some steps need more than an address. Types E, G and J add the index number of the interface on the router, so the step means that particular port rather than the router as a whole. Types F, H and K go further and name the link itself by giving the addresses at both of its ends.
- 3Type C — IPv4 node address, with optional SR Algorithm and SR-MPLS SID.
- 4Type D — IPv6 node address, with optional SR Algorithm and SR-MPLS SID.
- 5Type E — IPv4 node address and local interface ID, with optional SR-MPLS SID.
- 6Type F — IPv4 local and remote addresses for a link, with optional SR-MPLS SID.
- 7Type G — IPv6 local and remote node addresses with interface IDs, for SR-MPLS.
- 8Type H — IPv6 local and remote addresses for a link, for SR-MPLS.
- 14Type I — IPv6 node address, with optional SR Algorithm and SRv6 SID.
- 15Type J — IPv6 local and remote node addresses with interface IDs, for SRv6.
- 16Type K — IPv6 local and remote addresses for a link, for SRv6.
§2.10The Segment Flags
The Segment Type sub-TLVs may contain the SR Policy Segment Flags of RFC 9830 in their Flags field, and this document introduces additional flags. The Flags octet holds four flags in its top bits, in the order V, A, S and B, with the remaining bits unused.
- The V-Flag is an existing flag defined in RFC 9830.
- The A-Flag, when set, indicates the presence of the SR Algorithm identifier in the SR Algorithm field. The SR Algorithm is used by the Segment Routing Policy Module as described in the architecture.
- The S-Flag, when set, indicates the presence of the SR-MPLS or SRv6 SID, depending on the segment type.
- The B-Flag is an existing flag defined in RFC 9830.
The rules for which flag applies where are explicit. The V-Flag applies to all Segment Types, including those introduced by this document. The A-Flag applies to Segment Types C, D, I, J and K, and its value MUST be ignored for Types A, B, E, F, G and H. The S-Flag applies to Segment Types C, D, E, F, G, H, I, J and K, and its value MUST be ignored for Types A and B. The B-Flag applies to Segment Types B, I, J and K, and its value MUST be ignored for Types A, C, D, E, F, G and H.
The flags byte tells the receiver which optional fields are really there. Two new flags are added here: one says the algorithm number is meaningful, the other says a label or identifier is present. Each flag is only meaningful for certain segment types, and receivers are told to ignore the others.
- V-FlagExisting flag from RFC 9830. It applies to every segment type.
- A-FlagSays the SR Algorithm field is meaningful. It applies to types C, D, I, J and K.
- S-FlagSays an SR-MPLS or SRv6 SID is present. It applies to types C through K.
- B-FlagExisting flag from RFC 9830. It applies to types B, I, J and K.
§3IANA and Security Considerations
IANA has allocated code points from the SR Policy Segment List Sub-TLVs registry of RFC 9830, under the Border Gateway Protocol Tunnel Encapsulation registry group: value 3 for the Type C Segment sub-TLV, 4 for Type D, 5 for Type E, 6 for Type F, 7 for Type G, 8 for Type H, 14 for Type I, 15 for Type J and 16 for Type K.
IANA has also allocated code points from the SR Policy Segment Flags registry: bit 1 for the SR Algorithm Flag, the A-Flag, and bit 2 for the SID Specified Flag, the S-Flag.
The security considerations of RFC 9830 apply to the Segment Types defined in this document, and no additional security considerations are introduced. The operations and manageability considerations of RFC 9830 likewise apply, and no additional ones are introduced.
The document registers the new sub-TLV numbers and the two new flag bits, and it adds nothing to the security or management rules that already apply to SR Policy in BGP.