| Internet-Draft | BGP-SPF SRv6 | July 2025 |
| Zhang, et al. | Expires 8 January 2026 | [Page] |
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing 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 SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI.¶
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 8 January 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.¶
[I-D.ietf-lsvr-bgp-spf] extends BGP for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol [RFC4271] and BGP-LS protocol extensions [RFC9552], with the extensions to BGP-LS attribute and new NLRI selection rules.¶
Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". SRv6 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 SRv6 domain.¶
In network scenarios such as Data Center networks, WAN networks or other networks where BGP-LS-SPF can be used as the underlay routing protocol, it may be useful to enable SRv6 based source routing mechanism for traffic engineering and optimization. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI, and discusses which SRv6 extensions can be applied to BGP-LS-SPF SAFI.¶
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.¶
Based on [RFC9514], the following SRv6 Node Attributes TLV SHOULD be supported in BGP-LS-SPF.¶
| Type | Description | Reference |
|---|---|---|
| 1138 | SRv6 Capabilities TLV | RFC 9514 |
| 266 | Node MSD TLV | RFC 8814 |
| 1035 | SR Algorithm TLV | RFC 9085 |
These SRv6 Node Attributes TLVs are advertised associated with the BGP-LS-SPF Node NLRI.¶
The SRv6 Capabilities TLV defined in [RFC9514] is used to announce the SRv6 capabilities of the node along with the BGP-LS Node NLRI and indicates the SRv6 support by the node.¶
For BGP-LS-SPF, it SHOULD support this TLV for a BGP-LS-SPF node to advertise its support for the SRv6-related capabilities. This is an optional TLV of BGP-LS-SPF Node NLRI that MUST be advertised by an SRv6-capable node.¶
This TLV MUST be advertised only once in the attributes of BGP-LS-SPF Node NLRI. When multiple SRv6 Capabilities TLVs are received from a given node, the receiver MUST use the first occurrence of the TLV in the attributes of BGP-LS-SPF Node NLRI.¶
If no SRv6 Capabilities TLV is advertised in the BGP-LS-SPF Node NLRI, then it indicates that the originator of this NLRI does not support SRv6.¶
The format and flags of SRv6 Capabilities TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of BGP-LS-SPF SRv6 Capability TLV is shown as follow:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1038¶
Length: 4¶
Flags: 2-octet field. the following flags are defined:¶
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
where:¶
O-flag: If set, the node supports use of the O-bit in the SRH, as defined in [RFC9259].¶
Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.¶
Reserved: 2-octet field that MUST be set to 0 when originated and ignored on receipt.¶
The Node MSD TLV defined in [RFC8814] is used to advertise the limits and the Segment Routing Header (SRH) operations supported by the SRv6-capable node in BGP-LS.¶
For BGP-LS-SPF, different SRv6-capable node may have different limits related to SRH processing, therefore, BGP-LS-SPF SHOULD support this TLV for nodes to advertise the limits and operations.¶
The SRv6 Node MSD TLV is an optional TLV of BGP-LS-SPF Node Attribute in BGP-LS-SPF NLRI that MAY be advertised by an SRv6-capable node.¶
This TLV MUST be advertised only once in the attributes of BGP-LS-SPF Node NLRI. When multiple SRv6 Node MSD TLVs are received from a given node, the receiver MUST use the first occurrence of the TLV in the attributes of BGP-LS-SPF Node NLRI.¶
The MSD types for SRv6 that are defined in Section 4 of [RFC9352] for IS-IS are also used by BGP-LS-SPF. These MSD types are allocated in the "IGP MSD-Types" registry maintained by IANA and are shared by IS-IS, OSPF, and BGP-LS-SPF. They are described in the subsections below.¶
The format of this TLV is the same as that in BGP-LS:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 266.¶
Length: variable, represents the total length of the value field in octets.¶
Value: consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value. The detail description of MSD-Type and MSD-Value is in Section 3 of [RFC8814].¶
Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use by the advertising BGP-LS-SPF instance. MSD values may be learned via a hardware API or may be provisioned.¶
If there are multiple MSD-Types that have the same code point in a Node MSD TLV, then the Node MSD TLV MUST be ignored by the receiver.¶
The Maximum Segments Left MSD Type signals the maximum value of the Segments Left field in the SRH of a received packet before applying the Endpoint behavior associated with a SID.¶
If no value is advertised, the supported value is assumed to be 0.¶
The Maximum End Pop MSD Type signals the maximum number of SIDs in the SRH to which the node can apply "Penultimate Segment Pop (PSP) of the SRH" or "Ultimate Segment Pop (USP) of the SRH" behaviors, which defined in Section 4.16 of [RFC8986].¶
If the advertised value is zero or no value is advertised, then the node cannot apply the PSP or USP flavors.¶
The Maximum H.Encaps MSD Type signals the maximum number of SIDs that can be added as part of the H.Encaps behavior as defined in [RFC8986].¶
If the advertised value is zero or no value is advertised, then the headend can apply an SR Policy that only contains one segment without inserting any SRH.¶
A non-zero SRH Max H.Encaps MSD indicates that the headend can insert an SRH with SIDs up to the advertised value.¶
The Maximum End D MSD Type specifies the maximum number of SIDs present in an SRH when performing decapsulation. These include, but are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and End.X with USD as defined in [RFC8986].¶
If the advertised value is zero or no value is advertised, then the node cannot apply any behavior that results in decapsulation and forwarding of the inner packet when the outer IPv6 header contains an SRH.¶
[RFC9514] specifies that the algorithm support for SRv6 is advertised via the SR-Algorithm TLV specified in [RFC9085]. The SR-Algorithm is used to advertise the SR algorithms supported by the node.¶
This TLV is a basic TLV of SR and SHOULD be supported in BGP-LS-SPF. The SR-Algorithm TLV is an optional TLV of BGP-LS-SPF Node Attribute in BGP-LS-SPF NLRI that MAY be advertised by an SRv6-capable node.¶
This TLV MUST be advertised only once in the attributes of BGP-LS-SPF Node NLRI. If a node receiving multiple SR-Algorithm TLVs in the BGP-LS-SPF Node NLRI, the receiver MUST use the first occurrence of the TLV in the attributes of BGP-LS-SPF Node NLRI.¶
If a SRv6-capable node does not advertise the SR-Algorithm TLV, it implies that algorithm 0 is the only algorithm supported by the node.¶
If the originating node does advertise the SR-Algorithm sub-TLV, then algorithm 0 MUST be present while non-zero algorithms MAY be present.¶
The format of Algorithm fields in this TLV is consistent with that in BGP-LS, as defined in Section 2.1.3 of [RFC9085].¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1035¶
Length: Variable¶
Algorithm: 1 octet of algorithm.¶
The algorithm values are allocated in the "IGP Algorithm Type" registry defined in [RFC8665], these values are shared by IS-IS, OSPF, and BGP-LS-SPF.¶
Based on [RFC9514] and [RFC9085], the following Link Attributes SHOULD be supported in BGP-LS-SPF.¶
| Type | Description | Reference |
|---|---|---|
| 1106 | SRv6 End.X SID TLV | RFC 9514 |
| 1106 | L2 Bundle Member Attributes TLV | RFC 9085 |
| 267 | SRv6 Link MSD TLV | RFC 8814 |
These SRv6 Link Attribute TLVs are advertised associated with the BGP-LS-SPF Link NLRI.¶
The SRv6 End.X SID TLV defined in [RFC9514] is used to advertise the SRv6 SIDs associated with an IGP Adjacency SID behavior that correspond to a point-to-point or point-to-multipoint link or adjacency of the node running the IS-IS or OSPFv3 protocols. It is also used by BGP-LS to advertise the BGP EPE Peer Adjacency SID for SRv6 on the same lines as specified for SR-MPLS in [RFC9086].¶
BGP-LS-SPF SHOULD support this TLV to advertise the SRv6 SIDs correspond to a point-to-point or adjacency of the node running the BGP-LS-SPF.¶
The SRv6 End.X SID TLV is an optional TLV of BGP-LS-SPF Link Attribute in BGP-LS-SPF Link NLRI that MAY be advertised by an SRv6-capable node.¶
More than one instance of this TLV (one for each SRv6 End.X SID) can be included in the BGP-LS-SPF Attribute. Multiple SRv6 End.X SID TLVs MAY be associated with the same adjacency.¶
Every SRv6-enabled node SHOULD instantiate at least one unique SRv6 End.X SID corresponding to each of its neighbors, although it MAY omit doing so if features like TE or TI-LFA that require End.X SID are not in use.¶
All End.X SIDs MUST be a subnet of a locator with matching algorithm that is advertised by the same BGP-LS-SPF node in an SRv6 Locator TLV. End.X SIDs that do not meet this requirement MUST be ignored. This ensures that the BGP-LS-SPF node advertising the End.X is also advertising its corresponding locator with the algorithm that will be used for computing paths destined to the SID.¶
The format of this TLV is the same as in BGP-LS:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Behavior | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight | Reserved | SID (16 octets) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | Sub-TLVs (variable) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1106¶
Length: variable¶
Endpoint Behavior: 2-octet field. The Endpoint behavior code point for this SRv6 SID as defined in Section 10.2 of [RFC8986].¶
Flags: 1 octet. The definition of flags are same as that in IS-IS SRv6 End.X SID sub-TLV (Section 8.1 of [RFC9352]) and the OSPFv3 SRv6 End.X SID sub-TLV (Section 9.1 of [RFC9513]).¶
Algorithm: 1-octet field. Algorithm associated with the SID. The algorithm associated with the SRv6 Locator from which the SID is allocated.¶
Weight: 1-octet field. The value represents the weight of the SID for the purpose of load balancing. The use of the weight is defined in [RFC8402].¶
Reserved: 1-octet field that MUST be set to 0 when originated and ignored on receipt.¶
SID: 16-octet field. This field encodes the advertised SRv6 SID as a 128-bit value.¶
Sub-TLVs: Used to advertise sub-TLVs that provide additional attributes for the specific SRv6 SID.¶
The L2 Bundle Member Attributes TLV is defined in [RFC9085], it identifies an L2 Bundle Member link, which in turn is associated with a parent L3 link. This TLV is useful when entities external to BGP-LS-SPF wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle.¶
The network deployed BGP-LS-SPF may include trunk links. Therefore, BGP-LS-SPF MAY support this TLV to advertise L2 bundle member link attributes.¶
The L2 Bundle Member Attributes TLV is an optional TLV of BGP-LS-SPF Link Attribute with BGP-LS-SPF Link NLRI that MAY be advertised by an SRv6-capable node.¶
This TLV MAY include sub-TLVs that describe attributes associated with the bundle member. The identified bundle member represents a unidirectional path from the originating node to the neighbor specified in the parent L3 link.¶
Multiple L2 Bundle Member Attributes TLVs MAY be present in a single BGP-LS-SPF Link NLRI.¶
Advertisement of this TLV implies that the identified link is a member of the L2 Bundle associated with the Parent L3 Link, and the member link is operationally up. Therefore, advertisements MUST be withdrawn if the link becomes operationally down or it is no longer a member of the identified L2 Bundle.¶
The format of this TLV is the same as that in BGP-LS:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 Bundle Member Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Attribute Sub-TLVs(variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Type: 1172¶
Length: Variable.¶
L2 Bundle Member Descriptor: 4-octet field that carries a link-local identifier as defined in [RFC4202].¶
Link attribute Sub-TLVs: variable, the detail description of these Sub-TLVs is specified in Section 2.2.3 of [RFC9085].¶
The Link MSD TLV defined in [RFC8814] is used to advertise the limits and the SRH operations supported on the specific link by the SRv6-capable node. BGP-LS-SPF SHOULD support this TLV to advertise the limits and operations supported on the specific link to enable segment routing. The SRv6 MSD types specified in Section 4 of [RFC9352] are also used with the BGP-LS-SPF Link MSD TLV, as these code points are shared between the IS-IS, OSPF, and BGP-LS-SPF.¶
The SRv6 Node MSD TLV is an optional TLV of BGP-LS-SPF Link Attributes in BGP-LS-SPF Link NLRI that MAY be advertised by an SRv6-capable node.¶
This TLV MUST be advertised only once in the attributes of BGP-LS-SPF Link NLRI. When multiple SRv6 Link MSD TLVs are received from a given node, the receiver MUST use the first occurrence of the TLV in the attributes of BGP-LS-SPF Link NLRI.¶
The format and different MSD Types of SRv6 Link MSD TLV is the same as Section 2.2, the Type of Link MSD TLV is 267[RFC8814].¶
Based on [RFC9514], the BGP-LS SRv6 Prefix Attributes only includes the SRv6 Locator TLV. This TLV SHOULD be supported by BGP-LS-SPF.¶
| Type | Description | Reference |
|---|---|---|
| 1162 | SRv6 Locator TLV | RFC 9514 |
These SRv6 Prefix Attribute TLVs are advertised associated with the BGP-LS-SPF Prefix NLRI.¶
The SRv6 Locator TLV defined in [RFC9514] is used to advertise the locators supported by each node. Locator is the key component of SRv6 SID, BGP-LS-SPF SHOULD support this TLV to enable segment routing.¶
A node is provisioned with one or more locators supported by that node. Locators are covering prefixes for the set of SIDs provisioned on that node. Each locator is advertised as a BGP-LS-SPF Prefix NLRI object along with the SRv6 Locator TLV in its BGP-LS-SPF Attribute.¶
Multiple SRv6 Locator TLVs MAY be advertised in each BGP-LS-SPF Prefix NLRI. Each locator is advertised in a SRv6 Locator TLV.¶
When multiple SRv6 Locator TLVs are received from a given node in an BGP-LS-SPF prefix NLRI for the same locator, the receiver MUST use the first occurrence of the TLV in the NLRI.¶
The format of the SRv6 Locator TLV is the same as BGP-LSSection 5.1 of [RFC9514].¶
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 | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1162¶
Length: variable¶
Flags: 1 octet of flags. Currently, the flags field is not used and MUST be set to zero on transmission and MUST be ignored on receipt.¶
Algorithm: 1-octet field. Algorithm associated with the SID, as defined in the "IGP Algorithm Types" registry [RFC8665].¶
Reserved: 2-octet field. The value MUST be set to 0 when originated and ignored on receipt.¶
Metric: 4-octet field. The value of the metric for the locator.¶
Sub-TLVs: Used to advertise sub-TLVs that provide additional attributes for the given SRv6 Locator. Currently, none are defined.¶
Since BGP-LS-SPF defines the Prefix Metric TLV is mandatory for Prefix NLRI, so the Metric field in this TLV is no longer usable. It SHOULD be set to 0 and MUST be ignored on receipt.¶
The SRv6 SID NLRI defined in [RFC9514] is used to carry the SRv6 SID information. When SRv6 SIDs need to be advertised in BGP-SPF, the following NLRI type and attributes TLV for SRv6 SID SHOULD be supported in BGP-LS-SPF SAFI:¶
| Type | NLRI Type | Reference |
|---|---|---|
| 6 | SRv6 SID NLRI | RFC 9514 |
| 518 | SRv6 SID Information TLV | RFC 9514 |
| 1250 | SRv6 Endpoint Behavior TLV | RFC 9514 |
The format of SRv6 SID NLRI is the same as that in BGP-LSSection 6 of [RFC9514].¶
An SRv6-enabled node SHOULD advertise at least one SRv6 SID associated with an End behavior encapsulated in the SRv6 NLRI for itself as specified in [RFC8986].¶
An SRv6-enabled node MAY advertise multiple instances of the SRv6 SID NLRI -- one for each of the SRv6 SIDs to be advertised.¶
The SRv6 SID Information TLV is used to carry the SRv6 SID that do not require a particular neighbor in a SRv6 SID NLRI. This TLV SHOULD be supported in BGP-LS-SPF to advertise SRv6 SIDs of each node.¶
SRv6 SID Information TLV is a mandatory TLV in SRv6 NLRI. For each SRv6 SID NLRI, it MUST contain a single SRv6 SID Information TLV.¶
When multiple SRv6 SID Information TLVs are received from a given node in an BGP-LS-SPF SRv6 SID NLRI for the same SID, the receiver MUST use the first occurrence of the TLV in the NLRI.¶
The format of SRv6 SID Information TLV is the same as that in BGP-LSSection 6.1 of [RFC9514].¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 518¶
Length: 16¶
SID: 16-octet field. This field encodes the advertised SRv6 SID as a 128-bit value.¶
The SRv6 SID MUST be allocated from its associated locator. SRv6 SIDs that are NOT allocated from the associated locator MUST be ignored.¶
The Endpoint Behavior TLV defined in [RFC9514] is used to advertise the behaviors associated with a SID. The BGP-LS-SPF SHOULD support this TLV to enable the advertisement of behaviors associated with a SRv6 SID.¶
The SRv6 Endpoint Behavior TLV is a mandatory TLV that MUST be included once in the BGP-LS Attribute associated with the BGP-LS-SPF SRv6 SID NLRI.¶
When multiple SRv6 Endpoint Behavior TLVs are received from a given node in an BGP-LS-SPF SRv6 SID NLRI, the receiver MUST use the first occurrence of the TLV in the NLRI.¶
The format of SRv6 Endpoint is the same as that in BGP-LS.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Behavior | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Type: 1250¶
Length: 4¶
Endpoint Behavior: 2-octet field. The Endpoint behavior code point for this SRv6 SID.¶
Flags: 1 octet of flags. No flags are currently defined, and this field MUST be set to 0 on transmission and MUST be ignored on receipt.¶
Algorithm: 1-octet field. Algorithm associated with the SID.¶
Supported behavior values for this TLV are defined in Section 7 of this document. Unsupported or unrecognized behavior values are ignored by the receiver.¶
The SRv6 SID Structure TLV defined in [RFC9514] is used to advertise the length of each individual part of the SRv6 SID as defined in [RFC8986]. BGP-LS-SPF MAY support this TLV to indicate the length of each individual part of the SRv6 SID of BGP-LS-SPF, which is useful in some scenarios using compressed SID.¶
It is an optional TLV that MAY be use in the BGP-LS-SPF SRv6 SID NLRI and SRv6 End.X SID TLV.¶
The SRv6 SID Structure TLV MUST NOT appear more than once in its parent TLV or NLRI. If it appears more than once in its parent TLV or NLRI, the parent TLV or NLRI MUST be ignored by the receiver.¶
The format of SRv6 Structure TLV is the same as that in BGP-LS.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LB Length | LN Length | Fun. Length | Arg. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Type: 1252¶
Length: 4¶
LB Length: 1-octet field. SRv6 SID Locator Block length in bits.¶
LN Length: 1-octet field. SRv6 SID Locator Node length in bits.¶
Fun. Length: 1-octet field. SRv6 SID Function length in bits.¶
Arg. Length: 1-octet field. SRv6 SID Argument length in bits.¶
The sum of all four sizes advertised in SRv6 SID Structure TLV MUST be less than or equal to 128 bits. If the sum of all four sizes advertised in the SRv6 SID Structure sub-TLV is larger than 128 bits, the parent TLV or NLRI MUST be ignored by the receiver.¶
The SRv6 SID Structure sub-TLV is intended for informational use by the control and management planes. It MUST NOT be used at a transit node (as defined in [RFC8754]) for forwarding packets. The typical use cases for this information are described in the Section 10 of [RFC9513] and Section 9 of [RFC9352].¶
Endpoint behaviors are defined in [RFC8986]. The code points for the Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry of [RFC8986]. This section lists the Endpoint behaviors and their code points, which MAY be advertised by BGP-LS-SPF and the TLVs in which each type MAY appear.¶
| Endpoint Behavior | Endpoint Behavior Code Point | Endpoint Behavoir | End.X SID |
|---|---|---|---|
| End(PSP, USP, USD) | 1-4, 28-31 | Y | N |
| End.X(PSP, USP, USD) | 5-8, 32-35 | N | Y |
This document introduces no additional security vulnerabilities in addition to the ones as described in [RFC9552].¶
This document has no IANA actions.¶
This document refers extensively to the content of [RFC9514], [RFC9513], [RFC9352], and [RFC9085]. The authors would like to thank the authors of these RFCs, they are James Uttaro, Hani Elmalky, Arjun Sreekantiah, Les Ginsberg, Shunwan Zhuang, Zhenbin Li, Zhibo Hu, Ketan Talaulikar, Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Stefano Previdi, Hannes Gredler, and Mach(Guoyi) Chen.¶
The authors also would like to thank Acee Lindem for his valuable comments and suggestions.¶