RFC 9831: Segment Type Extensions for BGP Segment Routing (SR) Policy
- K. Talaulikar, Ed.,
- C. Filsfils,
- S. Previdi,
- P. Mattes,
- D. Jain
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://
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://
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
- 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
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:¶
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:¶
- 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
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:¶
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:¶
- 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
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:¶
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:¶
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.¶
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.¶
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 , , <https:///RFC2119 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 , , <https:///RFC8174 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 , , <https:///RFC8402 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 , , <https:///RFC8660 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 , , <https:///RFC8754 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 , , <https:///RFC8986 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 , , <https:///RFC9256 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 , , <https:///RFC9552 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 , , <https:///RFC9830 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.¶