Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) LinkedIn
United States of America gdawra.ietf@gmail.com
Cisco Systems
Belgium cfilsfil@cisco.com
Cisco Systems
India ketant.ietf@gmail.com
Huawei
China mach.chen@huawei.com
Bell Canada
Canada daniel.bernier@bell.ca
Orange
France bruno.decraene@orange.com
rtg idr BGP BGP-LS Segment Routing SRv6 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". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3. This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085.
Status of This Memo This is an Internet Standards Track document. 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). Further information on Internet Standards is available in 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) 2023 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
  • .  BGP-LS Extensions for SRv6
  • .  SRv6 Node Attributes
    • .  SRv6 Capabilities TLV
    • .  SRv6 Node MSD Types
  • .  SRv6 Link Attributes
    • .  SRv6 End.X SID TLV
    • .  SRv6 LAN End.X SID TLV
    • .  SRv6 Link MSD Types
  • .  SRv6 Prefix Attributes
    • .  SRv6 Locator TLV
  • .  SRv6 SID NLRI
    • .  SRv6 SID Information TLV
  • .  SRv6 SID Attributes
    • .  SRv6 Endpoint Behavior TLV
    • .  SRv6 BGP PeerNode SID TLV
  • .  SRv6 SID Structure TLV
  • .  IANA Considerations
    • .  BGP-LS NLRI Types
    • .  BGP-LS NLRI and Attribute TLVs
    • .  SRv6 BGP EPE SID Flags
  • . Manageability Considerations
  • . Security Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • .  Differences with BGP-EPE for SR-MPLS
  • Acknowledgements
  • Contributors
  • Authors' Addresses
Introduction SRv6 refers to Segment Routing instantiated on the IPv6 data plane . An SRv6 segment is often referred to by its SRv6 Segment Identifier (SID). The network programming paradigm is central to SRv6. It describes how different behaviors can be bound to SIDs and how a network program can be expressed as a combination of SIDs. An SRv6-capable node maintains all the SRv6 segments explicitly instantiated locally. The IS-IS and OSPFv3 link-state routing protocols have been extended to advertise some of these SRv6 SIDs and SRv6-related information . Other SRv6 SIDs may be instantiated on a node via other mechanisms for topological or service functionalities. The advertisement of SR-related information along with the topology is specified in for the MPLS data plane instantiation (SR-MPLS) and in for BGP Egress Peer Engineering (EPE). On similar lines, introducing the SRv6-related information in BGP-LS allows consumer applications that require topological visibility to also receive the SRv6 SIDs from nodes across an IGP domain or even across Autonomous Systems (ASes) as required. This allows applications to leverage the SRv6 capabilities for network programming. The identifying key of each link-state object, namely a node, link, or prefix, is encoded in the Network Layer Reachability Information (NLRI), and the properties of the object are encoded in the BGP-LS Attribute . This document describes extensions to BGP-LS to advertise the SRv6 SIDs and other SRv6 information from all the SRv6-capable nodes in the IGP domain when sourced from link-state routing protocols and directly from individual SRv6-capable nodes (e.g., when sourced from BGP for EPE).
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.
BGP-LS Extensions for SRv6 BGP-LS defines the Node, Link, and Prefix Link-State NLRI types and the advertisement of their attributes via BGP. When a BGP-LS router advertises topology information that it sources from the underlying link-state routing protocol, it derives the corresponding SRv6 information from the SRv6 extensions for IS-IS or OSPFv3 as applicable. In practice, this derivation comprises a simple copy of the relevant fields from the IS-IS or OSPFv3 TLV/sub-TLV into the fields of the corresponding BGP-LS TLV/sub-TLV. When a BGP-LS router advertises topology information from the BGP routing protocol (e.g., for EPE) or advertises SRv6 SIDs associated with a node using Direct as the Protocol-ID, it derives the SRv6 information from the local node. Such information is advertised only on behalf of the local router, in contrast to the advertisement of information from all nodes of an IGP domain when sourced from a link-state routing protocol. The SRv6 information pertaining to a node is advertised via the BGP-LS Node NLRI using the BGP-LS Attribute TLVs as follows:
  • The SRv6 capabilities of the node are advertised via the SRv6 Capabilities TLV ().
  • Maximum SID Depth (MSD) types introduced for SRv6 are advertised () using the Node MSD TLV specified in .
  • Algorithm support for SRv6 is advertised via the SR-Algorithm TLV specified in .
The SRv6 information pertaining to a link is advertised via the BGP-LS Link NLRI using the BGP-LS Attribute TLVs as follows:
  • The SRv6 SID of the IGP Adjacency SID or the BGP EPE Peer Adjacency SID is advertised via the SRv6 End.X SID TLV introduced in this document ().
  • The SRv6 SID of the IGP Adjacency SID to a non-Designated Router (DR) or non-Designated Intermediate System (DIS) is advertised via the SRv6 LAN End.X SID TLV introduced in this document ().
  • MSD types introduced for SRv6 are advertised () using the Link MSD TLV specified in .
The SRv6 information pertaining to a prefix is advertised via the BGP-LS Prefix NLRI using the BGP-LS Attribute TLVs as follows:
  • The SRv6 Locator is advertised via the SRv6 Locator TLV introduced in this document ().
  • The attributes of the SRv6 Locator are advertised via the Prefix Attribute Flags TLV specified in .
The SRv6 SIDs associated with the node are advertised using the BGP-LS SRv6 SID NLRI introduced in this document (). This enables the BGP-LS encoding to scale to cover a potentially large set of SRv6 SIDs instantiated on a node with the granularity of individual SIDs and without affecting the size and scalability of the BGP-LS updates. If the SRv6 SIDs had been advertised within the BGP-LS Link Attribute associated with the existing Node NLRI, the BGP-LS update would have grown rather large with the increase in SRv6 SIDs on the node and would have also required a large update message to be generated for any change, even a change to a single SRv6 SID. BGP-LS Attribute TLVs for the SRv6 SID NLRI are introduced in this document as follows:
  • The Endpoint behavior of the SRv6 SID is advertised via the SRv6 Endpoint Behavior TLV ().
  • The BGP EPE Peer Node context for a PeerNode SID and the Peer Set context for a PeerSet SID are advertised via the SRv6 BGP PeerNode SID TLV ().
Subsequent sections of this document specify the encoding and usage of these extensions. All the TLVs introduced follow the formats and common field definitions provided in .
SRv6 Node Attributes The SRv6 attributes of a node are advertised using the BGP-LS Attribute TLVs defined in this section and associated with the BGP-LS Node NLRI.
SRv6 Capabilities TLV This BGP-LS Attribute TLV 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. A single instance of this TLV MUST be included in the BGP-LS Attribute for each SRv6-capable node. The IS-IS SRv6 Capabilities sub-TLV and the OSPFv3 SRv6 Capabilities TLV that map to this BGP-LS TLV are specified with the ability to carry optional sub-sub-TLVs and sub-TLVs. However, no such extensions are currently defined. Moreover, the SRv6 Capabilities TLV defined below is not extensible. As a result, it is expected that any extensions will be introduced as top-level TLVs in the BGP-LS Attribute. The SRv6 Capabilities TLV has the following format:
SRv6 Capabilities TLV Format 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 flags are copied from the IS-IS SRv6 Capabilities sub-TLV () or from the OSPFv3 SRv6 Capabilities TLV () in the case of IS-IS or OSPFv3, respectively.
Reserved:
2-octet field that MUST be set to 0 when originated and ignored on receipt.
SRv6 Node MSD Types The Node MSD TLV of the BGP-LS Attribute of the Node NLRI is also used to advertise the limits and the Segment Routing Header (SRH) operations supported by the SRv6-capable node. The SRv6 MSD types specified in are also used with the BGP-LS Node MSD TLV, as these code points are shared between the IS-IS, OSPF, and BGP-LS protocols. The description and semantics of these new MSD types for BGP-LS are identical to those specified in . Each MSD type is encoded in the BGP-LS Node MSD TLV as a one-octet type followed by a one-octet value as derived from the IS-IS or OSPFv3 Node MSD advertisements specified in .
SRv6 Link Attributes SRv6 attributes and SIDs associated with a link or adjacency are advertised using the BGP-LS Attribute TLVs defined in this section and associated with the BGP-LS Link NLRI.
SRv6 End.X SID TLV The SRv6 End.X SID TLV 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. The information advertised via this TLV is derived from the IS-IS SRv6 End.X SID sub-TLV () or the OSPFv3 SRv6 End.X SID sub-TLV () in the case of IS-IS or OSPFv3, respectively. This TLV can also be used to advertise the SRv6 SID corresponding to the underlying Layer 2 member links for a Layer 3 bundle interface as a sub-TLV of the L2 Bundle Member Attribute TLV . This TLV 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 . The SRv6 SID for the BGP Peer Adjacency using End.X behaviors (viz. End.X, End.X with PSP, End.X with USP, and End.X with PSP & USP) indicates the cross-connect to a specific Layer 3 link to the specific BGP session peer (neighbor). More than one instance of this TLV (one for each SRv6 End.X SID) can be included in the BGP-LS Attribute. The TLV has the following format:
SRv6 End.X SID TLV Format 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 .
Flags:
1 octet of flags. The flags are copied from the IS-IS SRv6 End.X SID sub-TLV () or the OSPFv3 SRv6 End.X SID sub-TLV () in the case of IS-IS or OSPFv3, respectively. In the case of the BGP EPE Peer Adjacency SID, the flags are as defined in .
Algorithm:
1-octet field. Algorithm associated with the SID.
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 .
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. This document defines one in .
SRv6 LAN End.X SID TLV For a LAN interface, an IGP node ordinarily announces only its adjacency to the IS-IS pseudonode (or the equivalent OSPF DR). The information advertised via this TLV is derived from the IS-IS SRv6 LAN End.X SID sub-TLV () or the OSPFv3 SRv6 LAN End.X SID sub-TLV () in the case of IS-IS or OSPFv3, respectively. The SRv6 LAN End.X SID TLV allows a node to announce the SRv6 SID corresponding to its adjacencies to all other (i.e., non-DIS or non-DR) nodes attached to the LAN in a single instance of the BGP-LS Link NLRI. Without this TLV, multiple BGP-LS Link NLRIs would need to be originated, one for each neighbor, to advertise the SRv6 End.X SID TLVs for those non-DIS/non-DR neighbors. The SRv6 SID for these IGP adjacencies using the End.X behaviors (viz. End.X, End.X with PSP, End.X with USP, and End.X with PSP & USP) are advertised using the SRv6 LAN End.X SID TLV. More than one instance of this TLV (one for each SRv6 LAN End.X SID) can be included in the BGP-LS Attribute. The BGP-LS IS-IS SRv6 LAN End.X SID and BGP-LS OSPFv3 SRv6 LAN End.X SID TLVs have the following format:
SRv6 LAN End.X SID TLV Format 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 | Neighbor ID - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IS-IS System-ID (6 octets) or OSPFv3 Router-ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont ...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type:
1107 for IS-IS and 1108 for OSPFv3
Length:
variable
Endpoint Behavior:
2-octet field. The Endpoint behavior code point for this SRv6 SID as defined in .
Flags:
1 octet of flags. The flags are copied from the IS-IS SRv6 LAN End.X SID sub-TLV () or the OSPFv3 SRv6 LAN End.X SID sub-TLV () in the case of IS-IS or OSPFv3, respectively.
Algorithm:
1-octet field. Algorithm associated with the SID.
Weight:
1-octet field. The value represents the weight of the SID for the purpose of load balancing.
Reserved:
1-octet field that MUST be set to 0 when originated and ignored on receipt.
Neighbor ID:
6 octets of Neighbor System-ID in the IS-IS SRv6 LAN End.X SID TLV or 4 octets of Neighbor Router-ID in the OSPFv3 SRv6 LAN End.X SID TLV.
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. This document defines one in .
SRv6 Link MSD Types The Link MSD TLV of the BGP-LS Attribute of the Link NLRI is also used to advertise the limits and the SRH operations supported on the specific link by the SRv6-capable node. The SRv6 MSD types specified in are also used with the BGP-LS Link MSD TLV, as these code points are shared between the IS-IS, OSPF, and BGP-LS protocols. The description and semantics of these new MSD types for BGP-LS are identical as specified in . Each MSD type is encoded in the BGP-LS Link MSD TLV as a one-octet type followed by a one-octet value as derived from the IS-IS or OSPFv3 Link MSD advertisements specified in .
SRv6 Prefix Attributes SRv6 attributes with an IPv6 prefix are advertised using the BGP-LS Attribute TLVs defined in this section and associated with the BGP-LS Prefix NLRI.
SRv6 Locator TLV As specified in , an SRv6 SID comprises locator, function, and argument parts. 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 Prefix NLRI object along with the SRv6 Locator TLV in its BGP-LS Attribute. The information advertised via this TLV is derived from the IS-IS SRv6 Locator TLV () or the OSPFv3 SRv6 Locator TLV () in the case of IS-IS or OSPFv3, respectively. The IPv6 Prefix matching the locator may also be advertised as prefix reachability by the underlying routing protocol. In this case, the Prefix NLRI would also be associated with the Prefix Metric TLV that carries the routing metric for this prefix. A Prefix NLRI that has been advertised with a SRv6 Locator TLV is also considered a normal routing prefix (i.e., prefix reachability) only when there is also an IGP Metric TLV (TLV 1095) associated it. Otherwise, it is only considered an SRv6 Locator advertisement. The SRv6 Locator TLV has the following format:
SRv6 Locator TLV Format 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. The flags are copied from the IS-IS SRv6 Locator TLV () or the OSPFv3 SRv6 Locator TLV () in the case of IS-IS or OSPFv3, respectively.
Algorithm:
1-octet field. Algorithm associated with the SID.
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 copied from the IS-IS SRv6 Locator TLV () or the OSPFv3 SRv6 Locator TLV () in the case of IS-IS or OSPFv3, respectively.
Sub-TLVs:
Used to advertise sub-TLVs that provide additional attributes for the given SRv6 Locator. Currently, none are defined.
SRv6 SID NLRI The Link-State NLRI defined in is extended to carry the SRv6 SID information. This document defines the following new Link-State NLRI type for SRv6 SID information: SRv6 SID NLRI (type 6). The SRv6 SIDs associated with the node are advertised using the BGP-LS SRv6 SID NLRI. This new NLRI type has the following format:
SRv6 SID NLRI Format 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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Node Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 SID Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Protocol-ID:
1-octet field that specifies the information source protocol .
Identifier:
8-octet value as defined in .
Local Node Descriptors TLV:
Set of Node Descriptor TLVs for the local node as defined in for IGPs, the Direct Protocol-ID, and the Static configuration Protocol-ID or as defined in for BGP.
SRv6 SID Descriptors:
Set of SRv6 SID Descriptor TLVs. This field MUST contain a single SRv6 SID Information TLV () and MAY contain the Multi-Topology Identifier TLV .
New TLVs for advertisement within the BGP-LS Attribute are defined in to carry the attributes of an SRv6 SID.
SRv6 SID Information TLV An SRv6 SID that is associated with the node and advertised using the SRv6 SID NLRI is encoded using the SRv6 SID Information TLV. When advertising the SRv6 SIDs from the IGPs, the SID information is derived from the IS-IS SRv6 End SID sub-TLV () or the OSPFv3 SRv6 End SID sub-TLV () in the case of IS-IS or OSPFv3, respectively. The TLV carries the SRv6 SIDs corresponding to the BGP PeerNode and PeerSet SIDs when SRv6 BGP EPE functionality is enabled in BGP. The TLV has the following format:
SRv6 SID Information TLV Format 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.
SRv6 SID Attributes This section specifies the TLVs to be carried in the BGP Link State Attribute associated with the BGP-LS SRv6 SID NLRI.
SRv6 Endpoint Behavior TLV Each SRv6 SID instantiated on an SRv6-capable node has specific instructions (called "behavior") bound to it. describes how behaviors are bound to a SID and also defines the initial set of well-known behaviors. The SRv6 Endpoint Behavior TLV is a mandatory TLV that MUST be included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID NLRI. When advertising the SRv6 SIDs from the IGPs, the Endpoint behavior, Flags, and Algorithm are derived from the IS-IS SRv6 End SID sub-TLV () or the OSPFv3 SRv6 End SID sub-TLV () in the case of IS-IS or OSPFv3, respectively. When advertising the SRv6 SIDs corresponding to the BGP EPE functionality, the Endpoint behavior corresponds to End.X and similar behaviors. When advertising the SRv6 SIDs that are locally instantiated on the node using Direct as the Protocol-ID, the Endpoint behavior corresponds to any SRv6 Endpoint behavior associated with the node. Flags are currently not defined. The algorithm value MUST be 0 unless an algorithm is associated locally with the SRv6 Locator from which the SID is allocated. The TLV has the following format:
SRv6 Endpoint Behavior 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Behavior | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type:
1250
Length:
4
Endpoint Behavior:
2-octet field. The Endpoint behavior code point for this SRv6 SID. Values are from the "SRv6 Endpoint Behaviors" IANA registry ().
Flags:
1 octet of flags. The flags map to the IS-IS or OSPFv3 encodings when advertising SRv6 SIDs corresponding to IGPs. No flags are currently defined for SRv6 SIDs corresponding to BGP EPE or for advertisement of a SRv6 SID using Direct as the Protocol-ID. Undefined flags MUST be set to 0 when originating and ignored on receipt.
Algorithm:
1-octet field. Algorithm associated with the SID.
SRv6 BGP PeerNode SID TLV The BGP PeerNode and PeerSet SIDs for SR-MPLS are specified in . Similar Peer Node and Peer Set functionality can be realized with SRv6 using SIDs with END.X behavior. Refer to for some differences between the signaling of these SIDs in SR-MPLS and SRv6. The SRv6 BGP PeerNode SID TLV is a mandatory TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI advertised by BGP for the EPE functionality. This TLV MUST be included along with SRv6 SIDs that are associated with the BGP PeerNode or PeerSet functionality. The TLV has the following format:
SRv6 BGP PeerNode SID TLV Format 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 | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type:
1251
Length:
12
Flags:
1 octet of flags with the following definitions:
SRv6 BGP EPE SID Flags Format 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P| | +-+-+-+-+-+-+-+-+
B-Flag:
Backup Flag. If set, the SID is eligible to be protected using Fast Reroute (FRR). The computation of the backup forwarding path and its association with the forwarding entry for the Peer BGP Identifier are implementation specific.
S-Flag:
Set Flag. When set, the S-Flag indicates that the SID refers to a set of BGP peering sessions (i.e., BGP Peer Set SID functionality) and therefore MAY be assigned to one or more End.X SIDs associated with BGP peering sessions.
P-Flag:
Persistent Flag. When set, the P-Flag indicates that the SID is persistently allocated, i.e., the value remains consistent across router restart and/or session flap.
Other bits are reserved for future use and MUST be set to 0 when originated and ignored on receipt. The flags defined above are also used with the SRv6 End.X SID TLV when advertising the SRv6 BGP Peer Adjacency SID ().
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 .
Reserved:
2-octet field. The value MUST be set to 0 when originated and ignored on receipt.
Peer AS Number:
4 octets of the BGP AS number of the peer router.
Peer BGP Identifier:
4 octets of the BGP Identifier (BGP Router-ID) of the peer router.
For an SRv6 BGP EPE PeerNode SID, one instance of this TLV is associated with the SRv6 SID. For an SRv6 BGP EPE PeerSet SID, multiple instances of this TLV (one for each peer in the "peer set") are associated with the SRv6 SID and the S-Flag is set.
SRv6 SID Structure TLV The SRv6 SID Structure TLV is used to advertise the length of each individual part of the SRv6 SID as defined in . It is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI and as a sub-TLV of the SRv6 End.X SID, IS-IS SRv6 LAN End.X SID, and OSPFv3 SRv6 LAN End.X SID TLVs. When advertising SRv6 SIDs from the IGPs, the SRv6 SID Structure information is derived from the IS-IS SRv6 SID Structure sub-sub-TLV () or the OSPFv3 SRv6 SID Structure sub-TLV () in the case of IS-IS or OSPFv3, respectively. When advertising the SRv6 SIDs corresponding to the BGP EPE functionality or for advertising SRv6 SIDs using Direct as the Protocol-ID, the SRv6 SID Structure information is derived from the locally provisioned SRv6 SID. The TLV has the following format:
SRv6 SID Structure 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 the LB Length, LN Length, Fun. Length, and Arg. Length MUST be less than or equal to 128.
IANA Considerations Per this document, IANA has allocated code points in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group, as described in the subsections below.
BGP-LS NLRI Types IANA has assigned the following code points in the "BGP-LS NLRI Types" registry: Addition to BGP-LS NLRI Types Registry
Type NLRI Type Reference
6 SRv6 SID NLRI RFC 9514
BGP-LS NLRI and Attribute TLVs IANA has assigned the following TLV code points in the "BGP-LS NLRI and Attribute TLVs" registry: Additions to BGP-LS NLRI and Attribute TLVs Registry
TLV Code Point Description Reference
518 SRv6 SID Information RFC 9514
1038 SRv6 Capabilities RFC 9514
1106 SRv6 End.X SID RFC 9514
1107 IS-IS SRv6 LAN End.X SID RFC 9514
1108 OSPFv3 SRv6 LAN End.X SID RFC 9514
1162 SRv6 Locator RFC 9514
1250 SRv6 Endpoint Behavior RFC 9514
1251 SRv6 BGP PeerNode SID RFC 9514
1252 SRv6 SID Structure RFC 9514
SRv6 BGP EPE SID Flags Per this document, IANA has created a new registry called "SRv6 BGP EPE SID Flags" under the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group. The allocation policy of this registry is "Standards Action" according to . The initial contents of the registry are as follows: New SRv6 BGP EPE SID Flags Registry
Bit Description Reference
0 Backup Flag (B-Flag) RFC 9514
1 Set Flag (S-Flag) RFC 9514
2 Persistent Flag (P-Flag) RFC 9514
3-7 Unassigned
Manageability Considerations This section is structured as recommended in . The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via . Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in Section Manageability Considerations of . Specifically, the malformed attribute tests for syntactic checks in Section Fault Management of now encompass the new BGP-LS extensions defined in this document. The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their BGP-LS Attribute are left to the consumer of the BGP-LS information (e.g., an application or a controller) and not BGP. The SR information introduced in BGP-LS by this specification may be used by BGP-LS consumer applications like an SR Path Computation Engine (PCE) to learn the SRv6 capabilities of the nodes in the topology and the mapping of SRv6 segments to those nodes. This can enable the SR PCE to perform path computations based on SR for traffic-engineering use cases and to steer traffic on paths different from the underlying IGP-based distributed best path computation. Errors in the encoding or decoding of the SRv6 information may result in the unavailability of such information to the SR PCE or incorrect information being made available to it. This may result in the SR PCE not being able to perform the desired SR-based optimization functionality or performing it in an unexpected or inconsistent manner. The handling of such errors by applications like SR PCE may be implementation specific and out of the scope of this document. The manageability considerations related to BGP EPE functionality are discussed in in the context of SR-MPLS; they also apply to this document in the context of SRv6. The extensions specified in this document do not introduce any new configuration or monitoring aspects in BGP or BGP-LS other than as discussed in . The manageability aspects of the underlying SRv6 features are covered by .
Security Considerations The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via . The advertisement of the SRv6 link-state information defined in this document presents a similar risk as associated with the existing link-state information as described in . Section Security Considerations of also applies to these extensions. The procedures and new TLVs defined in this document, by themselves, do not affect the BGP-LS security model discussed in . The extensions introduced in this document are used to propagate IGP-defined information . These extensions represent the advertisement of SRv6 information associated with the IGP node, link, and prefix. The IGP instances originating these TLVs are assumed to support all the required security and authentication mechanisms (as described in and ). The security considerations related to BGP EPE functionality are discussed in in the context of SR-MPLS, and they also apply to this document in the context of SRv6. BGP-LS SRv6 extensions enable traffic-engineering use cases within the SR domain. SR operates within a trusted domain , and its security considerations also apply to BGP-LS sessions when carrying SR information. The SR traffic-engineering policies using the SIDs advertised via BGP-LS are expected to be used entirely within this trusted SR domain (e.g., between multiple AS or IGP domains within a single provider network). Therefore, precaution is necessary to ensure that the link-state information (including SRv6 information) advertised via BGP-LS sessions is securely limited to consumers within this trusted SR domain. BGP peering sessions for address families other than Link State may be set up to routers outside the SR domain. The isolation of BGP-LS peering sessions is RECOMMENDED to ensure that BGP-LS topology information (including the newly added SR information) is not advertised to an external BGP peering session outside the SR domain.
References 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. North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP In a number of environments, a component external to a network is called upon to perform computations based on the network topology and 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 new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual 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). Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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. Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. 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. Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies. This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP. Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) Huawei Technologies Huawei Technologies Cisco Systems Cisco Systems Informative References Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. This memo provides information for the Internet community. 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. YANG Data Model for SRv6 Base and Static Cisco Systems Cisco Systems Volta Networks Huawei Technologies Infinera Corporation Ciena Corporation Bell Canada SoftBank SoftBank Cisco Systems Cisco Systems Work in Progress
Differences with BGP-EPE for SR-MPLS The signaling of SRv6 SIDs corresponding to BGP-EPE functionality as defined in this document differs from the signaling of SR-MPLS BGP-EPE SIDs as specified in . This section provides a high-level overview of the same. There is no difference in the advertisement of the BGP Peer Adjacency SID in both SR-MPLS and SRv6, and it is advertised as an attribute of the Link NLRI, which identifies a specific Layer 3 interface on the BGP Speaker. The difference is in the advertisement of the BGP PeerNode and PeerSet SIDs. In the case of SR-MPLS, an additional Link NLRI is required to be advertised corresponding to each BGP peering session on the node. Note that this is not the same Link NLRI associated with the actual Layer 3 interface even when the peering is set up using the interface IP addresses. These BGP-LS Link NLRIs are not really links in the conventional link-state routing data model but instead identify BGP peering sessions. The BGP PeerNode and/or PeerSet SIDs associated with that peering session are advertised as attributes associated with this peering Link NLRI. In the case of SRv6, each BGP PeerNode or PeerSet SID is considered to be associated with the BGP Speaker Node and is advertised using the BGP-LS SRv6 SID NLRI, while the peering session information is advertised as attributes associated with it. The advertisement of the BGP PeerSet SID for SR-MPLS is done by including that SID as an attribute in all the Link NLRIs corresponding to the peering sessions that are part of the "set". The advertisement of the BGP PeerSet SID for SRv6 is advertised using a single SRv6 SID NLRI, and all the peers associated with that "set" are indicated as attributes associated with the NLRI.
Acknowledgements The authors would like to thank , , , , , , , , and for their review of this document and their comments. The authors would also like to thank for her shepherd review and for his detailed Routing Area Directorate review.
Contributors AT&T
United States of America ju1738@att.com
Ericsson
United States of America hani.elmalky@gmail.com
Individual
United States of America arjunhrs@gmail.com
Cisco Systems
United States of America ginsberg@cisco.com
Huawei
China zhuangshunwan@huawei.com
Authors' Addresses LinkedIn
United States of America gdawra.ietf@gmail.com
Cisco Systems
Belgium cfilsfil@cisco.com
Cisco Systems
India ketant.ietf@gmail.com
Huawei
China mach.chen@huawei.com
Bell Canada
Canada daniel.bernier@bell.ca
Orange
France bruno.decraene@orange.com