Segment Type Extensions for BGP Segment Routing (SR) Policy Cisco Systems
India ketant.ietf@gmail.com
Cisco Systems
Brussels Belgium cfilsfil@cisco.com
Huawei Technologies
Italy stefano@previdi.net
Microsoft
One Microsoft Way Redmond WA 98052 United States of America pamattes@microsoft.com
Google
dhanendra.ietf@gmail.com
RTG idr 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 .
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 () 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
  • .  Introduction
    • .  Requirements Language
  • .  Segment Type Sub-TLVs
    • .  Segment Type C
    • .  Segment Type D
    • .  Segment Type E
    • .  Segment Type F
    • .  Segment Type G
    • .  Segment Type H
    • .  Segment Type I
    • .  Segment Type J
    • .  Segment Type K
    • . SR Policy Segment Flags
  • .  IANA Considerations
    • .  SR Policy Segment List Sub-TLVs
    • .  SR Policy Segment Flags
  • .  Security Considerations
  • .  Manageability Considerations
  • .  Normative References
  • Acknowledgments
  • Authors' Addresses
Introduction The BGP Segment Routing (SR) Policy Subsequent Address Family Identifier (SAFI) was introduced by for the advertisement of SR Policies . introduced the base SR Segment Types A and B as specified by the SR Policy Architecture . This document specifies the extensions for the advertisement of the remaining SR Segment Types defined in in the SR Policy SAFI for both SR-MPLS (see ) and Segment Routing over IPv6 (SRv6) (see and ). The extensions in this document do not impact the SR Policy operations or fault management as specified in .
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 when, and only when, they appear in all capitals, as shown here.
Segment Type Sub-TLVs The Segment List sub-TLV encodes a single explicit path towards the endpoint as described in . 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). 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
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 and of , 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 . As specified in , a mix of SR-MPLS and SRv6 segments make the segment-list invalid.
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:
Type C Segment Sub-TLV 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
SR Algorithm:
1 octet specifying the SR Algorithm as described in when the A-Flag as defined in is set. The SR Algorithm is used by the SRPM as described in . 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 .
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:
Type D Segment Sub-TLV 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
SR Algorithm:
1 octet specifying the SR Algorithm as described in when the A-Flag as defined in is set. The SR Algorithm is used by the SRPM as described in . 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 .
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:
Type E Segment Sub-TLV 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
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 ).
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 .
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:
Type F Segment Sub-TLV 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
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 .
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:
Type G Segment Sub-TLV 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
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 ).
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 ). 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 .
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:
Type H Segment Sub-TLV 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
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 .
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:
Type I Segment Sub-TLV 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) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
SR Algorithm:
1 octet specifying the SR Algorithm as described in when the A-Flag as defined in is set. The SR Algorithm is used by the SRPM as described in . 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 . 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 has been deprecated to avoid backward-compatibility issues.
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:
Type J Segment Sub-TLV 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) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
SR Algorithm:
1 octet specifying the SR Algorithm as described in when the A-Flag as defined in is set. The SR Algorithm is used by the SRPM as described in . 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 ).
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 ). 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 . 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 has been deprecated to avoid backward-compatibility issues.
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:
Type K Segment Sub-TLV 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) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
SR Algorithm:
1 octet specifying the SR Algorithm as described in when the A-Flag as defined in is set. The SR Algorithm is used by the SRPM as described in . 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 . 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 has been deprecated to avoid backward-compatibility issues.
SR Policy Segment Flags The Segment Type sub-TLVs described above may contain the following SR Policy Segment Flags in their Flags field (see also ). This document introduces additional flags below:
SR Policy Segment Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|A|S|B| | +-+-+-+-+-+-+-+-+
Where:
V-Flag:
This is an existing flag as defined in .
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 as described in .
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 .
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.
IANA Considerations
SR Policy Segment List Sub-TLVs IANA has allocated the following code points from the "SR Policy Segment List Sub-TLVs" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. SR Policy Segment List Code Points
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
SR Policy Segment Flags IANA has allocated code points from the "SR Policy Segment Flags" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. SR Policy Segment Flags
Bit Description Reference
1 SR Algorithm Flag (A-Flag) RFC 9831
2 SID Specified Flag (S-Flag) RFC 9831
Security Considerations The security considerations in apply to the Segment Types defined in this document. No additional security considerations are introduced.
Manageability Considerations The operations and manageability considerations in apply to the Segment Types defined in this document. No additional operations and manageability considerations are introduced.
Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing with the MPLS Data Plane Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). IPv6 Segment Routing Header (SRH) Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Segment Routing Policy Architecture Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Distribution of Link-State and Traffic Engineering Information Using BGP In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. Advertising Segment Routing Policies in BGP Huawei Technologies Cisco Systems Cisco Systems Microsoft Google
Acknowledgments The authors would like to , , and for their comments and review. The authors would like to thank for her detailed shepherd review that helped in improving the document.
Authors' Addresses Cisco Systems
India ketant.ietf@gmail.com
Cisco Systems
Brussels Belgium cfilsfil@cisco.com
Huawei Technologies
Italy stefano@previdi.net
Microsoft
One Microsoft Way Redmond WA 98052 United States of America pamattes@microsoft.com
Google
dhanendra.ietf@gmail.com